VM・コンテナ・サンドボックスの隔離入門 — 何を信頼境界にするか

執筆時点: 2026-06 / 対象: 技術は法域に中立・規格と制度のみ日本国内向け / last_updated: 2026-06-10 更新履歴: 2026-06-10 初版公開

本シリーズの位置づけ: 本記事は「仕組みを理解するシリーズ」の 3 本目です。1 本目の 企業ネットワークの仕組み が「装置をどこに置くか(配置の地図)」、2 本目の 通信セキュリティの全体像 が「通信をどの層で守るか(守り方の地図)」を扱ったのに対し、本記事は「コードを どこで動かせば安全か(実行の地図)」を 1 本で俯瞰します。3 枚の地図は独立して読めますが、ネットワークの全体像が気になる場合は 1 本目から読むと立体的になります。

用語ミニ解説(はじめての方へ): 本記事で繰り返し出る言葉の最小限の説明です。

• 隔離(isolation): あるプログラムが、ホスト(自分のパソコンやサーバ)や他のプログラムに悪影響を与えられないよう、見える範囲・触れる範囲を区切ること。
• 信頼できないコード(untrusted): 中身を完全には信頼できないコード。ネットで拾った OSS スクリプト、AI が生成したコード、ユーザーが投稿したコードなど。
• 信頼境界(trust boundary): 「ここから内側は信頼する / ここから外は信頼しない」と決める境目。隔離は、この境界をどの技術で作るかという話です。
• サンドボックス(sandbox): 信頼できないコードを閉じ込めて動かすための隔離環境の総称。本記事では OS の機能で作る軽量なもの(OS サンドボックス)を指すことが多いです。
• カーネル: OS の中核。CPU・メモリ・デバイスを管理し、各プログラムからの要求を仲介する土台。
• プロセス: OS 上で実行中のプログラム 1 つ分の単位(専用のメモリ空間と権限を持つ)。
• デバイスエミュレーション: 仮想マシンが、物理ハードウェア(ディスク・ネットワーク機器など)をソフトウェアで模倣して見せる仕組み。
• サーバレス: サーバの管理をクラウドに任せ、コードの実行単位だけを意識して使う提供形態(例: AWS Lambda)。
• マルチテナント環境: 1 つの基盤を複数の利用者(テナント)で共有する構成。他人のコードと同居するため、隔離が要点になる。
• フォールバック: 本来の方法が使えないときに、別の(多くは機能を落とした)動作へ自動的に切り替えること。
• worktree(Git worktree): 1 つのリポジトリで複数の作業ディレクトリを並行して持てる Git の機能。
• subagent(サブエージェント): AI エージェントが内部で起動する補助のエージェント。
• Computer Use: AI がマウス・キーボードで PC を直接操作する仕組み。Anthropic の Computer Use ツールのほか、OpenAI も同等機能を提供します(Computer-Using Agent〔CUA〕。API の computer use ツールと、一般向けの ChatGPT Agent に統合)。

ネットで見つけたスクリプトや AI が生成したコードを「とりあえず手元で実行」していないでしょうか。実は、コードを動かす場所には VM・microVM・コンテナ・OS サンドボックス・WebAssembly という 5 つの選択肢があり、強く隔離するほど起動が遅く重くなる という一貫したトレードオフで並んでいます。本記事は、①まずこの 5 層の地図を描き ②VM とコンテナの仕組みの違いを押さえ ③「まず安全に試す」ための OS サンドボックスの使い方を整理し ④AI コーディングエージェント時代の新しい問い「このコードはどこの sandbox で動き、誰の責任か」に答え ⑤最後に制度の駆動力を置きます。製品名の暗記ではなく「信頼境界をどこに引くか」で、自分の実行環境を選べるようになりましょう。

隔離は「強度と性能のトレードオフ」— 5 層の地図

