Runtime Protocol — Why AI Needs Decision OS Architecture —

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

生成AIやマルチエージェントシステムの進化によって、
AIは単なる「会話システム」ではなく、

行動する
協調する
判断する
実行する

システムへ変化し始めています。

しかしここで、
極めて重要な問題が生まれます。

それは：

AI Runtime を、
どう制御するのか？

という問題です。

これは単なる：

プロンプト設計

の話ではありません。

本当に重要になるのは：

  • どの順番で判断するのか
  • どこで停止するのか
  • どこでHumanへEscalationするのか
  • Boundaryをどう扱うのか
  • Agent同士の衝突をどう調停するのか
  • 誰が責任を持つのか

です。

つまり必要なのは：

DTMとしてのRuntime Protocol

なのです。

Runtime Protocol はなぜ必要なのか

現在の多くのAIシステムは、

入力
↓
LLM
↓
出力

という比較的シンプルな構造を持っています。

この構造は、

会話生成
検索支援
要約
コード生成
文章作成

といった領域において、非常に強力です。

実際、生成AIの登場によって、
私たちはこれまでよりも高速に：

情報へアクセスし
知識を整理し
アイデアを生成し
ソフトウェアを作り
複雑な文書を理解できる

ようになりました。

しかし、
AIが現実社会の中へ入り始めると、
別の問題が現れ始めます。

現実世界には、
単純な「入力 → 出力」だけでは扱えないものが大量に存在するからです。

例えば現実には：

曖昧な状況
部門間の利害衝突
法規制やコンプライアンス
安全境界
責任所在
承認フロー
Human Review
例外処理
未知の状況（Unknown Unknown）

が常に存在しています。

製造現場では、
センサー異常や個体差、運用差が発生します。

医療では、
患者ごとの状態差や倫理判断が存在します。

行政では、
制度・説明責任・公平性が求められます。

金融では、
リスク境界や監査可能性が必要になります。

つまり現実社会では、
単に「もっともらしい答え」を返すだけでは不十分なのです。

重要なのは、

誰が判断したのか
どの条件で実行されたのか
どこで停止したのか
誰が承認したのか
なぜその判断になったのか

を扱えることです。

ここでAIは、
単なる「予測システム」から、
より大きな構造へ変わり始めます。

それは：

AI = Prediction

ではなく、

AI = Decision Coordination

という世界です。

つまりAIは、
単独で答えを生成する存在ではなく、

複数の情報
複数のAgent
組織ルール
安全境界
Human Gate
外部システム

を調整しながら、
意思決定を支援・制御・記録する
「協調実行基盤」
へ進化し始めているのです。

そしてこの変化によって、
今後重要になるのは：

モデル性能だけではありません。

むしろ重要になるのは：

どう制御するのか
どう停止するのか
どう承認するのか
どう責任を扱うのか
どう境界を定義するのか
どう意思決定を追跡するのか

という、
Runtime / Governance / Coordination の設計です。

AI時代は、
単なる生成の時代から、

「意思決定構造をどう設計するか」

の時代へ入り始めているのです。

では Runtime をどう制御するのか？

ここで重要になるのが：

  • DSL
  • Behavior Tree（BT）
  • Policy Engine
  • Ledger
  • Human Gate

です。

1. DSL:  Runtime Protocol を記述する

DSL（Domain Specific Language）は、

「意思決定ルール」

を人間が理解しやすい形で記述するための言語です。

例えば：

when:
  risk_score: "> 0.7"
  conflict: true

then:
  boundary_check: required
  human_gate: required
  trace: write

これは：

「高リスクで、かつ衝突が発生している場合は、
Boundary確認とHuman Reviewを必須にし、
Decision Traceを書き込む」

という Runtime Protocol を表しています。

一方、
DSLを使わずに普通のコードだけで書くと、
こうなります。

if risk_score > 0.7 and conflict:
    boundary_check()
    request_human_review()
    write_trace()

最初はシンプルに見えます。

しかし現実では：

  • 条件追加
  • 例外処理
  • 部門ごとの差分
  • 国ごとの規制
  • Runtime変更
  • 緊急モード
  • Human権限変更
  • などが増えていきます。

