この連載について

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

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

こんな経験はありませんか。30往復の試行錯誤の末に、ようやく理想のコードレビューをしてくれるようになった。何度も修正指示を出して、やっと好みの文体で書いてくれるようになった。——で、新しいチャットを開いた瞬間、全部リセット。

第3回で学んだ通り、長い会話は腐る（Context Rot）ので、チャットは切り替えなければなりません。しかし切り替えるたびに、苦労して育てた「良い状態」がゼロに戻るのは耐えがたい。そこで誰もが考えるのが、「うまくいった会話を、再利用可能なプロンプトに凝縮する」——今回のテーマ、**Prompt Distillation（プロンプト蒸留）**です。

第5回のContext Handoffが「フェーズ間で情報を安全に運ぶ」守りの技術だったのに対し、蒸留は同じ技術の攻めの使い方です。運ぶのは「何が決まったか」ではなく、「なぜうまくいったのか」。そしてこれが、引き継ぎよりはるかに難しいのです。

みんな自己流でやっている、そして大体失敗している

蒸留の素朴なやり方は「今までの指示をまとめて、次回から使えるプロンプトにして」と頼むことです。ほとんどの人がこれをやったことがあり、そして多くの人が同じ経験をしています。出てきたプロンプトを新しいチャットで使うと、「あれ、なんか違う」。

なぜこうなるのか。蒸留には、第5回の引き継ぎにはなかった固有の罠が3つあります。

罠①：うまくいった要因は、会話のどこにも書かれていない。 30往復の末の良い挙動は、あなたの明示的な指示だけの産物ではありません。途中の失敗例へのダメ出し、暗黙に蓄積した文脈、偶然の言い回し——コンテキスト全体の合成物です。「指示をまとめて」と頼むと、モデルは明示的な指示だけを拾い、暗黙の要因を落とします。「なんか違う」の正体はこれです。

罠②：モデルは「効いている要因」を内省できない。 ならば「なぜ今のあなたは良い出力をするのか、要因をプロンプト化して」と頼めばいいのでは？　残念ながら、これで返ってくるのは**「もっともらしい要因の説明」であって、実際に効いている要因の特定ではありません**。attentionの中で何が効いているかを、モデル自身は観測できないからです。第1回のポチョムキン理解——「説明できること」と「実際にそうであること」の乖離——の再来であり、第4回の言葉で言えば「効いてそうな要因を、それらしく生成しているだけ」の可能性が常にあります。

罠③：蒸留プロンプトは検証されないまま配布される。 個人で使う分にはまだ被害は小さいですが、チームに配布した瞬間、「本当に元の挙動を再現できているか」を誰も検証していない資産が量産され始めます。これは第7回（Project化の罠）・第8回（GPT化の罠）で扱う問題への直接の入り口です。

学術的な裏付け：研究の世界でも「要約」は「抽出」に負けている

実は、プロンプト圧縮は学術的にも活発な研究分野で、そこでの結論が第5回の「原文ママ戦略」と綺麗に一致しています。

MicrosoftのLLMLingua-2は、プロンプト圧縮を「要約」ではなくトークン分類問題——各単語を「残す／削る」の2値分類——として定式化しました。理由は明確で、生成的な要約（abstractive）ではハルシネーションが混入し、元のプロンプトへの忠実性が保証できないからです。抽出（extractive）なら原文の単語しか残らないため、少なくとも捏造は起きません。また、プロンプトを学習済みベクトルに圧縮するソフトプロンプト系の手法は、意味の歪みが起きやすいことが指摘されています。

「生成的な圧縮は歪む、抽出的な圧縮は歪みにくい」——第5回で見た「マスキングが要約に勝つ」現象、そして機構①（分布の重心への回帰）の話と、完全に同じ構造です。この原則を、蒸留の設計にも一貫して適用していきます。

フェーズ理論で整理する：真の難所は「振り返りフェーズ」

第3回で紹介した「フェーズごとにチャットを切る」運用を、蒸留を組み込んだ形に拡張すると、AIとの共同作業は次の5フェーズに整理できます。

学習フェーズ：AIに背景・資料を読み込ませる
ユーザーとの調整フェーズ：試行錯誤しながら出力の質を上げていく
成果物提出フェーズ：確定した成果物を出す
振り返りフェーズ：何が効いたのかを特定する ← 真の難所
プロンプトフェーズ：特定された要因をプロンプト資産に梱包する

蒸留は4と5に対応しますが、5は"梱包"でしかなく、勝負は4で決まります。そして罠②がある以上、4を「振り返って、何が良かったか教えて」という内省として実施するのは悪手です。「自分に何が効いたか、自分に聞く」——これは第1回のポチョムキン理解が最も発生しやすい構図そのものです。

