「説明できるAI」は判断を良くするのか｜705人の実験が示した効く条件と効かない条件
社内向けAIツールの要件定義で、「判断根拠を表示する機能」が項目に入ることが増えました。AIの出力をそのまま信じさせるのは危険だから、なぜそう判断したのかを見せる。ブラックボックスを避ける。方向としては、まっとうに聞こえます。
ただ、要件を書き進めるうちに、目的が入れ替わっていることがあります。「現場の判断を良くするために説明を出す」が、いつのまにか「説明可能性を実装する」こと自体になっているという入れ替わりです。そして、説明を出せば判断が良くなるという前提そのものは、たいてい検証されないまま残ります。
この記事では、参加者705名・観測6,959件のユーザースタディをもとに、説明つきAIが効く条件と効かない条件を整理します。
出典は論文「Are Concept Bottleneck Models Effective as Decision-Support Systems?」（Bogani, Debole, Marconato, Pugnana, Tentori, Passerini、arXiv:2608.25581、2026年8月26日投稿）です。査読や学会採択の記載はなく、プレプリントである点を先に添えておきます。
30秒で要点
- 研究は、参加者705名・観測6,959件の2つの大規模ユーザースタディで、概念ベースの説明と、ユーザーによる概念への介入が、人とAIのチームの成績に与える影響を2つの二値分類タスクで評価した
- 結果として、説明つきモデル（特にその対話的な要素）は、支援なしの人間単独の成績とも、説明できないAI支援を受けた場合の成績とも比べて、チームの正答率を改善しうるとされている
- ただし論文は、その利得が生じるのは3つの条件下のみだと明記している——難しいと知覚されたタスク、容易に識別できる概念、モデルとの能動的な相互作用
- 論文は、概念検出が不正確な場合にユーザーのモデルへの信頼を損なう可能性についても論じている
| 用語 | 意味 |
|---|---|
| 概念（concept） | 人間が理解できる中間的な手がかり。「この画像には縞模様がある」のような、判断の材料になる要素 |
| 概念ボトルネックモデル（CBM） | 入力からまず人間が理解できる概念を検出し、その概念を使って予測を出す設計のAI |
| 介入（intervention） | ユーザーがモデルの検出した概念の値を書き換え、予測がどう変わるかを見ること |
| 二値分類タスク | 答えが2択（該当する／しない）になる判定作業 |
この研究が測ったもの
まず、何を測った研究なのかをはっきりさせます。
対象となっているのは、概念ボトルネックモデル（CBM）と呼ばれる設計のAIです。入力から直接答えを出すのではなく、いったん人間が理解できる「概念」を検出し、それを経由して予測を組み立てます。この設計であれば、ユーザーは予測の根拠になった概念を点検できますし、概念の値を別の構成に置き換えたときに予測がどう変わるかも探索できます。だからこそ、人とAIの協働を支える有力な方式とされてきました。
ただし論文は、その実際の有効性を検証したユーザースタディは限られている、と述べています。そこで実施されたのが、参加者705名・観測6,959件からなる2つの大規模ユーザースタディです。2つの異なる二値分類タスクで、概念ベースの説明と、ユーザーが概念に介入することが、人とAIのチームの成績にどう影響するかを評価しています。
数字を分母と分子で捉えておくと、705名の参加者が、合計6,959件の判断を行ったという規模です。1人あたりおよそ10件の観測に相当します。
結果は「改善しうる」であって「改善する」ではない
結果について、論文はこう書いています。CBMは、特にその対話的な要素が、(a)支援なしの人間単独の成績、および(b)解釈できないAI支援を受けた場合の成績、その両方と比べて、人とAIのチームの正答率を改善しうる。
ここで2つ、押さえておきたい点があります。
ひとつは、比較対象が2つあることです。「AIなしの人間」より良いだけでなく、「説明のないAIを使った人間」よりも良い、とされています。つまり、AIを使うこと自体の効果と、説明があることの効果が、いちおう切り分けられた形になっています。
もうひとつは、「改善しうる（can improve）」という表現です。常に改善すると書かれているわけではありません。そしてこの但し書きこそが、この論文の中心にあります。
利得が出るのは、3つの条件がそろったときだけ
論文は続けて、こう述べています。「これらの利得が生じるのは、一定の条件下でのみである」。挙げられている条件は3つです。
- 難しいと知覚された分類タスク（classification tasks perceived as difficult）
- 容易に識別できる概念（easily identifiable concepts）
- モデルとの能動的な相互作用（active interaction with the model）
この3つを、要件定義の言葉に置き換えてみます。
1つ目は、対象業務が難しいと現場に思われているかどうかです。注意したいのは「難しい」ではなく「難しいと知覚された」と書かれている点で、客観的な難易度ではなく、担当者がどう感じているかが条件になっています。簡単だと思っている作業に説明を足しても、そもそも根拠を読む動機が生まれません。
2つ目は、AIが示す根拠が、人間の側で見分けのつくものになっているかどうかです。表示された概念が、担当者にとって「たしかにこれは判断材料だ」と分かる粒度でなければ、説明として機能しません。専門用語の羅列や、内部的な特徴量の名前がそのまま出ているような画面は、この条件を満たしません。
3つ目は、使う人が能動的に関わっているかどうかです。ここが実務では最も落ちやすい条件です。論文の実験では、ユーザーが概念の値を書き換えて予測の変化を見る「介入」が含まれており、論文自身が「特にその対話的な要素が」と書いています。表示を眺めるだけの説明機能は、この研究が効果を報告している状態とは違うということになります。
なぜ「説明を出せば良くなる」と考えてしまうのか
条件付きだと言われると当たり前に聞こえますが、要件定義の現場ではこの前提が検証されないまま進みます。それにはいくつか理由があります。
ひとつは、説明可能性が「あるか・ないか」で書ける要件だからです。「根拠を表示する」は仕様として書けますし、実装できたかどうかも判定できます。一方「担当者が根拠を読んで判断を変えられる状態にする」は、仕様書に落としにくい。書ける形のほうが要件に残ります。
もうひとつは、説明機能が反対されにくいことです。ブラックボックスは避けるべきだという合意はほぼ全員が持っているため、「根拠を出す」という提案は会議を通ります。通ってしまうと、それが効く条件を誰も点検しないまま実装に進みます。
そして三つ目に、効果が測られないという事情があります。説明機能を入れたあとで、担当者の判断精度が上がったかどうかを測っている組織はまれです。測っていなければ、条件を満たしていないまま運用されていても、それに気づく契機がありません。
説明が外れたとき、信頼のほうが削れる
もう一点、論文が触れているのが逆方向の作用です。概念検出が不正確な場合に、ユーザーのモデルへの信頼を損なう可能性がある、と論じられています。
これは、説明機能の設計を考えるうえで見落としやすい非対称性です。説明が当たっているときの効果は「判断が少し良くなる」ですが、説明が外れたときの効果は「このAIは信用できない」という判断に及びます。しかも後者は、その1回の判断だけでなく、以降の利用全体に影響します。
説明を出すという設計は、AIの内部を可視化する分だけ、間違いも可視化されます。可視化された間違いを見た人が何を結論するかまでを含めて、設計の範囲だということになります。
確かなことと、まだ確かではないこと
確かなこと：この研究が参加者705名・観測6,959件、2つの二値分類タスクで実施されたこと。CBM（特に対話的な要素）が、支援なしの人間単独および説明できないAI支援の両方と比べてチーム正答率を改善しうるとされていること。その利得が3条件（難しいと知覚されたタスク・容易に識別できる概念・能動的な相互作用）の下でのみ生じると明記されていること。概念検出が不正確な場合の信頼への影響が論じられていること。
まだ確かではないこと：この論文はarXivのプレプリントであり、査読や学会採択の記載はありません。また、各条件下で正答率がどれだけ改善したかという具体的な数値は、本記事が確認した範囲（アブストラクト）には記載がないため扱っていません。扱われているのは2つの二値分類タスクであり、業務上の複雑な判断——選択肢が2つに割り切れない、正解が後になるまで分からないといった判断——に同じ結果が当てはまるかどうかは、この研究からは分かりません。
判断軸の提示
「説明を出すかどうか」ではなく、「その説明を読んだ人が、何かを操作できるか」を要件にすること。
3つの条件のうち、実装側でいちばん動かせるのが3つ目の能動的な相互作用です。難易度は業務側の性質で決まりますし、概念の識別しやすさもある程度はデータ側の制約を受けます。一方、ユーザーが根拠に手を触れられるかどうかは、画面の設計で決まります。
確認する順序としては、次のようになります。
- その業務は、現場から難しいと思われているか — 簡単だと思われている作業に説明を足しても、読まれない
- 表示する根拠は、担当者の言葉になっているか — 内部的な特徴量の名前が並んでいるなら、まだ説明ではない
- 担当者は、根拠に対して何かできるか — 見るだけか、書き換えて結果の変化を見られるか
- 説明が外れたときに、何が起きるか — 外れた説明を見た人がどう受け取るかまでを想定しているか
このうち3番目が「見るだけ」で止まっている場合、この研究が改善を報告している状態には達していない可能性があります。
自分でも試せる、最小の検証
いま計画している、あるいは既に動いているAIツールの画面を1つ開いて、「担当者はこの根拠表示に対して、何を操作できるか」を挙げてみてください。
操作が「読む」しかないのであれば、この研究の3条件目を満たしていません。次の一歩は、機能を増やすことではなく、担当者が根拠のどれか1つを疑ったときに、それを反映して結果の変化を見られる経路が1本あるかを確認することです。その経路が無いなら、説明は表示されていても、判断には触れていないことになります。
この記事で扱ったような、AIツールの要件設計を自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。
状況を整理する（15分）