この連載について

ChatGPTやClaudeを毎日仕事で使うようになって、「なんか賢そうなのに、たまに信じられないミスをする」と感じたことはありませんか？

この連載では、LLM（大規模言語モデル）を実務で使い倒すために知っておきたい「LLMのクセ」を全10回で解説します。

ポチョムキン理解 ← 今回
Lost in the Middle
Context Rot
Sycophancy（迎合）
Context Handoff
Prompt Distillation
Project化の罠
GPT化の罠
Instruction Drift
AI成果物の品質保証

第1回は、すべての土台になる話。「AIは概念を説明できても、使えるとは限らない」という現象、ポチョムキン理解（Potemkin Understanding） です。

ポチョムキン理解とは？

2025年6月、ハーバード大学・MIT・シカゴ大学の研究チームが発表した論文 Potemkin Understanding in Large Language Models で提唱された概念です。

名前の由来は18世紀ロシアの逸話。軍人ポチョムキンが、女帝の視察のために「中身のないハリボテの村」を作って見せた……という話から来ています（史実かは怪しいらしいですが）。

一言でいうと：

LLMは概念の「定義」には正しく答えられるのに、その概念を「実際に使う」場面では一貫して失敗することがある

これがポチョムキン理解です。見た目は立派、中身はハリボテ。

具体例：本格的なカルボナーラの「乳化」

カルボナーラで考えてみます。ただし「材料が何か」ではなく、手順の中で起きる現象に注目するのがポイントです。

本格的なカルボナーラの核心は、実は材料そのものではなく、「卵黄・チーズ・パスタの茹で汁の脂とデンプンが、火を止めた余熱で乳化して、卵がスクランブルエッグにならずクリーム状のソースになる」という、手順の中で起きる物理的なプロセスにあります。材料が正しくても、「フライパンを火にかけたまま卵液を投入する」という手順を書いてしまえば、卵はただ凝固するだけで乳化は起きません。

質問①「本格的なカルボナーラが成立する条件を説明して」
→ LLMは完璧に説明します。「火を止めてから卵液を加え、余熱で乳化させる。直火にかけたまま加えると卵が凝固してしまう」

質問②「このレシピ(“フライパンを弱火にかけたまま卵液を加えて混ぜる”)は本格的？」
→ 定義上は明らかにNGなはずなのに、「はい、正しい手順です」と誤判定することがある

質問③「本格的なカルボナーラの手順を書いて」
→ 説明では「火を止めてから」と正しく言えていたのに、いざ手順を書かせると「弱火のまま卵液を絡める」と、こっそり自分の定義に反する手順を書いてしまう

材料は正しい。定義も正しい。でも判定させても生成させても、微妙にズレる。しかもそのズレ方に一貫性がありません。これがポチョムキン理解です。人間の職人なら「説明できるのに応用だけ一貫してズレる」という壊れ方は普通しません。

なぜ人間向けテストが機能するのか

「概念を理解している」とは、噛み砕くと**「ある物事を見たときに、それが概念に該当するかどうかを判定する、頭の中のYes/No判定基準(仕分け機)が、専門家の判定基準とほぼ一致していること」**です。

人間の場合、この判定基準が専門家とズレていても、そのズレ方が一貫しています。例えば「カルボナーラには生クリームが必要」と思い込んでいる人がいたとします。この人に「本格的な条件は？」と聞けば、その歪んだ基準がそのまま言葉として出てきます。だからこの人にレシピを作らせても判定させても、同じ歪んだ基準で一貫してズレるわけです。「定義を聞けば、その後どうズレるか予測できる」——これが人間向けベンチマーク（資格試験や面接など）が機能する理由です。誤解のバリエーションが少なく、代表的な質問1つで見抜けるということです。

LLMの場合、同じ概念に対して聞き方(タスクの型)を変えると、まったく別の判定基準が出てくることがあります。定義は完璧、でも分類させても生成させても別々の基準でズレる。しかもそのズレ方に人間的な一貫性がない。これが論文が定義する「ポチョムキン」の正体です。

もう一段深い原因：「ズレ」じゃなくて「矛盾」

ここが一番重要な発見です。論文は「LLMは、人間と同じように少しズレてるだけなのか」「それとも複数の判定基準が内部で共存して矛盾してるのか」を検証しました。

