検索ログでも監視ログでもない──企業の「Decision Trace」をどう集め、判断資産に変えるか

🎥 YouTubeでも公開しています

検索・監視から、企業の判断資産へ｜Decision Trace Model と Trust Infrastructure

Books: Decision Trace Fabric on AWS: Built-in と Attachedー企業の判断をつなぐ Decision Trace Fabric の設計

AIを企業業務に導入するとき、多くの組織はまず検索、要約、監視、アラートから始める。

規程や過去事例を検索できるようにする。設備データを監視して異常を知らせる。AIが問い合わせに回答し、参照文書を示す。これらは確かに重要であり、現場で価値を生みやすい入口でもある。

しかし、企業活動の本質は、情報を見つけることや異常を検知することだけではない。

検知した後に何をするのか。
複数の選択肢のうち、どれを選ぶのか。
誰が、どの権限と責任のもとで承認するのか。
何を根拠に、どのリスクを引き受け、どの条件で再評価するのか。

ここに企業の判断がある。

Semantic Digital Twin が現実世界の状態や変化を意味づけて捉え、Knowledge Flow が組織に散在する知識を接続・流通させるなら、Decision Trace Model は、その知識と現実を使って行われた判断を記録し、再利用可能な資産へ変える構造である。

そして Trust Infrastructure は、その判断記録が「後から説明できる」だけでなく、「本当にその時点で、その権限を持つ主体が、その根拠に基づいて行ったものだ」と検証できるようにする。

本稿では、検索履歴や監視イベントに閉じない、企業のための Decision Trace をどう設計し、どのように集めていくべきかを考える。

Decision Trace は「AIの説明文」ではない

Decision Trace という言葉から、AIが生成した説明文や、回答時に表示される参照元を想像するかもしれない。

たとえば、

• この回答はどの文書を参照したか
• この推奨はどの特徴量に基づくか
• このアラートはどの閾値を超えたため出たか

といった情報である。

これは重要な Evidence Trace、すなわち「根拠の追跡」である。しかし、企業に必要な Decision Trace はそれより広い。

Decision Trace が記録すべきなのは、次の問いに答えるための最小構造である。

誰、または何が、どの状況で、どの権限のもと、何を判断し、どの根拠と代替案を用い、何を実行し、その結果はどうだったか。

ここには、AIだけでなく、人、業務システム、機器、ルールエンジン、複数のAgentが含まれる。

したがって、Decision Trace は単なるログではない。
それは、現実の変化、利用可能だった知識、判断、実行、結果、学びをつなぐ「判断の因果構造」である。

企業にある判断は、すでに分散している

多くの企業では、重要な判断に必要な材料はすでに存在している。しかし、それらは一つのシステムにはない。

設備保全を例にすると、判断に関わる情報は次のように分散している。

• IoTやPLCにある温度、振動、電流、稼働時間
• MESにある製番、工程、作業実績
• 品質システムにある検査結果、不良内容、是正記録
• ERPにある部材Lot、在庫、調達情報
• 文書管理にある保全基準、作業手順、変更履歴
• チャットや会議にある現場の気づき、仮説、判断理由
• ワークフローにある承認・差戻し・例外処理
• 実行系にある設備停止、隔離、発注、復旧の記録

異常の発生は監視システムで捕捉できるかもしれない。しかし、企業が本当に知りたいのは次のようなことだ。

• どの製品・Lot・顧客への影響を、なぜその範囲と判断したのか
• なぜ即時停止ではなく監視継続を選んだのか
• どの手順書の例外を適用したのか
• 誰が最終的に隔離・出荷・復旧を承認したのか
• その判断は結果として妥当だったのか
• 次回、何を早く検知し、どの判断を自動化または支援できるのか

この連鎖が残らなければ、組織は毎回「そのとき分かっていた人」に依存する。ベテランの暗黙知、個人のメール、会議の記憶の中に、判断資産が閉じ込められることになる。

Decision Trace を構成する六つの層

企業の判断を扱うには、少なくとも六つの層を区別しておくとよい。

層	記録するもの	例
Reality Trace	現実世界の状態と変化	振動上昇、Lot入庫、納期遅延、顧客行動
Evidence Trace	判断に使った根拠	規程、検査結果、過去事例、図面、外部情報
Decision Trace	選択・承認・保留・却下	停止する、隔離する、値引きを承認する
Action Trace	判断を受けた実行	設備停止、出荷保留、発注、顧客通知
Outcome Trace	実行後に生じた結果	不良率、損失、復旧時間、顧客影響
Learning Trace	振り返りと知見の更新	閾値変更、手順改訂、再発防止策

この区別は、データ基盤を複雑にするためのものではない。

むしろ、「検知された事実」と「人やAIが下した判断」と「その結果」を混同しないために必要である。

たとえば「振動値が規定値を超えた」は Reality Trace である。
「設備を止め、過去24時間に処理したLotを隔離する」は Decision Trace である。
「停止コマンドを送り、Lotを出荷保留にした」は Action Trace である。
「隔離したLotに不良は見つからず、2時間で復旧した」は Outcome Trace である。