すると：

if risk_score > 0.7 and conflict:
    if country == "JP":
        ...
    elif country == "US":
        ...
    if emergency_mode:
        ...
    if operator_role == "senior":
        ...

のように、

if 文が増殖し、
ルール全体が見えなくなっていきます。

DSLの強みは、

「コードの中に埋もれていた意思決定ルール」

を、
Runtime Policy として外に出せることです。

つまり：

コードを書く

のではなく、

「どう判断するか」

を宣言的に記述できる。

例えば：

when:
  medical_risk: high

then:
  human_gate: doctor_required
  escalation: emergency_team

を見るだけで、

「高リスク患者は医師確認必須」

だと分かる。

これは：

エンジニアだけでなく、
現場担当者
管理者
監査
法務

も読める。

ここが非常に大きい。

つまりDSLは：

Algorithm

ではなく、

Decision Policy

を表現するための言語です。

そしてこれは：

Government Runtime
Manufacturing Runtime
Medical Runtime
Financial Runtime

のような、

「ルール変更」
「監査」
「説明責任」

が重要な世界で非常に強いのです。

2. Behavior Tree（BT）:  実行時の分岐・停止・Escalationを制御する

DSLだけでは、
Runtimeは動きません。

必要なのは：

実際にどう動くか

です。

ここでBehavior Tree（BT）が重要になります。

例えば、
「工場の温度異常」を扱うだけでも、
BTはかなり自然に書けます。

Root
 └─ Sequence
    ├─ Detect High Temperature
    ├─ Check Machine Status
    ├─ Evaluate Safety Limit
    ├─ Notify Operator
    └─ Write Incident Log

これは意味としては：

  1. 温度異常を検知する
  2. 機械状態を確認する
  3. 安全限界を超えていないか判定する
  4. 必要ならオペレーターへ通知する
  5. 最後にログを記録する

という流れです。

例えば：

  • 温度が少し高いだけなら監視継続
  • 危険温度なら停止
  • 判断が難しければ人間へ通知

のように、
現実的な運用をそのまま構造化できます。

さらにBTでは：

Evaluate Safety Limit
   ├─ OK → Continue Monitoring
   └─ NG → Stop Machine

のように、

「危険なら止める」

を自然に書ける。

これが：

製造
医療
ロボット
自動運転
行政

のような、

「安全停止」

が重要な世界で、
BTが強い理由です。

このようにBTは：

  • 分岐
  • 停止
  • Retry
  • Escalation
  • Human Gate

を非常に扱いやすい。

特に：

Event → Signal → Decision → Boundary → Human → Log

という DTM 構造と相性が良い。

また、BT（Behavior Tree）の大きな強みは、

「成功する流れ」

だけではなく、

「失敗した時にどう動くか」

を構造として明確に書けることにあります。

例えば現実世界では、
AIは常に正しく動けるとは限りません。

製造現場では：

安全基準を超える
異常センサー値が出る
設備状態が不安定になる

ことがあります。

医療では：

診断に確信が持てない
リスクが高い
患者状態が複雑すぎる

ことがあります。

行政や金融では：

法規制に抵触する可能性
権限不足
説明責任上の問題

が発生します。

この時に重要なのは、

「AIが無理に続行しないこと」

です。

BTはこれを自然に表現できます。

例えば、
製造ラインの異常判定を
単純な if 文だけで書こうとすると、
こうなりがちです。

if boundary_ok:
    execute()
else:
    if risk_level > 8:
        stop_line()
        notify_manager()
        if manager_available:
            review_result = human_review()
            if review_result == "approved":
                if safety_recheck():
                    execute()
                else:
                    stop_line()
            elif review_result == "retry":
                retry_count += 1
                if retry_count < 3:
                    execute_again()
                else:
                    emergency_shutdown()
            else:
                emergency_shutdown()
        else:
            emergency_shutdown()
    else:
        if temporary_sensor_error:
            retry()
        else:
            stop_line()

これが：

if 地獄

