既存のAgent Frameworkでは足りない──Runtime OSに最適化した独自フレームワークを作る

🎥 YouTubeでも公開しています

Runtime OS Architecture｜Centralized・Edge・Federatedで実現するAI意思決定基盤

Books: Runtime OS 実践ガイド: AI Agent • Human Gate • Decision Trace* 統合する実装アーキテクチャ

はじめに

OpenAI Agents SDK、Claude Agent SDK、AutoGen、LangGraphなどの登場によって、AI Agentを開発するための環境は急速に整備されつつある。

専門Agentへの委任。

ツール呼び出し。

Human-in-the-loop。

状態管理。

分散実行。

実際の業務で利用できるmulti-agentシステムを構築するための機能は、すでに十分に提供されている。

しかし、企業や社会システムへAIを導入すると、別の問題が現れる。

• 誰が最終的なDecisionを確定するのか
• Agentは何を実行してよいのか
• 人間はどのタイミングで介入すべきなのか
• 権限の範囲をどのように制限するのか
• 後から誰が責任を負うのか
• なぜその判断に至ったのかを証明できるのか

既存のAgent Frameworkは、この問題を十分には解決できない。

だからこそ、Runtime OSに最適化した独自のフレームワークが必要になる。

この発想は、「新しいAgent SDKを作る」という意味ではない。

既存の優れたAgent Frameworkを活用しながら、その上にDecisionを統制する新しい実行基盤を構築するという考え方である。

---

Agent Frameworkが最適化しているもの

現在のAgent Frameworkは、主に次のような課題を解決している。

• タスクの分解
• 専門Agentへの委任
• ツールの実行
• 状態管理
• 会話管理
• Agent間の協調
• 実行の監視
• 実行結果の評価

つまり、Agentを効率よく動かすことが目的である。

しかし、企業の実務は単なるタスク実行ではない。

例えば、AIが顧客への返金を提案したとする。

Agent Frameworkの観点では、

1. 顧客情報を取得する
2. 契約を確認する
3. 返金額を計算する
4. 支払いAPIを呼び出す

という流れになる。

しかし、企業の視点では、それだけでは不十分である。

• 契約上、返金は許可されているのか
• 担当者に承認権限はあるのか
• 返金額は上限を超えていないか
• 不正利用の可能性はないか
• 上長の承認は必要か
• 監査証跡は残っているか

これらは、Agentの能力とは別の問題である。

---

AgentではなくDecisionを中心に設計する

Runtime OSでは、設計の中心が変わる。

中心となるのはAgentではない。

Decisionである。

Event
 ↓
Structured Signal
 ↓
Context Evaluation
 ↓
Policy Evaluation
 ↓
Decision
 ↓
Boundary Check
 ↓
Human Gate
 ↓
Command Permit
 ↓
Agent Execution
 ↓
Outcome
 ↓
Decision Trace Ledger

Agentは分析を行う。

提案を行う。

計画を立案する。

しかし、それらはすべてSignalに過ぎない。

最終的なDecisionを確定するのはRuntimeである。

AI produces signals.

Only the Runtime produces decisions.

Agents execute only approved, traceable decisions.

---

Runtime OS専用フレームワークの設計

既存のAgent Frameworkをそのまま利用するのではなく、Runtime OS専用のフレームワークを設計するとすれば、次のような構成になる。

Layer 1: Interaction Core

すべての入力を標準化する。

• ユーザー入力
• センサー情報
• 業務イベント
• システム通知
• Agentからの提案

これらをStructured Signalへ変換する。

---

Layer 2: Decision Runtime

Runtime OSの中核となる層である。

{
  "signal": {},
  "context": {},
  "policy": {},
  "risk": {},
  "delegation": {},
  "decision": "Act | Ask | Stop"
}

この層がDecisionを確定する。

---

Layer 3: Policy Engine

Decisionの妥当性を評価する。

評価項目の例は次のとおりである。

• 組織ポリシー
• 業務ルール
• 法規制
• コンプライアンス
• データアクセス権
• 金額上限
• 時間制限

---

Layer 4: Boundary Engine

実行可能な範囲を制限する。

boundary:
  action:
    - read
    - create
    - update

  prohibited:
    - delete_customer
    - transfer_money

  amount_limit:
    max: 100000

  expiration:
    ttl: 24h

Boundaryが存在しなければ、Agentは無制限に行動できてしまう。

---

Layer 5: Human Gate

人間の承認を管理する。

Low Risk
 ↓
Automatic Execution

Medium Risk
 ↓
Manager Approval

High Risk
 ↓
Executive Approval

Human-in-the-loopは、単なる承認機能ではない。

組織の責任境界そのものである。

---

Layer 6: Command Permit

実行権限をトークンとして発行する。

{
  "action": "refund",
  "target": "customer_123",
  "scope": "finance",
  "expires": "2026-08-21T00:00:00Z",
  "max_execution": 1
}

Permitが存在しなければ、Agentは外部システムを操作できない。

---

Layer 7: Agent Runtime Layer

ここで初めて既存のAgent Frameworkを利用する。

Runtime OS
        ↓
OpenAI Agents SDK

Claude Agent SDK

AutoGen

LangGraph
        ↓
Enterprise Gateway

既存のフレームワークを置き換える必要はない。

OpenAIはOpenAIのまま使う。

ClaudeはClaudeのまま使う。

AutoGenもLangGraphもそのまま使う。

ただし、それらはDecision Authorityを持たない。

あくまでもRuntime OSの内部で動作する実装コンポーネントとして扱う。

---

Runtime OSのための新しいBenchmark

既存のBenchmarkは、

• GAIA
• AgentBench
• OSWorld
• Agent-SafetyBench

などを中心に発展している。

しかし、Runtime OSでは別の評価指標が必要になる。

評価項目	評価内容
Decision Validity	Decisionは適切だったか
Authority Integrity	権限を逸脱していないか
Human Gate Fidelity	適切な承認が行われたか
Trace Completeness	監査証跡は完全か
Fail-Closed Behavior	異常時に安全に停止できたか

これらは、Agentの性能を測る指標ではない。

組織として安全にAIを運用できるかを測る指標である。

---

おわりに

次世代のAIシステムは、「より賢いAgent」を競う時代から、「より信頼できるDecision」を競う時代へ移行するだろう。

重要なのは、Agentを増やすことではない。

重要なのは、AIの能力を組織の意思決定へ安全に統合することである。

そのためには、Agent Frameworkだけでは足りない。

必要なのは、Decisionを統制するためのRuntime OSである。

そして、そのRuntime OSを実装するためには、既存のAgent Frameworkを単純に利用するだけではなく、Decision・Authority・Human Gate・Traceを中心に据えた、新しいRuntime OS専用フレームワークが必要になる。

それは、新しいAgent Runtimeではない。

AI、Agent、人間、組織、設備を統合するためのDecision Infrastructureなのである。