この違いを保つことで初めて、企業は後から「アラートの精度」だけでなく、「判断と実行は妥当だったか」を評価できる。

記録すべきは、すべての行動ではなく「判断点」である

Decision Trace を導入する際に、最初に避けるべきなのは、すべてのデータ、すべての会話、すべての操作を収集しようとすることである。

これはコスト、プライバシー、現場負荷、運用不信のいずれにおいても持続しない。

重要なのは、業務フローの中にある「判断点」を特定することである。判断点とは、複数の選択肢があり、選択によって責任、コスト、リスク、顧客影響、あるいは安全性が変わる地点である。

典型的には、次のようなものがある。

• 基準外データに対する停止・継続・追加確認の判断
• 品質異常に対するLot隔離範囲の判断
• 納期遅延時の優先順位変更
• 与信、値引き、購買、採用における例外承認
• AIの提案を採用・却下・保留する判断
• 権限外または規程例外の処理を承認する判断
• インシデント発生時の公開、報告、復旧の判断

こうした判断点だけを最初の対象にすれば、Trace は「監視」のためのデータ収集ではなく、組織が責任を持って学ぶための記録になる。

企業の Decision Trace は、どう集めるのか

収集方法は、すべてを自動化する必要はない。むしろ、データの性質に応じて三つの方式を組み合わせるべきである。

1. システム・現場から自動取得する

Reality Trace と Action Trace の多くは、既存システムから取得できる。

• 設備、センサー、カメラ、RFID、バーコード
• ERP、MES、WMS、CRM、SCM
• 品質管理、保全管理、チケット、ワークフロー
• 文書管理、権限管理、監査ログ
• AI Agent の検索、推論、ツール利用、実行結果

ただし、元データをすべて中央に複製する必要はない。重要なのは、判断に関係するイベントを意味づけて接続できることだ。

たとえば、単なる「振動値 12.4」という時系列データではなく、

SFN-Machine-01 において、製番 P-1028 の加工中、治具交換から37分後に、通常帯域を超える振動変化が検出された

というように、設備、工程、製番、時間、変更履歴との関係を持つイベントとして扱う。

ここで Semantic Digital Twin が、物理世界のデータを判断可能な文脈へ変換する役割を果たす。

2. 判断の瞬間に、軽く記録する

人の判断理由を毎回長文で書かせる運用は失敗しやすい。

その代わり、承認画面、例外処理画面、AIの提案画面、保全チケットなど、すでに人が仕事をしている場所に、軽量な記録項目を置く。

たとえば、次の程度でよい。

• 選択した判断：停止／継続／隔離／追加確認
• 主な理由：安全、品質、顧客影響、規程、コスト、納期
• 参照した根拠：候補から選択またはリンク
• 未確実な点：何が未確認か
• 再評価条件：何が起きたら判断を見直すか
• 決裁・承認：誰が最終責任を持つか

ここで重要なのは、自由記述をゼロにすることではない。
人にしか書けない「なぜ今回は例外と判断したか」「何を懸念しているか」を、短くても残せるようにすることである。

3. 事後的にAIが下書きを作り、人が確定する

会議、メール、チャット、報告書には、判断に至る文脈が大量にある。これらを人手で完全に構造化することは現実的ではない。

そこでAIは、決定者ではなく Trace の編集支援者として使える。

AIは、分散した記録から次の候補を生成する。

• 判断候補
• 関係者と役割
• 参照された根拠
• 検討された代替案
• 実行されたアクション
• 未解決の論点
• 結果評価のために追うべき指標

しかし、AIが推定した内容を、そのまま正式記録にしてはならない。

特に、責任者、承認、例外理由、外部への説明が必要な事案では、人が確認して初めて正式な Decision Trace とする。AIの出力は「候補」「下書き」「解釈」であり、原本や承認の代わりではない。

一つの判断を、どのようなデータ構造で持つか

Decision Trace の一件は、次のような構造で表せる。

項目	内容
Decision ID	判断を一意に識別するID
Decision Question	何を決める必要があったか
Scope	対象設備、Lot、顧客、契約、拠点など
Decision Maker	人、組織、Agent、ルールエンジン
Authority	その判断を行う権限、委任、承認条件
Context Snapshot	判断時点の現実状態と制約条件
Evidence Set	用いた文書、データ、事例、外部情報
Alternatives	検討した選択肢と却下理由
Decision	採用した選択肢、確信度、条件
Action Plan	実行内容、担当、期限、連携先
Policy Binding	適用した規程、例外、ガードレール
Outcome	実行結果、影響、測定指標
Review	事後評価、差分、学び、見直し内容
Integrity Data	時刻、署名、ハッシュ、版、出所

この構造があれば、後から単に「何をしたか」を検索するだけでなく、次のような問いに答えられる。

• 同様の条件で過去にどの判断をしたか
• その判断はどの程度成功したか
• どの根拠が結果の良し悪しと関係していたか
• 誰の経験・どの規程・どのデータが判断に効いたか
• 例外が頻発しているルールはどれか
• AIの提案が人に採用されない条件は何か

