プロンプトは「長くする」時代から「短くして強くする」時代へ — ESPOが示したプロンプト最適化の新常識

「プロンプトを改善し続けていたら、いつの間にか最初の3倍の長さになっていた」——LLMを業務に組み込んでいるチームなら、一度は経験する現象ではないでしょうか。失敗ケースが出るたびに条件を追記し、例外ルールを足し続けた結果、プロンプトは肥大化し、トークンコストは膨れ上がっていきます。

問題は、それだけではありません。長いプロンプトはコストを増やすだけでなく、精度そのものを下げることが研究で明らかになっています。

EMNLP 2026に採択された「ESPO」は、この矛盾に正面から取り組んだ手法です。7つのNLPベンチマークで平均精度を**+3.76ポイント改善しながら、プロンプト長を47%削減**する——その両立をどう実現したのかを、実務目線で解説していきます。

結論ファースト｜ESPOの要点を3分で

ESPOとは何か

**ESPO（Error-Structured Prompt Optimization via Diagnose, Diversify, and Stabilize）**は、Lihao Liuらが開発した自動プロンプト最適化フレームワークです。名前の通り、エラーを「構造」として捉え、診断・多様化・安定化の3段階でプロンプトを改善していきます。

数字で見るインパクト

指標	ESPO	既存手法
平均精度	74.67%	70.91%
精度改善幅	+3.76ポイント	ベースライン
プロンプト長	1,004文字	1,878文字
削減率	▲47%	—

従来手法の多くは「精度か、短さか」のトレードオフを抱えていました。ESPOはそれを同時に達成した点が最大の新規性です。検証は7つのNLPベンチマーク × 4つのLLMという幅広い条件で行われており、特定モデルへの依存もありません。

そもそもの課題 — 「プロンプト膨張」とは何か

自動プロンプト最適化が陥る悪循環

GEPAやOPROに代表される反復型プロンプト最適化の基本メカニズムはシンプルです。「失敗例を見つけ、その対処ルールを追記し、また評価する」——このサイクルを回すことで精度を向上させていきます。

ところがこのアプローチには、「削る」インセンティブが設計に組み込まれていないという根本的な欠陥があります。失敗するたびに何かを追加することはあっても、既存のルールを削除・置換する判断はほとんど生まれません。結果として、プロンプトは反復のたびに太り続け、最終的には初期の3倍の長さに達することもあります。

膨張の実害①：コストとレイテンシの悪化

長くなったプロンプトは、毎回のAPIコール時にそのまま送信されます。プロンプト長が3倍になれば、トークンコストも単純に膨れ上がります。高頻度で呼び出すシステムや、エージェント型ワークフローでは、この影響は特に顕著です。レスポンス速度の悪化はUXにも直結します。

膨張の実害②：長いほど精度が落ちる「Lost in the Middle」

より深刻なのは、精度への影響です。スタンフォード大学の研究が明らかにした「Lost in the Middle」現象によれば、入力コンテキストが長くなるほどLLMの精度は15〜47%低下します。文脈の中盤に配置された情報が無視されやすくなるためです。

つまり、よかれと思って追加したルールが、文脈の中盤に押しやられることで実質的に機能しなくなる——という「情報を足したのに性能が下がる」という直感に反する落とし穴が生まれます。

コスト増 × 精度劣化——この二重苦こそがESPOが解こうとした問題です。

ESPOの技術的アプローチ — 診断・多様化・安定化の3段階

ESPOが優れているのは、3つの段階がそれぞれ「膨張の異なる原因」に対処する多層防御の構造になっている点です。順を追って理解を深めていきましょう。

ステップ①：診断（Diagnose）— エラーを構造化する

従来手法がやっていたのは、「この入力で失敗した」という失敗事例の羅列でした。ESPOはここを根本から変えます。

訓練データ上のすべてのエラーを構造的なパターンにクラスタリングし、失敗の根本原因を体系化します。個別の失敗事例ではなく、「このタイプの誤りが多い」という抽象化された弱点の集合を特定するのです。

類似した失敗をグループ化することで、修正すべき弱点が少数のカテゴリに集約されます。個別の失敗ごとに対処ルールを足すのではなく、パターンに対して一つの改善を施せばよい——この発想の転換が、追記の量を劇的に減らします。

ステップ②：多様化（Diversify）— 4つの相補的戦略で候補を生成

診断で特定した弱点に対して、ESPOは単一の改善案ではなく、異なるバイアスを持つ4つの戦略で候補プロンプトを独立に生成します。

なぜ複数の戦略が必要なのでしょうか。「同じ方向に改善を重ねること」が膨張の正体だからです。一つの改善方向に収束してしまうと、同じ種類の記述が積み重なっていきます。互いに異なる視点から生成された候補を並べることで、探索空間を広げながらも、冗長な追記を防ぐことができます。

ステップ③：安定化（Stabilize）— ブートストラップ安定性選択

多様化で得た候補の中から、最終的に採用するものを選ぶのが安定化のステップです。ここでESPOが使うのがブートストラップ安定性選択という手法です。

複数のデータサンプルにわたって、「一貫して」良いパフォーマンスを示す候補だけを採用します。一部のサンプルでだけ良い結果が出た「まぐれ当たり」のルールは、ここで弾かれます。

「たまたま効いたルール」が蓄積されないことで、プロンプトは太らずに済みます。これが安定化が膨張を防ぐメカニズムです。

3段階が組み合わさると何が起きるか

診断：無駄な追記を減らす（根本原因のクラスタリング）
多様化：単一方向への収束を防ぐ（探索の広さを確保）
安定化：まぐれ当たりを排除する（採用基準の厳格化）

それぞれの段階が独立して膨張を抑制するため、最終的に得られるプロンプトは「短く、かつ効く」ものになります。

ベンチマーク結果を読み解く

7つのNLPベンチマークでの総合成績

ESPOは、分類（Tweet感情分析）、知識問答（MMLU）、数学的推論（GSM8K）、マルチホップQA（HotpotQA）など、性質の異なる7つのベンチマークで評価されました。特定タスクに特化した数字ではなく、横断的な平均値で**+3.76ポイント**という改善を達成しています。

汎用ベンチマークの平均スコアで3ポイント以上の改善は、実務的には非常に大きな意味を持ちます。単一タスクで極端にチューニングした結果ではないため、実環境でも同様の効果が期待しやすいのです。

47%削減が効いてくる場面

プロンプト長が1,878文字から1,004文字に削減されるということは、毎回のAPIコールで送信するトークンが半分近くになるということです。これが特に効いてくるのは以下のようなシナリオです。

高頻度APIコール：月間数百万回のリクエストがあるシステム
エージェント型ワークフロー：複数ステップにわたってプロンプトを繰り返し送信する構成
長文システムプロンプト：既に数千トークンのコンテキストを持つシステム

削減の効果は「毎回送るトークン」に直接かかってくるため、スケールするほど恩恵が大きくなります。

汎化性能 — 4つのLLMでのクロス検証

検証対象モデルと結果

ESPOは特定のモデルに依存していないことを確認するため、以下の4つのLLMでクロス検証を実施しています。

Gemma 3 12B
Mistral 14B
Qwen3 32B
Claude Haiku

すべてのモデルで、既存手法を上回る結果を達成しています。

最も劇的だったケース：Qwen3 32B × GSM8K

特筆すべきは、Qwen3 32BをGSM8K（数学推論ベンチマーク）で評価した結果です。精度が**15.00%から91.40%**へと約6倍の向上を記録しました。

この結果が示唆するのは、モデル自体が持っている能力をプロンプトの構造が阻害していた可能性です。不適切なプロンプト設計が「足かせ」になっていたところを、ESPOが外したと解釈できます。

注意: 単一の劇的なスコアは条件依存の可能性があります。実務での判断には、7タスクの平均値である+3.76ポイントを基準にすることをお勧めします。

「特定モデル依存でない」ことが実用性の鍵

実務の観点では、モデル依存がないことは非常に重要です。コスト要件やパフォーマンス要件に応じてモデルを切り替えても、ESPOで最適化したプロンプト設計の資産を活かし続けることができます。ベンダーロックインを避けたいチームにとって、これは大きなメリットです。

他のプロンプト圧縮・最適化手法との比較

「圧縮」と「最適化」は別の技術である

まず整理しておきたいのは、アプローチの違いです。

LLMLingua系のツールは、推論時にコンテキストを動的に圧縮する手法です。送るプロンプト自体を変えるのではなく、長い入力をリアルタイムで短縮することを目的としています。

