解けない推論は分解しても反転しても並列にしても解けない

この記事は2026年10月時点の前提で書いています。LLMが外部のデータへ自力で接続し、フィードバックを集められる範囲が広がれば、人間に返す判断の範囲も変わります。

先に結論だけ

フィードバックループ（答えが合っていたかを、プログラムや実データ、人間の反応など外部から受け取る経路）に接続できない推論は、解けたかどうかを評価できません。

LLMのワークフローで推論処理を組み替える3つの操作は、どれもこの評価できないという課題を解決しません。

• 推論を分解すると、評価できる部分は切り出せます。評価できない部分は残ります
• 推論を反転しても（「良いものを作れ」を「劣化したものを作れ」に変えても）、必要な能力は同じで、実施できません
• 並列に実行して多数決をとっても、答えはモデルの偏りに従うだけで、解けたかどうかは評価できないままです

分解して残った部分の扱い方は2つです。フィードバックループに接続するか、その問題のフィードバックループに接続している人間に判断を返します。

はじめに

LLMに判定を任せるワークフローを、別々の目的でいくつか作ってきました。判定役を分けたり、役割を入れ替えたり、と構成を足していったのですが、どのワークフローでも「結局ここは誰が判定するの？」という部分が残り続けました。

この記事では、その残り続けた部分が何だったのかを整理します。扱うのは個別のワークフローではなく、評価できる推論と評価できない推論の見分け方です。

対象読者はLLMを組み込んだワークフロー・スキル・エージェントを設計している方です。学術的な厳密さはありません。ワークフローを組み立てるときの経験則としてまとめます。

以前の記事「判断基準を推論ブロックの構成で渡す」では、推論を分割するとブレが小さくなる話を書きました。この記事は同じ分割を別の面から見て、分割しても評価できるようにはならない部分を扱います。

評価できない推論は解けたかどうかが分からない

この記事でいう評価できない推論は、フィードバックループに接続できない推論です。LLMが正しい答えを出せない推論、という意味ではありません。

LLMは一発の回答で正解を出すことがよくあります。困るのはその後で、合っていたかを確かめる手段がないと、正解と不正解を見分けられません。見分けられなければ、直すことも、次に生かすこともできません。

抽出はできても良し悪しは判定できない

私の作業での例を挙げます。LLMとの長い議論が健全に進んだのか、ドリフトを起こしていないのかを、後から点検したいと考えました。点検の材料として、議論をLLMに読ませ、決まった項目の表へまとめさせました。

• 議論を表にまとめること（抽出）はできました
• 表の引用が元の議論に実在するかは、文字列の照合で機械的に判定できました
• 表が示す議論は健全か、という判定はできませんでした

2つ目と3つ目の違いは照合先があるかどうかです。引用の実在は元の議論と突き合わせれば決まります。議論の健全さには突き合わせる相手がありません。照合先がないので、この判定はLLMに任せず、人間の私へ返すことにしました。

人間とLLMの違いは接続

「人間ははじめての問題でも判断できるじゃないか」と思うかもしれません。

人間が未知の問題に判断を下せるように見えるのは、評価のループを回せるからでしょう。問題に対処し、結果を受け取り、仮説を組み直し、また結果を受け取ります。人間は外部の環境と常に接続していて、まったく接続していない人間はそもそも存在しません。

LLMは、環境と接続しない状況を作れてしまいます。ツールもデータも渡されず、プロンプトだけを受け取って判定を返す、という状況です。判断の基準は人間もLLMも同じで、違うのは接続しているかどうかだと私は考えています。

正誤の判定に外部の判定器が要るという先行研究

正誤の判定に外部の基準が要る、という問題は、ソフトウェアテストの分野で名前が付いています。テストオラクル問題（test oracle problem）です。Barrらの論文は、ある入力に対するシステムの正しい挙動と、誤っているかもしれない挙動を区別する難しさを、この名前で呼んでいます¹。同じ論文は、自動の判定器で足りない場合、最後に判定のよりどころになるのは人間だと述べています。

LLMの自己訂正についても、近い方向の報告があります。

• Huangらは推論の課題で、外部のフィードバックなしではLLMが自分の回答をうまく訂正できず、訂正後に性能が下がる場合もあると報告しています²
• Kamoiらは先行研究を調べ、LLM自身にプロンプトで出させたフィードバックについて、特別に向いた課題を除けば、自己訂正がうまくいった例はないと整理しています。信頼できる外部フィードバックを使える課題と、大規模なファインチューニングをした場合には自己訂正が機能するとも述べています³
• Kambhampatiらは、自己回帰型のLLMは単独では計画も自己検証もできないという立場をとり、外部の検証器と組み合わせる枠組みを提案しています。こちらは実験の報告ではなく、立場を述べる論文です⁴

どれも課題や条件を限った報告で、「LLMは自己評価が一切できない」と述べているわけではありません。この記事では「外部のフィードバックがない自己評価は、合っているかを確かめられない」という範囲で話を進めます。

分解しても評価できない部分は残る

分解には2つの役があります。

