AIエージェントの実行層（Execution Layer）とは何か——bashの限界からagentOSまで

コードを書かないAIエンジニア@もるふぉです。

今日はClaude Codeを毎日使っている自分が、ここ最近ずっと気になっていたテーマについて書きます。

AIエージェントの「実行層（Execution Layer）」——LLMが実際にツールを動かすときの基盤レイヤーが、いま猛烈な勢いで進化しています。

X上ではKenn Ejimaさん、Rhys Sullivanさん、広木大地さんといったエンジニアたちが、このテーマを議論しておりました。

この記事では、AIエージェントの実行層がなぜ重要なのか、bashからどう進化しているのか、そして2026年現在の主要プレイヤーを整理します。

Claude Codeのbash実行——便利だけど、なんか違和感ない？

あのYes連打の正体

Claude Codeを使っている方なら、この画面に見覚えがあるはずです。

「bashコマンドを実行していいですか？」と聞かれて、中身をよく読まずに「Yes」を押す。

巨大なシェルスクリプトが表示されて、何をやっているのか正直よくわからないけど「まあ大丈夫でしょ」とOKする。

これ、ちょっとイヤな感じがしませんか。

自分も正直、1日に何十回とYesを押しています。

Ejimaさんの言葉を借りれば「良くわからんがヨシ！」状態ですよね。

--dangerously-skip-permissionsフラグで全承認にしている人も多いんじゃないでしょうか。(私も全承認にしてます)

でもこれ、冷静に考えるとかなり怖いことをやっています。

bashをOKしてしまうと、あらゆるセキュリティのガードレールがバイパスされます。

ファイルの削除も、ネットワークアクセスも、環境変数の読み取りも、全部できてしまう。

「何でもできる」からこそコーディングエージェントは強力なんですが、このYes連打が最終形態なわけがない——というのが、今回の議論の出発点です。

bashがAIエージェントに向かない3つの理由

1. セキュリティの粒度が粗すぎる

bashは「実行するか、しないか」の二択しかありません。

「このコマンドはファイル読み取りだけだからOK」「これはネットワークアクセスを含むからNG」といった細かい制御ができない。

ワイルドカード的な承認ルール（「readは常にOK」「writeは確認」など）も作れません。

2. 型安全性がゼロ

bashコマンドの引数に型はありません。

LLMが生成したコマンドが正しい形式かどうか、実行前に検証する仕組みがないんです。

typoひとつでrm -rf /が走る可能性がある世界です。

地味にゾッとしますよね。

3. エージェント間の連携ができない

複数のエージェントがbashを共有するとき、ログイン状態や認証情報の引き継ぎができません。

チーム向けの権限管理もできない。

「このエージェントにはデプロイ権限を与えるが、あのエージェントには与えない」といった制御が、bash上ではほぼ不可能です。

つまり、bash実行は「とにかく動く」の一点突破で成立していた仕組みで、スケールを考えると限界が見えてくるんですよね。

次は、その限界に気づいたエンジニアたちが何をしてきたか——進化の流れを追ってみましょう。

AIエージェント「実行層」の進化の系譜

Ejimaさんが投稿の中で示した進化の流れが非常にわかりやすいので、これをベースに整理します。

ここが面白いところなんですが、たった1ヶ月ほどの間に、以下のような進化が起きています。

bash（第1世代）: とにかく動く、でも野蛮

Claude Codeがブレイクスルーを起こせた理由のひとつが、ローカルファイルシステムへのアクセスと、bashの実行権限をLLMに渡したことでした。

「とにかく動く」という意味では最強です。

OSの全機能にアクセスできるので、何でもできる。

でも、それは「何でもできてしまう」というリスクと表裏一体です。

Theoさんが「Agents are good at bash. Bash is not good for agents.（エージェントはbashが得意だが、bashはエージェントに向いていない）」と端的に表現していますが、まさにその通りですね。

just-bash / Code Mode（第2世代）: Yesを減らす努力

第1世代の問題を受けて、bashの実行を制限する仕組みが登場しました。

許可リスト方式で「このコマンドだけはYesなしで実行OK」とするアプローチです。

Claude Codeの.claude/settings.jsonで設定できるallow/denyルールもこの流れに含まれます。

改善はされましたが、本質的にはbashの上にルールを被せているだけで、根本的な解決にはなっていません。

