コンテキストエンジニアリングとは？RAG・メモリ・ツールの設計

PR：本記事にはアフィリエイト広告（プロモーション）を含みます。

コンテキストエンジニアリングとは、LLMが推論するたびにコンテキストウィンドウへ載せる情報を取捨選択し、維持し続ける設計です。対象は人が書く指示文だけではなく、システムプロンプト・ツール定義・外部データ・会話履歴・メモリの5つに及びます。

コンテキストウィンドウは、情報をいくらでも置ける倉庫ではありません。載せる量が増えるほど、モデルがそこから必要な情報を正確に取り出す精度は落ちます。何を載せて何を載せないかを決める作業が、プロンプトの書き方とは別の設計課題になります。

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

コンテキストエンジニアリングとは、LLMが推論するたびにコンテキストウィンドウへどの情報を載せるかを取捨選択し、維持する設計です。Anthropicはこれを、プロンプトの外側に入り込む情報も含めて、推論中に最適なトークンの集合を選び維持するための戦略群だと定義しています。

Anthropicは技術ブログ「Effective context engineering for AI agents」で、コンテキストを「LLMからサンプリングする際に含まれるトークンの集合」と定義しています。同社の定義で要になるのは、管理対象がプロンプトに限定されない点です。システム指示・ツール・外部データ・メッセージ履歴といった、コンテキスト状態の全体が対象に含まれます。

設計対象を要素に分けると5つになります。どの要素で不具合が起きているかを特定できれば、触る場所が決まります。

OpenAIも公式ドキュメントで、コンテキストを2種類に分けています。1つはコードから見えるローカルのコンテキストで、ツール関数が動くときに必要になるデータや依存関係を指します。もう1つはLLMが見るコンテキストで、モデルが応答を生成するときに実際に目にするデータです。

設計対象になるのは、LLMが見るコンテキストのほうだけです。OpenAIはLLMへデータを渡す手段を4つに整理しており、指示文（システムプロンプト）、呼び出し時の入力メッセージ、必要になった時点でLLM側から要求させる関数ツール、検索やWeb検索という並びになります。渡す先が4つあるという前提を持つと、「プロンプトに書く」以外の選択肢が見えます。

コンテキスト次第でAIが業務にフィットし切るかが変わります。AI開発時には必ず必要になる知識・スキルだ、というのが私の実務での位置づけです。

AIエージェントそのものの定義と、ワークフローとの境界は本記事の対象外です。実行の流れを誰が制御するかという判定はAIエージェントとは？ワークフローとの違いと実務で使う条件で解説しています。

プロンプトエンジニアリングと何が違うのか？

対象範囲が違います。プロンプトエンジニアリングは指示文の書き方と組み立てを最適化する手法であり、コンテキストエンジニアリングは指示文を含めて、推論のたびに何を載せるかを管理する設計です。1回の入力を磨く作業と、状態を持ち続けるシステムを設計する作業の違いになります。

Anthropicは同じブログで2つを並べて定義しています。プロンプトエンジニアリングは「最適な結果を得るためにLLMへの指示を書き、組み立てる手法」であり、コンテキストエンジニアリングは「推論中に最適なトークンの集合を選び、維持するための戦略群」です。後者の定義には、プロンプトの外側に入り込みうる情報がすべて含まれます。

なぜ管理が必要になるかの根拠も、Anthropicが示しています。コンテキストウィンドウのトークン数が増えるほど、モデルがそこから情報を正確に想起する能力は落ちます。同社はこの現象をコンテキストの腐敗（context rot）と呼び、LLMには新しいトークンが入るたびに消費される「アテンションの予算（attention budget）」があると説明しています。

予算に限りがあるという前提に立つと、載せる情報の取捨選択そのものが設計課題になります。なお、長文コンテキストを使うかRAGを使うかという採否の判断は本記事の対象外です。3つの選択肢の選び方はRAGとファインチューニングの違いは？選び方を解説で整理しています。

用語が分かれた理由は、エージェント化にあります。エージェントは自分でツールを呼び、返り値を受け取り、その結果を次の推論に持ち越します。この仕組みから考えると、人が書いた指示文だけでは制御できない情報が自動的に積み上がるため、書き方の工夫が届かない領域が生まれます。

システムプロンプトはどこまで具体的に書くべきか？

