AIエージェント実行基盤の大転換 — なぜOpenAI・Google・AWSは「ランタイム」に巨額投資するのか

なぜ今、「AIエージェントの実行基盤」が焦点になっているのか

2026年2月27日、OpenAIとAmazonは500億ドルの戦略的投資とともに「Stateful Runtime Environment」の共同開発を発表した。「モデルを賢くする」競争から「エージェントを安全・確実に動かす基盤を押さえる」競争へ — 業界の焦点が明確に移行した瞬間だった。

homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。

エンタープライズのAIエージェント導入が「PoC止まり」になる最大の理由は、モデルの性能ではない。実行基盤の欠如にある。Gartnerは2027年末までにエージェントAIプロジェクトの40%以上がキャンセルされると予測しており、その主因として実行・ガバナンス基盤の未整備を挙げている。

では、ここで言う「実行基盤（ランタイム）」とは一体何なのか。本記事では、1つの具体的な業務シナリオを軸に、ランタイムの概念を定義した上で、ステートレスAPIの限界からAgent OSへと向かう進化の因果関係を読み解く。

そもそも「ランタイム」とは何か

「ランタイム」は技術者向けの用語だが、概念自体はシンプルだ。AIエージェントが実際に「仕事」をするための土台と考えるとわかりやすい。

スマートフォンのアプリは、iOSやAndroidというOS（オペレーティングシステム）の上で動いている。アプリ単体ではカメラにアクセスすることも、通知を送ることも、データを保存することもできない。OSが「カメラを使っていいか」「通知を送っていいか」を管理し、アプリに安全な実行環境を提供している。

AIエージェントにとってのランタイムは、このOSに相当する。具体的には、2つの中核機能で構成される。

LLM（ChatGPTやClaude等のAIモデル）は、あくまで「考える」能力を提供するだけだ。考えた結果を実世界のアクションに変換する — たとえばSlackにメッセージを送る、データベースを更新する、ファイルを生成する — には、その「考え」を安全に実行し、進捗を管理する基盤が必要になる。これがランタイムの役割だ。

なぜ今までランタイムが不要だったのか

ChatGPTに質問して回答をもらう — この使い方であればランタイムは不要だった。なぜなら「質問→回答」の1往復で完結し、外部のシステムに触る必要がなかったからだ。

しかしAIエージェントは違う。1つの具体例で考えてみよう。

1つのシナリオで理解する — 「経費レポートを作って部長に送っておいて」

あなたがAIエージェントに「今月の経費レポートを作成して、部長にSlackで送っておいて」と指示する場面を想像してほしい。

この一見シンプルな指示を実行するために、エージェントは以下のステップを踏む必要がある。

1. 経費管理システムのAPIにアクセスし、今月のデータを取得する
2. データを集計し、レポート形式に整形するコードを生成・実行する
3. 完成したレポートをSlack APIで部長に送信する

ChatGPTに「経費レポートの書き方を教えて」と聞くのとは根本的に異なる。エージェントは複数の外部システムに順番にアクセスし、コードを書いて実行し、その結果を次のステップに引き渡す必要がある。

図1: 経費レポート作成フローとランタイムの構成 — ランタイム（①②）とツール呼び出し革新の関係

この図が示す通り、ランタイムの中核は①記憶と継続と②安全な実行の2つだ。そしてその上で動くツール呼び出しの効率化技術（PTC / Code Mode）が、3つ目の重要な要素として存在する。

なぜこの3つがセットで語られるのか。それは、この3つが因果関係で連鎖しているからだ。次のセクションでは、ステートレスAPIの限界から始まり、「ツール呼び出しの革新 → サンドボックスの必要性 → 状態管理の必要性」という進化のストーリーを追う。

ステートレスAPIの限界 — OpenAIが認めた構造的問題

OpenAIはStateful Runtimeの発表に際して、従来のステートレスAPIの限界を率直に認めている。その内容は、エンタープライズのAIエージェント導入を検討するすべての企業にとって重要だ。

