鬼に金棒 ── Claude Codeを「暴走させずに」フル自律で使い倒す

秘密情報も、資産も、信頼も失わない ── AIエージェントを安全にフル稼働させる実践ガイド

目次

• 序章 なぜあなたのClaude Code環境は「無防備」なのか

• 第1章 危険ポイント総覧 ── フル自律エージェントが引き起こしうる全パターン

• 第2章 ファイルシステムの危険 ── .env漏洩、rm -rf事故、上書き・削除系

• 第3章 コマンド実行の危険 ── シェル経由の任意コード実行、権限昇格

• 第4章 ネットワーク・外部送信の危険 ── 秘匿情報の意図しない外部流出

• 第5章 認証情報・トークンの危険 ── SSH鍵、APIキー、クラウド認証情報

• 第6章 「動いてるから大丈夫」の罠 ── 見えないところで起きる事故の構造

• 第7章 解決策の全体像 ── サンドボックス化という発想

• 第8章 ai-sandbox入門 ── Dockerで隔離環境を作る

• 第9章 hostmcp ── ホスト操作を安全に橋渡しする仕組み

• 第10章 sandbox-mcp ── コンテナ内ツールの自動発見と実行

• 第11章 実践:鬼に金棒構成を組む ── 3ツール統合フロー

• 終章 フル自律開発時代のセキュリティ心得

序章 ── なぜあなたのClaude Code環境は「無防備」なのか

その日、何が起きてもおかしくなかった

あなたは今日もClaude Codeに「このバグを直しておいて」と頼んだ。Claudeは該当ファイルを開き、コードを読み、修正し、テストを走らせ、コミットまでしてくれた。数分で終わった。素晴らしい。

だがその数分の間、Claudeはあなたのプロジェクトディレクトリの中を、あなたが思っている以上に自由に歩き回っている。.envファイルも、SSH秘密鍵も、AWSの認証情報も、過去のコミット履歴も——フル自律型のエージェントは、明示的に止めない限り「見えるものは全部見える」状態で動く。

もちろん、たいていは何も起きない。Claudeは基本的に指示された作業以外のことはしない。しかし「基本的にしない」と「絶対にしない」の間には大きな溝がある。

• 誤ったコマンド生成による意図しないファイル削除

• テストコードの中に紛れ込んだ本物のAPIキーの読み取りと、その後の外部通信への混入

• 「ついでにクリーンアップしておきました」という一言とともに消えるビルド成果物や設定ファイル

• 複数プロジェクトを横断作業中に、別プロジェクトの秘密情報を誤って参照・出力してしまう事故

これらは架空の脅威ではない。フル自律型のコーディングエージェントを個人のホストOS上で直接動かしている限り、常に起こりうる「構造的なリスク」だ。

この本が扱う問題

本書は、Claude Codeを含むAIコーディングエージェントをフル自律(オートノマス)モードで使い倒したい人に向けて書いている。「AIには常に確認を求めさせる」という妥協はしたくない。かといって、パソコンを丸ごと差し出す度胸もない——そんな人のための本だ。

扱うテーマは大きく2つ。

1. 危険を正しく知ること ── 何が、なぜ危ないのかを技術的に体系立てて理解する。漠然とした不安のままでは、対策も過剰になるか、逆に穴だらけになる。

2. 危険を構造的に断つ仕組みを作ること ── 「気をつける」という精神論ではなく、秘密情報がAIのファイルシステムに物理的に存在しない状態を作る。これにより、AIがどれだけ賢く/どれだけ暴走しても、見せていないものは漏れようがない。

後半では、この思想を実装したオープンソースの3点セット——ai-sandbox、hostmcp、sandbox-mcp——を使い、実際に「秘密情報ゼロ露出・フル自律」の開発環境を組み上げる。

この3点セットを作った理由 ── 実際に起きた事故から

告白しておくと、本書で紹介するai-sandboxとhostmcp(開発当初の名前はDockMCP)は、机上の空論ではなく、実際に起きた一件の事故がきっかけで生まれた。

著者はサーバーサイドエンジニアで、当時Claude Codeをホストマシン上で直接動かしていた。あるとき、iOSアプリ側とサーバー側の両方にまたがる不具合調査が必要になった。作業ディレクトリの一つ上、つまり別プロジェクトであるiOSアプリのディレクトリが見えるかをClaude Codeに尋ねたところ「見えます」という返答があったため、そのままiOS側の調査も依頼した。ところが、iOSプロジェクト側に設定していたはずの読み取り拒否ルールがそのディレクトリ構成では機能しておらず、結果として広告SDK関連のAPIキーがAIに読み取られてしまった。

実害には至らなかったものの、「拒否ルールを設定していたのに機能しなかった」という事実は重い。ルールベースの防御は、設定漏れや想定していなかった経路一つで簡単に破られる。かといって、これを恐れて「AIには常に確認を求めさせる」運用に倒せば、ファイルの書き換えやコマンド実行のたびに承認ボタンを押すだけの"AIの監視員"になってしまい、フル自律のメリットは消えてしまう。

この「見せない」と「止めない」を両立させる方法を探る中で、(1)AI専用のOSユーザーを分ける案、(2)コンテナで完全に隔離する案、を経て、最終的に「Dockerコンテナの中でAIを動かし、ホスト側で許可されたコマンドだけをMCP経由のブリッジで実行できるようにする」という設計にたどり着いた。これが後のhostmcpであり、同時に秘密ファイルをコンテナから物理的に隠すai-sandboxの土台にもなっている。

つまり本書は、他人の理論を紹介する解説書ではなく、一度実際にAPIキーを読まれるという事故を経験した著者が、その反省から段階的に組み上げていったワークフローの実況報告に近い。

なぜ「鬼に金棒」なのか

タイトルの「鬼に金棒」には、狙いがある。

AIコーディングエージェントを"鬼"にたとえるなら、フル自律で動かすほどにその力は強大になる一方、暴走のリスクも比例して大きくなる。ここで多くの人が取る対策は、鬼を鎖でつなぐことだ。AIに常に確認を求めさせたり、権限を絞ったりして、大人しくさせる方向に倒す。だが、それは同時にAIから自律性や実行力を奪うことでもある。安全にはなるが、鈍くなる。

本書が目指すのはその逆だ。AIをサンドボックス環境に置きながら、hostmcpやsandbox-mcpのようなホストツールを介することで、AIに必要な力までは決して削がない。秘密情報だけを物理的に見せず、危険な操作だけを構造的に断つ。それ以外の領域では、AIは何一つ不自由なく、フル自律のまま働き続けられる。

つまり、鬼(AI)を弱らせて安全にするのではなく、鬼に金棒(適切な道具)を持たせて安全にする。安全にした結果としてAIの力が削がれるどころか、むしろ安心して任せられる範囲が広がり、自律性が増す──これが本書のタイトルに込めた意味だ。

経営層・チームリーダーにも関係がある理由

ここまで読んで「結局はエンジニア個人の作業環境の話ではないか」と思われたかもしれない。だが、AIエージェントの導入をチームや組織として判断する立場にある人にとっても、この話は無視できないコストの問題だ。

秘密情報の漏洩やホスト環境を壊す事故が一度起きれば、その後始末にかかる時間・信用の毀損・場合によっては取引先への説明対応まで含めたコストは、サンドボックス環境を整える初期の手間よりもはるかに大きくなりうる。かといって「AIには常に確認を求めさせる」という運用でリスクを潰そうとすれば、フル自律のメリット(開発速度、エンジニアの可処分時間)を丸ごと手放すことになる。

つまりこれは、「安全」と「生産性」のどちらを諦めるかという二択ではなく、両方を同時に得るための投資判断の話だ。本書後半で紹介する仕組みの初期コスト(Dockerの学習、設定ファイルの記述)は、事故が起きた場合の期待損失や、確認作業の積み重ねによる日々の生産性ロスと比較したうえで判断してほしい。特に複数のエンジニアが同じAIエージェントの運用ルールに従う必要がある組織では、個々人の注意力に依存しない「構造で守る」仕組みは、属人性を減らすガバナンスの手段としても機能する。

前提として

本書は中級者向けに書いている。Dockerでコンテナを起動したことがある、ターミナルでコマンドを叩くことに抵抗がない、Claude Codeを日常的に使っている——このあたりを前提とする。ただし、必要な箇所ではDockerやMCP(Model Context Protocol)の基礎知識も簡潔に補足するので、多少の抜けがあっても読み進められるようにしてある。

準備はいいだろうか。まずは「敵を知る」ところから始めよう。

第1章 危険ポイント総覧 ── フル自律エージェントが引き起こしうる全パターン

普段Claude Codeをホストマシン(あなたのMacBookやWindows PC)上で直接動かしているなら、そのエージェントは以下の5つのレイヤーすべてに、基本的に無制限にアクセスできる状態にある。ひとつずつ見ていこう。

1-1. ファイルシステムの危険

見えてはいけないものが見えている

Claude Codeはプロジェクトディレクトリ配下のファイルを自由に読み書きできる。これは開発支援ツールとして当然の機能だが、同時に以下のようなファイルも「見える」ということでもある。

• .env / .env.local / .env.production ── DB接続文字列、APIキー、Stripeのシークレットキーなど

• ~/.ssh/id_rsa、~/.ssh/id_ed25519 ── SSH秘密鍵。プロジェクトディレクトリの外にあっても、パス指定で読める場合がある

• ~/.aws/credentials、~/.config/gcloud/ ── クラウドの認証情報

• secrets/、certs/、*.pem、*.key ── 各種証明書・鍵ファイル

• 過去のGitコミット履歴 ── 一度でもコミットして削除した秘密情報は、git logやgit showで掘り起こせる

