結論：AIは「正しく動く設計」だけでなく「後から説明できる設計」がないと監査・苦情で詰まる

AI導入後に最も静かに、しかし深刻に効いてくる失敗が、「なぜこの結果になったのか」を後から説明できないことである。監査人に問われても、顧客から苦情が来ても、社内で責任を確認しようとしても、入力・参照したデータ・使ったモデルとバージョン・途中の判断過程が記録されていなければ、個別の出力を再現することも根拠を示すこともできない。説明可能性とトレーサビリティを発注時の要件に入れていないと、運用が始まってから「説明できないブラックボックス」を抱え込むことになる。

  • AIの説明責任は、出力が正しいかどうかではなく、その出力を後から再現・説明できるかどうかで問われる。
  • 説明可能性（なぜそう判断したかを示せる）とトレーサビリティ（何を入力し何を参照したかを追える）は別物で、両方を設計する必要がある。
  • 監査・苦情・社内説明の三場面はいずれも「個別の一件」の根拠提示を求めるため、平均精度の説明では答えにならない。
  • どこまで記録するかはコストと表裏一体で、業務のリスクに応じて記録粒度を設計するのが現実的である。
  • 説明・監査対応は開発後に付け足せない要件であり、発注時に明記しておく必要がある。

この連載は「AI開発発注の失敗図鑑」として、発注側がつまずきやすい論点を一つずつ分解している。第26回となる本稿は、データ保護を扱った回や規制準拠を扱った回、責任分界を扱った回とは切り口を分け、「個別の一件をなぜそう判断したのかを後から再現・説明できるか」という説明可能性・トレーサビリティに絞って解説する。データを守れるか（セキュリティ・個人情報を後回しにするリスク）でも、ルールに従えているか（規制・ガイドライン準拠）でも、誰が責任を負うか（HITL・責任分界）でもなく、本稿は「後から一件ずつ根拠を示せる状態を作れているか」を扱う。

なぜ「判断根拠を説明できない」と詰まるのか

監査では「平均的に正しい」ではなく「この一件の根拠」を問われる

監査の場面で問われるのは、AI全体の精度や正答率ではなく、問題になった「その一件」がなぜその結果になったのかである。「全体としては高精度です」という説明は、個別の一件の妥当性を問う監査には答えになっていない。何を入力し、どのデータを参照し、どのモデルがどう判断したのかを一件単位で再現できなければ、監査人に対して根拠を提示できず、AIの利用そのものを止めざるを得ない事態に至る。

この「一件の再現」は、ルールに従っているかという準拠の話とは層が異なる。準拠は方針やプロセスの整備で示せる部分があるが、説明責任は実際の出力を後から再構成できることを求める。準拠の論点は連載第15回の規制・ガイドライン準拠で扱ったが、本稿はその一段下、「個別の判断を後から開ける状態か」を問う点で別の設計課題である。

苦情対応で根拠を示せないと不信が連鎖する

顧客や利用者から「なぜこの扱いになったのか」と苦情が来たとき、根拠を示せなければ、不信は個別の一件を超えて広がる。説明できないAIは「都合よく決めている」と疑われ、一度そう受け取られると、後から精度を改善しても信頼は戻りにくい。苦情対応で必要なのは謝罪ではなく、何を根拠に、どういう過程でその結果になったのかを具体的に示すことである。それができるかどうかは、出力時点で根拠を記録していたかにかかっている。

ここで誰が説明し誰が責任を負うのかは、人間がどこで関与するかという責任分界の設計と密接に関わる。HITLや責任分界の論点は連載第19回のHITL・責任分界で扱ったが、責任の所在が決まっていても、説明する材料（記録）がなければ責任者は答えようがない。本稿は「答えるための材料を残す設計」を扱う点で、責任分界の前提を支える論点である。

社内説明・再発防止でも記録がないと原因にたどり着けない

AIが想定外の出力を出したとき、社内で原因を確認し再発を防ぐには、その時点の入力・参照データ・モデルの状態を追える必要がある。記録がなければ「たまたま変な出力が出た」で終わり、同じ問題が繰り返される。説明可能性とトレーサビリティは、外部対応だけでなく、社内の品質改善とガバナンスを回すための基盤でもある。この観点は推進体制の整備と地続きで、連載第23回の推進体制・ガバナンスで扱った組織側の備えと合わせて設計したい。

「説明可能性」と「トレーサビリティ」を比較する

両者は混同されがちだが、求められる場面も実装も異なる。整理すると、なぜ両方が要るかが見えてくる。

