メインコンテンツまでスキップ

自律実行の堅牢化

上級
What you'll learn
  • 人が見ていない実行に固有の 3 つのリスク
  • 適用すべき順に並べた 8 項目の堅牢化チェックリスト
  • どの権限プリミティブが実際に機能を取り除き、どれが事前承認するだけなのか
  • なぜ慎重なプロンプトよりも最小権限トークンのほうが重要なのか
  • 暴走ループを、願望ベースの指示ではなくプラットフォームが強制する予算で抑える方法
  • 永続的な指示ファイルを、エージェントが書き込めない場所へ diff しておくべき理由

Claude をヘッドレスやスケジュールで実行する場合 — CI、cron ジョブ、pre-commit フック — 本来なら不適切な操作を止めてくれる人間がいなくなります。この便利さこそ、こうした実行に最も厳しいガードレールが必要な理由です。

無人実行に固有のリスク​

  • 危険なツール呼び出しをその場で止める人がいない。
  • 環境に存在する認証情報。 CI には強力なトークン(デプロイ、パッケージレジストリ、クラウド)があることが多く、そこで動くエージェントはそれらを継承します。
  • 信頼できない入力。 PR や issue をきっかけに起動した実行は、攻撃者が書いたコンテンツを処理する可能性があります(インジェクション)。
Watch out

設計で防ぐべき失敗モードは、悪意あるモデルではありません。持たせるべきでないトークンを握った普通のモデルが、攻撃者の書いたテキストに従って動くことです。以下の各項目は、この 3 つの要素のどれかを取り除きます。

堅牢化チェックリスト​

Guided walkthrough1 of 8
  1. 権限の deny ルールで .env、鍵ファイル、認証情報のパスの読み取りをブロックします。モデルが避けてくれることに頼ってはいけません。deny ルールは機能を取り除ける唯一のプリミティブです。allow リストにこの役目が果たせない理由は、6 段階の評価順序を参照してください。

deny は取り除き、allow は事前承認するだけ​

堅牢化した実行で最もよくある間違いは、使うレバーを間違えることです。allow リストは鍵のように見えますが、そうではありません。リストに載せなかったものもエージェントは使え続けられ、セッションの権限モードにフォールスルーするだけです。

機能を取り除く — リクエストからツールが消える

claude -p "run the test suite" \
--disallowedTools "Bash(curl *)" "Read(//.ssh/**)" "Edit(//etc/**)"

事前承認リストを厳密にする — それ以外は確認ではなく拒否される

claude -p "run the test suite" \
--permission-mode dontAsk \
--allowedTools "Bash(npm test)" "Read"

CI で使いたいのは後者の形です。dontAsk は確認プロンプトになるはずのものをすべて拒否に変えるため、想定外の事態に遭遇した実行は、ハングしたり、緩いデフォルトに黙ってフォールバックしたりせず、はっきりと失敗します。

呼び出しごとに走るチェック​

allow ルールと deny ルールはパターンにマッチします。呼び出しの内容 — 引数に含まれるシークレットらしき文字列や、想定外のホスト名 — を検査するチェックが必要なら、PreToolUse フックに置きます。フックは他のすべての権限ステップより先に実行され、フックによる拒否は bypass モードでも有効です。

シークレットを含むツール呼び出しをすべて拒否する

# .claude/settings.json -> hooks.PreToolUse
# Exit code 2 blocks the call and tells Claude why.
jq -e '.tool_input | tostring | test("AKIA|BEGIN PRIVATE KEY|ghp_")' >/dev/null \
&& { echo "secret material in tool input" >&2; exit 2; } || exit 0

例: 安全な CI レビュアー​

PR レビューボットは、コードを読み取り専用でチェックアウトし、デプロイやシークレットへのアクセスを持たず、コンテナ内で動き、発見事項をコメントする — 保護されたブランチは決して変更しない、という形であるべきです。PR レビューのウォークスルーを参照してください。

Check yourself

0/3
  1. CI の実行がコンテナ内で bypassPermissions を使っています。次のうち、ツール呼び出しをそれでもブロックするのはどれですか?
  2. CI の実行で、プロンプトインジェクションが成功した場合の被害を最も抑えられる単一の対策はどれですか?
  3. CLAUDE.md とスキルファイルを、エージェントが書き込めない場所へ diff しておくべきなのはなぜですか?
Key takeaways
  • 無人実行は人間の拒否権を失い、環境の認証情報を継承し、攻撃者が書いたテキストを読むことも多い — 要素を一つずつ取り除く。
  • deny ルールとフックは機能を取り除き、allow リストは事前承認するだけ。allowedTools を dontAsk と組み合わせて厳密にする。
  • プロンプトを調整する前にトークンのスコープを絞る。インジェクションが言いくるめられない防御だ。
  • コストとイテレーションの上限は、指示ではなくプラットフォームが強制する予算で設ける。
  • 出力は PR かコメントとして出し、人間のマージを挟む。
  • 自動注入される指示ファイルは、エージェントが書き込めないストレージへ diff する。

次へ​