AIエージェントのサンドボックス隔離とは、自律的にコードやツールを実行する AI エージェントを、ファイル・プロセス・ネットワークを制限した隔離環境に閉じ込め、社内データや認証情報への不正アクセスを防ぐセキュリティ手法である。エージェントが自分で判断して操作する以上、「やってはいけないこと」を指示で禁じるだけでは不十分で、環境そのもので実行できる範囲を絞る必要がある。

本記事は、日系企業で AI エージェントの導入・運用を担う情報システム／セキュリティ担当者に向けて、隔離が必要な理由から、実行環境・ネットワーク・監査ログの 3 ステップでの実装手順までを解説する。読み終えたときには、自社のエージェントに対して「何を、どの層で塞ぐか」を設計できる状態を目指す。

自律エージェントは「人間が与えた権限の範囲で、自分で判断して動く」ため、想定外の操作が起きたときの被害が大きい。 まず、自律エージェント特有の脅威と、アプリ層の制御だけでは防ぎきれない理由を押さえる。

AI エージェントは、ツール実行・ファイル読み書き・外部通信といった強力な能力を組み合わせて動く。この能力が攻撃者や誤動作によって悪用されると、主に 3 つの脅威につながる。

• データ持ち出し: エージェントがアクセスできる社内ファイルや DB の内容を、外部へ送信してしまう。
• 認証情報の窃取: 環境変数や設定ファイルに置かれた API キー・トークンを読み取り、別のシステムへ横展開される。
• 権限昇格: 実行ホスト上の脆弱性や過剰な権限を足がかりに、本来触れられないリソースへ到達する。

特に厄介なのが、間接的プロンプトインジェクションだ。エージェントが読み込んだ外部データやウェブページに悪意ある指示が埋め込まれていると、エージェントがそれを「正規の指示」と誤認して上記の操作を実行してしまう。OWASP も LLM アプリ固有のリスクを整理しており、対策の出発点としてOWASP LLM Top 10 に学ぶ AI セキュリティが参考になる。

「エージェントのプロンプトで禁止事項を指示する」「アプリのコードで操作を制限する」といったアプリ層の対策は必要だが、それだけでは防御として薄い。理由は単純で、アプリ層の制御はバグや回避策で破られうるからだ。

たとえばプロンプトでの禁止は、巧妙な指示注入で上書きされることがある。アプリのチェック漏れがあれば、想定外のファイルパスやコマンドが通ってしまう。エージェントが任意のコードを実行できる構成なら、アプリ層の前提そのものを迂回される。

だからこそ、アプリ層の「お願いベース」の制御に加えて、OS やネットワークの層で「そもそも実行できない・到達できない」状態を作る多層防御が必要になる。サンドボックス隔離は、この最下層の砦にあたる。アプリ層の安全な実装と組み合わせて初めて意味を持つ点は、LLM セキュリティ実装ガイドとあわせて理解しておきたい。

サンドボックス隔離は「ファイル」「プロセス」「ネットワーク」「権限ポリシー」の 4 つの保護ドメインで考えると整理しやすい。 それぞれが何を守るのかを先に俯瞰してから、実装手順に入る。

第一のドメインは、エージェントが触れられるファイルと実行できる処理を絞ることだ。Linux 環境では、これを OS のカーネル機能で実現できる。

• Landlock: プロセス単位でアクセスできるファイル・ディレクトリを制限する Linux のセキュリティ機構（カーネル 5.13 で導入）。SELinux などと違い root 権限が不要で、非特権プロセスでも自分自身の権限を制限できるのが特徴だ。エージェントの作業ディレクトリ以外を読めない・書けないようにする、といった制御ができる。
• seccomp: プロセスが発行できるシステムコールを絞り込む仕組み。不要なシステムコール（たとえば特定のネットワーク系や権限操作系）をブロックし、攻撃の足場を減らす。

これらは「エージェントが暴走しても、触れる範囲がそもそも狭い」状態を作るための土台になる。重要なのは、アプリケーションの善意に頼らず、カーネルが強制する点だ。アプリのバグでチェックが漏れても、Landlock や seccomp の制限はカーネル側で効き続ける。

