Skip to Content
Docs03. 実装コード実行サンドボックスの実装
上級sandboxcode-executionisolationmicrovm更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

コード実行サンドボックスの実装

この記事の目的

モデルが生成したコードの実行環境を、隔離強度・起動速度・運用コストのトレードオフで選定・構築できるようになります。守るべき対象の整理・実装技術の類型と比較・セッションとライフサイクル・エグレス制御・リソース制限・依存の扱い・マルチテナント複数のテナント(顧客・部門)が同一の Agent 基盤を共有する構成です。データ・設定・容量・費用を分けて設計し、認証キーを分けた場合も上流の共有上限と容量の隔離を別に確認します。での分離水準を、実装の判断として持ち帰れる状態を目指します。

対象読者

前提知識

本文

概要: 「サンドボックスを使え」の先へ

エージェントに任意のコードを実行させるなら、隔離は必須です。この「サンドボックスを使え」という原則は ツール権限設計とサンドボックス が正本です。本記事はその先——どの実装技術で隔離を実現するか——を扱います。

実装技術には、プロセス分離からコンテナ・軽量 VM・WebAssembly まで幅があり、それぞれ隔離の強さ・起動の速さ・運用の重さが違います。唯一の正解はなく、「何から何を守るか」の要件で選びます。まず守るべき対象を整理し、次に技術を選ぶ、という順序で設計します。

要件の整理(何から何を守るか)

技術を選ぶ前に、守るべき対象を明確にします。守る対象で必要な隔離強度が変わります。

  • ホストを守る: 生成コードがホスト OS を侵害・破壊しないこと。最も基本的な守りです
  • ネットワークを守る: サンドボックスから内部ネットワーク・外部へ勝手に出られないこと(エグレス制御)。データ持ち出しの経路を塞ぎます(データ漏えい対策)
  • データを守る: 実行対象以外のデータ・秘密情報にアクセスできないこと
  • 他セッション/他テナントを守る: あるセッションのコードが、別のセッション・別の顧客のデータや処理に干渉しないこと(後述のマルチテナント)
  • 生成コードは信頼しない前提: モデルが生成したコードも、外部から注入された指示で悪意あるものになりえます。「信頼できない入力」として扱うのが出発点です

実装技術の類型と比較

隔離を実現する技術には、代表的な類型があります。以下は境界を比較するための整理で、安全性の認証や一律の性能順位ではありません。起動時間はイメージ取得・初期化・ウォーム起動の条件を揃えて実測し、隔離はランタイムの設定・更新・許可した入出力まで含めて評価します。

技術主な隔離境界起動時の確認点特徴
プロセス分離(namespace / seccomp 等)ホストカーネルのアクセス制御プロセス作成・初期化OS 機能で権限・資源を絞る。カーネルは共有
コンテナnamespace 等とホストカーネルイメージ取得・展開・初期化標準のコンテナはカーネル共有。特権・マウント・システムコールを制限
強化コンテナ(ユーザー空間カーネル等)アプリ用カーネルとホストの境界ランタイム初期化・互換性gVisor 等はホストのシステムコールへの直接露出を減らす
microVM(軽量仮想マシン)仮想化・ゲストカーネルの境界ゲスト起動・スナップショット復元Firecracker 等は不要な仮想デバイスを減らす。VM 脱出や設定不備の対策は必要
WebAssembly(Wasm)線形メモリAgent が「覚えている」ように見えるデータの総称。短期記憶(コンテキスト)・作業状態・長期記憶(外部ストレージ)の 3 層に分けて設計する。・制御フローとホスト関数コンパイル・モジュール初期化外部入出力はホストが提供する機能次第。ネイティブ依存に制約
ブラウザ内/クライアント実行ブラウザ・端末側の境界ブラウザ・モジュールの起動サーバーへの持ち込みを避ける代わりに、利用者の端末・情報を保護する
マネージドサンドボックスサービスサービスが提供する境界コールド起動・待ち行列隔離の実装と責任分界を確認。権限・依存・データの管理は利用者にも残る
  • カーネル共有の弱さを理解する: 標準的なコンテナはホストのカーネルを共有します。任意コード実行では、カーネルの脆弱性を突く攻撃(コンテナからの脱出)を想定し、より強い隔離(強化コンテナ・microVM)を検討します
  • 起動時間と安全性を別々に確認する: microVM は仮想デバイスを減らすなどして起動を軽量化します。実際の起動時間や安全性は構成に依存するため、技術名だけで優劣を決めません
  • WebAssembly のホスト機能を絞る: Wasm モジュールは任意のホストメモリや OS に直接アクセスできず、外部入出力はインポートしたホスト関数や、Wasm 向けシステムインターフェース(WASI: WebAssembly System Interface)経由になります。Wasmtime の安全性設計 のように能力を制限し、広いファイル・ネットワーク権限を渡さない構成にします。許可した関数の悪用やランタイムの脆弱性まで消えるわけではありません
  • 運用コストで選ぶ: 自前で隔離基盤を作る運用コストが重いなら、マネージドサンドボックスサービスに委ねる選択肢もあります(顔ぶれは変化が速いため後述の TODO)