やり方はシンプルです。同じモデルに、まず具体例を生成させ、次に別の質問として「さっき自分が作ったこの例、本当に条件を満たしてる？」と自己採点させるのです。もしモデルの中に単一の一貫した判定基準があるなら、自分が作ったものを自分で正しく判定できるはずです。ところが実際には、モデルが自分の生成物を、自分で後から否定することが起きます。まるで「レシピを書いた自分」と「それを判定する自分」が別々の舌を持っているような状態です。

これは「ズレた基準がひとつある」という話ではなく、「生成するときに使った基準」と「判定するときに使った基準」が、そもそも別物として内部に共存しているということです。論文ではこの食い違いの割合を「incoherence（内部矛盾）スコア」として計測しており、モデルによって0.02〜0.64とかなり幅がありました。

コラム：この記事を書いている最中に、筆者(Claude)自身がポチョムキン理解を実演していた

実はこの記事の初稿では、上のカルボナーラの例え話として「グアンチャーレ・卵黄・ペコリーノ・黒胡椒・生クリーム不使用の材料リストを満たすか」というチェックリスト型の定義を使っていました。しかし読者から「その定義なら特徴の有無を照合するだけで済むので、そもそもズレが起きないのでは？」と指摘され、初めて誤りに気づきました。

これはまさに、「定義（ポチョムキン理解とは何か）を正確に説明できる」のに「その構造を再現する具体例を作らせると、定義が要求する構造を満たさないものを出してしまう」という、この記事のテーマそのものの失敗でした。しかも筆者は自分でそれに気づけず、指摘されるまで押し通していました。生成した本人が自分の生成物を正しく検証できるとは限らない、というincoherenceの話を、期せずして自ら証明してしまった格好です。

なぜアーキテクチャ的にこれが起きるのか

LLMは「次に来るトークンを当てる」ことだけを目的に学習されています。同じ概念でも、

定義を語る時の文章（教科書・解説文っぽい文体）
判定する時の文章（クイズ・レビューっぽい文体）
手順を書く時の文章（ブログ・マニュアルっぽい文体）

は、学習データの中ではまったく別の文章ジャンルとして出現します。人間の職人なら「本格的なカルボナーラ」という1つの理解モデルを頭に持っていて、聞かれ方が変わっても同じ基準で答えます。でもLLMには「聞き方が変わっても同じ内部表現を使う」ことを保証する仕組みがそもそもありません。

タスクの型（定義・判定・生成）が変わるたびに、微妙に別の「判定基準の断片」が呼び出されてしまう

というのが、根本原因の一番深いところです。「勘違いしている」のではなく、**「聞き方次第で別人格が答えている」**に近いイメージです。

「具体例をたくさん学習すればいいのでは？」への反証

これは自然に浮かぶ疑問ですが、実は成立しません。俳句もカルボナーラもナッシュ均衡も、学習データ中に「正しい例・間違った例」のペアが大量に存在する、むしろ具体例が異常に豊富な概念です。もし「具体例の量」が解決策なら、この手の超メジャー概念こそ真っ先にポチョムキン理解が起きないはずですが、そうなりませんでした。

ここで区別すべきは2つの別物です。

具体例の量（volume）：学習中に正しい例・間違った例を何回見たか
タスクを跨いで同じ判定基準を使わせる、という制約（consistency constraint）：define時の基準とgenerate時の基準が同一であることを強制する学習信号

次トークン予測という学習目的は、①をひたすら積み上げることはできても、②を保証する仕組みを持っていません。損失関数は「このトークン列の次に来る単語として尤もらしいか」だけを見ていて、「さっき定義で使った基準と、今生成で使っている基準が論理的に同一かどうか」は一切チェックしていないからです。どれだけ例の数を増やしても、この制約自体が学習に組み込まれない限り、分裂は解消されない可能性が高い、ということです。

対処法：7つのアプローチ

マルチペルソナレビュー：視点の異なる複数の人格に独立評価させ、意見が割れた箇所を検出する
批判的再鑑者（アドバーサリアル・レビュー）：性善説を捨てて「定義と応用のズレ」を狙い撃ちで疑わせる、別枠のレビューを挟む
定義＋具体例の同時要求：同じターンで定義と具体例を両方出させ、直前の文脈を手がかりにさせる
生成→自己分類の食い違いチェック：生成させた後、別クエリで「本当に条件を満たしてるか」を自己採点させ、食い違いを検出する
複数回生成させて多数決を取る（self-consistency）：同じ依頼を独立に複数回生成させ、結果のバラつきを見る
判定プロセスを明示的に分解して踏ませる：チェックリストでは解けない概念（関係・因果・手続き型）に対し、判定の手順を細分化させる
AIの自己検証だけで完結させず、外部検証（実行・ログ・数値）を挟む：コードのように実行して確認できる対象には、これが最も強い

なぜ1・2・4・5だけでは不十分なのか

一見どれも有効そうですが、実は共通の弱点があります。マルチペルソナも批判的再鑑者も、結局は同じ重みの中から呼び出された、別ラベルの人格でしかないという点です。独立したモデルではなく、同じ判定基準の集合から、違うプロンプトで別の断面を切り出しているに過ぎません。

タスクの型によって別の基準が呼ばれる場合 → 視点を変えれば矛盾を炙り出せる（効く）
どの視点・どのタスク型でも同じ盲点が共有されている場合（材料リスト型のカルボナーラのように、そもそも学習データレベルで本質を誤解しているケース） → 何人格演じさせても、批判的にレビューさせても、全員が同じ盲点を共有したまま「合っています」と言う

これは機械学習のアンサンブル手法と同じ限界です。アンサンブルはメンバー間の誤差が独立（uncorrelated）な時だけ機能します。今回のケースはメンバー全員が同じ重みから来ているので、誤差が相関しています。相関した誤差は、いくら人数を増やしても消えません（1・2・5の限界）。

4（生成→自己分類）も、食い違いを検出はできても、「どちらの基準が正しいか」を決める第三者の基準がどこにもないため、無限に往復させても真の解に収束する保証がありません。検出器であって修正器ではない、というのが正確な位置づけです。

どんでん返し：6が「独立した外部基準」を作れば、1・2・3・4は機能する

1・2・4が機能しなかった理由は、比較対象が両方とも「同じモデルの中の曖昧な感覚」だったからです。しかし6（分解）を正しく実行できれば、話が変わります。チェックポイントの明文化は、暗黙の判定基準を、外部から参照可能な明示的な文章に変換する作業です。これができた瞬間、1・2・3・4の性質がまるごと変わります。

1（マルチペルソナ）：各人格が自分の暗黙の感覚ではなく、明文化されたチェックポイントに沿って判定するようになる。人格間で食い違うとしたら「感覚のズレ」ではなく「チェックポイントの読み違い」になり、原因特定がしやすい
2（批判的再鑑者）：レビュアーが自分の知識で概念を再構築する必要がなくなり、「チェックリストに沿っているか」を機械的に照合するだけでよくなる。判定のハードルが「概念理解」から「文章の照合」まで下がる
3（定義＋具体例同時）：チェックリスト自体が「定義」と「引っかけ例」をセットで持つため、Phase Aの時点で組み込み済みになる
4（生成→自己分類ループ）：固定された外部参照点ができるため、生成物とチェックリストを照合するだけで済み、無限ループする理由がなくなる

つまり6は、1・2・4に共通して欠けていた「独立した外部基準」を作る工程そのものだった、ということです。

ただし正直に言うと、これでリスクがゼロになるわけではなく、リスクの所在が一段抽象度の高い場所に移動するだけです。「概念を正しいチェックポイントに分解する」という作業自体が一種の生成タスクであり、分解が本質を外すリスク（材料リスト型のカルボナーラの失敗のように）は残ります。ここで重要なのは、この分解結果（チェックリスト）は一度作れば使い回せる固定資産になるということです。毎回の出力を人間がレビューするのではなく、「このチェックリストが本質を捉えているか」を、その概念について最初に1回だけ検証すればいい。一度検証されたチェックリストは、以降1・2・3・4を回す土台として繰り返し使えます。コードのlintルールやテストスイートを1回書けば、以降は自動で回せるのと同じ構造です。

「結局、人間の判断が必要」という結論で終わらせず、人間の関与を"毎回の出力チェック"から"分解結果の一度きりの妥当性検証"まで圧縮する——これがこの記事の実践的な着地点です。

実践編：プロンプト設計

**Phase A（1回だけ実行・人間が検証する分解工程）とPhase B（毎回回す運用工程）**の2段構成にします。

