「説明できるAI」から「証明できるAI」へ Chinoba PFが目指す、判断を検証可能にするための基盤

🎥 YouTubeでも公開しています

説明できるAIから、証明できるAIへ──Chinoba PFが目指す「検証可能な判断基盤」

Books:『Decision Trace Model 実践導入ガイド』: ― 製造・医療・リテール・マルチエージェントで学ぶAI意思決定システム ―

生成AIを業務に導入するとき、多くの組織がまず求めるのは「説明できるAI」である。

なぜこの提案をしたのか。
どの文書を参照したのか。
どのような手順で結論に至ったのか。

AIが理由を自然な文章で説明し、根拠らしき情報を添えられることは、確かに重要である。ブラックボックスのまま答えだけを返すAIより、利用者は内容を理解しやすくなる。

しかし、設備保全、品質管理、審査、金融、公共サービス、医療、製造、重要インフラのように、判断の影響が大きい領域では、それだけでは足りない。

そこで問われるのは、次の問いである。

その説明はもっともらしいだけなのか。
それとも、後から第三者が確認し、再現し、検証できる判断なのか。

この差が、「説明できるAI」と「証明できるAI」の差である。

Chinoba PFは、AIの出力をわかりやすく説明するためだけの基盤ではない。人、AI、知識、ルール、権限、実行、結果をつなぎ、ある判断がどの条件のもとで正当に行われたのかを検証可能にするための基盤である。

説明は、AIが後から語ることができる

説明できるAIは、たとえば次のように答える。

温度上昇と過去の保全履歴を参照し、異常の可能性が高いと判断しました。

この説明は利用者にとって便利である。AIの結論を理解し、次の行動を考える助けになる。

だが、この一文だけでは重要なことが分からない。

• どの温度データを、いつ取得したのか
• センサーデータは正常に取得されていたのか
• 参照した保全履歴は、現在も有効な情報なのか
• 適用したルールは誰が承認したのか
• 例外条件や安全制約は確認されたのか
• AIの提案を誰が承認したのか
• 実際に何が実行され、その結果はどうだったのか

生成AIは、説明文を非常に上手く作れる。だが、流暢な説明は、それ自体では事実や正当性の証明にならない。

AIが「この判断は安全です」と説明しても、その文が安全性を保証するわけではない。AIが「この規程に従いました」と述べても、実際にどの版の規程を、どの条件で適用したかが残っていなければ、監査や再検証には耐えられない。

説明は、理解のためのインターフェースである。
しかし証明は、信頼と責任のための構造である。

証明できるAIは、判断の成立条件を残す

ここでいう「証明」は、すべてを数学的定理として証明するという意味ではない。

現実の業務では、センサー値、文書、現場観察、熟練者の判断、例外対応など、不確実な要素が多く存在する。したがって必要なのは、AIの結論が絶対に正しいと主張することではない。

必要なのは、次のことを追跡可能な形で残すことである。

この判断は、どの観測、知識、ルール、権限、制約、承認、実行記録に基づいて成立したのか。

証明できるAIは、単に「理由」を返すのではない。判断の成立条件を、再確認可能な記録として保持する。

説明は、判断を理解するために必要である。
証明は、判断を任せ、実行し、責任を持つために必要である。

AIの出力はSignalであり、Decisionではない

Chinoba PFの重要な原則の一つは、SignalとDecisionを分けることである。

AIが出した回答、推奨、要約、予測、異常検知結果は、有用なSignalである。しかし、それをただちに正式なDecisionとみなしてはならない。

たとえばAIが「設備を停止すべきです」と提案したとしても、そこには少なくとも次の確認が必要になる。

• 現在の設備状態はどうか
• 安全停止の条件は満たされているか
• 停止による生産・供給への影響は何か
• 代替手段はあるか
• 誰に停止を承認する権限があるか
• 人による確認が必要な境界を超えていないか

AIの出力をそのまま実行へつなぐ構造では、説明があったとしても、判断の責任境界が曖昧になる。

Chinoba PFでは、AIの出力をSignalとして受け取り、Context、Knowledge、Policy、Constraint、Authority、Human Gateを通じてDecisionへ変換する。そして、許可された範囲だけをExecution Authorizationとして実行系へ渡す。

この分離により、AIは重要な判断支援を担いながらも、権限なき実行主体にならない。

Chinoba PFは、意味・判断・信頼を接続する

Chinoba PFは、単なるチャット画面やRAG基盤ではない。AI・人・組織・社会をつなぐContext Infrastructureであり、Physical AIを含む業務AIのためのSemantic and Decision Control Planeである。

その中心には、五つの層がある。