いわば「悪い道路に標識を立てた」くらいの対処療法ですね。

just-js / TypeScript Runtime（第3世代）: 型とエコシステムを手に入れる

ここで大きなパラダイムシフトが起きます。

「そもそもbashじゃなくてJavaScript/TypeScriptランタイムの上で実行すればいいのでは？」という発想です。

JavaScriptランタイムはbashのスーパーセットではないか、という視点です。

• bashでできることはJavaScriptでもほぼ全て可能
• TypeScriptなら型安全性が手に入る
• npmエコシステムの恩恵を受けられる
• 人間にとっても可読性が高い

つまり、「今まで型もなく実行前検証もできなかった」のが、TypeScriptに変えるだけで一気に解決するんです。

MCPコールも含めた処理をまとめて行う「Glue（糊付け）層」として、JavaScriptランタイムの方がbashよりあらゆる点で優れている、という主張ですね。

secure-exec / agentOS（第4世代）: V8 Isolateで「軽さ」と「安全」を両立

第3世代の「TypeScriptで実行する」という方向性に、さらにセキュリティと軽量性を加えたのが第4世代です。

ここで鍵になるのがV8 Isolateという技術です。

V8 IsolateはNode.js上で動く超軽量な実行環境で、テナントごとに完全に分離された空間を提供します。

Dockerのような「重い」サンドボックスではなく、ミリ秒単位で起動できるのが特徴です。

ファイルシステムもin-memoryとして仮想化することで、安全性とパフォーマンスを両立させているわけです。

「Dockerより速くて、bashより安全」——これがいかにエレガントな解決策か、わかりますよね。

では、この方向性を実装した具体的なツールを見ていきましょう。

2026年現在、AIエージェント実行環境の主要プレイヤーを比較する

この領域には既にいくつかのプロジェクトが登場しています。

正直、この4つを並べたとき「ここまで来たか」と思いました。

それぞれの特徴を整理してみましょう。

Executor（Rhys Sullivan）

Rhys Sullivanさんが公開したOSSプロジェクトで、Xでの発表投稿は大きな反響を呼びました。

プロジェクトのコンセプトは「エージェントのための統合レイヤー」です。

OpenAPI、GraphQL、MCP、Google Discoveryに対応したツールカタログを持ち、エージェントがTypeScriptでツールを呼び出せる環境を提供します。

ローカルで動かせる統合ツールカタログとして、Cursor、Claude Code、OpenCodeなどのMCP対応エージェントから接続でき、ツールカタログ・認証・ポリシーを複数エージェント間で共有できるのが強みです。

つまり、「今まで各エージェントにバラバラに設定していた認証やポリシーを、一か所で管理できる」わけです。

OSSなのでコスト面の心配もなく、まず試してみるハードルが低いのがうれしいですね。

GitHub - RhysSullivan/executor: The missing integration layer for AI agents. Let them call any OpenAPI / MCP / GraphQL / custom js functions in secure environment.

The missing integration layer for AI agents. Let them call any OpenAPI / MCP / GraphQL / custom js functions in secure environment. - RhysSullivan/executor

github.com

agentOS（rivet-dev）

rivet-devが開発する「エージェント向けポータブルOS」です。

V8 IsolateとWebAssemblyを組み合わせた実行基盤で、冷起動が約6ミリ秒という驚異的なパフォーマンスを実現しています。

6ミリ秒、想像してみてください。

Dockerでコンテナを起動しようとすると数秒〜十数秒かかるのに、その約1000倍以上速い。

従来のサンドボックスと比較して約32倍安価という数字も出ています。

npmパッケージとして提供されているので、既存のNode.jsプロジェクトにnpm installで組み込めるのも魅力です。

ホストツールとの連携や、きめ細かい権限管理もサポートしています。

GitHub - rivet-dev/agent-os: A portable open-source operating system for agents. ~6 ms coldstarts, 32x cheaper than sandboxes. Powered by WebAssembly and V8 isolates.

A portable open-source operating system for agents. ~6 ms coldstarts, 32x cheaper than sandboxes. Powered by WebAssembly and V8 isolates. - rivet-dev/agent-os

github.com

Cloudflare Dynamic Workers

Cloudflareが2026年3月にオープンベータとして公開した、V8 Isolateベースの実行基盤です。

