コンテキストエンジニアリングがなぜ重要なのか

導入

こんにちは、株式会社ナレッジセンスの須藤英寿です。

今回は、コンテキストエンジニアリングがエージェントにとってなぜ重要なのかを解説します。

https://blog.langchain.com/context-engineering-for-agents/

説明の過程で、上記のブログの内容を参照しています。

サマリー

ここ最近コンテキストエンジニアリングという言葉が話題になっています。

ツイートの中でも登場するプロンプトエンジニアリングと似た言葉ですが、コンテキストエンジニアリングという言葉が登場した背景にはエージェントの台頭が関係しています。

これまでLLMは基本的に「人」が利用するものでした。そのため入力するプロンプト、そのものに焦点を当てられていました。しかし、「エージェント」は人の手が基本的に介在することなく、自動的にLLMが動作し続けます。そのためプロンプトだけではなく、情報そのものをどう管理するかまで考える必要性が出てきました。この情報の扱い方を考えることこそコンテキストエンジニアリングです。

コンテキストエンジニアリングのゴールは２つあります。１つ目は、LLMの性能を最大限に引き出すこと。これはプロンプトエンジニアリングに通じるものがあります。そして２つ目は、LLMにとって必要十分な情報を提供すること、です。

今回は、コンテキストエンジニアリングが必要になる背景と、手法について解説していきます。

課題意識

LLMに複雑な指示をした際に、その指示がLLMの持つ問題解決能力を上回ってしまうと、タスクを完了できなくなることがあります。これは主に２つの制約によって発生します。

• 入力長の限界: LLMには入力可能な文章量に制限があるため、その中で解決できないと、それ以上何もできなくなってしまいます。
• 認識の限界: 複数の指示をLLMに任せると"Lost in the Middle"などの問題などにより解決すべき問題を見失うことがあります。

これらの限界は、LLMの進化によって確実に解消していきますが、人の要求する問題解決能力からはまだ大きな隔たりがあります。

コンテキストエンジニアリングでの解決方法

ここで登場するのがコンテキストエンジニアリングという考え方です。LLMに適切なコンテキストを渡すことでLLMの限界に到達しないように問題を解いていこう、というものです。以下に関連する４つの手法を紹介しています。

• 書き出し: 重要な情報を外部に保管して再利用可能にする
• 選択: 必要なコンテキストだけを取得して、余計な情報を持たない
• 圧縮: コンテキストを厳選して、密度の高い情報にする
• 分割: 複雑な問題を分解して、独立した扱いやすい問題にする

これらの手法を組み合わせることで、LLMに解かせる問題を最小限にして、かつその推論能力を問題の解決に集中させることができます。結果として、LLMが問題を解くのに成功する確率を引き上げることが可能です。

手法

ここからは具体的な手法について紹介します。注意点として、ここで紹介する手法はあくまで現時点で想定された解法であり、今後もアップデートが想定される部分です。LLMの出力の品質をいかにして上げられるかが、根幹にあるということを念頭に見ていただければと思います。

書き出し(Write Context)

セッション内で得られた情報を外部に保管し、別のセッションで再利用できるようにすることを目的としています。

• メモ書きの書き出し

重要な内容や方針を外部のメモ書きとして残します。たとえば、実行の手順を記録しておくことで、セッションを再開したときに続きから再開可能であったり、"Lost in the Middle"で情報が消えることを防げます。

• 記憶の書き出し

セッション内の情報のうち、他の指示に関わるような情報は記憶(memory)として長期に利用できるようにします。これにより、たとえば毎回行っているような指示や、ハマりやすい失敗を繰り返さずに済むようになります。

実践上のヒント

情報量が多すぎるとそれだけでコンテキストを圧迫したり、選択のコストが発生してしまうため、書き出し過ぎには注意が必要です。対策としては以下のようなものが考えられますが、運用方法によって調整してみてください。

• 出力の内容を指定して、情報が散漫にならないようにする
• RAGと組み合わせて、効率のよい検索と組み合わせる
• 単純にデータ量を制限して古いデータを破棄する

選択(Select Context)

• メモ書き、記憶の読み込み

新しいセッションの開始時や、問題の切替時などに読み込めるようにすることでLLMが次にやるべきことを把握できるようになります。Toolとして、ないしはルールベースで渡す、などが想定できます。

• Toolの選択

LLMは基本的にはテキスト、画像の出力以上のことは出来ず、また算術などの指示を苦手としているため、それらの処理を適切に外部の機能に頼っていく必要があります。また指示の目的そのものになることも有るので、Toolを増やすことがすなわちLLMにできることを増やす手段となっています。

• 情報の検索

LLMの内部知識には限界があります。このような場合で有効なのが"RAG"もしくは"Web検索"です。特に、企業内の機密情報などを扱う際は、RAGを用いて重要な情報のみを適切にLLMへ渡す必要があります。

実践上のヒント

Tool選択は、実は思っているよりも精度が出にくい部分です。実際に利用してみると、ある程度問題なく選択できるようになるのはo3, gemini-2.5~, claude-3.7-sonnet~と比較的最新の、最高性能のものに絞られてきます。

この問題への対策には以下のようなものが考えられます。

• 実行するToolを限定してしまって、選択させない
• 高い性能のLLMを使用する
• RAGと組み合わせて、自然言語で選択できるようにする

圧縮

• コンテキストの圧縮、切り捨て

不要な情報をなくすことで、LLMのコンテキスト長の限界を超えないようにし、そして、推論の性能を引き上げることが可能です。そこまでのMessageの要約、Toolの出力の要約、古いメッセージの削除などで実現可能です。

実践上のヒント

圧縮は、実はできれば避けたい方法です。もちろん、必要な情報をしっかりと残すことができれば良い手法なのですが、得てして必要な情報が抜け落ちます。むしろ重要なのは、LLMに解かせるタスクを圧縮が必要なく解ききれるくらい、細かくすることで圧縮は最終手段と考える方が良いです。

分割

• 処理の分割、分岐

LLMの解くべく問題を分割することで、それぞれのセッションで解決しないといけない問題を減らすための手法です。具体的には、マルチエージェントで複数のエージェントが分担して問題を解決する手法や、同じセッション内でも短くゴールを設定して問題を解決する手法があります。

実践上のヒント

ここまでの主張と矛盾をした話に聞こえるかもしれませんが、可能であれば処理は分割しないほうがいいです。理由としては、分割する過程そのものでミスが発生する可能性があるからです。LLMに指示する場合は以下のような順序で考えていき、可能であれば上の方の手法で解決することが望ましいです。

1. LLMが分割しなくも解決できるくらい、短く明確な指示する
2. 細かなゴール設定だけで、単一セッションで解決できる指示を出す
3. 同一のエージェントが独立したセッションを繰り返すことで解決できる指示をする
4. 複数の専門的なエージェントがそれぞれ問題を解決することで実現できる指示をする

まとめ

コンテキストエンジニアリングの考え方とその中で登場する具体的な手法について紹介しました。重要なのは、いかにしてLLMが最高の性能を発揮できる環境をお膳立てするかです。そして、それを実現するうえで重要な要素が、「小さな指示」、「解決に必要十分な情報」、「実行可能な手段の提供」です。この考え方は、エージェントに限定されるものではなく、LLMを活用したすべてのシステムに応用できます。読者の皆様の解決したい課題は様々だとは思いますが、ここで紹介した考え方や手法が解決の糸口になれば幸いです。