• ⭕️ 評価できる部分を切り出す手段になる
• ❌ 評価できない部分を解く手段にはならない

先ほどの表の例でいえば、「引用が実在するか」は分解で切り出せた部分です。切り出した後に「議論は健全か」が残りました。これをさらに「前提は妥当か」「結論は前提から導けるか」と分けても、それぞれの問いに照合先がなければ、評価できない問いの数が増えるだけです。

成功の要因は分解ではなく外部の正解データ

私がここでつまずいたのは、過去の成功体験の読み違えでした。

以前、問題を小さく分けて処理する手法がうまくいったことがあります。その手法は、正解データを外部に持っていました。分けた各部分の出力を、正解データと突き合わせられたのです。私はこの成功を「分解したからうまくいった」と理解し、正解データのない問題にも同じ分解を当てはめました。うまくいったのは分解のおかげではなく、突き合わせる相手があったからでした。

ブレが減っても正しくなったとは限らない

分割するとブレは小さくなります。これは以前の記事で扱ったとおりです。

ただ、外部の判定器がない判断を分割した場合、減るのはブレだけです。答えがそろうようになっても、そろった先が合っているとは限りません。同じ間違いを繰り返すこともあります。再現性が上がったことを、評価できるようになった証拠と読み違えないようにしましょう。

反転しても必要な能力は同じ

「良いものを作れ」が評価できないなら、逆向きにすれば評価できるのでは、と考えたくなります。たとえば次のような構成です。

• 判定役を、「劣化した版を作る役」と「元の版と劣化版を比べる役」に分ける
• 成果物の欠点を探す役（レッドチーム）を置き、欠点が見つからなければ合格とする

どちらも、実施できない仕事を別の役へ移しただけでした。

1つ目の構成は「必ず劣化した版を作れる」ことを前提にしています。ある版が元より劣化していると言い切るには、良し悪しを判定する力が要ります。つまり前提に置いた力は、作ろうとしていた評価の力と同じでした。「良いものを作れ」と「劣化したものを作れ」は同じ種類の命令で、必要な能力も同じです。片方が実施できないなら、もう片方も実施できません。

2つ目の構成も同じです。見つかった欠点が本当に欠点なのか、欠点が見つからなかったのは欠点がないからなのかを、誰かが判定しなければなりません。欠点を欠点と判定する方法が決まっていなければ、欠点は見つけられません。これも外部の判定器の問題で、判定器のない欠点探しは機能しません。

プログラミングの課題では、判定器を渡さなくてもレッドチームが欠点を見つけてきます。モデルが事前学習で膨大な数の事例を学習していて、その事例が判定器の代わりをしているからだと私は考えています。学習した事例が少ない種類の問いでは、この代わりは働きません。

並列にして多数決をとっても答えは偏りに従う

同じ問いを複数のインスタンスに渡して多数決をとっても、解けたかどうかは評価できないままです。

多数決が正しさに近づくのは、それぞれの誤りがバラバラの方向を向いている場合です。同じモデルの複製は同じ重みを共有しているので、同じ方向へ外れやすいはずです。その場合、多数決はばらつきを減らしますが、偏りは減らしません。得られるのは「このモデルが出しやすい答え」です。

これは文献で確かめた結果ではなく、私の推論です。また、各インスタンスが外部の判定器や実データに触れているなら話は別で、それはフィードバックループに接続した構成です。

残った部分の扱い方

評価できる部分を切り出したら、残った部分の扱い方は2つです。

フィードバックループに接続する

残った問いに照合先を用意できるなら、接続します。

• プログラムによる判定（テスト、型検査、文字列の照合）
• 外部のデータとの突き合わせ（正解データ、一次資料、計測値）
• 実際に動かした結果の観測

そのループに接続している人間に返す

照合先を用意できない問いは、人間に返します。返す相手は、その問題のフィードバックループに接続している人間です。

まとめ

• フィードバックループに接続できない推論は、解けたかどうかを評価できません
• 分解は評価できる部分を切り出せますが、残った部分は評価できないままです
• 反転しても必要な能力は同じで、実施できません
• 並列にして多数決をとっても、答えはモデルの偏りに従うだけです
• 残った部分は、フィードバックループに接続するか、そのループに接続している人間に返します

ワークフローを組むときは、構成を足す前に「この判定は何と照合しているのか」を確かめてみてください。

1. Barr et al., "The Oracle Problem in Software Testing: A Survey"。掲載誌はIEEE Transactions on Software Engineering, 41(5), 2015。2026年10月に要旨を確認。https://discovery.ucl.ac.uk/id/eprint/1471263/ ↩

2. Huang et al., "Large Language Models Cannot Self-Correct Reasoning Yet", ICLR 2024. 2026年10月に要旨を確認。https://arxiv.org/abs/2310.01798 ↩

3. Kamoi et al., "When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs", TACL 2024. 2026年10月に要旨を確認。https://arxiv.org/abs/2406.01297 ↩

4. Kambhampati et al., "Position: LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks", ICML 2024. 2026年10月に要旨を確認。https://arxiv.org/abs/2402.01817 ↩