サンドボックス化されたコードエージェント：モデルに自由な行動を許さず、コードを実行させる方法

AIモデルにコード実行能力を与えることは、最も効果的なアップグレードの一つです。10万行のデータをコンテキストに読み込ませる代わりに、エージェントがコードを書いて計算させることができます。モデルにファイル変換を考えさせる代わりに、パーサーを実行させることができます。曖昧な提案を返す代わりに、成果物を作成してテストまで行うことが可能です。

しかし、これはAIシステムが「単なるテキスト」ではなくなる瞬間でもあります。コードはファイルの読み取り、ソケットのオープン、CPUの消費、プロセスのフォーク、環境変数の検査、そしてランタイムが到達可能なあらゆる場所の改変が可能です。正しい本番環境のパターンは「モデルをより信頼する」ことではなく、 モデルに小さなコンピュータを与えることです。

1. サンドボックスの境界

agent
  ↓
ephemeral workspace
  ├─ filesystem: scoped
  ├─ CPU / memory: bounded
  ├─ runtime: code + shell
  ├─ network: deny / allowlist
  ├─ secrets: none by default
  └─ artifacts: explicit export
          ↓
     governed tool boundary
          ↓
   approval / policy
          ↓
   external side effect

ファイルシステム

ホストのファイルシステムではなく、実行用のワークスペースを与えてください。必要な入力のみをマウントし、機密性の高いホストパスにはアクセスできないようにします。成果物のエクスポートは明示的に行う必要があり、「エージェントがファイルを作成した」ことが「エージェントがどこにでも書き込める」ことを意味しないようにします。

ネットワーク

ネットワークアクセスは「機能」として扱うべきです。多くの分析タスクでは、外部ネットワークは全く必要ありません。必要な場合でも、許可リスト（allowlist）による制御が求められます。広範な外部通信を許可すると、任意のコード実行がデータ流出経路に変わってしまう恐れがあります。

シークレット

長期間有効なプロバイダーの認証情報やビジネス上の機密情報を、デフォルトでサンドボックス環境に注入しないでください。エージェントが外部機能を利用する必要がある場合は、サンドボックス外で認証を行い、必要な最小限の操作のみを公開する管理されたツールを使用することを推奨します。

時間とリソース

実行時間、CPU、メモリ、プロセス数、出力サイズに制限を設けてください。これらがないと、意図しない無限ループや無制限のデータ拡張が、単なるエージェントの失敗ではなく、インフラ障害に発展してしまいます。

成果物の受け渡し

作成と実行（結果の適用）を分離してください。サンドボックスはパッチ、レポート、画像、SQLファイル、デプロイ計画などを生成できます。その成果物を公開または適用するかどうかは、その後のポリシーや承認ステップで判断します。

機能ごとにサンドボックスの脅威モデルを構築する

「サンドボックス化」は二者択一の状態ではありません。プロセスに与えられる機能を列挙してください：読み書き可能なパス、外部への接続先、パッケージのインストール、サブプロセスの作成、カーネル機能、環境変数、マウントされた認証情報、最大実行時間などです。セキュリティ体制とは、コンテナのラベルではなく、これらの機能の組み合わせによって決まります。

例えば、ホストマウントがなくても、インターネット接続とクラウド認証情報が制限されていないワークスペースは、データの流出やインフラの改変が可能です。逆に、ネットワークが遮断されていても、書き込み可能な本番ボリュームがあれば損害を与えることができます。有用な設計成果物とは、各クラスのエージェントジョブが何を実行できるかを明確に示す機能マトリックスです。

直接的な変更よりもアーティファクトの昇格を優先する

コードエージェントによるタスクの多くは、本番環境への直接アクセスを必要としません。エージェントにはサンドボックス内でパッチ、ノートブック、レポート、移行計画、デプロイメントマニフェスト、あるいは変換済みデータセットを作成させましょう。その後、そのアーティファクトを別のレビュープロセスを経て昇格させます。これにより、決定論的なテストやポリシーチェック、そして人間によるレビューを、影響が出る前に実行できる自然なチェックポイントが生まれます。

このパターンはソフトウェア開発において特に有効です。パッチの生成 → サンドボックスでのテスト実行 → diffとテスト結果の出力 → 承認 → 管理されたリポジトリやデプロイツールを通じた適用、という流れです。これにより、エージェントは本番環境に対する権限を持たせることなく、計算処理において高い自律性を発揮できるようになります。

パッケージのインストールもコード実行である

パッケージを自由にインストールできるエージェントは、任意のサードパーティ製インストールスクリプトを実行し、ネットワークの攻撃対象領域を拡大させる可能性があります。本番環境のサンドボックスでは、精査されたベースイメージ、固定された依存関係セット、許可リスト化されたパッケージソース、あるいは明示的なパッケージインストールポリシーを使用すべきです。「必要なものは何でもpip installする」という利便性は、リスクの低い一時的な作業には適していますが、それは意識的な選択であるべきです。

実行内容を再現できる十分な証拠を記録する

サンドボックスのイメージやランタイムのバージョン、入力アーティファクトの識別子、実行されたコマンドやコードセル、終了ステータス、生成されたアーティファクトのハッシュ、および管理された外部呼び出しを保存してください。バイト単位での完全な再現が常に実用的とは限りませんが、運用担当者は何が実行され、どの出力がサンドボックスの境界を越えたのかを説明できる必要があります。

2. TrueFoundryの役割：ハーネス内のサンドボックス、その外側の権限管理

TrueFoundryの Agent Harness は、サンドボックス化された実行を、コンテキスト管理、承認、ツール実行、トレーシングと並ぶ、モデル周辺のランタイムの一部として扱います。これにより、コード実行は自動化とコンテキスト制御の両面で有用なものとなります。つまり、かさばる中間データをモデルのやり取りのたびにコピーするのではなく、ワークスペース内で直接処理できるようになるのです。

外部へのアクションは、 MCP Gatewayを通じて行うのが最適です。ここでは、ツールの認証情報、アクセス制御、実行前後のガードレール、および承認プロセスが一元管理されます。 Agent Registry はエージェントのアイデンティティや所有者コンテキストを提供し、エンドツーエンドのトレースによってサンドボックス内での作業とモデルやツールのステップを関連付けます。

アーキテクチャ上のポイントは分離です。 サンドボックスはエージェントが計算を行う場所であり、ゲートウェイはエージェントが他のシステムに影響を与えるための権限を得る場所です。

3. 境界線を明確にする

サンドボックスは被害範囲を限定するものであり、任意のコードを信頼できるものに変えるわけではありません。カーネルやコンテナからの脱出、依存関係のリスク、過剰な権限、ネットワークへの露出といった問題は依然として存在します。高度な保証が求められる環境では、標準的なコンテナよりも強力な分離が必要になる場合があります。

また、すべてのエージェントにコード実行機能が必要なわけではありません。3つの明確に定義されたAPIを呼び出すだけのワークフローにシェルを追加しても、機能はほとんど向上せず、攻撃対象領域が広がるだけです。問題を解決するために必要な最小限の実行環境を使用してください。

参考文献

• TrueFoundry: エージェントハーネスとは？.
• TrueFoundry: JITコンテキスト.
• TrueFoundry MCPゲートウェイ.
• TrueFoundry ガードレール.
• TrueFoundry エージェントレジストリ.

サンドボックス化は多層防御の一環であり、安全性を保証するものではありません。分離の強度は、対象となるコード、データ、ネットワーク、および下流システムの機密性に合わせて調整する必要があります。

‍