Claude の逐次的な説明で小さなモデルをファインチューニングする。評価セットでのその推論の根拠は素晴らしく見える——一貫していて、構造も整っていて、教師と区別がつかないこともある。本番投入する。6 週間後、誰かが摂動実験を走らせて、推論の根拠のテキストと最終的な答えは実質的に無相関だと発見する。モデルは喋っている。ただ、口に出しながら考えてはいないのだ。
これが推論の根拠の忠実性問題であり、最近の解釈可能性研究の中でもとりわけ居心地の悪い発見の一つだ。Claude のワークフローから蒸留しているなら——特に教師の思考の連鎖 (CoT) を学習信号の一部にしているなら——このための実務的なメンタルモデルが必要になる。そうでなければ、間違った対象を最適化し、下流での静かな失敗に驚かされることになる。
忠実性が実際に意味するもの
「忠実性 (faithfulness)」は、正確に定義しようとするまでは直感的に分かった気になる言葉の一つだ。説明の品質評価に関する文献では、これは特定の意味を持つ：説明が忠実であるとは、モデルが出力を生成するために実際に使った推論過程を、その説明が正確に反映していることをいう。もっともらしいこと、正しいこと、人間の読み手にとって有用であることとは別物だ。
Wiegreffe と Marasovic による NLP における説明評価のサーベイは、この区別を鋭く提示した。彼らは plausibility（もっともらしさ：この説明は人間に説得的に見えるか？） と faithfulness（忠実性：この説明はモデルの実際の計算を記述しているか？） を分けて論じた。もっともらしさは読み手側の性質。忠実性はモデル側の性質。推論の根拠は「高くもっともらしく」かつ「完全に不忠実」でありうるし、この 2 つの失敗モードは意図的にテストしない限り区別がつかない。
蒸留モデルにとって、この分裂は特に痛い。学習損失はもっともらしく見える出力に報酬を与える——教師が生成したのがそういう出力だからだ。標準的な教師あり目的関数の中に、生徒の述べた推論と、内部で実際に使っている特徴とを対応させる力は何もない。結果として、信じられる説明文を書くことに最適化されたシステムが手に入る。自分自身を説明することに最適化された、とは限らない。
Anthropic の Lanham らはこれを思考の連鎖に対して直接検証している。CoT の忠実性を測る彼らの研究は、ある種の状況ではモデルは CoT を切り詰めても、言い換えても、能動的に破壊しても、同じ答えに到達しうることを示した。これは、推論の根拠の中の言葉が最終的な答えを支えていなかったという強い信号だ。別の状況では CoT が実際に効いていて、推論トレースを変えると答えが変わる。もどかしいのは、推論の根拠のテキストだけを見てもどちらの領域にいるか分からないことだ。
Turpin らは別角度からこの点を突いた。彼らは、選択肢問題での正解位置や、微妙な文脈手がかりといった「バイアス特徴」がモデルの最終予測をずらしうるが、それが推論の根拠で言及されることは一度もない、と示した。モデルは質問の内容についての議論のように聞こえる文を生成する。実際の答えの駆動要因は、推論の根拠が一切触れない特徴だ。これは不忠実性の最も影響の大きい形——説明は不完全なだけでなく、因果構造について能動的にミスリーディングだ、という形——である。
失敗はどう検出されるのか
忠実性を綺麗に合否判定してくれるテストは存在しない。あるのは摂動ベースの一連のプローブで、それぞれが別の失敗モードを検出する。蒸留モデルを本気で本番投入するなら、少なくともこのうち 2 つは走らせるべきだ。
推論の根拠の摂動。 推論の根拠が生成されたあと、最終的な答えが生成される前に、推論の根拠を変える。答えが変わらないなら、推論の根拠は意味のある仕事をしていなかった。よくある亜種：CoT を途中で切り詰める、言い換える、間違いを挿入する、別の問題の推論の根拠に置き換える。前後の答えの分布を比較する。一致率が大きければ、モデルは推論の根拠を装飾として扱っている。
反実仮想の入力。 述べられた推論が忠実なら答えが変わるはずのやり方で入力の何かを変える。モデルの推論の根拠が「X に言及しているから B を選んだ」と言っているなら、入力を編集して X が今度は A に含まれるようにする。忠実な推論器なら A を選ぶはずだ。不忠実なら、「X だから」と言い続けながら依然として B を選ぶ。Turpin の研究が突いているのはここに近い：述べられた理由と真の駆動要因が乖離するような入力を構築する。
バイアスプローブ。 モデルが依存すべきでない偽の特徴——位置、書式、名前、注意逸らしの文——を導入する。最終的な答えがどれだけずれるかを測る。次に、推論の根拠がその偽特徴に言及したかを確認する。無言のずれこそが証拠だ。
言い換えを跨いだ一貫性。 同じ質問を複数の表現で尋ね、推論の根拠が互いに、そして答えと整合しているかを見る。蒸留モデルはここで驚くほど脆いことが多い：意味は同じなのに推論の根拠が大きく違い、時には答えまで違う。
どれも完璧ではない。摂動はモデルを分布外に押し出して信号を撹乱しかねない。反実仮想は構築コストが高い。バイアスプローブはどの偽特徴が問題かの仮説が要る。それでも、これらを組み合わせれば、いくつかの推論の根拠を読んで「良さそう」と結論付けるよりずっと良い像が得られる。
FDE がなぜリスクを増幅するのか
FDE（Focused Distillation from Explanations、最近この略称が流通している）は、答えと推論トレースをペアにした教師出力のキュレーション集合から生徒が学ぶ、という学習レシピだ。Claude ワークフローに自然に噛み合う：強い教師から質の高い推論を生成し、推論が一貫している例だけをフィルタし、より小さなモデルに答えと推論トレースの両方を再現させる。
これは機能する。この方法で学習させた生徒は、下流タスクで、答えだけで学ばせた生徒より一般に良い結果を出す。推論トレースが密な教師信号を提供し、キュレーションがノイズを取り除く。ここまでは順調だ。
問題は、学習目的が「生徒が教師のように推論することを学んでいる」と「生徒が教師の推論のように 聞こえる 出力を作りつつ、実際には別のことをしていることを学んでいる」を区別しないことだ。両方の目的が、読みやすい推論の根拠上で低い損失を生む。しかし、推論の根拠が「効いている」生徒を作るのは片方だけだ。
FDE 特有の要素が、この状況を特に悪化させる。
-
推論の根拠の品質でフィルタすると、もっともらしさを直接選抜することになる。 学習セットを、推論の根拠を読んだり LLM ジャッジでスコアしたりしてキュレーションするとき、あなたはもっともらしく見えるトレースを直接最適化している。それこそが、もっともらしさと忠実性が乖離する軸だ。生徒を失敗モードへ押しやっている格好になる。
-
生徒は教師より容量が小さい。 蒸留は圧縮だ。教師が内部でやっていたことのうち、生徒に簡潔に表現できないものは必ずある。生徒はどこかで妥協する。推論トレースは犠牲にしやすい部分の一つだ——学習信号は、もっともらしいが結合していないトレースを罰しないので。
-
評価がたいてい答えの精度で止まっている。 ほとんどの FDE パイプラインは生徒をタスクメトリクスで評価する。答えの分布が評価セット上で教師と一致していれば、レシピは成功と宣言される。推論の根拠が仕事をしているかどうかは、パイプラインの誰も問わないので、見ないまま終わる。
結果として、ベンチマークで良い成績を出し、流暢な説明を生成し、それでいて推論の根拠が一度も触れない特徴に静かに依存している、というクラスの蒸留モデルができあがる。多くのアプリケーションではそれで問題ない。しかし、推論の根拠がユーザーに見える、監査対象になる、あるいは別のシステムへの入力として下流で使われるアプリケーションにとっては、深刻な問題だ。
Claude ワークフローで蒸留モデルを本番投入するチームのための 3 つの緩和策
推論の根拠の忠実性は、現行技術では完全には解けない。エクスポージャーを減らすことは間違いなくできる。工数を投じる価値のある 3 つ。
1. 忠実性の評価を蒸留パイプラインに追加する
生徒のタスク性能を評価している何かの隣に、少なくとも 1 つ、摂動ベースの忠実性プローブを置く。最も単純な版：評価例の無作為サブセットについて、生徒の推論の根拠を生成し、次に推論の根拠を長さの 50% まで切り詰めた状態で 2 つ目の答えを生成する。一致率を測る。推論の根拠の半分が欠けていても生徒が 90% 以上自分と一致するなら、その断面で推論の根拠は意味のある仕事をしていない。
粗い信号ではあるが、安いし、最悪の悪化は捕まえられる。時系列で追う。生徒を再学習してタスク精度は横ばいなのに忠実性数値が下がったなら、新しいチェックポイントが推論を表面的な形と交換している警告になる。
予算があるなら、答えを駆動すべき特徴が分かっている手作りの例で反実仮想プローブを走らせる。生徒の答えのずれを教師のそれと比較する。乖離が診断的だ。
2. Claude を学習教師だけでなく、監査層としても使う
多くの FDE パイプラインは Claude を 1 つの役割——学習データの生成——にしか使わない。同じくらい価値のある 2 つ目の役割がある：評価時や本番で生徒の推論の根拠を監査させることだ。
具体的には、生徒の出力のサブセットを Claude に戻し、入力・述べられた推論の根拠・最終的な答えを別フィールドとして与えて、推論の根拠と答えを比較し不整合をフラグさせる、というプロンプトを走らせる。この種の構造化された批評は Claude が得意な領域だ。不忠実なトレースをすべて捕まえるわけではないが、明らかなもの——答えと矛盾する推論の根拠、入力にない情報に訴える推論の根拠、実際の決定点を飛ばす推論の根拠——は捕まえる。
これを CI や、本番のサンプル抜きシャドウ評価に組み込む。監査プロンプトを CLAUDE.md 的な仕様として書いておけば、再現可能でバージョン管理できる。「なんとなく良さそう」を超えた、継続的な推論の根拠の品質指標が手に入る。
3. 推論の根拠が任意または検証可能な形になるようにプロダクト面を設計する
最も堅牢な緩和策はアーキテクチャ的なものだ：検証されていない生徒の推論の根拠を、あたかも信頼できる説明であるかのようにユーザーや下流システムに見せない。推論の根拠をユーザーに見せる場合は、「その答えの理由」ではなく「モデルが自称している推論」としてラベル付けする。別の自動ステップの入力にする場合は、推論の根拠が答えと整合しているか確認する検証パスを、動作前に挟む。
ハイステークスなケースでは、最終的な答えを別の推論チェックに通すことも検討する——Claude 呼び出しでも、不忠実なトレースを捕まえるよう専用に学習させた小さな検証器モデルでもいい。レイテンシとコストは増える。しかし静かな失敗モードを騒がしい失敗モードに変えられる——重要な用途では、ほぼ常にその方が正しい取引だ。
おわりに
居心地の悪い真実は、現行の蒸留レシピは「正しく見える推論の根拠」を作るよう最適化されていて、「モデル自身の計算について正しい推論の根拠」を作るようには最適化されていない、ということだ。これは特定の学習ランのバグではない。損失関数が何に報酬を与え、人間のキュレーションが何を選抜するかの帰結だ。Wiegreffe と Marasovic のフレーミング、Lanham らの CoT 実験、Turpin らのバイアス研究——どれも別の角度から同じ形の失敗を示している：もっともらしさは易しく、忠実性は難しく、その隙間こそが物事が壊れる場所だ。
Claude ワークフローの上に構築しているなら——学習データを生成し、より小さなモデルに蒸留し、プロダクトに載せているなら——デフォルトで生徒の推論の根拠は不忠実であると想定し、その想定が安全に成立するように評価とプロダクト面を設計する。推論の根拠のテキストを信じて後で驚くよりも、ずっと良い構え方だ。
学習時側の話については、Focused Distillation from Explanations for Builders を参照。忠実性チェックを再現可能にする仕様と監査を軸に Claude ワークフローを構造化する話は、Claude Code CLAUDE.md Complete Guide を参照。