AIを動かすサンドボックスとは？｜事故を閉じ込める設計

「AIに調べものを頼むのは慣れたが、ファイルを触らせたり外部とやり取りさせたりするのは怖い」「サンドボックスで動かせと言われたけれど、何をどこまで用意したら『隔離した』ことになるのか分からない」——AIエージェントを試作から実務に移す段で、必ず出てくる声です。公開されている設計の指針を並べてみると、同じサンドボックスという言葉が、シェルの命令だけを囲う仕組みから、基本ソフトごと丸ごと分ける仕組みまでを指していることが分かります。つまりサンドボックスは、AIをおとなしくさせる道具ではありません。本当は、失敗が外へ出ていく道を、先に塞いでおくための設計です。なお、この言葉は端末に入れたソフトを試すための機能や、規制の実証枠を指すこともあります。この記事で扱うのは、AIエージェントを走らせる実行環境の隔離に限ります。方式の違い、囲える範囲、隔離が破れる条件、そして隔離環境で何をどこまで試して本番に出すかを、順に見ていきます。

サンドボックスという言葉は、3つの別のものを指している

この言葉が検索されるとき、実は3つの別物が混ざっています。1つ目は、端末に入れた怪しいソフトや添付ファイルを本体から切り離して試すための機能。2つ目は、新しい事業や技術を限定した条件で実験させる規制の枠組み。そして3つ目が、AIエージェントに手を動かさせるとき、その手が届く範囲を区切る実行環境です。この記事が扱うのは3つ目だけです。

なぜ線を引く必要があるかというと、1つ目と3つ目では守っている向きが逆だからです。端末の隔離機能は「外から来た怪しいものが、本体を壊さないように」守ります。一方でAIの実行環境の隔離は、「中で動いているAIが、正しく動こうとした結果として、触ってはいけないものに触らないように」守ります。攻撃者を止める話ではなく、任せた仕事の届く範囲を決める話です。この向きを取り違えると、「うちは端末に隔離の仕組みが入っているから大丈夫」という誤った安心にたどり着きます。

3つ目に絞ると、決めることは2つに縮まります。どこで走らせるかと、そこから何につなぐかです。以降はこの2つを軸に、方式・範囲・破れる条件・本番に出す判断の順で整理していきます。

AIに手を動かさせると、何が事故になるのか

調べて答えるだけのAIと、ファイルを書き換えたり外部に接続したりするAIでは、失敗したときの重さが変わります。手を動かすAIの事故は、だいたい3つの形に落ちます。外に出してはいけないものが外に出る、消してはいけないものが消える、そして次回も動くように何かが居座る。この3つ目が見落とされやすく、厄介です。設定ファイルや自動実行の仕掛けに一度書き込まれてしまうと、次にAIを立ち上げたときにも同じことが起きます。

引き金は攻撃だけではありません。AIは読み込んだ内容に引っ張られます。調査させた文書や取り込んだページの中に指示めいた文が混ざっていると、それを仕事の一部として取り込んでしまうことがあります。加えて、単純な取り違えもあります。似た名前のフォルダを消す、宛先を1つ間違える。人間もやることですが、AIは速く、しかも夜中に無人で動きます。

ここが設計の出発点です。AIの判断精度を上げる努力は必要ですが、それだけでは事故はゼロになりません。だから、精度と並行して起きたときに広がる範囲を先に決める。この考え方が隔離環境の全部です。AIに「安全に進めて」と判断させるのではなく、危ない道を最初から通れなくしておく。判断を任せる範囲と、環境で塞ぐ範囲を分けて考えます。

隔離の方式は、強さと重さで4段階に分かれる

実行環境の隔離には、大きく4つの層があります。強いほど重く、手間がかかります。公開されている設計指針の比較を整理すると、次のようになります。

方式	隔離の強さ	動作の重さ	用意の手間
実行環境ごと包む軽量な仕組み	安全な既定値があり十分	非常に軽い	小さい
コンテナ	設定次第	軽い	中くらい
ユーザー空間で命令を受け止める方式	正しく設定すれば非常に強い	中〜重い	中くらい
仮想マシン（マイクロVMを含む）	正しく設定すれば非常に強い	重い	中〜大きい

注目してほしいのはコンテナの行です。強さが「設定次第」と書かれています。同じコンテナでも、固め方で境界がまるで変わるという意味です。裸のコンテナは隔離というより単なる実行場所で、ネットワークの口も権限も既定のまま残っています。コンテナに入れたから安全、とは言えません。