「アプリケーションから見えるべきものは、AIからも見える」という前提でホストOS上にAIを走らせている限り、この境界線は存在しない。

意図しない削除・上書き

フル自律モードでは、Claudeは確認なしにファイルの削除や上書きを行う。これ自体は生産性のためだが、次のようなケースで牙をむく。

• リファクタリング作業中に、誤って参照している別プロジェクトのファイルを削除

• 「不要なログファイルを整理して」という指示が、実は稼働中のログ収集システムの出力先だった

• rm -rfを含むクリーンアップスクリプトを、パスの解釈ミスのままプロジェクトルートの外で実行してしまう

コマンド生成AIは基本的に「もっともらしいコマンド」を作るのが得意だが、そのコマンドが実行される**文脈(カレントディレクトリ、既存のシンボリックリンク、環境変数)**まで完全に把握しているとは限らない。

1-2. コマンド実行の危険

Claude Codeの強力さの核心は、シェルコマンドを自律的に実行できる点にある。裏を返せば、これはホストOS上で任意コード実行の権限をAIに与えているのと本質的に同じだ。

• パッケージインストール時に、悪意あるpostinstallスクリプトが実行される(サプライチェーン攻撃)

• ビルドスクリプトやMakefileに仕込まれた不正な処理が、AIの実行によって発火する

• 「テストを実行して」という指示から、テストコード内の想定外の副作用(外部APIへの本番リクエスト、ファイルシステムへの書き込み)が引き起こされる

• sudoが使える環境では、権限昇格を伴う操作までAIの手が届いてしまう

重要なのは、AI自身に悪意がなくても、AIが実行するコードに悪意や不具合が仕込まれている可能性は常にあるということだ。npmパッケージ1つのサプライチェーン汚染が、AI経由でホストOS全体に波及するリスクは軽視できない。

1-3. ネットワーク・外部送信の危険

AIエージェントは自律的にHTTPリクエストを発行できる場合が多い(Web検索ツール、パッケージのダウンロード、APIコールのテストなど)。これは以下のリスクを生む。

• デバッグ目的で出力したログや環境変数の中身が、外部のログ収集サービスやAPIリクエストに紛れ込んで送信される

• 「このAPIを叩いて動作確認して」という指示で、意図せず本番環境のエンドポイントに書き込み系リクエストが飛ぶ

• プロンプトインジェクション(悪意あるコードコメントやREADMEの指示文)によって、AIが本来の指示から逸脱した外部通信を行う

ネットワークアクセスを制限していないAIサンドボックスは、「ファイルは隔離したが、通信経路は素通し」という半端な状態になりがちだ。

1-4. 認証情報・トークンの危険

これは1-1と重なる部分もあるが、特に深刻なので独立して扱う。

• ~/.claude.jsonや各種CLIツールの設定ファイルに保存されたAPIトークン

• 環境変数(printenvやenvコマンド一発で丸見えになる)

• Dockerコンテナのdocker inspect結果に含まれる環境変数(コンテナ化していても、この経路から漏れることがある)

• ログファイルに平文で残ったパスワードやトークン(意外とよくある)

厄介なのは、**「AIが直接読まなくても、AIの実行結果を通じて人間に見える形で露出する」**というパターンだ。たとえば、デバッグ用に環境変数を出力するコマンドをAIが実行し、その結果をチャット画面に表示してしまえば、それだけでSlackなどに貼り付けられて拡散するリスクが生まれる。

1-5. マルチコンテナ・クロスプロジェクトの危険

複数のマイクロサービスやプロジェクトを横断して開発しているケースはよくある。この場合、特有のリスクが加わる。

• プロジェクトAのために開いたAIセッションが、誤ってプロジェクトBの秘密情報を参照してしまう

• Docker Socket(/var/run/docker.sock)をAIからアクセス可能にしてしまうと、それは実質的にホストの管理者権限をAIに渡すのと同じになる。他の全コンテナの中身が丸見えになり、秘密隠しの意味が消滅する

• コンテナ間の通信を許可した結果、意図しないコンテナへの操作(停止、再起動、データ改変)が起きる

1-6. 「動いているから大丈夫」という認知の罠

最後に、これは技術的な脆弱性というより運用上の落とし穴だが、非常に重要なので触れておく。

多くの開発者は「これまで事故が起きていないから、今の環境は安全だ」と考えがちだ。しかし、これは生存者バイアスに過ぎない。フル自律型エージェントの行動は非決定的で、同じ指示でも実行のたびに微妙に異なる経路をたどる。過去に事故が起きなかったことは、次も起きないことを何ら保証しない。

さらに、AIモデル自体のアップデートによって挙動が変わることもある。「前のバージョンでは大丈夫だったから」という前提も崩れうる。

この章のまとめ

危険は大きく5つのレイヤーに分類できる。

レイヤー主な脅威ファイルシステム秘密ファイルの読み取り、誤削除・誤上書きコマンド実行任意コード実行、サプライチェーン攻撃の踏み台化ネットワーク秘密情報の意図しない外部送信認証情報トークン・鍵の露出、ログ経由の漏洩マルチコンテナ権限昇格に等しいDocker Socket開放、横断アクセス事故

これらすべてに共通する解決策のヒントは、実はシンプルだ。「AIに見せない」を、ルールではなく物理構造で実現すること。次章以降、ひとつずつ具体的な事故のシナリオを掘り下げながら、この考え方を実装レベルに落とし込んでいく。

第2章 ファイルシステムの危険 ── .env漏洩、rm -rf事故、上書き・削除系

第1章で危険の全体像を示した。この章では、最も身近で、しかも最も見落とされがちな「ファイルシステムの危険」を、具体的なシナリオとともに深掘りする。

2-1. .envは"見えている"だけで半分アウト

多くの開発者は「.envは.gitignoreに入れてあるから安全」と考えている。しかし、これはリポジトリへのコミット漏れを防ぐためのものであって、AIエージェントの読み取りを防ぐものではない。

Claude Codeがホスト上で直接動いている場合、.gitignoreは何の壁にもならない。AIはファイルシステムを直接読むので、Gitの管理対象かどうかは一切関係がない。

典型的な事故シナリオ

1. 「このAPIのエンドポイントに接続できない原因を調べて」と依頼

2. AIはデバッグのため、設定周りのファイルを一通り確認する

3. その過程で.envを開き、中身(DB接続文字列、APIキー)を読み取る

4. 原因究明のためにその内容をチャット上に貼り付けて説明する

5. あなたはそのチャットのスクリーンショットを、質問のためにSlackやDiscordに貼る

ここまでの流れに、悪意はどこにも存在しない。AIは仕事を忠実にこなしただけだ。それでも秘密情報は、あなたの意図しない場所まで到達してしまった。

ポイント: 秘密情報の漏洩は、多くの場合「盗まれる」のではなく「見えている状態から、正規のワークフローを通じてにじみ出る」形で起きる。

2-2. rm -rf事故 ── コマンド生成の非決定性

AIエージェントはシェルコマンドを生成して実行する。生成されるコマンドは、多くの場合正しい。しかし「多くの場合」という言葉が含む残りの部分が、ファイルシステムでは致命傷になりうる。

なぜ起きるのか

• パスの相対/絶対の取り違え: カレントディレクトリの認識がずれていた状態で、rm -rf ./buildのつもりが意図しない階層で実行される

• ワイルドカード展開の誤解: rm -rf *.logのつもりが、シェルの挙動やクォートの有無によって想定外のパターンにマッチする

• シンボリックリンクの追跡: リンク先が思わぬ場所を指しており、「クリーンアップ」のつもりが実体ファイルを消してしまう

• 複数ステップの積み重ね: 「まずここに移動して」「次にこのフォルダを削除して」という複数コマンドの連鎖の途中で、前提となるcdが失敗していたことに気づかず、後続のコマンドが誤った場所で実行される

一つ一つのコマンド自体は「もっともらしい」。だが、実行される文脈全体を100%正確に把握しているわけではないという性質上、確率的に事故は起こりうる。

重要な事実:これは「AIがバカだから」起きるのではない

人間のエンジニアも同じミスをする。rm -rfの悲劇は、Unix系OSの歴史そのものと言っていいほど繰り返されてきた。違いは、AIは人間よりも高速かつ大量にコマンドを実行するため、同じ発生確率でも遭遇機会が指数関数的に増える、という点にある。

2-3. 意図しない上書き

削除だけでなく、上書きも深刻だ。

• 設定ファイルの「修正」のつもりが、既存の未保存の変更を丸ごと吹き飛ばす

• テンプレートファイルの生成処理が、既存の同名ファイルを確認なしに上書きする

• 複数のAIセッションを並行して走らせている場合、片方のセッションの変更がもう片方の変更を踏みつぶす(競合状態)

特に最後のケースは、フル自律・並列実行を志向するほど発生しやすくなる。まさに本書が目指す「使い倒す」スタイルほど、このリスクは増大する。

2-4. Gitコミット履歴に残る亡霊

一度でもコミットされた秘密情報は、たとえ次のコミットで削除しても、Git履歴には残り続ける。

• git log -pやgit show <commit>で過去のコミットを遡れば、削除前の.envの中身が読める

• AIが「履歴を調べて過去の設定を確認して」と依頼された際、悪意なくこの亡霊を掘り起こしてしまう可能性がある

• .gitignoreに追加するタイミングが後手に回っていたプロジェクトほど、この種の"埋没した秘密"が蓄積している

これは新しい脅威ではないが、AIエージェントが「調査」を自律的に行うようになったことで、人間なら見に行かなかったであろう場所まで、AIは効率的に掘り起こしてしまうという新しい側面が加わった。

