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

システムプロンプトは、エージェントの基礎的なコンテキスト、すなわちそのアイデンティティ、能力、制約、行動ガイドラインを確立します。ユーザープロンプトが各インタラクションで変化するのに対し、システムプロンプトは比較的安定し、持続的な「パーソナリティ」およびルールブックとして機能します。効果的なシステムプロンプトは、具体性（曖昧な行動を防御するほど明確）、柔軟性（多様なシナリオを扱えるほど一般的）、簡潔さ（コンテキストウィンドウの空間を保つほど簡潔）という3つの競合する要求のバランスを取ります。ベストプラクティスには以下が含まれます。

• エージェントの役割を明確に定義する（「あなたは財務アナリストのアシスタントです...」）
• 抽象的なルールではなく、望ましい行動の具体例を提供する
• 構造化された区切り文字（XMLタグ、マークダウンセクション）を使用して指示を整理し、モデルの理解を向上させる
• 重要な制約（安全ルール、出力フォーマット要件）を、モデルの位置バイアスを考慮して、目立つ位置に配置する。

高度な技術には、ランタイムコンテキストに基づいてアクティブ化する条件付き指示（例：「ユーザーが個人情報について尋ねたら、プライバシーポリシーにリダイレクトする」）や、エージェントの推論プロセスをガイドするメタ指示（「分析を提供する前にステップ別に考える」など）が含まれます。システムプロンプトは、特にコンテキストウィンドウの競合に弱いです。会話履歴、ツールの出力、取得したデータが蓄積されるにつれて、貧弱に設計されたシステムプロンプトは、モデルの有効な注意持続期間から押し出され、エージェントが徐々にそのコアとなる指示を忘れるような行動のドリフトを引き起こします。

長期記憶により、AIは複数のセッションや会話にわたって情報を保持できるようになります。一時的でセッションの終了時に失われる短期記憶とは異なり、長期記憶は、AIがユーザーの好み、過去のやり取り、学習した事実を将来の参照のために記憶することを可能にします。

状態と履歴は、現在のセッションにおけるエージェントのワーキングメモリを構成します。進行中のインタラクションの中で言われたこと、行われたこと、学んだことの記録です。この短期記憶により、会話の継続性が確保されます。エージェントは、ユーザーにコンテキストを繰り返させることなく、以前のやり取りを参照できます。ただし、会話履歴はインタラクションの長さに応じて直線的に増加し、コンテキストウィンドウをすぐに消費してしまいます。

効果的なコンテキストエンジニアリングには、能動的な記憶管理戦略が必要です。要約は、重要な事実と決定を維持しながら、古いやり取りを簡潔な表現に圧縮します。ウィンドウ処理は、最近のコンテキストが最も重要であるという前提の下、以前の履歴を破棄して、最新のN件のメッセージのみを保持します。選択的保持は、ヒューリスティックを用いて重要な情報（ユーザーの好み、確立された事実、未解決の質問）を特定し保存しつつ、日常的な会話のつなぎ部分をカットします。

より洗練されたアプローチでは、エージェントが重要な状態を外部ストレージに書き込み、必要に応じて取り出すエピソード記憶構造を使用します。これは、人間がアクティブワーキングメモリに会話全体を保持するのではなく、必要なときに特定の詳細を呼び出せることを模倣したものです。課題は一貫性の維持にあります。過度に積極的なプルーニングはエージェントが重要なコンテキストを「忘れて」間違いを繰り返す原因となり、不十分な圧縮はコンテキストのオーバーフローとパフォーマンスの低下につながります。

Retrieval-Augmented Generation（RAG）には、AIが社内文書や公開Webサイトなどの知識ベースから、データを「ジャストインタイム」で取得することが含まれます。RAGは、AIが元々訓練されていない情報を用いて質問に答えることを可能にし、それによってAIの対応が最新かつ正確であることを保証します。

セマンティックチャンキングは、情報を論理的に構造化することで検索を改善します。セマンティックチャンキングでは、テキストを任意の固定サイズの断片に分割するのではなく、関連する概念をグループ化します（段落、機能、論理セクションなど）。関連するチャンクが検索されると、そのチャンクの周辺も検索対象に含まれます。これにより、LLMはより首尾一貫した完全な文脈を得ることができ、より効果的に推論し、断片的な情報による問題を軽減することができます。

単一の検索方法に依存すると失敗することが多いため、ハイブリッド検索はコンテキストエンジニアリングにとって重要です。ベクトル検索は概念的に類似した情報を見つけるのに優れていますが（「夏服」は「暖かい季節の服」など）、特定の正確な用語を見逃す可能性があります。キーワード検索（BM25など）は完全一致を見つけるのに優れていますが（「SKU-123AB」など）、同義語では失敗します。ハイブリッド検索は、両方を1つの統一されたクエリに組み合わせることで、LLMがユーザーの概念上の意図と重要なキーワードの両方を捉えて、可能な限り正確でバランスの取れたコンテキストを受け取るようにします。

ランク付けの再調整 は、スケールの大きい検索に内在する「速度と正確さ」のトレードオフを解決します。初期に検索する処理（ハイブリッド検索と同様に）は、関連性のある大量の文書（例：トップ100）を迅速に取得するよう最適化されています。次に、再ランク付けモデル（通常は計算コストは高くなりますが、はるかに正確です）を使用して、この小さなサブセットのみを再スコアリングします。コンテキストエンジニアリングにおいて、これは非常に重要です。なぜなら、最も関連性の高いスニペットをコンテキストウィンドウの最上部に配置することで、途中で見失われる問題を軽減し、LLMの注目を最高品質の情報に集中させることが不可欠だからです。

ツールは、外部システムとのやり取り（コードの実行、データベースのクエリ、APIの呼び出し、ファイルの操作など）を可能にすることで、テキスト生成以外のエージェントの機能を拡張します。コンテキストエンジニアリングの観点から見ると、ツールは固有の課題を生み出します。これは、各ツールにコンテキストウィンドウのスペースを消費する説明（名前、目的、パラメーター、使用例）が必要となる点です。ツールライブラリが増えるにつれて、この「ツールコンテキストのオーバーヘッド」は重要になります。100のツールを持つエージェントは、ユーザーの実際のタスクが始まる前に、利用可能な機能を説明するだけでコンテクストウィンドウの30%–40%を費やす可能性があります。

効果的なツールエンジニアリングは以下のいくつかの原則に従います。

• ツールの説明は簡潔かつ明確に： ツールの目的、必要なパラメータとその種類、1つの標準的な例を含めます。
• ツールを構成可能に設計：小さくて焦点を絞ったツール（例：「search_documents」、「summarize_text」）は、複数のシナリオを処理しようとするモノリシックツールよりも柔軟に組み合わせることができます。
• 選択的読み込みを可能にするためのツールカテゴリーや名前空間の実装：財務分析を行うエージェントには画像処理ツールは不要です。
• ツールの結果フィルタリングを活用：生のAPI応答ではなく、エージェントに必要な情報のみを返します。データベースクエリツールは、完全なSQL結果セットではなく、「関連する3つのトランザクションが見つかりました。合計金額は$4,532です」と返すべきです。

適切に設計されたツールでは、説明にエラー処理も含まれており、ワークフローを通じてエラーを連鎖させるのではなく、障害から適切に回復する方法をエージェントに教えます。

エージェント型検索

エージェント型検索は専用の「サブエージェント」ツールで、複雑で多段階の調査を独自のコンテキストで実行します。例えば、自然言語のリクエストを正確なESQLクエリに変換し、データを検索し、メインエージェントに簡潔なサマリーのみを返すことで、その作業メモリをクリーンに保つことができます。

ドメイン固有のワークフロー

ドメイン固有のワークフローは、高リスクで予測可能なビジネスプロセス向けに設計された、事前定義された決定論的なツールチェーンです。ここでは、探索的な柔軟性よりも信頼性と一貫性が重視されます。一般的なエージェントが各ステップを動的に推論するのとは異なり、これらのワークフローは厳格で検証されたシーケンスに従います。（例：「お客様の本人確認 → 信用履歴の確認 → 外部規制審査 → リスクスコアの計算 → レポートの作成」）各ステップには明確な成功基準、エラー処理、ロールバック手順があります。

