メインコンテンツまでスキップ
中級

コンテキストエンジニアリング

プロンプトエンジニアリングは、あなたが選ぶ言葉についてのものです。コンテキストエンジニアリングは、あなたがモデルに手渡すワークスペースについてのもの — その中に何があるか、どんな順序になっているか、そして何を意図的に除外したかです。

この区別が重要なのは、コンテキストウィンドウがメモ帳ではないからです。それは限られた、高価な、注意のリソースです。それをどう満たすかが、モデルが何に焦点を当てるか、どれだけのコストがかかるか、そしてセッションが長くなっても有用であり続けるかどうかを左右します。

What you'll learn
  • コンテキストエンジニアリングをプロンプトエンジニアリングと区別し、この分野がなぜ移行したのかを理解する
  • コンテキストウィンドウを保管庫ではなく、注意の予算として扱う
  • コンテキストロットと「中間で迷子になる」現象を、長いセッションを台無しにする前に見抜く
  • 実際に注意が向く場所に指示を置く — 冒頭、末尾、決して中間に埋もれさせない
  • 三つの主力戦術を適用する: 圧縮、メモ取り、そしてジャストインタイム検索

コンテキストの予算​

どのモデルにも最大コンテキストサイズ — トークンで測られる厳格な上限があります。これを予算として考えてください。あなたはそれを次のものに費やします:

  • システムプロンプトと常設の指示
  • 検索されたドキュメント、コードベースの抜粋、ツール定義
  • 会話履歴
  • モデルの出力(マルチターンのセッションではこれもウィンドウに計上されます)

使い切ると、何かを犠牲にしなければなりません。古い内容が削除されるか、セッションが壁にぶつかるかのどちらかです。

ほとんどの初心者向けガイドは、コンテキストウィンドウを「多ければ多いほどよい」ものとして扱います。コンテキストエンジニアリングはそれを慎重に割り当てるべきリソースとして扱います: 関連しそうなあらゆるものではなく、このターンでモデルが実際に必要とするものにそれを費やすのです。Anthropic はこの分野全体を、「高信号トークンの可能な限り最小の集合」を探す営みとして枠づけています — あなたが追加するすべてのトークンは、有限の注意の予算を奪い合います。これは、トランスフォーマーがすべてのトークンを他のすべてのトークンと関連づける仕組みの直接的な帰結です。

コンテキストロットと「中間で迷子になる」​

長文コンテキストの LLM には、よく知られた現象があります: モデルはコンテキストの冒頭と末尾付近の内容に不釣り合いなほど注意を払い、中間に埋もれた内容の想起は劣化します。この効果を研究する人々はこれを「中間で迷子になる(lost in the middle)」と呼びました。

実際の帰結はこうです: 10万トークンのコンテキストにドキュメントを詰め込み、最も重要な指示を位置60,000に埋めると、モデルは実質的にそれを無視するかもしれません — そこまで読めないからではなく、注意がウィンドウ全体に均等に分布していないからです。

「コンテキストロット」はより広範なパターンです: セッションが長くなるにつれて、応答の質は漂流しがちになります。初期の指示が薄まります。繰り返されるやり取りが元のタスクを押しのけます。モデルは曖昧な言い回しを始めたり、同じことを繰り返したり、あなたが実際に求めたことの筋を見失ったりし始めます。

これらは、より良いプロンプトで完全に修正できるバグではありません。これらは、注意が大規模にどう働くかという構造的な性質です。エンジニアリング上の対応は、コンテキストをより小さく、より鋭く保つことであって、詰め込んで期待することではありません。

順序が重要​

内容をどこに置くかは、何を含めるかと同じくらい重要です。確立された良い慣行は次のとおりです:

位置そこに置くもの
最上部(システムプロンプト)安定した、永続的な指示。ペルソナ、ルール、フォーマット要件。
システムプロンプトの後現在のタスクを、平易な言葉で。
最後のユーザーターンの直前このまさにこの要求のための、最も重要で具体的なコンテキスト。
中間補助ドキュメント、検索されたチャンク — 時系列ではなく関連性で並べる。
会話履歴継続性のために必要なものだけ。積極的に刈り込む。

一般的なルール: 現在のターンに近いほど、より多くの注意を受けます。長い履歴の中間にしか存在しない重要な指示はリスクにさらされています。

指示にとっての「適切な高度」​

システムプロンプトは、正反対の二通りの仕方で失敗しうります。低すぎると、現実がずれた瞬間に壊れる脆い「これならばあれ」式のロジックをハードコードしてしまいます。高すぎると、モデルが持っていないコンテキストを前提とした曖昧なガイダンスを書いてしまいます。Anthropic はその目標を**「適切な高度」**と呼びます — 「行動を効果的に導くのに十分なほど具体的でありながら、強力なヒューリスティックを提供できるほど柔軟」というちょうどよい領域です。そこを狙ってください: 決定木でも雰囲気でもなく、具体的なルールと例を。

詰め込みより検索​

すべてを入れたくなる誘惑があります: すべてのドキュメント、コードベース全体、会話のすべて。それに抗ってください。

より良いアプローチは選択的検索です: この特定の要求にモデルが実際に必要とするものを特定し、それだけを注入するのです。適切なドキュメントから巧みに検索された2,000トークンのチャンクは、答えが中間のどこかにある4万トークンの投げ込みを上回ります。

