コーディングエージェントをYOLOモードで安全に実行する方法

コーディングエージェントをYOLOモードで実行する際の安全性は、爆発半径（blast radius）を封じ込めることによってのみ確保できます。エージェントを信頼するのではなく、エージェントの実行環境を使い捨て可能にするという考え方です。パーミッション・バイパスモード（Claude Codeの--dangerously-skip-permissions、Codexのfull-auto、Gemini CLIのYOLO）は、承認クリックの手間を省く代わりに、エージェントがSSHキーの読み取り、ファイルの削除、gitヒストリーの破壊、そして数秒前に自身が生成したコードの実行を、一切確認なしに行えるようにしてしまいます。モデルを信頼したり、より厳格なアローリストを作成したりしても、この問題は解決できません。解決策は、実際のリスクに応じた多層防御を用いて、エージェントが重要なものに影響を与えられない環境に配置することです。

本記事では、リスクモデル、必要な分離レイヤーを判断するためのツール非依存の意思決定ルール、Claude Codeが現在提供する公式の封じ込め機能、そしてトレードオフを明示したコピー＆ペースト可能な最小安全構成を解説します。この分野は月単位で進化するため、フラグやツール名は変わり続けますが、コンテナ、マイクロVM、エグレスプロキシ、使い捨てワークスペースといった基本的なプリミティブは変わりません。

2026年におけるClaude CodeのYOLOモードの実態

パーミッション・バイパスモードは、通常エージェントのシェルコマンドとファイル書き込みを制御する承認プロンプトとほとんどの安全チェックを無効にします。Claude Codeのパーミッションモードのドキュメントによると、--dangerously-skip-permissionsは--permission-mode bypassPermissionsと同等です。Claude Code v2.1.126で導入されたこのモードは、以前のバージョンでは依然としてプロンプトを表示していた保護されたパスへの書き込みもスキップします。ただし、モデルエラーに対するサーキットブレーカーとして、rm -rf /とrm -rf ~は引き続きプロンプトを表示します。また、このフラグはLinuxとmacOSでrootまたはsudoでの起動を拒否するようになりました。

root/sudo拒否については、サンドボックス化されたBashツールのドキュメントでも確認されており、エージェントをrootとして実行するすべての単純なDockerレシピを静かに破壊します。

より厳格なアローリストを作成しても解決できない理由は構造的なものです。コーディングエージェントに対する最小権限のアローリストは、エージェントの有効なアクション空間が無制限であるため機能しません。1つの正当なタスクが、パッケージのインストール、任意のパスへの書き込み、生成したばかりのコードの実行を行う場合があります。Ederaはこれを直接的に表現しています。有効な動作空間を列挙できないため、エージェントに最小権限を適用することはできないのです。破壊的に見えるすべてのコマンドは、エージェントが通常の作業でも実行するものです。

障害モードは仮定の話ではありません。Anthropicのautoモードに関する独自のインシデントログには、エージェントがリモートのgitブランチを削除し、エンジニアのGitHub認証トークンをアップロードし、本番データベースに対してマイグレーションを試みた事例が記録されています。これが脅威の本質です。悪意ではなく、フルシェルアクセスを持つ非決定論的プロセスが、もっともらしいが誤った操作を行うことです。

爆発半径の封じ込め：多層防御モデル

Ederaから借用したこの作業原則は、これをポリシーの問題ではなく回復力の問題として扱うことです。最終的に何かが必ず失敗することを受け入れ、失敗が発生した際にその影響が封じ込められるようにします。エージェントをサンドボックス化するのは、今回の実行で問題が起きると予想するからではありません。問題が起きた実行のコストが、認証情報の漏洩ではなく、コンテナの削除で済むようにするためです。

封じ込めには、両方が成立する必要がある2つの軸があります。効果的な分離には、ファイルシステムとネットワークの両方の制限が必要です。Claude Codeのサンドボックス化ドキュメントはこの依存関係を明示しています。ネットワーク分離がなければエージェントがSSHキーを外部に送信でき、ファイルシステム分離がなければエージェントがネットワークに到達するために脱出できます。一方の軸のみをカバーするレイヤーには穴があります。