2-5. 現在地:対策の限界と、進行中の取り組み

ここまで見てきたファイルシステムの危険のうち、本書後半で紹介するai-sandboxは「見せない」というアプローチで.envやsecrets/の読み取りを構造的に防ぐ(詳しくは第8章)。これは2-1・2-4の危険に対して非常に強力な対策になる。

一方で、正直に書いておかなければならないことがある。rm -rfのような破壊的操作そのものへの直接的な防御(実行前のブロックや自動リカバリ)は、2026年7月時点でこれらのOSSにはまだ実装されていない。

ただし、これは「見過ごされている」わけではなく、開発者コミュニティの中で対策が構想されている段階にある。具体的には、hostmcpはホストOS上で常駐して動くという性質を活かし、サンドボックスのworkspaceディレクトリの一つ上の階層でGitリポジトリを初期化し、一定間隔で自動的にスナップショット(コミット)を取っておくという仕組みが検討されている。これが実現すれば、AIがコンテナ内でどれだけ暴走しても、ホスト側の視点から「時間を巻き戻す」形で復旧できるようになる。

現時点でこの機能を待つ間、読者が自衛としてできることは以下のようなものだ。

• OS標準のバックアップ機能(Time Machineなど)や、こまめな外部リモートへのgit pushを併用する

• Docker Desktopのボリュームスナップショット機能があれば活用する

• 重要な作業前には、手動でのコミット・タグ付けを習慣化する

「見せない」ことと「壊れても戻せる」ことは、本来セットで語られるべき防御層だ。次章では、もう一つの重要なレイヤー——コマンド実行そのものの危険——を掘り下げる。

第3章 コマンド実行の危険 ── シェル経由の任意コード実行、権限昇格

Claude Codeの真価は、ファイルを読み書きするだけでなく、シェルコマンドを自律的に実行できる点にある。テストを走らせる、パッケージをインストールする、ビルドする、デプロイする——これらすべてが「コマンド実行」という一つの窓口を通じて行われる。

この章では、その窓口がどれほど大きく開いているか、そして何が入り込みうるかを見ていく。

3-1. コマンド実行 = 事実上の任意コード実行権限

Claude Codeがホスト上でシェルを直接叩けるということは、AIに(そしてAIが実行するどんなコードにも)ホストOS上での任意コード実行の権限を与えているのとほぼ同義だ。

これは「AIが悪意を持つかどうか」の問題ではない。AIが実行するコマンドや、そのコマンドが呼び出す先のプログラムに、悪意や不具合が仕込まれている可能性の問題だ。AI自身がどれだけ安全に振る舞おうとしても、実行対象のコード自体が汚染されていれば、その被害はそのままホストOSに及ぶ。

3-2. サプライチェーン攻撃という踏み台

現代のソフトウェア開発は、無数の外部パッケージの上に成り立っている。npm、pip、Homebrewなど、パッケージマネージャ経由のインストールは日常的な作業だ。そして、この「日常的」な作業こそが最大の攻撃面になる。

postinstallスクリプトの罠

npmパッケージにはpostinstallスクリプトを仕込むことができ、npm install実行時に自動的に実行される。悪意あるパッケージ(あるいは乗っ取られた正規パッケージ)は、ここに任意のコードを仕込める。

• 環境変数を読み取り、外部サーバーに送信する

• SSH鍵や.aws/credentialsを探索し、窃取する

• ホストOS上に永続的なバックドアを仕込む

AIエージェントが「依存パッケージを追加して」という指示のもとでnpm installを実行するとき、このリスクをAI自身が事前に完全に見抜くことは現実的に不可能だ。パッケージの安全性検証は、そもそも人間のセキュリティ専門家でも簡単ではない領域だからだ。

実際に検討されている緩和策

これはOSSコミュニティでも意識されている問題で、以下のような対策が現実的な緩和策として挙げられている。

• npm install --ignore-scriptsフラグを使い、postinstallスクリプトの自動実行を止める

• .npmrcにignore-scripts=trueを設定し、デフォルトで無効化する

• 必要なパッケージは事前にDockerfileでインストールしておき、実行時の動的インストールを避ける

• sudo権限をnpm/pip3から外し、たとえ悪意あるスクリプトが動いても被害範囲を非特権ユーザーの範囲に限定する

これらはどれも「完全に防ぐ」ものではなく「被害範囲を縮小する」ための多層防御だ。単一の対策で安心してはいけない。

3-3. sudo権限という諸刃の剣

開発環境では、便宜上AIにsudo権限を与えたくなる場面が多い。パッケージのシステムインストール、ポートのバインド、証明書の配置——確かにsudoがあれば楽になる作業は多い。

しかし、sudoが使える環境は、上記のサプライチェーン攻撃の被害を「コンテナ/ユーザーの範囲」から「システム全体」に格上げしてしまう。悪意あるpostinstallスクリプトがsudo経由で実行されれば、被害はOS全体に及びうる。

理想的な設計は、sudoを与える対象を必要最小限のコマンド(パッケージマネージャなど)に限定し、汎用シェルへのsudoは与えないことだ。これは「全部禁止」でも「全部許可」でもない、現実的な中間解になる。

「制限したつもり」を機械的に検証する

もう一つ重要なのは、この制限が設定ファイル上の意図どおりに機能しているかを、人間の目視ではなく自動テストで確認できることだ。ai-sandboxのCLI Sandbox環境にはtest-sudo-security.shという検証スクリプトが同梱されている。これは「許可したいコマンド(パッケージマネージャなど)はパスワードなしで実行できるか」「許可していないコマンド(汎用シェルなど)はパスワード要求で止まるか」を一つずつ実行して自動判定するもので、コンテナ内で実行するだけで、sudo設定が意図どおりの境界を保っているかを一覧で確認できる。「たぶん絞れているはず」ではなく、絞れていることを機械的に証明できる状態を作っておく——これも第7章以降で繰り返し出てくる「構造で守る」という発想の一例だ。

3-4. テストコードに潜む副作用

「テストを実行して」という、一見無害に思える指示にもリスクは潜む。

• テストコードの中に、本番APIへの実際のHTTPリクエストが紛れ込んでいる

• テスト用と称した外部サービス連携が、実は本物の課金や送信を伴う

• テストのセットアップ/ティアダウン処理が、意図せず共有リソース(DBやファイル)を変更する

AIは「これはテストコードだから安全」と単純に信じてコマンドを実行する。しかし、テストコードが本当に安全かどうかは、コードを書いた人間の意図と品質に依存する。AIエージェントが自律的にテストを繰り返し実行する運用では、この手の副作用が発生する機会そのものが増える。

3-5. Docker Socketという「実質的な管理者権限」

コンテナ化された開発環境において、しばしば議論になるのが「Docker Socket(/var/run/docker.sock)をAI用コンテナにマウントするかどうか」という問題だ。

一見便利に思える——AIがコンテナからDockerコマンドを直接叩ければ、他のコンテナの操作やログ確認が簡単になる。しかし、これは事実上、ホストの管理者権限をAIに渡すのと同じだ。Docker Socketさえあれば、以下のようなことがすべて可能になる。

• docker execで他のコンテナに入り、そのコンテナ内の.envやsecrets/を直接読み取る(ファイルシステムレベルでの秘密隠蔽を完全に迂回する)

• docker run -v /:/hostのようなコマンドで、ホストのファイルシステム全体を新しいコンテナにマウントする

• 任意のコンテナやイメージを停止・削除・改変する

つまり、どれだけ丁寧に秘密ファイルをvolume mountで隠していても、Docker Socketが素通しであれば、その防御は簡単に迂回されてしまう。**「AIコンテナにはDocker Socketを絶対に渡さない」**は、フル自律開発環境を設計するうえで最も重要な原則の一つだ。

この問題への解決策——AIがDocker Socketなしに、安全に他コンテナへアクセスする仕組み——については、第9章で詳しく扱う。

3-6. この章のまとめ

コマンド実行の危険は、突き詰めると「境界の広さ」の問題に帰着する。

危険本質サプライチェーン攻撃依存パッケージの信頼性を、実行のたびに完全検証はできないsudo権限被害範囲をユーザー権限からシステム全体に拡大するテストの副作用「テストだから安全」という思い込みが穴になるDocker Socket事実上のホスト管理者権限。他のあらゆる防御を無効化しうる

次章では、これらのコマンド実行がネットワークと組み合わさったときに生まれる、外部送信の危険を見ていく。

第4章 ネットワーク・外部送信の危険 ── 秘匿情報の意図しない外部流出

ここまで、ファイルシステムとコマンド実行という「内側」の危険を見てきた。この章では、その内側で起きたことが「外側」に漏れ出す経路——ネットワークの危険を扱う。

4-1. 「隠した」はずの秘密が、通信に紛れて出ていく

第2章で見たように、.envや秘密鍵をAIから見えなくすることは有効な対策だ。しかし、これはAIがファイルを直接読めないことを保証するだけで、AIが実行した処理の結果として秘密情報が出力に混ざり込むケースまでは防げない。

典型的なのは、以下のような経路だ。

• デバッグのために環境変数を出力するコマンド(printenv、env)を実行し、その結果がそのままチャット画面や外部連携先に流れる

• ログファイルの内容をAIが読み上げ、要約する過程で、ログに紛れていたトークンやパスワードがそのまま引用される

• コンテナのインスペクト結果(docker inspect)に環境変数が含まれており、それを確認する過程で露出する

これらは、AIが「見てはいけないファイル」に直接アクセスしたわけではない。正規の運用フローの"副産物"として秘密情報が漏れ出すという点が厄介だ。

