AIに原因を調べさせると「それっぽい答え」で止まる ― 根本原因まで追わせる方法

トラブルの原因をAIに尋ねると、たいていはもっともらしい理由が一つ返ってくる。「アプリの動作が重いのはサーバーが遅いから」「開封率が下がったのは件名が弱かったから」。筋は通っているし、そのまま受け取りたくなる。ところが手を打ってみても状況が変わらない、ということが起きる。最初に返ってきた原因が、症状の一部しか説明していなかったからだ。

これはAIの手抜きではなく、言語モデルの推論のクセに近い。モデルが示す理由の説明は、実際に答えへ至った道筋を忠実に反映しているとは限らず、筋の通った説明に見えても、最初の答えを支える形に寄ることがある。しかも、自分の推論を外部の手がかりなしに見直すのも得意ではない。つまり「もっとよく考えて」と頼んでも直りにくい。効くのは、原因を最後まで追わせる手順――残差監査――を外から与えることだ。

なぜ最初の「それっぽい原因」で止まるのか

書き出した理屈が、本当の理由とは限らない

言語モデルが示す「理由の説明」は、必ずしもその答えにたどり着いた本当の道筋とは限らない。思考過程（Chain-of-Thought）の忠実性を調べたAnthropicの研究（Lanham ほか, 2023）によると、思考を書き出させても、その記述が実際の判断根拠を忠実に反映しているとは限らないという。書かれた説明が筋の通ったものに見えても、それが答えを決めた本当の根拠とは限らない。

この「先に結論があり、あとから理屈が整えられたように見える」性質は、原因調査と相性が悪い。最初に思いついたもっともらしい原因が仮の結論になり、以降の説明はその結論を支える方向へ寄っていく。反証になりそうな症状は自然と視界から外れ、一つの原因で話が閉じてしまう。

自力での見直しはあてにならない

ならば「もう一度見直して」と指示すればいいかというと、そう単純でもない。言語モデルの自己修正を検証した研究（Huang ほか, ICLR 2024）は、外部からの手がかりなしに自分の推論を修正させると、精度が上がるどころか下がる場合すらあることを報告している。自己修正には、正しい方向を示す外部の基準が要る。

この二つを重ねると、原因調査でAIを使うときの勘所が見えてくる。放っておけば一つの答えに閉じ、「見直して」だけでは改善が保証されない。だから対策は、モデルの「気の持ちよう」ではなく、外から与える手順で成り立たせる。

「追い切らせる」ための三つの手順

やることは難しくない。原因を一つ挙げさせて終わりにせず、次の三段階を毎回踏ませる。

症状を全部並べ、説明しきれない点を「残差」として書かせる

最初に、観測された症状をすべて箇条書きにさせる。次に、挙がった原因でそれらの症状が「全部」説明できるかを一つずつ照らし合わせ、説明しきれない点を「未説明」として明示させる。この未説明の残り（残差）が、次に掘るべき場所を教えてくれる。一つの原因で満足せず、まず「説明できていない症状はどれか」を可視化するのがこの手順の核心だ。

残差がある限り、原因を一段深くする

未説明が残っている限り、そこを起点に「なぜそれが起きるのか」をもう一段だけ掘る。大事なのは、回数を決めて機械的に深掘りすることではない。最初の原因で説明できない症状が残っているなら、その原因はまだ仮説にすぎない。

たとえば「開封率が落ちた原因は件名が弱いから」と言われても、Gmail宛てだけ極端に落ちているなら、件名だけでは説明しきれない。その未説明の点を起点に、「なぜGmail宛てだけ落ちるのか」と一段深く掘る。

つまり、残差監査で続けるのは、抽象的な深掘りではなく「説明できていない症状を説明するための掘り下げ」だ。未説明が残っている限り原因を更新し、未説明が消えるか、残った点が対策を変えないレベルになるまで続ける。

止める条件を先に決めておく

深掘りは、放っておけばいくらでも続く。実務で使うには「どこでやめるか」を先に決めておく。目安はシンプルで、残った未説明が対策を変えないレベルになったら止める。たとえば「その要因が真だとしても、打つ手は同じ」なら、それ以上掘っても行動は変わらない。逆に、残差が対策を変えうるうちは掘る価値がある。この止め時を最初に宣言させておくと、無限ループにも早すぎる打ち切りにも倒れにくい。

症状は「事実」で書く ― 良い記述・悪い記述

この手順の精度は、最初に並べる症状の質でほぼ決まる。残差は「症状どうしの食い違い」から生まれるので、症状の記述が曖昧だと食い違いも見えず、AIは最初の原因で話を閉じてしまう。

良い症状の記述は、解釈ではなく観測された事実でできている。悪い記述と並べると差がはっきりする。

