AIエージェントの実行環境を、OSの視点から整理してみた
本文の状態
日本語全文を表示中
詳細モードで約12分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Algomatic Tech Blog
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
株式会社 Algomatic の藤崎（@yuufdev）です。
今回は「Algomatic 初夏のアドベントカレンダー」、メンバー各々が好きな技術を語る会の 4 日目です。アドベントカレンダーを通して、Algomatic のエンジニアチームがどんな技術に関心を持っているのか、少しでも伝われば嬉しいです。
前回の記事はこちらです。
普段は、AI エージェントをエンタープライズ企業に導入する PoC（概念実証）やシステム開発に携わっています。そこでよく考えているのが、エージェントが実行するコマンドや生成コードを、どこまで通し、どこで止め、何を記録するかという線引きです。
AI エージェントの話は、たいていモデルやプロンプト、ツール設計が中心になります。それも大事なんですが、エージェントが実際に npm install を叩き、ファイルを書き換え、ブラウザや外部 API（Application Programming Interface）に触り始めると、最後に効いてくるのは OS の境界のほうでした。
この記事では、AI エージェントの実行環境を「どこで走らせるか」で整理しながら、その下で OS やカーネルが何をしているのかを振り返ります。
この記事の 3 行まとめ
- AI エージェントが実際にコマンドを動かす時代になり、効くのはモデルの賢さより、ハーネスと実行環境のほうになった。
- 今回はそのうち実行環境に絞って、サンドボックスの種類や、OS・仮想化が持つ隔離の仕組みとパターンを整理してみた。
- どれも OS が昔から続けてきた「信頼できないコードを隔てる」仕組みを活用している。新しいのは相手がエージェントになったことだけ。
その一行が、どこで走っているのか
エージェントが「依存を入れてテストして」と判断し、npm install を実行する。ただの一行ですが、これが何の制約もなくホスト上で走ることもあれば、何重にも隔離された中で走ることもあります。まず、その下で OS が何をしているかを覗いてみます。
その一行は、最初に一つのプロセスになります。shell やランタイムが fork / exec に近い流れで起動し、npm install 自体もファイルを読み書きし、ネットワークへ出て、postinstall script のような別のプロセスまで動かす。動き出したあと、このプロセスをどこまで走らせるかを握っているのがカーネルです。
CPU をいつ割り当てられるかは scheduler（スケジューラ）次第で、並列するジョブが増えれば取り合いになります。だから「遅い」原因はモデルとは限らず、スケジューリングや周辺負荷にあることもあります（Linux 6.6 は 2023 年 10 月に通常タスクの既定を CFS から EEVDF に変更しました）。
使用可能なメモリや CPU リソースは cgroup の上限によって制限され、メモリ不足となれば OOM killer がプロセスを強制終了します。「テストが途中で落ちた」の正体がコード自体ではなく単なるメモリ上限だった、というケースもよくあります。呼び出せる system call も seccomp によって絞り込まれ、許可されないものは EPERM エラーで弾かれます。ただし、seccomp 単体では sandbox にはならず、namespace や cgroup、capabilities と組み合わせて、カーネルにアクセス可能な範囲を狭めるための部品として機能します。
エージェントが「遅い」「途中で kill された」「権限エラーで弾かれた」と詰まるとき、原因の多くはモデルの出力ではなく、カーネルがこのプロセスをどのように実行し、どこで停止させるかにあります。どこで止まったかを確認すれば、修正すべき場所も変わります。
なぜ境界がいくつもあるのか。OS の仕事を一言で言えば、アプリとハードウェアの間に立ち、プロセスが CPU・メモリ・ファイル・ネットワーク・デバイスを使うのを許可し、隔離し、計測することです。特権的な操作は system call を通じて user space から kernel space へ入ります。この境界は CPU の特権レベルによって強制されるため、アプリ側からは回避できません。
ここで言う「信頼できないコード」とは、悪意あるコードだけを指すわけではありません。他人の依存パッケージ、レビューしきれていないスクリプト、CI で初めて動かすコード、エージェントが生成してその場で実行するコマンドです。「完全には検証していないが、動かす必要があるコード」をまとめてそう呼びます。
OS は、この種のコードを隔てるために進化してきました。複数ユーザーで 1 台のマシンを共有する時代は、ユーザーごとにファイルとメモリを隔離していました。クラウドでは、複数テナントが同じハードウェアを共有するために VM や container 技術が活用されています。serverless や CI/CD では、任意のコードを短時間だけ実行し、終わったら環境ごと破棄します。境界の置き方は変わっても、問いは同じです。信頼性の異なるコードを、どこまで許容し、どこで停止させるか。
隔離を、カーネルではなく言語ランタイムの中でやろうとした系譜もありました。1995 年の Java アプレットは、Web からダウンロードした信頼できないコードを、JVM のサンドボックス（SecurityManager とバイトコード検証）を用いてファイルや通信を制限しながら実行する仕組みです。ただ、サンドボックス脱出が相次ぎ、アプレットは姿を消し、SecurityManager も 2025 年の JDK 24 で恒久的に無効化されました。任意の信頼できないコードを隔てる境界は、結局カーネルとハードウェアの側に残ったわけです。
似た系譜として、ブラウザ上の JavaScript sandbox もあります。JavaScript はブラウザが許可した Web API だけを通じて外界に触れ、Same-Origin Policy や権限プロンプトで制約される。ただしこれは言語ランタイム単体というより、ブラウザ全体と OS の sandbox による隔離です。ブラウザ外で同じ capability ベースの発想を明確に持ち込んでいるのが WebAssembly（WASI）です。
エージェントの実行環境を整理する
では、エージェントはその一行を「どこで」走らせているのか。素のホストから、隔離で囲うところまで、順に整理してみます。
① ほぼ素のホスト
いちばん無防備なのは、エージェントをホスト上でそのまま動かす形です。
ここ数ヶ月で広がった OpenClaw は、自分のデバイスで動かすパーソナル AI アシスタントです。Signal・Telegram・Discord・WhatsApp などを UI に、ユーザーの代わりに処理を進める。ローカルで広い権限を持ち、ファイルの読み書き、shell コマンドの実行、メールやカレンダーへのアクセスまでこなします。ツールは基本、ホスト上でほぼフルアクセスで動きます。
この自由度は、そのまま事故につながっています。データに悪意ある指示を埋め込む prompt injection が指摘され、Cisco の研究チームはサードパーティ skill がユーザーの知らぬ間にデータを持ち出す例を報告、2026 年 3 月には中国が政府機関・国有企業での利用を制限しました。
② 隔離して囲う
そこで、実行環境を隔離で囲う方法が出てきます。同じ「隔離する」でも、境界の置き方はいくつもあります。
- container: host kernel を共有しつつ、namespace で見える世界を、cgroup で資源を、seccomp や capabilities でできることを絞る。軽くて速い一方、カーネルは host と共有のまま。任意コードの基盤に使うなら、host mount・privileged mode・root mapping・network egress・secret の渡し方を慎重に見る必要があります。
- microVM（例：Firecracker）: workload ごとに guest kernel と hardware virtualization の境界を置く。container より重いが、host kernel を共有しない分、隔離は強い。任意コードを受け取り、短時間で走らせて捨てる serverless 的な運用と相性が良いです。
- gVisor: host kernel に直接 syscall を届けず、Sentry という userspace の application kernel が syscall を受ける。host kernel への attack surface を減らす代わりに、互換性や性能とのトレードオフがあります。
- Kata Containers：マイクロVM（microVM）が「隔離の部品（VMそのもの）」であるなら、Kata は OCI / Kubernetes 互換のコンテナランタイムであり、docker run や pod を、ネームスペースコンテナではなく軽量 VM の中で実行します。コンテナの操作感（イメージ・pod・kubectl）をそのまま保ちつつ、隔離のみを VM レベルまで高められ、内部の VMM には QEMU や Firecracker（マイクロVM）を選べます。
ファイルがどこまで見えるかはマウントネームスペース次第、ネットワークに出られるかは egress の制御次第です。ここを曖昧にすると、「便利だから全部見せる・全部出す」が既定になりがちです。
こうした隔離は、自前で組まずマネージドな「サンドボックス」として使うこともできます。
たとえば Vercel Sandbox は、AI 生成コードの実行に特化した使い捨ての compute で、各実行を Firecracker マイクロVM（専用カーネル）に隔離し、egress を細かく絞り、秘密をサンドボックス内に晒さず注入する credentials brokering で持ち出しを防ぎます。
その他にも E2B や Daytona など、AI エージェント向けの同種の選択肢も揃ってきました。
さらに 2026 年には、こうした隔離を OS 自身が機能として組み込む動きも出てきました。Microsoft が Build 2026 で発表した MXC（Microsoft Execution Containers） は、Windows と WSL 上で「エージェントが何に触れてよいか」をポリシーで宣言させ、その境界（ファイル・ネットワーク・セッション分離・エージェント固有の ID・監査）を実行時に OS が強制する仕組みです。隔離の強さもプロセス/セッション分離からマイクロ VM まで段階的です。ただし今のところ Windows 固有で、発表・プレビューの段階です。
正直、「コンテナか VM か」という分類は、あまり本質だと思っていません。見ているのは、ホストカーネルをどこまで共有するか、syscall やファイル・ネットワークをどこまで絞るか、起動の速さと隔離の強さをどう天秤にかけるか。そこで決めています。
おわりに
AI エージェントは、OS にとって新しい存在というより、「信頼できないコードを実行する主体」の新しい形だと思っています。
他人のパッケージ、CI で走るテスト、serverless 上の関数。OS はずっと、完全には信頼できないコードを同じ資源の上で安全に動かすことを扱ってきました。
そこに今回 LLM が生成してその場で実行するエージェントが追加されました。
そのため、安全な基盤を構築するときは、API 名やエージェント名ではなく、プロセスやファイル、ネットワークへのアクセスが、どこで許され、どこで止められているかを見る必要があります。
個人的には、基盤に「エージェント専用の新しい何か」が必須だとは思っていません。プロセスを分け、資源に上限を置き、syscall を絞り、ネットワークの向きを決める。効く道具はどれも、OS が何十年も持ってきた枯れた部品です。新しいのは、相手がモデルになったことだけ。だからまず信用するのは、目新しい隔離レイヤより、この枯れた境界を使って素直に組むことです。
しかし、今回の隔離の仕組みは安全性とコストのトレードオフとなるので最適解と言えるものはなくその時の要件や扱うデータの性質に合わせて決める必要があります。
Windows の MXC のように、「信頼できないコードをどこで止めるか」を OS の機能として組み込む話も出てきました。とはいえ 現状は Windows 固有の機能で、今は Build 2026 で発表・プレビューされた段階。実運用に広く降りてくるのはこれからですし、Linux やクラウド側に同じものがあるわけではありません。それでも、足元の OS がどう応えていくのかは、低レイヤ好きとしてはずっと追いかけたい領域です。
エンジニアを募集しています！
ここまで読んでいただきありがとうございました！
Algomatic では、「AI 革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
参考リンク
- OpenClaw - GitHub
- OpenClaw - Wikipedia
- Introducing Microsoft Scout: Your always-on personal agent - Microsoft 365 Blog
- Windows platform security for AI agents - Windows Developer Blog
- EEVDF Scheduler (Linux Kernel documentation)
- Control Group v2 (Linux Kernel documentation)
- Seccomp BPF (Linux Kernel documentation)
- Firecracker microVMs
- gVisor documentation
- Kata Containers
- Vercel Sandbox - Vercel Docs
- JEP 486: Permanently Disable the Security Manager
- Capabilities-Based Security with WASI
原文を表示
株式会社Algomaticの藤崎（@yuufdev）です。
今回は「Algomatic 初夏のアドベントカレンダー」、メンバー各々が好きな技術を語る会の4日目です。アドベントカレンダーを通して、Algomaticのエンジニアチームがどんな技術に関心を持っているのか、少しでも伝われば嬉しいです。
前回の記事はこちらです。
普段は、AIエージェントをエンタープライズ企業に導入するPoCやシステム開発に携わっています。そこでよく考えているのが、エージェントが実行するコマンドや生成コードを、どこまで通し、どこで止め、何を記録するかという線引きです。
AIエージェントの話は、たいていモデルやプロンプト、ツール設計が中心になります。それも大事なんですが、エージェントが実際に npm install を叩き、ファイルを書き換え、ブラウザや外部APIに触り始めると、最後に効いてくるのはOSの境界のほうでした。
この記事では、AIエージェントの実行環境を「どこで走らせるか」で整理しながら、その下でOSやカーネルが何をしているのかを振り返ります。
この記事の3行まとめ
- AIエージェントが実際にコマンドを動かす時代になり、効くのはモデルの賢さより、ハーネスと実行環境のほうになった。
- 今回はそのうち実行環境に絞って、サンドボックスの種類や、OS・仮想化が持つ隔離の仕組みとパターンを整理してみた。
- どれもOSが昔から続けてきた「信頼できないコードを隔てる」仕組みを活用している。新しいのは相手がエージェントになったことだけ。
その一行が、どこで走っているのか
エージェントが「依存を入れてテストして」と判断し、npm install を実行する。ただの一行ですが、これが何の制約もなくホスト上で走ることもあれば、何重にも隔離された中で走ることもあります。まず、その下でOSが何をしているかを覗いてみます。
その一行は、最初に一つのプロセスになります。shell やランタイムが fork / exec に近い流れで起動し、npm install 自体もファイルを読み書きし、ネットワークへ出て、postinstall script のような別のプロセスまで動かす。動き出したあと、このプロセスをどこまで走らせるかを握っているのがカーネルです。
CPU をいつ割り当てられるかは scheduler 次第で、並列するジョブが増えれば取り合いになります。だから「遅い」原因はモデルとは限らず、スケジューリングや周辺負荷にあることもあります（Linux6.6 は 2023年10月に通常タスクの既定を CFS から EEVDF に変更しました）。
使えるメモリや CPU 量は cgroup の上限で頭打ちになり、メモリが足りなくなれば OOM killer がプロセスを kill します。「テストが途中で落ちた」の正体が、コードではなく単なるメモリ上限だった、というのもよくあります。呼べる system call も seccomp が絞り、許可されないものは EPERM で弾かれます。ただし seccomp 単体で sandbox になるわけではなく、namespace や cgroup、capabilities と組み合わせて、触れられるカーネルの面を小さくするための部品です。
エージェントが「遅い」「途中で kill された」「権限エラーで弾かれた」と詰まるとき、原因の多くはモデルの出力ではなく、カーネルがこのプロセスをどう走らせ、どこで止めるかにあります。どこで止まったかを見れば、直す場所が変わります。
なぜ境界がいくつもあるのか。OSの仕事を一言で言えば、アプリとハードウェアの間に立ち、プロセスが CPU・メモリ・ファイル・ネットワーク・デバイスを使うのを許可し、隔離し、計測することです。特権的な操作は system call で user space から kernel space に入る。この境界は CPU の特権レベルが強制するので、アプリ側からは回避できません。
ここで言う「信頼できないコード」は、悪意あるコードだけではありません。他人の依存パッケージ、レビューしきれていないスクリプト、CIで初めて動かすコード、エージェントが生成してその場で実行するコマンド。「完全には検証していないが、動かす必要があるコード」をまとめてそう呼びます。
OSは、この種のコードを隔てるために進化してきました。複数ユーザーで1台を共有する時代は、ユーザーごとにファイルとメモリを隔てていました。クラウドでは、複数テナントが同じハードを共有するために VM や container 技術が活用されています。serverless や CI/CD では、任意のコードを短時間だけ走らせ、終わったら環境ごと捨てる。境界の置き方は変わっても、問いは同じです。信頼の違うコードを、どこまで許して、どこで止めるか。
隔離を、カーネルではなく言語ランタイムの中でやろうとした系譜もありました。1995年のJavaアプレットは、Webから落とした信頼できないコードを、JVMのサンドボックス（SecurityManager とバイトコード検証）でファイルや通信を制限して走らせる仕組みです。ただサンドボックス脱出が相次ぎ、アプレットは姿を消し、SecurityManager も2025年のJDK 24で恒久的に無効化されました。任意の信頼できないコードを隔てる境界は、結局カーネルとハードウェアの側に残ったわけです。
似た系譜として、ブラウザ上の JavaScript sandbox もあります。JavaScript はブラウザが許可した Web API だけを通じて外界に触れ、Same-Origin Policy や権限プロンプトで制約される。ただしこれは言語ランタイム単体というより、ブラウザ全体と OS の sandbox による隔離です。ブラウザ外で同じ capability ベースの発想を明確に持ち込んでいるのが WebAssembly（WASI）です。
エージェントの実行環境を整理する
では、エージェントはその一行を「どこで」走らせているのか。素のホストから、隔離で囲うところまで、順に整理してみます。
① ほぼ素のホスト
いちばん無防備なのは、エージェントをホスト上でそのまま動かす形です。
ここ数ヶ月で広がった OpenClaw は、自分のデバイスで動かすパーソナルAIアシスタントです。Signal・Telegram・Discord・WhatsApp などをUIに、ユーザーの代わりに処理を進める。ローカルで広い権限を持ち、ファイルの読み書き、shellコマンドの実行、メールやカレンダーへのアクセスまでこなします。ツールは基本、ホスト上でほぼフルアクセスで動きます。
この自由度は、そのまま事故につながっています。データに悪意ある指示を埋め込む prompt injection が指摘され、Cisco の研究チームはサードパーティ skill がユーザーの知らぬ間にデータを持ち出す例を報告、2026年3月には中国が政府機関・国有企業での利用を制限しました。
② 隔離して囲う
そこで、実行環境を隔離で囲う方法が出てきます。同じ「隔離する」でも、境界の置き方はいくつもあります。
- container: host kernel を共有しつつ、namespace で見える世界を、cgroup で資源を、seccomp や capabilities でできることを絞る。軽くて速い一方、カーネルは host と共有のまま。任意コードの基盤に使うなら、host mount・privileged mode・root mapping・network egress・secret の渡し方を慎重に見る必要があります。
- microVM（例：Firecracker）: workload ごとに guest kernel と hardware virtualization の境界を置く。container より重いが、host kernel を共有しない分、隔離は強い。任意コードを受け取り、短時間で走らせて捨てる serverless 的な運用と相性が良いです。
- gVisor: host kernel に直接 syscall を届けず、Sentry という userspace の application kernel が syscall を受ける。host kernel への attack surface を減らす代わりに、互換性や性能とのトレードオフがあります。
- Kata Containers: microVM が「隔離の部品（VMそのもの）」なら、Kata はOCI / Kubernetes 互換のコンテナランタイムで、docker run や pod を、namespace コンテナではなく軽量VMの中で動かす。コンテナの操作感（イメージ・pod・kubectl）のまま隔離だけVM級にでき、中身のVMMには QEMU や Firecracker（microVM）を選べます。
ファイルがどこまで見えるかは mount namespace 次第、ネットワークに出られるかは egress の制御次第です。ここを曖昧にすると「便利だから全部見せる・全部出す」が既定になりがちです。
こうした隔離は、自前で組まずマネージドな「サンドボックス」として使うこともできます。
たとえば Vercel Sandbox は、AI生成コードの実行に特化した使い捨ての compute で、各実行を Firecracker microVM（専用カーネル）に隔離し、egress を細かく絞り、秘密を sandbox 内に晒さず注入する credentials brokering で持ち出しを防ぎます。
その他にもE2B や Daytona など、AIエージェント向けの同種の選択肢も揃ってきました。
さらに2026年には、こうした隔離を OS 自身が機能として組み込む動きも出てきました。Microsoft が Build 2026 で発表した MXC（Microsoft Execution Containers） は、Windows と WSL 上で「エージェントが何に触れてよいか」をポリシーで宣言させ、その境界（ファイル・ネットワーク・セッション分離・エージェント固有のID・監査）を実行時に OS が強制する仕組みです。隔離の強さも process / session isolation から micro-VM まで段階的。ただし今のところ Windows 固有で、発表・プレビューの段階です。
正直、「container か VM か」という分類は、あまり本質だと思っていません。見ているのは、host kernel をどこまで共有するか、syscall やファイル・ネットワークをどこまで絞るか、起動の速さと隔離の強さをどう天秤にかけるか。そこで決めています。
おわりに
AIエージェントは、OSにとって新しい存在というより、「信頼できないコードを実行する主体」の新しい形だと思っています。
他人のパッケージ、CIで走るテスト、serverless上の関数。OSはずっと、完全には信頼できないコードを同じ資源の上で安全に動かすことを扱ってきました。
そこに今回LLMが生成してその場で実行するエージェントが追加されました。
そのため、安全な基盤を構築するときは、API名やエージェント名ではなく、プロセスやファイル、ネットワークへのアクセスが、どこで許され、どこで止められているかを見る必要があります。
個人的には、基盤に「エージェント専用の新しい何か」が必須だとは思っていません。プロセスを分け、資源に上限を置き、syscall を絞り、ネットワークの向きを決める。効く道具はどれも、OSが何十年も持ってきた枯れた部品です。新しいのは、相手がモデルになったことだけ。だからまず信用するのは、目新しい隔離レイヤより、この枯れた境界を使って素直に組むことです。
しかし、今回の隔離の仕組みは安全性とコストのトレードオフとなるので最適解と言えるものはなくその時の要件や扱うデータの性質に合わせて決める必要があります。
Windows の MXC のように、「信頼できないコードをどこで止めるか」を OS の機能として組み込む話も出てきました。とはいえ 現状はWindows 固有の機能で、今は Build 2026 で発表・プレビューされた段階。実運用に広く降りてくるのはこれからですし、Linux やクラウド側に同じものがあるわけではありません。それでも、足元のOSがどう応えていくのかは、低レイヤ好きとしてはずっと追いかけたい領域です。
エンジニアを募集しています！
ここまで読んでいただきありがとうございました！
Algomatic では、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
参考リンク
- OpenClaw - GitHub
- OpenClaw - Wikipedia
- Introducing Microsoft Scout: Your always-on personal agent - Microsoft 365 Blog
- Windows platform security for AI agents - Windows Developer Blog
- EEVDF Scheduler - The Linux Kernel documentation
- Control Group v2 - The Linux Kernel documentation
- Seccomp BPF - The Linux Kernel documentation
- Firecracker microVMs
- gVisor documentation
- Kata Containers
- Vercel Sandbox - Vercel Docs
- JEP 486: Permanently Disable the Security Manager
- Capabilities-Based Security with WASI
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み