OpenAIの主張を要約すると、次のようになる。ステートレスAPIベースのエージェント・プロトタイプは、単純なユースケースにしか対応できない。本番環境のエージェントは、過去のアクションのコンテキストを必要とし、複数のツール出力や承認、システム状態に依存する。しかしステートレスAPIでは、状態の保存方法、ツールの実行方法、エラー処理、長時間タスクの安全な再開方法を、すべて開発チームが自前で構築する必要がある。

ステートフルランタイムは、この負荷を軽減するために設計されている。「作業コンテキスト（working context）」が記憶・履歴、ツールとワークフローの状態、環境の利用状況、アイデンティティと権限境界を引き継ぐことで、エージェントが自動的に複雑なステップを実行できるようになる。

要するに、「LLMの賢さ」と「実世界で仕事を遂行する能力」の間には巨大なギャップがあり、それを埋めるのがランタイムだというのがOpenAIの見立てだ。

「自動販売機」と「担当営業」の違い

ステートレスとステートフルの違いは、身近な例で考えるとわかりやすい。

ステートレスは自動販売機のような仕組みだ。 お金を入れて、ボタンを押して、商品が出てくる。自動販売機は「前回この人がコーラを買った」ことを覚えていない。毎回ゼロからのやり取りになる。従来のAI API（ChatGPT APIなど）は、このステートレスな仕組みで動いている。

ステートフルは担当営業のような仕組みだ。 「先月のお見積りの件ですが」と言えば、担当者は過去のやり取りを踏まえて対応してくれる。途中で別の用事が入っても、戻ってきたときに「どこまで進んでいたか」を覚えている。

この「自動販売機」から「担当営業」への転換を、業界全体が一斉に進めている。しかし、なぜ今なのか。そのきっかけとなったのが、「AIにコードを書かせてツールを呼ぶ」という発見だった。

進化の起点 — 「AIにコードを書かせる」方が正確だった

従来のツール呼び出しの構造的な非効率

AIエージェントが外部ツール（Slack API、データベース、経費管理システムなど）を使うには、「ツール呼び出し」という仕組みが必要だ。従来の方式は次のような流れだった。

1. AIに「使えるツールの一覧」を渡す
2. AIが「次に使うべきツール」を1つ選ぶ
3. ツールを実行し、結果をAIに戻す
4. AIが結果を読み、次のツールを選ぶ
5. 2-4をタスクが完了するまで繰り返す

経費レポートの例で言えば、「経費データ取得API → 結果をAIに戻す → AIが集計方法を決める → 集計API → 結果を戻す → AIがSlack送信を決める → Slack API」と、毎回AIに判断を戻す往復が発生する。

Cloudflareのエンジニアはこの問題を端的に表現している。LLMに1ステップずつツールを呼ばせるのは、シェイクスピアに中国語の授業を1ヶ月受けさせてから中国語で戯曲を書かせるようなものだ、と。LLMが最も得意な能力を使わせていない。

発見: LLMはコードを書くのが得意だ

LLMの学習データには、GitHubの膨大なPythonやTypeScriptのコードが含まれている。つまり「コードを書くこと」はLLMにとって母国語のような能力だ。ならば、ツールの呼び出し手順もコードで書かせればいい — これがAnthropicのProgrammatic Tool Calling（PTC）とCloudflareのCode Modeが到達した結論だ。

従来方式: AIが「次はどのツールを呼ぶか」を1ステップずつ判断する

新方式: AIが「経費データ取得 → 集計 → Slack送信」の全手順を1本のPythonコードとして書き出し、一括で実行する

Anthropicの計測では、PTCにより複雑な調査タスクのトークン消費が43,588から27,297へ37%削減された。ツール選択の精度もOpus 4で49%から74%へ向上している。Cloudflareの事例はさらに極端で、2,500以上のAPIエンドポイントを持つCloudflare APIを従来方式で記述すると117万トークンを消費するところ、Code Modeでは約1,000トークンの固定フットプリントで提供できる。

