# 長時間動くAIエージェントを止めずに再開する エージェントOSの役割

- 媒体: 知能圏（CHINOUKEN）
- 公開日: 2026-08-14
- カテゴリー: エージェント・ソフトウェア
- タグ: エージェントOS、実行環境、オーケストレーション
- 想定読了時間: 約20分
- 調査基準日: 2026-08-14
- 出典: 21件（末尾の「参照リンク」に番号順で記載）
- ページ: https://www.chinouken.com/articles/why-ai-agents-need-an-os
- このMarkdown: https://www.chinouken.com/articles/why-ai-agents-need-an-os.md
- 利用条件: 引用する場合は出典として「知能圏（chinouken.com）」と該当ページのURLを明記してください。本文の再配布は行わず、要約や引用の範囲で使ってください。

エージェントOSは、長時間動くAIエージェントの状態、権限、実行記録、途中再開を管理する共通基盤です。モデルが外部サービスを操作し、別のエージェントへ仕事を渡すほど、この管理機能が重要になります。2026年には各社が別々の形で実装を進めていますが、共通仕様はまだありません。

![人の依頼を受けたエージェントの仕事を、状態保存、権限制御、実行記録、途中再開によって完了まで追跡する概念図](https://www.chinouken.com/images/articles/why-ai-agents-need-an-os/hero-concept-slide-v2.png)

*エージェントOSは、仕事の状態、権限、実行記録、途中再開を管理します。*

## 長時間の仕事を管理する共通基盤

AIエージェントが数時間稼働し、コードを生成し、顧客データを読み取り、顧客管理システムを更新し、別のエージェントへ調査を頼むと、会話の外に作業状態と操作結果が残ります。途中で止まった仕事を再開し、誰の権限で何を行ったかを追跡する管理機能が必要になります。

従来のOSは、プログラムへCPU、メモリ、ファイル、ネットワークを割り当て、ほかのプログラムや利用者から隔離します。エージェント向けのOSも考え方は似ていますが、追加で扱うのは、モデルへ渡す文脈、外部サービスを操作するツール、企業の権限、利用者への承認、実行経路の記録です。

ここでいうツールは、エージェントが外部へ働きかける操作手段のことです。API呼び出し、CLIのコマンド実行、ブラウザー操作、別エージェントへの作業委任などが含まれます。モデルはどのツールを使うかを判断しますが、どこまで使えるかを決めるのは基盤です。

2026年7月の研究論文は、現在のエージェント基盤を、POSIX以前のOSやKubernetes以前のクラウドにたとえています。部品は増えていますが「タスク」「メモリ」「権限」「失敗」が何を意味し、どのような保証があるかについての共通理解はまだありません。

![人の目的とモデルの判断を、統制面と実行面からなるエージェントOSが、業務システムでの権限付き操作へ変える構造](https://www.chinouken.com/images/articles/why-ai-agents-need-an-os/figure-agent-os-planes.png)

*既存OSの上で、統制と実行を共通化する*

## エージェントOSと呼ばれる製品群

「エージェントOS」が分かりにくいのは、異なる製品が違う課題を解こうとしながら、同じOSの比喩に向かっているためです。大きく四つの系統に分けると、各社の発表を同じ軸で比較しやすくなります。

一つの製品が複数の系統にまたがることもあります。Googleは社内利用向けアプリと開発基盤を持ち、Microsoftは統制、開発フレームワーク、Windows操作向けクラウドPCを別製品として組み合わせています。分類は優劣を決めるものではなく、どこから課題に入る設計かを示すためのものです。

ハーネスとOSも同じではありません。ハーネスは、モデルへ状況を渡し、ツールを実行し、結果を再びモデルへ返す反復処理を担います。OSはその外側で、複数のハーネスやエージェントに共通する状態、権限、実行場所、監査を管理します。実際の製品では、この境界が固定されないことが多いです。

**エージェントOSと呼ばれる四つの系統**

| 系統 | 主な利用者 | 中心の問い | 代表例 |
| --- | --- | --- | --- |
| 業務環境 | 社員、業務部門 | どこで仕事を頼み、成果をどう残すか | Cloudflare OS、Gemini Enterpriseアプリ、ServiceNow |
| 実行基盤 | エージェント開発者 | 長時間、安全、再開可能にどう動かすか | AgentCore、Agent Runtime、Managed Agents |
| 統制面 | IT、セキュリティ部門 | 何が動き、どの権限とデータを使うか | Agent 365、AI Control Tower、Agent Gateway |
| 研究カーネル | 研究者、基盤開発者 | エージェント固有の資源と保証をどう定義するか | AIOS、2026年のAgent OS論文 |

## 2026年7月以降の変化

2026年後半の動きを見ると、競争の中心が『エージェントを作れるか』から『長く、安全に、複数で運用できるか』へ移ったことが分かります。個別の更新は別物に見えても、長時間タスク、レジストリ、ゲートウェイ、メモリ、エージェント間通信が共通語になりました。

ここで注意したいのは、ドキュメントの更新日、APIのバージョン名、機能の一般提供日が一致しないことです。たとえば Claude Managed Agents のメモリAPIには `agent-memory-2026-07-22` という識別子がありますが、この日付が一般提供日を直接示すわけではありません。

**2026年7月以降に確認した主な更新**

| 日付 | 発表または更新 | この記事での意味 |
| --- | --- | --- |
| 07月10日 | Microsoft Agent Framework文書を更新 | Agent、長時間処理向けハーネス、明示的なワークフローを三本柱として整理 |
| 07月17日 | GoogleがAgent Platformの13実装例を公開 | 永続セッション、メモリ、長時間タスク、承認後の再開、ゲートウェイを一つのプラットフォームで扱う |
| 07月27日 | Agent OSの共通機能を提案する論文を公開 | 共通抽象と保証がまだ定まっていないことを整理 |
| 07月28日 | MCP 2026-07-28仕様を公開 | 接続をステートレス化し、長時間タスク、認可、ルーティングを強化 |
| 08月04日 | 二つのPlaneで構成するAgent OS論文を公開 | 統制面と実行面を分けるベンダーニュートラルな参照構造を提案 |
| 08月06日 | AWS Agent Registryが専用ネームスペースへ移行 | Agent、MCPサーバー、スキルの登録、承認、検索が独立した基盤機能になる |
| 08月05日 | Cloudflare OS v2をオープンソース公開 | 社員向けワークスペース、権限仲介、生成アプリ、実行基盤を縦に統合 |

> 観測メモ: 日付は発表日、文書更新日、仕様公開日を区別しています。API名に含まれる日付だけで一般提供日とは判断していません。

## エージェントOSの管理対象

エージェントOSの機能を製品名から離して見ると、六つに整理できます。すべてを一社が提供する必要はありませんが、実務でエージェントを動かすシステム全体としては、どこかが必ず担う必要があります。

一般的なOSなら、プログラムが終了コード0を返せば成功と見なせる場面が多いですが、エージェントでは、API呼び出しが成功しても、違う顧客のレコードを更新したり、古い情報にもとづいて誤判断をしたりする可能性があります。基盤は「動いたか」だけでなく、「目的を満たしたか」を元データと評価規則で照合します。

2026年8月の参照アーキテクチャ論文では、この機能を二つの面に分けて説明しています。制御とガバナンス面の担当は目的、権限、信頼、監査、人的監督で、ランタイムと調整面の担当はライフサイクル、ワークフロー、モデルとツールの経路付け、メモリ、スケジュールです。Linux、Windows、コンテナー、物理基盤はその下位に残ります。

- 状態と文脈：タスク、会話、ファイル、承認待ち、失敗地点を保存し、モデルへ渡す情報を選ぶ
- 実行と復旧：生成コード、CLI、ブラウザーを隔離し、途中再開、再試行、取り消しを行う
- ツールと権限：APIや外部サービスを発見し、対象、操作、有効時間を必要な範囲へ絞る
- 統制と来歴：何を読んだ結果なのかを記録し、承認や外部送信の規則を適用する
- 観測と評価：誰の代理で何をしたかを追跡し、意味上の完了条件を検査する
- 発見と委任：別のエージェントを見つけ、仕事、期限、予算、最小権限を渡す

## 一件の営業予測で起きること

「今月の営業予測を作成し、異常な案件を確認し、経営会議用の資料を準備する」という依頼で、エージェントの動きを追ってみます。まず利用者が渡すのは、締切、予測の基準、確認が必要な金額、外部送信前の承認条件です。基盤は依頼者と担当エージェントをタスクに紐づけ、使える予算、スキル、データ、ツールを読み込みます。

エージェントが次に決めるのは、CRMとデータウェアハウスから情報を取得する方法です。構造化されたAPIがあればAPIを使い、社内ツールがMCPとして提供されていればMCP経由で呼び出し、集計コードは隔離されたサンドボックスで実行します。サンドボックスは、生成コードが端末全体や社内ネットワークへ無制限に接触しないようにする実行環境です。

異常な案件は、営業分析を専門にする別のエージェントへ渡せます。ただし元の権限を丸ごと複製せず、渡すのは対象案件を読む権限と回答期限だけです。戻った結果はCRMの元レコード、過去の予測、計算結果と照合し、食い違いがあれば再調査します。

最後にダッシュボードと会議資料を作成し、利用したデータ、計算、エージェント間の受け渡し、失敗と再試行を記録します。メール送信やCRM更新は人の承認後に行い、却下された操作は反映されません。モデルが担当するのは解釈、計画、ツール選択、再計画で、OSが担当するのは何を保持するか、どこで実行するか、何を残すか、どこで止めるかです。

![人の依頼から、権限確認、APIとMCP、隔離実行、別エージェントへの委任、検証、承認、記録まで進む営業予測の流れ](https://www.chinouken.com/images/articles/why-ai-agents-need-an-os/figure-delegated-work.png)

*一件の仕事を、権限・実行・検証・承認へ分ける*

## Cloudflare OSが一つにしたもの

Cloudflare OSは、インターネット基盤企業Cloudflareが社内利用から作ったAI作業環境です。名前にOSがあるからといって、PCを起動する基本ソフトではありません。社員がワークスペースでエージェントへ依頼し、成果を文書だけでなく、画面、操作用API、保存データを持つ小さなアプリとして残せます。

外部サービスの間に置かれるゲートキーパーは、GitHubやGoogleなどへの接続を仲介する専用モジュールです。ログイン情報を生成コードから隠し、「このリポジトリを読む」「この文書だけ更新する」のように権限を絞り、操作を記録します。副作用のある処理では結果を模擬し、エージェントを進めた後に人がまとめて承認または却下する設計も説明されています。

ガジェットはエージェントが作る小さなアプリ、ブループリントはその再利用可能な設計図です。各ガジェットはダイナミックワーカーと呼ばれる隔離実行環境で動作し、永続状態はCloudflareのデュラブルオブジェクトを使います。ランタイムや権限要素だけでなく、日常画面と生成ソフトウェアの配布単位までを一体化した点が特徴です。

一方、公開されたv2はアーリーアクセスです。派生データの来歴、生成アプリの脆弱性、依存関係の更新、ゲートキーパーの品質が大規模運用でどこまで維持されるかは、まだ検証が要ります。Cloudflare OSは、すべてのSaaSを置き換えるという約束をした製品ではありません。記録の原本となるシステムは残り、固定画面と人の手作業の一部はそのまま残る可能性があります。

> 観測メモ: Cloudflareの安全性に関する強い表現はベンダーの設計上の主張です。安全を意図した設計と、第三者により実証された安全性は分けて評価します。

## 各社は別の入口から同じ場所へ向かう

主要基盤を比較するときは、機能の多さではなく、何を自社で引き受け、何を利用者に残すかを見る必要があります。AgentCoreは実行前のツール呼び出しを検査するポリシーと、エージェント、MCPサーバー、スキルを承認・検索するレジストリを持ちます。Googleはエージェントランタイムとメモリバンクに、社員向けアプリ、エージェントゲートウェイ、A2Aを組み合わせる構成です。

MicrosoftはAgent 365で統制し、Agent Frameworkで長時間ワークフローを作り、Windows 365 for AgentsでWindows操作用の使い捨てクラウドPCを貸し出します。OpenAI Frontierは企業データを共有文脈へつなぎ、エージェント実行、アイデンティティ、評価、監査をまとめる製品です。Claude Managed Agentsは永続セッションとサンドボックスを持つハーネスとして、複数のエージェントを独立したスレッドで動かします。

ServiceNowとSalesforceは、すでに持っている業務データ、権限、ワークフローをAgent向けの操作面へ広げています。Lettaは永続メモリを持つエージェントをステートフルサービスとして扱い、AIOSはLLM、メモリ、ストレージ、ツールをカーネルが管理する研究実装です。

**主要基盤の出発点と担当範囲**

| 基盤 | 出発点 | 主に引き受ける範囲 | 現時点の境界 |
| --- | --- | --- | --- |
| Cloudflare OS | 社員向けAI業務環境 | ワークスペース、権限仲介、生成アプリ、ワーカー実行 | v2はアーリーアクセス。組織固有の統合と運用が必要 |
| Amazon Bedrock AgentCore | 開発者向けエージェント基盤 | ランタイム、メモリ、ゲートウェイ、アイデンティティ、ポリシー、レジストリ、評価 | 社員向けの業務画面とワークフローは利用側が設計 |
| Gemini Enterprise Agent Platform | 開発・実行・統制の統合 | ADK、ランタイム、メモリ、アイデンティティ、ゲートウェイ、サンドボックス、A2A | 製品群が広く、利用形態ごとの構成選択が必要 |
| Microsoft Agent 365群 | 企業IDとMicrosoft 365 | レジストリ、Entra、Purview、Defender、フレームワーク、Agent向けクラウドPC | 統制、開発、PC実行が別レイヤーに分かれる |
| OpenAI Frontier | エンタープライズ向けエージェント基盤 | ビジネスコンテキスト、エージェント実行、アイデンティティ、評価、監査 | 公開情報は概念と導入事例が中心 |
| Claude Managed Agents | マネージドハーネス | 長時間セッション、サンドボックス、ツール、メモリ、複数エージェント | ベータ。組織横断レジストリや業務アプリ配布は別途必要 |
| ServiceNow AI Platform | ワークフローとシステム・オブ・レコード | Agent Studio、オーケストレーター、ファブリック、コントロールタワー | ServiceNow上の業務状態を中心に価値を出す |
| Letta／AIOS | メモリ／研究カーネル | 永続エージェント、メモリ、LLM・ツール・ストレージの資源管理 | 企業全体の統制面より、状態とカーネル抽象に重心 |

## MCPとA2AだけではOSにならない

MCPはModel Context Protocolの略で、エージェントがデータ、API、ツールを共通の形式で扱うための接続規約です。A2AはAgent2Agent Protocolの略で、異なる会社やフレームワークで作られたエージェント同士が、相手の内部実装を公開せずに能力を見つけ、仕事をやり取りするための規約です。簡単に言えば、MCPはエージェント→ツールの接続を、A2Aはエージェント→エージェントの接続を主に扱います。

2026年7月28日のMCP仕様は、接続状態に依存しないリクエスト／レスポンス方式へ移行し、長時間タスクを表すタスク、認可の強化、ゲートウェイで振り分けやすいヘッダー追加を行いました。MCPが本番運用の部品へ進んだ重要な更新です。

それでもMCPやA2AだけでOSにはなりません。接続先を呼び出せることと、その操作を取り消せることは別です。別のエージェントへ仕事を渡せても、元の人間から委任先まで責任を追跡できるとは限りません。プロトコルの上位に、権限、予算、期限、状態、承認、復旧、監査を実施する基盤が必要です。

7月の研究論文も、MCPとA2Aは通信を前進させる一方、実行保証までは定義していないと整理しています。OSに相当する層は、プロトコルを置き換えるのではなく、プロトコル経由の操作と委任に共通規則を適用するところです。

## エージェント同士の委任が中心になる

最終的には、利用者が一つのエージェントへ目的を伝え、その裏で複数の専門エージェントがやり取りする形が増えるはずです。単一エージェントへ全ツール、全知識、全権限を持たせるより、営業分析、法務確認、資料作成、システム更新を分けた方が、必要な文脈と権限を絞りやすいでしょう。

現在の製品にもその兆候があります。GoogleのAgent PlatformはA2Aによる委任を組み込み、ServiceNowは外部エージェントとワークフローをつなぎます。Claude Managed Agentsではコーディネーターが複数種類のエージェントを登録し、それぞれ独立した文脈を持つスレッドへ仕事を渡せます。

ただし、分散すれば自動的に安全になるわけではありません。エージェント間のメッセージに悪意ある命令が混じることがあり、元の権限をそのまま渡せば委任のたびに被害範囲が広がります。途中のエージェントが失敗を成功と報告すると、最終結果だけを見ても原因追跡が困難になります。

OSが管理する対象は通信そのものより委任の連鎖です。誰の依頼か、何の目的か、どのデータを渡したか、委任先が使えるツールは何か、いつ権限が切れるか、どれくらい使えるか、どこで人へ戻るかを、すべてのエージェントにまたがって保持します。

人が使う入口は、チャット、メール、既存の業務画面、音声など複数あります。エージェントOSは、どの入口から依頼しても、同じ状態、権限、履歴の上で仕事を続けられるようにします。

## 共通仕様はまだない

2026年8月時点で、エージェント向けのPOSIXやKubernetesに相当する共通仕様はありません。エージェントのライフサイクル、スキルの依存関係と署名、自然言語で指定された操作の副作用、文脈から情報を捨てる基準、意味上の失敗、エージェント間委任で権限を絞る方法は、どれも十分に標準化されていません。

現在の製品は、この未成熟な全体の一部を先に固めています。AWSは実行部品とレジストリ、Microsoftは企業IDと統制、Googleはランタイムとエージェント間連携、Anthropicは長時間ハーネス、ServiceNowとSalesforceは業務の正本、Cloudflareはワークスペースから生成アプリまでを厚くしています。

ここからは筆者の見立てですが、短期的には一つのエージェントOSが市場を独占するより、企業が既存のクラウド、ID、データ基盤に合わせて複数製品を組み合わせる可能性が高いでしょう。その一方で、タスク、エージェントID、ケイパビリティ、トレース、チェックポイント、エージェントカードのような共通抽象は、製品をまたいで揃っていくはずです。

## 状態 権限 実行を共通に管理する

AIエージェントの出力は、長く残る作業状態、会社の権限、実行コード、別のエージェント、外部サービスの変更へつながります。エージェントOSは、この一連の仕事を共通の規則で管理します。

Cloudflare OSは、この問題をワークスペース、ゲートキーパー、ガジェット、ワーカーという一体設計で提示しました。ほかの各社はランタイム、レジストリ、アイデンティティ、ゲートウェイ、メモリ、ワークフロー、コントロールタワーといった異なる入口から、同じ管理層へ近づいています。

将来、利用者は目的を一つのエージェントへ渡し、その裏で複数のエージェントがAPI、コマンドライン、ブラウザ、業務システムを使う場面が増えるでしょう。エージェントOSは、誰の依頼か、何を見られるか、どこまで実行できるか、誰へ仕事を渡せるか、失敗時にどこから再開するかを管理します。

## 参照リンク

1. [Cloudflare: Cloudflare OS：エージェント、アプリ、作業のためのオープンプラットフォーム](https://blog.cloudflare.com/ja-jp/cloudflare-os/)
2. [Cloudflare: cloudflare/cloudflare-os — source code and architecture](https://github.com/cloudflare/cloudflare-os)
3. [Cloudflare: Enterprise AI agent workspace — reference architecture](https://developers.cloudflare.com/reference-architecture/diagrams/ai/enterprise-ai-agent-workspace/)
4. [AWS: What is Amazon Bedrock AgentCore?](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html)
5. [AWS: Get started with AWS Agent Registry](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-get-started.html)
6. [Google Cloud: The new Gemini Enterprise: one platform for agent development, orchestration, and governance](https://cloud.google.com/blog/products/ai-machine-learning/the-new-gemini-enterprise-one-platform-for-agent-development)
7. [Google Cloud: 13 hands-on demos to build on Gemini Enterprise Agent Platform](https://cloud.google.com/blog/products/ai-machine-learning/13-demos-on-gemini-enterprise-agent-platform)
8. [Microsoft: Overview of Microsoft Agent 365](https://learn.microsoft.com/en-us/microsoft-agent-365/overview)
9. [Microsoft: Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/overview/)
10. [Microsoft: Identity and security in Windows 365 for Agents](https://learn.microsoft.com/en-us/windows-365/agents/identity-security)
11. [OpenAI: Introducing OpenAI Frontier](https://openai.com/index/introducing-openai-frontier/)
12. [Anthropic: Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview)
13. [Anthropic: Multiagent orchestration](https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration)
14. [ServiceNow: AI Agents — Agent Studio, Orchestrator, Fabric and Control Tower](https://www.servicenow.com/products/ai-agents.html)
15. [Salesforce: Agentforce 360 Platform](https://www.salesforce.com/platform/agentforce-platform/)
16. [Letta: Letta Documentation — platform for stateful agents](https://docs.letta.com/)
17. [AGI Research: AIOS: AI Agent Operating System](https://github.com/agiresearch/AIOS)
18. [Model Context Protocol: The 2026-07-28 Specification](https://blog.modelcontextprotocol.io/posts/2026-07-28/)
19. [A2A Project: A2A and MCP: Detailed Comparison](https://github.com/a2aproject/A2A/blob/main/docs/topics/a2a-and-mcp.md)
20. [arXiv: Towards an Agent Operating System — Lessons from Classical and Cloud OS](https://arxiv.org/abs/2607.25076)
21. [arXiv: The Agent Operating System: A Reference Operating Architecture for Distributed Agentic Systems](https://arxiv.org/abs/2608.03214)

2026-08-14時点の公式資料を確認しています。仕様は更新される可能性があります。

---

© 知能圏 https://www.chinouken.com/articles/why-ai-agents-need-an-os