生成AIやRAG、Multi-Agentシステムの導入が進む中で、
企業では次のような問題が増え始めています。
- AIが「それっぽい答え」を返す
- 過去データ検索はできる
- 類似事例も見つかる
しかし最終的に：
「このケースを本当に承認してよいのか」
が決められない。
特に製造業・医療・金融・インフラなどでは、
この「曖昧な境界問題」が極めて重要になります。
今回のシナリオは、
その典型例です。
1. シナリオ概要
今回のケースでは：
- 高温時に電圧が微妙に不安定
- 閾値は超えていない
- 過去に類似ケースが存在
- しかし結果が分かれている
という状態です。
つまり：
- Failureになる可能性
- 単なるノイズの可能性
の両方が存在している。
ここが重要です。
これは単純な「検索問題」ではありません。
これは：
Decision Ambiguity（意思決定曖昧性）
の問題です。
2. Before：従来型会議 / 単純RAG構成
パターンA：
人間だけの会議
従来の設計レビューでは：
- ベテラン経験
- 過去記憶
- 部署間パワーバランス
- 会議の空気
によって判断が決まりやすい。
つまり：
「なぜその決定になったのか」
が残りにくい。
例えば：
- QAが強かったから止まった
- 上司が急いでいたから通った
- 過去に問題なかったから通した
などが起きる。
しかし：
Decision Trace（意思決定過程）
は残らない。
パターンB：
単純RAG + LLM
近年増えているのが：
Jira
Confluence
PDF
過去障害
QAレポートをRAGで検索し、
LLMが：
「過去類似ケースがあります」
と回答する構成です。
しかしここにも問題があります。
RAGは：
「情報検索」
はできる。
しかし：
- 類似ケース間の矛盾
- Failure / Non-Failure の競合
- 安全境界
- Human escalation
- 判断保留
を扱えない。
つまり：
Signal は扱えるが、
Decision は扱えない。
ここが本質です。
3. 実際の会話とDTMフロー
Step 1：
弱Signalの検出
<会話>
[Aiko]
この部品、高温環境で電圧が少し不安定になっています。
通常範囲にも見えますが、
ピーク時に微妙な揺れがあります。<システム内部>
Sensor Data
↓
Signal Detection
↓
Risk Scoring
↓
Semantic Classification<Runtime内部状態>
Signal Detected:
- Thermal Risk
- Voltage Instability
- Potential Safety Concern
Risk Score: 0.38ここで重要なこと
通常のRAGでは、
この段階ではまだ：
「閾値内なので問題なし」
で終わる可能性があります。
しかしDTMでは：
Weak Signal
として保持される。
つまり：
「まだFailureではないが、
無視すべきではない」
状態として扱われる。
4. 過去Knowledge検索
<会話>
[Aiko]
まだ閾値内ですが、
過去に似たケースありましたか？<システムフロー>
Runtime
↓
Knowledge Retrieval
↓
Failure Trace Search
↓
Decision Ledger Search
↓
QA Notes Search<実際の検索対象>
Sources:
- Failure Trace
- Validation Reports
- Jira
- QA Notes
- Decision Ledgerここで重要
普通のRAGは：
Document Retrieval
で終わる。
しかしDTMでは：
Decision Retrieval
を行う。
つまり：
- どう判断されたか
- なぜEscalationされたか
- なぜ通ったか
まで検索対象になる。
5. 類似ケース競合
<Runtime結果>
Case A:
2025 Thermal Instability
→ Escalated to QA
→ Additional shielding added
Case B:
2024 Voltage fluctuation
→ Judged acceptable
→ No field issue observed
Confidence Conflict Detected.<システム内部>
Similarity Engine
↓
Case Comparison
↓
Outcome Conflict Detection
↓
Confidence InstabilityここがDTMの重要ポイント
普通のRAGでは：
「類似ケースがあります」
で終わる。
しかし現実には：
類似ケース同士が矛盾する。
つまり：
Knowledge Conflict
が発生する。
ここで重要なのは：
検索結果ではなく、
曖昧性そのもの。
6. Boundary接近
<Runtime状態>
Decision ambiguity detected.
Risk Score adjusted: 0.52<システムフロー>
Conflict Detection
↓
Risk Recalculation
↓
Boundary Evaluationここで起きていること
DTMでは：
「矛盾情報」
自体がRiskになる。
つまり：
- Failure類似あり
- 反例あり
- 原因未確定
という：
不確実性そのもの
を扱う。
7. Knowledge Holder呼び出しとBoundary Escalation
<初期状態：Runtimeが曖昧性を検出>
過去ケース検索の結果、
Runtimeは：
- Failure事例
- Non-Failure事例
の両方を検出した。
つまり：
同じような症状なのに、
過去Decisionが分かれている状態になっている。
ここでRuntimeは：
Decision Ambiguityを検出する。
<Aikoによる追加確認>
[Aiko]
同じような症状でも、
対応が分かれてますね…
過去の経緯を知っている人や、
類似Failureを直接見た人っていますか？<Runtime>
[Runtime]
Searching for additional validation sources...
Candidate Knowledge Holders:
- Mina (QA Thermal Validation)
- Ken (Field Failure Analysis)<システムフロー>
Conflict Detection
↓
Organizational Graph Search
↓
Expert Routing
↓
Knowledge Holder Selection
↓
Human Knowledge Retrievalここで重要
普通のRAGでは：
Knowledge = 文書として扱われる。
しかし現実の組織では：
- 「あの障害を見た人」
- 「当時レビューした人」
- 「なぜ止めたか知っている人」
- 「市場不具合を解析した人」
が極めて重要になる。
つまり知識は：
PDFの中だけに存在しているわけではない。
<Minaからの知識取得>
[Mina]
2025のケースは、
連続充電時に温度上昇が加速しました。
最初は軽微な揺れでしたが、
長時間試験で急激に悪化しています。
QA側では、
「初期症状が似ている」
と判断していました。<Runtime状態更新>
[Runtime]
Evidence correlation increased.
Thermal similarity score: 0.84
Risk Score: 0.68
Boundary Status:
NEAR_THRESHOLD<システム内部で起きていること>
Human Knowledge Input
↓
Evidence Correlation
↓
Similarity Recalculation
↓
Risk Score Update
↓
Boundary Re-evaluation<Kenからの反証知識>
[Ken]
ただ、2024のケースでは、
同様の変動がありましたが、
市場不具合には繋がっていません。
原因はセンサー側ノイズでした。
当時は過剰反応として扱われています。<Runtime内部状態>
[Runtime]
Conflicting interpretation detected.
Current State:
- Failure similarity exists
- Counterexample also exists
- Root cause unresolved
Decision confidence unstable.<Aikoの認識>
[Aiko]
つまり、
・本当に危険な初期兆候
・単なるノイズ
の両方の可能性があるんですね。<システム内部で起きていること>
Human Knowledge Input
↓
Evidence Correlation
↓
Counterexample Detection
↓
Interpretation Conflict
↓
Decision Confidence Instability
↓
Boundary Re-evaluation<Boundary Escalation>
[Runtime]
Boundary escalation condition detected.
Reason:
- Safety-related ambiguity
- Conflicting historical interpretations
- Insufficient causal certainty
Human Review Required.
Runtime Status:
WAITING_HUMAN_REVIEWここで重要
普通のRAGでは：
類似ケースがありますで終わる。
しかしDTMでは：
- Failure方向のEvidence
- Non-Failure方向のEvidence
- 人間知識
- 解釈競合
- 因果不確実性
を：
Runtime状態として保持する。
つまりここで重要なのは：
どちらが正しいかではない。
重要なのは：
安全上、
曖昧なまま通してよいのかです。
DTMで本当に重要なのは
DTMでは：
Knowledge = 文書 + 人間知識 + 解釈競合として扱う。
つまり：
- PDF検索
- 類似検索
- Vector Search
だけでは終わらない。
さらに：
- 誰がどう解釈したか
- なぜ意見が割れたか
- なぜBoundaryへ近づいたか
- なぜHuman ReviewへEscalationしたか
まで含めて構造化される。
ここが、
単なるRAGとDTMの決定的な違いです。
8. Human Gate発動
<Runtime>
[Runtime]
Boundary escalation condition detected.
Reason:
- Safety-related ambiguity
- Conflicting historical interpretations
- Insufficient causal certainty
Human Review Required.
Runtime Status:
WAITING_HUMAN_REVIEW<システムフロー>
Boundary Threshold
↓
Escalation Trigger
↓
Human Gate
↓
Reviewer Assessment
↓
Decision Finalization
↓
Ledger Recording<Reviewer判断>
[Reviewer]
確認しました。
現段階では、
危険性を断定する証拠は不足しています。
ただし、
過去Failureとの類似度が高く、
安全領域の問題でもあるため、
追加熱解析なしでの承認は危険です。
以下を要求します：
- Long-duration thermal test
- Sensor noise isolation
- Additional QA validation
設計承認は、
追加検証完了まで保留とします。<RuntimeによるDecision確定>
[Runtime]
Decision Recorded.
Decision:
HOLD_WITH_ADDITIONAL_VALIDATION
Reason Trace:
- Weak thermal instability signal
- Historical conflict detected
- Failure similarity high
- Counterexample existed
- Human escalation triggered
Decision Trace Written to Ledger.<Organizational Memory更新>
[Runtime]
Organizational Memory Updated.
Future signals involving:
- thermal instability
- ambiguous voltage fluctuation
- conflicting historical precedent
will reference this decision trace.<システム内部で起きていること>
Interpretation Conflict
↓
Boundary Detection
↓
Human Escalation
↓
Safety-oriented Review
↓
Conditional Decision
↓
Decision Trace Generation
↓
Organizational Memory Updateここが本質
AIは：
類似性は出せる。
しかし：
責任は持てない。
今回も：
- Failure類似あり
- 反例あり
- 原因未確定
- 安全影響あり
という：
曖昧で不完全な状態
だった。
ここで重要なのは：
「正しい答え」を出すことではない。
重要なのは：
危険な曖昧性を、
どう安全側へ処理するかです。
Human Gateで起きていること
Reviewerは：
単に「AI結果を承認」しているわけではない。
実際には：
- Signalの強さ
- Failure類似度
- Counterexample
- 安全性
- 因果不確実性
- 追加検証コスト
- 誤判定リスク
を総合的に評価している。
つまりここで行われているのは：
社会的意思決定です。
さらに重要な点
今回のDecisionは：
APPROVEでも：
REJECTでもない。
DTMでは：
HOLD_WITH_ADDITIONAL_VALIDATIONという：
中間Decision
を扱える。
ここが極めて重要です。
現実社会では：
- 完全肯定
- 完全否定
だけでは運用できない。
実際には：
- 保留
- 条件付き承認
- 追加検証
- エスカレーション
- 部分承認
のような：
曖昧な中間状態
が大量に存在する。
DTMは、
この「現実の曖昧性」を
Runtime上で扱うための構造なのです。
Ledgerが重要になる理由
さらに重要なのは：
このDecisionが、
Organizational Memoryへ保存されること。
つまり将来：
同じような：
- thermal instability
- voltage fluctuation
- ambiguity conflict
が発生した時、
単なるFAQではなく：
過去にどう判断したかそのものを参照できる。
ここで企業は初めて：
Decision Memoryを持ち始める。
これが、
DTMの本質です。
9. 最終Decision
<Runtime>
Decision:
HOLD_WITH_ADDITIONAL_VALIDATION<システムフロー>
Human Review
↓
Decision Finalization
↓
Ledger Write
↓
Organizational Memory Update<Ledger記録>
Reason Trace:
- Weak thermal instability signal
- Historical conflict detected
- Failure similarity high
- Counterexample existed
- Human escalation triggered10. OSSベースシステム構成例
<最小構成>
[ Sensor / Test Data ]
↓
Kafka / Redpanda
↓
Runtime Engine
(Python / FastAPI)
↓
┌───────────────┐
│ Signal Analyzer │
│ Risk Scoring │
│ Similarity │
└───────────────┘
↓
Vector DB
(Qdrant / Weaviate)
↓
Knowledge Sources
- Jira
- QA Notes
- Failure Reports
- Ledger
↓
LLM Agent
(OpenAI / Ollama / vLLM)
↓
Boundary Engine
(rule / threshold)
↓
Human Gate UI
(React / Next.js)
↓
Decision Ledger
(PostgreSQL / XTDB)11. DTMで本当に変わるもの
ここで重要なのは：
AI精度向上
ではありません。
本当に変わるのは：
「曖昧性の扱い方」
です。
今回のケースでは：
危険かもしれない
しかし断定できないという状態でした。
従来システムでは：
- 通す
- 止める
の二択になりやすい。
しかしDTMでは：
HOLD_WITH_ADDITIONAL_VALIDATIONという：
中間Decision
を扱える。
12. DTMは「AI導入」ではない
DTMは：
LLM導入手法
ではありません。
それは：
AIを社会的実行可能へ変換する構造
です。
特に重要なのは：
- 曖昧性
- 例外
- 境界
- 責任
- 保留
- escalation
- competing interpretation
を扱えることです。
つまりDTMとは：
「AIが答えを出す仕組み」
ではなく、
「AI・人間・組織・Boundaryを通して、
社会的に実行可能なDecisionへ変換する仕組み」
なのです。
Chinoba — Runtime Society and Coordination Systems:
chinoba.org
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 の一部です。
コメント