「社内の見積もり作業を効率化したくて、AIにツールを作らせたんです。動くには動くのですが、これを本番のサーバーに載せて、お客さまのデータも扱わせて、本当に大丈夫なのか。誰も自信を持って『安全です』と言えなくて、止まっています」——製造業の会社で情報システムを一人で見ている担当者から、こんな相談を受けました。動くコードができることと、そのコードを安心して本番で動かせることは、まったく別の話です。そして、この不安はきわめて正しい直感です。
生成AIやAIエージェントが書いたコードには、人が一行ずつ目視で追いきれない量と速度で生まれるという特徴があります。中には、外部に勝手に通信しようとするコード、想定外のファイルを書き換えるコード、認証情報をうっかり読み出すコードが紛れ込むこともあります。悪意がなくても、AIが「よかれと思って」危ない挙動を入れてしまう。だからこそ、「AIが書いたコードは、安全な檻の中で動かす」という設計が要ります。本記事では、2026年7月に公開プレビューへ入ったGoogleのCloud Runサンドボックスを題材に、その考え方を、開発を外注する発注者の視点で整理します。
なぜ「AIが書いたコード」は隔離して動かす必要があるのか
まず、何が怖いのかを整理します。人間のエンジニアが書いたコードは、書いた本人がレビューでき、意図も追えます。ところがAIが生成するコードは、量が多く、生成の瞬間まで中身が確定しないことがあります。とくにAIエージェントに「この作業をやって」と任せる場合、エージェントが実行時にその場でコードを書き、その場で走らせることがあります。事前に人がレビューする余地が、そもそも存在しないのです。
このとき危ないのは、そのコードが本番環境のあらゆるものに手を伸ばせてしまう状態です。データベースの接続情報、他のシステムへの通信、サーバー上のファイル——通常のプログラムと同じ権限で動けば、AIが生成した一片のコードが、本番全体を触れる立場を持ってしまいます。npmのようなパッケージの導入ですら「任意コードの実行」になりうるという話はnpm install は任意コード実行時代の記事で扱いましたが、AI生成コードはそのリスクをさらに広げます。だからこそ、「動かすが、何もできない狭い部屋の中で動かす」という発想が必要になります。
Cloud Run サンドボックスが差し出す「狭い部屋」
2026年7月、GoogleはCloud Runサンドボックスを公開プレビューとして提供し始めました。これは、信頼できないコードやAIエージェントが生成したコードを走らせるために設計された、隔離された実行環境です。要点は、この「部屋」が徹底的に狭く作られていることにあります。
| 制限のポイント | 既定の挙動 | 発注者にとっての意味 |
|---|---|---|
| 外部への通信 | 既定で拒否・許可した先だけ通す | AIコードが勝手に外へデータを送れない |
| 環境変数・認証情報 | サンドボックスからは見えない | 接続情報や鍵をAIコードに読ませない |
| ファイルシステム | 読み取り専用・変更は一時領域のみ | 本番ファイルを書き換えられない |
さらに、この部屋はミリ秒単位で立ち上がります。従来のように「隔離用の環境を別に用意して常時待機させる」やり方だと、起動の待ち時間やコストがかさみましたが、サンドボックスは呼ばれた瞬間に立ち上がり、使い終われば消えます。AIエージェントに何度もコードを実行させるような使い方でも、待たされず、かつ安全を保てる。「速さ」と「隔離」を両立させたところが、この仕組みの実務的な価値です。似た発想はプラグインの隔離実行を扱ったWASIによる安全な実行基盤の記事とも通じます。
発注者が確認すべきは「どこまで隔離されているか」
ここからが、開発を外注する側にとっての本題です。AIを使った社内ツールやシステムを外部に依頼するとき、成果物が「動くこと」だけを確認して受け取ってはいけません。確認すべきは、AIが関与するコードが、どこまで隔離された状態で動くように設計されているか、です。
具体的には、次のことを発注時に聞いてください。AIが生成・実行するコードは、本番の認証情報や他システムにアクセスできない状態で動くのか。外部への通信は既定で塞がれ、必要な通信先だけを明示的に許可する設計になっているのか。万一そのコードが暴走しても、影響がサンドボックスの中に閉じ込められるのか。これらに明確に答えられる開発パートナーは、AI時代の実行環境をきちんと設計できています。逆に「動くので大丈夫です」としか言わない相手には、注意が必要です。作って終わりではなく、危ないものを安全に走らせ続ける設計こそが、いまの受け取り基準です。
事例: AI製の社内ツールを「隔離してから本番へ」載せ替えた会社
具体例を挙げます。冒頭の製造業の会社（社名は伏せます）は、AIに作らせた見積もり支援ツールを、そのまま本番サーバーに載せる寸前でした。相談を受けて、まず止めたのは「本番と同じ権限でAI生成部分を動かすこと」です。
進め方はこうしました。ツールのうち、AIがその場でコードを生成して計算する部分だけを切り出し、外部通信を既定で塞ぎ、本番の接続情報を見せない隔離環境の中で動かすように作り替えました。人が事前に確認できる固定部分と、AIがその場で書く可変部分を分け、危ないのは後者だと割り切って、そこだけを狭い部屋に閉じ込めたのです。結果、ツールとしての使い勝手は変えずに、「AIが生成したコードが本番の機微な情報に触れる経路」を断てました。効いたのは、AIを使うのをやめたことではありません。AIが書く部分と人が確認できる部分を分け、危ない部分だけを隔離して動かしたことです。この切り分けができれば、AIの生産性を活かしながら、本番の安全は守れます。
まず「AIが実行時にコードを書く箇所」を洗い出す
AIが書いたコードを本番で動かすことへの不安は、正しい直感です。答えは「AIを使わない」ではなく、「AIが関与する部分を、何もできない狭い部屋の中で動かす」こと。Cloud Runサンドボックスのような仕組みは、その部屋を速く・安全に用意する現実的な選択肢になりました。着手するなら、まず自社のシステムの中で、AIが実行時にコードを生成・実行する箇所はどこかを洗い出してください。そこが、隔離すべき最優先の場所です。
AIに作らせたツールを本番に載せてよいか判断がつかない、AI生成コードを安全に動かす設計を外注先に正しく求めたい、既存システムのどこを隔離すべきか一緒に整理したい——そうしたご相談があれば、グリームハブの開発・AI・自動化のご相談窓口からお気軽にお問い合わせください。危ない箇所の切り分けから、隔離した実行環境の設計まで、御社のシステムにあわせてご一緒します。