セッションとライフサイクル

サンドボックスを「使い捨て」にするか「永続ワークスペース」にするかは、重要な設計判断です。

  • 使い捨て(ephemeral): 1 回の実行ごとに作って捨てます。前の実行の状態が残らないため、汚染や情報の持ち越しが起きにくく、隔離の観点で安全です
  • 永続ワークスペース: セッションをまたいで状態(ファイル・インストール済みパッケージ)を保持します。反復的な作業(データ分析の続き・コーディングの継続)に便利ですが、状態が汚染・悪用されるリスクが加わります(常駐エージェントのライフサイクル管理)
  • 状態の持ち越しを設計する: 永続化するなら、何を残し・何をリセットするかを決めます。秘密情報や一時データを不用意に残さない設計にします
  • 確実に破棄する: 使い捨てでも永続でも、不要になった環境を確実に破棄し、資源とデータを残さないようにします

ネットワークとエグレス制御

サンドボックスからの通信は、既定で遮断し、必要なものだけ許可します。

リソース制限と暴走対策

生成コードは、無限ループ・メモリ枯渇・大量ファイル生成などで暴走しえます。資源に上限をかけます。

  • CPU・メモリ・実行時間の上限: 各実行に CPU・メモリ・時間の上限を課し、超えたら強制終了します。1 つの暴走が基盤全体を巻き込まないようにします
  • ディスク・ファイル数の制限: ディスク使用量・生成ファイル数にも上限をかけます
  • リトライと打ち切り: エラー時の自動リトライには回数上限を設け、直らないときは打ち切ります(ループのフィードバックと検証)

パッケージ・依存の扱い

コード実行では、外部パッケージのインストールを許すかが判断点です。

マルチテナントでの分離水準

複数の顧客・部門が同じ実行基盤を共有するなら、テナント間の分離を設計します(マルチテナント設計)。

  • テナント間を跨がせない: あるテナントのコードが、別テナントのデータ・処理に触れないよう、隔離の境界をテナント単位でも引きます。カーネル共有のコンテナでは、テナント間の分離に不安が残ります
  • 分離水準を要件で決める: 顧客データの機密性が高いなら、テナントごとに microVM・専用環境を割り当てるなど、分離水準を上げます。共有度と分離強度はトレードオフです
  • ノイジーネイバーを防ぐ: リソース制限を、テナント単位でもかけ、1 テナントの暴走が他テナントを巻き込まないようにします

実務での注意点

アンチパターン

  • 標準的なコンテナで任意コードを実行して安心する → カーネル共有でコンテナ脱出のリスク → 任意コード実行には強化コンテナ・microVM など強い隔離を検討する
  • 隔離強度だけで選び起動速度・運用を無視する → 使い物にならない/運用が破綻 → 隔離・起動・運用コストのトレードオフで選ぶ
  • 永続ワークスペースに状態を無制限に残す → 汚染・情報の持ち越し → 何を残し何をリセットするかを設計し、確実に破棄する
  • サンドボックスからのネットワークを既定で許可する → データ持ち出しの経路になる → 既定で遮断し、必要な宛先だけ許可する
  • リソース上限をかけない → 暴走が基盤全体を巻き込む → CPU・メモリ・時間・ディスクに上限をかける
  • 任意のパッケージインストールを許す → サプライチェーン攻撃の経路 → 許可リスト・事前準備済みイメージ・オフラインに絞る
  • マルチテナントでカーネル共有のまま分離する → テナント間の干渉・漏えい → 機密度に応じてテナント単位の隔離水準を上げる

チェックリスト

  • 守るべき対象(ホスト・ネットワーク・データ・他セッション/テナント)を整理したか
  • 要件に対し、隔離強度・起動レイテンシ・運用コストのトレードオフで技術を選んだか
  • 任意コード実行に、カーネル共有の弱さを踏まえた十分な隔離を選んだか
  • 使い捨て/永続の判断をし、状態の持ち越しと確実な破棄を設計したか
  • ネットワークを既定で遮断し、必要な宛先だけ許可しているか
  • CPU・メモリ・時間・ディスクにリソース上限をかけたか
  • パッケージインストールを制御し、サプライチェーンの経路を絞ったか
  • マルチテナントで、機密度に応じたテナント間の分離水準を設計したか

関連トピック

参考資料

  • gVisor — Documentation  — ユーザー空間のアプリケーションカーネルによる隔離の境界(アクセス日: 2026-09-10)
  • Firecracker  — KVM による microVM と仮想デバイス削減の設計。公開の起動性能を自社構成の保証値には使いません(アクセス日: 2026-09-10)
  • Wasmtime — Security  — Wasm のメモリ・制御フローの隔離、ホスト関数、WASI の能力制御と残存リスク(アクセス日: 2026-09-10)

TODO・未確認事項

ローカル・オンデバイス LLM の実務エージェント間連携プロトコル