コツは「いつから・どこで・どのくらい・どんなときだけ」を数字とタイミングで押さえること。とりわけ「どんなときだけ起きるか（＝起きない条件）」は残差の手がかりになりやすい。正常なケースとの差分が、原因の在りかを指し示すからだ。逆に、症状が「調子が悪い」の一言だと、AIは差分を取りようがなく、一般論の原因で埋めて終わってしまう。

具体例：メルマガの開封率が急に落ちた

手順の効き目は、一つ例を通すと分かりやすい。以下は説明のための仮想例だが（数値も架空）、あるメルマガの開封率が、先月の約20%から今月は約12%へ急落したとする。これをAIに分析させる場面を考える。

一つの原因で止めた場合、返ってくるのはたいてい「件名の訴求力が弱かった」あたりだ。もっともらしいし、A/Bテストで件名を改善しよう、という手も自然に出てくる。ところがここで症状を全部並べ直すと、件名だけでは説明できない点が残る。

• 開封率の低下が、特定の受信ドメイン（たとえばGmail宛て）に極端に偏っている
• 一部の購読者に、配信直後ではなく数時間遅れて届いている
• 本文リンクのクリック率は、開封した人の中では例年並みを保っている

件名が弱いだけなら、ドメインで偏る理由も、配信の遅延も説明がつかない。この「未説明」を起点に「なぜGmail宛てだけ落ちるのか」を掘ると、送信元IPのレピュテーション低下によって迷惑メール判定を受け、受信トレイに表示されず開封もされにくくなっていた、という別の原因にたどり着く。件名は主因ではなかった。

ここで効いたのは、賢い一発の推論ではない。「件名だけでは説明できない症状が残っている」と気づかせ、そこを掘らせた手順だ。最初のもっともらしい説明で止めていたら、見当違いのA/Bテストに時間を使っていたことになる。

もう一つの例：AIに任せた作業が「ときどき」失敗する

この手順は集客の分析だけでなく、AIツール自体のトラブルにも効く。次も説明のための仮想例だが、資料の要約や問い合わせ返信を自動化する処理を組んだところ、十回に一回ほど失敗する、というケースを考える。

一つの原因で止めると、返ってくるのは「プロンプトの指示が曖昧だから」あたりだ。指示を丁寧に書き直す、という手に流れやすい。だが症状を並べ直すと、指示の曖昧さでは説明できない点が残る。

• 失敗するのは決まって入力が長いときで、短い入力ではまず失敗しない
• 失敗がリクエストの集中する時間帯に偏っている
• 失敗したときの出力は、途中で切れているか、空になっている

指示が曖昧なだけなら、入力の長さや時間帯で失敗率が変わる理由がない。この未説明を起点に掘ると、長い入力で出力のトークン上限に達して途中で切れる、混雑時間帯にはレート制限やタイムアウトで応答が返らない、という二つの別々の原因が見えてくる。プロンプトの文面は主因ではなく、対策も「指示を書き直す」ではなく、入力の分割とリトライ・タイムアウトの設計に変わる。

二つの例に共通するのは、最初のもっともらしい答え（件名／プロンプト）が症状の一部しか説明していなかった点だ。分野が変わっても効いているのは同じ一手──「その原因では説明しきれない症状はどれか」を突きつける手順である。

そのまま使えるプロンプト

この手順は、ChatGPTやClaudeなどにそのまま指示できる。原因を尋ねるときに、次のような枠組みを添えるだけでいい。

ポイントは、3番の「未説明の明示」を必ず要求すること。ここを省くと、モデルは最初の原因に合わせて説明を閉じてしまう。「説明できていない症状はどれか」を毎回言語化させることが、追い切りのスイッチになる。

追い切るときにやりがちな失敗

手順自体は単純だが、運用でつまずく箇所は決まっている。次の四つを避けるだけで、追い切りの精度は安定する。

• 症状を曖昧に書く ― 「反応が悪い」「うまくいかない」では、AIも切り分けようがない。数字・タイミング・偏りを添えるほど残差がくっきりする。
• 未説明を確認せず先へ進む ― 原因が一つ出た時点で満足すると、この手順の意味が消える。「この原因で説明しきれない症状はどれか」を毎回明示させるのが要になる。
• 最初の答えに引きずられる ― AIが挙げた原因を正しいものとして話を進めると、反証になる症状を見落とす。仮説はあくまで仮説として扱い、残差と突き合わせる。
• 止め時を決めずに掘り続ける ― 残差が対策を変えないレベルまで下がったら止める、という基準を先に置かないと、枝葉の要因を延々と掘って結論が出なくなる。

この手順が向く場面・向かない場面

万能ではない。効く条件と効きにくい条件を先に知っておくと、無駄打ちが減る。

向いているのは、症状が複数観測できて、しかもその一部が最初の原因では説明しきれない問題だ。数字・タイミング・偏りといった手がかりが多いほど残差がくっきりし、追い切りが働く。原因調査・障害対応・データ分析・自動化のトラブルは、たいていこの型に当てはまる。