結論から言うと、隔離の選択肢は 5 層あり、「強く隔離するほど起動が遅く・リソースを食う」の一直線で並びます。まずこの地図を頭に入れると、個別の製品名がどこに属するかで整理できるようになります。

この表の使い方はシンプルです。「守りたいものの重さ」と「起動の速さ・軽さ」を秤にかけて層を選ぶ。たとえば別 OS ごと分離したいなら VM、アプリを素早く配りたいならコンテナ、1 つのプロセスだけ閉じ込めたいなら OS サンドボックス、という具合です。実務ではこれらを組み合わせることも多く、「VM の中でコンテナを動かし、その中のプロセスに OS サンドボックスを効かせる」という入れ子は珍しくありません。後述する AI コーディングエージェントの実行環境は、まさにこの入れ子の実例です。

VM とコンテナ — 仕組みの違いが隔離の違いになる

「VM とコンテナはどちらが良いか」という比較をよく見かけますが、優劣ではなく 何を共有し、何を分離するかの違い です。VM はハードウェアをエミュレートして OS ごと 分離し、コンテナは 同じカーネルを共有したまま プロセスの見える世界を分離します。この構造の差が、そのまま隔離強度と軽さの差になります。

VM — ハイパーバイザが OS ごと分離する

VM を支える ハイパーバイザ には 2 タイプあります。

• Type 1(ベアメタル): ハードウェアの直上でハイパーバイザが動く(下に OS がない)。VMware ESXi、Hyper-V(サーバ用途)、Xen が代表で、データセンターやクラウドの基盤はこちら。なお KVM は Linux カーネル自体がハイパーバイザになる構造のため、Type 1 と Type 2 の中間と分類されることもあります。
• Type 2(ホスト型): 普段の OS の上に「アプリとして」ハイパーバイザが動く。VirtualBox、VMware Workstation / Fusion、Parallels Desktop が代表で、開発機で「使い捨ての検証環境」を作る用途に向きます。

VM の強みは、ゲスト OS のカーネルまで分離されるため、ゲスト内で何が起きてもホストに波及しにくい ことです。代償として、OS 1 個分のメモリ・ディスクと数十秒〜分の起動時間がかかります。

コンテナ — カーネルを共有したままプロセスの世界を分ける

コンテナは Linux カーネルの 3 つの機能の組み合わせです。namespace(プロセスから見える世界 — プロセス一覧・ネットワーク・ファイルシステムなど — を分離する。現在 8 種類)、cgroups(CPU・メモリなどの資源量を制限する)、capabilities(root 権限を細かく分割して必要な分だけ与える)。「同じカーネルの上で、別のシステムに見せかける」技術なので 1 秒未満で起動し軽量ですが、カーネルの脆弱性を突かれると隔離ごと破られる(コンテナエスケープ)可能性が VM より構造的に高くなります。

ツールの名前は層で整理できます。開発者が触る ユーザー向けツール(高レベルランタイム)(Docker / Podman / nerdctl)→ コンテナのライフサイクルを管理する コンテナランタイム(CRI 実装)(containerd / CRI-O)→ 実際にプロセスを起動する 低レベル OCI ランタイム(runc / crun)→ Linux カーネル、という積み重ねで、互換性は OCI(Open Container Initiative) の 3 規格(runtime-spec / image-spec / distribution-spec)で標準化されています。だから Docker で作ったイメージを Podman で動かせます。

microVM — 「VM の隔離をコンテナの速さで」

両者の中間に microVM があります。デバイスエミュレーションを最小限に削った軽量 VM で、AWS が OSS 公開した Firecracker や、コンテナのインターフェースのまま VM 隔離を与える Kata Containers が代表です。起動は 100ms〜数秒で、「カーネルを共有しない強い隔離」と「サーバレス級の起動速度」を両立します。Firecracker は AWS Lambda などのサーバレス基盤で採用されており、他人のコードが同居するマルチテナント環境の隔離手段として広がっています。

OS サンドボックスと「まず安全に試す」