と呼ばれるものです。

問題は：

  • 分岐が増える
  • Retry が増える
  • Human Review が増える
  • 例外処理が増える
  • 安全停止が増える
  • 状態管理が複雑になる

と、

コード全体が：

「何をしたいのか」

より、

「分岐処理の管理」

だらけになることです。

一方BTだと：

Detect Signal
  ↓
Evaluate Boundary
  ├─ OK → Execute
  └─ NG
       ↓
   Escalation
       ↓
   Human Review
       ├─ Approve → Retry
       ├─ Retry → Retry
       └─ Reject → Shutdown

のように、

「失敗時の流れ」

そのものを構造として書ける。

つまり：

制御構造
停止
承認
再試行
Fallback

が Tree の形で見える。

ここがBTの非常に大きな強みです。

特に：

Government Runtime
Manufacturing Runtime
Medical Runtime

のような、

「危険時に止めること」

が重要な世界では、

if 文を増やすより、
Behavior Treeとして管理した方が、
圧倒的に理解しやすく、安全性も高くなるのです。

つまりBTは：

成功だけを目指すAI

ではなく、

安全に止まれるAI

を作りやすい。

ここが非常に重要です。

特に：

Government Runtime
Manufacturing Runtime
Medical Runtime

のような世界では、

「平均的に正しい」

よりも、

「危険時に止まれる」

ことの方が重要になります。

BTは、

停止
承認
エスカレーション
再試行
例外処理

を構造として明示できるため、

現実社会向けAIと非常に相性が良いのです。

3. Policy Engine:  Boundary を扱う

Policy Engine は、
Boundary（境界条件）を専門に判定するレイヤです。

BTにすべてのBoundary判定を入れてしまうと、ツリーが巨大化します。

例えばBTの中に、

GDPRチェック
ISOチェック
安全基準チェック
社内規程チェック
予算制約チェック
権限チェック
監査要件チェック

を全部書くと、BTはすぐに複雑になります。

そのため、役割を分けます。

BT = 実行の流れを制御する
Policy Engine = 実行してよいかを判定する

BTは、

Signalを検知する
Contextを分析する
Policy EngineにBoundary判定を依頼する
NGなら停止・Escalationする
OKなら次へ進む
Traceを書く

という制御に集中します。

一方、Policy Engineは、

この処理はGDPR上問題ないか
この操作は社内ルール上許可されるか
この判断は安全基準を超えていないか
このユーザーに承認権限があるか
この金額は自動承認してよいか

を判定します。

つまり、BTの中ではこう書きます。

Evaluate Boundary
  ↓
Call Policy Engine
  ├─ OK → Continue
  └─ NG → Escalation / Human Review / Stop

この分離が重要なのは、
実行ロジックとルール変更を切り離せるからです。

規制や社内ルールが変わっても、
BT全体を書き直す必要はありません。

Policy Engine側のルールを更新すればよい。

つまり、

BTは変えずに、
Policyだけを更新できる

という構造になります。

これは、

Government Runtime
Manufacturing Runtime
Medical Runtime
Financial Runtime

のように、
規制・安全・責任・監査が重要な領域で非常に強力です。

4. Ledger:  Decision Trace を残す

Decision Ledger は、
AIが行った意思決定の履歴を残すための記録レイヤです。

DTMにおいて重要なのは、単に、

何を決めたか

だけではありません。

むしろ重要なのは、

なぜその判断になったのか
どのSignalを受け取ったのか
どのContextを参照したのか
どのBoundaryが発火したのか
どこでHuman Reviewが入ったのか
どのAgent同士が衝突したのか
どのリスクが存在したのか
最終的に誰が承認したのか

を残すことです。

つまり、AIの出力だけではなく、
意思決定に至るプロセスそのものを記録します。

これが Decision Trace です。

そして、その Decision Trace を蓄積する場所が、

Decision Ledger

です。

Decision Ledger があることで、

後から説明できる
監査できる
失敗原因を分析できる
同じミスを防げる
組織の判断知として再利用できる

ようになります。

つまり Decision Ledger は、
単なるログではありません。