この効率化は画期的だった。しかし同時に、新たな問題を生み出した。

コードを書かせるなら「安全な実行環境」が必要になる

因果関係①: コード生成 → サンドボックスの必要性

AIにコードを書かせて一括実行する — これは効率的だが、「AIが書いたコードが暴走したら？」というリスクが直接的に発生する。

経費レポートの例で考えよう。AIが「今月の経費データを取得して集計するPythonコード」を書く。このコードがもし、誤って全データを削除する処理を含んでいたら？ 無限ループに陥ったら？ 想定外のデータベーステーブルにアクセスしたら？

従来の1ステップずつの呼び出し方式では、毎回AIに結果を戻して判断させていたため、各ステップで人間が「承認」を挟む余地があった。しかしコード生成型では一括で実行するため、中間での介入が効きにくい。だからこそ、隔離された安全な実行環境（サンドボックス） が不可欠になった。

サンドボックス隔離技術の現在地

サンドボックスとは、AIが生成したコードを「仕切られた部屋」で実行し、万が一の暴走が本番環境に影響しない仕組みだ。銀行のATMコーナーのように、利用者の操作と金庫を物理的に分離する考え方に近い。

この分野への投資は急加速している。E2Bは2025年7月にFirecrackerベースのサンドボックスで2,100万ドルのSeries Aを完了。Daytonaは2026年2月にサブ90msコールドスタートを武器に2,400万ドルのSeries Aを調達した。Vercel Sandboxは2026年1月にGA化し、内部運用してきたFirecracker基盤「Hive」を外部提供している。

GoogleはKubeCon NA 2025で、AIエージェント専用のKubernetes拡張「Agent Sandbox」を発表した。SandboxTemplate（実行環境の型を定義）、SandboxClaim（環境の要求）、WarmPools（事前準備済み環境のプール）という3つの部品を組み合わせる仕組みで、サブ秒での起動を実現する。これは後述する「Agent OS」の原型とも言える設計だ。

サンドボックスによって「AIが書いたコードを安全に実行する」問題は解決に向かった。しかし、実際のエンタープライズ・ワークフローを動かしてみると、次の壁がすぐに現れる。安全に実行できても、途中で止まったらどうするのか？

長時間のタスクには「記憶」が必要になる

因果関係②: 多段階実行 → 状態管理の必要性

サンドボックスで安全にコードを実行できるようになった。しかし、もう1つの問題が残っている。複数のステップを跨ぐタスクで、進捗をどう記憶するかだ。

経費レポートの例に戻ろう。Step 1（データ取得）が成功した後、Step 2（集計コード実行）でSlack APIのレート制限に引っかかったとする。ステートレスな仕組みでは「どこまで進んだか」の記録がないため、Step 1からやり直しになる。データ取得のAPIコールも、その課金も、すべて二重に発生する。

これが「月次の全部門経費レポートを順に作成し、経営会議資料にまとめる」という長期ワークフローになれば、問題はさらに深刻だ。数時間〜数日にわたるプロセスで、途中のエラーのたびに最初からやり直すのは実用に耐えない。

OpenAIがStateful Runtimeで解決しようとしているのはまさにこの問題だ。「作業コンテキスト（working context）」が各ステップの結果、ツールの状態、ユーザーの権限情報を引き継ぐことで、途中から再開できる。担当営業が「先月のお見積りの件ですが」と言われて即座に対応できるのと同じ仕組みを、AIエージェントに提供する。

各社の「記憶力」の差

2026年3月時点で、主要プラットフォームの状態管理能力には大きな差がある。自社のエージェントが「5分で終わるタスク」を処理するのか「数日かけて進めるワークフロー」を処理するのかで、選択すべきプラットフォームは根本的に異なる。

