コンテキストエンジニアリングとは｜プロンプトとの違いと実務

コンテキストエンジニアリングとは何か

結論から言うと、モデルに渡す入力の「中身の設計」ではなく「編成の設計」です。プロンプトという1つの入力欄ではなく、推論のたびに組み上がる情報の束をどう構成するかを扱います。

定義：モデルが見ている情報の総量を設計する

LLMは推論のたびに、その時点でコンテキストウィンドウに載っている情報だけを根拠に応答します。ここに何が載っているかは、多くの場合アプリケーション側のコードが決めています。システムプロンプトを組み立て、ツールの定義を並べ、過去のやり取りを連結し、ベクトル検索の結果を差し込む。この組み上げ工程の設計がコンテキストエンジニアリングです。

Anthropicは公式の技術ブログで、この領域を「望ましい振る舞いを引き出す確率が最も高いコンテキストの構成は何か」という問いだと整理しています（Effective context engineering for AI agents｜Anthropic）。注目すべきは、良い設計を「高シグナルなトークンの最小集合を見つけること」と定義している点です。足し算ではなく引き算の技術として位置づけられています。

コンテキストウィンドウと注意の配分

コンテキストウィンドウは有限です。ただし本質的な制約は容量よりも、モデルの注意（attention）が入力全体に均等に配られるわけではないという性質にあります。

長い入力の中盤に置かれた情報が参照されにくくなる現象は、Lost in the Middleとして広く報告されてきました。長文脈での性能劣化を指して、開発者コミュニティでは context rot という通称が使われることもあります（確立した学術用語ではなく、あくまで現場での呼び方です）。ウィンドウの上限に余裕があっても、埋めれば埋めるほど個々の情報の重みは薄まると考えたほうが実装は安定します。

実務上の目安として、利用可能なウィンドウに対する使用率が高止まりしている状態は設計の見直しサインです。あくまで筆者が関わった数件の案件での経験則ですが、常時7割以上を履歴が占める構成になったあたりから、ツールの選択ミスと指示の取りこぼしが体感でわかるほど増えました。一般的な閾値として検証された数字ではないため、自分の環境で計測して判断してください。

プロンプトエンジニアリングとの違い

両者は競合しません。担当する範囲が違います。

指示文そのものの書き方、つまりZero-shotやFew-shot、思考の分解といった技法は本記事では扱いません。そちらはプロンプトエンジニアリングとは？基本から実践テクニックまでわかりやすく解説で体系的に整理しています。本記事は、その指示文を含めた情報全体をどう供給するかに限定します。

ミニFAQ：プロンプトエンジニアリングはもう不要になるのか

なりません。コンテキストを完璧に編成しても、システムプロンプトの指示が曖昧なら出力はぶれます。順序としては、まず指示文を固め、そのうえで供給する情報を設計するのが実装しやすい流れです。「プロンプトはもう古い」という論調が一部にありますが、実装の現場では両方を触ります。

コンテキストを構成する6つの要素

結論として、コンテキストは単一の塊ではなく、性質の異なる6つの層の集合として扱うと設計しやすくなります。層ごとに更新頻度も削りやすさも違うためです。

このうち、実装初期に見落とされやすいのがツール定義です。トークンを常時消費し続けるにもかかわらず、プロンプトのように目に見える場所にないため、レビューの対象から漏れます。

Anthropicはツール設計について、機能が重複する定義があるとモデルが選択を誤りやすいと指摘しています（Writing effective tools for AI agents｜Anthropic）。似た名前のツールを増やすくらいなら、1つにまとめて引数で分岐させたほうが安定します。

外部データの引き込み方そのものについてはRAGとは？仕組み・活用事例・導入メリットをわかりやすく解説を、グラフ構造を使う発展形はGraphRAGとは｜通常RAGとの違い・仕組み・構築案件の実務を参照してください。

4つの基本戦略：Write・Select・Compress・Isolate

LangChainは、エージェントのコンテキスト設計を4つの操作に整理しています（Context Engineering｜LangChain）。特定のフレームワークに依存しない分類なので、実装の共通言語として使えます。

Write：コンテキストの外に書き出す

処理の途中で生まれた情報を、コンテキストウィンドウの中ではなく外に保存します。スクラッチパッドへのメモ書き、ファイルへの中間成果物の保存、セッションをまたぐメモリへの記録が該当します。

狙いは、後で必要になるかもしれない情報を抱え込まずに済ませることです。10回の調査を経て最終レポートを書くようなタスクでは、調査結果を毎ターン履歴に積むのではなく、ファイルに書いて必要時だけ読み直すほうが安定します。

Select：必要なものだけ引き込む

保存した情報や外部データのうち、いま必要なものだけをコンテキストに入れます。RAGの検索、メモリの条件付き読み込み、ツール定義の動的な絞り込みがここに入ります。

件数の欲張りは逆効果になりがちです。社内文書検索やFAQ応答のように答えが特定の数文書に閉じるタスクでは、検索結果を上位20件渡すより上位3〜5件に絞ったほうが精度が上がるケースがあります。再現率を優先したくなる場面ですが、ノイズも一緒に入る点は意識しておきたいところです。最適な件数は検索対象・チャンク粒度・再ランキングの有無で変わるため、固定値として扱わないでください。