行動を導けるだけ具体的で、なお判断の余地を残せる高さに置きます。Anthropicはこの高さを「right altitude」と呼び、2つの失敗の型の間にある領域だとしています。片方は複雑で壊れやすいロジックをハードコードすること、もう片方は曖昧で高水準すぎる指示を与えることです。

Anthropicが示す条件は「行動を効果的に導けるほど具体的で、かつモデルに強い判断の指針を与えられるほど柔軟」というものです。想定される分岐をすべて書き出す方向に寄せると、条件が1つ変わるたびにプロンプトが壊れます。逆に「適切に判断してください」まで抽象化すると、行動を決める手がかりが残りません。

例示は何件入れるべきか？

件数ではなく、多様さと代表性で選びます。Anthropicは、想定されるエッジケースを羅列してプロンプトに詰め込むやり方をよくある失敗として挙げ、期待される振る舞いを的確に表す、多様で代表的な例を厳選することを推奨しています。

Anthropicは、LLMにとって例示は千の言葉に値する「絵」だと述べています。この位置づけから考えると、例を足すかどうかの判断基準は「まだ表現できていない振る舞いの型があるか」になります。同じ型の例を3つ並べても、消費するトークンが増えるだけで伝わる情報は増えません。

情報は事前に全部渡すべきか、必要になってから取りにいかせるべきか？

両方が選択肢になります。Anthropicは、推論の前に検索して埋め込む方式と、軽量な識別子だけを持たせて実行時にツールで読み込ませる「just in time」方式を並べています。そのうえで、速度が要る一部を先に取得し、残りは自律的に探索させるハイブリッドを最も有効な形として挙げています。

just-in-time方式でエージェントが持つのは、ファイルパス・保存済みのクエリ・Webリンクといった軽量な識別子です。Anthropicは、エージェントがそれらの参照を使って実行時にデータを動的に読み込むと説明しています。人間が情報の全体を暗記せず、外部の整理の仕組みを持つのと同じ構図です。

Anthropicは、just-in-time方式の利点を「progressive disclosure（段階的な開示）」と呼んでいます。探索を通じて、関連するコンテキストを少しずつ見つけていける状態を指します。最初から全部を渡さないため、必要になった分だけがコンテキストに載ります。

事前投入とjust-in-timeは、どちらが優れているという関係にはありません。事前投入は毎回同じものを見せるため再現性が高くキャッシュも効きますが、質問と無関係な情報も必ず載ります。just-in-timeは載る量を抑えられますが、探索のたびに往復が増えて応答は遅くなります。

この仕組みから考えると、判断軸は参照対象の構造にあります。文章として書かれた大量のドキュメントを横断するなら、意味の近さで一気に絞り込める事前検索が向きます。テーブルやファイル階層のように構造が定まっている対象なら、条件を指定して取りにいける探索型が向きます。

事前投入か探索型かを選ぶ前に、注入そのものの設計が要ります。RAGにすべてを任せるのではなく、段階的なコンテキスト注入などでAIを制御するアプローチも必要になってきた、というのが私の現在地です。探させ方の工夫と同じだけ、コンテキストウィンドウに情報を入れる設計が重要になります。

使い分けの基準に置いているのは、探し先が構造を持っているかどうかです。構造化データをエージェントが探すというアプローチの方が精度が出る場合もあり、Claude CodeなどのようにGrepで持ってくるような挙動も選べます。ベクトル検索という意味でのRAGは、大量のドキュメントをサーチするようなものであれば非常に有効性が高い、というのが私の見方です。

AI活用の場面では、判断基準を統一し相談相手になる「上司AI」のようなものを作るというユースケースがあります。これはまさにコンテキストエンジニアリングの所業だ、というのが私の受け止めです。

特に大事なのは、常に参照させるべきコンテキストと、この場合はこのコンテキスト、この場合はこれ、というユースケースに合わせて切り替えるコンテキストの区別です。切り替えないとコンテキスト汚染にもつながるので、私の実務では最初に分けて設計します。

RAGはコンテキスト設計のどこに位置づくのか？

事前投入側の代表例として位置づきます。RAGは推論の前に関連文書を検索し、その結果をコンテキストへ埋め込む仕組みであり、コンテキストエンジニアリングと対立する概念ではありません。何をどのタイミングで載せるかという設計の中で、RAGは「先に載せる」を担当します。

RAGの仕組みそのものは本記事の対象外です。基本構造はRAGとはなにか？なぜ企業活用で必須なのか？、検索側で何が起きているかはベクトル検索とは？仕組みとRAGでの役割で解説しています。埋め込みが何を近いと判断しているかを押さえると、事前投入で何が載って何が落ちるかを読めるようになります。

事前投入したRAGの精度が出ないときの切り分けも本記事の対象外です。検索側と生成側のどちらが失敗しているかを分ける手順はRAGの精度が上がらない原因は？検索・データ・生成で切り分けるで解説しています。

全部プロンプトに入れて済むのはどんな場合か？

参照させたい知識の総量が小さい場合です。Anthropicは「Introducing Contextual Retrieval」で、知識ベースが20万トークン（資料にして約500ページほど）より小さいなら、RAGのような手法を使わずに知識ベース全体をプロンプトへ入れてよいとしています。数値は同社のモデルを前提とした目安です。

全部入れるかどうかの判断には、精度以外の条件も絡みます。総量が閾値を下回っていても、毎回の呼び出しで同じ量のトークンを消費し続ける点は変わりません。長文コンテキストを採るか検索を組むかという選定そのものはRAGとファインチューニングの違いは？選び方を解説が担当します。

エージェントに探させるとき、何をコンテキストへ入れるのか？

データの置き場所を教えるだけでは足りません。どんな問い合わせのときにどれを見るのかという対応関係と、実際の取り出し方の例までを渡す必要があります。Anthropicも、エージェントのフォルダとファイルの構造そのものがコンテキストエンジニアリングの一形態になると述べています。

Anthropicは「Building agents with the Claude Agent SDK」で、ファイルシステムをモデルのコンテキストへ引き込みうる情報の集合として扱っています。ログのような大きなファイルに当たったとき、Claudeは全体を読み込まず、grepやtailで必要な部分だけを選んで取り出します。

Anthropicが示すエージェントのループは、コンテキストを集める・行動する・作業を検証する、の3段です。3段のうち最初でつまずくと、後続の2段は成立しません。

コンテキストを集める段が機能するかどうかは、探し先の構造をどこまで言語化して渡せたかで決まります。日本語の解説で「メタデータを整備する」と書かれる部分を分解すると、渡すべき情報は3階層になります。

定義だけを渡した状態は、使えるが、いつ使うか分からない道具をエージェントに持たせた状態と同じです。この仕組みから考えると、定義の網羅性を上げるより先に、対応関係を1件でも書いたほうが選択の失敗は減ります。

3階層のうち最も抜けやすいのが実例です。例えば、社内の在庫データベースを参照させるエージェントで、テーブル定義と対応関係までは渡したものの、日付範囲の絞り方や結合の順序を渡していないという状態が考えられます。定義上は到達できる問い合わせでも、取り出し方を自力で組み立てる回数が増えるほど、失敗の起きる箇所も増えます。

同じ失敗の型は、ツール設計でも起こります。Anthropicがツールの失敗として挙げる「どれを使うか判断できない状態」と、データの対応関係を渡していない状態は同じ構造です。データもツールも、渡すべきものは対象の一覧ではなく、選択の基準まで含めた組になります。

定義を渡す工程そのものが、想像より重くなります。私の実務でいちばん見落としがちだったのは、エージェント検索させる時は意外と丁寧にデータテーブルを教える必要があり、コンテキストを注入する必要があるという点でした。

データテーブルの定義を教えるだけでは足りませんでした。どんなクエリがきたらそのテーブルをみるのか、このクエリにはこんなクエリを使うべし、というような一種のSQL例などを入れ込むことが必要だった、というのが私の実務での結論です。

緻密さがどこで要るかは、やってみるまで読めませんでした。予想外のポイントで意外といけるのかと思いきや、なかなか緻密なコンテキスト注入が必要となる。私の実務では、そこが面白いポイントかつ愚直にやらないといけないところでした。

参照させるデータそのものの整備手順は本記事の対象外です。重複や版違いの扱い、非テキストの処理、粒度の決め方はRAGにおけるデータクレンジングの重要性で扱っています。本記事は、整備済みのデータをエージェントにどう渡すかまでを担当します。

ツールはいくつまで渡してよいのか？

数の上限では決めません。人間の技術者がどれを使うべきか即答できるかどうかで決めます。Anthropicは、機能を盛り込みすぎたツール群と、どれを使うかが曖昧になる設計を最も多い失敗の型として挙げ、人が判断できない状況でAIに期待はできないと述べています。