ここに、Knowledge Flow が生まれる。

判断の記録は、単なる監査証跡ではなく、次の意思決定に流れ込む再利用可能な知識になる。

Trust Infrastructure は「収集基盤」ではなく「信頼の条件」を集める

Trust Infrastructure を考えるとき、ブロックチェーンや改ざん耐性のある台帳を最初に思い浮かべることがある。

それらは一つの技術的な選択肢ではある。しかし、Trust Infrastructure の本質は、特定技術ではない。

本質は、判断記録について次のことを検証できる状態を作ることである。

• そのデータはどこから来たのか
• いつ取得され、どのように変換されたのか
• 誰または何が判断・承認・実行したのか
• その主体には、その時点で必要な権限があったのか
• 判断時点で適用されていた規程やモデルは何か
• 後から内容が書き換えられていないか
• 修正された場合、何が、なぜ、誰によって修正されたか

そのために、Trust Infrastructure は判断内容とともに「信頼の条件」を収集する。

信頼の条件	収集する情報
Identity	人、組織、Agent、機器、データ源のID
Authority	役割、権限、委任、承認経路
Provenance	原本、取得経路、変換履歴、利用履歴
Integrity	ハッシュ、署名、改ざん検知情報
Time	発生、取得、判断、承認、実行の時刻
Policy	適用規程、しきい値、例外条件、モデル版
Accountability	承認者、異議、差戻し、責任境界
Disclosure	閲覧・利用・共有できる範囲と目的

たとえば、AIが「出荷を保留すべき」と提案した場合、Trust Infrastructure が必要とするのは提案文だけではない。

• どのモデル、プロンプト、検索設定で生成したか
• 参照した文書・データは何か
• それらは当該担当者が利用してよい情報だったか
• どのポリシーに照らして提案したか
• 誰が提案を確認し、最終判断を行ったか
• 実行内容は何で、結果はどうだったか

これにより、AIの説明可能性は「もっともらしい説明文」から、検証可能な意思決定記録へ進む。

重要なのは、上書きしないこと

企業の判断は、後から見れば誤りである場合もある。だからこそ、Decision Trace は「正しい結論だけを保存するデータベース」ではない。

最初の判断、追加で得られた証拠、判断変更、実行結果、事後評価を時間順に残す必要がある。

たとえば、

1. 異常を検知した
2. 当初は監視継続と判断した
3. 追加検査でLot差の可能性が高まった
4. 対象Lotを隔離した
5. 調査の結果、治具ずれが原因と判明した
6. 閾値と点検手順を改訂した

という流れを、後から上書きして「治具ずれが原因だった」とだけ残してしまうと、当時なぜ監視継続を選んだか、どの時点で何が分かったか、判断変更は適切だったかが失われる。

Trust は「誤りがないこと」から生まれるのではない。
不確実な状況でどのように判断し、何が分かった時点でどう修正したかを、正直に追跡できることから生まれる。

導入は、一つの高価値な判断連鎖から始める

全社の意思決定を一度に Trace 化する必要はないし、そうすべきでもない。

最初に選ぶべきなのは、次の条件を満たす業務である。

• 現実世界または業務システム上のイベントがある
• 判断点が明確である
• 複数の根拠を必要とする
• 例外処理や属人的判断が多い
• 実行後の結果を測定できる
• 安全、品質、収益、顧客、コンプライアンスのいずれかに影響する

製造であれば、「設備異常から影響範囲の特定、Lot隔離、復旧、再発防止まで」が有力な最初のテーマになる。

小売であれば、「需要変化・在庫・粗利・競合状況を踏まえた値引き判断と結果評価」が対象になる。

金融・審査であれば、「例外案件における追加確認、根拠、承認、条件変更、回収結果」が対象になる。

重要なのは、AIの回答精度だけをKPIにしないことだ。

見るべきは、たとえば次のような指標である。

• 判断から実行までの時間
• 追加確認の回数
• 例外判断の再発率
• 判断後の手戻り、損失、事故、不良
• 根拠不足による差戻し率
• 同種案件での判断のばらつき
• 過去の判断資産の再利用率
• AI提案の採用・修正・却下の理由

検索・監視から、企業の判断資産へ

検索は知識への入口であり、監視は現実の変化への入口である。

しかし、企業価値を左右するのは、その後に行われる判断である。

Semantic Digital Twin によって現実を意味のある状態として捉える。
Knowledge Flow によって、分散した知識、経験、規程、結果をつなぐ。
Decision Trace Model によって、判断・根拠・実行・結果を記録し、次の判断に活かす。
Trust Infrastructure によって、その記録の出所、権限、完全性、時点性を検証可能にする。

この四つがつながるとき、企業は単にAIを導入するのではない。

現実世界と組織知を接続し、判断そのものを学習・検証・改善できる能力へ変えていく。

AI is not prediction. It is decision.

そして、信頼できるAIとは、答えをうまく説明するAIではない。
現実に対して何を判断し、その判断がどの根拠・権限・責任・結果の上に成り立つのかを、後から検証できるAIである。