Andrej Karpathyはそれを率直に言いました：「プロンプトエンジニアリング」は誤解を招く言葉です。それは、言語モデルとの作業の技術が慎重に指示を言葉で表現することにあると示唆しています。正しい出力を引き出す魔法の文を書くことだと。このフレームは常に本当の作業を過小評価してきました。そして2026年には、それは真剣なAIチームが実際に行っていることをもはや説明していません。

彼らが行っているのはコンテキストエンジニアリングです：推論時にLLMのコンテキストウィンドウを占めるための、適切な情報を適切な時間に適切な形式で構築する意図的かつ体系的な実践です。それはリトリーバル、メモリ管理、システム設計、そしてUXの一部です。プロンプトではありません。そして、それをプロンプトのように扱うチームは、モデルの能力のほとんどを使いこなせていません。

なぜ「プロンプトエンジニアリング」は常に間違ったフレームだったのか

「プロンプトエンジニアリング」というフレーズはGPT-3時代の直感から来ています：モデルは不透明で、正しい言い回しが隠れた能力を引き出し、スキルは本質的に呪文のようなものでした。正しく呪文を書けばモデルが機能しました。

その思考モデルは3つの理由で崩壊しました：

コンテキストウィンドウが拡大した。モデルが4Kトークンだったとき、プロンプトは短かった。128K、200K、そして1M+トークンでは、ウィンドウに入れるものはシステム設計の問題であり、文章の問題ではありません。
システムが動的になった。現代のAIアプリケーションは静的なプロンプトを使いません。ドキュメントを取得し、ツールを呼び出し、セッション間でメモリを維持し、中間結果を処理します。「プロンプト」は実行時に多くのソースからアセンブルされます。
シグナルが移動した。実証的に、チーム間の最大のパフォーマンスのギャップはプロンプトの言い回しではなく、コンテキストの品質から来ています。より良いコンテキストを持つ同じモデルは、貧弱なコンテキストを持つより大きなモデルを一貫して上回ります。

コンテキストの6つの層

コンテキストエンジニアリングとは、推論時にモデルのコンテキストウィンドウを占める可能性がある6つの異なるコンポーネントについて意図的に考えることを意味します：

コンテキストエンジニアリングの6つの層

層1 — システムプロンプトと指示。役割定義、タスクの制約、出力フォーマットの仕様、ツールスキーマ。固定で比較的小さく — 通常は予算の5〜10%。
層2 — Few-shotの例。フォーマット、トーン、エッジケースの処理を固定する入力/出力デモンストレーション。良いfew-shotは精巧な指示段落よりも信頼性の高い作業を行います。
層3 — ワーキングメモリ/状態。エージェントのスクラッチパッド：中間推論、タスクの進捗、構造化出力スキーマ。この層はタスク中に成長し、アクティブな管理が必要です。
層4 — 取得されたドキュメント（RAG）。推論時に取得された外部知識：ベクトル検索結果、データベースルックアップ、コードベースのスニペット、リアルタイムデータ。
層5 — ツールとアクションの結果。APIコール、コード実行、検索、その他のツール呼び出しの出力。多くの場合冗長で、切り捨てや要約が必要です。
層6 — 会話履歴。前のターン、要約されたメモリ、永続化されたユーザー設定。長い会話には圧縮戦略が必要です。

重要なインサイト：「プロンプト」は最良の場合でも層1にすぎません。コンテキストエンジニアリングは、有限のトークン予算内で6つすべての層を同時に管理する実践です。

コンテキストの品質がモデルのサイズに勝る

コンテキストエンジニアリングの文献で最も実践的に重要な発見は、最も直感に反するものでもあります：よく設計されたコンテキストを持つ小さいモデルは、貧弱なコンテキストを持つ大きいモデルを日常的に上回ります。

より良いコンテキストは大きなモデルに勝る — タスク成功率の比較

これは複数のベンチマークで示されています。コード生成タスクでは、慎重にキュレートされたfew-shotと関連するコードベースコンテキストを持つGPT-4oが、一般的なシステムプロンプトを与えられたo3を上回ります。エンタープライズRAGデプロイメントでは、ナイーブなフルドキュメント取得からセマンティックチャンキング+リランキングへの切り替えが、モデルのアップグレードよりも大きな精度向上をもたらします。

「私たちは3ヶ月間、さまざまなモデルを試すことに費やしました。コンテキスト品質への1スプリントで、四半期間追い続けていたのと同じ成果が得られました。」— Hacker Newsの開発者

コンテキスト予算：トークンを有限リソースとして扱う

コンテキストエンジニアリングで最も有用なメンタルモデルの転換は、トークンを予算として扱うことです。コンテキストウィンドウは希少なリソースです。入るものは何かを押しのけます。

本番システムで繰り返し現れる予算管理テクニック：

階層的なリトリーバル

完全なドキュメントを取得しないでください。2段階のパイプラインを使用してください：高速で安価なリトリーバルモデルが候補を選択し、クロスエンコーダーのリランカーが最も関連性の高いパッセージを選択します。トップ5のリランクされた結果は通常、ナイーブなトップ20の取得よりも多くのシグナルを含んでいます。

プログレッシブ要約

会話履歴と中間状態は管理されないと無制限に成長します。本番パターンは閾値後に要約することです — 通常、各Nターン後、または履歴がXトークンを超えたとき。

動的few-shots

200のサンプルライブラリがある場合、現在の入力に最も意味的に類似した3〜5を取得します。このテクニック — リトリーバル強化few-shot選択 — は最も高いレバレッジのコンテキスト最適化の1つです。

リトリーバル品質の問題

チャンク境界エラー

固定サイズのチャンキングは、意味的に一貫したパッセージをチャンク間で分割し、半答えを返すことがよくあります。ドキュメント対応チャンキング（セクション境界、段落、または意味的単位での分割）は固定サイズのチャンキングを一貫して上回ります。

取得されたチャンクのコンテキスト欠如

Anthropicの「コンテキスト的リトリーバル」技術は、インデックス作成時に各チャンクにチャンク固有のコンテキスト要約を付加します。ベンチマークでは、リランキングと組み合わせてリトリーバルの失敗を49%削減しました。

クエリとドキュメントの不一致

HyDE（Hypothetical Document Embeddings）は、生のクエリを埋め込む代わりに、クエリへの仮想的な回答を生成してそれを埋め込むことでこれに対処します。

最初に何を構築するか

リトリーバルパイプラインを監査する。固定サイズのチャンクからセマンティックまたはドキュメント対応のチャンクに切り替えます。リランキングステップを追加します。
会話要約を実装する。会話履歴をトークン制限にキャップし、超過したときに要約します。
動的few-shotリトリーバルを追加する。高品質の例の小さなライブラリを構築します。推論時に現在の入力に最も類似したトップ3を取得します。
エージェントの状態を外部化する。マルチエージェントシステムを構築している場合は、最初から中間状態を構造化された外部ストアに移動します。
コンテキスト品質を計測する。コンテキストウィンドウと結果のロギングを追加します。

より深いポイント

コンテキストエンジニアリングは技術ではありません。それは視点の転換です：言語モデルを指示に応答するテキストジェネレーターとして扱うことから、実行時に提供される情報の品質によってパフォーマンスが制限される推論エンジンとして扱うことへの転換です。

チームが達成していることと可能なことの間のギャップは、ほぼ常にコンテキストのギャップです。そのギャップはエンジニアリングの問題です。そしてすべてのエンジニアリングの問題と同様に、体系的な投資に応答します。

呪文は決して言葉ではありませんでした。それは常にその背後にある情報でした。