近年、様々な規模の企業において、AIエージェントを自社プロダクトに組み込むケースが急増しています。特に、ChatGPTが提供する高度なデータ分析（旧Code Interpreter）のような、自然言語の指示からその場でPythonコードを生成・実行し、データ加工やグラフ化を行う機能への関心は非常に高いと言えます。
2026年現在、ChatGPTはGPT-5.2ファミリー（Instant、Thinking、Auto、Proの4モード）へと一本化され、旧来のGPT-4oやGPT-4.1などのモデルはUIから姿を消しました。推論能力やコンテキスト理解が飛躍的に向上し、カスタムGPTやプロジェクト機能を用いた複雑なタスクの自動化が推奨されるワークフローへと進化しています。これはユーザーにとっても開発者にとっても非常に魅力的な機能拡張です。
しかし、システム全体を俯瞰するシステムエンジニアの視点から言えば、そこには重大なリスクが潜んでいます。
「とりあえず動くプロトタイプとして、Pythonのexec()関数でAIが生成したコードをそのまま実行している」
もし、開発現場でこのような実装が行われているとすれば、一度立ち止まってシステム構成を見直すことを推奨いたします。それは、鍵のかかっていない武器庫に子供を招き入れるような非常に危険な状態です。
本記事では、AIにコードを実行させる際に不可欠となる「実行環境の隔離」について解説いたします。なぜPython標準の仮想環境では不十分なのか、なぜDockerコンテナによるサンドボックス化が必須なのか、そして安全なシステムをどう設計すべきかを論理的に紐解いていきます。
「AIが勝手にコードを実行する」リスクと現実
AIエージェント、とりわけ最新のLLM（大規模言語モデル）を組み込んだシステムにおいて、Function Callingや外部ツール連携は極めて強力な機能です。最新のGPT-5.2のThinkingモードのように、複雑な推論を経て自律的にタスクを処理するエージェント機能は利便性が高い反面、その運用には厳密な制御が求められます。
利便性の裏にある「任意コード実行」のリスク
セキュリティの領域には「RCE（Remote Code Execution：任意コード実行）」という概念があります。通常、これは攻撃者が悪意を持ってシステムに侵入し、外部から不正なコマンドを実行する致命的な脆弱性を指します。発見され次第、迅速な修正が不可欠な重大なセキュリティホールです。
AIエージェントにコード実行機能を持たせるアーキテクチャは、システム内部にこのRCEを意図的に実装することと同等のリスクを伴います。ユーザーのプロンプトに基づき、AIが動的に生成した未知のコードを、システム基盤上で実行することになるためです。
「AI自体には悪意がないから安全だ」と考えるのは早計です。
最新のモデルで精度が向上したとはいえ、AI特有の「幻覚（ハルシネーション）」を完全に排除することはできません。また、詳細なプロンプトやペルソナ指定によって意図しない挙動が引き出される可能性もあり、これがシステム全体を脅かす要因となります。
ファイル削除、情報流出、無限ループのリスク
具体的なシナリオを検証いたします。
例えば、ユーザーが「不要な一時ファイルを整理して」とAIに依頼したと仮定します。AIは、以下のようなコードを生成する可能性があります。
import os
# カレントディレクトリ以下の全ファイルを削除
os.system("rm -rf ./*")
もし、このコードが実行されるプロセスが、アプリケーションのソースコードや重要な環境設定ファイルが存在するディレクトリへのアクセス権を持っていたらどうなるでしょうか。システム全体が機能停止に陥る危険性があります。
あるいは、「サーバーの環境変数を一覧表示して」という指示に対し、AWSのシークレットキーやデータベースの認証情報を含む環境変数をそのまま出力してしまう情報流出のリスクも考えられます。最近のワークフローで推奨されるメモリ機能やコンテキストの保持により、AIが過去のセッションから機密情報を引き出してしまうケースにも注意が必要です。
さらに、悪意が全くなくても、以下のような無限ループを引き起こすコードが生成される可能性は常に存在します。
while True:
pass
これをリソース制限なしに実行すれば、CPU使用率は瞬時に100%に達し、他のユーザーからのリクエストを処理できなくなります。結果として、システムがDoS（Denial of Service）状態に陥ることになります。
開発環境で起こりうる事故
実際、開発中のローカル環境において「コンテナがフリーズした」「意図せずホスト側のデータが消去された」といったトラブルは珍しくありません。開発者のローカル端末であれば再構築で対応可能ですが、これが本番環境のサーバー、とりわけ顧客データを扱うプロダクトで発生した場合、ビジネスに致命的なダメージを与えます。
AIによるコード実行は、「出所が不確実で信頼できないコードを、インフラストラクチャ上で実行する」ことと同義です。厳重な警戒と環境の隔離が不可欠となります。
ここで有効なのがDockerコンテナによるサンドボックス化ですが、単にDockerを導入すれば安全というわけではありません。例えば、最新のセキュリティ動向を見ると、Docker Desktop 4.61.0以下に存在したgrpcfuseカーネルモジュールの脆弱性（CVE-2026-2664）に対応するため、直ちに4.62.0以降へのアップデートが推奨されています。また、コンテナ内からの/proc/dockerへのアクセス制限や、適切なリソースクォータの設定など、セキュアな設計を施した「使い捨て」の実行環境を構築することが、システム全体を防御する要となります。
なぜ「venv」や「仮想環境」では不十分なのか
ここでよくある意見が、「Pythonの仮想環境（venvやconda）を使っているから大丈夫では？」というものです。あるいは、「chrootで閉じ込めればいい」という意見も聞かれます。
しかし、venvはセキュリティのための仕組みではありません。
Python仮想環境はセキュリティ境界ではない
venv や conda の主目的は、「依存ライブラリのバージョン管理」です。プロジェクトAではPandas 1.0を使い、プロジェクトBではPandas 2.0を使う、といった競合を防ぐためのものです。
仮想環境の中にいても、実行されているプロセスはホストOSのユーザー権限で動いています。つまり、Pythonスクリプトから os モジュールや subprocess モジュールを使えば、ホストOSのファイルシステム、ネットワーク、他のプロセスに対して、実行ユーザーが持っている権限の範囲内でアクセスできてしまいます。
先ほどの rm -rf / のようなコマンドは、venvの中にいようと関係なく、実行ユーザーに権限があればホストのファイルを削除しに行きます。
ファイルシステムへのアクセス権限の問題
「じゃあ、実行ユーザーの権限を絞ればいい」と考えるかもしれません。確かにそれは重要ですが、アプリケーションサーバー上で直接コードを実行する場合、完全に安全な権限分離を行うのは非常に困難です。
AIエージェントが生成したコードが、一時ファイルを書き込む必要があったとします。その書き込み権限を与えたディレクトリから、シンボリックリンクを辿ってシステム領域にアクセスされるリスク（ディレクトリトラバーサル）や、意図しない設定ファイルの読み込みを防ぐには、OSレベルでの厳密なアクセスコントロールが必要です。
プロセス分離とリソース制限の欠如
また、venvにはCPUやメモリの使用量を制限する機能はありません。AIが生成したコードがメモリを数ギガバイト消費する処理を行った場合、ホストマシンのメモリが枯渇し、OOM Killer（Out of Memory Killer）によってデータベースなど他の重要なプロセスが強制終了させられる可能性があります。
これらを防ぐには、アプリケーションレベルの仮想化ではなく、OSレベルでのリソース隔離が必要です。ここで登場するのが、コンテナ技術です。
Dockerを「使い捨ての実験室」として利用する
推奨いたしますのは、Dockerコンテナを「アプリケーションのデプロイ先」としてではなく、「AIコード実行専用の使い捨て実験室（サンドボックス）」として利用するアーキテクチャです。
昨今のDocker Desktopの最新版では、Windows (WSL2) やNVIDIA GPU環境でのAIモデル実行サポートが強化されるなど、AIワークロードへの対応が急速に進んでいます。しかし、サンドボックス用途において最も重要なのは、その強力な「隔離性能」です。
コンテナ技術が提供する「隔離」
Docker（およびその基盤技術であるLinux Namespaceとcgroups）は、プロセスに対して以下の隔離を提供します。
- ファイルシステムの隔離 (Mount Namespace): コンテナは独自のファイルシステムを持ち、ホストのファイルシステムは見えません（明示的にマウントしない限り）。もしコンテナ内で
rm -rf /を実行しても、影響があるのはコンテナの中身だけで、ホストOSは影響を受けません。 - プロセスの隔離 (PID Namespace): コンテナ内のプロセスからは、ホスト上の他のプロセスが見えません。他のプロセスをkillしたり、メモリを覗き見たりすることはできません。
- ネットワークの隔離 (Network Namespace): 独自のネットワークスタックを持ちます。設定次第で、インターネットアクセスを完全に遮断することも可能です。
この隔離機能が、AIコード実行のリスクを抑制する役割を果たします。
ステートレス（状態を持たない）であることの重要性
Webアプリケーションやクラウドインフラの設計において「ステートレス」は重要なキーワードですが、サンドボックスにおいても重要です。
一度AIがコードを実行した環境は、何らかの形で「汚染」されている可能性があります。意図しないファイルが作成されたり、環境変数が書き換えられたり、あるいはバックグラウンドで不審なプロセスが動いていたりするかもしれません。
その環境を次の実行にも使い回すのは危険です。前の実行結果が残っていると、次の実行結果に影響を与えたり（情報のリーク）、蓄積された不要なファイルでディスクが溢れたりします。
実行のたびに新品を用意し、終われば破棄する運用
そこで、「Ephemeral（エフェメラル：短命、使い捨て）」な運用を推奨いたします。
- AIからコード実行のリクエストが来る。
- 新しいDockerコンテナを立ち上げる。
- その中でコードを実行し、結果を取得する。
- コンテナを破棄する。
このサイクルを毎回行います。Dockerの起動は仮想マシンに比べて非常に高速（数秒〜数百ミリ秒）なため、このアプローチは現実的です。
毎回「新品の実験室」を用意し、実験が終わったら「実験室ごと破棄して初期状態に戻す」。これなら、危険なコードが生成されても、被害はそのコンテナの中に限定されます。
安全なサンドボックス構築のための3つの設計原則
では、具体的にDockerを使ってサンドボックスを構築する際、どのような設定を入れるべきでしょうか。単に docker run するだけでは不十分です。以下に3つの原則を解説いたします。
ネットワーク遮断：外部への通信をどこまで許すか
原則として、サンドボックスからの外部通信は遮断すべきです。
AIが生成したコードが、外部の悪意あるサーバーにデータを送信したり、あるいはインターネット上のスクリプトをダウンロードして実行したりするのを防ぐためです。
Dockerでは --network none オプションを付与することで、コンテナからネットワークインターフェースを取り上げることができます。これにより、外部へのHTTPリクエストはもちろん、DNS解決すらできなくなります。
ただし、「pip install でライブラリを追加したい」や「外部APIからデータを取得したい」という要件がある場合は、完全遮断はできません。その場合は、プロキシサーバーを経由させてアクセス先をホワイトリストで制限するか、あらかじめ必要なライブラリを全てインストールしたDockerイメージを用意しておくアプローチが考えられます。
リソース制限：CPU・メモリ枯渇攻撃への対策
無限ループやメモリリークからホストを守るために、Dockerのリソースクォータ機能を使用します。
--memory: 使用できるメモリ上限を設定します（例:512m）。これを超えるとプロセスはkillされます。--cpus: 使用できるCPUコア数を制限します（例:0.5）。--pids-limit: 生成できるプロセス数を制限します。フォークボム（自己複製を繰り返してシステムをダウンさせる攻撃）を防ぎます。
さらに、実行時間にも制限（タイムアウト）を設けることが重要です。Python側で signal.alarm を使うのも良いですが、コンテナの外側（オーケストレーター側）で時間を計測し、一定時間を超えたら docker kill するのが確実です。
権限管理とセキュアなベースイメージ
Dockerコンテナ内のデフォルトユーザーは root です。コンテナ内とはいえ、root権限での実行はリスクを高めます。万が一、コンテナランタイム（Docker自体）に脆弱性があった場合、コンテナブレイクアウト（コンテナからの脱獄）を許してしまう恐れがあるからです。
Dockerfile内で以下のように一般ユーザーを作成し、そのユーザーで実行するように設定することを推奨いたします。
# ユーザー作成
RUN useradd -m sandboxuser
# ユーザー切り替え
USER sandboxuser
WORKDIR /home/sandboxuser
また、ベースイメージの選定もセキュリティの鍵を握ります。最新のトレンドとして、Docker社はDocker Hardened Images (DHI) のような堅牢化されたイメージの利用を推奨しています。これらは脆弱性（CVE）対応や、SBOM（ソフトウェア部品表）による構成管理が行われており、サンドボックスの土台として非常に有用です。
さらに、ファイルシステムを --read-only（読み取り専用）でマウントし、書き込みが必要な一時ディレクトリ（/tmp など）だけをボリュームとしてマウントすれば、より堅牢になります。
開発現場への導入：まずは「守れる範囲」から
完璧なサンドボックスシステムをすぐに構築するのは難しいかもしれません。Kubernetesの最新バージョンではAI/MLワークロードへのリソース管理機能が強化されていますが、Pod管理やgRPCを使った通信制御など、考慮すべき点は多くあります。
ローカル開発環境でのPoCから始める
まずは、開発者のローカル環境で小さく始めることをお勧めいたします。Pythonの docker ライブラリ（Docker SDK for Python）を使えば、PythonコードからDockerコンテナを操作できます。
「ユーザーの入力を受け取り、Dockerコンテナを起動し、そこで print("Hello") を実行して結果を受け取る」というシンプルなフローを実装してみることを推奨いたします。これだけでも、標準出力のキャプチャやタイムアウト処理、エラーハンドリングの難しさを実感できるでしょう。
また、Docker Desktopを使用する場合、docker build コマンドでのビルドプレビュー機能など、開発者向けのツールも充実してきています。こうした機能を活用し、開発サイクルの中で安全性を確認する習慣をつけることが重要です。
既存のOSSサンドボックスツールの活用検討
自前での基盤構築がリソース的に厳しい場合は、既存のソリューションの採用をご検討ください。
例えば、E2B (E2B Sandboxes) は、AIエージェント向けに特化したサンドボックス環境を提供するクラウドサービス（およびOSS）です。Code Interpreterのような機能をAPI経由で実装でき、安全な隔離環境が提供されます。
自前でKubernetesクラスタを構築・運用する場合、定期的なアップグレードやサポート切れ（EOL）への対応といった運用コストが発生します。これだけのコストを支払ってでも自前でやる理由があるのか、それともE2Bのような専用ツールにオフロードすべきか、アーキテクチャ設計の段階で冷静に判断することが求められます。
セキュリティと利便性のバランス
セキュリティを強化しすぎると、AIができることは減ってしまいます。ネットワークを完全に遮断すればWebスクレイピングはできませんし、ライブラリを厳しく制限すれば高度なデータ分析は不可能です。
ここで有効なのが、前述した信頼できるベースイメージの活用です。Docker Hardened Imagesのような、脆弱性スキャン済みでセキュリティ設定が施されたイメージを利用することで、一から設定を作り込む手間を省きつつ、一定の安全性を確保できます。
重要なのは、「何を守りたいか」を明確にすることです。顧客の機密データなのか、ホストシステム全体の可用性なのか。リスクの許容度に合わせて、サンドボックスの制限を調整することが重要です。
AIエージェントは素晴らしい技術ですが、それを支える基盤には、これまで以上に堅実なエンジニアリングが求められています。最新のツール動向を把握しつつ、まずは「使い捨て」できる安全な環境を用意することから始めてみてはいかがでしょうか。
コメント