VM やコンテナを立てるまでもなく、1 つのプロセスだけを閉じ込めたい 場面は多くあります。ブラウザがタブごとに描画プロセスを隔離しているように、OS には「プロセス単位で権限を制限する」機能が標準で備わっています。これが OS サンドボックスです。

ここで、個人開発で最も多い 2 つの場面に当てはめてみます。

場面 1: ネットで見つけた OSS スクリプトをまず安全に試したい

• 最低限: firejail や bubblewrap でホームディレクトリへのアクセスを制限し、ネットワークを遮断して動かす
• 推奨: Docker / Podman のコンテナ内で動かす(--network none でネット遮断、-v のマウントは最小限、--read-only で書き込み禁止)
• 強隔離: VirtualBox 等の使い捨て VM で動かす(スナップショットを取っておけば、何が起きても巻き戻せる)

場面 2: 自分のサービスに「ユーザーがコードを書ける機能」を載せたい

• 最軽量: WebAssembly + WASI(Wasmtime)— ミリ秒起動でプラグイン用途に向く
• 中量: gVisor(ユーザー空間でカーネル API を肩代わりし、本物のカーネルへの攻撃面を減らす)や Kata Containers
• 最重量: Firecracker microVM — 他人同士のコードが同居するマルチテナント前提ならここまで検討
• 避ける: ホスト OS のプロセスとして直接実行する(エスケープされたら全部を失う)

共通する考え方は、「困ったら 1 段強い層に上げる」 です。隔離を強くして困ることは「遅い・重い」だけですが、弱すぎた場合に失うものはホスト環境そのものです。判断に迷うときは強い側に倒してください。なお、コンテナイメージそのものの安全性(出所・脆弱性・署名)はまた別の問題で、OSS ライセンスの記事で触れた供給網の観点が関わります。SBOM やイメージスキャンの詳細は SBOM ツールの選び方 で扱っています。

AI エージェントのサンドボックス — 信頼境界はどこか

ここからが本記事の主題です。AI コーディングエージェント(Claude Code / Codex CLI など)は、LLM が生成したコードやコマンドを あなたの環境で実行します(権限・承認の設定によっては自動で実行します)。つまり 信頼できないコードの実行が日常になります。このとき問うべきは「この実行は どこの sandbox に乗っていて、誰の責任か」です。

同じ「隔離」でも層が違う — Anthropic の例

一口に「エージェントが隔離して実行する」と言っても、実態は 1 つではありません。たとえば Anthropic のドキュメントを横断すると、"isolate" という語は文脈によって 少なくとも 5 つの異なる層 を指しています(本記事の便宜的な整理です)。

注目すべきは、worktree の分離はファイル衝突防止であってセキュリティ境界ではないこと、subagent の分離はメモリ上の文脈の分離であって OS の隔離ではないこと、そして Computer Use はユーザーが Docker / VM を用意する責任側であることです。「隔離される」と聞いたら、どの層の話か を確認するのが安全です。

両社ともクライアント側は「枯れた OS 機構」に収束

興味深いのは、Anthropic(Claude Code)と OpenAI(Codex CLI)の どちらも、手元マシンでのコード実行には macOS = Seatbelt / Linux・WSL2 = bubblewrap という同じ OS 標準のサンドボックス機構を採用 していることです(両社の公式ドキュメントに明記)。新しい隔離ランタイムを発明せず、ブラウザ等で実績を積んだ「枯れた」OS 機構を信頼する、という判断に両社が独立に到達しています。具体的には、①作業ディレクトリの外への書き込みをブロックするファイルシステム隔離 ②ネットワークの制限、の 2 つの境界が基本形です。ただしネットワーク制御の実装はベンダで異なり、Claude Code はプロキシ経由で「新しいドメインへの到達前に承認を求める」許可ドメイン方式、Codex は既定でネットワークを遮断し「オンライン接続の前に承認を求める」承認フロー方式です(固定の許可リストとは限りません)。

