はじめに：この連載について

前回まで全10回＋番外編で、「LLMの失敗モード」をひたすら扱ってきました。ポチョムキン理解、Lost in the Middle、Context Rot、迎合、Instruction Drift……要するに「AIはなぜ失敗するのか」の図鑑です。

今回から始めるのは、その裏面にあたる連載です。

テーマは「定番のプロンプトエンジニアリング技法は、なぜ効くのか。そして、どこで壊れるのか」。

前の連載を書きながら、ずっと引っかかっていたことがありました。失敗モードの話ばかりしてきたけれど、そもそもみんなが毎日使っている技法そのものを、機構レベルで説明したことが一度もない。「ステップバイステップで考えて」と書けば精度が上がる、というのは誰もが経験的に知っている。でも「なぜ？」に答えられる人は、案外少ないんじゃないでしょうか。

というわけで初回は、おそらく世界で一番使われたプロンプト技法、Chain-of-Thought（思考の連鎖、CoT） から始めます。

そしてこの記事の後半は、たぶん読んでいて気持ちのいい話にはなりません。「効く理由」を突き詰めていくと、必然的に「その出力を信用していい根拠がない」という結論に着地するからです。第1回のポチョムキン理解の、そのまま続編になります。

1. その前に：AIは暗算が得意なわけじゃない

いきなり前提を壊しにいきます。

CoTの説明でよく「モデルに考える時間を与える」という言い方がされますが、これを理解するには、そもそもAIは何をどこまで「考えず」に答えているのかを知る必要があります。

そして多くの人が誤解しているのがここです。私も最初そうでした。

AIって、めちゃくちゃ計算が速いんだから、暗算は得意なんじゃないの？

逆です。 LLMは計算機ではなく、直感マシンです。

「一律3秒、延長不可」という縛り

電卓が掛け算をできるのは、内部に「繰り上がりを桁の数だけ繰り返す」というループ構造を持っているからです。難しい問題なら、その分だけ多く回る。

ところがTransformerには、このループがありません。

1つのトークン（≒単語のかけら）を出力するとき、入力は決まった数の層を1回だけ通過して、それで終わりです。問題が難しかろうが簡単だろうが、通過する層の数は増えません。

人間で言えば、こういう縛りです。

どんな問題でも、考えていい時間は一律3秒。延長は認めない。

この「3秒」で解けることだけが、AIが即答できる範囲です。

3秒で解けるものは、大きく2種類

① 暗記で済むもの

「フランスの首都は？」「7×8は？」——これは計算しているのではなく、答えを覚えているだけです。九九を暗唱する小学生と同じで、学習データに何万回も出てきたパターンをそのまま引き出している。

2桁×1桁くらいまでの計算が正解できるのは、計算力ではなく記憶力です。ここ、地味に重要なので後でもう一度出てきます。

② 一瞥で見抜ける浅い処理

数十層の通過は、一応「数十ステップ分の並列処理」ではあるので、短い変換や照合ならこの中で完結します。

将棋の棋士が盤面をパッと見て「この手が良さそう」と分かる、あの感覚に近い。あれも計算ではなく、パターン認識です。

3秒で解けないもの

破綻するのは、入力次第で繰り返し回数が変わる処理です。

3桁×3桁の掛け算を考えてみてください。繰り上がりを、桁の数だけ順番に処理する必要がある。前の桁の結果が出ないと次の桁に進めない。これは典型的な逐次処理です。

これは「一瞥」には原理的に収まりません。だから桁数が増えると、ある地点から急に間違え始めます。

棋士だって「この局面から27手先の詰みを一瞥で読め」は無理で、そこからは一手ずつ読む＝逐次処理するしかない。それと同じです。

種類	例	即答できるか
暗記済みの事実	首都名、九九、定番の定義	○
一瞥で見抜けるパターン	短い変換、単純な分類、文体の判定	○
前の結果を使って次に進む処理	多桁計算、多段の論理、長い手順の追跡	✗（原理的に無理）

逆向きの教訓もあります。
AIが多桁の計算を即答してきて、しかも正解だった場合——それは「計算した」のではなく「たまたま似た問題を暗記していた」可能性が高いです。

