OpenClawのスキル、heartbeatによる自律動作、承認ゲート

OpenClawをインストールし、チャネルのIDを制限したら（セットアップ、許可リストとペアリング）、次は能力の設定です。スキル、定期的なheartbeatターン、ホストシェルの承認ポリシー、レビュー済みワークフロー内でブラウザー自動化を有効にするかを決めます。

ドキュメント：スキル、Heartbeat、セキュリティー。

heartbeatと無制限のホストexec、または重要なログイン状態を持つブラウザー自動化を組み合わせると、そのインターフェースに公開された認証情報とアクセス権を使う無人操作が可能になります。ツールポリシーが脅威モデルに合うまで定期ターンを有効にしないでください。特に、自分以外のチャネルからエージェントを起動できる場合は注意が必要です。

スキルとは何か

スキルは、YAML frontmatterと本文を持つSKILL.mdからなるMarkdown指示パッケージです。エージェントにツールを使う場面と方法を教えます。OpenClawは同梱スキルとローカルの上書きを読み込み、環境、設定、必要なバイナリーの有無に応じて、読み込み時に絞り込みます。

現行ドキュメントに基づく優先順位は、上から次のとおりです。

1. ワークスペーススキル
2. プロジェクトのエージェントスキル
3. 個人用エージェントスキル（既定では~/.agents/skills）
4. OpenClawの状態ディレクトリーにある管理対象またはローカルスキル
5. 同梱スキル
6. 追加ディレクトリーまたはプラグインスキル

同じ名前のスキルが複数の場所にある場合は、優先順位の高いソースが使われます。スキルフォルダーは信頼済みコードとして扱ってください。変更できる人は、エージェントの動作も変更できます。

エージェントに見せるスキルの許可リスト

配置場所の優先順位と、エージェントごとの許可リストによる可視性は別のものです。ドキュメントにある構成例：

{
  agents: {
    defaults: {
      skills: ['github', 'weather'],
    },
    list: [
      { id: 'writer' },
      { id: 'docs', skills: ['docs-search'] },
      { id: 'locked-down', skills: [] },
    ],
  },
}

意図して広いインターフェースを与える場合だけ、既定のスキル一覧を省略します。個人用ゲートウェイでは、読んだことがあり、インストールしたバイナリーと一致し、実際の仕事に使うスキルだけから始めてください。

コミュニティースキルとプラグインはサプライチェーンです。インストールによってコードが実行され、ツールの範囲が広がる可能性があります。公式ドキュメントとレビュー済みのスキルを優先してください。運用者が所有するホスト側の許可または拒否判断を強制する場合は、security.installPolicyを使います。

ノードでホストするスキルは、ペアリング済みノードが接続している間だけ表示されます。ファイル、参照パス、バイナリーはそのノードに残り、実行にはexec host=node node=<node-id>を使います。最初のノードロールのペアリングによってスキル公開が承認されます。その後のスキル変更にはノードの再起動が必要ですが、再ペアリングは不要です。実行は引き続きエージェントのexecポリシーと、ノードのホストローカル承認ポリシーに従います。

Heartbeat：脈拍であり、第二の頭脳ではない

Heartbeatはメインセッションで定期的なエージェントターンを実行し、注意が必要なことを過剰に通知せずモデルから提示できるようにします。これは定期実行されるメインセッションのターンであり、バックグラウンドタスクの記録ではありません。

既定値は導入バージョンで確認してください。

• 間隔は多くの場合30m。Anthropic OAuthまたはトークン設定では、未指定時の既定値がより長くなることがあり、ドキュメントではその場合を1hとしている
• agents.defaults.heartbeat.everyで設定し、0mで無効化
• 既定のプロンプトは、古いチャットから定期作業を作り出すのではなく、heartbeatモニターのスクラッチに従い、注意事項がなければHEARTBEAT_OKと返すよう指示

設定例：

{
  agents: {
    defaults: {
      heartbeat: {
        every: '30m',
        target: 'none',
        lightContext: true,
        isolatedSession: true,
        // activeHours: { start: "08:00", end: "22:00" },
      },
    },
  },
}

実用上の指針：

