AI駆動開発 2026年5月31日

LLMが「正しく考えた後に答えを覆す」のはなぜか——プロンプトでは解決できない6つの構造的理由

LLMが「正しく推論した後に答えを覆す」という現象

業務システムにLLMを組み込んでいると、ある種の奇妙な失敗に遭遇することがある。モデルがChain-of-Thoughtの中でルールを正確に適用し、正解を導き出す。そこまでは完璧だ。ところがその直後、「しかし、より詳細に検討すると」と書いて、自分が出した答えをひっくり返す。

Zennに公開された技術記事「LLMはなぜ正しく推論した後に答えを覆すのか」は、この現象を数ヶ月にわたって追いかけた著者が、論文ベースで6つのメカニズムに整理した内容だ。読んで率直に思ったのは、「これは現場で詰まっている人間が最終的に辿り着く問いを、きちんと言語化している」ということだった。

記事中に示された失敗例が象徴的なので、そのまま紹介する。文書分類タスクにおいて、モデルのthinkingはこう展開する。

Step 1: 「クリアランス」を含む
Step 2: R1に該当 → カテゴリA
Step 3: 最終判定 → カテゴリA
しかし、この文書の内容を詳細に検討すると……最終回答: カテゴリC

プロンプトには「ルールの結果は確定的であり、再解釈で覆してはならない」と明記されている。それでも覆す。

これはバグでも性能不足でもない

この種の問題に直面した開発者が最初にやることは、たいていプロンプトの修正だ。強調表現を足す、制約を繰り返す、「絶対に覆すな」と書く。確かに部分的には効く。でも根本的には直らない。モデルを変えると改善することもあるが、別の箇所で新たな問題が出る。

ここからが本記事の核心で、著者はこれを「プロンプトの良し悪しの問題ではなく、Transformerアーキテクチャに起因する構造的限界」と位置づけている。言い方を変えれば、これはモデルが「悪意を持って」指示を破っているのでも、能力が足りないのでもない。注意機構（Attention）の数学的な性質から必然的に起きることだ、という整理だ。

ここは重要なので少し立ち止まりたい。「構造的限界」という言葉は便利すぎて、何でも言い訳に使えてしまう側面がある。だが今回の話は、引用されている論文の実験結果と対応しており、単なる印象論ではない。

6つのメカニズムを読み解く

記事が整理した6つのメカニズムを順に見ていく。個々の論文名と数値を押さえておくと、「なるほど」から「だから自分のシステムでもこうなるのか」まで線がつながりやすい。

メカニズム1: 指示密度減衰

Qin et al. (2025) のIFScaleベンチマークによれば、10〜500個のキーワード制約を課す実験で、最も優れたフロンティアモデルでもN=500制約下では精度が約68%にとどまる。重要なのは低下パターンの違いで、推論特化モデルは約150〜200制約まで高精度を保った後に急崩壊する「閾値型」、汎用モデルは制約数に比例して線形に低下する。制約は「足せば足すほど良い」のではなく、密度の管理が必要だということだ。

メカニズム2: 文脈の中間部における情報損失

Liu et al. (2024) の「Lost in the Middle」が実証した現象で、関連情報がプロンプトの先頭または末尾にある場合にパフォーマンスが最高となり、中間部では著しく低下するU字型のカーブを描く。Transformerの因果マスキングと残差接続の相互作用で、初期トークンがアンカーとして機能する（Attention Sinks）ため、中間のルールは物理的に見落とされやすい。

メカニズム3: 注意力の希釈

Softmax関数による正規化の性質上、注意の重みの総和は常に1だ。制約数Nが増えると、個々のトークンへの注意は数学的に1/Nへと減少する。「モデルが意図的に無視している」のではなく、物理的に強い注意を向けられなくなる。さらに複数の制約が競合する「命令の干渉（Instruction Interference）」が隠れ状態で発生する。

メカニズム4: 推論のパラドックス

Wen et al. (2025) の「When Thinking Fails」が示した、直感に反する知見だ。明示的なChain-of-Thought推論が指示遵守の精度を下げる場合がある。複雑な論理を解くための推論能力と、ルールに厳密に従うためのコンプライアンス能力が、内部表現においてアテンションリソースを奪い合う。「もっと深く考えさせれば正確になる」は必ずしも正しくない。

メカニズム5: 構造化出力の代償

Tam et al. (2024) の「Let Me Speak Freely?」によれば、JSONスキーマ等の厳密なフォーマットを強制すると、モデルが本来生成しようとする自然言語のパターンがブロックされ、確率分布が歪む。この歪みが思考の連続性を断ち切り、推論精度を下げる。

メカニズム6: 自然言語空間での推論優位性

Hager et al. (2025) の実験では、JSONスキーマによるツール呼び出しから自然言語によるツール選択に切り替えることで、精度が69.1%から87.5%へ向上し、出力の分散が70%減少した。推論フェーズと構造化フェーズを分離する設計が有効だという話だ。

「合理的に見える設計」が最悪の組み合わせになる

ここが記事で最も刺さる指摘だと思う。

著者はこの6つが「独立した問題ではなく、相互に強化し合う」と述べている。そして「プロンプトに制約を追加して、深く考えさせて、構造化出力で返させる」という設計が、6つのメカニズムすべてを同時に悪化させる最悪の組み合わせになりうると断じている。

開発者がやりがちな「より良くしようとした結果」の組み合わせが、まとめて裏目に出るということだ。

ここからは見方になるが、これはLLMの活用において「設計者の勘」が通用しにくいという話でもある。人間が「念のため詳しく考えさせよう」「より明確に制約しよう」「出力を機械可読にしよう」と積み重ねた工夫が、モデルの内部では相互干渉を引き起こしている。直感と挙動が逆向きになる領域では、仮説→実験→計測のサイクルなしに設計を改善するのは難しい。

実際に著者が観察した失敗パターンも3つ示されている。ドメイン知識による覆し（ルール上の正解とモデルの事前学習知識が矛盾すると後者が勝つ）、優先順位ルールの無視（全ルールを並列評価して「最も関連性が高い」と判断したものを選ぶ）、否定条件の見落とし（「AかつBでない」の否定条件が肯定条件より注意を引きにくい）。どれも「言われてみると確かに見たことがある」という種類の失敗だ。

実務的な示唆と今後の論点

記事が示す対策の方向性を整理すると、「制約を減らす・分割する」「重要な制約は先頭か末尾に置く」「推論フェーズと構造化フェーズを分離する」「コード側でバリデーションを持つ」といったことになる。

実務的な観点で補足すると、これらは「LLMをブラックボックスとして扱うのをやめる」という設計思想の転換と読める。LLMの出力を最終出力として信頼するのではなく、「推論はモデルに任せ、判定はコードで行う」という役割分担が現実的だということだ。

判断軸として持っておきたいのは、「この問題はプロンプトで解くべき問題か、それとも設計で解くべき問題か」という問いだ。制約が多い、推論が長い、出力が構造化されている——この3つが重なるタスクは、プロンプトの改善で対処しようとするとコストが跳ね上がり続ける。先にシステム設計を見直すほうが合理的なことが多い。

次の論点として気になるのは、後編で予告されているDeCRIMパイプラインや後処理バリデーションの具体像だ。「推論と構造化を分離する」はわかるが、それを実装レベルでどう組むか、どれだけ汎用的に使えるかは別の問いになる。複数のLLM呼び出しにまたがるシステムのコストとレイテンシへの影響も、実運用では無視できない。後編の内容を見てから改めて整理したい。