Compress：要らなくなったものを畳む

古い履歴を要約に置き換える、ツールの生出力から必要な行だけ抜く、といった圧縮です。会話が長引くアプリでは避けて通れません。

圧縮の発火条件は、ターン数ではなくトークン使用率で決めるほうが素直です。使用率が一定の水準（設計時に決めた閾値、たとえば7〜8割）に達したら古い区間から要約する、という組み方が扱いやすいと感じています。要約時に決定事項と未解決事項だけは原文に近い形で残すのがコツです。ここを丸めると、エージェントが同じ議論を繰り返します。

Isolate：文脈を分割する

1つのコンテキストに全部を載せず、役割ごとに切り離します。サブエージェントへの委譲、処理のフェーズ分割、サンドボックス内での実行がこれにあたります。

調査と執筆を1つの文脈で回すと、調査ログが執筆時のノイズになります。調査は別エージェントに任せ、結果だけを受け取る構成にすれば、執筆側のコンテキストは軽いままです。マルチエージェント構成の選択肢はAIエージェント開発フレームワーク比較｜LangGraph・CrewAI・AutoGenで整理しています。

ミニFAQ：4戦略はどれから手をつけるべきか

会話が続くチャット型やエージェント型のように履歴が伸びやすいアプリでは、Compressから入ると投資対効果が高くなりやすいです。履歴の膨張は起きやすく、対処も比較的定型的だからです。一方、単発の問い合わせ応答が中心でRAGが主役のアプリでは、Selectの精度から着手したほうが先に効きます。WriteとIsolateは、それでも足りない段階で検討する順序が現実的でしょう。

コンテキストが劣化する兆候と対処

結論として、精度低下の原因をモデルの性能に求める前に、コンテキストの状態を疑ってください。症状には出方の型があります。

典型的な4つの症状

• 指示の取りこぼし：システムプロンプトに書いたはずの制約が守られない。履歴が伸びた後半で起きやすい

• 同じ作業の繰り返し：数ターン前に決めたことを再検討し始める。圧縮時に決定事項を落とした場合の典型

• ツール選択のミス：似た機能のツールを取り違える。定義の重複か説明文の曖昧さが原因

• 古い前提での回答：長期メモリに残った過去の設定を現在の前提として使う

対処の優先順位

順番を間違えると効きません。上から試すのが効率的です。

1. ツール定義の棚卸し。機能が重なるものを統合し、説明文を1機能1目的に書き直す

2. 履歴の圧縮方針の見直し。決定事項・未解決事項・現在の目標を構造化して残す

3. 検索結果の件数を絞る。適合度の閾値を上げ、下位の結果は捨てる

4. システムプロンプトの条件分岐を減らす。細かい場合分けはツール側やコード側に逃がす

5. それでも足りなければ、フェーズを分割して別コンテキストにする

3番目までで改善するケースが多く、そこで止まれば構成変更まで踏み込まずに済みます。いきなり構成を作り替えると、何が効いたのか判定できなくなります。

なお、外部データを引き込む構成では、取り込んだ内容に指示文が混入するリスクがあります。対策はプロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイドにまとめています。

実装パターン別の設計方針

同じ4戦略でも、アプリの形によって重心が変わります。3パターンに分けて整理します。

単発チャット・単発生成

履歴がほぼないため、コンテキスト設計の比重は小さめです。システムプロンプトの品質と、必要なら検索結果の適合度で決まります。ここでコンテキストエンジニアリングを持ち出す実益は薄く、指示文の設計に集中したほうが早いでしょう。

RAGを伴う問い合わせ応答

Selectが主戦場です。チャンク分割の粒度、検索の件数、再ランキングの有無で精度が動きます。

実務で効くのは、検索結果をそのまま連結せず、出典と本文を構造化して渡すことです。どの文書のどの位置・どのセクションから来たかが明示されていると、モデルは根拠の紐付けを間違えにくくなります。PDFならページ、Web文書なら見出し、DBならレコードIDというように、媒体に合わせた位置情報を添えてください。ベクトルデータベースの選定はPineconeとは｜特徴・料金・RAG構築での使い方を実装例つきで解説が参考になります。

マルチステップのエージェント

4戦略すべてを使います。ここが最も設計の巧拙が出る領域です。

1タスクが10ターンを超えるような構成では、Write（中間成果物の外部保存）とIsolate（サブエージェント分割）が効きます。逆に3〜5ターンで終わるタスクに最初からサブエージェントを導入すると、受け渡しのオーバーヘッドだけが増えます。精度の最適化だけを目的にするなら、まず単一エージェントで組み、ターン数が伸びてから分割するのが手戻りの少ない進め方です。ただし権限分離や障害の切り分けが要件に入る場合は、精度とは別の理由で最初から分割する判断もあります。

エージェント自体の基礎はAIエージェントとは？仕組み・種類・活用事例をわかりやすく解説を参照してください。

よくある失敗と対策

失敗1：とりあえず全部入れる

社内文書を丸ごと、履歴も全部、ツールも思いつく限り。初期実装で最も多いパターンです。動くには動きますが、伸びしろがありません。

対策は計測から入ることです。1リクエストあたりの入力トークンを要素別に分解し、どこが太いかを出します。だいたい履歴かツール定義のどちらかが犯人です。

失敗2：システムプロンプトに条件分岐を書き込む

「Aの場合はこうして、Bの場合はこうして」を増やし続けると、指示同士が干渉し始めます。Anthropicも、複雑なハードコードされたロジックは壊れやすいと指摘しています。

対策は、分岐をコード側かツール側に移すことです。プロンプトには判断基準の水準（どういう方針で判断するか）だけを書き、個別の場合分けは実装で吸収します。

失敗3：圧縮で決定事項まで消す

要約時に「重要そうな部分」を残そうとして、議論の結論を落としてしまうケース。エージェントが堂々巡りを始めたら、まずここを疑ってください。

対策は、要約の出力形式を固定することです。現在の目標、確定した決定、未解決の論点、この3つは見出し付きで必ず残す。自由形式の要約に任せると落ちます。

失敗4：改善したかどうかを測っていない

体感で「良くなった気がする」で進めると、数週間後に元に戻っています。

対策は評価セットの用意です。小〜中規模の内部評価では、代表的な入力を20〜50件程度固定して変更前後を比較するところから始めるケースが多いでしょう。本番運用で品質保証まで求められる場合は、これより多くの件数とカバレッジ設計が必要になります。評価の組み方はLLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説で詳しく扱っています。

コンテキスト設計チェックリスト

実装レビューでそのまま使える形にまとめました。手元のプロジェクトに当てて、通らない項目から潰してください。

全項目を最初から満たす必要はありません。計測の2項目だけ先に通すと、残りの判断がやりやすくなります。

フリーランスエンジニアの案件での位置づけ

結論として、コンテキストエンジニアリングは単独の職種名としてはまだ定着しておらず、LLMアプリ開発・エージェント開発案件の要件の一部として現れることが多い領域です。

以下は、主要フリーランスエージェント数社（首都圏中心）の公開案件ページで、2026年9月時点に週3〜5日の準委任案件を確認した範囲の観測です。この範囲では、「コンテキストエンジニアリング」を職種名として掲げる募集はほとんど見当たりません。一方で、LLMアプリやAIエージェントの開発案件の要件欄に、RAGの精度改善、トークン最適化、エージェントの設計といった形で実質的に含まれるケースは確認できます。非公開案件は対象に含めておらず、公開案件の母数もまだ多くない領域です。網羅的な調査ではなく限定的な観測として読んでください。

スキルをどう示すか

案件面談で評価されやすいのは、抽象的な理解より具体的な改善の経験です。実務で語れる材料を3つ挙げます。

• 入力トークンを要素別に分解し、どこを削って何%圧縮したか

• 検索結果の件数や再ランキングを変えて、評価セットのスコアがどう動いたか

• 単一エージェントからサブエージェント分割に切り替えた判断基準と、その前後の変化

いずれも数値で語れる形にしておくと、面談での説得力が変わります。数字が出せないなら、せめて判断の根拠を言語化しておくことです。

トークン削減や推論設計そのものを主題とする案件の動向はLLMコスト最適化案件の単価相場｜トークン削減・推論設計のフリーランス実務で、エージェント開発案件の全体像はAIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説で扱っています。自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は『【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？』で整理しています。

まとめ

コンテキストエンジニアリングは、モデルに見せる情報を増やす技術ではなく、必要な情報だけを残す判断の技術です。要点を整理します。

• 対象はプロンプト文字列ではなく、システムプロンプト・ツール定義・履歴・検索結果・メモリ・ユーザー入力の6層すべて

• 基本戦略はWrite（外部保存）・Select（選択）・Compress（圧縮）・Isolate（分割）の4つ

• コンテキストウィンドウに入ることと、その情報が効くことは別問題。長いほど中盤が薄まる

• 精度低下の原因調査は、ツール定義の棚卸し→履歴の圧縮方針→検索件数の順で当たると効率がよい

• 圧縮では決定事項と未解決事項を構造化して残す。ここを落とすと堂々巡りが起きる

• 改善は評価セットで測る。代表入力20〜50件を固定し、変更前後を比較する

次の一歩としては、手元の実装で入力トークンを要素別にログ出力するところから始めてください。着手順は、①要素別のトークンログ取得 ②履歴が占める比率の確認 ③ツール定義の重複棚卸し、の3つで十分です。削る判断はそのあとで構いません。指示文そのものの書き方を先に固めたい場合は、プロンプトエンジニアリングとは？基本から実践テクニックまでわかりやすく解説から読むのが順当でしょう。

参照した一次情報は以下のとおりです。

• Effective context engineering for AI agents｜Anthropic

• Writing effective tools for AI agents｜Anthropic

• Context Engineering｜LangChain

• context_engineering｜LangChain（GitHub）