AIエージェントの安全なデプロイ

Claude CodeおよびAgent SDKは、コードを実行し、ファイルにアクセスし、外部サービスと対話できる強力なツールです。これらの機能を持つツールと同様に、これらを慎重にデプロイすることで、利点を得ながら適切な制御を維持できます。

事前に決められたコードパスに従う従来のソフトウェアとは異なり、これらのツールはコンテキストと目標に基づいて動的にアクションを生成します。この柔軟性が有用性をもたらしますが、処理するコンテンツ（ファイル、ウェブページ、ユーザー入力）によって動作が影響を受ける可能性があることも意味します。これはプロンプトインジェクションと呼ばれることもあります。例えば、リポジトリのREADMEに異常な指示が含まれている場合、Claude Codeはオペレーターが予想しなかった方法でそれらの指示をアクションに組み込む可能性があります。このガイドでは、このリスクを軽減するための実践的な方法について説明します。

良いニュースは、エージェントのデプロイを保護するために特殊なインフラストラクチャは必要ないということです。半信頼できるコードを実行する場合に適用される同じ原則が適用されます：分離、最小権限、多層防御です。Claude Codeには一般的な懸念に対応するためのセキュリティ機能が含まれており、このガイドではこれらと、さらなる強化が必要な場合の追加的な強化オプションについて説明します。

すべてのデプロイが最大限のセキュリティを必要とするわけではありません。ラップトップでClaude Codeを実行している開発者は、マルチテナント環境で顧客データを処理している企業とは異なる要件があります。このガイドでは、Claude Codeの組み込みセキュリティ機能から強化されたプロダクション アーキテクチャまで、さまざまなオプションを提示しているため、状況に合ったものを選択できます。

何から保護しているのか？

エージェントは、プロンプトインジェクション（処理するコンテンツに埋め込まれた指示）またはモデルエラーが原因で、意図しないアクションを実行する可能性があります。Claudeモデルはこれに対する耐性を持つように設計されており、モデルカードで分析したように、Claude Opus 4.5は利用可能な最も堅牢なフロンティアモデルであると考えています。

ただし、多層防御は依然として良い実践です。例えば、エージェントが顧客データを外部サーバーに送信するよう指示する悪意のあるファイルを処理する場合、ネットワーク制御はそのリクエストを完全にブロックできます。

組み込みセキュリティ機能

Claude Codeには、一般的な懸念に対応するためのいくつかのセキュリティ機能が含まれています。詳細については、セキュリティドキュメントを参照してください。

• 権限システム：すべてのツールとbashコマンドは、許可、ブロック、またはユーザーの承認を求めるように設定できます。グロブパターンを使用して、「すべてのnpmコマンドを許可」または「sudoを含むコマンドをブロック」などのルールを作成します。組織は、すべてのユーザーに適用されるポリシーを設定できます。アクセス制御と権限を参照してください。
• 静的分析：bashコマンドを実行する前に、Claude Codeは静的分析を実行して、潜在的にリスクのある操作を特定します。システムファイルを変更したり、機密ディレクトリにアクセスしたりするコマンドはフラグが立てられ、明示的なユーザー承認が必要です。
• ウェブ検索の要約：検索結果は、生のコンテンツをコンテキストに直接渡すのではなく、要約されるため、悪意のあるウェブコンテンツからのプロンプトインジェクションのリスクが軽減されます。
• サンドボックスモード：bashコマンドはサンドボックス環境で実行でき、ファイルシステムとネットワークアクセスを制限します。詳細については、サンドボックスドキュメントを参照してください。

セキュリティの原則

Claude Codeのデフォルトを超えた追加の強化が必要なデプロイの場合、これらの原則は利用可能なオプションをガイドします。

セキュリティ境界

セキュリティ境界は、異なる信頼レベルを持つコンポーネントを分離します。高セキュリティのデプロイの場合、機密リソース（認証情報など）をエージェントを含む境界の外に配置できます。エージェントの環境で問題が発生した場合、その境界外のリソースは保護されたままです。

例えば、エージェントにAPIキーへの直接アクセスを与える代わりに、エージェントの環境外で実行されるプロキシを実行して、キーをリクエストに注入することができます。エージェントはAPI呼び出しを実行できますが、認証情報自体は見ることはありません。このパターンは、マルチテナント デプロイまたは信頼できないコンテンツを処理する場合に有用です。

