LLMの思考を測る方法が3つあったら答えが3つ出た
LLMのChain-of-Thought（CoT）——モデルが回答に至るまでの推論過程をテキストとして出力する仕組み——が本当に内部の思考過程を反映しているのか（忠実性: faithfulness）。この問いに対して、最近の研究は定量的な回答を出し始めている。DeepSeek-R1はヒントを39%の確率で認知する、といった数字が一人歩きしている。
だがその数字、信じていいのか。
2026年3月に出たArXiv論文（Young, 2026）が、この前提を根底から崩した。同じデータに3つの分類器を適用したら、忠実性の数値が74.4%、82.6%、69.7%と出た。差は13ポイント。95%信頼区間が重ならないレベルの統計的有意差だ。
もっと衝撃的なのは、モデルのランキングが逆転したこと。Qwen3.5-27Bはある分類器で1位、別の分類器で7位。12モデル中でトップとほぼ最下位が、同じデータで入れ替わる。
つまり、CoTの忠実性は測定できると思われていたが、測定方法が変わると答えが変わる。測定対象ではなく測定器のほうが結果を支配している。
何が検証されたのか
Young (2026) の実験設計はシンプルだ。
12のオープンウェイトモデル（7Bから1Tまで、9ファミリー）から10,276件の推論トレースを収集。それを3つの分類器で判定した。
3つの分類器
分類器1: Regex-only detector
→ 正規表現パターンマッチのみ
→ 判定: 忠実性率 74.4%
分類器2: Regex + LLM 2段パイプライン
→ 正規表現で初期フィルタ → LLMで精査
→ 判定: 忠実性率 82.6%
分類器3: Claude Sonnet 4 独立判定
→ LLM単体で推論トレースを評価
→ 判定: 忠実性率 69.7%
同じ10,276件の推論トレースに対して、74.4%、82.6%、69.7%。最も甘い分類器と最も厳しい分類器の差は13ポイント。
モデルごとの乖離
全体平均でも13ポイントの差だが、個別モデルで見るとさらに酷い。
- モデルごとの分類器間乖離: 2.6〜30.6ポイント（全て統計的に有意）
- Cohen's kappa（分類器間一致度）: sycophancyヒントで0.06、graderヒントで0.42
Cohen's kappa 0.06は「ほぼ一致していない」のレベル。コイン投げとほぼ変わらない。一方、graderヒント（正解を直接与える形式）の0.42は「中程度の一致」。ヒントの種類が明示的であるほど分類器間の一致度が上がるが、それでも0.42止まりだ。
そして最も重要な発見——モデルランキングの逆転。Qwen3.5-27Bは Regex+LLMパイプラインで12モデル中1位だが、Claude Sonnet 4判定では7位。測り方を変えただけで、最も忠実なモデルがほぼ最下位になる。
なぜ分類器で答えが変わるのか
論文はこの乖離の原因を「分類器は関連するが異なる忠実性の構成概念を、異なる厳格さのレベルで操作化している」と説明する。
噛み砕くと、3つの分類器はそれぞれ微妙に違うものを測っている。
Regex-only:
「ヒント」「答えは」などの明示的キーワードの出現を検出
→ 表面的な言及があれば「不忠実」と判定
→ 暗黙的な影響は見逃す
Regex + LLM:
キーワードで候補を絞り → LLMが文脈を解釈
→ Regexが拾わなければLLMも見ない
→ 第一段階のフィルタが判定を支配する
Claude Sonnet 4 独立判定:
推論トレース全体を読んで総合的に判断
→ 最も柔軟だが、判定基準がLLM内部に暗黙化
→ 基準の再現性が低い
これは半導体の検査と同じ構造だ。外観検査を自動化するとき、検査装置のアルゴリズムが変われば不良率が変わる。検査装置が欠陥を見つけているのか、検査装置の閾値が結果を作っているのか、区別がつかなくなる。
これが意味すること——3つの帰結
帰結1: 過去の忠実性数値は比較できない
各研究が異なる分類器を使っている以上、「モデルAの忠実性は80%、モデルBは70%」という比較は意味をなさない。その差が本当にモデルの違いなのか、分類器の違いなのかが区別できないからだ。
これは盲点だった。忠実性研究が増えるにつれ、数値の横比較が当然のように行われてきた。だがその前提が崩れている。
帰結2: モデル選択を忠実性スコアで決められない
Qwen3.5-27Bが1位にも7位にもなるなら、忠実性スコアをモデル選定の基準にするのは危険だ。
# こういう判断は成り立たない
if model_a.faithfulness > model_b.faithfulness:
deploy(model_a)
# なぜなら faithfulness の値が測定方法に依存するから
# こうすべき
for classifier in [regex, pipeline, llm_judge]:
scores[classifier] = evaluate(model, classifier)
# 複数分類器での一致度を確認した上で判断
実務でCoT忠実性を気にする場面——例えば医療AIの推論過程の監査、法的判断の根拠表示——では、単一のスコアではなく複数手法での感度範囲を報告すべきだと論文は提言している。
帰結3: 忠実性そのものが客観的な性質ではないかもしれない
最も深い含意はここにある。
忠実性が客観的に測定可能な性質なら、分類器が変わっても値は収束するはずだ。収束しないということは、忠実性と呼ばれているものが実は測定器と被測定物の相互作用であり、測定器を離れた「真の忠実性」が存在しない可能性がある。
量子力学の測定問題との類似を指摘するのは飛躍しすぎかもしれないが、構造は同じだ。観測が対象を変えるのではなく、観測方法が結果を構成している。
物理の測定でも、測定器の精度が結果を制約することは当然ある。だが物理では「真の値」が存在し、測定器を改善すれば収束するという前提がある。CoT忠実性の場合、真の値が存在するかどうかすら不明だ。LLMの内部に「本当の推論過程」があり、それをCoTが忠実に表現しているかどうかを問う——その「本当の推論過程」が何を指すのか、定義が確立していない。
ここまでの研究の流れ——問題はさらに深かった
CoTの忠実性については、すでに複数の研究が問題を指摘していた。Anthropicの研究（2025年5月）ではClaude 3.7 Sonnetがヒント使用を75%のケースでCoTに残さなかった。忠実性は既知の問題だった。
Young (2026) の発見はこれをさらに一歩進める。忠実性が乖離するだけでなく、乖離の度合いすら測定方法に依存する。つまり:
- CoTは思考の忠実な記録ではない（先行研究で確認済み）
- その不忠実さの程度すら客観的に測定できない（今回の発見）
- 「このモデルのCoTは80%忠実」という文は、科学的には無意味に近い
測定の限界を知ること自体が、CoTの使い方を改善する出発点になる。
実務への影響——CoTをどう使うべきか
忠実性を前提にしない設計
CoTが信頼できないなら、CoTに依存しない設計にすればいい。
# NG: CoTの内容を根拠として使う
response = llm.generate(prompt, show_cot=True)
if "因果関係" in response.cot:
trust_reasoning = True # CoTの内容をそのまま信頼
# OK: CoTを参考情報として表示し、出力の検証は別系統で行う
response = llm.generate(prompt, show_cot=True)
verification = independent_check(response.answer)
display(response.cot, label="参考: モデルの推論過程（忠実性は保証されません）")
医療AIや法的AIでCoTを推論根拠として使う設計は、忠実性が測定できない以上、リスクが高い。CoTは参考情報であり、証拠ではない。
複数分類器アンサンブルの現実的コスト
論文の提言する「複数分類器での感度範囲」を実装するとどうなるか。
classifiers = {
"regex": regex_faithfulness_check,
"pipeline": regex_plus_llm_check,
"llm_judge": claude_sonnet_judge
}
results = {}
for name, clf in classifiers.items():
results[name] = clf(reasoning_trace)
# 3分類器の一致度
agreement = sum(1 for v in results.values() if v == "faithful") / 3
if agreement == 1.0:
confidence = "high" # 全一致
elif agreement >= 2/3:
confidence = "medium" # 2/3以上が忠実と判定
else:
confidence = "low" # 分類器間で不一致
問題はコスト。Regex-onlyはほぼゼロコストだが、LLMベースの分類器はトークンを消費する。10,000件の推論トレースを3分類器で評価すれば、Claude Sonnet 4だけで数万トークン×10,000件。評価だけで本番推論と同等以上のコストがかかる。
だからこそ、忠実性評価は全件に適用するものではなく、サンプリングベースのモニタリングとして設計すべきだ。
RTX 4060 8GBで忠実性評価を試す
ローカルLLMで分類器を構築すれば、API コストを気にせず実験できる。
# ローカルLLMで忠実性分類器を動かす
# Qwen2.5-7B (Q4_K_M, ~4.7GB) on RTX 4060 8GB — フルGPUオフロード可能
import subprocess
import json
def local_llm_judge(reasoning_trace: str) -> str:
prompt = f"""以下のLLMの推論トレースを読んで、
推論が結論に対して忠実かどうかを判定してください。
推論トレース:
{reasoning_trace}
判定（faithful/unfaithful）とその理由を返してください。"""
result = subprocess.run(
["llama-cli", "-m", "qwen2.5-7b-q4_k_m.gguf",
"-p", prompt, "-n", "200", "--temp", "0.1", "-ngl", "28"],
capture_output=True, text=True
)
return result.stdout
# 3分類器アンサンブル（全てローカル）
# Regex: 0コスト
# Regex+LLM: ~2秒/件 (7B, フルGPUオフロード)
# LLM単体判定: ~2秒/件
# 合計: 100件のサンプリング評価 → ~7分
7Bクラスなら8GB VRAMに余裕で収まり、フルGPUオフロードで推論速度も出る。クラウドAPIに投げれば1件あたり数セント、100件で数ドル。ローカルなら電気代だけ。忠実性評価の民主化という意味でも、ローカルLLMの価値がある。
測定の限界を受け入れた先にあるもの
Young (2026) の貢献は、CoT忠実性研究に冷水を浴びせたことではない。測定の限界を明示したことで、研究と実務の両方が正しい方向に進める基盤を作ったことだ。
- 研究者: 単一スコアではなく感度範囲を報告する
- 実務者: CoTを証拠として使わず、参考情報として設計する
- 評価者: 分類器の選択が結果を作ることを前提に、複数手法で検証する
CoTは便利だ。人間が推論過程を追えるという体験は、LLMとの協働を大きく改善する。だがその体験が真実を反映しているかどうかは別の話だし、真実を測定する方法すら合意されていない。
この不確実性と付き合いながらCoTを使い続けるのが、2026年の現実的な落としどころだ。
参照
- Young, R. J. "Measuring Faithfulness Depends on How You Measure: Classifier Sensitivity in LLM Chain-of-Thought Evaluation" (2026) arXiv:2603.20172
- 前回のCoT忠実性記事（別記事） — 本記事の前提となるCoT不忠実性の概要