第二のドメインは通信だ。データ持ち出しと認証情報の横展開は、多くがネットワーク経由で起こる。したがって、エージェントの実行環境からの通信を「必要な宛先だけ」に絞ることが効果的だ。

具体的には、デフォルトですべての外部通信を拒否し、業務に必要なエンドポイント（利用する LLM API、許可された社内サービスなど）だけを許可リストに加える。エージェントが外部のツールやデータソースに接続する場合も、接続先を限定する。

外部ツール連携を標準化するMCPを使う構成でも、「どのツール・どの宛先まで許すか」をネットワーク層で重ねて制御しておくと、ツール定義側の設定ミスを補える。モデル呼び出し自体も通信である以上、利用するエンドポイントを固定し、想定外の宛先への送信を遮断することが、認証情報や機密データの流出を防ぐ近道になる。

第三・第四のドメインとして、権限ポリシーを「宣言的」に定義し、最小権限で運用する考え方を据える。宣言的とは、許可・禁止のルールを設定ファイルなどに明示的に書き下し、コードのあちこちに散らばった条件分岐に頼らない、ということだ。

最小権限の原則は、「そのエージェントが業務を遂行するのに本当に必要な権限だけを与える」ことを指す。読み取りだけで足りる業務に書き込み権限を与えない、特定のディレクトリしか使わないならそこだけ許可する、といった具合だ。

宣言的ポリシー × 最小権限のメリットは 2 つある。1 つは、許可範囲が一覧で見えるためレビューと監査がしやすいこと。もう 1 つは、権限の追加・削除が設定変更で完結し、変更履歴を追えることだ。組織として運用に乗せる際の体制づくりはAgentOps（AIエージェント運用組織の設計）も参考になる。

隔離の実装に入る前に、「このエージェントは何をする権限が要るのか」と「何を守るのか」を棚卸しする。 ここを飛ばすと、隔離が緩すぎて無意味か、厳しすぎて業務が止まるかのどちらかになる。

最初に行うのは、対象エージェントの責務（何をするか）と、そのために必要な権限の洗い出しだ。次の観点で書き出すと整理しやすい。

• 読み書きするファイル・ディレクトリはどこか
• 接続する外部サービス・API はどれか
• 実行する必要のあるコマンド・ツールは何か
• 扱うデータに個人情報や機密情報が含まれるか

この棚卸しの精度が、後続の権限設計の質を決める。ありがちな失敗は「とりあえず広めに権限を渡しておく」ことで、これは最小権限の真逆だ。最初は狭めに設定し、業務が回らない部分だけを足していくほうが、結果的に安全な構成に落ち着く。把握外のエージェントが現場で増えてしまうリスクについてはShadow AI のリスクと管理も押さえておきたい。

権限の棚卸しと並行して、「守るべき資産」を特定する。エージェントの実行環境やその周辺に、漏れて困るものが置かれていないかを確認する作業だ。

• API キー・トークン・パスワードなどの認証情報
• 顧客情報・従業員情報などの個人データ
• 設計書・契約書・財務データなどの機密文書

特に認証情報は、環境変数や設定ファイルに平文で置かれていることが多く、エージェントが読み取れる位置にあると一気にリスクが高まる。シークレット管理の仕組みに分離し、エージェントの作業ディレクトリからは見えないようにするのが基本だ。ASEAN 各国で事業を展開する日系企業の場合、個人データの取り扱いは現地のデータ保護法の対象にもなる。多国展開時のガバナンス整理はASEAN 進出企業の AIガバナンス体制構築を参照してほしい。

手順 1 では、エージェントを本番環境から切り離した「使い捨ての箱」の中で動かす。 コンテナか MicroVM かの選定と、ファイル・プロセス境界の設定を行う。

実行環境の隔離は、コンテナか MicroVM のいずれかを土台にするのが一般的だ。両者は分離の強さと起動コストのトレードオフで選ぶ。

