Runtime OSは、OpenAI・Anthropic・既存Multi-Agentシステムと何が違うのか

Knowledge Base Archive この記事は Chinoba Knowledge Base の技術アーカイブです。 Chinoba.orgを見る →

🎥 YouTubeでも公開しています

Runtime OSとは何か?|OpenAI・Claude・AutoGen・LangGraphとの本当の違い

Runtime OSとは何か?|OpenAI・Claude・AutoGen・LangGraphとの本当の違い

Books: 実践 Multi-Agent Systems: OpenAI Agents SDK・Claude Agent SDK・AutoGen・LangGraphを統合するChinoba Decision Runtime実装ガイド

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を評価し、初めて ActAskStop を確定する。

つまり、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 GovernanceAccountable 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である。

参考資料

Related Research

この記事は Chinoba Knowledge Base の一部です。

Chinoba Research
Chinoba-lab Open Source
Books and Library

コメント

タイトルとURLをコピーしました