「サンドボックスを100倍速く」というキャッチフレーズの通り、コンテナと比較してミリ秒単位の起動時間と、10〜100倍のメモリ効率を実現しています。

特筆すべきは、WorkerからWorkerを動的に生成できる点です。

LLMが生成したTypeScriptコードをオンデマンドで実行できるため、エージェントの「コードモード」実行に最適です。

料金はユニークWorkerあたり$0.002/日と、かなりリーズナブルです。

E2B

Firecracker microVMベースのサンドボックスで、この領域の老舗的存在です。

各実行環境に専用のLinuxカーネルが割り当てられるため、ハードウェアレベルの分離を実現しています。

冷起動は公式では200ms以内で、V8 Isolate系と比べると遅いですが、「何でも動くLinux環境」が必要な場合には最も堅実な選択肢です。

最大24時間のセッション継続にも対応しています。

比較表

4つのアプローチが揃ってきたことで、ユースケースに応じて選べる時代になってきています。

次は、なぜこのタイミングで実行層の議論が盛り上がっているのか、背景を確認しておきましょう。

MCP vs CLI論争は終わった——次の戦場はAIエージェントの実行層

少し前まで、エンジニアコミュニティでは「MCPがAPIの標準になるのか」「CLIツールをそのまま使えばいいのでは」という議論が活発でしたよね。

「え、あの盛り上がった議論、もう終わったの？」って思いますよね。

でも今、議論の焦点は「どのプロトコルで呼ぶか」から「どの環境で実行するか」に移っています。

「最もアツい領域」はまさにこの実行層なんです。

考えてみれば当然で、MCPでツール定義をどれだけ綺麗にしても、そのツールを実行するときにbashで全権限を渡していたら意味がない。

プロトコルの標準化と実行環境の安全化は、両輪で進める必要があるということですね。

プロトコル層は「何を呼ぶか」を決める。実行層は「どう安全に動かすか」を担う。

この2つが揃って初めて、エージェントは本番で使えるものになるわけです。

では実際、自分ならどれを選ぶか——正直に書きます。

自分がこれから使うなら何を選ぶか（もるふぉの結論）

正直に言うと、2026年4月時点ではまだ「これが正解」と断言できる段階ではないです。

ただ、自分なりの使い分けの方針はあります。

日常のローカル開発（個人利用）: Executor

Claude CodeやCursorと組み合わせて使うなら、Executorがいちばん手軽です。

ローカルで動かせる統合ツールカタログなので導入のハードルが低く、OSSなのでコスト面の心配もありません。

bashの代替として、まず試してみる価値があります。

プロダクション環境でのエージェント実行: agentOSまたはCloudflare Dynamic Workers

6ミリ秒の冷起動を実現しているagentOSは、パフォーマンス重視のケースで有力です。

一方、既にCloudflareのインフラを使っている場合はDynamic Workersが自然な選択肢になります。

重い処理や長時間のジョブ: E2B

「Linux環境でなんでもできる」という安心感は、やっぱりE2Bが強いです。

24時間のセッション継続が必要なワークロードでは、今でも最有力でしょう。

エージェント開発者として今やっておくべきことは、まずこの「実行層」という概念を理解しておくことだと思います。

bashをそのまま渡し続ける時代はそう長くは続かないでしょう。

「bash → just-bash → Code Mode → just-js → secure-exec → agentOS」という進化はマッハの速度で進んでいます。

この流れを知っているかどうかで、半年後のエージェント設計が変わってくるはずです。

まとめ

AIエージェントの実行層は、bashからTypeScriptランタイム、そしてV8 Isolateベースの軽量サンドボックスへと急速に進化しています。

Claude Codeの「Yes連打」に代表されるbash実行の問題点は、セキュリティ・型安全性・権限管理の3点に集約されます。

2026年現在、Executor、agentOS、Cloudflare Dynamic Workers、E2Bという4つのアプローチが競い合っています。

MCP vs CLIの議論から「実行層」の議論へとフェーズが移った今、この領域を押さえておくことがエージェント開発者にとって重要になってきています。

まずはExecutorをローカルで動かしてみるところから始めてみてはいかがでしょうか。

コマンド一発でインストールできますし、「bashを渡す」以外の選択肢があることを知るだけでも、エージェントの設計思想が変わるはずです。