AIシステムについて議論するとき、多くの人は次のようなテーマに注目します。
-
モデル精度
-
データ量
-
推論速度
-
パラメータ数
しかし、実際の業務システムでは、もう少し違う問題が存在します。
それは
「なぜその判断が行われたのか」
という問いです。
そしてこれは、AIシステムだけの問題ではありません。
実はこの問題は、多くの業務支援システムでも長年存在してきた問題です。
本当に失われているのは「最終結果」ではない
多くの製造業では、すでに次のような管理は非常に高度に整備されています。
-
図面管理
-
文書管理
-
改訂履歴
-
承認フロー
-
品質トレーサビリティ
つまり、
最終成果物の管理
は非常に強い。
しかし、現場では次のようなことがよく起きます。
-
なぜこの案が採用されたのか分からない
-
他の案は何だったのか分からない
-
何を懸念していたのか残っていない
-
なぜ当時は問題ないと判断したのか説明できない
つまり、
失われているのは「意思決定の途中経過」
なのです。
設計の価値は「結果」ではなく「途中」にある
設計の価値は最終図面にあるわけではありません。
本当に価値があるのは次の部分です。
-
何を検討したか
-
何を却下したか
-
どこにリスクを感じたか
-
どこで判断を止めたか
つまり
Option → Concern → Decision
という判断経路です。
この判断経路は、企業にとって極めて重要な資産です。
しかし通常のシステムでは、この部分は、いわゆる暗黙知として
-
会議の会話
-
メール
-
Slack
-
個人メモ
の中にに散らばり、構造として保存されません。
Decision Trace Model の本来の目的
Decision Trace Model は
AIシステムのためだけの技術ではありません。
もともとは
人間の意思決定プロセスを構造化するための枠組み
として設計されたものです。
例えば、製造業向けのDecision Trace Modelの基本構造は非常にシンプルです。
1 Option（検討案）
例
A案：SUS304
B案：SUS316
2 Concern（懸念）
-
腐食リスク
-
コスト増
-
調達納期
3 Risk Assessment（リスク評価）
-
低 / 中 / 高
-
スコア
4 Rejected Reason（却下理由）
-
コスト制約
-
納期制約
-
標準化優先
5 Stop Condition（判断停止条件）
-
試験結果未取得
-
安全基準未確認
-
信頼度不足
これらの構造を使うことににより
判断の経路そのものを保存する
ことが可能になります。
これはRAGや文書検索とは何が違うのか
最近は多くの企業が
-
文書検索
-
ナレッジベース
-
RAG
を導入しています。
しかしこれらは基本的に
文書を読む
仕組みです。
つまり
「文章を検索してLLMが要約する」
という構造です。
しかしそれでは
-
却下理由
-
懸念
-
判断停止条件
は構造として残りません。
LLMは
毎回その場で解釈するだけ
です。
Decision Trace Modelは違います。
保存する単位は
文書ではなく「判断」
となります。
Decision Trace Model を業務支援システムに適用する方法
実際の導入は次のような段階になります。
Phase1
Decision Trace の共通スキーマを定義
Phase2
既存データを分解
既存の
-
図面
-
議事録
-
試験結果
-
標準書
などを構造単位に分解する。
Phase3
AIによる補助によるスキーマとの統合
前述したGNNやLLM、機械学習を使い
-
懸念候補抽出
-
却下理由候補提示
-
類似案件検索
を行う。
Phase4
横断分析
Decision Trace を横断すると
-
同じ却下理由の案件
-
同じ懸念パターン
-
過去に警告されたリスク
などが検索できる。
何が変わるのか
この仕組みが導入されると、次の変化が起きます。
1 再発防止が強くなる
事故が起きたとき、
従来は
「当時は問題なかった」
で終わることが多い。
しかし Decision Trace があれば
-
なぜ採用したのか
-
どの懸念が無視されたのか
を説明できます。
2 ベテランの判断を再利用できる
ベテランの価値は
危険な道を潰していること
です。
しかし
「潰した経路」
は通常残りません。
Decision Trace は
その経路を資産化する
仕組みです。
3 AIとの統合が可能になる
そしてここで初めて
AIと結びつきます。
Decision Trace が存在すると
AIは
-
類似判断の検索
-
リスクパターン提示
-
懸念の自動生成
を行うことができます。
つまり
AIは
判断を作る存在ではなく
判断を補助する存在
になります。
Decision Trace Model と AIシステム
AIシステムで Decision Trace Model を使うと
次の構造になります。
Event
↓
Signal（AI予測）
↓
Decision（人間またはAI）
↓
Boundary（停止条件）
↓
Ledger（判断履歴）
ここで重要なのは
AIの判断も、人間の判断も、同じTrace構造で保存される
ということです。
つまり
Decision Trace Model は
AI専用の技術ではない。
それは
人間とAIが共存する意思決定システム
の基盤です。
最後に
企業は長年、
-
図面
-
文書
-
コード
等の結果を資産化してきました。
しかし、
途中経過である判断
は資産化されていません。
Decision Trace Model は
判断を構造化し、企業資産に変える
ための枠組みです。
設計の価値は
結果ではない。
途中にある。
Decision Trace Model は
その「途中」を保存するための仕組みです。
コメント