単一のレイヤーですべての障害モードをカバーできるわけではないため、有用なメンタルモデルは、各レイヤーが保護するものと保護しないものを理解することです。

2つの行について補足が必要です。標準的なコンテナは、被害範囲を「マシン全体」から「このプロジェクトフォルダ」に絞りますが、ホストカーネルを共有しているため、信頼できないコードに対するセキュリティ境界として設計されたものではありません。これは分離の利便性であり、ジェイルではないのです。最強のレイヤーであるカーネルレベルの分離でも、認証情報の窃取やデータの外部送信は防げません。Edera自身もこれを認めており、ハードウェア分離は認証情報の悪用やネットワーク経由の外部送信をカバーしない。これらはエージェントごとの認証情報とネットワークポリシーでスコープする必要があると述べています。選択したレイヤーに関わらず、シークレットをサンドボックスの外に置き、エグレスアローリストを設置してください。

実際に必要なレイヤーはどれか？

リスクに応じてレイヤーを選択してください。日常的な編集には組み込みサンドボックスまたはautoモード、定期的な無人実行には非rootのdevcontainer、完全無人または信頼できないコードの実行にはカーネルを持つマイクロVM、共有CIまたはマルチテナントインフラにのみpodごとのカーネル分離を使用します。唯一の正解となるツールはありません。適切な答えは意思決定ルールです。リファクタリングを監視している開発者と、信頼できないPRを実行するCIジョブでは、さらされるリスクが異なるからです。

このルールは編集上の統合であり、ベンダーの主張ではありませんが、各レイヤーの機能は以下のソースに基づいています。ポイントは、過剰または過小な分離を避けることです。タイポを修正するためにマイクロVMを起動する必要はありませんし、簡単だからといって信頼できないPRをrootコンテナで実行すべきではありません。

Claude Codeにはすでにこれらのレイヤーが搭載されている

最も迅速な封じ込めは、自分で構築する必要がないものです。Claude Codeには現在、いくつかの公式分離レイヤーが標準搭載されています。2025年10月20日以降、Claude CodeはBashツール用にLinux bubblewrapとmacOS SeatbeltをベースとしたOS レベルの/sandboxを搭載し、基盤となるエンジンをオープンソースのリサーチプレビュー@anthropic-ai/sandbox-runtime（GitHubリポジトリanthropic-experimental/sandbox-runtime、バイナリsrt）として公開しました。 これはまだリサーチプレビュー（2026年4月3日時点でv0.0.49）であるため、APIは変更される可能性があります。 リポジトリのREADMEはその境界を示しています。サンドボックス化されたsrt "cat ~/.ssh/id_rsa"は、秘密鍵を表示する代わりにブロックされます。

# オープンソースのsandbox-runtimeデモ（リサーチプレビュー、v0.0.49 — APIは変更される可能性あり）
srt "cat ~/.ssh/id_rsa"   # -> denied: read outside the allowed filesystem

同じ2025年10月のリリースでは、Claude Code on the webも追加されました。これはセッションを分離されたクラウドサンドボックスで実行し、重要なことに、git認証情報と署名キーはエージェントと同じサンドボックス内に置かれません。

2026年の真に新しいレイヤーはautoモードで、2026年3月24日にリリースされました。Anthropicは、ユーザーが承認プロンプトの約93%をいずれにせよ承認することを発見し、autoモードはモデル分類器を使用してそれらを自動的に処理し、3回連続または合計20回の拒否後に人間にエスカレーションします。これは侵害されたまたは過度に積極的なエージェントに対するバックストップです。このモードは--dangerously-skip-permissionsを中断なしに置き換えることを明示的に意図しており、多くの日常的な作業において完全バイパスを使用する理由がなくなることを意味します。これは完全無人実行のためのサンドボックスを置き換えるものではありませんが、デフォルトを変更します。YOLOの使用頻度を減らし、使用する際にはより強固な分離を行うという方向性です。

ネットワークと認証情報のロックダウン