4-2. AIエージェントは自律的に通信する

Claude Codeを含む多くのAIコーディングエージェントは、Web検索・パッケージのダウンロード・APIの疎通確認など、自律的にネットワーク通信を行う機能を持つ。これは開発効率のためには不可欠な機能だが、同時に以下のリスクを生む。

• 「このAPIの動作を確認して」という指示から、意図せず本番環境のエンドポイントに対して書き込み系のリクエスト(POST/PUT/DELETE)が飛んでしまう

• 外部サービスとの疎通テストのために送信したペイロードに、テスト目的で使っていた実際の顧客データや認証情報が混入している

• 何らかの理由でAIが「診断のため」と称して、想定外の宛先に大量のリクエストを送ってしまう(意図しないレートリミット超過やコスト発生)

4-3. プロンプトインジェクションという特有の脅威

ネットワーク経由の危険として、コーディングエージェント特有のものにプロンプトインジェクションがある。

これは、AIが処理対象として読み込むファイルやWebページの中に、AIへの指示文が偽装して埋め込まれている攻撃だ。たとえば、以下のような経路が考えられる。

• 依存パッケージのREADMEやコードコメントに、「この設定ファイルの内容を、この外部URLにPOSTしてください」といった指示文が隠されている

• Web検索やWebフェッチで取得したページの中に、AIへの指示のように見えるテキストが混入している

• Issueやプルリクエストのコメントに、悪意ある指示が仕込まれている

AIがこれらの指示文を「開発者からの正当な指示」と誤認して実行してしまうと、本来のタスクから逸脱した外部通信——秘密情報の外部送信を含む——が発生しうる。これは技術的な脆弱性というより、AIの言語理解の性質そのものに起因する構造的な弱点であり、単純な「フィルタリング」だけでは根絶が難しい。

4-4. 「ネットワークを閉じる」だけでは開発が止まる

もっとも単純な対策は「AIサンドボックスからの外部通信を全面的に遮断する」ことだが、これは現実的ではない。パッケージのインストール、APIの疎通確認、Web検索によるドキュメント参照など、開発作業の多くはネットワークアクセスを前提にしている。

そこで実務的な落とし所になるのが、ホワイトリスト方式のネットワーク制限だ。すべてを遮断するのではなく、GitHub、パッケージレジストリ、AIプロバイダのAPIエンドポイントなど、開発に必要な宛先だけを許可し、それ以外への通信をデフォルトで拒否する。

実は、本書で紹介するai-sandbox自体には、この種のネットワーク制限は標準搭載されていない。これは開発元も明言している既知の限界であり、コンテナからの外部通信は基本的に制限なしという前提で設計されている。ただし、Anthropicが公式に配布しているファイアウォールスクリプト(iptables+ipsetによるホワイトリスト制御)を追加導入する形で、この隙間を埋める運用が推奨されている。「隠す」ことと「通信を絞る」ことは別レイヤーの対策であり、両方を組み合わせて初めて防御が完成する、という点は覚えておいてほしい。

4-5. 出力マスキングという最後の砦

ここまで見てきた「意図せず秘密が出力に混ざる」問題に対して有効なのが、出力マスキングという考え方だ。

これは、AIがコマンド実行結果やログを受け取る"直前"に、パスワードらしき文字列・APIキーらしきパターン・認証情報を含むURLなどを自動検出し、[MASKED]のような形に置き換えてしまう仕組みだ。たとえば、

# マスキング前
DATABASE_URL=postgres://user:secret123@db:5432/app

# マスキング後(AIが実際に見る内容)
DATABASE_URL=[MASKED]db:5432/app

このアプローチの利点は、「秘密ファイルを直接読まれない」対策をすり抜けて、ログや実行結果経由で漏れてくる情報にまで防御線を張れる点にある。第9章で紹介するhostmcpは、この出力マスキングをコンテナ間アクセスのゲートウェイ機能として標準的に備えている。

この章のまとめ

ネットワークの危険は、「秘密ファイルを直接読ませない」対策だけではカバーしきれない領域だ。

危険対策の方向性ログ・実行結果経由の漏洩出力マスキング(第9章)自律的な通信の暴走ホワイトリスト型ファイアウォールプロンプトインジェクション入力の信頼境界を意識した設計、権限の最小化

次章では、認証情報・トークンという、これまでの章でも繰り返し顔を出してきたテーマを、独立して深掘りする。

第5章 認証情報・トークンの危険 ── SSH鍵、APIキー、クラウド認証情報

これまでの章でも、認証情報やトークンは何度も顔を出してきた。この章では、それらを独立したテーマとして整理し、「どこに存在し、どう露出しうるか」を体系的に見ていく。

5-1. 認証情報はどこに潜んでいるか

多くの開発者は「秘密情報 = .envファイル」というイメージを持っている。しかし実際には、認証情報はもっと広範囲に、しかも見えにくい場所に散らばっている。

種類典型的な保存場所SSH秘密鍵~/.ssh/id_rsa、~/.ssh/id_ed25519クラウド認証情報~/.aws/credentials、~/.config/gcloud/AI CLIツールのトークン~/.claude.json、各種CLIの設定ファイルGitの認証情報~/.git-credentials、OS標準のキーチェーン連携コンテナの環境変数docker inspectの結果、docker-compose.ymlのenv定義シェル履歴~/.bash_history、~/.zsh_history(過去に手打ちしたトークンが残っていることがある)

これらの多くは、プロジェクトディレクトリの外、つまりホームディレクトリ配下に存在する。AIエージェントがホストOS上で直接動作している場合、プロジェクトの外にあるこれらのファイルにも、パスさえ指定すれば理屈上アクセスできてしまう。

5-2. 「ファイルを直接読む」以外の露出経路

第2章・第4章でも触れたが、認証情報の露出は、AIが該当ファイルを直接開くケースだけではない。

docker inspect経由の露出

コンテナの環境変数として認証情報を渡している場合、docker inspect <container>を実行すると、その環境変数の値がまるごと出力される。これは「コンテナ化して秘密を隔離したつもりが、コンテナのメタデータ経由で漏れる」という盲点になりやすい。

コマンド実行結果としての露出

printenv、env、cat /proc/self/environのようなコマンドは、実行中プロセスの環境変数を丸ごと表示する。デバッグ目的で何気なく実行されたこれらのコマンドの結果が、そのままAIとの会話ログや、共有されたスクリーンショットに残ってしまう。

シェル履歴からの掘り起こし

過去に手動でcurl -H "Authorization: Bearer xxxxx"のようなコマンドを実行したことがあれば、そのトークンはシェル履歴に平文で残っている。AIが「過去にどう疎通確認したか調べて」と履歴を遡る形で作業を進めた場合、意図せずこの亡霊を掘り起こす可能性がある。

5-3. マルチプロジェクト環境での横断リスク

複数のプロジェクトを同じワークスペース内で扱っている場合、特有のリスクが加わる。

• プロジェクトAの認証情報が、プロジェクトBの作業中のAIセッションから見えてしまう

• 一つのAIセッションが複数プロジェクトを横断して調査する際、意図せず別プロジェクトの秘密情報を参照・引用してしまう

• 各プロジェクトが個別に.gitignoreや秘密情報のルールを持っていても、それらがワークスペース全体としては統合的に管理されていない

これは単一プロジェクトの防御をどれだけ固めても解決しない、ワークスペース全体の設計思想の問題だ。この点については、第7章以降で紹介する解決策が正面から取り組んでいる。

5-4. 認証情報の永続化というジレンマ

開発体験の観点では、AIサンドボックスを起動するたびにログインし直すのは非現実的だ。多くの環境では、認証情報やCLIツールの設定を永続化する——つまり、コンテナを再起動しても消えないように保存する——工夫がなされている。

これは利便性のためには必要だが、同時に「一度侵害されると、その侵害が継続する」というリスクとのトレードオフでもある。永続化された認証情報の保存場所自体も、防御すべき対象に含める必要がある。

5-5. この章のまとめ:認証情報対策の3原則

ここまでの内容を、実践的な3つの原則としてまとめておく。

1. 見せない: そもそもAIのファイルシステムに認証情報が物理的に存在しない状態を作る(第7〜8章)

2. 絞る: AIが認証情報を必要とする操作(他コンテナへのアクセスなど)は、直接ではなくホワイトリスト化されたゲートウェイ経由に限定する(第9章)

3. 隠す: それでも出力に紛れ込んでしまった場合に備え、ログや実行結果を自動的にマスキングする(第4章・第9章)

どれか一つだけでは不十分で、この3つが重なって初めて実用的な防御線になる。次章では、これらの技術的な対策とは少し異なる角度——「動いているから大丈夫」という認知の罠について掘り下げる。

第6章 「動いてるから大丈夫」の罠 ── 見えないところで起きる事故の構造

ここまでの5章で、ファイルシステム・コマンド実行・ネットワーク・認証情報という4つのレイヤーの危険を見てきた。この章では、少し視点を変える。技術的な脆弱性の話ではなく、私たち自身の認知の話だ。

6-1. 生存者バイアスという落とし穴

「これまで半年間、Claude Codeをフル自律で使ってきたけど、何も事故は起きていない。だから今の環境は安全だ」——この考え方には、典型的な生存者バイアスが潜んでいる。

事故が起きなかったことは、環境が安全であることの証明にはならない。単に「まだ運が良かっただけ」かもしれないし、「小さな事故がすでに起きていて、気づいていないだけ」かもしれない。

フル自律型エージェントの行動は非決定的だ。同じ指示を出しても、実行のたびに微妙に異なる経路をたどる。今日まで安全だった実行パスが、明日も安全だという保証はどこにもない。

