2026-09-19 発行（読了 6 分）
実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り
エージェントがファイル操作やコマンド実行を任される場面が増えるほど、行為ごとに確認を求めるダイアログは形骸化する。ユーザーは10回目の確認では中身を読まずに許可を押すようになり、承認は安全装置ではなく儀式になる。この『承認疲れ』への対処として、2026年に入り複数のベンダーが同じ結論にたどり着いた——確認の頻度を運用で調整するのではなく、ファイルシステムとネットワークの到達範囲を実行前に構造的に固定し、その範囲内では確認を求めない設計への転換だ。ただし境界が及ぶ範囲はツールごとに異なり、抜け穴も残る。
エージェントに任せる操作が増えるほど、行為のたびに『実行していいですか』と確認を求めるUIは機能しなくなる。最初の数回は内容を読んで判断できても、10回、20回と続くうちに承認は反射的なクリックに変わり、本当に危険な操作が紛れ込んでも気づけなくなる。これは個々のプロンプト設計の問題ではなく、確認頻度をサンドボックスの緩さで決めている限り避けられない構造的な限界だ。
OpenAI CodexとAnthropicのClaude Codeは、この2つを分離する設計にそろえた。Codexはread-only/workspace-write/danger-full-accessのサンドボックス段階と、untrusted/on-request/neverの承認ポリシーを独立した軸として組み合わせる。Claude Codeもサンドボックス自体が課すファイルシステム・ネットワーク制限を2つのモードで共通にした上で、自動承認するか確認を挟むかだけを切り替える。境界の強さと確認の頻度を別々のノブにしたことで、境界内の行為はまとめて自動承認しても安全性は落ちない。
ファイルシステムの制限だけでなく、到達可能なネットワーク範囲を実行前に宣言しておく動きも標準化しつつある。エージェントが外部と通信できる範囲を都度の確認任せにせず、設定ファイルや組織ポリシーとして固定しておけば、確認ダイアログを増やさなくても攻撃対象を絞り込める。
Cursorはサンドボックスのネットワークアクセスをsandbox.jsonで3段階（許可リストのみ/許可リスト+既定値/全許可）に分け、169.254.169.254のようなクラウドメタデータエンドポイントやRFC1918プライベートアドレスをデフォルトで遮断してSSRFを防ぐ。GitHub Copilot coding agentも同様に、組織管理者がfirewallの有効/無効/リポジトリ委任を一元設定でき、OSパッケージリポジトリやコンテナレジストリなどの推奨許可リストをリポジトリ横断で強制できる。個別の確認ではなく境界そのものを組織のポリシーとして先に決める点で、両社は同じ方向を向いている。
こうしたサンドボックスの多くは、エージェントのBash・ターミナルツールとその子プロセスだけを対象にしている。だが実際のエージェントはMCP（Model Context Protocol）サーバー経由で外部サービスに接続する場面が増えており、この経路はBashサンドボックスの外側にある。ファイルシステムやネットワークの境界をどれだけ厳しく固定しても、MCP接続自体が別経路で外部と通信していれば境界は素通りされる。
Claude Codeの公式ドキュメントも、サンドボックスが保護するのはBash・PowerShell・Monitorとその子プロセスに限られることを明記しており、MCPサーバー通信はスコープ外だと認めている。この抜け穴に対しMicrosoftは、エージェント側のサンドボックスを強化するのではなく、ネットワークのエッジ側でMCPトラフィックを検査・許可判定する専用ファイアウォールを別レイヤーとして投入した。サンドボックス設計が『ツールごとの境界』の集合である以上、抜けているツールをどう塞ぐかは各社まだ足並みが揃っていない。