ファイルシステムを封じ込めながらエグレスを封じ込めないと、最悪の外部送信経路が開いたままになります。そのため、ネットワークレイヤーはオプションではありません。クリーンなプリミティブは、ドメインアローリストを持つホスト側のエグレスプロキシです。これにより、不正なエージェントが外部に通信したり、読み取ったものをアップロードしたりできなくなります。Docker Sandboxes（sbx）には、メンタルモデルとしてコピーできる3つのプリセットが用意されています。Open（すべてのトラフィックを許可、CLI: allow-all）、Balanced（デフォルト拒否で一般的な開発サイトを許可、CLI: balanced）、Locked Down（明示的に許可されない限りすべてをブロック、CLI: deny-all）です。 Balancedが適切なデフォルトです。Openは便利ですが、無人実行の場合は目的を損なうことになります。

認証情報は別途処理する必要があります。最も簡単な漏洩方法はマウントすることだからです。~/.ssh、~/.aws、または.envをエージェントの環境にマウントしないでください。シークレットがサンドボックス内になければ、エージェントはそれを読み取れません。エージェントがモデルAPIやサービスへの認証を本当に必要とする場合は、エージェントに直接渡すのではなく、プロキシで認証情報を注入してください。Dockerのsbxはまさにこれを行います。ホスト側のフォワードプロキシがAIサービスの認証ヘッダーを注入するため、生の認証情報の値はVM内に保存されません。これは分離ドキュメントに記載されています。このMITMスタイルの認証ヘッダー注入パターンは、採用するサンドボックスで探すべきパターンです。

gitの安全性を保つ

gitはマウントされた.gitディレクトリがエージェントによって完全に書き込み可能であるため、人々が過小評価しがちな障害モードです。対策は、ブランチまたはworktreeモードで実行し、エージェントがメインラインではなく使い捨てのブランチにコミットするようにすることです。Andrew Lockのsbxのウォークスルーがこのパターンを示しています。sbx run claude --branch my-feature/autoはエージェントを.sbx/配下のgit worktreeに配置し、これをグローバルgitignoreに追加します。

正直な注意点として、ブランチモードは不正なコミットがmainに入る可能性を減らしますが、gitを完全に封じ込めるわけではありません。Lockが指摘するように、エージェントは基本的にgitディレクトリへのアクセス権を持つため、リポジトリを破壊する可能性があります。そのため、唯一の本当のバックストップは、再クローンできるリモートバックアップです。git cloneでリポジトリを復元できない場合、それはバックアップされていないということです。

コピー可能な最小安全構成

ほとんどのローカル作業では、非rootのdevcontainerが適切な最低限の選択肢です。エージェントをプロジェクトに限定し、新しい開発者向けのワンコマンドオンボーディングとしても機能し、バイパスモードがrootとして実行されないというフラグ自体の要件を満たします。最小限の.devcontainer/devcontainer.jsonは次のようになります。

{
  "name": "agent-sandbox",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "remoteUser": "node",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"
}

重要な行は"remoteUser": "node"です。非rootユーザーを指定しています。--dangerously-skip-permissionsはrootまたはsudoでの起動を拒否するためです。プロジェクトディレクトリのみをマウントし、ホームディレクトリや認証情報パスはマウントしないでください。コンテナ内にエージェントをインストールし、エグレスアローリストを通じてモデルAPIに接続し、実行させてください。

完全無人実行、または信頼できないPRや任意の生成スクリプトを実行する場合は、独自カーネルを持つマイクロVMにステップアップしてください。

# Docker Sandboxes: エージェントごとのマイクロVM、独自カーネルとDockerデーモンを持つ
sbx run claude        # 分離されたマイクロVMを起動し、バイパスモードで起動する

sbx CLIは商用利用を含めて無料で使用できます。組織のガバナンス機能のみが有料サブスクリプションを必要とします。現在、macOS、Windows、Linuxで動作し、Claude Code、Codex、Copilot、Gemini、Droid、Kiro、OpenCodeなどをサポートしています。 LinuxではKVMハードウェア仮想化を有効にし、ユーザーをkvmグループに追加する必要があります（スタートガイドを参照）。

トレードオフは現実のものであり、明示する価値があります。

• マイクロVMは単純なプロジェクトでもパフォーマンスオーバーヘッドが発生します。
• ホストSSHエージェント経由のコミット署名はサンドボックスにクリーンにフォワードされないため、一般的な回避策は内部で署名なしでコミットし、ホスト上でrebaseして署名することです。
• デフォルト拒否のネットワークポリシーは、作業の妨げにならなくなるまでキュレーションが必要です。

