蒸留にはマーケティングの物語と本当の物語がある。マーケティングの物語は、高価なフロンティアモデルを安価な 7B の生徒で置き換え、品質の 95% を保つ、というもの。本当の物語は、これを試したほとんどのチームが「生徒は評価セットでは問題なく、本番では平凡で、ドリフトすればデバッグ不能」だと発見する、というものだ。蒸留は確かに有用なツールだ——ただし、いつ箱から取り出すかの判断には、通常より慎重さを要する。

この記事は意思決定フレームワークであってチュートリアルではない。特定のワークロードについて Claude を蒸留すべきか天秤にかけているなら、見るべきシグナル、考えるべき経済性、そして生徒モデル単独に賭けなくて済むルーティングパターンをまとめておく。

甘い罠（「Opus を 7B に置き換え」がたいてい間違いな理由）

売り文句は魅力的だ：Claude の請求が増えている、小さなオープンモデルは僅かなコストでファインチューニングできる、自前 GPU の推論は償却後には実質タダ。差し替えて出荷継続。

実際に起こることはもっと微妙だ。生徒モデルは蒸留元の分布ではよく動くが、その後ロングテールで静かに壊れる。ユーザーがわずかにスコープ外のことを聞く、慣れた依頼を見慣れない言い回しで表現する、そうすると生徒は自信満々に的外れなことを吐く——Claude なら hedge するか、質問を返すか、拒否したはずの場面で。数週間気付かない。なぜなら評価セットが学習データと同じ分布から引かれているからだ。

第 2 の問題：測っていない次元での能力崩壊。あなたは「このチケットを分類する」ために蒸留した、生徒は分類が得意になった。しかしパイプラインのどこかで、Claude の「チケットを一文で首尾よく要約する」能力にも頼っていた。生徒はスモークテストは通るが精読すると通らない要約を吐く。監査人が気付くまで誰も気付かない。

第 3 の問題：「安い 7B の生徒」は、正直に数え上げると API より高いことがままある。GPU レンタル、運用工数、学習パイプラインの構築・保守にかかるエンジニアの月数、データ分布が動くたびの再学習サイクル——これらのコストは実在し、しかも先払いだ。蒸留モデルが本番に載ろうが載るまいが支払うことになる。

以上は、蒸留が悪いという意味ではない。「Opus を 7B に置き換え」というフレーミングが間違っているという意味だ。正しいフレーミングはこうだ：私のワークロードのどの断面が、蒸留が本当にペイする性質を持っているか？

タスクが蒸留の良い候補である 5 つのシグナル

蒸留が「元を取る」タスクは、共通した性質のファミリーを持つ。多くが当てはまるとき、算数が回り始める。

1. タスクが狭い。 「カスタマーサポート」ではなく、「チケットを 12 カテゴリに分類し、対象製品の SKU を抽出する」。狭いタスクは入力分布が有界、出力空間が有界で、広い世界知識を要するエッジケースが少ない。Claude の汎用性はここでは無駄になる——だからこそ生徒が追いつける。

2. 挙動が安定している。 タスクが半年間実質的に変わっておらず、変わる予定もない。プロダクトマネージャーが来四半期に 3 つ新カテゴリを足すつもりなら、変更のたびに再学習サイクルだ。蒸留は安定を報い、変動を罰する。

3. 量が多い。 呼び出しが月に数千ではなく数百万。蒸留には固定コスト——データセット構築のための教師推論、学習、評価、デプロイ——と、呼び出しあたりの節約がある。高量は固定コストを償却する；低量はしない。

4. 推論の根拠がプログラム的である。 このタスクで Claude がやっている推論が、チェックリストを辿るとかルールを適用するとかに見えて、新奇な洞察を組み立てているようには見えない。プログラム的な推論の根拠は小さなモデルによく圧縮される。オープンエンドな推論は圧縮できない。ロジックを長大な決定木として書けそうなら、たぶん蒸留できる。

5. 結果が検証可能である。 生徒の出力が正しいかを、安価かつ自動で判定できる。構造化出力、抽出タスク、コンパイルしてテストを通るコード、グラウンドトゥルースのある分類——これらは検証可能。「モデルは良い返信を書いたか」は、信頼できる別の検証器を持たない限り、検証可能ではない。

蒸留の強い根拠は、5 つのうち 4 つか 5 つが真であるときだ。2 つか 3 つなら、Claude 上に留まってプロンプト長・キャッシング・ルーティングなど別のものを最適化するほうが良い。

そうでない 5 つのシグナル

鏡像も同じくらい重要だ。紙の上では蒸留が魅力的に見えて、本番で失望させるタスク群。

1. タスクが広いかオープンエンドである。 「顧客のどんな質問にも答える」「役に立つ返信を書く」は汎用能力に依存する。特定分布の例で学習した生徒は、現実がその分布から外れた瞬間に壊れる——そして現実は必ず外れる。

2. 推論の根拠が世界知識や判断を要する。 Claude が広い知識を引き出し、トレードオフを秤にかけ、審美眼を働かせるあらゆるタスクは、悪い蒸留対象だ。こうしたタスクの教師出力は入力だけの関数ではない：入力と、教師の学習全体、の関数だ。7B に圧縮しきれない。

3. 分布がドリフトしている。 入力が月次で変わる——新製品、新ユーザー行動、新用語。蒸留モデルは学習した瞬間で凍結する。フロンティアモデルが動く世界に自然に適応し、生徒が追随しないなら、現状維持のためだけに再学習にエンジニアの数か月を焼くことになる。