最小権限

必要に応じて、エージェントを特定のタスクに必要な機能のみに制限できます：

多層防御

高セキュリティ環境では、複数の制御を層状に配置することで追加の保護が提供されます。オプションには以下が含まれます：

• コンテナ分離
• ネットワーク制限
• ファイルシステム制御
• プロキシでのリクエスト検証

適切な組み合わせは、脅威モデルと運用要件によって異なります。

分離技術

異なる分離技術は、セキュリティ強度、パフォーマンス、運用の複雑さの間で異なるトレードオフを提供します。

サンドボックスランタイム

コンテナなしで軽量な分離を行う場合、sandbox-runtimeはOSレベルでファイルシステムとネットワークの制限を強制します。

主な利点はシンプルさです：Dockerの設定、コンテナイメージ、またはネットワーク設定は必要ありません。プロキシとファイルシステムの制限は組み込まれています。許可されたドメインとパスを指定する設定ファイルを提供します。

動作方法：

• ファイルシステム：OS プリミティブ（Linux上のbubblewrap、macOS上のsandbox-exec）を使用して、設定されたパスへの読み取り/書き込みアクセスを制限します
• ネットワーク：ネットワークネームスペース（Linux）を削除するか、Seatbeltプロファイル（macOS）を使用してネットワークトラフィックを組み込みプロキシ経由でルーティングします
• 設定：ドメインとファイルシステムパスのJSONベースの許可リスト

セットアップ：

npm install @anthropic-ai/sandbox-runtime

次に、許可されたパスとドメインを指定する設定ファイルを作成します。

セキュリティに関する考慮事項：

1. 同一ホストカーネル：VMとは異なり、サンドボックス化されたプロセスはホストカーネルを共有します。カーネルの脆弱性は理論的にはエスケープを可能にする可能性があります。一部の脅威モデルではこれは許容可能ですが、カーネルレベルの分離が必要な場合は、gVisorまたは別のVMを使用してください。

2. TLS検査なし：プロキシはドメインを許可リストに登録しますが、暗号化されたトラフィックは検査しません。エージェントが許可されたドメインに対する許容的な認証情報を持っている場合、そのドメインを使用して他のネットワークリクエストをトリガーしたり、データを流出させたりすることが可能でないことを確認してください。

多くのシングル開発者およびCI/CDユースケースでは、sandbox-runtimeは最小限のセットアップで大幅に改善されます。以下のセクションでは、より強力な分離が必要なデプロイメント向けのコンテナとVMについて説明します。

コンテナ

コンテナはLinuxネームスペースを通じて分離を提供します。各コンテナはファイルシステム、プロセスツリー、ネットワークスタックの独自のビューを持ちながら、ホストカーネルを共有します。

セキュリティが強化されたコンテナ構成は次のようになります：

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

各オプションの機能は次のとおりです：

Unixソケットアーキテクチャ：

--network noneを使用すると、コンテナはネットワークインターフェースを持ちません。エージェントが外部世界に到達する唯一の方法は、マウントされたUnixソケットを通じることです。これはホスト上で実行されているプロキシに接続します。このプロキシはドメイン許可リストを強制し、認証情報を注入し、すべてのトラフィックをログに記録できます。

これはsandbox-runtimeで使用されるのと同じアーキテクチャです。エージェントがプロンプトインジェクション経由で侵害された場合でも、任意のサーバーにデータを流出させることはできません。プロキシを通じてのみ通信でき、プロキシが到達可能なドメインを制御します。詳細については、Claude Codeサンドボックスブログ投稿を参照してください。

追加の強化オプション：

gVisor

標準コンテナはホストカーネルを共有します：コンテナ内のコードがシステムコールを実行すると、ホストを実行する同じカーネルに直接移動します。これはカーネルの脆弱性がコンテナエスケープを許可する可能性があることを意味します。gVisorはユーザースペースでシステムコールをインターセプトしてホストカーネルに到達する前に処理することでこれに対処し、実際のカーネルを関与させずにほとんどのシステムコールを処理する独自の互換性レイヤーを実装します。

エージェントが悪意のあるコード（おそらくプロンプトインジェクションが原因）を実行する場合、そのコードはコンテナ内で実行され、カーネルエクスプロイトを試みる可能性があります。gVisorを使用すると、攻撃面ははるかに小さくなります：悪意のあるコードはまずgVisorのユーザースペース実装を悪用する必要があり、実際のカーネルへのアクセスは限定的です。