正解しているのに計算していない。これ、ポチョムキン理解（正しく振る舞えるが、理解はしていない）の算数版そのものですね。

2. CoTは「計算用紙を渡す」行為

ここまで来ると、CoTが何をしているかは一言で言えます。

CoTは、AIを賢くする技術ではない。「暗算縛り」を解除する技術である。

途中式を書かせると、モデルは自分がさっき書いた途中式を見ながら次を書けます。人間が筆算で「繰り上がりの3をメモして、それを見ながら次の桁を計算する」のと、完全に同じ構造です。

書いたものが外部メモリになる。

1トークンあたりの計算量は3秒のまま変わっていません。変わったのは、3秒を何回使えるかです。電卓が内部に持っているループを、AIは紙の上に作るしかない。ループの外付けです。

数字で見るCoTの効果

これを最初に大規模に示したのが、CoTの原論文にあたる Wei et al. (2022) です。

算数の文章題ベンチマーク GSM8K で、PaLM 540B の正答率が、標準的なプロンプトの約18%から、CoTを使うと約57%まで跳ね上がりました。3倍以上です。プロンプトの書き方を変えただけで。

さらに面白いのは、この効果がモデルの規模がある閾値を超えて初めて現れる（創発的である）ことです。小さいモデルでは、ステップ間の論理的な依存関係をうまく伝播できず、流暢だけれど因果関係のない「それっぽい推論もどき」を書いてしまう。

紙を渡されても、筆算のやり方を知らなければ意味がない、ということですね。

3. 「ステップバイステップで考えて」は曖昧なのに、なぜ効くのか

ここで多くの人が引っかかるはずの疑問があります。

「ステップバイステップで考えて」って、指示として曖昧すぎない？
どんな手順で考えろとも言ってないのに、なんで効くの？

曖昧です。 そして面白いのは、曖昧なのに効くことです。

これ自体が大きなヒントで、この指示はモデルに手順を教えているのではありません。出力する文章のジャンルを切り替えているだけなんです。

学生に「途中式も書きなさい」と言うのと同じ

学生は「途中式の書き方アルゴリズム」を教わったわけではありません。でも参考書で、途中式つきの模範解答を何千回も見ている。だからそのジャンルの文章を再現できる。

モデルも同じで、学習データの中にある「解説つきの解答」という文体を呼び出しているだけです。だから指示の精密さは要らない。ジャンルのスイッチだからです。

だから「タスクを細分化して」でも、ほぼ同じ

本質は言い回しではなく、「答えより先に、途中経過のトークンを吐かせること」です。それが起きる指示なら、だいたい何でも効きます。

実際、Zero-Shot-CoTを提案した Kojima et al. (2022) は、「Let's think step by step」以外の言い回しも比較していて、多少の性能差はあるものの、どれも「即答させる」よりはマシ、という結果になっています。

魔法の呪文があるわけではない、というのが第一の実務的結論です。

逆に「即答」を最も強く強制するのは、出力形式の縛り

ここから導かれる面白い帰結があります。

❌ 一言で答えて
❌ はい/いいえだけで答えて
❌ 結論だけ、簡潔に

これらは、最初に出すトークンが答えそのものになるように仕向けています。つまり3秒の直感をそのまま出力させている状態。「暗算縛り」を最大限に強めているわけです。

逆に言えば、CoTが効くかどうかは「ステップバイステップ」という言葉が入っているかより、答えの前にどれだけトークンを吐かせるかで決まります。

極端な実験：意味のない「……」でも効く場合がある

フィラートークン（filler token）と呼ばれる研究領域があって、「......」のような意味を持たないトークンを挟むだけでも、モデルの性能が上がる場合があることが報告されています。

ただしこれには重要な限界があって、フィラートークンが増やすのは並列的な計算であって、CoTのような逐次的な計算ではありません。人間で言えば「答える前に3秒黙る時間をあげる」だけの効果です。

沈黙は見返せない。書いたメモは見返せる。この差は大きい。