ただし 2 つ注意があります。第一に、この機構は 既定で常時有効とは限りません。たとえば Claude Code では有効化(/sandbox または設定)が必要で、Linux / WSL2 では依存パッケージ(bubblewrap / socat)が要ります。依存が欠けている場合、既定では 警告のうえサンドボックスなしの実行にフォールバック する挙動が公式に説明されています(厳格化する設定も用意されています)。「有効化したか」を必ず確認してください。第二に、Windows では両社に差があります。Codex は PowerShell 上で Windows ネイティブのサンドボックスを使うのに対し、Claude Code は Windows ネイティブ非対応で、WSL2 上での実行を案内しています。「同じ機構への収束」は macOS / Linux / WSL2 の範囲の話です。

クラウド側のコード実行はベンダごとに別系統

エージェントのコード実行をクラウド側に任せる選択肢(Code Interpreter 系)もあります。隔離技術はベンダごとに異なります。

導入前に点検する 8 項目チェックリスト

AI エージェントを導入するとき(個人でも組織でも)、以下を貼り付けて点検できます。

【AI エージェント sandbox 境界チェック】
□ このエージェントのコード/操作は どこの sandbox で動くか(手元 OS / クラウド / 自前 Docker・VM)
□ 機密データ(ソース・認証情報・顧客情報)は sandbox 境界の外に流れないか
□ その sandbox に既知の escape(脆弱性報告・研究)はあるか
□ prompt injection で意図と異なる動作が誘発される経路はないか・対策はあるか
□ 破壊的な操作(削除・送信・課金)の前に人間の確認が入るか
□ ネットワーク/ファイル/実行権限は最小権限になっているか(許可リスト方式か)
□ 認証情報ディレクトリ(~/.aws、~/.ssh など)を sandbox の読み取り対象から除外したか(既定では読める実装があり、明示的な読み取り拒否の設定が必要)
□ sandbox の責任分界(ベンダ / 自分 / OS / 第三者 API)をチーム(または自分)で言語化したか

このチェックリストの根底にあるのは、本記事をここまで貫いてきた問い —「何を信頼境界にするか」— です。エージェントの便利さは実行の自動化から来ますが、その自動化は「信頼できないコードの実行」と表裏一体です。境界を言語化できていれば、便利さを安心して使えます。なお、エージェントが通信する先(API・ドメイン制限)の考え方は 通信セキュリティの全体像 と地続きです。

制度の駆動力 — 日本では「調達」が基準を作る

隔離技術そのものを名指しで義務づける法律はほとんどありません。代わりに、ガイドラインと調達制度 が事実上の基準を作ります。日本での駆動力は次の 2 つです。

• ISMAP(政府情報システムのためのセキュリティ評価制度): 政府が調達するクラウドサービスの評価制度(2020 年運用開始)。ISO/IEC 27001/27017 や NIST SP 800-53 をベースにしており、コンテナや VM の隔離は専用条項ではなく一般的な管理策の中に内包されています。政府向けクラウド(ガバメントクラウド)は ISMAP 登録が条件のため、国内ベンダにとって実効的な基準になっています。
• IPA による米ガイドラインの橋渡し: コンテナセキュリティの基礎文献である米 NIST SP 800-190(Application Container Security Guide)は、IPA(情報処理推進機構)が日本語訳を公開しており、国内実務はこれを参照することが多い構図です。「米のガイドラインに追随しつつ、調達制度で実効性を持たせる」二層構造と言えます。

個人開発の範囲では、これらの制度が直接の義務になることはまずありません。ただ、企業や行政向けにサービスを提供する立場になったとき、相手の調達要件としてこれらが現れます。コンテナで提供するサービスなら NIST SP 800-190 系のチェック観点(イメージの脆弱性管理・ランタイム設定)を知っておくと、要求の意味が読めるようになります。米国(NIST / FedRAMP)と EU(Cyber Resilience Act の供給網注意義務)の駆動力は法域が異なるため、本記事の英語版で扱います。