DockerでgVisorを使用するには、runscランタイムをインストールしてデーモンを設定します：

// /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

次に、以下を使用してコンテナを実行します：

docker run --runtime=runsc agent-image

パフォーマンスに関する考慮事項：

マルチテナント環境または信頼できないコンテンツを処理する場合、追加の分離はしばしばオーバーヘッドの価値があります。

仮想マシン

VMはCPU仮想化拡張機能を通じてハードウェアレベルの分離を提供します。各VMは独自のカーネルを実行し、強力な境界を作成します。ゲストカーネルの脆弱性はホストを直接侵害しません。ただし、VMは自動的にgVisorなどの代替案より「より安全」ではありません。VMセキュリティはハイパーバイザーとデバイスエミュレーションコードに大きく依存します。

Firecrackerは軽量なマイクロVM分離用に設計されています。125ms以下でVMをブート可能で、5MiB未満のメモリオーバーヘッドで、攻撃面を減らすために不要なデバイスエミュレーションを削除します。

このアプローチでは、エージェントVMは外部ネットワークインターフェースを持ちません。代わりに、vsock（仮想ソケット）を通じて通信します。すべてのトラフィックはvsock経由でホスト上のプロキシにルーティングされ、プロキシが許可リストを強制し、認証情報を注入してからリクエストを転送します。

クラウドデプロイメント

クラウドデプロイメントの場合、上記の分離技術のいずれかをクラウドネイティブなネットワーク制御と組み合わせることができます：

1. エージェントコンテナをインターネットゲートウェイなしのプライベートサブネットで実行します
2. クラウドファイアウォールルール（AWS Security Groups、GCP VPCファイアウォール）を設定して、プロキシ以外へのすべての送信をブロックします
3. リクエストを検証し、ドメイン許可リストを強制し、認証情報を注入し、外部APIに転送するEnvoyなどのプロキシ（そのcredential_injectorフィルター付き）を実行します
4. エージェントのサービスアカウントに最小限のIAM権限を割り当て、可能な限りプロキシ経由で機密アクセスをルーティングします
5. 監査目的でプロキシのすべてのトラフィックをログに記録します

認証情報管理

エージェントはしばしば、APIを呼び出し、リポジトリにアクセスし、クラウドサービスと対話するための認証情報が必要です。課題は、認証情報自体を公開することなくこのアクセスを提供することです。

プロキシパターン

推奨されるアプローチは、エージェントのセキュリティ境界の外で実行されるプロキシを実行して、送信リクエストに認証情報を注入することです。エージェントは認証情報なしでリクエストを送信し、プロキシがそれらを追加して、リクエストを宛先に転送します。

このパターンにはいくつかの利点があります：

1. エージェントは実際の認証情報を見ることはありません
2. プロキシは許可されたエンドポイントの許可リストを強制できます
3. プロキシはすべてのリクエストを監査目的でログに記録できます
4. 認証情報は各エージェントに分散されるのではなく、1つの安全な場所に保存されます

Claude Codeをプロキシを使用するように設定する

Claude Codeはサンプリングリクエストをプロキシ経由でルーティングするための2つの方法をサポートしています：

オプション1：ANTHROPIC_BASE_URL（シンプルですがサンプリングAPIリクエストのみ）

export ANTHROPIC_BASE_URL="http://localhost:8080"

これはClaude CodeおよびAgent SDKに、Anthropic APIに直接ではなく、プロキシにサンプリングリクエストを送信するよう指示します。プロキシはプレーンテキストHTTPリクエストを受け取り、検査および変更（認証情報の注入を含む）してから、実際のAPIに転送できます。

オプション2：HTTP_PROXY / HTTPS_PROXY（システム全体）

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Claude CodeおよびAgent SDKはこれらの標準環境変数を尊重し、すべてのHTTPトラフィックをプロキシ経由でルーティングします。HTTPSの場合、プロキシは暗号化されたCONNECTトンネルを作成します：TLS検査なしではリクエストコンテンツを見たり変更したりすることはできません。

プロキシの実装

独自のプロキシを構築するか、既存のものを使用できます：