Google Agent Engineは、Sessions（会話コンテキスト）、Memory Bank（長期記憶）、Code Execution（最大14日間の状態保持）をGA化し、2026年2月から課金を開始している。セキュリティ面でもIAM Agent IdentityやThreat Detectionとの統合を提供しており、エンタープライズ向けの成熟度が高い。

AWS Bedrock AgentCoreは、ランタイム（8時間の実行ウィンドウ）、メモリ、アイデンティティ管理、ポリシー制御、可観測性をモジュラーに提供する。MCP対応のGatewayも含まれ、東京リージョンを含む複数リージョンで利用可能だ。OpenAIのStateful Runtimeは、このAgentCoreと統合される形で提供される。

因果関係の全体像 — ステートレスAPIからAgent OSへの道筋

ここまでの流れを整理する。各社の動きは一見バラバラに見えるが、実は1本の因果関係で繋がっている。

図2: ステートレスAPIからAgent OSへの進化 — 各段階が次の段階を「必要」にする因果関係

この進化の流れで重要なのは、各段階が次の段階を「必要」にしている点だ。

ステートレスAPIの限界がコード生成型ツール呼び出し（PTC / Code Mode）を生んだ。しかしAIにコードを書かせて一括実行するにはサンドボックス（隔離実行環境） が必要になった。そして複数ステップを跨ぐワークフローを確実に動かすには状態管理（ステートフルランタイム） が必要になった。サンドボックスと状態管理 — この2つが「ランタイム」の本体であり、その上で動くコード生成型ツール呼び出しが効率的なインターフェースとして機能する。

OpenAI、Anthropic、Google、Cloudflare、AWSが「バラバラに」進めてきた技術投資は、この因果関係の異なるフェーズに注力しているだけだ。Anthropic + Cloudflareはコード生成型インターフェースの先駆者。GoogleとSaaS企業（E2B、Daytona、Vercel）はサンドボックス基盤の専門家。OpenAI × AWSとGoogleはステートフル状態管理のプラットフォーマー。そしてMCPが、すべてのフェーズを貫く「ツールの標準接続規格」として横断的に機能する。

MCPの位置づけ: ランタイムの「電話帳」

MCPはツールの発見・認証・スキーマ定義を標準化する「コントロールプレーン」だ。ランタイムが「どう安全に実行するか」を担い、MCPが「どのツールがあるか」を担う。両者は競合ではなく、スタックの異なる層を担当する補完関係にある。MCPがLinux Foundation傘下のAgentic AI Foundationに寄贈されたことで、プロトコル層のベンダー中立性は一定程度担保されている。

「Agent OS」は生まれるのか — 2026年以降の展望

記事冒頭でランタイムを「スマートフォンのOS」に例えた。この比喩は、単なる説明上の便宜ではなく、業界が実際に向かっている方向を正確に映している。

iOSの歴史が教えること

2007年の初代iPhoneを振り返ると、サードパーティ製アプリは存在しなかった。すべてAppleが組み込んだ機能だけで、外部の開発者がカメラにアクセスすることも、プッシュ通知を送ることも、バックグラウンドで処理を走らせることもできなかった。2008年にApp Storeが登場し、さらにiOS 4以降でマルチタスキング、通知センター、権限管理が順次標準化されるにつれて、「OSが提供すべき基盤機能」が確立された。アプリ開発者はビジネスロジックだけに集中すればよく、インフラの問題はOSが引き受ける — この分業が、モバイルアプリの爆発的な成長を可能にした。

AIエージェントの世界は、2026年現在、まさにApp Store登場前夜の段階にある。各社がバラバラにツール接続、状態管理、隔離実行を実装しており、「エージェント開発者がビジネスロジックだけに集中できる標準基盤」はまだ存在しない。

GoogleのKubernetes Agent Sandbox — 最も「OSらしい」設計

この標準基盤の原型に最も近いのが、GoogleがKubeCon NA 2025で発表したKubernetes Agent Sandboxだ。その設計は、OSの「プリミティブ」（基本部品）という考え方を意識的に採用している。

