ASADASHI
因果関係の複数の解釈を示すミニチュア紙工作の分岐路ジオラマ
研究・論文2026.06.25·読了 2·難易度: むずかしい

AIは「なぜ」を正しく答えられるのか?因果推論の限界

因果関係の複数の解釈を示すミニチュア紙工作の分岐路ジオラマ

朝の出汁版(通勤2分)

  • ポイント1: LLMに「原因を特定して」と聞いても、その判断基準の定義自体が研究者間でまだ統一されておらず、7つの有力な定義が互いに矛盾することが論文で示された。
  • ポイント2: AIが「Aが原因でBが起きた」と答えたとき、その根拠となるロジックは複数の解釈が混在している可能性があり、出力を鵜呑みにする前に「どういう意味での原因か」を問い直す視点が必要。
  • ポイント3: 原因分析や施策効果の整理にAIを使いたい人は、まず「なぜそう判断した?」と追加質問する習慣をつけるところから始めると、AIの推論の穴が見えてくる。

出汁の素(深読みモード)

「原因」の定義が7つあって、しかも全部矛盾している

哲学・AI研究の世界で「実際の因果関係をどう定義するか」という問いに、Andreas & Günther という研究者コンビが一連の論文を通じて7つの定義を提案してきた。それらは「事実的な差異生成」「反事実的な差異生成」「規則性ベース」という3種類のアプローチに分類されてきたのだが、最新の論文でその分類自体が崩れることが示された。

具体的には、彼らが最新版として提示した定義を精査すると、それが3種類すべての性質を同時に持ってしまっていた。つまり「この定義は他と違う」という主張の根拠が消える。さらに著者が7つの定義を複数のテストケースで比較したところ、互いに矛盾する結論が出るケースが複数確認された。7年かけて積み上げた体系が、自己参照的に崩れる構造になっていたわけだ。

これは学術上の話に見えるが、実用上の問いに直結する。「なぜ売上が落ちたか」「あの施策が効いたのか」——AIにこういった原因分析を頼む場面は増えているが、その判断を支える「因果関係」の定義が研究者間でも固まっていないという事実は、使う側として押さえておきたい。

AIが「Aが原因です」と言うとき、裏側で何が起きているか

現行のLLMは、因果関係を「確率的な共起パターン」で学習している。学習データの中で「AのあとBが起きる」という組み合わせが多ければ、AをBの原因として答える傾向が強くなる。これは因果推論の研究でいう「規則性ベース」のアプローチに近い。

ところが人間が「なぜ?」と聞くとき、求めているのはもっと踏み込んだ説明——「Aがなければ、Bは起きなかったか(反事実的差異)」や「Aは実際にBを生み出す働きをしたのか(事実的差異)」——であることが多い。LLMはこれらを明確に区別せず、問いのニュアンスや文脈に応じてどれかのロジックに乗って答えを生成する。

今回の論文が示したのは、その「どれかのロジック」の候補すら研究者間で統一されていないという事実だ。つまり、AIが出す因果的な結論は「複数の互いに矛盾しうる解釈のどれかに乗った答え」であり、どの解釈なのかはモデル自身も明示しない。「AIが仕事を奪う」研究、実は穴だらけだったで紹介したように、AI由来の主張の精度を過信するリスクはここにも潜んでいる。

原因分析でAIを使うとき、最初に投げるべき追加質問

では使う側はどう構えるか。ポイントは「AIが出した因果的な結論を、そのままアウトプットに使わない」という一点に尽きる。具体的には、以下の質問を続けて投げることで、推論の根拠を引き出せる。

① 「それはどういう意味での『原因』?」と聞く 「Aが原因でBが起きた」という答えをもらったら、「Aがなければ、Bは起きなかったと言える?」「Aが実際にBを引き起こす働きをしたと言える?」と別角度で問い直す。答えが変わるなら、最初の返答は「相関の言い換え」に近い可能性が高い。

② 「反例を挙げて」と聞く 「AとBが無関係のケースや、Aがあってもいった事例は?」と追うことで、モデルが答えを一方向に寄せていないか確認できる。

③ 「どの情報に基づいている?」と聞く 学習データの傾向なのか、会話内で与えた文書からの推論なのかを分けて確認する。前者なら出所が曖昧で、後者なら自分で原典を確認できる。

この3ステップは「AIの推論を壊すための質問」ではなく、「AIが黙って選んでいる解釈を表に出させる」操作だ。分析結果を人に見せる前の最終チェックとして習慣化すると、アウトプットの信頼度が上がる。

因果推論ツールとAIを組み合わせる方向性

より踏み込むなら、LLMによる「言語的な原因分析」と、統計的因果推論ライブラリを組み合わせる構成が現実的だ。Pythonの dowhycausalml は、反事実分析や介入効果の推定を数式ベースで実行できるため、「LLMで仮説を言語化 → 構造的なツールで検証」という流れが作れる。

LLMは「どの変数間に関係がありそうか」を自然言語で整理するのは得意だ。一方で「その関係が本当に因果なのか」を担保する力は持っていない。両者の役割を分けて設計することで、分析の精度と説明可能性が同時に上がる。

完全に自動化しようとするより、「LLMが出した仮説リストを、人間が構造的ツールで一本ずつ叩く」という分業のほうが、今の技術水準では安定する。

参照ソース