AIエージェントに専用PC又はクラウド上の実行環境を与える場合，「サンドボックスで動かしている」という一語だけでは，何をどこまで隔離できているかは分からない。OSユーザー，コンテナ，gVisor等のアプリケーションカーネル，MicroVM，書込み可能フォルダ，外部通信，資格情報及び永続データは，それぞれ別の境界である。
法律事務所では，採用した技術の名称よりも，①何を守るのか，②どの処理を信用しないのか，③どこまで読取り・書込み・送信を許すのか，④事故後に何を読み戻し，復旧できるのかを案件ごとに固定する必要がある。
第１ 本記事の対象と結論
本記事は，AIエージェントがコマンド又はツールを実行する環境を，法律事務所がどのように区切るかを扱う。特定製品の導入を推奨するものではなく，コンテナ，gVisor及びMicroVMの優劣を一つの順位に並べるものでもない。
結論として，安全性は単一の技術ではなく，次の境界の組合せで考える必要がある。
- 実行環境とホストOSとの境界
- 読めるファイルと書き込めるファイルの境界
- 接続できる外部ネットワークの境界
- 利用できるアカウント及び資格情報の境界
- 実行終了後に残るデータと削除されるデータの境界
- AI自身が変更できないログ，バックアップ及び停止手段
また，スナップショット又はチェックポイントは復旧に有用であるが，それだけで証拠の真正性又は取得後の無変更を証明するものではない。
第２ サンドボックスという名称だけでは安全性は分からない
サンドボックスは，実行できる処理又は到達できる資源を限定した環境の総称である。同じ名称でも，OSのアクセス制御を利用するもの，コンテナを利用するもの，システムコールを仲介するもの，仮想マシンを利用するもの等がある。
OpenAIのWindows版Codexに関する公式技術記事は，書込み可能範囲と外部通信を制限するため，専用のローカルユーザー，制限付きトークン，アクセス制御リスト及びファイアウォール規則を組み合わせた設計を説明している。これは同製品の公表された実装を確認する資料であり，あらゆるAIエージェント又は法律事務所で同じ安全性が得られることを証明するものではない。
また，AI Engineerの修正版講演記録は，大規模なAIエージェント用サンドボックス基盤を設計した講演者の説明を確認する資料である。講演者の経験及び設計思想の原資料ではあるが，第三者環境での一般的な効果又は日本法上の義務を証明する資料ではない。
第３ 実行環境の境界を四層に分ける
１ OSユーザーとアクセス権
専用のOSユーザーを用い，管理者権限を与えず，作業フォルダだけを書込み可能にする方法は，通常の業務端末の中でも実装できる。既存のソフトウェア及びファイルを利用しやすい反面，読取り可能な場所，継承されたアクセス権，ブラウザープロファイル及び保存済み資格情報を個別に確認しなければならない。
専用ユーザーを作ったことと，そのユーザーから依頼者ファイル，メール，クラウドストレージ又は本番システムへ到達できないことは同じではない。
２ コンテナ
コンテナは，プロセス，ファイルシステム及びネットワーク等を分けて実行環境を作ることができる。他方，一般的なコンテナはホスト側のカーネルを利用するため，別のゲストカーネルを持つ仮想マシンとは境界が異なる。設定によってホストのディレクトリ，ソケット又はネットワークを共有すれば，その部分は隔離されない。
したがって，「コンテナ内である」ことより，マウントしたディレクトリ，権限，ネットワークモード，実行ユーザー及びホスト側ソケットの有無を確認する必要がある。
３ gVisor等のアプリケーションカーネル
gVisorの公式資料によれば，gVisorはユーザー空間で動くSentryがアプリケーションのシステムコールを受け，Linuxのシステムコール，メモリ管理，ファイルシステム及びネットワーク機能等を実装する。アプリケーションからホストカーネルへの直接の接触面を小さくする考え方である。
もっとも，gVisor自身も限定されたホストのシステムコールを用い，未実装の機能による互換性の制約及びシステムコール処理の負荷があり得る。gVisorの公式資料も，サンドボックスは安全なシステム全体の設計を置き換えるものではないとしている。
４ MicroVM
MicroVMは，軽量な仮想マシンモニターを用い，実行環境ごとにゲストカーネルを持たせる方式である。AWSは，Firecrackerについて，サーバーレス及びコンテナ向けに最小限のデバイス構成を備えた軽量な仮想化技術として説明している。
別のゲストカーネルを持つことは境界を強める方向に働くが，イメージの管理，起動，ネットワーク，ディスク，スナップショット，更新及びホストとの接続を別に設計する必要がある。Cloud Hypervisorの公式API資料も，VMの作成，起動，停止，ディスク及びネットワークの追加並びにスナップショット及び復元を別々の操作として示している。
第４ ファイル，通信，資格情報及び永続化を別々に制限する
１ 読取りと書込み
AIエージェントが資料を読む必要があることから，事務所内の全資料を書き換えられることは導かれない。公開資料又は対象案件の複製を読める範囲とし，書込みは案件内の作業フォルダへ限定する方法が考えられる。
原本，確定版，期限台帳，提出済み書面及び事務所全体の共有フォルダは，通常の作業領域から分ける。上書きが必要な場合も，対象，変更前後，根拠及び承認者を記録し，保存後の値を読み戻す。
２ 外部通信と資格情報
外部通信を禁止しても，すでに作業環境へ置かれた資格情報又は共有フォルダへの書込みによる被害は残り得る。反対に，資格情報を置かなくても，自由な外部通信を許せば，秘密情報の送信経路が生じ得る。
そこで，外部通信は必要な接続先に限定し，メール送信，裁判所提出，WordPress公開，決済及び権限変更に用いる資格情報を通常の実行環境へ常置しない。ログインできる状態と，当該操作を行う承認があることも分ける。
３ 永続化，保存期間及び削除
実行終了時に環境を破棄しても，接続したクラウド，バックアップ，ログ，キャッシュ又はスナップショットにデータが残る場合がある。反対に，全てを直ちに消すと，事故調査，作業の再開又は提出物の作成経緯を確認できないことがある。
案件ごとに，作業用データ，記録原本，監査ログ，バックアップ及び一時キャッシュを分け，保存場所，保存期間，削除方法，削除権限及び復元可能期間を決める必要がある。
第５ スナップショットによる復旧と証拠保全を混同しない
１ 復旧及び二重実行防止
スナップショット又はチェックポイントは，処理前後の状態を分け，失敗後に直前の確定状態へ戻るために有用である。保存，送信又は公開の直後に接続が切れた場合も，外部結果と保存済み値を先に読み戻し，実行済みかどうかを判定することで二重実行を防ぎやすくなる。
もっとも，復元できることと，復元後の状態が法令，製品仕様又は現在の外部サービスに適合することは別である。ソフトウェアの版が変われば古いスナップショットを復元できないこともあるため，復旧手順を定期的に試す必要がある。
２ 証拠として残す場合
業務用スナップショットは，取得後の変更を防ぐ保存媒体，取得経路及び保管者を当然には示さない。証拠として用いる可能性があるウェブページ，電子メール，ログ又はファイルについては，取得元，取得日時，取得方法，原本又は写しの別，ハッシュ値，保管場所，変更履歴及び再取得可能性を別に記録する。
スナップショットの存在だけを理由に「証拠保全済み」とせず，業務復旧の記録と，裁判又は事故調査で提示する証拠の取得・保管記録を分ける。
第６ 法律事務所の規程及び案件管理へ落とし込む
１ 弁護士情報セキュリティ規程との関係
日本弁護士連合会の弁護士情報セキュリティ規程は，弁護士等に対し，取り扱う情報の重要度及びリスクに応じた基本的な取扱方法を定め，適切な人的，物理的及び技術的安全管理措置を講じること等を求めている。また，事故時には，影響範囲の把握，被害拡大防止，原因調査及び再発防止策の検討等を行うものとしている。
同規程は，コンテナ，gVisor又はMicroVMの採用を個別に義務付けるものではない。どの方式を選ぶ場合も，案件の情報，端末，アカウント，ネットワーク，ログ，停止及び復旧を含む取扱方法として具体化する必要がある。
また，弁護士法23条の秘密保持義務及び個人情報保護委員会の生成AIに関する注意喚起は，入力情報，利用目的，学習利用等の確認に関係するが，特定のサンドボックス製品が法的に十分であることを認証するものではない。
２ 案件ごとのAI作業許可票
AIエージェントを動かす前に，次の事項を案件又は作業ごとに固定する方法が考えられる。
- 目的，成果物及び基準時
- 参照可能な資料と入力禁止情報
- 利用する実行環境と隔離方式
- 読取り可能な場所と書込み可能な場所
- 外部通信先と利用可能な資格情報
- 禁止する操作と人の承認を要する操作
- 永続化するデータ，保存期間及び削除方法
- ログ，バックアップ及び復旧地点
- 異常時の停止・報告条件
- 完了を証明する読戻し及び確認方法
第７ どの隔離方式を選ぶか
隔離方式は，名称の強さではなく，処理する情報と失敗時の影響から選ぶ。公開情報の検索及びローカル下書きであれば，書込み先及び通信先を限定したOSのアクセス制御で足りることがある。第三者のコード又は信頼できないファイルを実行する場合は，ホストカーネルへの接触面を減らすgVisor又は別ゲストカーネルを持つMicroVMを検討する余地がある。
他方，強い隔離方式を採用しても，本番資格情報を渡し，外部通信を無制限にし，全案件の共有フォルダを接続すれば，被害範囲は広がる。実行環境の隔離と，データ，ネットワーク，資格情報及び承認の制限を組み合わせる必要がある。
第８ 本記事の限界及び裁判例の確認状態
本記事で参照したgVisor，Firecracker，Cloud Hypervisor及びOpenAIの資料は，各提供者又は開発主体が自らの実装及び設計を説明する技術一次資料である。当該構造又は公表内容の確認には用いることができるが，他の環境における安全性，日本法への適合又は事故時の責任を直接証明するものではない。
本記事の中心は技術構造及び法律事務所の運用設計であり，特定の日本法上の裁判例命題を掲げていないため，作成に当たり判例秘書の検索は実施していない。このことは，AIエージェント，情報漏えい又は電子証拠に関連する裁判例が存在しないことを意味しない。具体的事故の責任又は証拠能力を検討する場合は，事実関係と争点を固定して別途検索する必要がある。
第９ 関連記事
①法律事務所がAIエージェントに専用PCを与えるときの安全設計－全権委任，承認疲れ，最小権限及び敬語の限界（AI作成）
②法律事務所のAIエージェント業務設計－目的・コンテキスト・権限・完了条件をどう分けるか（AI作成）
③法律事務所の生成AI利用ガイドラインの作り方－許可サービス，入力情報，出力確認，委託先及び事故対応（AI作成）
④OpenAIの「AI暴走」と700のAIエージェント――2026年7月のHugging Face侵入事件の実態（AI作成）
第１０ 出典・参考資料
①日本弁護士連合会「弁護士情報セキュリティ規程」（令和4年6月10日会規第117号）
②e-Gov法令検索「弁護士法」23条
③個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（令和5年6月2日）
④OpenAI「Building a safe, effective sandbox to enable Codex on Windows」（令和8年5月13日）
⑤gVisor「Introduction to gVisor security」
⑥gVisor「Security Model」
⑦AWS「Firecracker – Lightweight Virtualization for Serverless Computing」
⑧Cloud Hypervisor「API」
⑨AI Engineer「From fork() to Fleet: Designing an Agent Sandbox Cloud」修正版（調査の起点及び講演者の説明を確認する資料）