1. Knowledge Plane
   文書、マニュアル、規程、過去事例、現場知識を取り込み、意味、適用範囲、例外、版、承認状態を管理する。文書から抽出されたルール候補を、そのまま実行可能なルールにはしない。
2. Semantic Twin Plane
   設備、人、工程、顧客、案件、組織などのEntity、Relationship、State、Eventを表現する。現実世界の観測を、判断可能なContextへ変換する。
3. Decision Plane
   AIのSignal、観測値、知識、ルール、制約を結び、どの選択肢を採るべきかを扱う。ここでは提案と正式なDecisionを分離する。
4. Trust and Governance Plane
   Provenance、Authority、Policy、Human Gate、Autonomy Control、Decision Traceを扱う。誰が何を根拠に、どの権限で判断・承認したかを残す。
5. Physical Integration Plane
   センサー、業務システム、ロボット、機械、外部サービスなどと接続する。ただし、AIが直接命令を出すのではなく、認可されたActionだけを接続する。

この構造によって、業務上の出来事は次の流れで扱われる。

Observation → Context化 → Knowledge・Policy照合 → Decision形成 → Human Gate・Authorization → Action → Result Observation → Decision Trace

重要なのは、Actionのあとにも記録が続くことである。

結果を観測し、判断時の予測や前提と照合することで、組織は単にAIを使うだけでなく、判断の質を継続的に学習できる。

Decision Traceは「説明履歴」ではない

Decision Traceは、AIがどのような文章を返したかを保存する会話ログではない。

それは、判断を構成する要素を接続する記録である。

• どのObservationが入ったか
• どのKnowledgeを参照したか
• そのKnowledgeは誰が承認し、どの版だったか
• どのPolicyとConstraintを適用したか
• AIはどのSignalを出したか
• 人は何を確認し、何を承認または却下したか
• どのExecution Authorizationが発行されたか
• 実際にどのActionが行われたか
• 結果はどうなり、何を見直すべきか

このように記録されたDecision Traceは、説明のためだけでなく、監査、再現、改善、責任分界、教育、ルール改訂に使える。

たとえば事故や異常が起きたとき、「AIが誤った」とだけ結論づけても、組織は学べない。

本当に確認すべきなのは、AIのモデル出力だけではない。

• 参照知識が古かったのではないか
• ルールの適用範囲が誤っていたのではないか
• センサーの欠損を検知できなかったのではないか
• 人の承認条件が曖昧だったのではないか
• 実行権限の境界が広すぎたのではないか
• 結果のフィードバックが次の判断へ反映されていなかったのではないか

Decision Traceは、失敗を個人やAIモデルの責任へ単純化せず、判断システム全体を改善可能にする。

「根拠付き回答」だけでは、業務AIの信頼はつくれない

RAGやKnowledge Graphによって根拠を添えるAIは、すでに多くの価値を生んでいる。検索精度を上げ、出典を示し、誤答を減らすことは重要である。

しかし、根拠付き回答と証明可能な判断の間には、まだ距離がある。

根拠付き回答は、「どの文書を参照したか」を示す。
証明可能な判断は、「なぜその文書を使ってよいのか」「そのルールを誰が承認したか」「誰に実行権限があるか」「実行結果はどうだったか」まで扱う。

つまり、必要なのは検索の精度だけではない。

• Knowledge Flowによる知識の来歴管理
• OntologyとSemantic Digital Twinによる意味と状態の共有
• DSLやPolicyによるルール・制約の明示
• Human Gateによる責任ある関与
• Trust Engineによる権限と信頼の評価
• Decision Traceによる判断経路の保存
• Boundary Designによる自律性の制御

これらがつながって初めて、AIは「説明の上手なアシスタント」から、組織が責任をもって使える判断基盤へ進む。

Chinoba PFが目指すもの

Chinoba PFが目指すのは、AIに万能な正解を出させることではない。

むしろ、不確実な現実の中で、人、AI、知識、ルール、組織の責任を適切につなぐことである。

AIは仮説を出す。
知識は根拠を提供する。
ルールは境界を定める。
人は責任を伴う判断を行う。
実行系は認可された範囲だけを動かす。
Decision Traceは、その全体を将来の検証と学習のために残す。

このときAIは、単に「なぜそう答えたのか」を説明する存在ではなくなる。

どの根拠、ルール、権限、承認、実行結果によって、その判断が成立したのかを示せる存在になる。

説明可能性は、AIを理解するための出発点である。
証明可能性は、AIと共に判断し、行動し、改善していくための基盤である。

Chinoba PFは、その移行を支えるためのプラットフォームである。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance