Built-in と Attached──企業の判断をつなぐ Decision Trace Fabric の設計

🎥 YouTubeでも公開しています

企業の判断をつなぐ「Decision Trace Fabric」— AI時代の説明可能な意思決定基盤

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

企業にAIを導入するとき、多くの場合、個別の業務課題から始まる。

製造現場なら、設備異常の検知、品質問題の分析、影響Lotの特定。
小売なら、在庫、需要、粗利、競合状況を踏まえた値引き判断。
購買なら、見積比較、納期、品質、過去実績を考慮したサプライヤー選定。
審査や金融なら、例外案件の追加確認、条件変更、承認判断。
営業や顧客対応なら、問い合わせ、提案、エスカレーション、優先順位づけ。

こうした個別ソリューションは、それぞれにAIを組み込み、現場の判断を支援できる。

しかし、個別ソリューションが増えていくほど、新たな課題が現れる。

各システムは、それぞれの判断を記録しているだろうか。
その判断が何を根拠とし、誰によって承認され、何を実行し、どのような結果になったのかを追えるだろうか。
そして、ある業務で得られた判断と学びを、別の業務でも再利用できるだろうか。

ここで必要になるのが、Decision Trace である。

Decision Trace は、AIの回答履歴でも、単なる監査ログでもない。現実の変化、根拠、判断、実行、結果、学びをつなぎ、企業の意思決定を再利用可能な資産へ変える仕組みである。

この仕組みを企業に広げるには、二つの方式を持つ必要がある。

一つは、新しく作るソリューションに最初から Decision Trace を組み込む Built-in Trace。
もう一つは、既存のERP、MES、CRM、ワークフロー、品質管理システムなどに、外付けで Decision Trace を付与する Attached Trace である。

重要なのは、この二つを別々の仕組みにしないことだ。

両者を共通の仕様でつなぐ基盤を、ここでは Decision Trace Fabric と呼ぶ。

二つの導入方式が必要な理由

新規ソリューションでは、業務フロー、AI Agent、データモデル、承認画面を設計する段階から、Decision Trace を組み込める。

たとえば、設備保全AIが「設備を停止し、直近24時間に加工したLotを隔離する」という提案を出す場面を考える。

このとき、提案の根拠、参照した保全基準、設備状態、影響を受けるLot、代替案、承認者、実行された停止操作、復旧結果までを、一連の Trace として記録できる。

これは Built-in Trace に適した世界である。

一方、企業にはすでに多くの重要なシステムがある。ERP、MES、PLM、CRM、WMS、品質管理、保全管理、文書管理、承認ワークフローなどである。

こうした既存システムを、Decision Trace のために全面改修したり、置き換えたりすることは現実的ではない。システムによってはAPIが限定され、データモデルも変更できず、長年の業務運用と密接に結び付いている。

そこで必要になるのが Attached Trace である。

既存システムの原本データや業務フローを尊重しながら、その外側に Trace Adapter を置く。イベント、状態変更、承認記録、文書参照、実行結果を取り込み、既存システムだけでは不足する判断理由や例外条件を補う。

Built-in と Attached の二方式を持つことで、企業は新規AIソリューションから着実に判断資産を蓄積しつつ、既存の重要業務にも段階的に適用できる。

Decision Trace Fabric とは何か

Decision Trace Fabric は、すべてのデータを一箇所に集める巨大なデータレイクではない。

それは、複数の業務システム、AIソリューション、現場機器、人、Agentにまたがる判断を、共通の意味と信頼条件で接続する層である。

flowchart TB
  subgraph New["新規ソリューション"]
    A["業務アプリ / AI Agent"] --> B["Decision Trace SDK"]
  end

  subgraph Legacy["既存システム"]
    C["ERP / MES / CRM / Workflow"] --> D["Trace Adapter / Gateway"]
  end

  B --> E["Decision Trace Fabric"]
  D --> E

  E --> F["Trace Graph<br/>判断・根拠・行動・結果"]
  E --> G["Trust Layer<br/>ID・権限・出所・完全性"]
  E --> H["検索・分析・AI Agent"]

Fabric が持つべきものは、主に四つである。

• 判断、根拠、行動、結果を共通形式で表す Trace Schema
• Trace 同士や業務オブジェクトの関係を保持する Trace Graph
• ID、権限、出所、完全性、時刻を扱う Trust Layer
• 人とAIが判断履歴を確認、比較、学習できる Workspace

この基盤があれば、製造AI、見積査定AI、値引きAI、審査AI、顧客対応AIは、それぞれ独立して機能しながら、企業全体の判断能力を蓄積するネットワークになる。

