AIはなぜ「決められない」のか？ — Decision Trace Ledger Core を作った理由 —

Introduction

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

  • 予測（Prediction）
  • スコアリング
  • 分類

といった「出力」を中心に設計されています。

しかし実際の現場で重要なのは、

  • 何が決定されたのか
  • なぜその判断になったのか
  • 誰が関与したのか
  • どの順序で意思決定が行われたのか

です。

つまり、

AIは予測ではなく、意思決定のためのシステムである

という視点が必要になります。

意思決定は記録されていない

ここで重要な問題があります。

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

  • 入力は記録される
  • 出力もログに残る

しかし、

意思決定そのものは記録されていない

のです。

例えば：

  • なぜ承認されたのか？
  • なぜ却下されたのか？
  • なぜ人にエスカレーションされたのか？

これらは、

ログの断片から推測するしかありません。

つまり、

意思決定が「構造」として存在していない

なぜ新しい記録システム(Ledger)が必要だったのか

この問題を解決するために、

意思決定を「順序を持ったイベント」として記録する必要があります。

そこで登場するのが、

Ledger（台帳）という考え方です。

Ledgerは、

  • 順序を持った記録
  • 改ざん不可能な履歴
  • 再現可能なトレース

を実現する仕組みです。

しかし既存のLedgerには課題がありました。

なぜ新しいLedgerが必要だったのか

意思決定を記録・追跡するために「Ledger」という概念は以前から存在します。

しかし、既存の選択肢にはいくつかの問題がありました。

① Amazon QLDB の終了

Amazon Quantum Ledger Database（QLDB）は、

改ざん検知が可能な台帳として非常に優れた設計を持っていました。

しかし、このサービスは終了となり、

マネージドなLedger基盤に依存する設計のリスク

が明確になりました。

② 既存Ledgerの使いにくさ

他にもLedger系の仕組みは存在しますが、

  • 構成が重い（ブロックチェーン系など）
  • ドメインロジックと密結合している
  • 「記録」はできても「意思決定の構造」は扱えない

といった課題がありました。

特に問題だったのは、

意思決定プロセスそのものを記録する設計になっていない

ことです。

Decision Trace Ledger Coreとは

意思決定そのものを記録するためのLedger

従来のログやLedgerは、

・何が起きたか（Event）
・どんな結果になったか（Result）

を記録するものでした。

しかし、それだけでは

「なぜその判断になったのか」 は残りません。

Decision Trace Ledger Coreは違います。

記録するのは結果ではなく、

意思決定のプロセスそのもの

です。

Event
→ Signal
→ Decision
→ Boundary
→ Human
→ Log
この流れをそのまま保存します。

これにより、

・AIが何を出したのか（Signal）
・どのルールで判断したのか（Decision）
・どんな制約が働いたのか（Boundary）
・人がどう関与したのか（Human）

がすべて分離された形で記録されます。

つまりこれは、

単なる「ログ」でも
単なる「監査用Ledger」でもなく、

意思決定を再現・検証・改善できる基盤

です。

設計の特徴

Decision Trace Ledger Coreは、
従来のLedgerとは異なる前提で設計されています。

① Append-Only（追記のみ）

イベントは変更・削除されません。

すべての意思決定が履歴として残る

・監査性
・再現性

を保証します。

② Trace単位の分離

trace_id によって意思決定を分離

1つの意思決定 = 1つのTrace

・完全な追跡
・リプレイ可能

③ ハッシュチェーン

・prev_hash
・event_hash

改ざん検知可能な構造

④ Core特化設計

あえて含めていません：

・DB
・業務ロジック
・状態管理

ドメイン非依存のための構造

従来Ledgerとの違い

従来

「何が起きたか」を記録

Decision Trace Ledger

「なぜそう決めたか」を記録

観点 従来Ledger Decision Trace Ledger
対象 データ 意思決定
単位 トランザクション Trace
主目的 整合性・監査 再現・改善
構造 状態中心 プロセス中心

なぜCoreなのか

すべてを内包しないのは制約ではなく設計です。

・DBは外部に任せる
・ロジックはDSL / Agentに任せる
・状態はProjectionで扱う

Ledgerは「判断の事実」だけを扱う

最終的に何が変わるのか

この設計によって、

どんなシステムにも後付けできる

そして、

判断が「記録」ではなく「資産」になる

何が変わるのか

従来

入力 → AI → 出力

この構造では、

・なぜその結果になったのか
・どのような判断が行われたのか

が分かりません。

プロセスが見えないため、検証も改善もできない

これから

Event
→ Signal
→ Decision
→ Action
→ Outcome
→ Log

この構造では、

・何が起きたのか（Event）
・AIが何を提示したのか（Signal）
・どのように判断したのか（Decision）
・どの行動が選ばれたのか（Action）
・結果どうなったのか（Outcome）

がすべて分離された形で記録されます。

意思決定そのものが構造として残る

その結果、

・判断の再現ができる
・判断の妥当性を検証できる
・改善のためのフィードバックループが回る

ようになります。

マルチエージェントとの関係

マルチエージェント環境では、

・複数のAIが異なるSignalを出す
・別のAgentが評価・フィルタリングする
・最終的に人間またはルールがDecisionを行う

という構造になります。

しかし、このとき

Decision Traceがないと全体はブラックボックスになります

なぜなら、

・どのAgentの提案が採用されたのか
・なぜ他の案が棄却されたのか
・最終判断の根拠は何だったのか

が追えないからです。

Decision Trace Ledgerを導入すると、

・どのAgentが何を提案したか
・どの評価ロジックが作用したか
・どのように最終Decisionに至ったか

がすべて追跡可能になります。

つまり、

マルチエージェントを“説明可能な意思決定システム”に変えます

OSSとして公開

実装はOSSとして公開しています

👉 https://github.com/masao-watanabe-ai/Decision-Trace-Ledger-Core

このコアで何ができるのか

Decision Trace Ledger Coreはあくまで最小構成です。

しかし、この上にレイヤーを重ねることで、

意思決定そのものを扱うシステムへと進化します。

① 意思決定の再現（Replay）

過去の判断をそのまま再実行できます。

・同じ条件で同じ判断になるのか
・別のルールを適用したらどうなるか

意思決定の“シミュレーション”が可能になる

② 判断の可視化（Explainability）

・なぜその決定になったのか
・どのSignalが影響したのか

ブラックボックスだった判断が説明可能になる

③ 改善ループの構築（Feedback）

・OutcomeとDecisionのズレを検知
・ルールや評価ロジックを改善

判断を継続的に進化させられる

④ マルチエージェントの統合管理

・複数Agentの提案を記録
・評価・選択プロセスを可視化

分散したAIを一つの意思決定システムとして扱える

⑤ Decision Analytics（判断の分析）

・どの判断が成功したか
・どのパターンが失敗したか

意思決定そのものをデータとして分析できる

最後に

AIの本質は「予測」ではありません。

意思決定です

そしてこれから重要になるのは、

その意思決定をどれだけ追跡・説明・改善できるか

です。

そのために必要なのは、

より高性能なモデルではなく、

意思決定を正しく記録する基盤

です。

Decision Trace Ledger Coreは、

・何を判断したのか
・なぜそう判断したのか
・どのように結果につながったのか

を、構造として残します。

つまりこれは、

意思決定を“消えるもの”から“残るもの”に変える仕組み

です。

そして最終的に、

企業の競争力は「どれだけ良い判断をしたか」ではなく、
「どれだけ判断を蓄積し、改善できるか」で決まるようになります。

その基盤となるのが、

Decision Trace Ledger Core

です。

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