結論として、外部由来のコードや指示を扱い、強い分離が要るならば MicroVM、社内利用で起動効率を重視するならコンテナが基本線になる。 コンテナを使う場合も、ルート権限で動かさない、不要な機能（ケーパビリティ）を落とす、読み取り専用ファイルシステムを基本にする、といった締め付けを併用する。いずれの方式でも、1 タスクごとに環境を作り直して使い捨てにすると、前のタスクの汚染が次に持ち越されず安全だ。

隔離環境を用意したら、その中でさらにファイルとプロセスの境界を絞る。前述の Landlock・seccomp を使い、次のように設定していく。

• ファイル境界: エージェントの作業ディレクトリだけを読み書き可能にし、それ以外（システム領域、他ユーザーのデータ、認証情報の置き場）はアクセス不可にする。
• プロセス境界: 不要なシステムコールを seccomp で遮断し、想定外のプロセス起動や権限操作をできなくする。

設定の勘所は「許可リスト方式」で組むことだ。最初にすべてを禁止し、業務に必要な最小限だけを開ける。禁止リスト方式（危なそうなものを個別に塞ぐ）だと、塞ぎ忘れが必ず残る。設定後は、エージェントに通常業務を一通り実行させ、必要なアクセスが過不足なく許可されているか・想定外のアクセスが拒否されているかをログで確認する。

手順 2 では、エージェント環境からの通信を「デフォルト拒否＋許可リスト」で絞り込む。 データ持ち出しと認証情報の横展開は、ほぼ通信を経由するため、ここが流出対策の要になる。

ネットワークポリシーは、デフォルトで全拒否（送信方向も含む）から始める。そのうえで、業務に必要な宛先だけを許可リストに加える。

許可リストに入れる典型的な宛先は次のとおりだ。

• 利用する LLM API のエンドポイント
• エージェントが連携する社内サービス
• 取得を許可した外部データソース

許可は「ドメイン／IP」だけでなく「ポート」「プロトコル」まで含めて最小化する。広いレンジを一括許可すると、そこが流出経路になりうる。注意したいのは DNS や一見無害なサービスの扱いで、これらを無条件に許可すると、データを小分けにして外部へ送り出す経路として悪用される余地が残る。許可リストは定期的に棚卸しし、使われていない宛先は削除する運用にしておく。

ネットワークポリシー（および権限ポリシー全般）を導入する際は、いきなり全面 enforce（違反をブロック）にすると業務が止まるリスクがある。そこで、audit（違反を記録するが通す）モードと enforce モードを使い分ける。

• audit モード: まずはブロックせず、ポリシー違反を記録する。実際の業務で「何が拒否対象になるか」を可視化し、正当な通信まで巻き込んでいないかを確認する段階。
• enforce モード: audit で問題ないと確認できたら、違反を実際にブロックする本番運用へ移行する。

この段階移行により、「ポリシーが厳しすぎて業務が止まった」という事故を避けつつ、最終的には強い制御に到達できる。audit の段階で記録されたログは、許可リストの調整材料にもなる。enforce 移行後も audit ログは残し続け、想定外の通信試行を監視する。

手順 3 では、エージェントの操作を後から追える監査ログと、高リスク操作の前に人間が承認する仕組みを組み込む。 隔離で「できる範囲」を絞ったうえで、残るリスクを運用で受け止める層だ。

監査ログには、エージェントが「何をしようとし、許可されたか／拒否されたか」を記録する。最低限、次の情報を残しておきたい。

• いつ・どのエージェントが
• どの操作（ファイルアクセス・通信・コマンド実行）を試みたか
• ポリシーにより許可されたか拒否されたか
• 拒否の場合、どのルールに該当したか

この allow/deny の証跡があると、インシデント発生時の追跡（何が起きたか）と、ポリシー改善（どこが過不足か）の両方に使える。ログは改ざんされにくい場所に集約し、エージェント自身が書き換えられない構成にする。運用組織としてログを継続的に見直す体制づくりはAgentOps の設計が参考になる。

隔離とポリシーで多くは防げるが、それでも「実行はさせたいが、間違うと痛い」操作は残る。本番データの削除、外部への送信、決済や契約に関わる操作などだ。これらには人間の承認（HITL）を挟む。

設計の基本は、操作をリスクで区分することだ。