3段目の「ユーザー空間で命令を受け止める方式」は、中で動くプログラムが基本ソフトに出す命令を、ホストの中核に届く前に横取りして自前で処理する仕組みです。ホストの中核へ直接手が届かなくなるため隔離は強くなりますが、代償があります。公式の性能の手引きでは、計算が主体の処理には目立つ遅れは出ないが、細かい命令を大量に出す処理では上乗せが大きいと説明されています。第三者が測った報告でも、時刻を取るような単純な命令で数倍、外側の受け渡し役を経由する操作ではさらに大きな差が出たとされています。毎晩まとめて動かす仕事なら許せますが、対話しながら使う場面では体感が変わります。

4段目の仮想マシンは、基本ソフトの中核ごと分けるので最も強い分離になります。近年は起動の速い小型の仮想マシンが出ていて、公式に公表されている数字では、ファイアクラッカーは125ミリ秒以下で利用者側の処理が動き出し、メモリの上乗せは5MiB以下です。不要な装置の模擬を削って攻撃される面自体を小さくしている、という設計です。「重いから無理」と決めつける前に、いまの選択肢を見直す価値はあります。

「囲える範囲」は方式ごとに違う——ここが最大の落とし穴

強さよりも先に確かめるべきは、その仕組みが何を囲っているのかです。同じサンドボックスという名前でも、囲える範囲は次のようにばらばらです。

方式	囲える範囲	用意の手間
サンドボックス版のシェル	シェルの命令とその子プロセスだけ	小さい
実行環境ごと包む仕組み	AI本体のプロセス全体（ファイル操作の道具・外部接続の部品・自動実行の仕掛けを含む）	小さい
開発用のコンテナ	開発環境の全体	中くらい
自前のコンテナ	開発環境の全体	中〜大きい
仮想マシン	基本ソフトの全体	大きい
事業者が運用するクラウド実行	基本ソフトの全体（事業者側が管理）	ほぼ不要

1行目に注目してください。シェルの命令だけを囲う方式では、AIが直接ファイルを読み書きする内蔵の道具、外部システムとつなぐ部品、そして決まった場面で勝手に走る自動実行の仕掛けは、ホスト上で制限なしに動きます。サンドボックスを有効にしたことと、AIの動きが全部囲われたことは別です。ここを混同したまま無人で走らせるのが、いちばん危ない状態です。

だからこそ、公開されている指針は「人が確認を挟まない設定で走らせるなら、コンテナか仮想マシンか、プロセス全体を包む仕組みのいずれかを使うこと」と明記しています。逆に言えば、画面を見ながら使う日常作業なら、シェル単位の軽い隔離で十分な場面も多い。人が見ているかどうかが、必要な範囲を決める分かれ目です。

これらは重ねられます。外側をコンテナで囲い、その内側でシェル単位の制限も掛ける。外側が環境の境界を作り、内側が個々の命令の範囲を絞ります。ただし重ね掛けには注意点があって、コンテナの中で入れ子に隔離を動かすために安全性を落とす設定が必要になることがあります。この点は後の章で扱います。

ファイルの隔離は、書ける場所と読める場所を別に決める

ファイル側の隔離は、書き込みと読み取りで既定が大きく違います。書き込みは厳しく、多くの実装では作業用のフォルダとその配下、それに止めたら消える一時領域だけに限られます。作業フォルダの外——シェルの起動設定ファイルや、システムの実行ファイルが置かれた場所——は、明示的に許可しない限り変えられません。

ところが読み取りは、既定では計算機のほぼ全体に及びます。公式の説明でも「この既定のままでは資格情報のファイルも読めてしまう」と注意されているほどです。つまり、書けないから安全ではない。読めるものは、外に出る口が1つあれば出ていきます。読める範囲を絞る指定を、書ける範囲とは別に自分で入れる必要があります。

実務でいちばん効くのは、範囲の指定より前の判断です。そもそも隔離環境に何をつながないかを先に決めます。接続の設定を書いたファイル、環境変数をまとめたファイル、各種の構成ファイル。これらを置いた場所を丸ごとつないでおいて、あとから読めない指定を足していく順番は、抜けが出ます。必要なファイルだけを写して渡す、という向きで組んだほうが確実です。

• 読み取りの既定は「ほぼ全部読める」。書き込み制限だけ見て安心しない
• 読み取り専用でつないだ場所からも中身は読める。つなぐ範囲そのものを絞る
• 必要なものだけを写して渡す。丸ごとつないで後から塞ぐ順番は抜けが出る

通信の隔離は、出口を1つにまとめること