SandboxTemplate — 実行環境の「型」を定義する。iOSで言えばアプリのsandboxプロファイルに相当する。「このエージェントにはPython実行環境とネットワークアクセスを許可するが、ファイルシステムの書き込みはこのディレクトリに限定する」といった仕様をテンプレートとして宣言する。

SandboxClaim — エージェントが「この型の実行環境を1つください」と要求する仕組み。Kubernetesの永続ボリューム（PersistentVolumeClaim）と同じ発想で、エージェント側はインフラの詳細を知る必要がない。

WarmPools — 事前に起動済みの実行環境をプールしておく仕組み。エージェントがサンドボックスを要求した瞬間に、コールドスタート（ゼロからの起動）を経ずにサブ秒で環境を提供する。スマートフォンのアプリ切り替え（マルチタスキング）が瞬時に行えるのと同じ考え方だ。

さらにPod Snapshotsによる状態復元にも対応しており、「実行途中の環境をそのまま保存し、後から復元して再開する」ことができる。これはまさにiOSの「アプリ状態の保存と復元」に相当する機能だ。

経費レポートは「Agent OS」上でどう変わるのか

冒頭の経費レポートのシナリオを、Agent OSが成熟した世界で再度考えてみよう。

現在の世界では、開発チームが「経費管理APIへの接続を設定し、サンドボックスの隔離レベルを選定し、状態管理のためのチェックポイントを実装し、エラー時の再開ロジックを書き、権限管理をクラウドのIAMと統合する」必要がある。ランタイム基盤の構築に開発工数の大半が費やされ、本来のビジネスロジック（経費データをどう集計し、どうレポートを構成するか）に集中する余裕がない。

Agent OSが成熟した世界では、こうなる。開発者は「経費管理API、Excel処理、Slack API」をMCPで宣言的に接続する。実行環境はSandboxTemplateから自動的にプロビジョニングされ、gVisor級の隔離がデフォルトで有効。状態管理は、エージェントIDとセッションIDがOSレベルでネイティブサポートされているため、チェックポイントやリトライのコードを書く必要がない。開発者はビジネスロジックだけを書き、インフラはOSが引き受ける。

OpenAIが「ランタイムがステップ間の永続的なオーケストレーションと状態を処理する場合、チームは足場作りではなくワークフローとビジネスロジックに集中できる」と述べているのは、まさにこのビジョンだ。

2つのアプローチが競合している

現時点では、Agent OSの実現に向けて2つの異なるアプローチが並走している。

オープンプリミティブ型（Google + CNCF）。Kubernetes Agent Sandboxのように、OSの「部品」をオープンソースの標準として公開し、任意のクラウド・オンプレミス環境に展開できるようにするアプローチ。ベンダーロックインが最小化される反面、統合と運用の責任は利用者側に残る。

マネージドプラットフォーム型（OpenAI × AWS / Google Agent Engine）。ランタイムの全機能をクラウドサービスとして提供し、利用者はAPIを呼ぶだけで良いアプローチ。導入は容易だが、特定のクラウドへのロックインが発生する。

どちらが「正解」かは、企業のクラウド戦略とリスク許容度次第だ。重要なのは、両者が向かっている方向は同じということだ。

市場はAgent OSの成熟を待っている

市場予測はこの方向性を強く支持する。IDCは2030年までに45%の組織がAIエージェントを大規模にオーケストレーションすると予測し、Gartnerは2028年までにエンタープライズソフトウェアの33%にエージェントAIが搭載される（2024年の1%未満から）と見込んでいる。ただし同じGartnerが2027年末までに40%以上のエージェントAIプロジェクトがキャンセルされるとも予測している。

この「33%に搭載」と「40%がキャンセル」の間にあるギャップを埋めるのが、ランタイムの成熟度だ。サンドボックスと状態管理が「意識せずに使える標準基盤」になるか — つまりAgent OSが成立するかどうかが、エンタープライズAIの成否を分ける。