• 自動実行: 取り返しのつく低リスク操作（閲覧・下書き作成など）。
• 承認後に実行: 後戻りしにくい高リスク操作（送信・削除・確定など）。

承認フローの実装例は、ツール実行に人間の確認を組み込むラオス語 AI エージェントの MCP ツール実行と HITLが具体的だ。承認を求める操作を増やしすぎると運用が回らなくなるため、「本当に痛い操作」に絞って人間を呼ぶ設計にする。承認の判断材料として、その操作の内容と影響範囲をログとあわせて提示すると、確認役が素早く正確に判断できる。

サンドボックス隔離の導入でつまずきやすい失敗を、回避策とあわせて挙げる。

失敗 1: 隔離が緩すぎて意味がない。 「とりあえずコンテナに入れた」だけで、中では広い権限・自由な通信が許されているケース。回避策は、最小権限とデフォルト拒否を徹底し、許可リストで開けた範囲だけを使わせること。

失敗 2: 厳しすぎて業務が止まる。 必要な通信やファイルアクセスまで塞ぎ、エージェントが動かなくなるケース。回避策は、audit モードで実際の業務を走らせ、必要な許可を洗い出してから enforce に移すこと。

失敗 3: 認証情報がエージェントから見える。 環境変数や設定ファイルに平文のキーが置かれ、隔離環境内から読めてしまうケース。回避策は、シークレットを専用の管理機構に分離し、作業ディレクトリから見えなくすること。

失敗 4: ログを残していない／改ざんできる。 事故時に何が起きたか追えない、あるいはエージェント自身がログを書き換えられるケース。回避策は、監査ログを外部に集約し、書き換え不可にすること。

いずれも「設定して終わり」ではなく、運用しながら調整する前提で進めると、緩すぎ・厳しすぎの両極を避けやすい。

Q1. コンテナに入れれば十分ですか？ コンテナ化は出発点であって、それだけでは不十分なことが多い。ルート権限での実行、過剰なケーパビリティ、自由な外部通信が残っていれば、コンテナの中で被害が起こりうる。最小権限・デフォルト拒否・ファイル／プロセス境界の設定まで含めて初めて「隔離」と言える。

Q2. 小規模なチームでもここまで必要ですか？ 扱うデータの機微さで判断する。個人情報や認証情報に触れるエージェントなら、規模に関わらず最低限の隔離（最小権限・通信制限・監査ログ）は用意したい。何から手をつけるか迷う場合は中小企業の AI × サイバーリスク対策のチェックリストから始めると整理しやすい。

Q3. クラウドのマネージドサービスを使えば隔離は不要ですか？ マネージド環境でも、エージェントに与える権限・通信範囲・データアクセスの設計は利用者側の責任で残る。基盤の堅牢さと、その上で自社が組む権限設計は別物だと考え、本記事の前提整理とポリシー設計は実施したい。

Q4. 隔離するとエージェントの性能が落ちませんか？ 適切に設計すれば、業務に必要なアクセスは許可されるため、本来の業務性能はほぼ維持できる。問題になるのは性能ではなく「許可の過不足」なので、audit モードで必要なアクセスを洗い出してから enforce に移すのが現実的だ。

AI エージェントのサンドボックス隔離は、自律的に動くエージェントから社内データと認証情報を守るための土台だ。プロンプトやアプリ層の制御は破られうるため、OS・ネットワーク・権限ポリシーの層で「そもそも実行できない・到達できない」状態を作る多層防御が欠かせない。

実装は 3 つの手順に整理できる。実行環境をコンテナ／MicroVM で隔離し、ファイル・プロセス境界を絞る（手順 1）。ネットワークをデフォルト拒否＋許可リストで制御する（手順 2）。監査ログと高リスク操作の人間承認を組み込む（手順 3）。いずれも、最小権限・デフォルト拒否・audit から enforce への段階移行という共通原則の上に成り立つ。

ASEAN 各国で事業を展開する日系企業にとっては、現地のデータ保護法も踏まえた設計が求められる。当社では、AI エージェントの安全な導入とガバナンス整備を支援している。自社のエージェントに対して「どの層で何を塞ぐか」を一緒に設計したい場合は、お気軽にご相談いただきたい。