それは、

AI時代の意思決定記憶
Decision Memory

です。

DTMでは、AIを「答えを出す装置」としてではなく、
判断し、止まり、承認され、記録される実行システムとして扱います。

その中で Decision Ledger は、
AIシステムに説明責任・監査可能性・学習可能性を与える中核になります。

5. Human Gate:  AIは最終決定者ではない

Human Gate は、
AIが最終決定者にならないための仕組みです。

ここで重要なのは、

LLMをシステムの中心に置かない

という考え方です。

LLMは、

説明を生成する
情報を要約する
候補を提示する
人間との対話インターフェースになる

ことには非常に強いです。

しかし、

実行してよいか
停止すべきか
誰が責任を持つか
安全境界を超えていないか
例外ケースをどう扱うか

といった最終制御を、LLMだけに任せるのは危険です。

そのため、Runtime Architecture では中心に置くべきものは、

LLM

ではなく、

BT + Policy Engine

です。

BTは実行の流れを制御し、
Policy Engineは安全・規制・権限・社内ルールなどのBoundaryを判定します。

そして、

Conflict
Boundary NG
Unknown Unknown
高リスク判断
責任が発生する判断

が起きた場合は、AIが勝手に進めるのではなく、

Human Gate

へEscalationします。

つまり Human Gate は、

AIが判断を支援する
しかし最終判断は人間または組織が行う

ための境界です。

これは、AIを止めるための仕組みでもあり、
責任を人間側に戻すための仕組みでもあります。

Runtime Architecture の重要思想は、

AIにすべてを決めさせることではなく、
AIを制御可能な意思決定構造の中で動かすこと

です。

Runtime Protocol の他の方式

Runtime Protocol を実現する方法は、
DSL + Behavior Tree（BT）だけではありません。

実際には、AIシステムや業務システムでは、

State Machine
Workflow Engine
Rule Engine
Petri Net
Graph Runtime
Event-driven Runtime
Goal-based Planning

など、さまざまな方式が使われています。

重要なのは、

どれが「最強」か

ではなく、

何を重視するか

です。

例えば：

安定性
柔軟性
監査性
説明可能性
並列性
停止制御
例外処理
Human Review

などによって、適した方式は変わります。

1. State Machine（状態機械）

例えば：

Idle
 ↓
Running
 ↓
Review
 ↓
Approved
 ↓
Completed

のように、
状態遷移でシステムを管理する方式です。

Pros
安定
動作が明確
検証しやすい

つまり：

「今どの状態にいるか」

が非常に分かりやすい。

そのため：

組み込み
制御系
プロトコル
安全システム

でよく使われます。

Cons

しかし現実世界では：

例外
条件分岐
人間介入
並列処理

が増えていきます。

すると：

状態 × 条件 × 例外

が爆発し、

State Explosion（状態爆発）

が起きやすい。

つまり、
シンプルな世界には強いが、
複雑な社会システムには厳しくなる。

2. Workflow Engine

例えば：

申請
 ↓
承認
 ↓
実行
 ↓
通知

のような業務フローを管理する方式です。

Airflow や Temporal のようなものも近いです。

Pros
再実行しやすい
並列処理しやすい
障害耐性が高い

つまり：

「途中で落ちても再開できる」

ここが非常に強い。

業務システムやデータ処理で多用されます。

Cons

ただし：

曖昧な判断
Conflict調整
動的状況変化

には弱い。

Workflow は基本的に：

「決まった流れ」

を実行するのが得意だからです。

3. Rule Engine

例えば：

IF risk > 0.7
THEN human_review

のように、
ルールで判断する方式です。

Pros
説明しやすい
監査しやすい
非エンジニアでも読める

つまり：

法務
監査
業務担当

にも共有しやすい。

Government や Financial 系で強い。

Cons

しかしルールが増えると：

Rule Conflict

が起きやすい。

例えば：

Rule A → 実行OK
Rule B → 実行NG

のような衝突です。

そのため：

優先順位
例外ルール
Override

管理が必要になる。

4. Petri Net

Petri Net は：