だから4は、**「内省させるフェーズ」ではなく「会話の中の観測可能な事実を機械的に拾い出すフェーズ」**として設計し直します。

発想の転換：「言った内容」ではなく「行動が変わった瞬間」を拾う

1〜3フェーズの会話履歴には、2種類の情報が混在しています。

あなたが指示したこと全部
その指示の後、AIの出力が実際に変わったこと

失敗する振り返りは、前者を拾います。しかし前者には「指示したのに無視された・効かなかった指示」が混ざっており、逆に「明示的に指示していないのに、なぜか良くなった瞬間」（暗黙の文脈の蓄積）は前者からは拾えません。

拾うべきは後者——**「フィードバックの直後に、出力の質が観測可能に変わった箇所」**です。これなら「言ったかどうか」ではなく「効いたかどうか」を基準に絞り込めます。第5回のStep1（要素分解）が「言及頻度」で重要度を測ったのに対し、蒸留では「行動変化の有無」で測る。これが質的な違いです。

嬉しいことに、この設計は確立された学術手法にそのまま対応づけられます。

Instruction Induction（Honovich et al.）：「入力→出力」ペアから、その変換を説明する指示文を逆算する手法
APE（Automatic Prompt Engineer, Zhou et al. 2023）：候補指示を複数生成し、実際に実行させてスコアで評価し、最良のものを選ぶループ。24個中24個の指示誘導タスクで、人間が作ったプロンプトに匹敵・凌駕する結果を出しています
OPRO（Yang et al. 2024, Google DeepMind）：過去の試行の履歴（どの指示がどう評価されたか）をメタプロンプトに含めて、次の改善案を生成させる最適化手法

以降のStep A〜Cは、この3つの手動実装です。

Step A：Instruction Induction ― BEFORE/AFTERから候補指示を逆算する

調整フェーズが終わったチャットで実行します。

1〜3フェーズの会話を時系列で確認し、以下のパターンに該当する箇所を
BEFORE/AFTERのペアとして抽出してください。

パターン:「私(ユーザー)の指摘・修正の直後に、あなたの出力の傾向が
明確に変化した箇所」

各ペアについて:
- BEFORE: 修正前の出力(該当箇所をそのまま引用、要約しない)
- 私の指摘: 実際の発言をそのまま引用
- AFTER: 修正後の出力(該当箇所をそのまま引用)
- ペアID: PAIR-001など

単に「私が何かを指示した」だけの箇所(その後の出力に変化が確認
できないもの)は除外してください。逆に、私が明示的に指示していない
のに、途中から自然と出力の傾向が変わった箇所があれば、それも
「暗黙の変化」として別途拾ってください。

次に、各ペアについて「BEFOREからAFTERへの変化を、最初の指示だけで
再現するには、どう書いておけばよかったか」を1文で推測してください
(これを"候補指示"とします)。この推測はまだ仮説であり、確定した
ルールではないことを明記した上で出力してください。

設計意図は3つ。引用ベース（第5回の原文ママ戦略の継承）、変化ベースのフィルタ（効いていない指示を最初から除外）、そして**「仮説であることを明記させる」**——ここでモデルに自信満々に断定させないことで、次のStep Bでの検証が"確認作業"として機能します。

Step B：APEループ ― 候補を実際に実行させて選別する

罠②の帰結として、候補の正しさは説明では検証できません。実行でしか検証できません。新しいクリーンなセッションで、候補を入れた場合と抜いた場合の出力を比較します。機械学習で言うアブレーション（要素を1個ずつ抜いて効果を測る）です。

(新しいクリーンなセッションで実行。1〜3フェーズとは別のチャット)

以下は、過去の試行錯誤から抽出した「候補指示」のリストです。

候補指示リスト:
{PAIR-001〜PAIR-Nの候補指示を箇条書きで}

これらを全て含めた指示のもとで、次の新しいタスクを実行してください。
新しいタスク: {1〜3フェーズと同種だが、初めて見る課題}

出力後、続けて以下を自己申告してください:
- 各候補指示が、出力のどの部分に具体的に反映されたか
- 反映が確認できなかった候補があれば、その番号を明記

続けて、疑わしい候補を1つ抜いた条件でも同じタスクを実行し、出力を人間が見比べます。抜いても出力が変わらなければ効いていなかった候補として除外、明確に変わったら因果関係が実証された成分として正式採用です。

自己申告のチェックも人間が行います。「反映した」と申告しているのに実際の出力に反映が見えないケースは、第4回のメタ迎合（監査を通すための空申告）そのものなので、申告を鵜呑みにしないことが重要です。