• 配信が必要になるまではtarget: "none"を維持します。最後の連絡先への通知を許容する場合だけtarget: "last"を設定します。
• activeHoursを使い、自分のタイムゾーンで夜間のheartbeatを止めます。
• 定期作業はheartbeatスクラッチの曖昧な覚え書きではなく、automationsまたはcronジョブへ置きます。heartbeatドキュメントもこの区別を強調しています。
• 定期heartbeatにはautomationsの有効化が必要です。cronを無効にすると、定期heartbeatは動きません。

応答契約：先頭または末尾のHEARTBEAT_OKは確認応答として扱われ、残りの内容が短い場合は表示されません。アラートではHEARTBEAT_OKを省き、アラート本文だけを返します。

heartbeatターンでも、エージェントが利用できるツールが使われます。execを許可した「無害な定期確認」も、メモリや取得したページに含まれるプロンプトインジェクションからシェル操作を要求される定期的な機会になります。heartbeatにはツールの拒否または確認ポリシーを組み合わせてください。

シェルとブラウザーの承認ゲート

OpenClawのセキュリティーモデルでは、exec承認を運用者の意図を守るガードレールとして扱い、敵対的なマルチテナント隔離とは見なしません。それでも個人用ゲートウェイでは、「私に確認する」と「そのまま実行する」の違いになります。

Exec

現行のexec承認リファレンスにある関連設定です。導入済みバージョン付属のスキーマでも確認してください。

• tools.exec.modeは、永続化されるホストexecポリシーの標準フィールドで、deny、allowlist、ask、auto、fullを指定します。
• autoは、承認に一致しない要求をOpenClawの組み込みレビュアーへ送り、その後で人によるフォールバックを使います。これは利便性のための経路であり、コマンドが安全である証明ではありません。
• Gatewayとノードでの実行は、実行ホストのローカル承認文書も参照します。設定とホストローカル文書のうち、厳しい方が実効ポリシーになります。
• askFallbackは、確認が必要でもUIへ到達できない、またはタイムアウトした場合に適用されます。既定値はdenyです。承認経路の消失によってアクセスが広がらないよう、そのままにしてください。
• 許可リストはエージェントごとに設定します。実行ファイルのパスを狭くし、必要に応じてargPatternを使います。インタープリターを許可する場合は、strictInlineEvalが多層防御を追加します。
• tools.exec.host: "auto"は、有効なサンドボックスがあればサンドボックスへ、それ以外ではGatewayへ解決されます。ノードでの実行にはペアリング済みノードと、そのノード固有のホストローカル承認状態が必要です。

最初はtools.exec.mode: "deny"を使います。確認が必要なら、mode: "ask"と、同等に厳しいホストローカル承認文書を組み合わせ、elevatedツールは無効のままにしてください。それ以外では、Gatewayとノードのホスト実行は既定でfull、サンドボックスのホスト実行は既定で拒否です。チャネル、スキル、heartbeatによって影響範囲が広がる前に、ホストポリシーを厳しくします。

ペアリング済みMacでのノードsystem.runは、そのMac上でのリモートコード実行です。ペアリングはコマンドごとの承認ではありません。Gatewayのノードコマンドポリシーと、ノード自身のexec承認が実行境界を構成します。リモートシェル実行を無効にするには、要求するexecモードをdenyにし、ノードのホストローカル承認ポリシーも厳しく保ちます。不要ならノードロールとペアリングを削除してください。

ブラウザー

ブラウザー制御は、ナビゲーション、ページの読み取り、評価を行える運用者向けインターフェースです。リモートブラウザーやCDPの公開を運用者アクセスとして扱い、ループバックか意図して保護した非公開経路だけを使い、公開CDPや制御エンドポイントを設けないでください。日常利用するブラウザープロファイルから隔離された専用のopenclawプロファイルを使い、レビュー済みのタスクで必要になるまでブラウザープラグインやツールを無効にします。exec承認はクリックごとのブラウザー承認境界を作りません。重要な送信、購入、公開、アカウント変更の前に、ワークフロー内で人の確認を必須にします。

取得したページを介するプロンプトインジェクションは主要なリスクです。ツールの許可または拒否ポリシー、ブラウザープロファイルの分離、明示的なワークフロー確認、サンドボックス化は影響範囲を狭めますが、チャネル許可リストの必要性をなくしません。

Elevatedツール

