Runtime OSの構成案──中央集権・Edge協調・Federated Runtimeをどう使い分けるか

🎥 YouTubeでも公開しています

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

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

生成AIやAI Agentが企業や社会の業務へ入るとき、問われるのは「どのモデルが最も賢いか」だけではない。

誰が判断を確定するのか。誰が実行を許可するのか。境界を越えるとき、どの権限と責任が引き継がれるのか。そして、その過程を後から再現できるのか。

こうした問題を扱う実行基盤を、ここでは Runtime OS と呼ぶ。

Runtime OSの中心原則は明確である。

AIはSignalを生成する。Decisionを確定するのはRuntimeだけである。

AIの出力はDecisionではない。Agentの提案もDecisionではない。さらに、Decisionが確定したことと、外部へのExecutionが許可されたことも同じではない。

この記事では、Runtime OSを実装するための三つの構成──中央集権型、Central RuntimeとCDR Edgeの協調型、そしてFederated CDR Edge型──を比較し、どのように選ぶべきかを考える。

Runtime OSが扱うもの

Runtime OSは、モデルを呼び出すためだけのGatewayでも、Agentを順番に動かすだけのOrchestratorでもない。Signal、Context、Policy、Permission、Risk、Humanの判断を結び付け、行為の可否を確定する層である。

基本フローは次のようになる。

Event / Interaction
  → Structured Signal
  → Context and Policy Evaluation
  → Decision Runtime
  → Boundary Check
  → Human Gate (when required)
  → Execution Permit
  → Execution
  → Decision Trace

ここで、interaction-core-v2 はInput / Interaction Layerとして機能する。会話、文書、センサー、他Agentからの提案、業務イベントを、構造化されたSignalとEvidenceへ変換する。しかし、それ自身はDecisionを確定しない。

Multi-Agent Orchestratorも同様である。複数の専門Agentに調査、比較、計画、実行準備を分担させることはできる。しかし、Agent間の会話や合意は実行権限を生まない。Runtimeが確定したDecisionと、限定されたExecution Permitがあって初めて、Agentは外部行為を実行できる。

Runtime OSを構成する主要部品

Enterprise Gatewayは、認証・認可、モデルルーティング、利用管理、監査ログを担う。Runtime OSの中では、単なる接続部品ではなく、外部世界へ出る前の重要なBoundaryになる。

構成案1：中央集権型Runtime

最も分かりやすいのは、企業の中央に一つのDecision Runtimeを置く構成である。各Agent、業務アプリケーション、Gatewayは中央RuntimeへSignalを送り、中央でDecision、Human Gate、Ledger記録を行う。

flowchart LR
    I["Interaction / Agents"] --> R["Central Runtime"]
    R --> H["Human Gate"]
    R --> G["Enterprise Gateway"]
    R --> L["Decision Trace Ledger"]

この方式は、全社共通のPolicy、ID、監査、Human Gateを整備しやすい。特に金融、公共、医療、大企業の基幹業務のように、統一的な統制と監査が重要な領域では有効である。

一方で、ネットワーク断や中央障害の影響を受けやすく、現場のリアルタイム性やデータ主権と衝突しやすい。すべての判断を中央へ送る設計は、Physical AI、工場、店舗、設備運用のような領域では重くなりやすい。

構成案2：Central RuntimeとCDR Edgeの協調型

次の段階は、現場・拠点・機器の近くに Chinoba Decision Runtime Edge（CDR Edge） を置き、中央Runtimeと役割分担させる構成である。

CDR Edgeは、署名済みPolicy BundleとDelegation Contractに基づき、委任済みの低〜中リスク判断をローカルで処理する。中央Runtimeは、全社横断の判断、高リスク処理、方針変更、正式なHuman Gate、Ledgerの最終確定を担う。

flowchart TB
    subgraph Edge["現場・拠点"]
        IC["Interaction Core v2"] --> E["CDR Edge"]
        E --> EG["Local Gateway Adapter"]
        E --> J["Local Trace Journal"]
    end
    subgraph Central["中央"]
        R["Central Runtime"] --> H["Human Gate"]
        R --> L["Decision Trace Ledger"]
    end
    E -->|"escalation / sync"| R
    R -->|"policy / delegation"| E
    J -->|"commit"| L