実務上の注意を2つ。 第一に、候補が10個あれば理屈上10回のテストが要りますが、全部やるのは重い。優先すべきは「丁寧に書いて」のような一般的な指示ではなく、"一見どうでもよさそうなのに何度も言った特殊な指摘"です。地味な指示ほど、実は効いている本命だったりします。第二に、1個ずつ抜くアブレーションは「AとBが両方揃って初めて効く」という相互作用効果を見逃します。チーム配布するような重要な蒸留では、怪しい組み合わせをペアでも試す価値があります。

Step B拡張：プロンプトは日本語で書くべきか、英語で書くべきか

蒸留プロンプトは何度も使い回す資産なので、ここで一度立ち止まる価値のある問いがあります。「AIが識別しやすい言語で書いた方が強いのでは？」

実はこれ、**「英語ピボット仮説」**という、れっきとした研究テーマです。複数の研究（Wendler et al. 2024、Schut et al. 2025など）が示しているのは、英語データが訓練の大半を占めるモデルは、非英語の入力を処理するとき、中間層で一度英語的な表現に変換してから推論し、出力言語に戻すという挙動です。英語89%で訓練されたLlama-2では、フランス語→英語→中国語という内部迂回が観測されており、この処理様式は「Multilingual Workflow仮説」として定式化されています。

これが成り立つ場合、日本語で複雑な指示を書くと、内部の"見えない翻訳"の過程でニュアンスが失われる可能性があります。第5回で扱った「生成を経由すると劣化する」の最も深いバージョンです——モデル内部で起きる暗黙の変換も、根っこは同じ生成プロセスだからです。

ただし、これは全モデル共通の性質ではありません。 同じ研究群が示す重要な留保があります。

日本語で継続事前学習されたSwallowやLLM-jpは、英語ではなく日本語をデフォルトの内部言語にする
バランスよく多言語訓練されたモデルは英語依存度が下がる（Aya-23の英語活性化は約50%で、Gemma-2-27Bの約70%より低い）
Anthropicの解釈可能性研究（Lindsey et al. 2025）では、Claude 3.5 Haikuに言語に依存しない概念表現が見つかっており、「英語に変換してから考える」とは別の、言語をまたいで共有される処理空間の存在が示唆されている

つまり「AIは内部で英語で考えている」は、英語偏重モデルには強く当てはまるが、普遍的ではない。使っているモデル次第です。

一方、ピボット仮説とは独立に、英語には実務的なメリットが1つ確実にあります。トークン効率です。日本語は同じ意味内容を表すのに英語よりトークン数を消費しやすく（第3回の「圧縮バジェット」を思い出してください）、何度も使い回す蒸留プロンプトでは、この差が毎回のコストとコンテキスト消費に効いてきます。

では結論はどうするか。思い込みで決めず、Step Bの枠組みでそのまま検証します。 「どちらの言語が元の意図を忠実に再現するか」は、まさにアブレーションテストの対象にできるからです。

(新しいクリーンなセッションで、2条件を別々に実行)

【条件A】候補指示リストを日本語のまま使って、新しいタスクを実行
【条件B】候補指示リストを英語に翻訳してから、同じ新しいタスクを実行

同一の評価基準で両方の出力を比較し、BEFORE/AFTERペアで確認された
"再現したい変化"が、どちらでより忠実に再現されているか判定してください。

モデルとタスクの組み合わせによって結果は変わりうるので、一般論で断定するより、言語選択そのものをA/Bテストの変数に組み込む——これがこの連載らしい着地です。

Step C：OPROループ ― 効かなかった候補を、失敗の履歴ごと再挑戦させる

Step Bで「反映されなかった」候補が出たとき、1回で諦めるのはもったいない。候補指示の書き方が悪かっただけで、変化自体は本物かもしれないからです。ここでOPROの核心——過去の試行の履歴を見せて、次の候補を出させる——を輸入します。

先ほどの候補指示のうち、PAIR-003は出力に反映されませんでした。

元のBEFORE/AFTERペアをもう一度確認してください:
{PAIR-003のBEFORE/AFTER/私の指摘}

先ほどの候補指示「{Step Aで出した候補文}」では再現できなかった
という結果を踏まえて、この変化を再現できる、より具体的な候補指示を
再度考えてください。前回との違いを明記してください。

当てずっぽうの再試行ではなく、軌跡を踏まえた改善になるのがポイントです。改善案が出たら、再びStep Bのアブレーションにかけます。

それでも言語化できないものは、無理に言語化しない