4. 微妙な失敗のコストが高い。 蒸留モデルは教師とは違う壊れ方をする。自信満々に、もっともらしく聞こえるが誤った出力を吐き、人間レビュアーが気付かないことがある。誤答が高価な領域——法務レビュー、医療トリアージ、金融助言——では、蒸留のテールリスクは実行時の節約に見合わないことが多い。

5. 検証器が作れない。 生徒の出力を自動でチェックする方法がなければ、継続的な評価は走らせられず、低信頼度なケースを Claude にフォールバックするルーターも組めず、リグレッションも検知できない。検証器なしの蒸留は目隠しのベットだ。

非対称性に注目：蒸留を正当化するには複数の陽性シグナルが要り、強い陰性シグナル 1 つで却下されることも多い。その比率が正しい。蒸留は最適化であり、最適化はケースが明白なときにだけ追求されるべきだ。

経済性：教師コスト対ランタイム節約

経済性の問いは「生徒での推論は API より安いか？」ではない。「気にする期間の総コストで、蒸留の総コストは API 継続の総コストに勝てるか？」だ。これは損益分岐計算であり、数値を入れる前に記号のまま済ませておく価値がある。

置く：

教師のまま行くコストはおおよそ N · c_t。

蒸留してルーティングするコストはおおよそ D + T + M + N · ((1 - q) · c_s + q · c_r)。

蒸留が勝つのは：

N · c_t > D + T + M + N · ((1 - q) · c_s + q · c_r)

並べ替えると、1 コールあたりの節約 (c_t - (1 - q) · c_s - q · c_r) が、N コールに渡って D + T + M を回収できる大きさでないといけない。

ここから直ちに分かること。実務では量は二乗のように効いてくる——N が大きいほど固定コストの償却が進み、節約も可視化される。品質差は人の想像より効く——q が 20% で c_r が c_t に近いなら、節約のほとんどはフォールバック経路で食われている。そして保守は選択肢ではない：M を予算に入れないなら、インシデントとして支払うことになる。

これに偽の数字を入れないこと。式の目的は、各項を正直に見積もらせることだ。実際にやってみたチームの多くは、N が小さすぎる、q が高すぎる、M を無視していた、のいずれかを発見し、損益分岐の期間が機能の寿命より長いと知る。

式が回るときは、たいてい圧倒的に回る——節約は 20% ではなく 5x とか 10x になる。「蒸留で 15% 節約できる」という見積もりなら、たぶん何かを勘定に入れ忘れていて、本当の答えは負の可能性が高い。

3 つのルーティングパターン

蒸留に意味があるときでも、生徒を単独でデプロイするのが正しいアーキテクチャであることは稀だ。面白い問いは、生徒・教師・その他のコンポーネントの間でどうルーティングするかだ。3 つのパターンで、ほとんどの本番構成は説明がつく。

カスケード

全コールをまず生徒に投げる。生徒の出力が信頼度の閾値——ロジットベースのスコア、検証器のチェック、分布外検知シグナル——を通れば返す。通らなければ教師にフォールバックする。

これは主力パターンだ。高信頼の大多数トラフィックでランタイム節約の大半を捕り、テールでは教師の品質を保つ。エンジニアリング的複雑度は中程度：本物の信頼度シグナル（モデルの自己申告の確信度はしばしば無用）が必要で、フォールバック率をドリフトの先行指標として監視する必要がある。

カスケードは信頼度シグナルが悪いときに失敗する。生徒が自信満々に間違っていると、カスケードはその失敗を通してしまう。生徒だけでなく、シグナルに投資すること。

蒸留 + 検証

生徒が出力を作り、別の検証器——教師のこともあれば、小さなルールエンジンのことも、2 つ目の蒸留モデルのこともある——がチェックする。検証が落ちたら教師で再試行するかエスカレートする。

このパターンは、検証器が教師よりずっと安くて生徒の自己申告信頼度よりずっと信頼できるときに輝く。抽出タスク（正しいフィールドを引けたか？）、構造化出力（この JSON はバリデーションを通るか？）、コード（コンパイルしてテストを通るか？）は自然にはまる：検証がほぼタダで、ほぼ完璧だからだ。

罠は、「検証器」が実は生徒と同じ盲点を持つ別のモデルであるとき。安全性を足さずに遅延だけ足したことになる。

アンサンブル

生徒と教師を並列で走らせ、出力を合成するか調停する。生徒を初手の安価な回答、教師を権威ある回答として 2 段目のストリームで返す、といった形もある。投票の重み付けをすることもある。

アンサンブルは、コスト重視の構成では最も少ないパターンだ。たいてい教師単独より高くつく。ここが元を取れるのはレイテンシがクリティカルな経路だ：生徒の答えがユーザーに即ストリームされ、教師の答えはバックグラウンドで完了し、意見が違えば上書きする。これは UX の勝ちであって、コストの勝ちではない。

多くのチームはまずカスケードに手を伸ばし、検証器ができれば足し、他の方法で満たせない特定のレイテンシ要件があるときにだけアンサンブルを組む、という順番でよい。

正しい問い

正しい問いは「Claude を蒸留すべきか？」ではない。「私たちのワークロードのどの断面が、蒸留が継続的コストに見合う性質——狭く、安定し、高量で、プログラム的で、検証可能——を持っているか？」だ。多くのチームにとって答えは「プロダクト全体ではなく、1 つか 2 つの断面」だ。その断面は慎重に追求する価値がある。残りは教師に任せておく。

良い候補があると確信したなら、次の問いは実務的なものだ：生徒に Claude が知っていることを本当に教える推論の根拠データセットをどう作るか、そしてどうやって蒸留を模倣ではなく説明に集中させておくか。それぞれ別の記事だ。