共通化すべき最小単位

新しいソリューションであっても、既存システムに外付けする場合であっても、Decision Trace の基本構造は共通でなければならない。

最低限、次の項目を持つべきである。

項目	意味
Decision ID	判断を一意に識別するID
Decision Question	何を決める必要があったか
Scope	設備、Lot、製品、顧客、契約、拠点などの対象
Actor	人、AI Agent、システム、機器などの判断主体
Authority	判断・承認を行うための権限、委任、ポリシー
Context	判断時点の現実状態、制約、関連イベント
Evidence	文書、データ、過去事例、検査結果、外部情報
Alternatives	検討した選択肢と採用しなかった理由
Decision	選択した内容、理由、確信度、条件
Action	実行内容、担当、期限、実行結果
Outcome	判断後に生じた品質、収益、顧客、安全上の結果
Review	事後評価、学び、ルールや手順の見直し
Integrity	時刻、出所、署名、ハッシュ、訂正履歴、版情報

ただし、このすべてを毎回、人が入力する必要はない。

設備アラートのような低リスクの自動判断では、入力イベント、適用ルール、実行結果だけで十分な場合もある。

一方で、出荷停止、与信例外、値引き例外、安全対応、規制対象の判断などでは、代替案、承認、再評価条件、証拠の版、訂正履歴まで必要になる。

重要なのは、判断の重要度とリスクに応じて、Trace の密度を変えられる設計にすることである。

Built-in Trace：新規ソリューションに判断の構造を埋め込む

新しく作るAIソリューションでは、Decision Trace を後から追加するログ機能として扱うべきではない。

AIが提案する。人が確認する。承認する。実行する。結果を評価する。

この業務フローそのものの中に、Trace を組み込む。

そのための主要コンポーネントは、次の四つである。

Decision Trace SDK

アプリケーション、AI Agent、ルールエンジンから、共通仕様の Trace を発行するためのSDKである。

たとえば、アプリケーション側は次のような流れで Trace を記録する。

trace.open(question, scope, context)
trace.addEvidence(evidenceRef)
trace.propose(option, rationale, confidence)
trace.requestApproval(policy)
trace.recordDecision(selectedOption, actor)
trace.recordAction(actionResult)
trace.recordOutcome(metrics)
trace.review(learning, ruleChange)

これは開発者に「すべての内部処理を記録せよ」と求めるものではない。

何を決める必要があったか。
何を根拠に提案したか。
誰が最終的に何を選んだか。
何を実行し、どんな結果になったか。

この最小の流れを、どのソリューションでも一貫して記録できるようにする。

Decision Workspace

Trace は、開発者や監査担当だけが見る裏側のログであってはならない。

現場の担当者、管理者、承認者が、判断の根拠、代替案、不確実な点、再評価条件を確認できる画面が必要である。

特にAIの提案に対して、人が単に「承認」または「却下」を押すだけでは不十分である。

人がどの部分を修正したか。
どの根拠を重視したか。
AIが見落とした現場条件は何だったか。
なぜ今回は例外として扱ったか。

こうした差分が、次の改善のための Learning Trace になる。

Trace Store と Trace Graph

個々の Trace を時系列で保存するだけでは、企業横断の学習には不十分である。

一つの判断は、設備、Lot、製品、顧客、規程、文書、担当者、別の判断、結果とつながっている。

たとえば、ある設備異常に対する判断は、次のような関係を持つ。

• 特定の設備状態を根拠にする
• 特定のLotへ影響する
• 特定の保全手順書を参照する
• 品質管理者の承認を受ける
• 出荷保留というアクションを起こす
• 顧客への納期影響につながる
• 後の手順改訂に反映される

Trace Graph は、この関係を扱うための構造である。

これにより、後から「同じような設備状態で、過去にどの判断をしたか」「この規程の例外はどの部署で頻発しているか」「AIの提案はどの条件で人に修正されるか」といった問いに答えられるようになる。

Review & Learning Loop

Decision Trace の価値は、意思決定時だけでは終わらない。

実行後の結果を追跡し、判断が妥当だったかを評価し、規程、しきい値、プロンプト、Agent、業務手順へフィードバックする必要がある。

これが Learning Trace である。

AIを導入しても、判断と結果の関係を学習しなければ、組織は同じ例外、同じ手戻り、同じ属人的な判断を繰り返す。

Decision Trace は、AIを「回答する仕組み」から「企業の判断能力を改善する仕組み」へ進めるための基盤になる。

Attached Trace：既存システムに外付けで判断の文脈を与える