Step A〜Cを回しても、どうしても指示文への言語化に失敗する候補が残ることがあります。ここで押さえておきたい研究知見があります。指示文（instructions）に言語化して渡すより、具体例（exemplars）をそのまま渡した方が性能が良いケースがある——「教える（teach）」か「見せる（show）」かの比較で、後者が勝つ場合があるのです。

だから、OPROループを2〜3周しても再現できない変化は、無理に指示文へ落とし込まず、該当するAFTERの実例そのものを、蒸留プロンプトにfew-shot例として生で埋め込みます。

# 出力例(この文体・粒度を再現すること)
以下は過去に承認された出力の実例です。指示で表現しきれない
文体・構成・粒度は、この実例に合わせてください。

【実例1】
{Step Aで抽出したAFTERの該当箇所を、一字一句そのまま貼る}

これは第5回の「原文ママ戦略」の精神の帰結です。言語化できないものは、言語化せず実例のまま運ぶ。要約も抽象化も、生成という劣化経路を経由します。実例のコピペは経由しません。

完成形：蒸留プロンプトのテンプレート

Step A〜Cを通過した成分を、次の形に梱包します（フェーズ5）。

# 蒸留プロンプト: {タスク名}  (v1.0 / 蒸留元: {元チャットの識別情報})

## 検証済み指示 (Step Bで効果を実証済み)
- {実証された候補指示1} [PAIR-001由来]
- {実証された候補指示2} [PAIR-004由来]

## 出力実例 (言語化不能な要素はこちらで再現)
{few-shot実例}

## 未検証・暫定 (効果未実証。使用時は注意)
- {アブレーション未実施の候補} [PAIR-007由来・未検証]

## 蒸留メタ情報
- 検証タスク: {Step Bで使ったタスクの種類}
- 検証日: {日付} / 検証モデル: {モデル名}
- 言語A/Bテスト結果: {日本語/英語/未実施}

「検証済み」と「未検証」を分けて明記するのは、罠③（検証されないまま配布される）への直接の対策です。由来ID（PAIR-XXX）を残すのは第5回と同じ発想で、後から「この指示、本当に要るんだっけ？」と疑ったときに元のBEFORE/AFTERまで遡れる導線を確保するためです。検証したモデル名を書くのは、蒸留プロンプトの効果はモデル依存であり、モデルが変われば再検証が必要になるからです。

まとめ

Prompt Distillationは「うまくいった会話」から「なぜうまくいったか」を抽出して資産化する、引き継ぎ（第5回）の攻めバージョン
素朴な「指示をまとめて」が失敗する理由は3つ：効いた要因は明示的に書かれていない、モデルは効いた要因を内省できない（ポチョムキン理解の再来）、検証されないまま配布される
研究の世界でも「生成的な要約は歪み、抽出は歪みにくい」（LLMLingua-2）——第5回の原文ママ戦略と同じ結論
振り返りフェーズは「内省」ではなく「観測」：**指摘の直後に出力が変わった箇所（BEFORE/AFTER）**だけを拾う
候補の実証は説明ではなく実行で：Instruction Induction（候補逆算）→APEループ（アブレーション）→OPROループ（失敗履歴つき再挑戦）
プロンプトの言語（日本語/英語）は思い込みで決めず、A/Bテストの変数に組み込む。英語ピボット仮説は実在するがモデル依存であり、トークン効率の差は確実に存在する
言語化しきれない要素は、無理に指示化せず実例（few-shot）のまま運ぶ
蒸留プロンプトには検証済み/未検証の区別・由来ID・検証モデル名を必ず残す

次回は、この蒸留プロンプトをチームで使い回そうとしたときに待っている落とし穴、Project化の罠を扱います。「よくできたプロンプトを共有すれば、みんなが同じ品質を出せる」——その前提、実は崩れています👀

参考文献

Pan, Z., et al. (2024). LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression. Microsoft. arXiv:2403.12968
Zhou, Y., et al. (2023). Large Language Models Are Human-Level Prompt Engineers (APE). arXiv:2211.01910
Yang, C., et al. (2024). Large Language Models as Optimizers (OPRO). Google DeepMind. arXiv:2309.03409
Honovich, O., et al. (2023). Instruction Induction: From Few Examples to Natural Language Task Descriptions.
Wendler, C., et al. (2024). Do Llamas Work in English? On the Latent Language of Multilingual Transformers. arXiv:2402.10588
Schut, L., Gal, Y., & Farquhar, S. (2025). Do Multilingual LLMs Think in English?
Lindsey, et al. (2025). Anthropic interpretability research on language-agnostic conceptual representations in Claude 3.5 Haiku.