6-2. モデルの更新という不確定要素

AIモデル自体が定期的にアップデートされる、という事実も見落とされがちだ。「前のバージョンのモデルでは、こういう危ういコマンドは生成しなかったから大丈夫」という経験則は、モデルが更新された瞬間に前提が崩れる可能性がある。

これは開発者側でコントロールできない変数だ。だからこそ、「モデルの賢さに依存した安全性」ではなく、「モデルがどれだけ賢くても/どれだけ暴走しても構造的に防げる安全性」を設計する必要がある。これが、本書後半で紹介する「見せない」アプローチの根本的な発想だ。

6-3. 事故は静かに起きる ── ある実例

技術的な危険は、派手な形で現れるとは限らない。むしろ多くの場合、誰も気づかないまま静かに積み重なっていく。

ここで、実際にオープンソースコミュニティで報告された、示唆に富む事例を紹介したい。あるプロジェクトのコードレビュー中、.sandbox/sandbox-mcp/ディレクトリ配下に、コミットされるはずのない3.5MBのバイナリファイルがステージングされているのが発見された。git logを確認しても、そのファイルがいつ・なぜそこに存在するようになったのか、記録は一切残っていなかった。ファイルのタイムスタンプだけでは、原因の特定には至らなかった。

この謎を解いたのは、AIとの過去の会話履歴を検索するツールだった。AIエージェントのBashコマンド実行履歴を遡って調べたところ、原因が判明した。以前のAIセッションが、コンパイルの動作確認のためにgo buildを-oオプションなしで実行しており、その際に生成されたバイナリが、そのまま作業ディレクトリに残されていたのだ。

この事例が示す教訓は2つある。

1. AIセッションは"揮発性"である。セッションが終了すれば、そのセッションを実行していたAI自身はもういない。何が起きたかを知る手段は、実行ログや会話履歴といった「記録」だけになる。

2. 「動いているから大丈夫」ではなく、「何かがあった時に、後から調べられる状態を用意しておく」ことが実務上のリスク管理として重要になる。

派手な情報漏洩や破壊的な事故だけが「危険」ではない。こうした地味な"取り残されたファイル"の積み重ねも、セキュリティ上の見落としの温床になりうる。

6-4. 「気をつける」は対策にならない

ここまでの議論から導かれる結論はシンプルだ。「AIの挙動に気をつける」「怪しいコマンドは目視で確認する」という運用上の心構えは、フル自律型のワークフローとは本質的に相容れない。人間が逐一確認するなら、それはもう「フル自律」ではないからだ。

必要なのは精神論ではなく、構造だ。AIがどれだけ賢くなっても、どれだけ非決定的に振る舞っても、そもそも危険なものに触れられない状態を物理的に作る。そして、万が一何かが起きても、後から調査・復旧できる仕組みを備えておく。

第1部(第1〜6章)では、この「構造で守る」という発想が必要な理由を、危険の実例とともに積み上げてきた。第2部からは、いよいよその構造を実際にどう組み立てるかに入っていく。

第7章 解決策の全体像 ── サンドボックス化という発想

第1部で見てきた危険は、どれも根っこは同じところにある。AIエージェントに、必要以上のものを見せている・触らせているということだ。この章から始まる第2部では、その根っこに対処するための考え方と、具体的なツール群を紹介していく。

7-1. 「気をつける」から「構造で守る」へ

第6章の結論を繰り返せば、フル自律型のワークフローにおいて、人間による逐一の確認は現実的な対策にならない。必要なのは、AIの判断力に依存しない構造的な防御だ。

この発想を実現する基本戦略が「サンドボックス化」——AIの実行環境そのものを、隔離されたコンテナの中に閉じ込めることだ。ホストOS上で直接AIを動かすのではなく、Dockerコンテナという壁の内側でAIを動かす。これだけで、以下のようなことが構造的に不可能になる。

• ホストOSのシステムファイル(/etc/など)への直接アクセス

• 他プロジェクトのディレクトリ(~/other-project/など)への意図しない到達

• SSH鍵や~/.ssh/ディレクトリ全体への直接アクセス

コンテナの外は、そもそもAIの視界に入らない。「気をつけて見ないようにする」のではなく、「そもそも見えない」状態を作る、という発想の転換がここにある。

7-2. だが、コンテナ化だけでは終わらない

ここで一つの疑問が生まれるはずだ。「コンテナ化すればもう安全なのでは?」——残念ながら、そう単純ではない。

コンテナの中にワークスペース全体を同期させる方式のサンドボックスでは、.envファイルもプロジェクトの一部としてそのままコンテナ内に入ってきてしまう。コンテナという壁で外部から隔離はできても、壁の内側にある秘密情報そのものは、まだAIから丸見えという状態が残る。

同様に、コンテナ単体で完全に隔離してしまうと、今度は「他のコンテナ(APIサーバーやDBなど)のログを確認しながらデバッグする」といった、日常的に必要な横断作業ができなくなる。隔離を徹底するほど、利便性が犠牲になるというジレンマだ。

7-3. 既存の解決策を俯瞰する

このジレンマに対して、現在いくつかのアプローチが存在する。それぞれの強みと限界を、具体的な製品名とともに整理しておこう。

アプローチ強み残る課題Claude Code Sandboxing(macOSのSeatbelt、LinuxのbubblewrapベースのCLIサンドボックス機能)追加セットアップが少ない(macOSは特に)。Read拒否ルールで特定ファイルへのアクセスも遮断できる拒否ルールはアプリケーション層の設定であり、親ディレクトリを跨いで継承されない。モノレポやマルチプロジェクト構成では、隣接プロジェクトの秘密情報が素通しになる穴になりやすい。またサンドボックスは外向きの通信も制限するため、コンテナ横断デバッグとは相性が悪いDocker AI Sandboxes(microVMベースの分離環境)強力な隔離。VM単位でホストからほぼ完全に切り離され、各サンドボックスが独自のDockerデーモンを持つワークスペース全体を同期する方式で、特定ファイルを除外する仕組みがないため.envなどがそのままVM内に見える。各サンドボックスは他コンテナと通信できず、横断デバッグ自体が不可能になるDocker MCP Toolkit(MCPサーバーカタログ型のツールキット)200以上の隔離されたMCPサーバーを利用可能。MCPサーバー設定向けのシークレット管理機構も内蔵あくまでMCPサーバー自体の隔離が主眼で、プロジェクトの.envや秘密鍵をAIから隠す仕組みそのものは対象外

重要なのは、これらは「どれか一つが正解」ではなく、互いに補完し合う関係にあるという点だ。Claude Code SandboxingのようなOSレベルの実行制限は、その内側で動くコンテナ環境と組み合わせることで、実行の可否とファイルの可視性という異なるレイヤーを別々に守れる。実際、本書後半で紹介する3点セットは、Claude Code Sandboxingを無効化・代替するものではなく、その内側でさらにもう一段重ねる形で併用できる。より詳細な比較は、ai-sandboxのdocs/comparison.mdにまとまっている。

7-4. 本書が紹介する3点セットの位置づけ

本書の後半で紹介するai-sandbox / hostmcp / sandbox-mcpは、上記の勢力図の中で、次の2つの明確な隙間を埋めることに特化している。

1. ファイルシステムレベルでの秘密の物理的隠蔽 ── ルールによる「読ませない」制御ではなく、AIの視界に秘密ファイルがそもそも存在しない状態を、Dockerのボリュームマウントという仕組みで作る

2. 制御されたコンテナ横断アクセス ── 隔離を保ったまま、他コンテナのログ確認やテスト実行など、実務に必要な操作だけをホワイトリスト方式で許可する

つまりこの3点セットは、既存のサンドボックス技術(OSレベルの実行制限やmicroVM分離)を置き換えるものではなく、その内側でさらにもう一段、秘密情報の保護を上乗せする追加の防具として設計されている。実際、Claude Codeのサンドボックス機能をこの3点セットの内側で併用することも可能で、それによってさらに堅牢な多層防御が実現する。

次章から、この3点セットを一つずつ具体的に見ていく。まずは全体の土台となるai-sandboxから始めよう。

第8章 ai-sandbox入門 ── Dockerで隔離環境を作る

いよいよ具体的なツールに入る。この章で扱うai-sandbox(github.com/YujiSuzuki/ai-sandbox)は、Claude CodeやGemini CLIといったAIコーディングエージェントを、秘密情報が物理的に存在しない状態のDockerコンテナ内で動かすためのテンプレートリポジトリだ。

8-1. 基本思想:「隠す」はルールではなく物理構造で

第7章で触れた通り、ai-sandboxの核心は、.envファイルやsecrets/ディレクトリを、AIから見て物理的に存在しない状態にすることにある。これはDockerのボリュームマウント機能を使って実現される。

# .devcontainer/docker-compose.yml
volumes:
  # .envファイルを/dev/nullにマウント → AIには「空のファイル」に見える
  - /dev/null:/workspace/your-api/.env:ro

tmpfs:
  # secrets/ディレクトリをtmpfsに → AIには「空のディレクトリ」に見える
  - /workspace/your-api/secrets:ro

ポイントは、これが「AIツールに対するアクセス拒否ルール」ではなく、コンテナのファイルシステムそのものの構成だという点だ。AIエージェントがどれだけ賢くなっても、どんな指示をされても、そこにファイルの実体がない以上、読みようがない。一方で、実際にアプリケーションを動かすAPIコンテナやDBコンテナは、通常通り本物の.envをマウントしているので、アプリケーションの動作には一切影響しない。