この厳格さは意図的なものであり、LLMベースの推論に固有の予測不可能性によって、財務承認、医療診断、規制遵守などのミッションクリティカルな操作が影響を受けないようにします。コンテキストエンジニアリングの観点から見ると、ドメインワークフローは自由度を減らすことでエージェントのタスクを簡素化します。エージェントは、すべての可能なツールと戦略に関するコンテキストを必要としません。必要なのは、現在のワークフロー ステップに必要な特定の情報だけです。この焦点を絞ったコンテキストにより、正確さと効率が共に向上します。

実装には通常、ステートマシンまたは有向非巡回グラフ（DAG）が含まれ、LLMは可変要素（ユーザーインプットの解析、データソースの選択、自然言語による要約の生成）を処理し、決定論的ロジックはプロセスフロー全体を制御します。トレードオフとして、適応性が低下します。これらのワークフローは既知のシナリオでは優れていますが、エッジケースが事前定義されたパスから外れると苦労します。

動的ツールディスカバリー

動的ツール検出は、エージェントが大規模なツールライブラリにアクセスするときに発生する「プロンプトの肥大化」問題に対処します。この戦略では、システムプロンプトに何百ものツールの説明をリストするのではなく（これにより貴重なコンテキストウィンドウのスペースが消費され、ツール選択の精度が低下します）、ツールのメタデータに対するセマンティック検索を使用して、実行時に関連する機能のみを取得します。

エージェントがタスクを受け取ると、タスクの説明を入力としてツールレジストリを照会し、その特定のコンテキストに最も意味的に類似したツールを3〜5個取得します。このアプローチは、ジャストインタイムのデータ取得を反映しています。ツールは必要になるまで外部ストレージに残り、エージェントの注意は網羅的なカタログに絞られるのではなく、適用可能な機能に集中します。MCP（モデルコンテキストプロトコル）のようなプロトコルは、ツールを動的に検出、理解、起動できるレジストリを提供することで、このパターンを標準化します。ただし、動的な検出では遅延（検索操作自体）が発生するため、ツールの説明があいまいな場合にエージェントが最適でないツールを選択したり行き止まりに陥ったりしないように注意深いエンジニアリングが必要になります。

ユーザープロンプトは、エージェントの動作をトリガーし、即時のタスクコンテキストを定義する直接入力です。システムプロンプト（比較的静的）とは異なり、ユーザープロンプトは各インタラクションで変化し、ほとんどのLLMアーキテクチャにおいて最も高い注意度の重みを持ちます。この位置的なバイアスは、ユーザープロンプトがしばしばコンテキスト内の他の場所にある矛盾する情報を上書きすることを意味します。

効果的なコンテキストエンジニアリングでは、ユーザープロンプトを単なる質問以上のものとして扱います。システムプロンプトを肥大化させることなく、検索やツールの選択をガイドする明示的なコンテキストヒント（タイムスタンプ、ユーザー設定、セッション状態）を含めることができます。ステートフルエージェントの場合、ユーザープロンプトはセッション固有の情報が注入される入口となります。例えば、「四半期指標に関する会話を踏まえて...」とすると、最近取得した財務データを優先するようにエージェントにシグナルを送ることになります。ただし、ユーザープロンプトはコンテキストの最も予測不可能な要素でもあり、曖昧、矛盾、または敵対的になる可能性があります。コンテキストエンジニアリングでは、不明瞭なリクエストを再定式化するクエリ理解モデル、プロンプトインジェクションの試みを検出する安全フィルター、入力のみからユーザーの意図を確実に推測できない場合のフォールバック戦略を通じて、この変動性を考慮する必要があります。

構造化された出力とは、AIがJSON、XML、表などの特定の方法でフォーマットする必要がある情報を指します。構造化された出力を定義することで、AIの応答に一貫性が生まれ、他のプログラムやシステムで簡単に使用できるようになります。

これらの概念についてより深く知りたい方は、ブログ記事「 コンテキストエンジニアリングの概要」をご覧ください。

コンテキストエンジニアリングの手法は、LLMをサポートするために構築された体系的なパイプラインの設計として理解するのが最も適切です。このパイプラインは、さまざまなコンポーネントをアドホックに組み合わせるのではなく、特定のタスクに合わせて調整され、ループの各段階でモデルとの間の情報の流れ全体を管理するように設計されています。このパイプラインは通常、3つのコアステージに分かれています。