この構成では、中央は単なる巨大な実行サーバーではなく、Policy、Delegation、監査、広域最適化を扱うControl Planeとなる。CDR Edgeは現場で判断を実行するDecision Data Planeとなる。

現実の企業導入では、最も取り組みやすい構成である。既存のEnterprise AI GatewayやLedgerの投資を活かしながら、段階的にEdgeの自治性を高められるからである。

ただし、Edgeと中央のどちらが最終Decisionを持つかが曖昧だと、二重の主権が生まれる。委任範囲、期限、対象、制約、失効手順を明文化しなければならない。

構成案3：Federated CDR Edge型

より分散性を重視するなら、全ての拠点・組織・機器をCDR Edgeとして動かし、中央のRuntimeを必須にしない構成がある。これを Federated Runtime OS と呼ぶ。

各Edgeは、自らが責任を持つデータ、設備、業務範囲に対してDecisionを確定する。組織をまたぐ仕事では、相手を直接制御するのではなく、Delegation Contractと検証可能なTraceを用いて協調する。

flowchart TB
    A["CDR Edge A\n工場・店舗"] <-->|"delegation"| B["CDR Edge B\n企業・部門"]
    B <-->|"delegation"| C["CDR Edge C\n取引先・地域"]
    A --> L["Federated Trace Ledger"]
    B --> L
    C --> L

この方式の利点は、現場の可用性、データ主権、組織間の自律性である。ネットワークが切れても、各Edgeはローカルの委任範囲内で継続できる。すべての生データを中央に送らず、Traceのハッシュ、要約、選択的に開示したEvidenceだけを共有することもできる。

一方で、Policyの配布、Identityの検証、失効通知、Edge間の競合解消、証跡の整合性は難しくなる。完全分散型は「中央がない」だけであり、「統制がない」ことを意味してはならない。

三つの構成の比較

分散しても守るべき五つの原則

どの構成を選んでも、Runtime OSの核は変わらない。

1. SignalとDecisionを分離する
   AI出力、Agent提案、センサー値はSignalであり、Runtimeの評価を経ない限りDecisionではない。
2. DecisionとExecutionを分離する
   実行は、対象・操作・期限・回数を限定した短命のExecution Permitで行う。
3. Delegationを明示する
   Purpose、Scope、Authority、Constraints、Expiration、Responsibility、Revocationを含む契約なしに権限は移らない。
4. 不明なときはFail-Closedにする
   権限、Policy、相手のIdentity、失効状態を検証できないなら、越境実行はしない。必要ならAsk、危険ならStopである。
5. Traceを共有可能な形で残す
   Signal、Context、Policy、Candidate、Decision、Human Gate、Execution、Outcomeを共通のTrace IDで結び付ける。ローカルログだけでは、組織横断の説明責任を満たせない。

どの構成から始めるべきか

実装の出発点としては、CDR Edge単体で完結する最小構成がよい。

Interaction Core v2
  → Signal Ingress
  → Decision Kernel
  → Boundary Checker
  → Human Gate Adapter
  → Local Trace Journal
  → Enterprise Gateway Adapter

これを単一バイナリまたは小さなサービスとして動かし、外部依存なしでもローカルのDecision Traceを記録できるようにする。その後、必要に応じて中央Ledger、Policy配布、Federated Identity、Edge間のDelegationを追加すればよい。

この順序なら、中央集権型を選んでも、協調型へ進んでも、最終的にFederated Runtime OSへ進んでも、コアを作り直す必要がない。

おわりに

Runtime OSの価値は、AIを一か所に集めることではない。異なるAI、Agent、人間、組織、設備が、それぞれの境界と責任を保ったまま協調できるようにすることにある。

中央Runtimeは、統一的なPolicy、監査、Human Gateに強い。CDR Edgeは、現場の即時性と自律性に強い。Federated CDR Edgeは、組織間・地域間・社会インフラのように、単一の主権者を前提にできない世界に強い。

重要なのは、どの構成でもAgentを主権者にしないことだ。AgentはSignalを生成し、提案し、承認済みのDecisionを実行する。RuntimeがDecisionを確定し、Boundaryが守り、Human Gateが責任を引き受け、Ledgerがその過程を未来へ残す。

それが、AIを単なる応答システムから、説明可能で信頼できる協調システムへ進化させるためのRuntime OSである。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance