コンテキストエンジニアリングとは、LLM の推論時に入力されるトークン群（システムプロンプト・指示・知識・履歴・ツール定義）を最適化する設計手法である。プロンプト文だけを磨く「プロンプトエンジニアリング」の上位概念として、Anthropic が 2025 年半ばから提唱し、OpenAI の Agents SDK や Vercel の本番エージェントでも中核的な技術として位置づけられている。

本記事では、B2B で LLM アプリケーションを開発するチームに向けて、プロンプトエンジニアリングとの違い、コンテキストウィンドウの構成要素、設計パターンから運用上の落とし穴までを整理する。読了後には、自社の RAG やエージェントを「コンテキスト全体の設計問題」として捉え直す視点を持ち帰れるはずだ。

コンテキストエンジニアリングは、LLM が推論時に「見る」情報環境全体を設計する技術である。プロンプトエンジニアリングが指示文の磨き込みに閉じるのに対し、コンテキストエンジニアリングはメモリ・検索結果・ツール定義・対話履歴までを一つの情報アーキテクチャとして扱う。

LLM アプリケーションの品質がプロンプトの書き方よりも「何を、どの順序で、どれだけコンテキストウィンドウに入れるか」に強く依存することが、本番運用で広く認識されるようになった。Anthropic のエンジニアリングブログは、コンテキストを「推論時にサンプリングするトークンの集合」と定義し、その有用性を有限資源として最適化する工学問題と位置づけている（出典: Anthropic Engineering – Effective context engineering for AI agents）。

プロンプトエンジニアリングは、LLM に与える指示文（プロンプト）をいかに工夫してタスク性能を引き出すかに焦点を当てる。一方、コンテキストエンジニアリングは、指示文の周辺にある要素、すなわち検索された文書（RAG）、過去の会話履歴、利用可能なツールの定義、長期メモリ、Few-shot 事例までを設計対象に含める。

両者の関係は「部分と全体」に近い。プロンプトエンジニアリングはコンテキストエンジニアリングの一要素であり、単独では本番エージェントの品質を保てない。複数ターンにまたがるエージェントは、毎ターンごとにツール出力や途中推論を蓄積するため、プロンプト単体を磨いても累積するコンテキストの質を管理できないからだ。

実例として、Vercel のエンジニアリングブログは自社エージェントのツールを 15 個から 2 個に削減した結果、5 クエリのベンチマークで精度が 80% から 100% に上昇し、トークン量が 37% 減少、応答速度が 3.5 倍に改善したと報告している。これはプロンプト文を書き直した成果ではなく、コンテキストに載せる情報を絞った成果である。

コンテキストエンジニアリングが 2025 年半ばから急速に注目されるようになった背景には、LLM アプリケーションが「単発の質問応答」から「複数ターンの自律エージェント」に主戦場を移したことがある。

エージェントは推論ループの中で検索結果・ツール実行結果・中間推論を次々とコンテキストに積み上げる。Anthropic はこれを「有限資源の管理問題」として整理し、失敗モードを 3 つに分類している。第一に情報不足によるハルシネーション、第二に情報過多によるコンテキストオーバーフロー、第三に情報の配置が悪いことによる関連性低下である。

この整理は、従来の「プロンプトを工夫すれば何とかなる」という発想の限界を明示している。コンテキストの形そのものを設計しない限り、長時間稼働するエージェントは早晩性能が劣化する。

コンテキストウィンドウに載せる要素は、大きく 6 種類に分類できる。それぞれが LLM の判断に異なる影響を与えるため、要素ごとの役割を意識した設計が欠かせない。

単に「プロンプト」と一括りにせず、構成要素を分解して扱うことがコンテキスト設計の第一歩となる。当社でも社内エージェントを設計する際、まずこの 6 要素でコンテキストを分解するワークショップから始めるケースが多い。

システムプロンプトは、LLM に役割・制約・出力形式を指示する基盤となる文章である。通常は全ターンで固定のまま使われ、コンテキストの土台をなす。長すぎる（たとえば 3,000 トークンを超える）システムプロンプトは、以降に積み上がる動的要素を圧迫するため注意が要る。

タスク指示は、各ターンでユーザーから届く具体的なリクエストに相当する。システムプロンプトが「どう振る舞うか」を定義するのに対し、タスク指示は「今回何をしてほしいか」を定義する。

Few-shot 事例は、出力フォーマットや思考プロセスの例を示すために挿入される入出力ペアである。事例は多ければ良いというものではなく、2〜5 件に厳選して多様なパターンを網羅するのが定石となっている。出力のばらつきが気になるタスクほど Few-shot の設計が効きやすい。

RAG で挿入する外部知識は、ベクトル検索や全文検索で取得した関連文書を指す。文書数が多すぎると関連性が薄まり、少なすぎると情報不足でハルシネーションが増える。ハイブリッド検索による精度改善は関連記事「ハイブリッド検索とは？ベクトル検索×全文検索でRAG精度を上げる仕組みと実装」も参照されたい。

ツール定義は、エージェントが呼び出せる関数の仕様（名前・引数・説明）である。Vercel の事例が示すように、不要なツールを載せるだけで精度は顕著に下がる。ツール数は「あれば便利」ではなく「今回のタスクで実際に使うもの」に絞るのが原則となる。

対話履歴・長期メモリは、過去ターンのユーザー発話・モデル応答・ツール結果を時系列で保持する要素である。ロングタスクではこの領域が最速で肥大化するため、後述する圧縮戦略が必須となる。

コンテキストを静的な「巨大プロンプト」として扱うのではなく、タスクごとに必要な要素を動的に組み立てる発想が本番運用では求められる。本節では、現場で繰り返し使われる 3 つの設計パターンを整理する。

最も基本的なパターンが、テンプレートにスロット（穴）を定義し、ターンごとに必要な要素を埋めて送信する動的スロット方式である。スロットは「システム指示」「タスク定義」「関連文書」「ツール定義」「最近の履歴」「ユーザー発話」のように区切り、各スロットに入れる内容を別々のロジックで生成する。

この方式の利点は、どの要素が品質に寄与しているかを切り分けやすい点にある。例えば関連文書スロットだけを A/B テストすれば、検索戦略の改善効果を独立に測れる。逆にスロット分離を怠り、巨大なプロンプト文字列を直接組み立てていると、どの部分が失敗の原因かを後追いで特定するのが極めて困難になる。

当社で社内の問い合わせエージェントを設計した際も、最初は単一のプロンプトテンプレートで運用していたが、履歴の扱いと検索結果の扱いが絡み合って問題の切り分けができなくなった経緯がある。スロット化してからは、検索層の改善と履歴戦略の改善を並行して議論できるようになった。

RAG で取得した文書や会話履歴の件数が多い場合、すべてを詰め込まず、関連性スコアに基づいて優先度順にコンテキストへ投入する。ベクトル類似度・BM25・リランカーモデル（例: Cohere Rerank）などを組み合わせ、上位 N 件のみを残すのが一般的である。

優先度制御の設計で陥りやすいのが、スコアの閾値で機械的に切ることである。閾値をまたぐ情報同士が文脈上不可分なケース（例: 同じ契約書の条項と補足）を切ってしまうと、出力の整合性が壊れる。実務では「スコア上位 N 件 + 同一文書内の関連セクション」というハイブリッドの選定ロジックに落ち着くことが多い。

関連性の評価自体が難しいタスクでは、リランカーの学習データに自社ドメインの正解ペアを追加すると効果が大きい。これは関連記事「RAG 構築の失敗パターン10選と回避策」でも主要な回避策として挙げた論点である。

長時間動くエージェントでは、履歴が数万トークン単位で蓄積されるため、一定の条件でコンテキスト圧縮を行う必要がある。Anthropic が提唱する「compaction」は、古い履歴をモデル自身に要約させ、要約文で置き換える手法である。

もう一つの重要なパターンがメモリ分離である。短期的な対話履歴と、永続的に保持するユーザーの嗜好・プロジェクト情報を別のストアに分け、必要に応じて選択的にコンテキストへ挿入する。OpenAI の Agents SDK が提供するセッションメモリは、この分離を標準化する試みと位置づけられる。直近 N 件だけを保持する trimming 方式と、古い履歴を要約に置換する summarization 方式の両方がサポートされている。

圧縮のタイミングは「入力トークンが閾値を超えた時」「同一タスク内で一定ターン経過した時」など、運用条件に応じて決める。圧縮を遅らせすぎるとオーバーフローで落ち、早すぎると文脈の微妙なニュアンスが失われる。

エージェント特有のコンテキスト課題は、複数ターンを経るにつれて履歴が指数関数的に膨張することにある。ここでは長時間タスクと肥大化防止の両面から設計指針を整理する。

コーディングエージェントや自律リサーチエージェントでは、1 回のタスクで数十回以上のツール呼び出しが発生する。ツール結果をそのまま全件蓄積するとコンテキストがあっという間にオーバーフローするため、ツール結果の要約が実質必須となる。

Anthropic が推奨する structured note-taking（スクラッチパッド） は、エージェントが外部ストアにメモを書き込み、次ターンではメモを参照するだけで詳細を再構築できるようにするパターンである。これにより、ツール出力の生データをコンテキストから追い出しつつ、意思決定に必要な情報は失わない構造を作れる。

ロングタスク対応では、タスク全体の目標・完了条件・残タスクを「プラン」として明示的に持ち、毎ターン冒頭に注入する設計も効果的である。モデルが自分の現在地を見失うのを防ぎ、途中で方針がぶれるのを抑えられる。関連記事「AIエージェントを本番運用に乗せるには？パイロットから量産化への実践ステップ」でも同種の工夫を紹介している。

肥大化を防ぐ具体策として、まず各コンテキスト要素にトークン予算を割り当てる。例えば「システム 1,500、タスク 500、RAG 3,000、履歴 2,000、ツール定義 1,000」のように合計値から逆算し、予算超過時に圧縮・削除するロジックを組み込む。