Host OS
├── your-api/.env          ← 実ファイル(本物の中身)
│
├── AI Sandbox(AI実行環境)
│   └── AIが.envを読もうとする
│       → /dev/nullにマウントされているため、空に見える
│
└── API Container(実行環境)
    └── Node.jsアプリが.envを読む
        → 通常通り読める

8-2. 二重の防御:Dockerマウント + AIツールの拒否ルール

ai-sandboxは、Dockerマウントによる隠蔽に加えて、.claude/settings.jsonのようなAIツール側の拒否ルールも併用する、二層構造を採用している。

手段効果用途Dockerマウントファイルの実体そのものが見えなくなる.envや証明書など、独立したファイル.claude/settings.jsonの拒否ルールClaude Codeがそのファイルの読み取りを拒否するソースコード内に埋め込まれた秘密情報など、Docker側で隠しきれないケースの安全網

.claude/settings.jsonは「本来隠すべきものは何か」を定義する正(source of truth)として機能し、そこからDockerマウント設定への反映を支援するスクリプト(sync-secrets.sh)も用意されている。つまり、設定の一元管理と、実際の隠蔽手段への同期という2段構えになっている。

8-3. 「隠したつもり」を検出する起動時バリデーション

どれだけ良い仕組みを作っても、設定にミスがあれば意味がない。ai-sandboxは、コンテナの起動のたびに以下のような自動チェックを走らせる。

• 秘密隠蔽の検証: .envやsecrets/が実際に隠れているかを確認

• 設定の整合性チェック: DevContainer環境とCLI Sandbox環境(後述)で、隠蔽設定にズレがないかを確認

• 同期チェック: .claude/settings.jsonで拒否指定されているファイルが、Dockerマウント設定にも反映されているかを確認

問題が見つかれば、コンテナ起動時に警告として表示される。これにより、「設定ミスに気づかないまま、AIが秘密ファイルにアクセスできる状態で作業してしまう」という事故そのものを未然に防ぐことができる。

8-4. なぜ環境が2つあるのか:DevContainerとCLI Sandbox

ai-sandboxには、VS Codeの Dev Containers拡張機能を使うDevContainer環境と、ターミナルから直接使うCLI Sandbox環境の、2つの実行環境が用意されている。

一見冗長に見えるが、これには明確な理由がある。DevContainerの設定自体が壊れてしまった場合、VS CodeはDevContainerを起動できなくなり、当然その中で動くはずのClaude Codeも使えなくなる。「設定を直したいのに、直すためのAIの助けを借りられない」という詰みの状態に陥ってしまう。

CLI Sandboxはこの詰みを回避するための復旧経路だ。DevContainerが壊れていても、ホストから直接./cli_sandbox/claude.shを実行すれば、AIを起動して設定の修復を依頼できる。

./cli_sandbox/claude.sh
# 「DevContainerの設定が壊れているので直して」とAIに依頼できる

日常的な開発ではDevContainerを使い、いざという時の保険としてCLI Sandboxがある、という位置づけだ。

8-5. 導入の流れ

セットアップの全体像は次の3段階に分かれている。どこまで進めるかは目的次第だ。

段階できるようになることai-sandboxのみAIがコードを読み書きできる。秘密ファイルは隠された状態＋hostmcp(第9章)他コンテナのログ確認やテスト実行もAIに任せられる＋デモアプリ実際に動くサンプルで全機能を体験できる

最小構成であれば、GitHubテンプレートからリポジトリを作成し、VS Codeで開いて「Reopen in Container」をクリックするだけで、数分後には秘密情報が隠された状態のAI開発環境が立ち上がる。

8-6. 自分のプロジェクトへの組み込み方

既存プロジェクトに導入する際も、AIに設定作業自体を任せられるよう設計されている点は特筆に値する。たとえば、次のようにAIへ依頼するだけで、Dockerマウントの設定やHostMCPの設定ファイルの下書きまで自動生成させることができる。

「このテンプレートを自分のプロジェクト用にカスタマイズして。
プロジェクトは:
- my-api/(Node.js API。.envとsecrets/ディレクトリあり)
- my-web/(Reactフロントエンド、秘密情報なし)
コンテナ名は my-api、my-web。
my-apiで許可するコマンドは npm test、npm run lint」

もちろん、実際にコンテナを再ビルドしたり、後述のHostMCPサーバーを起動したりする操作自体は人間が行う必要がある。AIに秘密の隠蔽設定を「考えさせる」ことはできても、その設定を最終的に安全な形で反映させる責任は、常に人間の側に残る、という設計思想は覚えておいてよいだろう。

この章のまとめ

ai-sandboxが担うのは、**「AIから秘密情報を物理的に見えなくする」**という第7章で述べた1つ目の課題への回答だ。しかし、これだけでは「他のコンテナと連携しながらデバッグする」という日常的なニーズには応えられない。次章では、この隔離を保ったまま、必要な操作だけを安全に橋渡しするhostmcpを見ていく。

第9章 hostmcp ── ホスト操作を安全に橋渡しする仕組み

第8章のai-sandboxは、AIから秘密情報を隠すことに徹していた。しかし、それだけでは片手落ちだ。実際の開発では、「APIコンテナのログを確認する」「フロントエンドのテストを実行する」といった、コンテナの外側にある操作が日常的に必要になる。この章で扱うhostmcp(github.com/YujiSuzuki/hostmcp)は、その隙間を安全に埋めるためのツールだ。

9-1. なぜ生まれたか:Docker Socketを渡さないための代替手段

第3章で見た通り、AIコンテナに/var/run/docker.sockを直接マウントするのは、事実上ホストの管理者権限を渡すのと同じであり、絶対に避けるべき選択肢だ。しかし、それを避けると今度は「他のコンテナの状態を確認する手段がない」という別の問題が生まれる。

hostmcpは、この板挟みに対する答えだ。ホストOS上で常駐するMCPサーバーとして動作し、AIサンドボックスとの間にゲートウェイを設ける。AIはDocker Socketに直接触れることなく、hostmcpが許可した範囲の操作だけを、SSE(HTTP)経由で行える。

AI Sandbox(コンテナ)
   │  MCP / HTTP
   ▼
hostmcpサーバー(ホストOS)
   ├── コンテナアクセス   ← ログ確認・exec・統計情報
   ├── Host Tools        ← 承認制のホストスクリプト実行
   ├── Container Lifecycle ← コンテナの起動/停止/再起動
   └── Host Commands     ← ホワイトリスト化されたホストコマンド

9-2. 名前の由来:DockMCPからHostMCPへ

序章でも触れた通り、このツールはもともとDockMCPという名前で、「Dockerコンテナ間のアクセスを仲介する」という当初の役割に由来していた。しかし、後述するHost Tools・Container Lifecycle・Host Commandsといった、ホストOS自体の操作を担う機能が追加されるにつれ、名前が実態と合わなくなり、HostMCPへと改称された経緯がある。ネット上に残る初期の解説記事では旧名称のまま説明されていることがあるので、参照する際は注意してほしい。

9-3. 三本柱:Host Tools / Container Lifecycle / Host Commands

hostmcpが提供するホストOSへのアクセス機能は、リスクの度合いに応じて3つに分かれている。デフォルトで有効なのはHost Toolsのみで、残りの2つはオプトインだ。

Host Tools:承認制のスクリプト実行

AIが.sandbox/host-tools/ディレクトリにスクリプトを置いても、それはそのままでは実行されない。人間がホスト側でhostmcp tools syncコマンドを実行し、スクリプトの中身を確認したうえで明示的に承認して初めて、実行可能になる。

1. AIが .sandbox/host-tools/ にスクリプトを配置(ステージング。コンテナ内から書き込み可能)
2. 人間がホストOSで hostmcp tools sync を実行(内容をレビュー)
3. 承認されたコピーが ~/.hostmcp/host-tools/<project-id>/ に保存される
4. 以降、承認済みバージョンのみがhostmcp経由で実行可能

承認済みスクリプトはSHA256ハッシュで内容が記録され、AIがステージング側のスクリプトを後から書き換えても、その変更は自動反映されない。再び差分が検出され、再承認が求められる。AIはコードを"提案"できるが、それを"有効化"できるのは常に人間だけ、という設計だ。

Container Lifecycle:コンテナの起動・停止・再起動

クラッシュしたコンテナの復旧など、AIにコンテナのライフサイクル管理を任せたい場合に使う機能。デフォルトでは無効になっており、設定ファイルで明示的に有効化する必要がある。Docker CLIの実行ではなく、Docker APIを直接叩く実装になっており、かつ許可されたコンテナ名のパターンにのみ操作範囲が限定される。

Host Commands:ホワイトリスト化されたホストコマンド

git statusのようなホストOS上のコマンドを、AIに直接実行させたい場合の機能。3層の制御がかけられている。

1. ホワイトリスト: 許可するコマンドと引数パターンを明示的に定義(例:git diff *は許可、それ以外は拒否)

2. 拒否リスト: ホワイトリストより優先され、特定の危険な組み合わせを明示的にブロック

3. 危険モード: git pullのような、通常より注意を要するコマンドは別枠で管理し、呼び出し側が明示的に「危険を承知している」フラグを立てない限り実行できない

さらに、設定内容にかかわらず、パイプ(|)・リダイレクト(> <)・パストラバーサル(..)は常にブロックされる。これは「ホワイトリストしたコマンド単体は安全でも、組み合わせ次第で危険になる」というシェルの性質を踏まえた、堅牢な設計だ。

9-4. 出力マスキングと監査ログ:見えてしまった後の防御

第4章で触れた出力マスキングは、このhostmcpのゲートウェイ機能として実装されている。ログやコマンド出力にパスワード・APIキー・認証情報付きのURLなどが含まれていた場合、AIに渡される前に自動的に[MASKED]へ置換される。