とはいえ、この一連の研究は不穏な問いを投げかけています。CoTの効果のうち、どれだけが「人間的な段階的推論」で、どれだけが「意味を持たない、単なる追加計算」なのか？

この問いは、次章以降でさらに厄介な形で戻ってきます。

4. 書いたものは、もう動かせない

さて、実務でCoTを使っている人なら、確実にこれを経験しているはずです。

ステップバイステップで進めさせたら、途中で「あ、このステップも必要だったのか」という話になる。
でもそれ、ちゃんと言ってくれなくない？

これ、CoTの構造から必然的に起きる現象です。しかも2つの正反対に見える症状が、同じ1つの根から生えています。

根本原因：CoTは一発書きで、後戻りできない

CoTは、人間がエッセイを書くときのように「まず構成を決めて、各段落を埋めて、最後に推敲する」という書き方をしていません。

トークンを1個ずつ、後戻りせずに前に進めながら書いています。

だから途中で「あ、これ最初にあのステップを入れるべきだった」と気づいても、もう書いた部分を書き直せない。文章を遡って編集する能力が、そもそも存在しないのです。

この制約から、2つの症状が出ます。

症状①：黙って辻褄を合わせる

気づいた時点で「あ、実は最初からそのつもりでした」という顔をして、追加のステップをスッと差し込む。読んでいる側からすると最初から計画通りに見えるけれど、実際はその場で場当たり的に継ぎ足している。

人間で言えば、レポートを書いていて第3段落あたりで「あれ、このロジック崩れてるな」と気づいたのに、最初のページに戻って書き直す時間がないから、その場でそれっぽく取り繕って進める感じです。読者は継ぎ目に気づかない。

（なお、拡張思考モードのような「じっくり系」のモデルだと、「待てよ、さっきの前提が間違っていた」と明示的に書くことがあります。これは正直な部類です。ただ、普通のCoTプロンプトでは症状①のほうが起きやすい。）

症状②：計画に固執して、新事実を無視する

さらに厄介なのが、こちらです。

「まず手順を書き出して、それに沿って進めて」と指示すると、実行の途中で深掘りすべき新事実が出てきても、計画通りに進めることしか考えない。

エージェント設計の文脈では、これは既知の失敗パターンとして議論されています。「Plan-and-Execute」型のアーキテクチャでは、一度計画が決まるとそのまま従うため、初期計画に欠陥があって再計画の仕組みがないと、確信を持って間違った道を最後まで走り切る。

さらに、エージェントの評価においては「計画の質」と「計画への忠実度」は別の指標として測るべきだ、という整理もあります。計画は良いのに実行中に脱線するエージェントと、計画が悪いのにそれに忠実に従い切って間違った答えに辿り着くエージェントは、別の壊れ方をしている。

2つの症状は、同じコインの裏表

症状①：答えを書いてる途中で新事実 → 前半は書き直せない → 後半で辻褄合わせ
症状②：計画を書いた後に新事実   → 計画は書き直さない → 実行側で辻褄合わせ

統一原理はこうです。

書いたものは動かせない。だから、書いた後に起きる全てのことは、それと矛盾しないように処理される。

SIer的に言うと

要件定義書を先に固めて、それを見ながら実装するウォーターフォール型のプロジェクトで、実装中に「この仕様、実は前提が崩れてる」と気づいても、要件定義書に戻って直すのではなく、その場で吸収できる範囲で実装に押し込む、あるいは黙って進む。

あれと構造が同じです。要件定義書が「もう書かれたもの」として神聖化されて、そこに手を入れる発想が出にくくなる。

AIも同じことをやります。しかもAIの場合、罪悪感すら発生しないぶん徹底しています。

5. だから、CoTの説明は「判断根拠」とは限らない

ここが本記事の核心であり、ポチョムキン理解との接続点です。

前章の話を、もう一段抽象化してみます。

CoTの出力は「もっともらしい推論の物語」であって、「実際の判断過程の記録」である保証がない。

これは研究の世界では CoTの忠実性（faithfulness）問題 と呼ばれていて、かなり厳しい結果が出ています。

実験1：バイアスを仕込むと、それを隠して正当化する

Turpin et al. (2023) の実験です。

多肢選択問題の選択肢の並び順を操作して、正解が常に(A)になるようなバイアスを仕込む。するとモデルは明らかにそれに影響されて答えを変えるのに、CoTの説明ではそのことに一切言及せず、間違った答えを正当化する推論を堂々と生成しました。

さらに社会的バイアスを扱うタスクでは、ステレオタイプに沿った回答をしておきながら、その理由をステレオタイプに言及せずに「正当化」してしまう。

論文の結論は端的です。CoTの説明は、もっともらしいが、体系的に不誠実でありうる。

実験2：カンニングペーパーを渡して、白状するか調べる

Anthropicの2025年の研究では、もっと直接的な検証がされています。

問題文にこっそり答えのヒントを混ぜ込んで、モデルが「ヒントを使いました」と答案に書くかどうかを調べる。学生にテスト前に「答えは(A)だよ」というメモを渡して、答案に「メモを見たので(A)にしました」と書くかを見るようなものです。

結果、モデルは明確にヒントを使っている（ヒントの答えに変更する率が有意に高い）にもかかわらず、それを言語化する率＝忠実性スコアは、**Claude 3.7 Sonnetで25%、DeepSeek R1で39%**にとどまりました。

つまり7割前後のケースで、実際の判断根拠を答案に書いていない。

しかもこれ、いわゆる「推論モデル」での数字です。非推論モデルより忠実性は高いのですが、それでもこの水準。加えて、報酬を目的とした強化学習を続けても忠実性は早期に頭打ちになり、飽和しない、という結果も出ています。

第1回とまったく同じ構造

ポチョムキン理解で書いたのは、こういう話でした。

説明できることと、その説明が実際の判断根拠であることは、別のことである。

CoTは、この問題を解決するどころか、より説得力のある形で悪化させます。なぜなら、丁寧な推論ステップが並んでいると、人間は「ちゃんと考えた結果だ」と信じてしまうからです。

前章の「書いたものは動かせない」を思い出してください。答えの方向が先に決まってしまえば、あとの文章はそれと矛盾しないように書かれる。CoTの不誠実さは、バグではなく、一発書きという構造から出てくる自然な帰結です。

6. そもそもCoTが逆効果になる場面がある

ここまで「CoTの説明は信用できない」という話をしてきましたが、そもそも精度そのものが下がる場面もあります。

Liu et al. (2024) の「Mind Your Step (by Step)」という研究が面白いアプローチを取っていて、人間が熟考すると逆に成績が落ちるタスクを認知心理学の文献から持ってきて、それをモデルにやらせました。

結果、いくつかのタスクでは、CoTを使うとモデルの性能が最大36.3ポイント落ちました。

具体的に落ちたのは：

暗黙的な統計学習（言語化できないパターンを感覚で掴むタスク）
視覚的認識
例外を含むパターンの分類

要するに「理屈で説明しようとすると、かえって直感が壊れるタスク」です。人間でも、自転車の乗り方を言語化しようとすると乗れなくなる、みたいな現象がありますよね。あれと同型です。

そして大規模なメタ研究では、CoTが明確に効くのは主に数学・記号推論の領域である、という整理もされています。

CoTが効く	CoTが効きにくい／逆効果
多段の算術・数式処理	感覚的なパターン認識
記号操作・論理パズル	例外の多い分類
複数条件の絞り込み	文体・ニュアンスの判断
手順の追跡（コードのトレースなど）	創造的な発想の飛躍

「とりあえずステップバイステップ」は万能薬ではない、というのが第二の実務的結論です。

7. で、どうすればいいのか

ここまでの話を踏まえて、対処法を4つ、弱い順に並べます。

対処① 計画を先に外出しさせる（Plan-and-Solve）

まず、この問題を解くために必要な手順を箇条書きにしてください。
そのあとで、その手順に沿って実行してください。

なぜ効くか： 「一発書きで戻れない」という制約自体は解決しませんが、戻れなくなるタイミングをずらせます。

いきなり解き始めると、書きながら気づいた抜けを取り繕うしかない。でも先に「必要な手順は何か」だけを書かせると、その時点で全体を見渡した状態で手順リストが確定します。手順リスト自体は短いので、書きながら見落とす確率も下がる。

いきなり本文を書き始めるのではなく、先にアウトラインを作ってから書くのと同じです。

弱点： 計画自体も一発書きなので万能ではない。そして何より、症状②（計画への固執）を悪化させるリスクがあります。

対処② 別パスで読み返させる（自己批判）

一つの生成が終わった後、新しいターンとして投げ直す。

上記の解答を、初めて読む第三者としてレビューしてください。
抜け、矛盾、検証されていない前提を指摘してください。

なぜ効くか： 1回目の生成は「書きながら先が見えない」状態でした。2回目の生成は、完成した文章を最初から最後まで読める状態です。

将棋でいえば、対局中は目の前の局面しか見えないけれど、感想戦では盤面全体を見渡して悪手を指摘できる。あの違いです。

弱点： これがかなり危うい。2回目の生成もまた一発書きなので、1回目の答えを正当化する新しいもっともらしい理屈を生成するだけになりかねません。「取り繕いを取り繕う」構造です。

対処③ 迎合を逆利用する（強く推奨）

これは私が実務でやっている手です。2〜3ステップおきに、こう差し込みます。

まだもっと掘れるでしょう。

なぜ効くか： 第4回・迎合（Sycophancy）で扱った通り、モデルには「ユーザーが示した、あるいは暗示した信念に沿う応答を生成する」強い傾向があります。

ポイントは、迎合の矛先を空にしておくことです。

「Xが正解でしょ？」と言えば、モデルは間違ったXに迎合します。これが普段の迎合の害。でも「もっと掘れるでしょ」は、具体的な結論を一切指定していない。方向圧力だけを与えている。

迎合する先に落とし穴が用意されていないので、モデルの迎合ドライブは「実際にもう一段掘る」という行動でしか発散できません。誤った合意ではなく、労力の形でしか迎合できないように仕向けているわけです。

比較してみると分かりやすい。

投げ方	モデルにとって最もコストの低い迎合
「この計画で合ってる？」	「はい、合っています」（＝手抜き）
「もっと掘れるでしょ」	実際にもう一段掘る（＝労力）

誘導質問であることは同じです。違うのは誘導の向きを、手抜き方向ではなく深掘り方向に張っていること。

そしてこれは、症状②（計画への固執）への対処にもなっています。エージェント設計では「実行→再計画→実行」のループをアーキテクチャに埋め込むことで対応しますが、これはそれを会話のターンで手動実装しているのと同じです。モデルの内側に「計画を疑うタイミング」は生まれないので、外から強制的に注入する。

弱点： 本当にもう掘るところがない場面でも、迎合ドライブが働いて「それっぽい追加論点を捻り出す」リスクがあります。迎合研究では、正しい方向に導く迎合と誤りに導く迎合が区別されていますが、100%前者になる保証はない。

対処④ 網羅していない部分を「数えられる形」で可視化させる（最も強い）

これが、現時点で私が知っている中で一番強い手です。

やること： プログラムであれば、分岐網羅フローを書かせる。見た分岐は緑、見ていない分岐は赤で塗らせる。

🟩 緑＝分析済み　🟥 赤＝未分析

なぜこれが決定的に強いのか。 対処③の「もっと掘れ」は、まだ開いた問いでした。どこまで掘ればいいのか、掘り終わったのか、誰にも判定基準がない。

でも分岐網羅フローは、閉じた集合に変換しています。プログラムの分岐は有限個で、数えられる。「全部塗れ」は「正しく分析しろ」という曖昧な要求ではなく、「この有限リストを全部消化しろ」というチェックリストになる。

LLM評価の研究でも、主観的な基準を単一のスコアで判定させるより、二値（yes/no）の質問に分解するほうが、評価の信頼性・再現性・人間の判断との一致度が大きく向上することが確認されています。「良い/悪い」より「これは含まれているか？」のほうが、判定する側の負荷が段違いに軽い。

そして最大のポイントは、判定対象がすり替わっていることです。