ESPOは、プロンプトそのものを設計し直す手法です。最適化のプロセスで「最初から短くて効くプロンプト」を生成します。

この2つは併用可能です。ESPOで最適化した後のプロンプトにLLMLingua系の圧縮を適用すれば、さらなるコスト削減が期待できます。

どの手法を選ぶべきか

優先事項	推奨手法
レイテンシ最小化が最優先	LLMLingua-2
QA特化で圧縮率を最大化したい	LongLLMLingua
精度とコストを同時に改善したい	ESPO
既にESPOで最適化 + さらに削減したい	ESPO + LLMLingua-2の併用

実務での活かし方 — ESPOの発想を今日から応用する

ESPOのコードが公式に公開されるのを待たなくても、その発想は今日から取り入れることができます。

論文実装を待たずにできること

1. エラーログを「分類」する 失敗例を列挙するのではなく、原因パターンでグルーピングする習慣をつけましょう。「数値計算を間違えた」「文体が違う」「条件を見落とした」という分類が、次の一手を明確にします。

2. 追記より「書き換え」を優先する 新しいルールを足す前に、既存のルールで対応できないか必ず確認してください。「追記ゼロで改善できた」が理想的なアウトカムです。

3. 複数案を並行生成する 1つの改善案に飛びつかず、方向性の異なる案を3〜4つ作って比較する習慣をつけましょう。「同じ方向への改善の積み重ね」がプロンプト膨張の正体です。

4. 複数サンプルで再現性を確認する 1回の評価で採用しない。5〜10件のテストケースにわたって一貫して改善が見られる変更だけを本番に採用する「安定化フィルター」を設けましょう。

プロンプト長の"健康診断"チェックリスト

自社プロンプトの現状を診断するために、以下を確認してみてください。

直近3回の改訂でプロンプト長は何%増えたか
増えた分に見合う精度改善はあったか（記録しているか）
重複・矛盾しているルールはないか
一度も機能していない条件分岐が残っていないか
削っても性能が落ちないルールを検証したか

よくある疑問（FAQ）

Q1. なぜ長いプロンプトは悪いのですか？

トークンコストの直接的な増加に加え、「Lost in the Middle」現象によって精度自体が低下します。情報を増やしたはずなのに性能が下がる、という二重苦が発生します。

Q2. 既存のAPE / OPROと何が違いますか？

ESPOの差別化点は2つです。①失敗例を個別に扱うのではなく「構造的パターン」にクラスタリングして根本原因を特定すること、②ブートストラップ安定性選択によって「まぐれ当たりの改善」を採用しないこと。この2点が膨張を防ぎながら精度を上げる鍵です。

Q3. 自社のプロンプトにも使えますか？

4つの異なるLLMで汎化性能が検証されており、分類・推論・QAなど幅広いタスクに適用可能です。ただし、最適化には一定量のエラーデータと、最適化プロセス自体のLLMコールが必要です。

Q4. 実装コードは公開されていますか？

EMNLP 2026採択論文（arXiv: 2609.04197）であり、コードの公開は今後見込まれる段階です。論文のページを定期的に確認することをお勧めします。

Q5. プロンプト圧縮ツールと併用できますか？

ESPOはプロンプトの「設計」を最適化する手法、LLMLingua系は「送信時の圧縮」を行う手法です。レイヤーが異なるため、ESPOで最適化したプロンプトをさらにLLMLingua-2で圧縮するという組み合わせが自然です。

まとめ｜プロンプト最適化の評価軸を更新しよう

ESPOが提示した成果は、プロンプトエンジニアリングの評価軸そのものを更新するものです。「精度が上がったか」だけでなく、「長さあたりの精度」という視点が不可欠になりつつあります。

ESPOの本質は、特定のアルゴリズムにあるのではありません。**「エラーを個別の失敗として扱うのではなく、構造として捉える」**という発想の転換にあります。この考え方は、コードが公開される前から実務に取り入れることができます。

明日からのアクションを3点に集約します。

エラーログをパターンで分類する — 個別対処から根本原因の特定へ
追記より書き換えを優先する — 「足す」前に「削れるか」を問う
複数サンプルで再現性を確認してから採用する — まぐれ当たりを本番に入れない

プロンプトを「長くする」ことで精度を上げようとした時代は、終わりを迎えつつあります。「短くして強くする」——ESPOはその新しい常識を、数字で証明しました。