観点説明可能性トレーサビリティ
問いの形なぜその判断になったのか何を入力し、何を参照したのか
主な対象判断の理由・根拠の提示入力・データ・モデル・経路の追跡
監査での役割妥当性の説明に使う事実関係の再現に使う
主な記録対象判断に効いた要因・参照根拠入力内容・参照データ・モデルとバージョン・処理ログ
欠けたときの困り方根拠を示せず信頼を失うそもそも何が起きたか再現できない
設計の力点根拠を人に分かる形で残す一件単位で経路をたどれるように残す

説明可能性は「なぜ」を人に分かる形で示すこと、トレーサビリティは「何を・どこから」を一件単位でたどれることである。トレーサビリティだけあっても理由を説明できなければ監査・苦情で納得は得られないし、説明の言葉だけあっても裏付ける記録がなければ後から疑われる。両方を要件に入れて初めて、後から一件を開いて答えられる状態になる。

後から説明するために残す五つの要素

実務上は、次の要素を残せているかで「後から再現・説明できるか」が決まる。

  • 入力：その出力を生んだ実際の入力内容（ユーザーの問い合わせや投入データ）。
  • 参照データ：判断に使った社内データや外部ソースと、その時点の版（どの文書・どの行を見たか）。
  • モデルとバージョン：どのモデル・どの設定・どのバージョンで処理したか。後日モデルが更新されると、記録がなければ当時の挙動を再現できない。
  • 判断ログ：処理の経路や中間的な過程、しきい値や分岐の結果など、判断に効いた情報。
  • 根拠の提示：以上を、人に説明できる形（参照箇所や理由の要約）でまとめられること。

これらのうち参照データの版管理は、入力データの質そのものとも関わる。データの状態が記録されていなければ、後から「当時どのデータを見たか」を再現できない。データ品質の論点は連載第3回のデータ品質で扱ったが、説明可能性の観点では「品質」だけでなく「どの版を参照したかの記録」まで設計する必要がある。

ブラックボックスのまま発注するリスク

「とにかく動くものを」という発注で説明可能性を要件に入れないと、納品物は出力するが根拠を残さないブラックボックスになる。動いているうちは問題が表面化しないが、最初の監査・苦情で一気に行き詰まる。そして説明機能やログは、運用が始まってから後付けしようとすると、過去の出力には遡れず、記録項目の追加にも大きな改修が要る。説明・監査対応を要件に含めるかどうかは、検収・受け入れ基準の置き方とも直結する。何をもって「完成」とするかの論点は連載第21回の検収・受け入れ基準で扱ったが、「後から説明できること」を受け入れ基準に含めておくことが、ブラックボックス納品を避ける防波堤になる。

発注前に確認すべきこと（チェックリスト）

説明可能性での失敗は、発注時に説明・監査対応を要件へ含めるかどうかで大きく変わる。発注前に次を確認したい。

  • 監査・苦情・社内説明の三場面で「個別の一件」の根拠を示す必要があるかを業務ごとに洗い出しているか。
  • 入力・参照データ・モデルとバージョン・判断ログ・根拠提示の五要素のうち、どこまで記録するかを要件として決めているか。
  • 参照したデータの「どの版を見たか」まで追えるよう、データの記録方法が設計に入っているか。
  • モデルやプロンプトを更新した後でも、過去の出力当時の挙動を再現・説明できる仕組みがあるか。
  • 記録の保存期間・保存範囲を、業務のリスクと運用コストの両面から決めているか。
  • 説明・トレーサビリティの実現を検収・受け入れ基準に含め、納品時に確認する手順があるか。
  • 記録自体が個人情報や機密を含む場合の保護・アクセス制御を、セキュリティの観点で設計しているか。
  • 誰が監査・苦情に対して説明するのか（責任者と参照する記録）を決めているか。

このチェックリストの多くは、対象業務が「説明責任の重い領域か」の見極めと直結する。導入可否そのものに不安がある場合は、AI導入可否アセスメントで対象業務の説明責任の重さと記録要件を切り分けてから着手すると、後付け改修を避けやすい。説明可能性とトレーサビリティを要件に織り込んだ形で設計を進めたいなら、AI開発の進め方と合わせて、最初の要件定義から相談するのが現実的である。

GXOに相談する前に整理しておくとよい情報

相談前に次を整理しておくと、説明・監査対応の議論が具体化しやすい。

  • 対象業務と説明責任の重さ：その業務でAIの判断が監査・苦情・規制の対象になりうるか、なるとしてどの程度の根拠提示を求められるか。
  • 想定される説明の相手と場面：監査人・顧客・社内のいずれに、どんな場面で根拠を示す必要があるのか。
  • 参照するデータの状態：判断に使う社内データ・外部ソースが、版や更新履歴を追える形になっているか。
  • 記録に関する制約：記録自体が個人情報や機密を含む場合の保護要件、保存期間・保存範囲に関する社内規程。
  • 意思決定体制：説明・監査対応の責任者は誰か、記録の運用・点検を誰が担うのか。

