なぜ今「意思決定グラフ」が必要なのか
AIシステムの説明可能性をめぐる議論は、長らく「このモデルがなぜそう予測したか」という問いに集中してきました。LIME や SHAP といった手法は、個別予測における特徴寄与を可視化するうえで有効ですが、現実の生成AIやエージェント環境では、最終的な出力は単一モデルだけで生まれません。入力データの選択、モデルの切り替え、外部APIの応答、オーケストレーション層、ガードレール、そして人間による手動承認——これら複数の「非人間アクター」が連鎖することで、はじめて結果が生成されます。
この構造的変化は、説明可能性に対してまったく新しい要求を突きつけます。監査対象を「一つのモデル」から「複数アクターの意思決定経路全体」へと拡張しなければ、AI システムの透明性もコンプライアンス対応も、形式的なものにとどまります。
本記事では、意思決定グラフという概念を軸に、説明可能性と監査可能性を同時に実現するアーキテクチャ設計の考え方を整理します。
従来のXAI手法が抱える限界
単一モデル説明から脱却できない現状
LIME は局所近似によって個別の予測を説明し、SHAP は特徴寄与を加法的に定義します。これらの手法は、単一の機械学習モデルの出力を解釈する場面では依然として有効です。しかし、エージェント型AIシステムでは次のような問題が生じます。
まず、外部ツール呼び出しの記録が困難です。あるステップでどのAPIが呼ばれ、何が返ってきたかは、モデル内部の特徴寄与では表せません。次に、モデルの切り替えが見えません。パイプラインの途中で別のモデルに処理が移る場合、それぞれの推論がどう連結されたかは追跡できません。さらに、制御フローが追えません。条件分岐やリトライ、ガードレールの適用といった手続き的な動作は、特徴寄与では表現の外側にあります。
Doshi-VelezとKimが提唱した「application-grounded・human-grounded・functionally-grounded」という説明評価の三層分類は今も有効ですが、それをエージェント環境に適用するためには、評価の対象そのものを更新する必要があります。
既存標準は分断されている
現在、関連する標準や仕様は複数存在します。Model Cards はモデルを、Datasheets はデータを、W3C PROV は来歴関係を、OpenLineage はデータフローを、ML Metadata はMLパイプラインのアーティファクトと実行関係を、OpenTelemetry/OpenInference は分散実行トレースを、MCP はツール契約をそれぞれ対象にしています。
問題は、これらが単一の監査オブジェクトとして統合されていないことです。それぞれの仕様が優れていても、横断的に一つの実行に紐づけられなければ、監査証跡としての有効性は限られます。求められているのは新しい要素技術の発明ではなく、既存の標準を「意思決定グラフ」という共通の監査面に束ねるメタモデル設計です。
意思決定グラフのメタモデル設計
グラフの基本構造と型定義
意思決定グラフは、「時間付き・型付き・版管理付きのプロパティ多重グラフ」として定義できます。形式的には DG = (N, E, T, A, L, B) と置き、N はノード集合、E はエッジ集合、T は時刻、A は属性写像、L はイベントログ、B は証跡束を表します。
各ノードの型は以下のいずれかです。
- DataArtifact：入力・出力データの実体
- ModelArtifact：推論に用いたモデルの実体
- ToolContract：ツールの契約定義
- ExecutionStep：実際の実行ステップ
- PolicyNode：ガードレール・認可・PII処理などのポリシー
- Principal：人間またはシステムの主体
- EvidenceBundle：証跡を束ねたパッケージ
エッジの型には、USED_BY、GENERATED、INVOKED、RETURNED、ROUTED_TO、PARENT_OF、CHECKED_BY、VERSION_OF、ATTESTED_BY などが含まれます。これらはW3C PROVのEntity/Activity/Agent/Bundle、OpenLineageのDataset/Job/Run/Facet、MLMDのArtifact/Execution/Context、OpenTelemetryのSpan/Event、MCPのTool schema/tools/list/tools/callにそれぞれ対応します。
「意思決定フロンティア」という概念
このメタモデルで特に重要なのが「意思決定フロンティア」の記録です。各ExecutionStepに対して、choice_set_refs[]（その時点で利用可能だったツール・モデル・プロンプトの集合）とselected_refs[]（実際に選ばれたもの）を保持します。
これがなければ、「なぜこのツールを呼んだのか」は説明できても、「なぜ他のツールではなかったのか」は監査できません。OpenTelemetryのgen_ai.tool.definitionsとMCPのtools/listは、この選択肢集合を復元するための一次情報です。監査可能な説明は、実行経路だけでなく、実行時の選択空間まで含めて初めて成立します。
イベントログの設計方針
イベントログは、スナップショット型ではなくappend-onlyのイベントソーシング形式にするのが望ましいです。OpenLineageのrun eventはeventTypeとeventTimeを核にして加法的にメタデータを追加できる設計であり、OpenTelemetryはtrace/span/parent-child関係を、MCPはtools/listとtools/callを提供します。
これらを一つの巨大なログに統合するのではなく、「共通キーで再結合できる多層ログ」として設計することが重要です。内容の全文は原則として保存せず、ハッシュと参照識別子を記録し、必要時のみ隔離ストアから復元する構成にします。これはOpenTelemetryが入力・出力の既定キャプチャを推奨しないこと、OpenInferenceがフィールドレベルのマスキングを重視することと整合します。
監査ワークフローの実践設計
証跡収集の三層構造
監査ワークフローは「対象の特定 → 証跡収集 → グラフ再構成 → 完全性検査 → 経路説明生成 → 再実行・差分検証 → 署名付き報告」の流れで設計します。証跡収集は三層に分けると扱いやすくなります。
Runtime証跡には、trace/span、LLM呼び出し、tool呼び出し、handoff、guardrail、retry、errorを含めます。Static証跡には、Model Card、Datasheet、tool contract、SBOM、利用ポリシー、権限スナップショットを含めます。Integrity証跡には、ハッシュ、署名、SLSA provenance、in-toto attestationを含めます。どれか一層でも欠けると、説明は「もっともらしい叙述」にはなっても、「検証可能な監査証跡」にはなりません。
監査観点と合格条件
主要な監査観点と合格条件の対応は以下の通りです。
| 監査観点 | 合格条件 |
|---|---|
| 対象同定 | 最終出力にrun_idと責任主体が付与されている |
| 経路完全性 | データ・モデル・ツール・実行まで上流に辿れる |
| 実行整合性 | trace_idに孤立がなく、時系列が単調である |
| ツール契約 | choice_setと実際のtools/callが一致している |
| ポリシー適合 | guardrail・認可・手動承認の結果が経路に紐付く |
| 改ざん耐性 | 署名・ハッシュ・attestationが存在する |
| 再現可能性 | deterministic区間の再実行結果が記録されている |
欠落証跡は暗黙補完せず、coverage_gapとして明示することが監査実務の鉄則です。たとえば、LLM応答は残っているがgen_ai.tool.definitionsが欠けている場合、「その判断がどのツール候補から選ばれたか」は監査不能となります。
可視化設計と選択的開示の原則
多面体UIの構成
意思決定グラフのUIは「経路」「状態」「証跡」「ポリシー」を同時に見せる多面体として設計します。開発者向けのObservability画面と監査人向けの証跡画面を分けるのではなく、同じグラフに複数の読み方を与える方が効率的です。
UIの主要ペインとしては、グラフキャンバス（ノードと関係エッジの全体像）、トレースタイムライン（span階層・retry・handoffの時系列）、エビデンスインスペクタ（hash・signature・attestationの検証）、ポリシーパネル（guardrail・認可の適用状況）、フロンティアビュー（実行時のchoice setと選択理由）、Diff/Replayペイン（run間の差分比較）、ナラティブパネル（自然言語による説明）が挙げられます。
「なぜ」と「なぜそうでないか」を分ける
説明可能性UIにおいて特に有効なのが、「why」と「why not」を明確に分けることです。「why」は実際に選ばれた経路の最小説明部分グラフを表示し、「why not」は同時点で可能だった他の経路をフロンティアビューに並べ、スキーマ不一致・認可不足・ルーティング方針・失敗リトライなどを理由として提示します。これにより、説明可能性が単なる「事後要約」ではなく、監査可能な選択アーキテクチャの提示として機能します。
観測可能性と秘匿性の両立
UIの設計原則として重要なのが選択的開示です。プロンプト・ユーザーメッセージ・ツール引数・ツール結果にはPIIや機密情報が含まれる可能性があるため、既定ではハッシュ・スキーマ・分類ラベル・vault参照のみを表示し、権限がある場合に限り原文を復号・閲覧する二層アクセスにすることを推奨します。監査に必要な追跡可能性を維持しつつ、プライバシーや営業秘密との衝突を抑える実践的な設計です。
評価指標と実験設計
三層の評価フレームワーク
評価はDoshi-VelezとKimの三層分類に沿って設計します。
Functionally-groundedでは、Path Completeness Score（上流到達率）、Evidence Binding Rate（hash/signature付与率）、Frontier Capture Rate（choice setのログ化率）、Replay Success Rate（再実行一致率）を測定します。
Human-groundedでは、Audit Query Time（監査人が「なぜ」に答える中央値時間）、Trust Calibration（確信度と正誤の相関）、Comprehension Score（理解テストの得点）を測定します。
Application-groundedでは、Root-Cause Localization Accuracy（障害原因の正確な特定率）、Policy Violation Recall（違反検出の再現率）、False Exoneration Rate（問題見落とし率）を測定します。
比較実験の設計
評価では、同一タスクに対して少なくとも三つの条件を比較します。条件Aはモデル説明のみ、条件BはRuntimeトレースのみ、条件Cは本設計の意思決定グラフです。各条件に対して障害注入（データ版ずれ・モデル版すり替え・ツールschema drift・権限スコープ不一致など）を行い、監査質問への正答率と所要時間で比較します。task正解率ではなく、「監査回答可能性（audit answerability）」を中心指標とすることが、この種の評価設計の要点です。
ガバナンスと実装上の提言
組織設計への落とし込み
最大の実装課題は、標準が多く成熟度も不揃いな点です。OpenTelemetryのGenAI関連セマンティック規約やMCPのセマンティック規約は発展途上のものが多く、外部標準は「upstream追従」、内部監査スキーマは「versionedプロファイルで固定」という二層管理が現実的です。
組織レベルでは「意思決定グラフ・オーナー」を設置することを推奨します。Data/Model/Tool/Executionを横断し、グラフプロファイル・ID管理・保持方針・redaction方針・再実行方針を統括する責任者です。NIST AI RMFに当てはめると、GOVERNはgraph policy、MAPはgraph inventory、MEASUREはgraph metrics、MANAGEはgraph incident responseに対応します。
調達・契約への反映
外部ベンダーとの契約には、以下の統制を必須条項として盛り込むことを勧めます。traceparent互換の分散トレース伝播のサポート、tool contractのversionとschema hashの固定可能性、tools/listないし利用可能tool definitionsのスナップショット取得可能性、Model CardとDatasheetの機械可読での提供、SBOMとbuild provenanceの提示可能性、監査ログのexport可能性——これらは日本のAI事業者ガイドライン、EU AI Actの記録保持要求、NIST AI RMFと方向が一致します。
まとめ：説明可能性の再定義に向けて
本記事で示した意思決定グラフの設計は、説明可能性と監査可能性を同時に満たすための統合的アプローチです。要点を三つに絞ると次のようになります。
第一に、各実行ノードで「何が呼ばれたか」に加え、「何が呼べたか」をログ化すること。これがなければ「なぜ他の選択肢でなかったか」は答えられません。
第二に、ログは内容全文の無差別保存ではなく、ハッシュ・参照・要約を中心に設計し、秘匿データは別保管にすること。監査の目的は「すべてを見ること」ではなく「必要時に検証可能に参照できること」です。
第三に、監査パッケージは技術文書・実行ログ・契約スナップショット・署名付きアテステーションを束ねた単位として出力されるべきこと。説明は「文章」ではなく「再構成可能な証拠付きグラフ」であるべきです。
AIシステムの説明可能性を「モデルの説明文」、監査可能性を「ログ保管」として別々に管理する時代は終わりつつあります。データ・モデル・ツール・実行を一体化した意思決定グラフこそが、異議申立て・事故調査・規制対応に耐える透明性の基盤となります。
コメント