ファイルよりも先に効くのが通信側です。読めたものが外へ出ていく道を塞げば、読めてしまったこと自体の重さが下がります。よく採られる設計は、許可した宛先をゼロから始めるやり方です。最初は何もつながらず、新しい宛先が必要になるたびに承認を挟んで足していく。この向きだと、許可の一覧そのものが「この仕事は外のどこと話すのか」の記録になります。

もう一段強い形は、隔離した中にネットワークの口を一つも持たせないやり方です。コンテナの構成例では、ネットワークの割り当てを外し、外側で動く中継役へつながる通信路だけを1本渡します。仮想マシンの構成例でも同じ考え方で、仮想の通信路を通してホスト側の中継役に流します。中継役は隔離の外にいるので、許可した宛先かどうかを判定し、通した記録を残せます。

クラウドで動かす場合も筋は同じです。外に出る出口を持たない区画に置き、クラウド側の通信制御で中継役以外への外向き通信を全部止め、中継役で通信を記録する。ここで押さえておきたいのは、隔離と通信の制御は、別々の2つの守りだということです。中核を分ける強い隔離を選んでも、外向きの通信が自由なら、中で読めたものはすべて持ち出せます。強い隔離は、通信制御の代わりになりません。

資源の上限と、止めたら消える作業場

隔離の話は「読み書きと通信」で終わりがちですが、実際の構成例にはもう2種類の指定が入っています。1つは資源の上限です。使えるメモリ量、割り当てる処理装置の数、作れるプロセスの数に上限を付けます。想定外の繰り返しで機械を埋め尽くす形の暴走は、悪意がなくても起きます。上限があれば、その仕事が止まるだけで済みます。

もう1つは後に残らない作業場です。根っこのファイル領域を書き換え不能にして、書けるのは止めたら消える一時領域だけにする。加えて管理者ではない利用者として動かし、権限を引き上げるのに使われる機能を落とし、使えるシステム命令の種類を絞る。こうしておくと、たとえ中で何かが仕込まれても、止めたら消える作業場ごと消えます。前章で挙げた「居座る」形の事故に効くのはこの指定です。

では成果物はどう持ち出すのか。よく使われるのは、下にある実体を書き換えず、変更分だけを別の層に溜める方式です。溜まった差分を人が見て、採用するか捨てるかを決めます。AIが直接本番の資産を書き換えるのではなく、差分を出させて人が採否を決める。隔離の技術的な仕組みと、人が確認する工程が、ここで一本につながります。

隔離が破れる条件①：許可を広げすぎる

ここから3章に分けて、隔離が破れる典型を見ます。攻撃の手口ではなく、運用の側で起きる条件の話です。1つ目は許可の広げすぎ。困ったときに範囲を1行広げる、という積み重ねで境界は薄くなります。

通信では、広い範囲をまとめて許す指定が効きすぎます。多くの中継役は、接続先が名乗ったあて名をもとに許可を判定し、既定では暗号化された通信の中身までは見ません。公式の注意書きにも、広く許した宛先が持ち出しの経路になりうること、名乗りを工作して許可外の相手に届く手口が知られていることが明記されています。広く許した1行が、隔離全体の値打ちを下げるということです。中身まで見て判定したいなら、中継役をそこまで作り込む必要があると公式に書かれています。

ファイル側も同じです。書き込みを許した場所に実行ファイルの探索先が含まれていると、そこに置かれたものが、後から別の人やシステムの処理に読まれた時点で別の権限で動きます。システムの設定を置く場所やシェルの起動設定も同じです。そしてもう1つ、外部の仕組みとやり取りするための通信口を通す指定にも注意が要ります。強い機能を持つ口を1つ通すと、その口の先にあるものを操作できてしまう場合があります。

• とりあえず広く許す：詰まるたびに範囲を1行広げ、半年後に何を許したか誰も説明できなくなる
• 実行ファイルの置き場に書けるようにする：そこに置かれたものが後から別の権限で動く道になる
• 強い機能を持つ通信口を通す：その口の先を操作できてしまい、境界の意味がなくなる
• 許可を広げた記録を残さない：戻すべき状態が分からなくなり、恒久的に広いままになる

隔離が破れる条件②：隔離が起動しないまま素通りする

2つ目が、実務でもっとも多い形です。多くの実装は、必要な部品が入っていない環境や対応していない環境では、警告を出したうえで隔離なしのまま実行を続けます。使い勝手を落とさないための親切な既定ですが、隔離を前提にした運用では、これが黙って崩れる原因になります。設定は入っている、画面には有効と出ている、しかし実際は素で動いている。

対策は1行です。起動できなかったら失敗させるという設定を明示的に立てておく。隔離をただの便利機能として使うならなくてもよいのですが、「隔離しているから無人で走らせてよい」という判断の土台にする場合、この1行がない構成は土台になりません。導入の確認項目に必ず入れる種類の設定です。

似た形がもう2つあります。1つは隔離の外で作り直して走らせる抜け道です。隔離のせいで失敗した命令を、外側で再実行する仕組みが用意されていることがあります。手元の作業では便利ですが、無人運転では禁じる設定にします。もう1つは、コンテナの中で入れ子に隔離を動かすために安全性を意図的に落とす設定です。これは外側のコンテナが本当の境界になっている場合にだけ許す、という条件付きで使うものです。条件を書き残さずに入れると、後から誰も理由を説明できなくなります。

隔離が破れる条件③：設定そのものを書き換えられる

3つ目は、境界の外側ではなく内側から崩れる形です。AI本体が起動時に読み込む設定——許可のルール、自動実行の仕掛け、外部接続の定義——に書き込めてしまうと、AIは自分の使える範囲を自分で広げられます。しかも厄介なのは、そうした仕掛けが隔離の外側で動くことです。隔離された中から、隔離されない場所で動くものを仕込める、という抜け方になります。

この形が知られているため、しっかりした実装では、書き込みを許した範囲の中であっても、これらの設定ファイルへの書き込みだけは別に拒否します。しかもその拒否は例外指定では外せず、ファイル側の隔離を丸ごと切る以外に解除する方法がありません。「便利だから1つだけ例外にする」ができないようになっているのは、そこが崩れると他の全部が意味を失うからです。

運用側の教訓は、隔離の設定は、AIが触れない場所に置くの一言です。実装側でもこの発想が徹底されていて、隔離を弱める種類の設定は「持ち込まれたプロジェクトの側の設定ファイルからは効かない」ようになっています。外から来たプロジェクトが、開いただけで隔離を解除できてはいけないからです。自社で組む場合も同じで、範囲を決める設定は管理側から配り、現場の作業フォルダの中には置かない。これだけで崩れ方が1つ減ります。

隔離しても変わらないこと

ここまで読むと隔離を万能に感じますが、公式の注意書きはむしろ逆を強調しています。隔離は影響範囲を小さくするだけで、無くしはしない。外向きの通信を許す構成なら、AIが読めたデータは漏れうる。作業フォルダを書き込み可でつないだなら、そのコードは書き換えられる。隔離は起きたことの後始末を軽くする仕組みで、起きないようにする仕組みではありません。

見落とされやすい点をもう1つ。隔離しても、AIの提供元に送られる内容は変わりません。頼んだ言葉と、AIが読んだファイルの中身は、隔離していてもいなくても外部の推論基盤へ送られます。したがって「隔離したから機密を扱わせてよい」は成り立ちません。何を読ませるかは、契約や社内規程の側で別に決める話です。ここを一緒にすると判断を誤ります。

最後に、しばしば混同される点を1つ。行為ごとに自動で危険度を判定する仕組みは、隔離の境界とは別のものです。前者は命令が走る前に文字列や文脈から判断し、後者は走っているプロセスに対して基本ソフトが強制します。だから後者は、AIが何を選んだかに関係なく効きますし、許された命令が名前以上のことをしても効きます。自動判定を隔離の代わりに数えないことです。

誰が隔離の範囲を決めるのか

ここから体制の話に移ります。隔離の設計で決めることは3つです。どの方式で走らせるか、何を読ませて何に書かせ、どこへ出させるか、そして範囲を広げたいときに誰が承認するか。1つ目は技術の判断ですが、2つ目と3つ目は業務側の判断です。ここを技術担当に丸投げすると、詰まらないほうへ、つまり広いほうへ寄っていきます。

運用でいちばん効くのは、現場が自分で広げられる範囲は、必ず広がるという前提に立つことです。悪意ではなく、締め切りのためです。だから範囲の型は管理側から配り、現場側では広げられない形にしておく。実装側にもこれを支える仕組みがあって、管理者が配った設定を現場の設定で上書きできないようにできます。ただし方式によって強制の効き方が違います。製品自身の設定として配れる方式は製品が強制できますが、コンテナに入れて動かすやり方は約束事であって境界ではありません。コンテナを使わずに動かせてしまうので、端末の管理やソフトの許可制で押さえる必要があります。

役割分担の現実的な形は、情報システム部門が「隔離の型」を数種類用意し、業務側が「この仕事にはこの型」と選ぶやり方です。たとえば、社外の資料を読ませるだけの仕事はこの型、社内の資産を書き換える仕事はこの型、というふうに。型から外れる要望が出たときだけ個別に相談する。毎回一から交渉する運用は続きません。そして記録すべきは、誰がいつどの型で走らせ、範囲を広げたなら誰が承認したかの4点です。

