AIが書いたコードを「使い捨ての檻」で走らせる──Cloud Run サンドボックスが、エージェント実行の安全弁を数ミリ秒で配る

コーディングエージェントに「このデータを集計するスクリプトを書いて、実際に走らせて結果まで出して」と頼む場面が増えています。ここで悩ましいのが、AIがその場で生成したコードを、どこで実行するかという問題です。本番のサーバーでそのまま動かせば、環境変数に入った認証情報や外部への通信経路まで、AIの書いたコードに握らせることになりかねません。Google Cloud は 2026年7月10日、この「生成コードの実行場所」に一つの答えを出しました。ベルリンで開催中の開発者向けイベント WeAreDevelopers World Congress に合わせ、Cloud Run サンドボックスをパブリックプレビューとして公開したのです。

実行のたびに立ち上がり、終われば消える隔離空間

Cloud Run は、コードをコンテナとして動かす Google のサーバーレス基盤です。今回のサンドボックスは、その動作中のインスタンスの内側に、使い捨ての隔離された実行空間を一瞬で作る仕組みです。信頼できないコード（AIが生成したスクリプトや、利用者が投稿したプラグインなど）を、そこに閉じ込めて走らせます。

特徴は速さです。Google のデモでは、1,000個のサンドボックスを起動・実行・停止して、平均500ミリ秒という数字を示しています。起動自体はミリ秒単位で、必要になった瞬間に生成し、処理が終わればまるごと破棄する、という回し方を前提にした設計です。有効化は難しくなく、デプロイ時に --sandbox-launcher というフラグを一つ足すか、設定ファイルに一行加えるだけとされています。

「何もできない」を初期状態にする三つの壁

安全性の肝は、既定でほぼ何も触れない状態から始める点にあります。公開情報では、主に次の三つの隔離境界が挙げられています。

• 認証情報・環境の遮断: サンドボックスからは、親となる Cloud Run サービスの環境変数や、Google Cloud のメタデータサーバー（クラウド上の権限を引き出せる入り口）にアクセスできません。生成コードに鍵束を渡さない、ということです。
• 外向き通信の既定ゼロ: 外部ネットワークへの通信は初期状態で遮断され、必要な場合だけ --allow-egress で明示的に開けます。データを勝手に外へ送り出す経路を、最初から塞いでおく発想です。
• 読み取り専用のファイルシステム: コンテナのファイルは読み取り専用に見え、書き込みは一時的なメモリ上の作業領域に隔離されます。実行が終わればその変更は破棄され、痕跡が残りません。

用途としては、AIアプリのコードインタープリタ（Python や SQL などをその場で実行してデータ分析する部分）、Webを自動で調べるためのヘッドレスブラウザ、利用者が持ち込むスクリプトやWebhookの実行、といった例が示されています。いずれも「素性の知れないコードを走らせざるを得ない」場面です。

エージェント基盤にとっての意味：安全な実行環境が「部品」になる

これまで、AIが生成したコードを安全に動かすには、専用の仮想マシンを別立てで用意したり、隔離用の仕組みを自前で組んだりする必要がありました。Cloud Run サンドボックスは、その隔離を既に動いているインスタンスのCPUとメモリの中で完結させるため、Google は追加料金なし（割り当て済みの資源を使うだけ）だと説明しています。オンデマンドで仮想マシンを立てる方式に対して、コストと起動速度の両面で差をつけにいく位置づけです。

開発の段取りにも組み込みやすくなります。Google のエージェント開発キット（Agent Development Kit）の次期版では、サンドボックス上でコードを実行する仕組みが用意され、エージェントが実行環境を意識せずに「コードを書いて、隔離空間で走らせて、結果を受け取る」流れを一行で書けるとされています。エージェントが自らサブエージェントを動かしたり、計算やブラウザ操作を安全に行ったりする土台として使える、という位置づけです。

ビジネス面での読みどころと、注意すべき前提

経営・導入の視点では、これは「AIに実行させる」ことへの心理的・技術的ハードルを下げる動きです。生成AIを試作段階から本番運用へ進めるとき、最後に残る不安の一つが「AIが書いたものを勝手に動かして大丈夫か」でした。実行を使い捨ての檻に閉じ込め、既定で権限を絞る仕組みが標準機能として配られれば、内製の自動化やデータ処理にエージェントを組み込む判断がしやすくなります。

ただし、便利さの裏側は見ておく必要があります。サンドボックス化は「万能の安全装置」ではなく、被害範囲を狭めるための一枚の壁です。外向き通信を --allow-egress で開ければ、そこから情報が漏れる経路は再び生まれますし、隔離空間の中で完結する処理であっても、誤ったコードが誤った結果を出すこと自体は防げません。現時点ではプレビュー版であり、正式提供前の条件下にある点も踏まえるべきです。「どこまでの権限を、どの処理に開けるか」を運用側が設計する責任は残ります。生成コードを気軽に走らせられるようになるほど、実行する前提でリスクを設計しておく姿勢が、むしろ重要になっていくでしょう。

AIにコードを書かせる段階から、AIにコードを走らせる段階へ。その移行を支える地味な足回りとして、実行環境の隔離が「標準で付いてくる部品」になりつつあることは、覚えておく価値があります。

参照: Google Cloud Blog — Google Cloud Run sandboxes are in public preview ／ SecurityBrief — Google Cloud puts Cloud Run sandboxes into preview ／ Google Cloud Documentation — Code execution in Cloud Run