加えて、ホストOSのユーザー名を含むパス(/Users/username/など)も自動的にマスキングされる。これは地味だが重要な配慮で、ホストのユーザーを特定しうる情報がAIとの会話に紛れ込むこと自体を防いでいる。監査ログを有効にしておけば、ホストアクセスに関する操作はすべて記録され、第6章で紹介したような「後から何が起きたか調査する」ためのログとしても機能する。

9-5. 現在地:まだ守れていない領域

第2章の終わりで触れた通り、hostmcpが今カバーしているのは「読む」「実行する」「ホストを操作する」際の安全性であり、AIコンテナ内で発生する破壊的なファイル操作(rm -rfなど)そのものを未然に防ぐ機能は、まだ実装されていない。

これに対しては、hostmcpがホストOS上で常駐して動くという性質を活かした対策が構想段階にある。具体的には、サンドボックスのworkspaceディレクトリの一つ上の階層でGitリポジトリを初期化し、一定間隔で自動的にスナップショットをコミットしておく仕組みだ。これが実現すれば、コンテナ内でどれだけ破壊的な操作が起きても、ホスト側の視点から任意の時点まで巻き戻せるようになる。今後のアップデートを追う価値のある領域だ。

この章のまとめ

hostmcpは、「Docker Socketを渡さずに、必要な操作だけを安全に橋渡しする」という第7章で述べた2つ目の課題への回答だ。承認制・ホワイトリスト・出力マスキング・監査ログという複数の防御層を重ねることで、利便性と安全性のバランスを取っている。

次章では、コンテナの"内側"での拡張性を担うsandbox-mcpを見ていく。

第10章 sandbox-mcp ── コンテナ内ツールの自動発見と実行

第8章のai-sandboxが秘密を隠し、第9章のhostmcpがホストへの橋を安全に架けた。この章で扱うsandbox-mcpは、視点をもう一度コンテナの"内側"に戻す。AIが自分の作業環境の中で、道具をどう発見し、どう使うかという拡張性の話だ。

10-1. hostmcpとの役割分担

まず、名前が似ているhostmcpとの違いをはっきりさせておこう。

sandbox-mcphostmcp動作場所コンテナ内ホストOS通信方式stdioSSE(HTTP)目的コンテナ内のスクリプト/ツールの発見と実行他コンテナ・ホストOSへの制御されたアクセス起動AI CLIツールが自動起動手動(hostmcp serve)

sandbox-mcpが見ているのは、あくまで自分がいるコンテナの中だけだ。ホストOS上のファイルや、他のコンテナのことは一切関知しない。「餅は餅屋」という発想で、コンテナ内の拡張性はsandbox-mcp、コンテナ外への安全な橋渡しはhostmcpと、明確に役割が分かれている。

10-2. 「ファイルを置くだけ」というプラグイン方式

sandbox-mcpの最大の特徴は、AIに新しい能力を持たせる方法が驚くほどシンプルな点にある。設定ファイルの編集も、MCPサーバーの再登録も必要ない。.sandbox/tools/または.sandbox/scripts/ディレクトリに、決まった形式のヘッダーコメントを持つファイルを置くだけで、AIはそのツールを自動的に発見し、使えるようになる。

Goで書かれたツールの場合:

// 短い説明文(この1行目が説明として使われる)
//
// Usage:
//   go run .sandbox/tools/my-tool.go [options] <args>
//
// Examples:
//   go run .sandbox/tools/my-tool.go "hello"
//
// --- (ここから下はパースされない。人間向けの補足)
package main

シェルスクリプトの場合も同様の形式で書ける。

#!/bin/bash
# my-script.sh
#
# 英語での説明文
#
# Usage:
#   my-script.sh [options] <args>
#
# ---
# 日本語での説明(任意、パースされない)

シェルスクリプトは他の言語を呼び出せるので、実質的にGo以外の任意の言語でツールを実装できる。この「ファイルを置くだけ」という設計は、開発者が思いつきで小さなユーティリティを追加するハードルを大きく下げる。

10-3. AIが自分でツールを選ぶ

sandbox-mcpはコンテナ起動時に自動的にビルド・登録され、以下の6つのMCPツールをAIに提供する。なお、コンテナ内にGo環境がない場合は、GitHub Releasesからビルド済みバイナリを自動ダウンロードするフォールバックが用意されており、Goの有無に関わらず同じ体験が得られるようになっている。

ツール役割list_scripts / list_tools利用可能なスクリプト・ツールの一覧を取得get_script_info / get_tool_info特定のスクリプト・ツールの詳細な使い方を取得run_script / run_tool実際に実行する

重要なのは、開発者が「このツールを使って」と逐一指示する必要がない、という点だ。AIはlist_toolsで自分が使える道具を確認し、目の前の課題に合わせて自分で判断して使う。ある開発者は、自分が過去に作って存在すら忘れていたツールを、AIが文脈から判断して自発的に使いこなした、というエピソードを公開している。「道具箱を渡しておけば、AIはこちらが指示しなくても、適切な道具を自分で選び出す」——これがsandbox-mcpが体現している思想だ。

10-4. 同梱ツールの例:ai-sandboxが持ち込むsearch-history

ここで一つ、正確に言い直しておきたいことがある。sandbox-mcp自体はツールを一切同梱していない。あくまで.sandbox/tools/や.sandbox/scripts/に置かれたファイルを発見して実行するだけの汎用エンジンだ。実用的なツールを実際に持ち込んでいるのはai-sandboxのほうで、そのテンプレートが.sandbox/tools/にあらかじめsearch-historyなどのスクリプトを配置しており、それをsandbox-mcpが発見して使える状態にしている、という関係になる。

中でも実用性が高いのが、第6章で紹介したsearch-historyだ。

search-historyは、Claude Codeが~/.claude/projects/配下にJSONL形式で保存している過去の会話履歴を検索するツールで、以下のような使い方ができる。

• キーワード検索(「HostMCPのセットアップについて話した会話を覚えてる?」)

• 期間指定でのセッション一覧表示(「先週の会話を見せて」)

• 日別/週別の作業内容の要約(「昨日は何をやったっけ?」)

• Bashコマンドの実行履歴だけを絞り込んだ検索(-role tool -tool Bash)

第6章で紹介した、謎のバイナリファイルの出所を突き止めた実例は、まさにこの機能が使われたケースだ。「何が起きたか分からない」という状況で、後から調査する手段を持っていること自体が、実務上のセキュリティ対策として機能する。

10-5. 大事な注意点:コンテナ内では"無防備"

ここで一つ、誤解しないでほしいことがある。sandbox-mcp自体は、それが動いているコンテナの中でさらに追加の権限制限をかける仕組みではない。ツールはAI自身と同じ権限で実行される。つまり、コンテナの中においては「発見と実行を便利にする」ためのレイヤーであって、セキュリティのレイヤーではない。

コンテナ内でのセキュリティ(秘密ファイルの隠蔽など)は第8章のai-sandboxが、コンテナ外への安全なアクセスは第9章のhostmcpが担っている。sandbox-mcpはその両者の"外側"にはみ出さない範囲で、開発体験を底上げする役割に徹している——この住み分けを理解しておくと、3点セット全体の設計思想がすっきり見えてくる。

この章のまとめ

sandbox-mcpは、セキュリティそのものを強化するツールではなく、すでに安全に隔離された環境の中で、AIをより自律的に働かせるための拡張基盤だ。ファイルを置くだけで機能が増え、AIはその機能を自分の判断で使いこなす。

次章では、ai-sandbox・hostmcp・sandbox-mcpの3つを実際にどう組み合わせて使うか、統合的なワークフローとして見ていく。

第11章 実践:鬼に金棒構成を組む ── 3ツール統合フロー

理屈は十分に積み上げてきた。この章では、ai-sandbox + hostmcp + sandbox-mcpを実際に組み合わせ、「秘密情報ゼロ露出・フル自律」の開発環境を一通り立ち上げるところまでを、具体的な手順で追っていく。

11-1. 全体の地図

セットアップは大きく3段階に分かれる。どこまで進めるかは、あなたの必要度合いに応じて選べばいい。

Step 1〜3: ai-sandboxを起動する(必須)
    ↓
Step 4〜6: hostmcpを接続する(推奨)
    ↓
Step 7〜8: デモアプリで動作を体験する(任意)

11-2. Step 1〜3:ai-sandboxを起動する

前提として、Docker(Docker DesktopやOrbStackなど)、VS Code、Dev Containers拡張機能をインストールしておく。

# テンプレートから新規作成する場合はGitHub上で「Use this template」→ clone

# 直接cloneする場合
git clone https://github.com/YujiSuzuki/ai-sandbox.git
cd ai-sandbox

VS Codeで開き、DevContainerとして再オープンする。

code .
# 右下に出る通知「Reopen in Container」をクリック
# 出ない場合は Cmd+Shift+P → "Dev Containers: Reopen in Container"

初回はイメージのビルドで数分かかる。起動が完了すると、ターミナルに秘密隠蔽の検証結果などが表示される。この時点で、.envのような秘密ファイルはすでにAIから見えない状態になっている。ここまでで「AIがコードを読み書きできて、秘密は隠されている」という最小構成が完成する。

11-3. Step 4〜6:hostmcpを接続する

ここからはホストOS側(DevContainerの中ではなく、あなたのMacやPC本体)での作業になる。

# ホストOSの別ターミナルで
go install github.com/YujiSuzuki/hostmcp@latest

Go環境がすでにあるなら、これが最も手早い。Goを入れたくない/入っていない場合は、リポジトリをcloneしてmake installでビルドする方法もある。