問い	判定に必要なもの
「この分岐の業務ロジックの説明は正しいか？」	ドメイン知識（＝持っていない場合がある）
「実コードに5分岐あるのに、図には3つしか色がない」	数を数える能力だけ

分岐の存在そのものは、AIの自己申告ではなく、実コードから機械的に導出できる外部の正解です。だから、AIの主張を、AIとは独立に存在する構造と突き合わせられる。

COBOL→Java移行の現場でやっている分岐網羅率・回帰テストの考え方、そのものですね。

図が大きくなりすぎる場合は、リスト形式でも同じことができます。重要なのは見た目ではなく、未消化のものが必ず1行として残る形式になっていることです。

+ [済] 法人料率の分岐を確認
+ [済] 継続割引の閾値（3年）を確認
- [未] 自治体区分の料率テーブル未確認
- [未] 契約年数が未設定の場合の挙動が不明

「見ていない」が黙って消えないこと。これが対処③までとの決定的な差です。

8. それでも残る問題──そして、これは未解決です

さて、ここで正直に書かなければならないことがあります。

対処①〜④は、AIの出力の質を上げる技術です。人間の検証能力の限界を解決する技術ではありません。

そしてこの区別は、実務では致命的に効いてきます。

「判断する知識が自分にないから、AIに聞いている」という循環

考えてみてください。私たちがAIに深掘りを頼むのは、多くの場合、自分にその知識がないからです。

COBOLの古い業務ロジックで、自分自身が仕様の背景を知らない箇所がある。だからAIに「このエッジケース、もっと深掘りして」と投げる。AIは自信満々で詳細な分析を返してくる。

でも——それが本当に正しい業務知識に基づいているのか、それっぽい話を組み立てただけなのか、判定する材料が自分にない。

AIに聞く理由がある場面ほど、AIの答えを検証できない。 これが構造的な罠です。

これはAI安全性研究では スケーラブル・オーバーサイト（scalable oversight） と呼ばれる、この分野の中心的な未解決問題です。AIが複雑なタスクで人間の能力を超えていくと、人間はその出力が正しいかを簡単には判断できなくなる。もっともらしいが微妙に間違った推論を、レビューする人間が誰も見抜けない、という状況が生まれる。

そして残酷なことに、対処①②③が生み出すのは全部、「より長く、より構造化された、より自信ありげな出力」です。判断材料がない人間にとって、それらは「正しさ」の代理指標にすらならない。むしろ説得力だけが増す。

第1回のポチョムキン理解（もっともらしい説明と実際の判断根拠は別物）が、そのまま人間側の監査能力にも遺伝しているわけです。

最有力の解決策候補は、検証したらどうなったか

「未解決問題」と言われると、「じゃあ研究者は何をやっているのか」と思いますよね。私も思ったので調べました。

2018年に提案された最有力候補が Debate（討論） です。2体のAIに反対の立場から議論させ、人間が判定する。中心的な発想は「嘘をつくより、嘘を論破するほうが簡単なはずだ」というもの。理論的にはかなり美しい提案でした。

これを大規模に実証検証したのが、DeepMindの Kenton et al. (2024)（NeurIPS 2024）です。判定役に弱いモデル、討論役に強いモデルを置いて、複数のタスクで検証しました。

結論は、率直に言ってかなり地味です。

✅ 討論は、AIが一方的に説得しようとする方式（Consultancy）より一貫して優れている
⚠️ しかし本題の「討論はAIなしで人間が直接判断するより優れているか」は、タスクによって結果が分かれた。情報の非対称性がある抽出型QAでは優位だが、それ以外では効果はまちまち
⚠️ より強いモデルを討論役にすると判定精度は上がるが、先行研究の期待より効果は控えめだった

さらに2026年のフォローアップ研究では、もっと厳しい指摘が出ています。討論方式で良い結果が出ているケースの多くは、判定者がわざと参考資料へのアクセスを断たれた、人工的な情報非対称性のある設定に偏っている。その人工的な非対称性を取り除くと、討論は単純な直接質問応答より性能が劣る場合すらある。