まとめ

コードを動かす場所の隔離は、VM・microVM・コンテナ・OS サンドボックス・WebAssembly の 5 層を「強く隔離するほど遅く重い」のトレードオフで選ぶ、というのが本記事の地図でした。そして AI コーディングエージェントの時代には、「このコードはどこの sandbox で動き、誰の責任か」という問いが日常の点検項目になります。最後に、そのまま使えるチェックリストを置きます(コピーしてお使いください)。

【信頼できないコードを動かす前】
□ このコードの出所はどこか(OSS / AI 生成 / ユーザー投稿)— 信頼できない前提で扱う
□ 失っては困るものは何か(ホーム直下のファイル / 認証情報 / ネットワーク内の他マシン)
□ 隔離の層を選んだか(迷ったら 1 段強い層へ: sandbox → コンテナ → VM)
□ ネットワークを遮断 or 許可リスト化したか
□ マウント / 共有するディレクトリを最小にしたか(書き込み禁止を既定に)
□ 使い捨て(再作成可能)な環境か — 巻き戻せない環境で 信頼できないコードを動かさない

【AI エージェント導入時】
□ 8 項目チェックリスト(本文)で sandbox の場所と責任分界を点検したか
□ sandbox 機能(ファイル隔離・ドメイン制限)を有効化したか — 無効化して使っていないか
□ 破壊的操作の人間確認を残したか

関連記事: 企業ネットワークの仕組み / 通信セキュリティの全体像 / 公開前の権利チェック

出典 / References

最終確認日: 2026-06-10 / 対象法域: 技術は法域に中立。本記事の制度パートは日本国内向け(米国・EU は英語版で扱う)。

規格・カーネル機構(一次情報)

• OCI 規格(runtime-spec / image-spec / distribution-spec)
• Linux namespaces(man 7) / cgroups(man 7) / seccomp(man 2) / Landlock
• Apple — App Sandbox / Windows AppContainer / Windows Sandbox
• WASI 0.2(Bytecode Alliance) / Wasmtime

仮想化・コンテナ・サンドボックス(公式)

• Firecracker microVM / Kata Containers / gVisor
• bubblewrap / firejail / Podman
• Docker Pricing FAQ(商用利用条件)

AI エージェントのサンドボックス(公式・一次報告)

• Claude Code — Sandboxing(Anthropic) / Computer Use Tool(Anthropic) / Computer-Using Agent(OpenAI)
• Codex — Sandboxing(OpenAI)
• AWS — Bedrock AgentCore Code Interpreter(セッション分離)
• Unit 42 — AWS sandbox のネットワーク隔離回避の実証(Palo Alto Networks)
• Microsoft Foundry — Code Interpreter / Gemini Enterprise Agent Platform — Scale(Secure sandbox execution、GCP)

日本の制度(公式)

• ISMAP(政府情報システムのためのセキュリティ評価制度)
• NIST SP 800-190 — Application Container Security Guide(原文)(IPA が日本語訳を公開)

各製品名・サービス名・料金条件・制度は改称や改定で変わります。本記事は計画段階の概観であり、実装・導入の判断時は上記の一次情報で最新の仕様・適用範囲・条件を確認してください。AI エージェントのサンドボックス仕様はとくに変化が速いため、公開時点の最新を公式ドキュメントで確認することをおすすめします。

実行環境の隔離や守りをテーマ別にまとめた連載を note「セキュリティマガジン」に置いています：セキュリティマガジン。

著者について

大手電機メーカーで制御工学から 20 年以上の電機・ソフトウェア開発、加えて個人開発 約 10 年の実務経験を持ちます。ハードとソフト、企業と個人の両面で「知らないとリスクになる」基礎から発信し、いずれは AI の実践的な活用法なども扱っていく予定です。詳しくは このブログについて。