これらが揃っていると、AI開発を「動けばよい」ではなく「後から説明できる」形で設計しやすくなる。記録が個人情報や機密を含む場合は、セキュリティ支援の観点で、ログの保護とアクセス制御を併せて整理しておくと安全である。説明・記録の作り込みには相応の工数がかかるため、投資規模の妥当性を社内で通す段になったら、システム開発の稟議・ROI診断の観点で、記録設計の範囲と効果を整理しておくと意思決定がスムーズになる。

補足：実務上の注意点

「説明できる」を業務リスクに応じて段階設計する

説明可能性とトレーサビリティは、すべての出力を最大粒度で記録すれば安心という話ではない。記録が増えるほど保存・運用コストと、記録自体の保護負担も増える。重要なのは、業務のリスクに応じて記録粒度を変えることである。監査・苦情・規制の対象になりやすい判断は手厚く、影響の小さい補助的な出力は軽く、と段階的に設計するのが現実的で、ここを一律に決めるとコストが過大になるか、肝心な場面で記録が足りないかのどちらかに陥る。

公開フレームワークは「一般的な考え方」として参照する

AIの説明可能性・透明性については、国内のAI事業者向けガイドラインや個人情報保護委員会の示す考え方、海外で参照されるNIST AI RMFなど、一般に公開された枠組みがある。これらは記録・説明をどう設計するかの考え方を整理する助けになるが、本稿では条文や具体的な数値には踏み込まず、あくまで一般的な方向性として参照するにとどめる。自社の業務にどの要件がどの程度かかるかは、対象領域と適用法令を踏まえて個別に確認する必要がある。

モデル更新で「当時の挙動」を失わないようにする

見落とされやすいのが、モデルやプロンプトの更新によって過去の出力を再現できなくなる問題である。当時どのモデル・どの設定で処理したかを記録していなければ、後から「なぜあのときそうなったのか」を再現できない。説明可能性は出力時点の記録に依存するため、モデルやプロンプトのバージョンを出力と紐づけて残す設計を最初から組み込んでおきたい。

記録は作るだけでなく「取り出せる」ことが要る

記録を残していても、必要なときに一件分を素早く取り出せなければ監査・苦情対応では役に立たない。膨大なログの中から該当する一件を特定し、関係者に分かる形で提示できることまでが説明可能性である。記録の保存と、取り出し・提示の手順をセットで設計しておくことが、いざという場面で行き詰まらないために欠かせない。

関連記事

よくある質問

Q1. 説明可能性とトレーサビリティは何が違うのか。

トレーサビリティは「何を入力し、どのデータを参照し、どのモデルで処理したか」を一件単位で追えること、説明可能性は「なぜその判断になったのか」を人に分かる形で示せることである。事実関係を再現するのがトレーサビリティ、その妥当性を説明するのが説明可能性で、監査や苦情対応では両方が必要になる。

Q2. すべての出力を記録すれば説明できるようになるのか。

記録があることと説明できることは別である。膨大なログを残しても、該当する一件を素早く取り出し、判断に効いた根拠を関係者に分かる形で提示できなければ役に立たない。また全出力を最大粒度で記録すると保存・保護コストが過大になるため、業務のリスクに応じて記録粒度を段階設計するのが現実的である。

Q3. 説明機能は運用が始まってから後付けできないのか。

後付けは難しい。説明やログは出力時点で記録していなければ過去の出力には遡れず、記録項目を追加するにも大きな改修が要る。さらにモデルやプロンプトを更新すると当時の挙動を再現できなくなる。説明・監査対応は発注時の要件に含め、検収・受け入れ基準でも確認しておくのが現実的である。

Q4. 規制やガイドラインに従っていれば説明責任は果たせるのか。

準拠と説明責任は層が異なる。ルールに従う方針やプロセスを整えることと、実際に問題になった個別の一件を後から再現・説明できることは別の備えである。準拠は本連載第15回で扱った論点だが、本稿の説明可能性・トレーサビリティはその一段下で、個別の判断を後から開ける状態を作れているかを問うものである。

発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。

AIの判断は、正しく動くことと同じくらい「後から説明できること」で評価される。説明可能性・トレーサビリティを要件に織り込んだ設計や、監査・苦情対応に耐える記録づくりでお困りの場合は、無料相談から、対象業務と説明責任の整理を一緒に始めていただきたい。