🎥 YouTubeでも公開しています
Runtime OSとは何か?|OpenAI・Claude・AutoGen・LangGraphとの本当の違い

OpenAIやAnthropicをはじめ、多くのAIプラットフォームがAgentを構築する仕組みを提供し始めている。専門Agentへの委任、ツール呼び出し、状態管理、Human-in-the-loop、実行Traceなど、実用的なmulti-agentシステムを作るための部品は急速に整ってきた。
では、Runtime OSはそれらと競合する別のAgentフレームワークなのだろうか。
結論から言えば、違う。
Runtime OSは、より多くのAgentを作るための仕組みではない。AI、Agent、人間、業務システム、設備が関わる環境で、誰がDecisionを確定し、何を実行でき、どこで人が介入し、どのように責任をTraceするかを統制するための基盤である。
AI produces signals. Only the Runtime produces decisions.
Agents execute only approved, traceable decisions.
この違いは、単なる用語の違いではない。Agentを「仕事を完了する存在」として見るのか、組織的な意思決定と実行の一部として扱うのかという、システム設計の出発点の違いである。
Agent Frameworkが解く問題
現在のAgent SDKやmulti-agentフレームワークは、主に次の問いに答える。
- どのAgentにどの仕事を任せるか
- Agentがどのツールを使うか
- 複数の専門Agentをどう連携させるか
- Agentの状態、会話、ツール呼び出しをどう管理するか
- 実行をどう観測し、評価し、改善するか
例えば、OpenAI Agents SDKは、Agent loop、専門Agentへのhandoff、agents-as-tools、guardrails、承認待ちの再開、Traceを提供する。ドキュメントは、SDKがtool loopを実行し、handoff後にAgentを切り替え、承認が必要なときには実行を停止できることを説明している。OpenAI Agents SDK
AnthropicのClaude Agent SDKも、Claude Codeで用いられるtool、agent loop、context managementをPythonとTypeScriptから利用可能にする。Agentが計画し、ファイルを読み、コマンドを実行し、複数ステップの仕事を完了するための実行基盤である。Claude Agent SDK
AutoGenは、会話型single / multi-agentアプリケーションと、Actor modelに基づくイベント駆動・分散型のAgentシステム構築を扱う。AutoGen Core
LangGraphは、共有State、Node、Edgeを用いて、長時間・状態保持型のAgent workflowをグラフとして構成する。Human-in-the-loopを含む制御可能なAgent workflowの実装に向く。LangGraph Graph API
これらはいずれも重要である。Runtime OSは、それらを置き換える必要はない。むしろ、Runtime OSの中で Agent Runtime / Orchestration Layer として活用できる。
違いは「最終的に何を統制するか」にある
Agent frameworkの中心は、多くの場合、Agent runである。入力を受け、モデルが推論し、ツールを呼び、必要なら他のAgentに委任し、タスクの成果を返す。
Runtime OSの中心は、Agent runではなく Decision Lifecycle である。
Event / Interaction
→ Structured Signal
→ Context and Policy Evaluation
→ Decision
→ Boundary
→ Human Gate
→ Command Permit
→ Agent / Workflow Execution
→ Outcome
→ Decision Trace Ledger
この構成で、Agentの分析、提案、計画、再計画はすべてSignalまたはCandidateになる。Runtimeが、Purpose、Context、Policy、Permission、Risk、Delegation、Human Authorityを評価し、初めて Act、Ask、Stop を確定する。
つまり、Runtime OSはAgentを「Decisionの主体」ではなく、能力を持つ実行・分析コンポーネントとして扱う。
比較:Agent SDK、Multi-Agent Framework、Runtime OS
| 観点 | Agent SDK / Framework | Runtime OS |
|---|---|---|
| 中心概念 | Agent、tool loop、workflow、handoff | Decision、authority、boundary、trace |
| 主な責務 | タスク分解、Agent協調、ツール実行 | 判断確定、権限統制、Human Gate、実行許可 |
| Agentの位置づけ | 多くの場合、workflowの主体 | Signal生成者・分析者・承認済み実行者 |
| 実行権限 | アプリケーション実装に委ねられる | Command Permitで対象・操作・期限・回数を限定 |
| Human-in-the-loop | Agent runの承認・中断・再開 | 組織上の責任境界としてのHuman Gate |
| Trace | 開発・運用の観測、debug、評価 | EvidenceからOutcomeまでのDecision Traceと説明責任 |
| Policy | prompt、tool guardrail、アプリ実装 | Decision前のPolicy / Boundary評価と失効可能な委任 |
| 分散性 | 分散Agentの実装を支援可能 | 組織・拠点・機器ごとの権限境界をFederationする |
この表は、Agent SDKが弱いという意味ではない。OpenAI Agents SDKのguardrailsやresumable approval flows、LangGraphのhuman-in-the-loop、AutoGenの分散runtimeといった機能は、Runtime OSの実装に有用である。OpenAI Agents SDK LangGraph AutoGen
ただし、これらの機能だけでは、組織をまたぐ権限委任、実行Permitの失効、改ざん検知可能なDecision Ledger、現場の通信断時における限定自治を、アーキテクチャの中心に据えることにはならない。そこを明示的に設計するのがRuntime OSである。
OpenAI Agents SDKとの関係
OpenAI Agents SDKは、Runtime OSと最も接続しやすい実装基盤の一つである。
OpenAIの公式ドキュメントは、handoffを「会話の次の所有者を専門Agentへ移す」方式、agents-as-toolsを「管理Agentが専門Agentを限定された能力として呼ぶ」方式として区別している。Orchestration and handoffs
Runtime OSから見ると、どちらもAgent Coordinationの方式である。しかし、handoffによって会話の所有者が移っても、外部業務を実行するDecision Authorityまで自動的に移るわけではない。
たとえば、返金専門Agentが返金案を作成し、必要情報を収集することはできる。しかし、返金の確定には、顧客契約、金額上限、不正リスク、担当者権限、承認条件をRuntimeが評価し、必要ならHuman Gateを通す。その上で発行されたCommand Permitだけが、Enterprise Gatewayを通じた返金APIの実行を可能にする。
OpenAIのTraceは、モデル呼び出し、ツール、handoff、guardrailなどを観測する上で有用である。一方、Runtime OSのDecision Traceは、開発時の可観測性に留まらず、なぜそのDecisionが許可されたのか、どのPolicyとEvidenceが適用され、誰が承認し、結果が何だったのかを組織的に残す。
AnthropicのAgent SDKとの関係
Claude Agent SDKは、Agent loop、tool execution、context managementを提供し、Claude Codeと同様の実行能力をアプリケーションへ組み込める。Claude Agent SDK
これは、CDR Edgeにおける専門Agentの実装や、ローカル環境での分析・コード生成・運用支援に向く。特に、現場での調査、文書解析、保全手順の作成、限定された作業の実行準備といった用途では、強力なAgent能力をRuntime OSの下へ配置できる。
しかし、Agent loopそのものは、何を組織として許可するかを決める機構ではない。Runtime OSでは、Claude Agent SDKを含む任意のAgentランタイムからの出力をSignalとして受け、同じPolicy、Boundary、Human Gate、Traceの規律へ入れることができる。
この分離により、モデルやAgent SDKを入れ替えても、組織のDecision Policyと責任構造を維持できる。
AutoGen・LangGraphなどとの関係
AutoGenは、Agent間の非同期メッセージング、分散Agent Runtime、複数の協調パターンを提供する。LangGraphは、StateとGraphを中心に、Agentの長期実行、分岐、Human-in-the-loopを設計する。
これらは、Runtime OSの Operational Layer を実装する有力な選択肢である。
flowchart TD
I["Interaction Core v2"] --> S["Structured Signal"]
S --> R["Decision Runtime"]
R --> B["Policy / Boundary / Human Gate"]
B --> P["Command Permit"]
P --> A["OpenAI / Claude / AutoGen / LangGraph\nAgent Orchestrator"]
A --> G["Enterprise Gateway"]
G --> O["Outcome"]
R --> L["Decision Trace Ledger"]
O --> L
Agent frameworkをRuntime OSの内側に置くことで、フレームワークごとに異なるAgentの実装方式を、共通のDecision Contractで統合できる。
既存ベンチマークが測るもの
Agentの能力を評価するベンチマークも進化している。
GAIA は、推論、マルチモーダル理解、Web閲覧、ツール利用を必要とする現実的な質問を通じて、General AI Assistantを評価する。問題の正答という形で、Agentが複数の能力を統合して仕事を完了できるかを測る。GAIA
AgentBench は、8つのインタラクティブ環境で、LLMをAgentとして用いたときの推論、意思決定、長期的な指示追従を評価する。AgentBench
OSWorld は、Web、デスクトップアプリケーション、ファイルI/Oを含む実コンピュータ環境で、multimodal Agentがタスクを遂行できるかを評価する。元論文では369のタスクを整備し、実行結果に基づく評価を行う。OSWorld
Agent-SafetyBench は、Agentがツールやインタラクティブ環境に接続されたときの安全性を扱い、349環境・2,000テストケースで8種のリスクを評価する。Agent-SafetyBench
これらは重要である。しかし、主に測っているのは「Agentがタスクを成功させられるか」「安全であるか」「コンピュータを操作できるか」である。
既存ベンチマークだけでは測れないこと
Runtime OSの観点では、タスク成功率だけでは足りない。現実の業務や社会システムでは、正しい結果に到達したとしても、権限のないAgentが実行していれば問題である。人の承認を飛ばしていれば問題である。再現可能なEvidenceが残っていなければ、後から説明できない。
Runtime OSが追加で評価すべき観点は、少なくとも次の五つである。
| 評価軸 | 問い |
| Decision Validity | 適切なContext、Policy、Permissionを根拠にDecisionされたか |
| Authority Integrity | Delegationの範囲・期限・失効を超えて実行していないか |
| Human Gate Fidelity | 必要な場面で正しい人へ、必要な根拠付きでエスカレーションしたか |
| Trace Completeness | Signal、Evidence、Decision、Permit、Execution、Outcomeが共通Trace IDでつながるか |
| Fail-Closed Behavior | Policy、Identity、通信、Ledgerが不明・不整合な場合に危険な実行を止められるか |
これは既存ベンチマークを否定するものではない。GAIA、AgentBench、OSWorldはAgent Capabilityを測る。Agent-SafetyBenchはAgent Safetyを測る。Runtime OSは、その上に Decision Governance と Accountable Execution の評価を加える。
言い換えれば、Agentが「できるか」を測るだけでなく、その行為を許可してよいか、誰が責任を持つのか、後から証明できるかを測る必要がある。
Runtime OS Benchmarkへの展望
将来的には、既存のAgent benchmarkを置き換えるのではなく、その実行環境の上にRuntime OS評価層を重ねられる。
たとえばOSWorldのような環境に、次の条件を加える。
- 発注、送信、削除、支払い、設備制御など、影響度の異なる操作を混在させる
- Agentごとに異なるRole、Scope、金額上限、データアクセス範囲を与える
- Policy Versionの更新、Permit失効、Identity検証失敗、ネットワーク断を途中で発生させる
- Human Gateが必要なケースでは、Evidenceと選択肢を持つ承認要求を生成させる
- 最終成果だけでなく、Traceの完全性、権限逸脱、危険操作の停止を採点する
こうした評価では、「すべてを自律実行したAgent」が最良とは限らない。必要なときにAskし、権限がなければStopし、確実なEvidenceがある範囲でだけActできるRuntimeの方が、現実の組織では信頼できる。
おわりに
OpenAI、Anthropic、AutoGen、LangGraphなどが提供するAgent技術は、Runtime OSの敵ではない。それらは、専門性を持つAgentを作り、協調させ、実行するための重要な実装層である。
Runtime OSが問うのは、その一段上である。
誰がDecisionを確定するのか。誰が外部行為を許可するのか。Agentの能力を、組織のPolicy、Human Authority、Traceabilityとどう結び付けるのか。
AIの能力が上がるほど、この問いは重要になる。Agentがより多くのことをできるようになるからこそ、Agentを主権者にせず、DecisionをRuntimeへ、責任をHuman GateとLedgerへ結び直す必要がある。
Runtime OSとは、Agentを増やすためのOSではない。AIの能力を、説明可能で、統制可能で、信頼できる行為へ変換するためのDecision Infrastructureである。
参考資料
- OpenAI Agents SDK
- Claude Agent SDK
- AutoGen Core
- LangGraph Graph API
- GAIA: a benchmark for General AI Assistants
- AgentBench: Evaluating LLMs as Agents
- OSWorld: Benchmarking Multimodal Agents
- Agent-SafetyBench: Evaluating the Safety of LLM Agents

Chinoba
Intelligence as Relationship
Research Platform
founded by
Masao Watanabe
AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance
Related Research
この記事は Chinoba Knowledge Base の一部です。

コメント