1. コンテキストの取得と生成：この段階では、ベクトルデータベースから文書を取得したり、構造化SQLデータベースを照会したり、外部サービスへのAPIコールなど、多様なインプットから生データを積極的に調達します。
2. コンテキスト処理: 一度収集されると、生の情報は最適化されます。これは、チャンキング、要約、圧縮、構造化などの技術を使用して、データの信号対雑音比を最大化するための変換を含みます。
3. コンテキスト管理：この最終段階では、情報が複数のインタラクションにわたってどのように格納され、更新され、利用されるかを管理します。ステートフルなアプリケーションの構築には不可欠であり、短期（セッション）および長期（永続的）メモリのための戦略を含みます。

最も強力な戦略は、情報をコンテキストウィンドウの外側に保持し、エージェントが必要な時に「ジャストインタイム」で取得することです。これは人間の働き方を反映しています。私たちはライブラリ全体を記憶するのではなく、検索エンジンとファイリングシステムを使用して、必要に応じて必要なものを見つけます。

AIエージェントにとって、これは外部のナレッジベースにクエリを送信することを意味します。しかし、適切な情報を見つけることは大きな課題です。データが増加するにつれて、単純なセマンティック検索は信頼性が低くなる可能性があります。効果的な選択には、多くの場合、キーワード、セマンティック、グラフベースの検索など、複数の検索手法を組み合わせて、膨大で複雑なデータセットから必要なコンテキストを正確に特定するハイブリッドアプローチが必要です。

この戦略により、エージェントは「スクラッチパッド」ファイルや専用データベースなどの外部メモリに書き込むことで情報をオフロードできます。例えば、エージェントは多段階のプランをファイルに保存して後で参照することで、プランが混雑したコンテキストウィンドウから押し出されるのを防御することができます。これにより、エージェントは作業メモリを乱雑にすることなく、長時間実行されるタスクの状態を維持し、進行状況を追跡できるようになります。

圧縮技術は、重要な情報を保持しつつ、コンテキストウィンドウ内のトークン数を削減します。

• 要約：長い会話や文書を簡潔な要約に凝縮するためにLLMを使用します。例えば、ツールの完全でトークンの多い出力は、その結果の短い要約に置き換えることができます。
• トリミング：会話内の最も古いメッセージを削除したり、不要になった冗長なツール出力をクリアしたりするなど、ハードコードされたルールを使用してコンテキストをフィルターします。

非常に複雑なタスクの場合、単一のエージェントでは負担が大きくなる可能性があります。分離には、問題を細分化し、それぞれが独自の明確で焦点を絞ったコンテキストウィンドウを持つ、サブタスクを専門の「サブエージェント」に割り当てることが含まれます。リードエージェントがこのチームを調整し、各専門エージェントから凝縮された最終出力のみを受け取ります。このアプローチにより、各エージェントのコンテキストの関連性が保たれ、管理しやすくなり、複雑な調査や分析タスクの全体的なパフォーマンスが向上します。

これらの原則に従うことで、コンテキストエンジニアリングはLLMに成功の可能性を最大化する最小限の 高信号トークンセット、すなわち関連性のあるアウトプットを提供することを目指します。

コンテキストエンジニアリングは、その基礎において、LLMの注意予算が有限であるという基本的な制約によって形成されます。コンテキストウィンドウ（トークンで測定）は、モデルが一度に処理できる情報の最大量を定義します。最新のモデルはますます大規模なコンテキストウィンドウ（10万、100万、さらには200万トークン）をサポートするようになっていますが、単にこのスペースを埋めるだけでパフォーマンスの向上が保証されるわけではありません。

LLMはTransformerアーキテクチャで動作し、すべてのトークンが他のすべてのトークンに対応する必要があります。コンテキストが大きくなると、計算オーバーヘッドが発生し、専門家が「コンテキスト腐敗」と呼ぶ状態になります。つまり、情報負荷が増加するにつれて、焦点を維持し、特定の詳細を思い出すモデルの能力が低下します。この現象は人間の認知の限界を反映しています。情報が多いからといって、必ずしもより良い意思決定ができるとは限りません。

ウィンドウを単純に拡張するだけでは、重大な課題が生じます。