隔離環境で何をどこまで試すか

隔離環境は「安全にした本番」ではなく「試す場」です。何を試すのかを決めておかないと、動いたことだけを確認して本番に持っていってしまいます。次の順で通すと、抜けが減ります。

この5段のうち、飛ばされやすいのは1段目と3段目です。1段目を飛ばすと、そもそも隔離が効いていない環境で「問題なく動いた」という結論が出ます。3段目を飛ばすと、正常に終わった場合しか検証していないことになります。実務で困るのは、たいてい途中で止まったときです。

本番に出す条件を、誰が承認するのか

隔離環境で動いたことは、本番で安全だという証明にはなりません。最初にやるべきは、隔離環境と本番の差分を書き出すことです。つなぐ先が増えるのか。扱うデータの中身が変わるのか。走る頻度と時間帯が変わるのか。失敗したときに影響を受ける人が誰になるのか。この4つが変わるなら、隔離環境での結果はそのまま持っていけません。

承認は3つに分けます。範囲を決める人（その仕事の責任者）、境界を作る人（情報システム部門）、本番に出す判断をする人（決裁者）。技術の担当がまとめて背負う形にすると、「動いたから出す」に流れます。逆に決裁者だけで決めると、隔離の範囲が実務に合っているかを誰も見ません。3つの役が同じ表を見て、それぞれの観点で通す。

そして出したあとです。範囲を広げるときは、同じ承認を通す。広げた記録が残らない運用は、いつか元の無制限に戻るからです。半年に一度、許可した宛先と書き込み先の一覧を開いて、いまも必要な行かどうかを見る。使われていない行を消すのは、新しく絞るより痛みが少なく、境界を保つのに効きます。

よくある質問

コンテナに入れれば、隔離できたことになりますか

設定次第です。公開されている比較でも、コンテナの隔離の強さは「設定次第」と評価されています。ネットワークの口を持たせない、根のファイル領域を書き換え不能にする、管理者以外の利用者で動かす、権限を引き上げる機能を落とす、使えるシステム命令を絞る、資源の上限を付ける。これらを入れていないコンテナは、隔離というより単なる実行場所です。

仮想マシンにすれば、いちばん安全ですか

中核を分けられる点は強いのですが、仮想マシンなら自動的に安全というわけではありません。安全性は基盤側の実装に依存しますし、外向きの通信が自由なら、中核を分けても読めたものは持ち出せます。隔離と通信の制御は別の2つの守りです。重さの分だけ運用の手間も増えるので、扱うものの重さと釣り合うところを選びます。

開発者以外に関係のある話ですか

あります。決めることの多くは技術ではありません。何を読ませるか、どこへ出させるか、範囲を広げるときに誰が承認するか、何を記録するか。これらは業務の責任者と情報システム部門が決める話です。技術の担当に丸投げすると、詰まらないほうへ、つまり動く範囲が広い設定へ寄っていきます。

隔離すれば、機密情報を扱わせてよいのですか

別の判断です。隔離はAIの行動が及ぶ範囲を絞る仕組みで、AIに送られる内容そのものは変わりません。頼んだ言葉と読ませたファイルの中身は、隔離していても提供元の推論基盤に送られます。何を読ませてよいかは、契約と社内規程の側で決めます。隔離の設定でこの判断を代替できません。

小さく始めるなら、最初にどれを入れますか

人が画面を見ながら使うだけなら、追加の基盤が要らない軽量な仕組みから始められます。確認の手数が減り、範囲を意識する習慣もつきます。人が見ずに走らせる段に上げるときが、コンテナか仮想マシンに移る分かれ目です。判断の軸は仕事の重要度ではなく、人が見ているかどうかです。

まとめ

AIを走らせる隔離環境の要点は、どこまで囲えているかを、方式の名前ではなく範囲で確かめることです。シェルの命令だけを囲う方式では、AIが使うファイル操作の道具や外部接続の部品は外で素のまま動きます。破れる条件の大半は攻撃ではなく設定で、許可の広げすぎ、隔離が起動しないままの素通り、設定ファイルの書き換えの3つに集まります。そして隔離は影響範囲を小さくするだけで、無くしはしません。だから範囲は業務側が決め、境界は管理側が配り、人が必ず見る範囲を先に一覧にして、本番に出す条件は3つの役で承認する。まずは、いまAIに使わせている環境で「許可した宛先」と「書き込みを許した場所」を1枚に書き出してみてください。説明できない行が、そのまま抱えている範囲の広さです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。