• Envoy Proxy — 認証ヘッダーを追加するためのcredential_injectorフィルター付きのプロダクショングレードプロキシ
• mitmproxy — HTTPSトラフィックを検査および変更するためのTLS終了プロキシ
• Squid — アクセス制御リスト付きのキャッシングプロキシ
• LiteLLM — 認証情報注入とレート制限付きのLLMゲートウェイ

他のサービスの認証情報

Anthropic APIからのサンプリングを超えて、エージェントはしばしば他のサービスへの認証済みアクセスが必要です。gitリポジトリ、データベース、内部API。主に2つのアプローチがあります：

カスタムツール

MCPサーバーまたはカスタムツール経由でアクセスを提供して、リクエストをエージェントのセキュリティ境界の外で実行されているサービスにルーティングします。エージェントはツールを呼び出しますが、実際の認証済みリクエストは外部で発生します。ツールはプロキシを呼び出し、プロキシが認証情報を追加してからリモートリポジトリに接続します。エージェントは認証情報を見ることはありません。

利点：

• TLS検査なし：外部サービスは認証済みリクエストを直接実行します
• 認証情報は外部に留まる：エージェントはツールインターフェースのみを見て、基礎となる認証情報は見ません

トラフィック転送

Anthropic APIコールの場合、ANTHROPIC_BASE_URLを使用すると、プレーンテキストでリクエストを検査および変更できるプロキシにリクエストをルーティングできます。ただし、他のHTTPSサービス（GitHub、npmレジストリ、内部API）の場合、トラフィックはしばしばエンドツーエンドで暗号化されます。HTTP_PROXY経由でプロキシ経由でルーティングしても、プロキシは不透明なTLSトンネルのみを見て、認証情報を注入することはできません。

カスタムツールを使用せずに任意のサービスへのHTTPSトラフィックを変更するには、トラフィックを復号化し、検査または変更してから、転送前に再暗号化するTLS終了プロキシが必要です。これには以下が必要です：

1. エージェントのコンテナの外でプロキシを実行する
2. プロキシのCA証明書をエージェントの信頼ストアにインストールする（エージェントがプロキシの証明書を信頼するため）
3. HTTP_PROXY/HTTPS_PROXYを設定してトラフィックをプロキシ経由でルーティングする

このアプローチはカスタムツールを記述することなく、任意のHTTPベースのサービスを処理しますが、証明書管理の周りに複雑さを追加します。

すべてのプログラムがHTTP_PROXY/HTTPS_PROXYを尊重するわけではないことに注意してください。ほとんどのツール（curl、pip、npm、git）は尊重しますが、一部はこれらの変数をバイパスして直接接続する可能性があります。例えば、Node.js fetch()はデフォルトではこれらの変数を無視します。Node 24以降では、NODE_USE_ENV_PROXY=1を設定してサポートを有効にできます。包括的なカバレッジの場合、proxychainsを使用してネットワークコールをインターセプトするか、iptablesを設定して送信トラフィックを透過プロキシにリダイレクトできます。

両方のアプローチはまだTLS終了プロキシと信頼されたCA証明書を必要とします。トラフィックが実際にプロキシに到達することを確認するだけです。

ファイルシステム設定

ファイルシステム制御は、エージェントが読み取り、書き込みできるファイルを決定します。

読み取り専用コードマウント

エージェントがコードを分析する必要があるが、変更する必要がない場合、ディレクトリを読み取り専用でマウントします：

docker run -v /path/to/code:/workspace:ro agent-image

書き込み可能な場所

エージェントがファイルを書き込む必要がある場合、変更を永続化するかどうかに応じて、いくつかのオプションがあります：

コンテナ内の一時的なワークスペースの場合、メモリにのみ存在し、コンテナが停止したときにクリアされるtmpfsマウントを使用します：

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

変更を永続化する前に確認したい場合、オーバーレイファイルシステムはエージェントが基礎となるファイルを変更することなく書き込みを可能にします。変更は別のレイヤーに保存され、検査、適用、または破棄できます。完全に永続的な出力の場合、専用ボリュームをマウントしますが、機密ディレクトリとは別に保ちます。

さらに読む

• Claude Codeセキュリティドキュメント
• Agent SDKのホスティング
• 権限の処理
• Sandbox runtime
• The Lethal Trifecta for AI Agents
• OWASP Top 10 for LLM Applications
• Docker Security Best Practices
• gVisor Documentation
• Firecracker Documentation

必要なソースファイルのみをコピーするか、.dockerignoreスタイルのフィルタリングを使用することを検討してください。