既存システムには、すでに価値の高いデータと業務履歴が存在する。

ERPには発注、在庫、購買、会計の事実がある。
MESには設備、工程、製番、作業実績がある。
CRMには顧客接点、案件、提案、受注履歴がある。
ワークフローには申請、承認、差戻し、例外処理の履歴がある。

しかし、既存システムだけでは、多くの場合、次の問いには十分に答えられない。

なぜ、この時点でこの判断を選んだのか。
他にどの選択肢があり、なぜ採用しなかったのか。
どの規程や証拠を根拠にしたのか。
どの条件で、この判断を見直すべきだったのか。

Attached Trace は、既存システムを置き換えるのではなく、そこにあるイベントや記録を、判断可能な文脈へ拡張する。

Trace Adapter と Trace Gateway

既存システムの外側に Trace Adapter、または Trace Gateway を置く。

接続方法は、システムの特性に応じて選ぶ。

接続方式	取得できるもの	適した対象
API / Webhook	更新、承認、状態変更、実行イベント	SaaS、クラウド業務システム
Change Data Capture	レコード追加・更新・状態遷移	ERP、MESなどの既存DB
Event / Message連携	設備、IoT、業務イベント	MQTT、Kafka、ログ基盤
文書・会話の補助取込	判断理由、論点、背景の候補	メール、会議録、チケット、帳票

例えば既存MESでは、設備アラート、製番、Lot、品質保留フラグ、担当者、承認時刻といった情報が取得できる。

それを共通の Decision Trace と対応づける。

既存MESの情報	Decision Trace 上の意味
equipment_alarm	Reality Trace
work_order_id	Scope
operator_id	Actor
quality_hold_flag	Decision または Action
approval_user_id	Authority / Accountability
change_timestamp	Time / Integrity
inspection_record_id	Evidence
disposition_code	Outcome の候補

こうして既存システム内の出来事を、単なるレコード変更ではなく、判断の連鎖を構成するイベントとして扱えるようにする。

外付けで補うべき情報

既存システムにない情報を無理に改修して持たせる必要はない。

必要な場合にだけ、Trace Workspace、承認画面、あるいはAIの下書き支援を通じて、次の情報を補えばよい。

• 判断理由
• 適用した規程と例外条件
• 検討した代替案
• 未確定の事項
• 再評価の条件
• 結果を評価するための指標

たとえば、AIが会議録、チケット、品質記録から「隔離判断の候補」と「根拠候補」を作成する。担当者はそれを確認し、必要なら修正して正式な Trace とする。

AIは正式な判断の作成者ではなく、分散した判断文脈を構造化する編集支援者として機能する。

二つの方式を本当に接続するための五つの仕様

Built-in Trace と Attached Trace をつなぐには、イベントを集めるだけでは足りない。

少なくとも、次の五つを共通仕様として定義する必要がある。

1. Identity

人、組織、AI Agent、機器、Lot、文書、顧客、契約、業務オブジェクトに、安定した識別子を付ける。

同じ設備、同じLot、同じ文書、同じ人物を、システムごとに別物として扱っていては、Trace を横断できない。

2. Semantic Model

「設備」「工程」「Lot」「規程」「証拠」「判断」「承認」「実行」「結果」といった概念を、企業横断で一貫して扱える意味モデルが必要である。

全社共通の巨大なOntologyを最初から作る必要はない。まずは一つの業務領域で使う最小の語彙から始め、関連する領域へ拡張すればよい。

3. Evidence Reference

原本をすべてFabric側に複製するのではなく、原本への参照を残す。

参照には、文書ID、版、作成元、取得経路、アクセス権、ハッシュ、利用時刻を含める。

これにより、機密情報を無制限に複製せず、既存システムを原本管理者として尊重できる。

4. Trust Envelope

Trace の内容だけでなく、誰が、いつ、どの権限で、どのポリシーに基づいて記録したかを付与する。

これを Trust Envelope と呼ぶ。

{
  "trace_id": "dt_01J...",
  "trust_envelope": {
    "issuer": "maintenance-app",
    "actor_id": "user_123",
    "actor_role": "quality-manager",
    "authority_snapshot": "policy-role-v7",
    "source_refs": [
      "mes:alarm-0081",
      "qms:inspection-882"
    ],
    "source_versions": {
      "maintenance-procedure": "v4.2",
      "ai-model": "model-2026-10"
    },
    "created_at": "2026-10-31T10:02:00Z",
    "content_hash": "sha256:...",
    "previous_trace_hash": "sha256:...",
    "correction_policy": "append-only"
  }
}