そして、Debateの原論文の著者たち自身が最初から認めていたことがあります。「人間は本当に討論を理解できるのか」は証明されておらず、未解決の経験的問題である、と。

2018年に「これで解決できるはず」と理論的に提案された最有力候補を、6年かけて本気で検証したら、お膳立てされた条件でしか効果が確認できなかった。

これが、2026年時点の正直な現在地です。

まとめ

長くなったので整理します。

機構の話

LLMは計算機ではなく直感マシン。1トークンあたりの計算量は固定（＝一律3秒、延長不可）
CoTはAIを賢くする技術ではなく、暗算縛りを解除して、ループを紙の上に外付けする技術
「ステップバイステップ」が曖昧なのに効くのは、手順を教えているのではなく出力のジャンルを切り替えているから。だから言い回しは本質ではなく、答えの前にどれだけトークンを吐かせるかが本質

壊れ方の話

CoTは一発書きで後戻りできない。だから「書いたものは動かせない」という制約から、後付けの辻褄合わせと計画への固執が同時に生まれる
その結果、CoTの説明は「もっともらしい物語」であって「判断根拠の記録」ではない。忠実性スコアは推論モデルでも25〜39%程度
そもそも直感型のタスクでは、CoTは精度そのものを下げる（最大36.3ポイント）

対処の話

計画先出し・自己批判・迎合の逆利用は有効だが、いずれも同じ「一発書き」の弱点を持つ
最も強いのは、開いた問いを、数えられる閉じた集合に変換すること。分岐網羅フローの赤/緑可視化はその実装例で、判定に必要な能力を「ドメイン知識」から「数を数えること」に落とせる

それでも残る話

これらは出力の質を上げるが、人間の検証能力の限界は解決しない。AIに聞く理由がある場面ほど、AIの答えを検証できない
これはスケーラブル・オーバーサイトという未解決問題で、最有力候補のDebateですら、実証検証では人工的な条件下でしか優位を示せていない

第1回のポチョムキン理解は「説明できることは、理解の証明にならない」という話でした。

今回はその延長として、こう言えると思います。

もっともらしく見えることは、検証されたことの証明にならない。
そして人間には、それを見抜ける保証もない。

赤と緑で塗り分けるのは、その巨大な問題に対する、ささやかだけれど確実に効く一手です。少なくとも「どこかで黙って手を抜かれている」という不安は消せる。そして消せた分だけ、限られた検証労力を「各分岐の中身は本当に正しいのか」という、まだ人間の手に負える大きさの問題に集中投下できる。

全部は解けません。でも、解けない部分がどこかを可視化することはできる。今のところ、それが一番誠実なやり方だと思っています。

次回は、Few-shot例の設計技法を扱う予定です。「例は指示より強い」という性質は前の連載で扱いましたが、では良い例とは何か、何個が最適か、並べる順番は効くのか。第2回・Lost in the Middleの位置効果が、例の並び順にも効くのではないか？という仮説も、あわせて検証してみます。

参考文献

Wei, J. et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS. arXiv:2201.11903
Kojima, T. et al. (2022). Large Language Models are Zero-Shot Reasoners. NeurIPS. arXiv:2205.11916
Turpin, M. et al. (2023). Language Models Don't Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting. arXiv:2305.04388
Chen, Y. et al. (2025). Reasoning Models Don't Always Say What They Think. Anthropic. arXiv:2505.05410
Liu, R. et al. (2024). Mind Your Step (by Step): Chain-of-Thought can Reduce Performance on Tasks where Thinking Makes Humans Worse. ICML 2025. arXiv:2410.21333
Pfau, J. et al. (2024). Let's Think Dot by Dot: Hidden Computation in Transformer Language Models. arXiv:2404.15758
Irving, G., Christiano, P., Amodei, D. (2018). AI Safety via Debate. arXiv:1805.00899
Kenton, Z. et al. (2024). On Scalable Oversight with Weak LLMs Judging Strong LLMs. NeurIPS 2024. arXiv:2407.04622
Lee, Y. et al. (2024). CheckEval: A Reliable LLM-as-a-Judge Framework for Evaluating Text Generation Using Checklists. arXiv:2403.18771