これが検索拡張生成(RAG)が存在する理由です — 単にコンテキストの制限を克服するためだけでなく、コンテキストを厳選された状態に保つことで質を向上させるためです。そのエージェント版がジャストインタイム検索です: すべてのドキュメントを事前に読み込む代わりに、エージェントは軽量な識別子(ファイルパス、ID、クエリ)を保持し、実際の内容を必要となったまさにその瞬間にだけコンテキストに引き込みます。

インタラクティブなセッションにも同じ論理が当てはまります: すべてを蓄積する代わりに、定期的に履歴を圧縮またはクリアして、現在のタスクにもはや関連しない内容を取り除きます。Claude Code の /compact と /clear コマンドは、単なるセッション管理ではなく、コンテキストエンジニアリングのツールです。API では、同じパターンがメモリとコンテキスト編集によって自動化されます — 古いツール結果がウィンドウから刈り込まれる一方で、重要なものは永続的なメモリストアに書き込まれます。

三つの主力戦術​

長期的な作業では、三つの技術がほとんどの重労働を担います。それらは組み合わさります — ほとんどの実際のエージェントは三つすべてを使います。

Guided walkthrough1 of 3
  1. セッションがウィンドウの上限に近づいたら、それを要約して、蒸留したバージョンで再初期化します。荷重を支える詳細 — アーキテクチャ上の決定、未解決のバグ、主要な実装の選択 — を保ち、逐次の実況を捨てます。これが Claude Code で /compact が行うことです。

コストの観点​

あなたが送るトークンは、あなたが支払うトークンです — 金銭面でもレイテンシ面でも。緩く関連する素材でコンテキストを詰め込むと、その両方が膨らみます。コンテキストエンジニアリングとコスト効率は同じ問題です。

より具体的には:

  • テンプレートからコピペした肥大したシステムプロンプトは、すべての呼び出しごとに支払われます。
  • 「役立つかもしれない」という理由で持ち越す古い会話履歴は、すべての呼び出しごとに支払われます。
  • 「念のため」に注入するドキュメントは、すべての呼び出しごとに支払われます。

そこにある必要のないものを削ることは、質にとってより良いと同時に、運用がより安価になります。

Claude ユーザーのための実践的な戦術​

Claude.ai では:

  • 異なるタスクには異なる会話を使ってください。午後の脱線が、集中したプロジェクトのコンテキストを汚染しないようにしましょう。
  • それらに依存する複雑な質問をする前に、長いスレッドを要約してください。明示的な要約は、生の履歴よりも有用なことがよくあります。
  • 求めている具体的な事柄を、長いメッセージの中間に埋めるのではなく、末尾に置いてください。

Claude Code では:

  • CLAUDE.md ファイルを引き締まった状態に保ってください。その中のすべての行が、すべてのセッションに注入されます。CLAUDE.md とコンテキスト管理を参照してください。
  • 本当に異なるタスクに切り替えるときは /clear を使ってください。続けたいけれどセッションが大きくなっているときは /compact を使ってください。
  • 現在のステップにファイル全体が必要ないときは、内容を貼り付けるのではなくパスでファイルを参照してください。

API レベルでは:

  • システムプロンプトは、すべての要求が本当に必要とするものだけを含むように設計してください。タスク固有の指示はユーザーターンに移しましょう。
  • ドキュメントの多いユースケースでは、コーパス全体をアップロードするのではなく、関連するチャンクを検索して注入してください。
  • 安定した再利用可能な接頭部が最初に来るようにプロンプトを構成してください — これはプロンプトキャッシュも可能にし、コンテキストエンジニアリングの自然な相棒となります。

長いドキュメントを Claude に手渡したいときは、配置のルールが生の分量に毎回勝ちます:

指示は最初に、末尾で再掲

タスク: この契約書の中で当社の責任に上限を設けているすべての条項を見つけ、それぞれを条番号とともに一字一句そのまま引用してください。

[... ここに40ページの契約書全文を貼り付け ...]

タスクの再確認: 上記のすべての責任上限条項を、条番号とともに正確に引用して列挙してください。該当するものがなければ、明示的にそう述べてください。

同じ指示が冒頭と末尾の両方に置かれています — 注意が好む二つの位置です — ので、非常に長い中間があってもそれは生き残ります。

発想の転換​

プロンプトエンジニアリングはこう問います: 「私は何を言うべきか?」 コンテキストエンジニアリングはこう問います: 「モデルは何を見るべきか、どんな順序で、そして私は何を意図的に締め出すべきか?」

二つ目の問いはより難しいですが、それこそが大規模における質を実際に決定するものです。

Check yourself

0/3
  1. プロンプトエンジニアリングとコンテキストエンジニアリングの中核的な違いは何ですか?
  2. 10万トークンのコンテキストの中で、最も重要な単一の指示をトークン60,000に埋めます。ありそうな結果は?
  3. コーディングエージェントが長いタスクでコンテキストを使い果たそうとしています。進捗を最もよく保つ戦術はどれですか?
語彙を定着させる
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 6
Key takeaways
  • コンテキストウィンドウは保管庫ではなく注意の予算である — それを高信号トークンだけに費やす。
  • 位置は分量に勝る: 重要な指示は冒頭と最終ターンの直前に置き、決して中間に埋もれさせない。
  • 圧縮、メモ取り、ジャストインタイム検索は、長いエージェントを首尾一貫させ続ける三つの戦術である。
  • コンテキストを厳選することは、コストを削るのと同じレバーである — より少ないトークン、より良い答え、より安い請求。

関連項目​