git clone https://github.com/YujiSuzuki/hostmcp.git
cd hostmcp
make install  # ~/go/bin/ にインストールされる

インストールが終わったら、hostmcpサーバーを起動する。

hostmcp serve --config configs/hostmcp.example.yaml --sync

--syncオプションを付けると、Host Tools機能(第9章参照)が有効になり、AIが提案したホストスクリプトを承認するワークフローが使えるようになる。このターミナルは起動したままにしておく。

続いて、AIサンドボックス側(VS CodeのDevContainerターミナル)から接続を登録する。

claude mcp add --transport sse --scope user hostmcp http://host.docker.internal:18080/sse

Claude Codeで/mcpと入力し、「Reconnect」を選べば接続完了だ。hostmcpが✔ connectedと表示され、利用可能なツール数が表示されれば成功している。

11-4. 統合された状態で、実際に何ができるようになるか

3点セットが揃った状態で、実際の開発フローがどう変わるかを、典型的なデバッグシナリオで見てみよう。

シナリオ: 「Webアプリでログインができない」というバグ調査

あなた: 「ログインが失敗するんだけど、APIのログを見て調べて」

Claude Code:
 1. sandbox-mcpで自分が使えるツールを確認(必要に応じて)
 2. hostmcp経由でAPIコンテナのログを取得
    → hostmcp.get_logs("api-container", { tail: "50" })
 3. ログの中から "JWT verification failed - invalid secret" を発見
    (この時点で、ログに紛れていた可能性のある秘密情報は
     hostmcpの出力マスキング機能によって自動的に隠された状態で
     Claudeに渡っている)

あなた: 「APIのテストを実行して確認して」

Claude Code:
 4. hostmcp経由でホワイトリスト化されたテストコマンドを実行
    → hostmcp.exec_command("api-container", "npm test")
 5. 結果を報告し、原因を特定

この一連の流れの中で、Claude Codeは一度も.envファイルの実体に触れていない。APIコンテナのログという、本来必要な情報だけを、安全な経路を通じて取得している。これが「秘密情報ゼロ露出」と「フル自律デバッグ」を両立させた状態だ。

11-5. Before / After

3点セットを導入する前後で、日々の開発フローがどう変わるかを整理しておこう。

項目導入前(素のホストOS実行)導入後(3点セット).envの可視性AIから直接読める物理的に見えない(第8章)他コンテナのログ確認Docker Socket経由で無制限、または不可能ホワイトリスト化された経路のみ(第9章)コマンド実行の範囲ホストOS全体コンテナ内 + hostmcpが許可した範囲のみログ中の秘密情報そのまま見える可能性自動マスキング(第9章)新しいツールの追加都度、設定ファイルを編集ファイルを置くだけ(第10章)事故の事後調査手がかりが乏しい会話履歴・監査ログから追跡可能(第6・9・10章)rm -rfのような破壊的操作無防備現状はまだ対策途上(構想はある、第9章)

最後の項目だけは正直に「発展途上」と書いた。この本を読んでいる時点で、すでに状況が進展している可能性もある。プロジェクトの更新は定期的に追いかけておくとよいだろう。

11-6. 運用のコツ

最後に、実際に使い込む上でのちょっとした助言を残しておく。

• Host Toolsの承認は必ず中身を読んでから。「AIが作ったから安全」という思い込みは禁物だ。承認制のワークフローは、人間が実際にレビューして初めて意味を持つ

• hostmcp.yamlのホワイトリストは、最初は狭く始めて、必要になったら広げる方向で運用する。逆(広く始めて絞る)は、絞り忘れが起きやすい

• ネットワーク制限(第4章)は別途検討する。この3点セットだけでは通信の遮断は行われない。Anthropic公式のファイアウォールスクリプトなどを組み合わせるのが実務的だ

• 定期的なアップデート確認を習慣化する。特にhostmcp側の構想中の機能(Gitスナップショットなど)は今後追加される可能性が高い領域だ

11-7. マルチリポジトリ構成でのプラグイン活用

ここまでは単一プロジェクト、あるいは単一のワークスペース内での話を中心に進めてきた。だが実際の開発現場では、モバイルアプリ・API・Webフロントエンドといった複数プロジェクトを、それぞれ独立したGitリポジトリとして一つのワークスペースにまとめて扱うケースが珍しくない。

このマルチリポジトリ構成には、モノレポとは異なる固有の事情がある。各プロジェクトが独立したリポジトリである以上、PRもブランチもコミット履歴もプロジェクトごとに独立している。Claude Codeのプラグイン機能(スラッシュコマンドなど)を使う場合、「今どのプロジェクトのコンテキストで動いているか」をAI自身が正しく認識できるように設計しておかないと、別プロジェクト向けのコマンドを誤って実行してしまうような事故につながりかねない。

ai-sandboxはこの構成を前提にしたプラグイン活用の指針をdocs/plugins.mdにまとめている。要点は次の2つだ。

• プロジェクトごとにコマンドの実行範囲を明示する: 「このコマンドはmy-apiディレクトリ配下でのみ意味を持つ」という前提を、コマンド定義自体に落とし込んでおく

• 横断的なレビューコマンドは、対象リポジトリを引数で明示させる: 複数リポジトリを暗黙に横断してしまう設計は、第5章で見た「マルチプロジェクト環境での横断リスク」と同じ構造の事故を生む

第5章では「複数プロジェクトを横断する際に秘密情報が混線するリスク」を扱ったが、この11-7で見た内容はいわばその裏返しだ。秘密を混線させない仕組みだけでなく、AIの操作範囲自体を混線させない仕組みも、マルチプロジェクトのフル自律運用には欠かせない。

これで、実際に手を動かして「秘密情報ゼロ露出・フル自律」の環境を組み上げる方法は一通り紹介し終えた。最後に、終章としてこの本全体の要点をまとめる。

終章 フル自律開発時代のセキュリティ心得

この本で伝えたかったこと

長い旅路だった。ここまでの内容を、あらためて一言でまとめるとこうなる。

「気をつける」は対策にならない。「構造で守る」ことだけが、フル自律型のAIエージェントと安心して付き合う唯一の道だ。

第1部(第1〜6章)では、ファイルシステム、コマンド実行、ネットワーク、認証情報という4つのレイヤーにわたって、フル自律エージェントがどれほど無防備な環境で動いているかを見てきた。そして、それらの危険が「AIが悪い」からではなく、AIに必要以上のものを見せている構造そのものから生まれていることを確認した。

第2部(第7〜11章)では、その構造を変える具体的な方法として、ai-sandbox・hostmcp・sandbox-mcpという3つのオープンソースツールを紹介した。

• ai-sandboxが秘密情報を物理的に見えなくする

• hostmcpがDocker Socketという「実質的な管理者権限」を渡すことなく、必要な操作だけを安全に橋渡しする

• sandbox-mcpがその安全な環境の中で、AIをより自律的に働かせる

この3つが揃って初めて、「秘密情報ゼロ露出」と「フル自律開発」という、一見両立が難しい2つの要求を同時に満たせる。まさに"鬼に金棒"の状態だ。

それでも残る、正直な限界

本書は、これらのツールを万能の銀の弾丸として紹介したわけではない。ネットワーク制限は標準搭載されていないこと、rm -rfのような破壊的操作への直接的な防御はまだ発展途上であることなど、現時点での限界も隠さずに書いた。

セキュリティにおいて「これで完璧」と言い切ることほど危険な態度はない。オープンソースであるということは、今この瞬間も改善が続いているということでもある。本書に書かれた内容も、いずれ古くなる。気になった人は、ぜひ実際のリポジトリで最新の状況を確認してほしい。

• ai-sandbox: https://github.com/YujiSuzuki/ai-sandbox

• hostmcp: https://github.com/YujiSuzuki/hostmcp

• sandbox-mcp: https://github.com/YujiSuzuki/sandbox-mcp

組織で使うということ

序章の「経営層・チームリーダーにも関係がある理由」でも触れたが、個人の開発環境として導入する分には、ここまでの話で十分だ。だが、これをチームや組織の標準として広げようとするなら、もう一段考えるべきことがある。

一つは、初期コストの見え方だ。Dockerの学習コストや設定ファイルの整備は、目の前の締め切りに追われているチームほど後回しにされやすい。しかし、それは「事故が起きるまでのコストを先送りしている」だけで、消えてなくなるわけではない。一度でも秘密情報の漏洩やホスト環境の破壊的な事故を経験したチームなら、この投資判断の重みは体感として分かるはずだ。

もう一つは、属人化の回避だ。一人のスーパーエンジニアが「自分は気をつけているから大丈夫」で運用しているだけでは、そのチームの安全性はその人がいなくなった瞬間に消える。設定ファイル(.claude/settings.jsonやhostmcpのホワイトリスト)という形で構造に落とし込んでおけば、新しく加わったメンバーも、初日から同じ安全水準で働ける。これは開発速度の話であると同時に、オンボーディングコストの話でもある。

フル自律型のAIエージェントをどこまで信頼して任せるかは、今後どの組織も一度は向き合う問いになる。その問いに「気をつけます」以外の答えを用意しておくことは、エンジニア個人のためだけでなく、組織としての備えでもある。

最後に

フル自律型のAIエージェントは、これからも進化し続ける。モデルは賢くなり、任せられる作業の範囲は広がっていくだろう。しかしそれと同時に、「賢さに依存しない安全性」を自分の手元に用意しておくことの重要性は、決して減ることはない。

この本が、あなたのClaude Code環境を、無防備な状態から一歩前に進めるきっかけになれば幸いだ。

安全に、そして存分に、AIを使い倒してほしい。