ラップトップを超えて：共有インフラとCIインフラ

エージェントが他のテナントやCIジョブと共有するインフラで実行される場合、ラップトップ向けのレイヤーでは不十分です。共有ホストカーネルは、1つのジョブのカーネルエクスプロイトがノード上のすべてのワークロードに到達できることを意味するためです。このレベルでの解決策はpodごとのカーネル分離です。Edera、Kata Containers、gVisorなどのランタイムを通じて、各エージェントにハードウェアサンドボックス内の独自のLinuxカーネルを提供します。Ederaは各ワークロードを独自のカーネルで実行しながら、ネイティブパフォーマンスの5%以内を維持していると報告しており、ベンチマークはarXiv:2501.04580で公開されています。これらはベンダーが公開した数値であり、Ederaへのアクセスは公開ダウンロードではなくチームを通じて行われます。このレベルは単一の開発者のラップトップには過剰です。設計された用途、つまりあるテナントの侵害が全員の問題にならないようにする必要があるマルチテナントまたはCIインフラのために予約してください。

リスクを実際にカバーする最低限のレイヤーを選択し、エージェントが実行されるボックスからシークレットを排除し、ネットワークの前にアローリストを設置してください。次にエージェントがもっともらしいが誤った操作を行ったとき、マシンを再構築するのではなく、コンテナを削除するだけで済みます。

よくある質問

Claude Codeのautoモードとバイパスパーミッションモードの違いは何ですか？

バイパスパーミッションモード（--dangerously-skip-permissions）は承認プロンプトとほとんどの安全チェックを完全に無効にし、判断なしにすべてのコマンドを実行します。2026年3月にリリースされたautoモードは、モデル分類器を使用して、ユーザーが通常承認するルーティンなプロンプト（約93%）のみを自動的に承認しながら、リスクの高いアクションは人間にエスカレーションし、3回連続または合計20回の拒否後にエージェントを停止します。autoモードは、常に中断を再導入することなく、日常的な作業での完全バイパスを置き換えるように設計されています。

DockerコンテナでコーディングエージェントをYOLOモードで安全に実行できますか？

標準的なDockerコンテナは被害範囲をマシン全体から1つのプロジェクトフォルダに絞りますが、ホストカーネルを共有しており、信頼できないコードを封じ込めるために設計されたものではないため、完全なセキュリティ境界ではありません。自分のコードの定期的な無人実行には非rootコンテナが合理的ですが、信頼できないまたは生成されたコードを実行する場合は、独自カーネルを持つマイクロVMが必要です。また、バイパスモードはrootまたはsudoでの起動を拒否するため、コンテナには非rootユーザーが必要です。

サンドボックスの代わりにより厳格なアローリストを作成できないのはなぜですか？

コーディングエージェントに対する最小権限のアローリストは、エージェントの有効なアクション空間が無制限であるため機能しません。1つの正当なタスクが、パッケージのインストール、任意のパスへの書き込み、数秒前に生成したコードの実行を行う場合があります。そのため、被害をブロックするのに十分な厳格なルールは、通常の作業もブロックしてしまいます。破壊的に見えるすべてのコマンドは、エージェントが通常の操作で行うことでもあります。信頼できるアプローチは封じ込めです。事前にすべての安全なアクションを列挙しようとするのではなく、リスクに合った使い捨て環境にエージェントを配置することです。

エージェントのファイルシステムをサンドボックス化すれば、認証情報やSSHキーも保護されますか？

いいえ。ファイルシステム分離とネットワーク分離は別々の軸であり、両方が成立する必要があります。ネットワーク制限がなければ、侵害されたエージェントが読み取れるSSHキーを外部に送信でき、ファイルシステム制限がなければ、エージェントがネットワークに到達するために脱出できます。カーネルレベルの分離でも、単独では認証情報の窃取やデータの外部送信を防ぐことはできません。SSHやAWSのディレクトリなどのパスをマウントしないことで、シークレットをサンドボックスから完全に排除し、必要に応じてエグレスプロキシで認証情報を注入し、ドメインアローリストでエージェントのネットワークアクセスを制限してください。