Anthropicの原文は「ある状況でどのツールを使うべきかを人間のエンジニアが断定できないなら、AIエージェントにそれ以上を期待することはできない」というものです。判定に使える基準として具体的で、ツール一覧を眺めながらそのまま適用できます。同社は、エージェントには実用最小限のツール集合を持たせることを推奨しています。

Anthropicは別の技術ブログ「Writing effective tools for agents」でも、ツールは多ければよいというものではないと述べています。同記事が挙げる対処は2つです。1つは複数の操作を1つのツールに統合すること、もう1つは関連するツールを共通の接頭辞でグループ化し、名前空間で区別できるようにすることです。

ツールの説明文そのものも設計対象です。Anthropicは、ツールの説明文へのわずかな改善が劇的な効果を生みうると述べています。ツールを削らなくても、どんなときに使うのかを説明文に1行足すだけで、選択の失敗が減る余地があります。

ツール定義がコンテキストを消費する点も見落とせません。ツールの一覧と説明文は、実データを渡す前からコンテキストウィンドウに載っています。この仕組みから考えると、道具を増やす行為は、そのぶん実データに使える枠を削る行為でもあります。

ツールをむやみやたらに増やすことで性能が悪化するということは起きうる、というのが私の実務での実感です。ツールの設計・選択は性能にかなりつながるところなので、気を使うべしという前提で組んでいます。

ツールの返り値はどう設計するのか？

高シグナルな情報だけを返します。Anthropicは、ツールの返り値について、柔軟性より文脈上の関連性を優先すべきだと述べています。実装の手段としては、ページング・範囲指定・フィルタ・切り詰めを、妥当な既定値とともに組み合わせることを挙げています。

返り値の詳しさを呼び出し側で選べるようにする方法もあります。Anthropicが示すのは、詳細版と簡潔版を引数で切り替えられるようにした例で、同社のSlack向けMCPサーバでの計測では簡潔版のトークン消費が詳細版の約3分の1でした。数値は同社の実装と計測条件に紐づくもので、返り値を絞れば常に3分の1になるという意味ではありません。

会話が長くなったコンテキストはどう維持するのか？

3つの手があります。上限が近づいたら要約して引き継ぐ圧縮、コンテキストの外にメモを書き出す外部メモリ、役割ごとに別のコンテキストで走らせるサブエージェントです。Anthropicはこの3つを、長い時間軸のタスクを扱うための手法として整理しています。

Anthropicが圧縮（compaction）と呼ぶのは、コンテキストウィンドウの上限に近づいた会話を要約し、その要約で新しいコンテキストウィンドウを立ち上げ直す手法です。同社が構造化されたメモ書き（structured note-taking）と呼ぶのは、エージェントがコンテキストウィンドウの外にあるメモリへ定期的にメモを書き出し、後の時点で必要な分だけ引き戻す手法を指します。

古くなった内容を選んで消すという手もあります。Anthropicは公式ドキュメントで、会話履歴が伸びるにつれて特定の内容を選択的に消去する仕組みをコンテキスト編集として提供しており、その前提を「コンテキストは収穫逓減を伴う有限の資源であり、無関係な内容はモデルの焦点を鈍らせる」と説明しています。

消す対象としてAnthropicが挙げるのは、ファイルの内容や検索結果のように、Claudeが処理し終えた後は不要になる古いツール結果です。同社APIの既定値では、入力が10万トークンに達した時点で消去が始まり、直近3件のツール利用は残ります。数値は製品の既定値であり、コンテキスト設計一般の推奨値ではありません。

履歴をどこまで持つかを決める対象として扱う点は、発行元が違っても共通しています。OpenAIは公式ドキュメントで、複数回の実行をまたいで会話履歴を自動的に保つセッションの仕組みを示す一方、履歴の保持をサーバ側に任せる指定とは同じ実行の中で併用できないと明記しています。同社のセッションでは、取り出す履歴を直近N件に限定する指定もできます。

圧縮と外部メモリはどう使い分けるのか？

役割が違うため、併用が前提になります。Anthropicのメモリツールは、会話をまたいで情報を保存・参照するための仕組みで、メモリファイルのディレクトリにClaudeが情報を書き出し、後から読み戻せるようにするものです。同社は、圧縮とメモリを両方使う構成を長時間動くエージェントに勧めています。

