9月5日、Balaji Subramaniamが「Solving the AI repair loop dilemma using sandboxes on Cloud Run」と題した記事を公開した。この記事では、AIコーディングエージェントが生成したコードを安全かつ高速に実行するため、Google Cloud Runのサンドボックス機能を使って「修復ループ」を実装する手法について詳しく紹介されている。
AIコーディングエージェントの「修復ループ」とは何か
コーディングエージェントは最初の試みで完璧なコードを生成するわけではない。一般的なフローは「コード生成 → テスト実行 → エラー検出 → 修正」を繰り返すフィードバックループ（修復ループ）だ。問題はその「テスト実行」をどこで行うか、という点にある。
選択肢は従来2つしかなかった。
- 共有コンテナ内で実行：100ms未満と高速だが、モデルが生成した悪意あるコード（あるいは幻覚によるミスコード）がホスト環境のファイルを削除したり、GCPのメタデータサーバーへアクセスしてサービスアカウントのトークンを盗んだりするリスクがある
- コンテナを都度起動：分離は強固だが、コールドスタートに1〜5秒かかる。4ターンの修復サイクルでは合計20秒ものウェイトが発生する
この二択のジレンマを解消するのが、Google Cloud Runサンドボックスだ。
コード実行サンドボックスの技術的文脈
AIエージェントによるコード実行の安全な隔離は、Cloud Run固有の課題ではない。業界では従来、gVisor（Googleが開発したユーザー空間カーネル）やFirecracker（AWSが開発したマイクロVM）が軽量な分離の選択肢として注目されてきた。gVisorはシステムコールをインターセプトすることでカーネル攻撃面を縮小し、FirecrackerはmicroVMを125ms程度で起動することで速度と分離のバランスを狙う。
Cloud Runサンドボックスはこれらとアーキテクチャ上の思想を共有しつつ、既存のCloud Runインスタンスのリソースをそのまま流用することでプロビジョニングのオーバーヘッドを大幅に削減している。すでにCloud Run上でエージェントを動かしている開発者にとっては、インフラを追加せずに分離された実行環境を得られる点が最大の利点だ。
Cloud Runサンドボックスの仕組み
Cloud Runサンドボックスは、既存のCloud Runインスタンス内部で仮想化された実行環境を起動する。VM自体のプロビジョニングが不要なため、起動時間は500ms未満に抑えられる。また、インスタンスにすでに割り当てられたCPU・メモリを共有するため、追加コストも発生しない。
セキュリティ面では、以下の制約がデフォルトで適用される：
- クラウドメタデータサーバーへのアクセスをブロック
- ホストの環境変数を除去
- アウトバウンドネットワークをすべて遮断（
--allow-egressで明示的に許可した場合のみ有効） - ファイルシステムへの書き込みは一時的なメモリオーバーレイ上のみで行われ、プロセス終了後にホストコンテナは元の状態に戻る
記事中の検証では、1000個のCloud Runサンドボックスに対して非信頼Pythonコードを並列送信し、平均500msで処理が完了したことが示されている。
実装：修復ループの構成
実際のアーキテクチャは、Google ADK（Agent Development Kit）とCloud Runサンドボックスを組み合わせる形で構築されている。
Cloud Runコンテナ内では、サンドボックスランタイムが /usr/local/gcp/bin/sandbox というCLIバイナリとして提供される。修復ループの各ターンは以下の流れで動く：
- エージェントが生成したコードを隔離されたディレクトリに書き込む
execute_sandbox_command()がサンドボックス内でpytestを実行- テストが失敗した場合、stderrを取得してモデルへのフィードバックターンを生成
- テストが通るか反復上限に達するまで繰り返す
ローカル開発環境向けには、サンドボックスが利用できない場合の自動フォールバック機能もPythonランナーモジュールに組み込まれている点が実用的だ。
デプロイ方法
サンドボックスを有効化するには、Cloud Runサービスまたはジョブのデプロイ時に専用のフラグを付与する。元記事のコマンド例に沿って確認することを推奨するが、基本的な手順は以下の通りだ。
# リポジトリのクローン
git clone https://github.com/balajismaniam/adk-harness-engineering
cd cloud-run-sandbox
.envファイルにプロジェクトIDを設定後、Cloud Runへデプロイする。デプロイ後は /usr/local/gcp/bin/sandbox バイナリが自動的にマウントされ、エージェントのワークフローからオンデマンドでサンドボックスを起動できるようになる。具体的なフラグ名やオプションの完全なコマンド例は、元記事およびサンプルリポジトリで確認されたい。
まとめ
「セキュリティか速度か」という従来のトレードオフに対し、Cloud Runサンドボックスは500ms未満の起動時間で、クラウド認証情報・環境変数・ファイルシステムをホストから完全に切り離した実行環境を提供することで両立を可能にしている。この分離モデルは、gVisorやFirecrackerと同様にホスト侵害のリスクを根本から断つアプローチであり、既存インスタンスのリソースを流用するため追加コストも不要だ。AIコーディングエージェントのハーネス構築における実用的な選択肢となる。
詳細はSolving the AI repair loop dilemma using sandboxes on Cloud Runを参照していただきたい。