並列状態と同期

を扱う数学モデルです。

Pros

複数Agent
並列処理
同期制御

に非常に強い。

例えば：

ロボット協調
分散システム
工場制御

など。

Cons

ただし：

理解が難しい
可視化が複雑
設計難易度が高い

ため、
現場導入のハードルが高い。

5. Event-driven Runtime

これは：

Event 発生
 ↓
Handler 実行

で動く方式です。

Kafka ベースのイベント駆動など。

Pros
リアルタイム性
疎結合
スケーラビリティ

に強い。

IoT や大規模分散システムで強力。

Cons

しかし：

全体状態が見えにくい
Traceが複雑
デバッグ困難

になりやすい。

6. Goal-based Planning

これは：

目的
 ↓
AIが計画生成
 ↓
実行

を行う方式です。

LLM Agent 系で多い。

Pros
柔軟
未知状況に強い
自然言語に強い

つまり：

人間っぽい問題解決

ができる。

Cons

しかし：

再現性
監査性
責任境界

が弱くなりやすい。

つまり：

「なぜそう動いたのか」

を説明しにくい。

7. LLM Orchestrator

最近増えている：

LLMがAgentを制御する

方式です。

Pros
柔軟
自然言語理解
高速開発

に強い。

Cons

しかし：

再現性が不安定
停止制御が難しい
Boundaryが曖昧
監査しにくい

という問題があります。

特に：

Government
Medical
Manufacturing

のような、

止める責任
説明責任
監査可能性

が必要な世界では課題が大きい。

DTM / Runtime Architecture が重要視するもの

DTMでは特に：

Boundary
Human Gate
Traceability
Governance

を重視します。

そのため：

DSL
BT
Policy Engine
Ledger
Human Gate

を組み合わせた：

制御可能なRuntime Architecture

を重視しています。

つまり：

AIを「自由に動かす」

ことより、

AIをどう止めるか
どう承認するか
どう記録するか

を中心に設計しているのです。

なぜこれは「Decision OS」なのか

ここで重要なのは、
これは単なるAIシステムではない、という点です。

たとえばAIシステムであれば、基本構造は次のようになります。

Input
 ↓
AI
 ↓
Output

しかし、現実社会でAIを使う場合は、これだけでは不十分です。

実際には、

Agent Coordination
Governance
Boundary Management
Escalation
Human Responsibility
Decision Memory

を扱う必要があります。

つまり、AIが答えを出すだけではなく、

複数Agentをどう協調させるか
どのルールに従うか
どこで止めるか
誰に承認を渡すか
誰が責任を持つか
判断履歴をどう残すか

を管理しなければなりません。

この役割は、単なるアプリケーションではなく、
AIの実行・制御・記録を支える基盤に近いものです。

だからこれは、

Decision Runtime

であり、さらに言えば、

Decision OS

と呼べるのです。

OSがアプリケーションの実行、権限、資源、ログを管理するように、
Decision OS はAI時代の意思決定において、

実行
制御
境界
承認
記録
責任

を管理します。

おわりに

今後、AIはますます、

推論する
実行する
他Agentと協調する
外部システムを操作する

ようになります。

しかし、その時に本当に重要になるのは、
AIがどれだけ賢いかだけではありません。

むしろ重要になるのは、

そのAI Runtimeをどう制御するのか
どこまで実行を許すのか
どこで止めるのか
誰が承認するのか
どう記録するのか

です。

AIが強力になるほど、
必要になるのは単なる LLM ではなくなります。

必要になるのは、

Runtime Protocol

です。

つまり、AIを自由に動かすための仕組みではなく、
AIを安全に動かし、必要な時に止め、
人間へ渡し、判断の履歴を残すための構造です。

これからのAIシステムは、

AIを使うシステム

から、

AIを制御するRuntimeを持つシステム

へ進化していくのだと思います。

Chinoba — Runtime Society and Coordination Systems:
chinoba.org

Related Research

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

Chinoba Research
Chinoba-lab Open Source
Books and Library

コメント

モバイルバージョンを終了
タイトルとURLをコピーしました