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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主要基盤を比較するときは、機能の多さではなく、何を自社で引き受け、何を利用者に残すかを見る必要があります。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、メモリ、ストレージ、ツールをカーネルが管理する研究実装です。

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は、誰の依頼か、何を見られるか、どこまで実行できるか、誰へ仕事を渡せるか、失敗時にどこから再開するかを管理します。