エージェント実行基盤の選択が、AI投資のROIを決める

本記事で分析した通り、AIエージェントの競争軸は「どのLLMを使うか」から「どの実行基盤の上でエージェントを動かすか」に移行している。そしてこの移行は、「コード生成型ツール呼び出し → サンドボックス → 状態管理 → Agent OS」という因果関係の連鎖として、必然的に進行している。

この転換を踏まえて、自社のランタイム選定にあたっては以下の5つの判断軸を推奨する。

第一に、自社のワークフローに必要な「タスクの長さ」を評価すること。数分で完結するタスクと、数日かけて段階的に進めるワークフローでは、選択すべきランタイムが根本的に異なる。先ほどの経費レポートのように数分で完結するタスクであれば、Anthropicの短期セッション（約4.5分）で十分だ。日〜週単位の長期ワークフローには、Google Agent Engine（14日間）やAWS AgentCore（8時間）が必要になる。

第二に、既存クラウドとの整合性を重視すること。AWS中心であればAgentCore/Stateful Runtime、GCP中心であればAgent Engineが自然な選択肢になる。マルチクラウド環境ではMCPとLangGraph等のフレームワークの組み合わせがロックインを最小化する。

第三に、セキュリティ/コンプライアンス要件を早期に定義すること。金融・医療などの規制業界ではgVisor/Firecracker級の隔離が必須だ。特にAnthropicのCode ExecutionはZDR（Zero Data Retention）に非対応であることに注意が必要だ。サンドボックスやデータ保持ポリシーの設計は、後付けで対応すると既存アーキテクチャの大幅な作り直しを伴う。

第四に、接続ツール数に応じた呼び出し方式を選択すること。ツールが10以下なら従来型で十分。100を超えるならPTC / Code Modeが事実上必須になる。

第五に、MCP対応を前提としたツール接続設計に着手すること。MCPはLinux Foundation傘下の中立的なオープン標準として定着しつつあり、ベンダーロックインの最小化にも寄与する。

無料相談を予約する | ブートキャンプの詳細

よくある質問

「ランタイム」と聞くと難しそうですが、自社に技術チームがなくても検討できますか？

ランタイムの選定は、技術的な詳細よりも「自社の業務要件」の整理が出発点になる。どの業務を自動化したいか、どの社内システムと連携させたいか、セキュリティ要件は何か — こうした業務要件が明確であれば、技術選定はAIインテグレーターに委任できる。

MCPとランタイムの関係を端的に教えてください

MCPは「ツールの電話帳」、ランタイムは「その電話帳を使って実際に電話をかけ、通話内容を記録し、通話中に問題があれば安全に切断する仕組み」だ。MCPが「どのツールがあって、どう接続するか」を標準化し、ランタイムが「そのツールを安全に・記憶を保ちながら実行する」ことを担当する。両者は競合ではなく、セットで使うものだ。

PTC / Code Modeは「ランタイム」の一部ですか？

厳密には違う。PTC / Code Modeは「AIがツールを呼び出す方法」の革新であり、ランタイム（状態管理 + 隔離実行基盤）の上で動く呼び出しインターフェースだ。ただし、この呼び出し方の革新がサンドボックスと状態管理の必要性を生み出したという意味で、ランタイムの発展と不可分な関係にある。

小規模なチームでも実行基盤の検討は必要ですか？

接続ツールが10以下で、1回数分で完結するタスクであれば、従来型のAPI呼び出しでも十分機能する。ただし、ツール数の増加や長時間タスクへの拡張を想定する場合は、早期にランタイム基盤の方針を決めておくことで後からの移行コストを大幅に抑えられる。

この記事で紹介された技術は、日本のリージョンで使えますか？

AWS AgentCoreは東京リージョンを含む複数リージョンで提供されている。Google Agent EngineはVertex AI経由で利用可能だ。個別のサービスの日本リージョン対応は変動するため、導入検討時に最新の対応状況を確認することを推奨する。