Trust Envelope により、後から次を確認できる。

• そのTraceを作ったのはAIか、人か、どのシステムか
• 当時、どの規程、権限、モデルが適用されていたか
• 元データはどこにあり、どの版だったか
• 後から内容が変更されていないか
• 訂正された場合、誰が、なぜ、いつ訂正したか

5. Event Contract

Trace の状態遷移を共通化する。

たとえば、proposed、approved、executed、reviewed、superseded といった状態を標準化する。

これにより、異なるソリューションや既存システムのイベントを、「まだ提案段階か」「すでに承認されたか」「実行済みか」「結果レビューまで完了したか」という共通のライフサイクルで扱えるようになる。

Trust Infrastructure は、判断のための検証可能な封筒である

Trust Infrastructure は、最初からブロックチェーンを導入することではない。

本質は、Decision Trace の周囲に、その真正性を検証するための情報を付けることにある。

誰が作成したのか。
その人やAgentには権限があったのか。
いつ作成されたのか。
どの原本、どの版、どのモデル、どのポリシーを使ったのか。
後から書き換えられていないか。
誤りが見つかったとき、修正の履歴を残しているか。

実装の初期段階では、追記型の履歴、ハッシュ連鎖、電子署名、時刻証明、権限スナップショットで十分に始められる。

複数企業間の取引、サプライチェーン、証憑、第三者監査のように、組織をまたぐ信頼が必要になった段階で、共有台帳、第三者証明、検証者Agentなどを追加すればよい。

Trust は、「間違いがない」ことから生まれるのではない。

不確実な状況でどのような判断が行われ、何が分かった時点でどのように修正され、誰が責任を持ったかを、後から検証できることから生まれる。

推奨する導入順序

Decision Trace Fabric は、最初から全社共通基盤として大規模に構築するべきものではない。

一つの高価値な業務で、Built-in Trace と Attached Trace を一つずつ動かし、共通仕様を実証しながら広げるべきである。

Phase 1：Decision Trace Core

• 共通 Trace Schema v1
• Trace ID、Actor ID、Evidence Reference の仕様
• 追記型の Trace Store
• 一つの新規AIソリューションへのSDK組込み
• 一つの既存システムへのTrace Adapter接続
• 判断、根拠、行動、結果を時系列で見るTrace Viewer

Phase 2：Decision Trace Workspace

• AIによるTrace下書き
• 人による確認、承認、訂正
• 例外判断の軽量フォーム
• DecisionとOutcomeの紐付け
• 類似判断の検索と比較
• 基本的な出所、権限、ハッシュ管理

Phase 3：Cross-Solution Decision Graph

• Semantic Digital Twinとの接続
• 複数ソリューションの判断関係の可視化
• 一つの変更が、どの判断群に影響するかの分析
• AI Agentによる過去判断と結果を踏まえた提案
• Learning Traceから規程、ルール、プロンプトを改善する仕組み

Phase 4：Trust Network

• 組織や企業をまたぐ署名と証明
• 委任、承認権限の検証
• 監査・規制対応向けの証跡パッケージ
• サプライヤー、顧客、第三者検証者との限定共有
• Decision Trace を基盤とした Trust Infrastructure の外部化

個別AIから、企業の判断能力を蓄積する基盤へ

新規ソリューションに Decision Trace を標準搭載する。
既存システムには、外付けの Trace Adapter を提供する。
両者を、共通の意味モデル、Evidence Reference、Trust Envelope、Trace Graphで接続する。

この形ができれば、企業は個別のAIアプリを増やすだけではなくなる。

設備異常への判断。
品質問題への判断。
購買、値引き、審査、顧客対応の判断。
そして、AIの提案を採用、修正、却下する判断。

これらが分断されたログではなく、つながった判断資産として蓄積されていく。

Semantic Digital Twin は現実世界を意味のある状態として捉える。
Knowledge Flow は分散した知識、規程、経験、結果を流通させる。
Decision Trace Model は、判断、根拠、実行、結果を再利用可能な構造にする。
Trust Infrastructure は、それらが本当に信頼できる経路で生成・承認・更新されたことを検証可能にする。

Chinoba が目指すべきものは、単なるAIアプリケーション群でも、単なるデータ統合基盤でもない。

現実世界と組織知を接続し、企業が行った判断を、説明でき、検証でき、学習でき、次の判断へ活かせる能力として蓄積する Runtime Platform である。

AI is not prediction. It is decision.

そして、Decision Trace Fabric は、その判断を企業の持続的な知性へ変えるための基盤になる。