コンテキストエンジニアリング
プロンプトエンジニアリングは、選ぶ言葉に関するものです。コンテキストエンジニアリングは、モデルに手渡すワークスペースに関するものです — 中に何があるか、どんな順序か、そして意図的に何を外したか。
この区別が重要なのは、コンテキストウィンドウがメモ帳ではないからです。それは限られた、高価な、注意のリソースです。どう埋めるかが、モデルが何に集中するか、いくらかかるか、そしてセッションが大きくなっても有用であり続けるかを変えます。
コンテキストの予算
すべてのモデルには最大コンテキストサイズがあります — トークンで測られる厳格な上限です。それを予算と考えてください。あなたはそれを次のものに費やします。
- システムプロンプトと常設の指示
- 検索した文書、コードベースの断片、ツール定義
- 会話履歴
- モデルの出力(マルチターンのセッションでは、これもウィンドウに対してカウントされる)
使い切ると、何かを犠牲にしなければなりません。古いコンテンツが落とされるか、セッションが壁にぶつかるかです。
ほとんどの初心者向けガイドは、コンテキストウィンドウを「多いほど良い」と扱います。コンテキストエンジニアリングは、それを慎重に配分するリソースとして扱います。関連しそうなすべてではなく、このターンでモデルが実際に必要とするものに費やすのです。
コンテキストの腐敗と「ロスト・イン・ザ・ミドル」
長コンテキストのLLMには、よく文書化された現象があります。モデルはコンテキストの冒頭と末尾近くのコンテンツに不釣り合いに注意を払い、中央に埋もれたコンテンツの想起は劣化します。この効果を研究した研究者たちは、これを「ロスト・イン・ザ・ミドル(中央で迷子)」と呼びました。
実用上の帰結はこうです。10万トークンのコンテキストを文書で詰め込み、最も重要な指示を位置60,000に埋めると、モデルは事実上それを無視するかもしれません — そこまで読めないからではなく、注意がウィンドウ全体に均等に分布していないからです。
「コンテキストの腐敗」はより広いパターンです。セッションが大きくなるにつれて、応答の質はずれていく傾向があります。初期の指示は薄まります。繰り返されるやり取りが元のタスクを押しのけます。モデルは曖昧な言い回しを始め、同じことを繰り返し、あなたが実際に求めたものの筋を見失っていきます。
これらは、より良いプロンプトで完全に直せるバグではありません。大規模な注意の働き方の構造的な性質です。エンジニアリング的な対応は、コンテキストを詰め込んで願うのではなく、より小さく鋭く保つことです。
順序が重要
コンテンツをどこに置くかは、何を含めるかと同じくらい重要です。確立された良い慣行はこちらです。
| 位置 | そこに置くもの |
|---|---|
| 最上部(システムプロンプト) | 安定した、耐久性のある指示。ペルソナ、ルール、フォーマット要件。 |
| システムプロンプトの後 | 現在のタスクを、平易な言葉で。 |
| 最後のユーザーターンの直前 | この正確なリクエストにとって最も重要で具体的なコンテキスト。 |
| 中央 | 補助的な文書、検索したチャンク — 時系列ではなく関連度順に並べる。 |
| 会話履歴 | 継続に必要なものだけ。積極的に刈り込む。 |
一般則。現在のターンに近いほど、より多くの注意を得ます。長い履歴の中央にだけ存在する重要な指示は、危険にさらされています。
詰め込みより検索
すべてを入れたくなる誘惑があります。すべてのドキュメント、コードベース全体、会話のすべて。抗いましょう。
より良いアプローチは選択的な検索です。この特定のリクエストにモデルが実際に必要とするものを特定し、それだけを注入するのです。適切に検索された正しい文書の2,000トークンのチャンクは、答えが中央のどこかにある40,000トークンの放り込みを上回ります。
これが、検索拡張生成(RAG)が存在する理由です — 単にコンテキストの制限を乗り越えるためだけでなく、コンテキストを厳選された状態に保つことで質を高めるためです。
対話的なセッションでも、同じ論理が当てはまります。すべてを蓄積するのではなく、現在のタスクにもはや関連しないコンテンツを取り除くため、定期的に履歴を圧縮または消去するのです。Claude Codeの/compactと/clearコマンドは、単なるセッション管理ではなく、コンテキストエンジニアリングの道具です。
コストの観点
送るトークンは、支払うトークンです — お金とレイテンシーの両方で。緩く関連するだけの素材でコンテキストを詰め込むと、その両方が膨らみます。コンテキストエンジニアリングとコスト効率は、同じ問題です。
より具体的には。
- テンプレートからコピー&ペーストした肥大したシステムプロンプトは、一回一回の呼び出しで支払われます。
- 「役立つかもしれない」と思って持ち越す古い会話履歴は、一回一回の呼び出しで支払われます。
- 「念のため」に注入する文書は、一回一回の呼び出しで支払われます。
そこにある必要のないものを削ぎ落とすことは、質にとってより良く、同時に運用が安くなります。
Claudeユーザーのための実践的な戦術
Claude.aiで:
- 異なるタスクには異なる会話を使う。脱線だらけの午後が、集中したプロジェクトのコンテキストを汚染させないように。
- それに依存する複雑な質問をする前に、長いスレッドを要約する。明示的な要約は、生の履歴よりも有用なことが多いです。
- 欲しい具体的なものを、長いメッセージの中央に埋めるのではなく、末尾に置く。
Claude Codeで:
CLAUDE.mdファイルを引き締めて保つ。その中の各行はすべてのセッションに注入されます。CLAUDE.mdとコンテキスト管理を参照してください。- 本当に別のタスクに切り替えるときは
/clearを使う。続けたいがセッションが大きくなっているときは/compactを使う。 - 現在のステップに完全なファイルが必要ないときは、内容を貼り付けるのではなくパスでファイルを参照する。
APIレベルで:
- システムプロンプトは、すべてのリクエストが本当に必要とするものだけを含むように設計する。タスク固有の指示はユーザーターンへ移す。
- 文書の多いユースケースでは、コーパス全体をアップロードするのではなく、関連するチャンクを検索して注入する。
- 安定した再利用可能なプレフィックスが最初に来るようプロンプトを構成する — これはプロンプトキャッシュも可能にし、コンテキストエンジニアリングの自然な相棒となります。
考え方の転換
プロンプトエンジニアリングはこう問います。「何を言うべきか?」 コンテキストエンジニアリングはこう問います。「モデルは何を見るべきか、どんな順序で、そして私は意図的に何を外すべきか?」
2つ目の問いのほうが難しいですが、大規模での質を実際に決めるのはこちらです。