なぜプロンプトエンジニアリングの時代は終わったのか
「言い方」から「見せるもの」へ——ゲームが変わった。
職業としてのプロンプトエンジニアリング
2023年、新しい職業が現れた。
プロンプトエンジニア。
「ステップバイステップで考えてください。」 「あなたは20年の経験を持つ専門家です。」 「まずいくつか例をお見せします。」
こうした文が数万ドルの価値を持つノウハウになった。同じ質問でも、言い方によってAIの回答は劇的に変わった。
プロンプトエンジニアリングは本当に効いた。 Chain-of-Thought一行で数学のスコアが20%上がった。 役割を一文付与するだけで専門知識の深さが変わった。 few-shotの例を3つ示すだけで出力フォーマットを完全にコントロールできた。
これは誇大宣伝ではなかった。実際に起きていたことだ。 ではなぜ終わりつつあるのか？
なぜ効いたのか：モデルが十分に愚かだったから
プロンプトエンジニアリングがなぜ効いたかを第一原理から見る。単純だ。
初期のLLMはユーザーの意図を把握するのが下手だった。 「要約して」と言えば書き直す。 「比較して」と言えばリストする。
モデルが意図を読み違えたから、 意図を正確に伝えるスキルが価値を持った。 プロンプトエンジニアリングは本質的に「通訳」だった—— 人間の意図をLLMが理解できる形に翻訳すること。
通訳が価値を持つには、言語の壁がなければならない。
何が変わったか：モデルが賢くなった
GPT-3.5からGPT-4へ。Claude 2からClaude 3.5へ。 世代を重ねるごとに、モデルの意図把握能力は飛躍的に向上した。
「要約して」と言えば要約する。 「比較して」と言えば比較する。 「ステップバイステップで考えて」と言わなくても、複雑な問題を自ら手順に分解する。
言語の壁が低くなった。 通訳の価値が縮小した。
2023年に劇的な差を生んだプロンプト技術は 2025年には限界的な差しか生まない。 モデルが十分に賢ければ、言い方はますます問題にならない。
では何が問題になるのか？
コンテキストウィンドウ：物理法則
LLMには一つの物理的制約がある。
コンテキストウィンドウ。
128Kトークンであれ1Mトークンであれ、有限だ。 この有限な空間に収まった情報だけが推論に影響する。 ウィンドウの外の情報は、いかに重要でも存在しないに等しい。
これはモデルサイズとは無関係だ。 1兆パラメータであっても、コンテキストウィンドウは有限だ。 インターネット全体を訓練データにしても、コンテキストウィンドウは有限だ。
モデルがいかに賢くても、 間違った情報がコンテキストに入れば、間違った答えを出す。 無関係な情報がコンテキストを埋めれば、重要なものを見逃す。 必要な情報がコンテキストにいなければ、知らないのと同じだ。
プロンプトエンジニアリングは「言い方」の問題だった。 新しいゲームは「見せるもの」の問題だ。
これがコンテキストエンジニアリングだ。
アナロジー：オープンブック試験
プロンプトエンジニアリングとコンテキストエンジニアリングの違いを示すアナロジーがある。
プロンプトエンジニアリングは試験問題をうまく作ること。 「以下から正しいものを選べ」ではなく 「以下の条件をすべて満たす答えを段階的に導出せよ」と書けば—— 学生はより良い答えを出す。
コンテキストエンジニアリングはオープンブック試験にどの本を持ち込むかの問題。 試験問題がいくらよくても、 学生が間違った本を持ち込めば答えられない。 持ち込める本の数は限られている。 どの本を持ち込むかが成績を決める。
モデルが愚かなとき、問題の形式（プロンプト）が重要。 モデルが賢いとき、参考資料（コンテキスト）が重要。
エージェント時代が転換を加速する
この転換はエージェントの出現とともに加速している。
プロンプトエンジニアリングは人間が毎回書く。 人間が質問を書き、コンテキストを説明し、フォーマットを指定する。
エージェントは違う。 エージェントは自律的に推論し、ツールを呼び出し、他のエージェントと協働する。 各ステップで、自らコンテキストを組み立てなければならない。
あるエージェントが外部APIを呼び出してデータを受け取った。 このデータを次の推論のコンテキストに入れる必要がある。 どの部分を入れ、どの部分を除くか？ 以前の推論結果のどれを保持し、どれを捨てるか？ 別のエージェントが送った情報は信頼できるか？
人間がこれらの判断を毎回することはできない。 エージェントが自律的に動くには、 コンテキスト組み立てが自動化されなければならない。
プロンプトエンジニアリングは人間のスキルだった。 コンテキストエンジニアリングはシステムの能力でなければならない。
プロンプトエンジニアリングは消えない
誤解を防いでおく。
プロンプトエンジニアリングが無意味になるとは言っていない。 システムプロンプトは依然として重要だ。 出力フォーマット指定は依然として必要だ。 役割と制約の宣言は依然として有効だ。
縮小しているのはプロンプトエンジニアリングが占めるシェアだ。
2023年に出力品質の70%がプロンプトで決まっていたなら、 2025年には30%がプロンプトで、70%がコンテキストで決まる。
比率が逆転した。
そしてこのトレンドは逆行しない。 モデルはますます賢くなり、 賢くなるほど言い方は問題にならなくなり、 コンテキストがますます重要になる。
しかしコンテキストエンジニアリングにはインフラがない
ここが核心だ。
プロンプトエンジニアリングにはツールがあった。 プロンプトテンプレート、プロンプトライブラリ、プロンプトテストフレームワーク。 「言い方」を体系的に管理するエコシステム全体が構築された。
コンテキストエンジニアリングにはまだこれがない。
実際のコンテキスト処理の現場を見てみよう。
RAGパイプラインのチャンクサイズは手動で調整されている。 背景情報は手動でシステムプロンプトに書き込まれている。 エージェントの記憶に何を格納するかは手動で設計されている。 どの検索結果をコンテキストに入れるかは手動で決められている。
すべてが手作業だ。
そしてその手作業の原材料はすべて自然言語だ。 自然言語の文書が自然言語で切り分けられ、自然言語のコンテキストに貼り付けられる。
自然言語は情報密度が低い。 出所がない。確信度がない。タイムスタンプがない。 同じ意味を伝えるのに不要なトークンが消費される。 品質判断を自動化する方法がない。
これはプロンプトエンジニアリング以前の時代に似ている。 プロンプトエンジニアリングも最初は手作業だった。 個人の直感と経験に依存していた。 やがてツールと方法論が現れ、体系化された。
コンテキストエンジニアリングは今、その以前の段階にある。 問題は認識されたが、インフラが存在しない。
インフラに必要なもの
コンテキストエンジニアリングが手作業からシステムに移行するには、 少なくとも以下が必要だ。
**圧縮。**同じウィンドウにより多くの意味を収める方法。 自然言語の文法的接着剤を剥ぎ取り、意味だけを残せば、 有効ウィンドウサイズが倍増する——モデルを変えずに。
**索引。**正しい情報を精密に見つける方法。 エンベディング類似度ではなく意味構造に基づく検索。 「Apple売上高」を検索して「りんごの栄養成分」が出てこない検索。
**バリデーション。**仕様に合わない情報を機械的にリジェクトする方法。 Goコンパイラが未使用変数をエラーとして捕捉するように、 出所のない主張やタイムスタンプのない事実はコンテキストに入る前にフィルタされるべきだ。 最も安価で最も決定論的なチェックが最初に来なければならない。
**フィルタリング。**意味的品質を判断する方法。 バリデーションが形式を見るなら、フィルタリングは内容を見る。 関連性、信頼性、鮮度。この情報はこの回の推論に本当に必要か？
**整合性。**選択された情報セットの内部的一貫性を保証する方法。 個々に良い情報でも、組み合わせると矛盾することがある。 2020年のCEOと2024年のCEOが同時にコンテキストに入ると、 LLMは混乱する。
**構成。**ウィンドウ内の配置と構造を最適化する方法。 同じ情報でも配置場所によって異なる注意重みを受ける。 前に置くか後ろに置くか？グルーピングは？
**蓄積。**システムが時間とともに学び成長する方法。 キャッシングは個々の結果の再利用。 蓄積はどのコンテキスト構成が良い結果を生んだかを学び、 知識ベース自体を成長させること。
これら7つがコンテキストエンジニアリングインフラのフルスタックだ。
これは特定のツールの話ではない
率直に言おう。
誰がこのインフラを構築するかはオープンクエスチョンだ。 一つのツールがすべてを解決するかもしれないし、 複数のツールが各層を担当するかもしれない。
しかしインフラが必要であることはオープンクエスチョンではない。
コンテキストウィンドウが有限であることは物理的事実だ。 ウィンドウが10倍に拡大しても、世界の情報はもっと速く増える。 自然言語の情報密度が低いことは構造的事実だ。 エージェントが自律的に動くには自動化されたコンテキスト管理が必要であることは論理的必然だ。
プロンプトエンジニアリングがツールを必要としたように、 コンテキストエンジニアリングもツールを必要とする。 しかし今回、ツールの性質は異なる。
プロンプトエンジニアリングのツールはテキストエディタに近かった。 コンテキストエンジニアリングのツールはコンパイラに近い。
情報を圧縮し、索引をつけ、バリデーションし、フィルタリングし、 整合性をチェックし、配置を最適化し、結果を蓄積する。 これは編集ではない。これはエンジニアリングだ。
だからコンテキスト「エンジニアリング」と呼ぶのだ。
まとめ
プロンプトエンジニアリングはモデルが愚かなとき価値があった。 モデルが意図を読めなかったから、意図をうまく伝えるスキルが重要だった。
モデルが賢くなるにつれ、ゲームが変わった。 「言い方」から「見せるもの」へ。 プロンプトからコンテキストへ。
エージェントの出現がこの転換を加速する。 人間が毎回コンテキストを組み立てることはできない。 システムが自律的にやらなければならない。
しかし今、コンテキストエンジニアリングにはインフラがない。 自然言語が手作業で切り貼りされている。
必要なインフラには7つの層がある： 圧縮、索引、バリデーション、フィルタリング、整合性、構成、蓄積。
終わりつつあるのはプロンプトエンジニアリングの時代ではない。 終わりつつあるのは、プロンプトエンジニアリングだけで十分だった時代だ。