Phase A：概念をチェックリスト化する

あなたはこれから「{概念名}」を、後工程で機械的に照合できる形に分解します。

# 手順
1. まず、この概念が次のどちらのタイプに近いか判定してください。
   - タイプA:表層的な特徴の有無だけで判定できる概念
   - タイプB:要素だけでなく、要素間の関係・因果・手順を踏まないと判定できない概念
   タイプBの場合、「構成要素のリスト」だけに分解すると本質を外すリスクが高いので、
   関係・因果の向き・発生条件まで分解に含めてください。

2. 分解した各チェックポイントについて、必ず次の3点をセットで書いてください。
   - チェックポイントの内容
   - 確認方法(観察・計算・実行結果など、具体的にどう確認するか)
   - 引っかけ例(満たしているように見えて実は満たしていない具体例を1つ)

3. 最後に「このチェックリストだけで概念を過不足なく判定できるか」を自己点検し、
   抜けている観点があれば追加してください。

出力形式:
## 概念タイプ判定
## チェックリスト(項目・確認方法・引っかけ例)
## 自己点検結果

「引っかけ例」を要求することで、分解が表層チェックリスト止まりになるのを防ぎます。人間がレビューするのはこの出力1回だけで、以降は使い回します。

Phase B：チェックリストを外部基準として1・2・4を回す

4（生成→自己分類）に終了条件をつける

チェックリスト:{Phase Aの出力を貼る}

Step1: 上記の概念に沿って{依頼内容}を生成してください。
Step2: 生成物をチェックリストの各項目に照合し、◯✕と根拠を1行で示してください。
Step3: ✕がある項目だけを修正して再生成してください。
Step4: 全項目◯になったら完了と報告。3回修正しても◯にならない項目が残れば、
       ループを止めて「未解決項目」として報告してください(人間レビューに回す)。

1（マルチペルソナ）を同じチェックリストで揃える

チェックリスト:{Phase Aの出力を貼る}

以下の3人格が、上記チェックリストのみを判断根拠として、独立にレビューしてください。
人格間で相談しないこと。自分の感覚ではなく、チェックリストの確認方法に従うこと。

【人格A:シニアアーキテクト】
【人格B:ドメインエキスパート】
【人格C:レッドチーム視点】

各人格は項目ごとに◯✕と根拠を出し、最後に人格間で判定が割れた項目だけ報告してください。

2（批判的再鑑者）は知識不要のレビュアーになる

チェックリスト:{Phase Aの出力を貼る}

あなたは粗探し専門のレビュアーです。あなた自身の概念理解は使わず、
上記チェックリストの「確認方法」だけを根拠に照合してください。
判定が怪しい項目は、チェックリストの「引っかけ例」との類似性を確認してください。

3（定義＋具体例同時）は、Phase Aの出力自体が定義と引っかけ例をセットで持っているため、追加のプロンプトなしで組み込み済みになります。

7（外部検証）だけはこのチェックリストを介さず、実行ツールやログを直接確認させる別トラックとして扱います。コードの動作確認のように「実行して確認できる」対象では、これが最も信頼できる手段です。

まとめ

LLMは「定義に答えられる」のに「分類・生成では一貫してズレる」ことがある＝ポチョムキン理解
原因は単なる「誤解」ではなく、タスクの型ごとに別の判定基準が呼び出される内部矛盾（incoherence）
学習データの量を増やしても解決しない。「タスクを跨いだ一貫性」を保証する制約が学習にないことが根本原因
マルチペルソナ・批判的再鑑者・自己分類ループは、単体では「相関した誤差」に無力
判定プロセスの明示的な分解（チェックリスト化）が、独立した外部基準を作り、他の対処法を機能させる鍵になる
人間の関与は「毎回のチェック」ではなく「チェックリストの一度きりの妥当性検証」まで圧縮できる
実行して確認できる領域（コードなど）では、外部検証が最も強い

次回は、長いプロンプトの「真ん中」が読み飛ばされる現象、Lost in the Middle を扱います。長文の仕様書を丸ごと貼り付けてる人、要注意です👀

参考文献

Mancoridis, M., Weeks, B., Vafa, K., & Mullainathan, S. (2025). Potemkin Understanding in Large Language Models. arXiv:2506.21521