監視面では、ターンごとの入力トークン数・出力トークン数・コスト・レイテンシをすべてログに残し、傾向をダッシュボードで可視化する。ログは関連記事「AIオブザーバビリティとは？LLMを本番運用で監視する仕組みと実践ガイド」で紹介した観点を参考に、リクエスト ID・セッション ID・モデルバージョンで絞り込めるようにしておくと後の調査が早い。

また、同じ情報をシステム指示と履歴の両方に重複記載していないか定期的に棚卸しすると、想像以上に余剰トークンが見つかる。コンテキストの 2 割は「歴史的経緯で残っただけで実は不要」なことが多い、というのが経験則である。

コンテキストエンジニアリングは一度設計して終わりではない。推論結果の品質を継続的に測り、コンテキスト構成を繰り返し改善するプロセスとして運用する必要がある。

コンテキスト精度の測定は、大きく 3 層で設計する。第一層は検索層で、RAG が正しい文書を上位に持ち上げているかを Recall@K・MRR で評価する。第二層は利用層で、取得した文書のうち出力に実際に使われた割合（attribution）を測る。第三層は出力層で、最終的な回答の正確性を LLM-as-a-Judge や人手評価で検証する。

これら 3 層を分離して測ることで、「回答が悪い」原因が検索不足なのか、取得したのに使えていないのか、判断が誤っているのかを切り分けられる。切り分けができないまま本番を運用すると、プロンプトを何度書き換えても性能が上がらない状態に陥りやすい。

評価手法の詳細は関連記事「LLM-as-a-Judge とは？AI 出力を AI で評価する手法とハルシネーション検知の実装」で取り上げている。コンテキストエンジニアリングの改善サイクルを回すうえで、評価基盤は先行投資として整えておく価値が大きい。

コンテキスト構成の変更は、必ず A/B テストで検証してから本番反映する。変更対象は典型的には「取得する文書数」「履歴の要約タイミング」「ツールの絞り込みロジック」などで、これらは互いに干渉しやすいため一度に一箇所のみ変更するのが鉄則となる。

段階的リリースでは、まず内部評価セット（100〜500 件程度のゴールデンクエリ）で回帰をチェックし、次にトラフィックの 5〜10% に限定公開して本番指標を観察する。エラーやコスト増が見られなければ段階的に拡大する。この手順を略すと、評価セットでは改善していたのに本番では悪化していた、という事態が高頻度で起きる。

当社の社内エージェント運用でも、ツール定義の絞り込み変更を直接全ユーザーに適用したところ、一部のエッジケースで回答品質が落ちる問題が後から発覚した経験がある。以後は、どんなに「明らかに改善のはず」の変更でも段階的リリースを省かない運用に落ち着いている。

コンテキストエンジニアリングの落とし穴は、多くが「良かれと思って情報を追加する」判断から生まれる。本節では現場でよく出会う 2 つの失敗パターンを整理し、最後にまとめに進む。

最も頻発する失敗が、コンテキストにできる限り多くの情報を詰め込んでしまうパターンである。「関連しそうな文書を全部入れておけば、モデルが賢く選んでくれるだろう」という発想は、ほぼ例外なく裏目に出る。

LLM のアテンションは無限ではなく、長いコンテキストでは中間部分に置かれた情報が無視されがちな「lost in the middle」現象も知られている。情報量が閾値を超えると、出力品質はむしろ低下する。Vercel のツール削減事例（15→2）で精度が 80→100% に上がったのはこの問題の典型的な解消例と読める。

もう一つの副作用がレイテンシである。入力トークン数に応じて処理時間は線形以上に伸びるため、コンテキスト肥大化はそのまま UX の劣化に直結する。ユーザーから見ると「回答が遅いうえに質も悪い」という最悪の組み合わせになりうる。

トークンコストの見えにくさも深刻な落とし穴となる。エージェントが内部で何度もツールを呼び、履歴を蓄積していく構造では、1 ユーザーあたりのトークン消費がインタラクションの回数に応じて加速度的に増える。請求書を見て初めて「このユースケースは採算が合わなかった」と気づくケースは珍しくない。

コストの可視化は、単に「月次の API 請求額」だけでは足りない。セッション単位・ユーザー単位・エンドポイント単位にブレイクダウンし、「1 タスクあたり何トークンで済むはずか」というターゲットを持つ必要がある。関連記事「LLMコスト最適化ガイド — トークン削減・モデル選定・キャッシュ実装」で紹介した原則を、コンテキスト設計のレイヤーからも適用することで、コスト暴走を未然に防げる。

本記事のまとめとして、コンテキストエンジニアリングは「何を入れるか」以上に「何を入れないか」の設計が質を決めることを強調したい。プロンプトエンジニアリングでは個々の指示文を磨けば十分だったが、エージェント時代のコンテキスト設計は情報の絞り込みと動的な再構成こそが中核となる。

自社で LLM アプリケーションを本番運用しているチームは、まずコンテキストウィンドウを 6 要素に分解し、それぞれの寄与度を測るところから改善サイクルを開始するとよい。当社でも B2B 顧客の LLM 導入支援で同じアプローチを採用し、コンテキスト設計のリファクタリングだけで体感品質が一段上がるケースを複数見てきた。