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

Claude CodeとAgent SDKは、コードの実行、ファイルへのアクセス、外部サービスとのやり取りをユーザーに代わって行うことができる強力なツールです。これらの機能を持つあらゆるツールと同様に、適切な制御を維持しながらメリットを得るためには、慎重にデプロイすることが重要です。

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

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

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

何から保護するのか？

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

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

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

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

• 権限システム: すべてのツールとbashコマンドは、許可、ブロック、またはユーザーに承認を求めるように設定できます。globパターンを使用して「すべてのnpmコマンドを許可」や「sudoを含むコマンドをブロック」などのルールを作成できます。組織はすべてのユーザーに適用されるポリシーを設定できます。アクセス制御と権限を参照してください。
• 静的解析: bashコマンドを実行する前に、Claude Codeは静的解析を実行して潜在的にリスクのある操作を特定します。システムファイルを変更したり機密ディレクトリにアクセスしたりするコマンドはフラグが立てられ、明示的なユーザー承認が必要になります。
• Web検索の要約: 検索結果は生のコンテンツをコンテキストに直接渡すのではなく要約されるため、悪意のあるWebコンテンツからのプロンプトインジェクションのリスクが軽減されます。
• サンドボックスモード: 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は、システムコールがホストカーネルに到達する前にユーザースペースでインターセプトし、実際のカーネルを関与させずにほとんどのsyscallを処理する独自の互換性レイヤーを実装することで、この問題に対処します。

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

gVisorをDockerで使用するには、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は軽量なmicroVM分離向けに設計されており、125ms未満でVMを起動でき、メモリオーバーヘッドは5 MiB未満で、不要なデバイスエミュレーションを排除して攻撃対象面を削減します。

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

クラウドデプロイメント

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

1. インターネットゲートウェイのないプライベートサブネットでエージェントコンテナを実行
2. クラウドファイアウォールルール（AWS Security Groups、GCP VPCファイアウォール）を設定して、プロキシ以外へのすべてのエグレスをブロック
3. リクエストの検証、ドメイン許可リストの適用、認証情報の注入、外部APIへの転送を行うプロキシ（credential_injectorフィルターを備えたEnvoyなど）を実行
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サーバーまたはカスタムツールを通じてアクセスを提供します。エージェントはツールを呼び出しますが、実際の認証済みリクエストは外側で行われます—ツールは認証情報を注入するプロキシを呼び出します。

例えば、git MCPサーバーはエージェントからのコマンドを受け入れますが、ホスト上で実行されているgitプロキシに転送し、リモートリポジトリに接続する前に認証を追加します。エージェントは認証情報を見ることはありません。

利点：

• 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