Anthropicが示す分担は明快です。圧縮は作業中のコンテキストを小さく保つ役割を持ち、メモリは要約で失われては困る情報を残す役割を持ちます。メモリは必要になった時点で読み出す方式を支えるため、関連しそうな情報を最初から全部載せる必要がなくなります。

前提として置かれている想定も参考になります。Anthropicのドキュメントによれば、メモリツールを使うときにシステムプロンプトへ自動追加される指示には、コンテキストウィンドウはいつリセットされてもおかしくないと想定せよ、という文言が含まれます。中断を前提に、進捗をコンテキストの外へ書き出しておく設計です。

サブエージェントに分けると何が変わるのか？

各担当がきれいなコンテキストで作業でき、親には要約だけが返ります。Anthropicは、専門化したサブエージェントがクリーンなコンテキストウィンドウで焦点の定まったタスクを扱い、自分の作業について凝縮され蒸留された要約だけを返すと説明しています。同社はサブエージェントの利点として、並列化とコンテキストの分離の2つを挙げています。

分割の効果はコンテキストの分離にあります。この仕組みから考えると、分ける単位はタスクの粒度ではなく、必要なコンテキストが重ならない範囲になります。同じ資料を両方が読まないと進まない2つの作業を分けても、同じ情報が2つのコンテキストへ二重に載るだけで、削減にはつながりません。

よくある質問

コンテキストウィンドウが大きいモデルに変えれば、この設計は不要になりますか？

不要にはなりません。Anthropicは、コンテキストウィンドウのトークン数が増えるほど、そこから情報を正確に想起する能力が落ちると述べています。枠が広がっても、載せた情報のどれにモデルの注意が向くかという問題は残るため、何を載せて何を載せないかの取捨選択は枠の大小と別に必要になります。

コンテキストエンジニアリングは誰の仕事ですか？

エンジニアだけの仕事ではありません。エージェントに渡す情報のうち、どんな問い合わせのときにどのデータを見るのかという対応関係と、実際の取り出し方の例は、業務を知っている側でなければ書けません。実装は技術側が担い、対応関係と例の言語化は業務側が担う、という分担が現実的な形になります。

社内にドキュメントが整っていない場合、何から着手すればよいですか？

参照させたい文書の棚卸しからです。何を根拠に答えさせたいのかが決まっていない状態では、事前投入にも探索型にも載せる対象が定まらないため、整備の対象を1つの業務に絞ってから広げます。文書の重複や版違いの整理、非テキストの扱いといった手順はRAGにおけるデータクレンジングの重要性で扱っています。

コンテキストエンジニアリングは何から学べばよいですか？

設計対象の全体像を先に押さえるのが近道です。システムプロンプト・ツール定義・外部データ・会話履歴・メモリの5つを分けて捉えられれば、不具合が起きたときに触る場所を絞れます。そのうえで、事前投入と必要時取得の使い分け、ツールの絞り方という順に進めると、依存関係に沿って積み上がります。

まとめ

コンテキストエンジニアリングとは、LLMが推論するたびに何を載せるかを取捨選択し、維持する設計です。設計対象はシステムプロンプト・ツール定義・外部データ・会話履歴・メモリの5つで、不具合がどの要素で起きているかを決めれば触る場所が絞れます。

実務では、並行してコンテキストの収集を考える必要があります。会議データやチャットデータなどのコンテキストを収集して、うまく集める仕組みを考えることが大事だというのが、私が現場で置いている前提です。コンテキストをどのように扱い、コントロールするのかはすごく大事になります。

Anthropicが結びに置いた原則は、望む結果が出る確率を最大化する、高シグナルなトークンの最小の集合を見つけることです。足す設計ではなく、削る設計です。

設計した内容を社内データで動かす手順は本記事の対象外です。着手から評価までの進め方はRAG導入の手順は？社内データで失敗しない進め方で扱っています。

ABOUT ME

ぬるったん

元データサイエンティスト、現在は非テック企業のCTO兼CAIO｜AI活用の企画から実装まで一気通貫で担当｜約500名規模の企業で100人規模のデータ組織のマネージャーを経験｜面接担当は100人以上｜未経験からデータサイエンティストに転職した経験あり

BLOG：https://digital-transformation-blog.com