• コストと遅延の増加：Transformerアーキテクチャの注意メカニズムの計算複雑性はシーケンス長に対して二次関数的に（$O(n^2)$）増加し、コンテキストが大きくなるほどコストと所要時間が指数関数的に増加します。
• パフォーマンス低下（「Lost in the Middle」）：LLMは、長いコンテキストウィンドウの最初または最後にある情報に対しては強い想起を示しますが、中間にある情報に対してはパフォーマンスが著しく低下します。
• ノイズと注意散漫： より大きなコンテキストウィンドウは、無関係な「ノイズの多い」情報を含む可能性を高め、モデルを混乱させ、出力の質を低下させる可能性があります。これはしばしば「干し草の中の針」問題と呼ばれます。

このパラドックスは、単なる力ずくではない、インテリジェントなキュレーションの必要性を強調し、コンテキストエンジニアリングを精巧な技術として位置付けています。

コンテキストエンジニアリングの主な目的は、エージェントがタスクを正常かつ確実に完了できるようにすることです。正確で関連性のあるコンテキストと適切なツールがなければ、エージェントはハルシネーションを起こしたり、間違ったツールを選択したり、複数ステップの計画を実行できなかったりして失敗します。これはコンテキストエンジニアリングが解決する基本的な問題です。

コンテキストエンジニアリングシステムの出力品質とは、エージェントの応答がユーザーの意図、事実の正確性、タスク要件とどの程度一致しているかを指し、LLMが自然に達成する単なる流暢さや一貫性とは異なります。高品質の出力は、高品質の入力コンテキストに大きく依存します。つまり、「ゴミを入れたらゴミが出てくる」の原則がそのまま当てはまります。

コンテキストエンジニアリングは、いくつかのメカニズムを通じて出力品質を向上させます。

• 検索品質は、エージェントが誤認や古いトレーニングデータに頼るのではなく、正確で関連性の高いソース資料にアクセスすることを保証します。
• コンテキスト構造は、モデルが情報をどれだけ効果的に抽出し、合成できるかに影響します。
• 適切にチャンク化され、意味的に一貫性のあるコンテキストは、断片化されたスニペットよりも正確な推論を生み出します。
• シグナル・ノイズ比が重要：5件の非常に関連性の高いドキュメントを含めると、同じ5件にさらに20件のわずかに関連するドキュメントを加える場合よりも優れた効果が得られます。これは、無関係な情報がモデルの注意をそらすためです。

出力品質は、システムプロンプトの指示の明確さと明示的なフォーマット要件（JSONのような構造化された出力は解析エラーを減らします）にも依存します。品質を測定するには、タスク固有の評価が必要です。RAGシステムの場合は事実の正確さ、エージェントのタスク完了率、会話システムの場合はユーザー満足度スコアです。コンテキストエンジニアリングは、入力と出力の関係を観察可能かつ調整可能にすることで、体系的な品質向上を可能にします。どのコンテキストの組み合わせがより良い出力を生み出すかを測定し、それに応じて検索、ランキング、フィルタリングを最適化できます。

コンテキストウィンドウ内のすべてのトークンには、コンピューティングリソース、API料金、レイテンシというコストがかかります。コンテキストエンジニアリングは、次の3つすべてに直接影響します。

• コスト最適化：プロンプト内の不要なトークンを減らすことで、大規模なアプリケーションではAPIコストを桁違いに削減できます。
• レイテンシー削減：コンテキストをより小さくし、焦点を絞ることで、より速い推論時間とより応答性の高いアプリケーションを実現できます。
• 品質の改善：ターゲットを絞った高信号コンテキストは、大量で焦点の定まっていない情報ダンプよりも一貫して優れています。

本番環境のAIシステムは強靭でなければなりません。コンテキストエンジニアリングが不十分だと、次のようないくつかの障害モードが発生します。

• コンテキスト汚染：ハルシネーションやエラーがコンテキストに組み込まれ、その後のインタラクションで複雑化してしまうこと
• 目標からのドリフト：無関係な情報が蓄積され、エージェントが当初の目標を見失う場合
• キャパシティオーバーフロー：コンテキストウィンドウが優先度の低いデータで満たされ、重要な情報が切り捨てられる場合

適切なコンテキストエンジニアリングは、検証、プルーニング、構造化されたメモリ管理を通じてこれらの問題を防止します。コンテキストを、受動的な情報の蓄積ではなく、慎重にキュレーションされたリソースとして扱います。