tools.elevatedはサンドボックスを回避します。allowFromを厳しく制限してください。第三者や広いチャネル利用者向けにelevatedモードを有効にしてはいけません。

無理のない自律性の段階

openclaw security auditを実行し、通常作業、拒否経路、承認タイムアウト、復旧を試せるだけの実行記録を保持してから、次の段階へ進みます。固定した日数は安全性の証明になりません。

小さな社内スキルを書く

最小限で役に立つスキルは、SKILL.mdを含むフォルダーです。

---
name: disk-check
description: Check disk usage on the gateway host when asked about disk or capacity.
---

When the user asks about disk space on this host:

1. Run only the allowlisted `df` invocation your exec policy permits.
2. Summarise filesystem use in three bullets.
3. Do not install packages or delete files.

エージェントが使う_場面_を判断できるよう、説明は具体的にします。スキルには、範囲の狭いexecモード、レビュー済みのエージェント別コマンドと引数規則、strictInlineEval、サンドボックスまたはOS隔離を組み合わせてください。これらはコマンドインターフェースを狭めますが、許可したインタープリターや補助ツールが破壊的な操作を実行できないことを証明しません。便利そうなClawHubパッケージを片端から導入せず、自分で管理するワークスペーススキルを優先します。

heartbeatスクラッチに入れるものと入れないもの

heartbeatモニターのスクラッチ（openclaw cron scratch <jobId> --set "..."）は、第二のタスクデータベースではなく短いチェックリストとして使います。

良い例：「ゲートウェイホストのディスク使用率が90%を超えたら通知する。問題がなければHEARTBEAT_OK。」 悪い例：「第3四半期のロードマップを終え、Aliceへメールし、エージェントをリファクタリングし、競合価格をスクレイピングすることを覚えておく。」

定期作業は独自のスケジュールを持つautomationsに置きます。古いチャットからheartbeatが雑務を毎回推論すると、静かだった環境が騒がしく、費用も高くなります。

承認を信頼する前にテストする

1. 安全側に閉じるテストではtools.exec.modeをdenyにする。確認を試す場合はaskにし、同等以上に厳しいホストローカル承認文書を用意する。
2. 許可リスト登録済みのDMから、unameまたは同等の無害な確認コマンドを実行するようエージェントへ依頼する。
3. 黙って成功するのではなく、明確な拒否または承認プロンプトが表示されることを確認する。
4. プロンプトをテストする場合は、要求を1つタイムアウトさせるかUIを利用不能にし、askFallback: "deny"で阻止されることを確認する。実効askポリシーがalwaysなら、次の異なるコマンドでも再度確認されることを確かめる。
5. ノードをペアリングしている場合は、そのノードに別途保存された承認ポリシーに対してテストを繰り返す。
6. 許可リストにないIDからツールへの経路が存在しないことを確認する。

手順3が設定したゲートなしで成功した場合は、heartbeatを有効にする前に、要求したexecモードと実行ホストのローカル承認文書を両方確認してください。

定期的な連携処理はn8nと組み合わせる

Heartbeatは、エージェントが判断する定期確認に向きます。手順が明確なSaaSのポーリング、再試行、人によるゲートは、多くの場合n8nに置きます（冪等性と人によるゲート、Hermes APIまたはwebhookへの引き継ぎ）。インターフェースがチャットならOpenClaw、システムならn8nを使います。

運用者向けチェックリスト

• スキルの許可リストをレビューし、未使用スキルを削除
• 第三者が書き込める信頼できないスキルディレクトリーがない
• heartbeatの間隔と有効時間帯を意図して設定
• heartbeatの配信先がグループチャネルへ過剰に通知しない
• tools.exec.modeがdenyまたはaskで、実行ホストのローカル承認文書が同等以上に厳しい
• 必要でなければブラウザー、検索、取得を無効化
• elevatedツールを無効化
• 無害なコマンドで承認経路をテスト
• 自律性を高めるたびに監査を再実行

スキルはエージェントに能力を与え、heartbeatは適時性を与えます。厳しいexecポリシー、ブラウザーポリシー、サンドボックス、チャネルID制御によって、能力と適時性が無人のホスト操作へ変わる可能性を抑えられます。この順序で、脅威モデルが正当化する範囲までだけ調整してください。