逆に向かないのは、観測できる症状がそもそも乏しい問題や、原因が一つだと最初から分かっている単純な不具合だ。前者は残差を取りようがなく、後者はこの手順を挟むだけ手間が増える。また、答えに知識そのものが要る問い（専門的な事実確認など）は、追い切りの手順ではなく、正しい情報源に当たるほうが早い。残差監査が減らせるのは「早すぎる納得による取りこぼし」であって、知識の不足そのものではない。

よくある質問

Q. 「ステップバイステップで考えて」と付けるのと何が違いますか？

思考を分割させても、出力された説明が実際の判断根拠を忠実に反映するとは限りません（前掲Lanhamほか）。結果として、最初の答えを支える方向に説明が整って見えることがあります。効くのは思考の分割そのものより、「説明しきれない症状を明示させる」という反証のフックです。結論を支える方向だけに進まないよう、残差の確認を手順に埋め込むのが違いになります。

Q. 深掘りが止まらなくなりませんか？

止める条件を先に決めておけば防げます。「残った未説明が対策を変えないレベルになったら停止」という基準を最初に宣言させると、行動に影響しない枝を延々と掘る事態を避けられます。

Q. 症状が一つしか分からないときは使えますか？

使えますが、効き目は落ちます。この手順は複数の症状の食い違いから残差を見つける仕組みなので、観測できる事実（数値・タイミング・偏り）を集めるほど精度が上がります。症状が一つなら、まず「他にどんな観測があれば原因を絞れるか」をAIに挙げさせる使い方が向きます。

Q. ChatGPTでもClaudeでも同じように使えますか？

手順自体はモデルを選びません。ただ、モデルや世代によって「未説明を素直に挙げるか」「最初の答えに固執するか」の癖は変わります。うまく残差が出てこないときは、「説明できない症状を必ず一つ以上挙げること」と条件を明示的に強めると効きやすくなります。

Q. 残差がたくさん出て、どれから掘るか迷います。

対策を最も変えそうな残差から掘るのが基本です。「これが原因なら打つ手が根本から変わる」ものを優先し、「原因だとしても対応は同じ」ものは後回しにします。優先順位づけ自体も、判断基準を添えてAIに並べさせると速くなります。

Q. チームでの原因調査にも使えますか？

向いています。人による原因調査は、最初に声の大きい仮説へ全員が寄ってしまいがちですが、「未説明の症状を先に洗い出す」という共通の型を挟むと、思い込みで議論が閉じるのを防げます。AIには症状と残差の整理役を任せ、判断は人がする、という分担が現実的です。

「原因を聞く」のではなく「残差を出させる」

この手順――残差監査――の核を一語で言えば「残差」だ。AIに「原因は何か」と聞くと、最ももっともらしい答えが一つ返ってきて、そこで話が閉じる。だが「この原因で説明しきれない症状はどれか」と聞くと、閉じかけた思考がもう一度開く。前者は答えを一つに収束させる問いで、後者は収束を押し戻す問いだ。

この差は小さく見えて大きい。原因調査でAIを外すのは、たいてい「もっともらしい説明を早く受け入れすぎる」ことから起きる。残差を出させる一手は、その受け入れを一段だけ遅らせる。追い切りとは、賢さを足すことではなく、早すぎる納得を止めることに近い。

最後に

原因を追い切る残差監査は、根気の問題ではなく手順の問題だ。言語モデルは放っておけば一つの答えで閉じ、自力の見直しも当てにならない。だからこそ、症状を全部並べ、説明しきれない残差を明示させ、それが対策を変えなくなるまで掘る、という外側の枠を渡す。たったこれだけで、原因調査の外し方が目に見えて減る。

原因を一つで閉じない残差監査は、AIの外し方を減らす道具の入口にすぎない。答えの枠組みを疑う多角推論、候補を反証で削る仮説収束、資料の食い違いを裁く統合ループも、狙う崩れ方が違うだけで骨格は同じだ。四つをまとめて推論制御と呼ぶ。

参考資料

• Lanham, T. ほか「Measuring Faithfulness in Chain-of-Thought Reasoning」(2023, arXiv:2307.13702) ― 思考過程の記述が実際の判断根拠を忠実に反映するとは限らないことを示した研究
• Huang, J. ほか「Large Language Models Cannot Self-Correct Reasoning Yet」(ICLR 2024, arXiv:2310.01798) ― 外部の手がかりなしの自己修正は精度を下げうるとの報告

本記事はAIツール図鑑編集部が、記載時点の情報をもとに執筆しました。引用した研究・手法は各一次ソースを参照のこと。モデルの挙動は世代・設定により変わりうるため、手順は自分の環境で確かめたうえで用いることを推奨する。