Home
Blog
AIエージェントを地に足をつけた状態に保つ：Milvusを用いたコンテキスト腐敗を防ぐコンテキストエンジニアリング戦略

AIエージェントを地に足をつけた状態に保つ：Milvusを用いたコンテキスト腐敗を防ぐコンテキストエンジニアリング戦略

Engineering

December 23, 2025

Min Yin

長いスレッドの途中で、モデルが漂流し始めるのだ。答えが曖昧になり、推論が弱まり、重要な詳細が不思議と消えてしまうのだ。しかし、まったく同じプロンプトを新しいチャットに投下すると、モデルは突然、集中し、正確で、地に足のついた行動をとるようになる。

これはモデルが「疲れている」のではなく、文脈が腐っているのだ。会話が大きくなるにつれ、モデルはより多くの情報を扱わなければならなくなり、優先順位をつける能力が徐々に低下していく。Antropicの研究によると、コンテキストウィンドウが約8Kトークンから128Kに伸びると、検索精度は15～30％低下する。モデルにはまだ余裕があるが、何が重要かを見失う。コンテキスト・ウィンドウを大きくすることで、問題を遅らせることはできるが、解消することはできない。

そこで、コンテキスト・エンジニアリングの出番となる。重要な部分のみを取り出し、冗長になる必要のない部分は圧縮し、プロンプトやツールはモデルが推論できる程度にクリーンな状態に保つ。ゴールはシンプルで、重要な情報を適切なタイミングで利用可能にし、それ以外は無視することだ。

ここで中心的な役割を果たすのが検索であり、特に長時間稼働するエージェントにとっては重要である。Milvusのようなベクターデータベースは、関連する知識を効率的にコンテキストに引き戻すための基盤を提供し、タスクが深く複雑になっても、システムが地に足をつけた状態を維持できるようにします。

このブログでは、コンテキストの回転がどのように起こるのか、それを管理するためにチームが用いる戦略、そして、検索からプロンプトの設計に至るまで、長い、マルチステップのワークフローにおいてAIエージェントをシャープに保つアーキテクチャパターンを見ていきます。

コンテキストの腐敗が起こる理由

AIモデルに多くのコンテキストを与えれば、より良い答えが得られると思われがちだ。しかし、実際はそうではない。認知科学によれば、人間のワーキングメモリーはおよそ7±2個の情報の塊を保持している。それを超えると、詳細を忘れたり、ぼやけたり、誤解したりし始める。

LLMも似たような挙動を示すが、規模がはるかに大きく、より劇的な故障モードがある。

根本的な問題は、トランスフォーマーのアーキテクチャそのものにある。すべてのトークンは、他のすべてのトークンと比較し、シーケンス全体にわたってペアワイズ・アテンションを形成しなければならない。つまり、計算量はコンテキストの長さとともにO(n²)倍になる。プロンプトを1Kトークンから100Kに拡張しても、モデルは「よりハードに働く」ようにはならない。

次に学習データの問題がある。モデルは長いシーケンスよりも短いシーケンスをはるかに多く見る。そのため、LLMに非常に大きなコンテクストにまたがって動作するよう求めると、LLMはそれ用に十分に訓練されていない領域に押し込まれることになる。実際には、非常に長いコンテキストの推論は、ほとんどのモデルにとって分布外であることが多い。

このような限界にもかかわらず、長いコンテキストは今や避けられない。初期のLLMアプリケーションは、分類、要約、または単純な生成といったシングルターンのタスクがほとんどだった。今日、企業のAIシステムの70％以上は、分岐するマルチステップワークフローを管理し、多くの場合、何時間もの対話のラウンドにわたってアクティブな状態を維持するエージェントに依存している。長時間のセッションは、例外からデフォルトへと移行した。

次の問題は、いかにしてモデルを圧倒することなく、注意を鋭敏に保つかということだ。

コンテキストの腐敗を解決するためのコンテキスト検索アプローチ

検索は、コンテキストの腐敗に対抗するための最も効果的な手段のひとつであり、実際には、異なる角度からコンテキストの腐敗に対処する補完的なパターンで現れる傾向がある。

1.ジャストインタイム検索：不要なコンテキストの削減

コンテキストの腐敗の主な原因のひとつは、まだ必要のない情報でモデルに負荷をかけることである。Claude Code-Anthropicのコーディングアシスタントは、ジャストインタイム（JIT）検索でこの問題を解決する。

コードベースやデータセット全体をコンテキストに詰め込むのではなく（これはドリフトや忘却の可能性を大きくする）、Claude Codeはファイルパス、コマンド、ドキュメントリンクといった小さなインデックスを維持する。モデルが情報の一部を必要とするとき、その特定の項目を検索し、重要な瞬間にコンテキストに挿入する。

例えば、クロード・コードに10GBのデータベースを分析するよう依頼しても、全体を読み込もうとはしない。エンジニアのように働くのだ：

SQLクエリーを実行し、データセットのハイレベルなサマリーを引き出す。
head 、tail のようなコマンドを使ってサンプルデータを表示し、その構造を理解する。
重要な統計やサンプル行など、最も重要な情報だけをコンテキスト内に保持する。

コンテキスト内に保持する情報を最小限にすることで、JIT検索は腐敗の原因となる無関係なトークンの蓄積を防ぐ。モデルは、現在の推論ステップに必要な情報だけを見るので、集中し続ける。

2.事前検索（ベクトル検索）：文脈ドリフトを事前に防ぐ

顧客サポート、Q&Aシステム、エージェントのワークフローでは、生成開始前に適切な知識が必要になることがよくあります。そこで事前検索が重要になる。

コンテキストの腐敗は、モデルが大量の生テキストの山を手渡され、何が重要かを選別することを期待されるために、しばしば起こります。Milvusや Zilliz Cloudのような）ベクトル・データベースは、推論の前に最も関連性の高い部分を特定し、価値の高いコンテキストのみがモデルに到達するようにする。

典型的なRAGのセットアップでは

ドキュメントはMilvusのようなベクトルデータベースに埋め込まれ、保存される。
クエリ時に、システムは類似性検索によって関連性の高いチャンクの小さなセットを検索する。
これらのチャンクのみがモデルのコンテキストに入る。

これにより、2つの方法で腐敗を防ぐことができる：

ノイズの削減：無関係なテキストや関連性の低いテキストは、そもそもコンテキストに入らない。
効率性:モデルが処理するトークンの数がはるかに少ないため、重要な詳細を見失う可能性が低くなる。

Milvusは何百万ものドキュメントをミリ秒単位で検索できるため、このアプローチはレイテンシーが重要なライブシステムに最適である。

3.ハイブリッドJITとベクトル検索

ベクトル検索ベースの事前検索は、モデルが生の特大テキストではなく、シグナル性の高い情報から開始することを保証することで、コンテキストの腐敗の重要な部分に対処する。しかし、Anthropicは、チームが見落としがちな2つの真の課題を浮き彫りにしている：

適時性：適時性：知識ベースがベクトルインデックスの再構築よりも早く更新される場合、モデルは古い情報に依存する可能性がある。
正確性：タスクの開始前に、モデルが必要とするものを正確に予測することは困難である。

そのため、実世界のワークロードでは、ハイブリッド・アパローチが最適なソリューションとなる。

安定した、信頼性の高い知識のためのベクトル探索
進化する情報、またはタスクの途中で初めて関連する情報には、エージェント駆動型のJIT探索

これら2つのアプローチをブレンドすることで、既知の情報に対するベクトル検索のスピードと効率性を得ることができ、新しいデータが関連するようになったときにはいつでも、モデルが新しいデータを発見して読み込む柔軟性を得ることができる。

これが実際のシステムでどのように機能するか見てみよう。例えば、プロダクション・ドキュメンテーションのアシスタントを考えてみよう。ほとんどのチームは最終的に2段階のパイプラインに落ち着く：milvusを使ったベクトル検索＋エージェントベースのJIT検索である。

1.Milvus搭載ベクトル検索（事前検索）

ドキュメント、APIリファレンス、変更履歴、既知の問題をエンベッディングに変換します。
Milvusベクターデータベースに、製品エリア、バージョン、更新時間などのメタデータとともに格納します。
ユーザーから質問があった場合、セマンティック検索を実行し、関連する上位K個のセグメントを取得します。

これにより、定型的なクエリの約80%を500ミリ秒以内に解決し、強力で文脈に左右されない出発点をモデルに与える。

2.エージェントベースの探索

最初の検索が十分でない場合、例えば、ユーザが非常に具体的なものを要求したり、時間的な制約がある場合、エージェントは新しい情報を取得するためにツールを呼び出すことができる：

search_code を使って、コードベースの特定の関数やファイルを見つける。
run_query を使って、データベースからリアルタイムのデータを取り出します。
fetch_api を使用して、最新のシステムステータスを取得します。

これらの呼び出しには通常3～5秒かかりますが、システムが事前に予測できなかった質問に対しても、常に新鮮で正確、かつ関連性のあるデータでモデルが動作することを保証します。

このハイブリッド構造により、コンテキストがタイムリーで、正しく、タスクに特化したままであることが保証され、長く続くエージェントワークフローでコンテキストが腐敗するリスクが劇的に減少します。

Milvusは、このようなハイブリッドシナリオにおいて特に効果的です：

意味的関連性と構造化された制約を組み合わせたベクトル検索＋スカラーフィルタリング
エンベッディングをダウンタイムなしに更新できるインクリメンタルアップデート

このため、Milvusは、意味的な理解と検索対象の正確な制御の両方を必要とするシステムにとって理想的なバックボーンとなります。

例えば、次のようなクエリを実行する：

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

コンテキストロットを扱うための正しいアプローチの選択方法

ベクトル検索の事前検索、ジャストインタイム検索、そしてハイブリッド検索がすべて利用可能であり、当然の疑問は、どれを使うべきか、ということである。

ここでは、知識がどれだけ安定しているか、モデルの情報ニーズがどれだけ予測可能であるかに基づいて選択する、シンプルだが実用的な方法を紹介する。

1.ベクトル探索 → 安定した領域に最適

金融、法務、コンプライアンス、医療文書など、変化のスピードは遅いが、正確さが要求される分野であれば、Milvusの事前検索機能付き知識ベースが適している。

情報は明確に定義されており、更新頻度は低く、ほとんどの質問は、意味的に関連する文書を前もって検索することで回答できる。

予測可能なタスク＋安定した知識→事前検索。

2.ジャストインタイム検索 → 動的で探索的なワークフローに最適

ソフトウェアエンジニアリング、デバッグ、アナリティクス、データサイエンスのような分野では、新しいファイル、新しいデータ、新しいデプロイメント状態など、環境が急速に変化する。新しいファイル、新しいデータ、新しいデプロイメントの状態などです。モデルは、タスクが始まる前に何が必要かを予測することはできません。

予測不可能なタスク＋急速に変化する知識→ジャストインタイム検索。

3.ハイブリッドアプローチ → 両方の条件が当てはまる場合

多くの現実のシステムは、純粋に安定しているわけでも、純粋に動的なわけでもない。例えば、開発者のドキュメントはゆっくりと変化するが、本番環境の状態は刻々と変化する。ハイブリッド・アプローチでは次のことができる：

ベクトル検索（高速、低レイテンシ）を使用して、既知の安定した知識をロードする。
オンデマンドでエージェントツールを使って動的な情報を取得（正確、最新）

混合知識＋混合タスク構造→ハイブリッド検索アプローチ。

コンテキストウィンドウがまだ十分でない場合は？

コンテキストエンジニアリングは過負荷を減らすのに役立つが、時にはもっと根本的な問題がある。

大規模なコードベースのマイグレーション、マルチ・リポジトリ・アーキテクチャのレビュー、深いリサーチ・レポートの作成など、特定のワークフローでは、モデルがタスクの最後に到達するまでに、200K以上のコンテキスト・ウィンドウを超えることがある。ベクトル検索が重労働であっても、より永続的で構造化されたメモリを必要とするタスクもあります。

最近、Anthropicは3つの実用的な戦略を提供しました。

1.圧縮：信号を保存し、ノイズを取り除く

コンテキストウィンドウが限界に近づくと、モデルは以前のやりとりを簡潔な要約に圧縮することができる。良い圧縮は

重要な決定
制約と要件
未解決の問題
関連するサンプルや例

そして削除

冗長なツール出力
無関係なログ
冗長なステップ

課題はバランスだ。積極的に圧縮し過ぎると、モデルは重要な情報を失い、軽く圧縮し過ぎると、スペースはほとんど得られない。効果的な圧縮は、"なぜ "と "何を "を維持する一方で、"どうやってここまで来たか "を捨ててしまう。

2.構造化されたノートテイキング：安定した情報をコンテキストの外に出す

モデルのウィンドウ内にすべてを保持する代わりに、システムは重要な事実を外部メモリに保存することができます。

例えば、クロードのポケモンエージェントのプロトタイプは、次のような耐久性のある事実を保存します：

Pikachu leveled up to 8
Trained 1234 steps on Route 1
Goal: reach level 10

一方、一時的な詳細（バトルログや長いツールの出力など）は、アクティブなコンテキストの外に置かれる。これは、人間がどのようにノートを使うかを反映している。私たちは、すべての詳細をワーキングメモリに保存するのではなく、参照点を外部に保存し、必要なときにそれらを調べる。

構造化されたノートテイキングは、繰り返される不要な詳細によるコンテキストの腐敗を防ぐと同時に、モデルに信頼できる真実のソースを与える。

3.サブエージェントアーキテクチャ：大規模タスクの分割と克服

複雑なタスクの場合、マルチエージェントアーキテクチャを設計することができ、そこでは、リードエージェントが作業全体を監督し、いくつかの専門化されたサブエージェントがタスクの特定の側面を処理する。これらのサブエージェントは、サブタスクに関連する大量のデータに深く潜り込みますが、簡潔で本質的な結果のみを返します。このアプローチは、研究レポートやデータ分析のようなシナリオでよく使われます。

実際には、圧縮と組み合わせた単一のエージェントでタスクを処理することから始めるのがベストだ。外部ストレージは、セッションをまたいでメモリを保持する必要がある場合にのみ導入すべきである。マルチエージェントアーキテクチャは、複雑で特殊なサブタスクの並列処理を本当に必要とするタスクのために確保されるべきである。

各アプローチは、コンテキストのウィンドウを吹き飛ばすことなく、またコンテキストの腐敗を引き起こすことなく、システムの有効な「ワーキングメモリ」を拡張する。

実際に機能するコンテキストを設計するためのベストプラクティス

コンテキストのオーバーフローを処理した後、もうひとつ同様に重要な部分がある。圧縮、外部ノート、サブエージェントがあっても、プロンプトやツール自体が長く複雑な推論をサポートするように設計されていなければ、システムは苦労するだろう。

Anthropicは、プロンプトを書く練習としてではなく、3つのレイヤーにわたってコンテキストを構築する方法として、このことを考えるのに役立つ方法を提供する。

システムのプロンプトゴルディロックスゾーンを見つける

ほとんどのシステム・プロンプトは両極端で失敗する。詳細すぎるルールリスト、入れ子になった条件、ハードコードされた例外などは、プロンプトをもろくし、維持することを難しくする。構造が少なすぎると、モデルは何をすべきかを推測することになる。

最良のプロンプトはその中間に位置します。行動を導くのに十分な構造を持っており、モデルが推論するのに十分な柔軟性を持っています。実際には、これはモデルに明確な役割、一般的なワークフロー、軽いツールガイダンスを与えることを意味します。

例えば

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…

このプロンプトは、モデルを圧倒したり、ここにふさわしくない動的な情報を無理に扱わせたりすることなく、方向性を示している。

ツールデザイン：少ないことは多いこと

システムプロンプトが高レベルの動作を設定したら、ツールは実際の操作ロジックを実行します。ツールを使ったシステムで意外と多い失敗モードは、単にツールが多すぎる、あるいは目的が重複するツールがある、というものだ。

経験則では

ツールは1つ、目的は1つ
明確で曖昧さのないパラメータ
責任の重複なし

人間のエンジニアがどのツールを使うか迷うなら、モデルも迷うだろう。クリーンなツールデザインは曖昧さを減らし、認知的負荷を下げ、不必要なツールの試行でコンテキストが乱雑になるのを防ぐ。

動的な情報はハードコードされるのではなく、取得されるべきである

最後のレイヤーは、最も見落としやすいものだ。ステータスの値、最近の更新、ユーザー固有の状態など、動的な情報や時間的な影響を受けやすい情報は、システムプロンプトにまったく表示されるべきではない。これをプロンプトに埋め込んでしまうと、長いタスクの間に陳腐化したり、肥大化したり、矛盾が生じたりすることになる。

代わりに、これらの情報は、検索またはエージェントツールによって、必要なときだけ取得されるべきである。システムプロンプトから動的なコンテンツを排除することで、コンテキストの腐敗を防ぎ、モデルの推論空間をクリーンに保つことができる。

結論

AIエージェントがさまざまな業界の生産環境に移行するにつれて、これまで以上に長いワークフローと複雑なタスクを担うようになっている。このような環境では、コンテキストを管理することが現実的に必要になってくる。

しかし、コンテキスト・ウィンドウを大きくすれば、自動的に良い結果が得られるというわけではなく、多くの場合、逆の結果になる。モデルに過負荷がかかったり、古い情報を与えられたり、大量のプロンプトを強制されたりすると、精度は静かに落ちていく。このゆっくりとした微妙な低下は、現在ではコンテキストの腐敗と呼ばれている。

JIT検索、事前検索、ハイブリッドパイプライン、ベクターデータベースを利用したセマンティック検索などの技術は、すべて同じゴールを目指している。モデルが適切な情報を適切な瞬間に、それ以上でもそれ以下でもなく、確実に見ることができるようにすることだ。

オープンソースの高性能ベクトルデータベースであるmilvusは、このワークフローの中核に位置する。Milvusは、知識を効率的に保存し、最も関連性の高い部分を低レイテンシーで検索するためのインフラを提供します。Milvusは、JIT検索やその他の補完的な戦略と組み合わせることで、AIエージェントのタスクがより深く、よりダイナミックになっても、精度を維持できるよう支援する。

しかし、検索はパズルの1ピースに過ぎません。優れたプロンプトの設計、クリーンで最小限のツールセット、そして圧縮、構造化ノート、サブエージェントなど、賢明なオーバーフロー戦略、これらすべてが連動して、長期にわたるセッションでモデルの集中力を維持する。これが本当のコンテキストエンジニアリングの姿である。賢いハックではなく、思慮深いアーキテクチャである。

数時間、数日、あるいはワークフロー全体にわたって正確さを維持するAIエージェントをお望みなら、コンテキストは、スタックの他のコア部分と同じ注意を払う価値があります。

ご質問や機能についてのディープダイブをご希望ですか？私たちの Discordチャンネルに参加するか、 GitHubに課題を提出してください。また、 Milvusオフィスアワーを通して、20分間の1対1のセッションを予約し、洞察、ガイダンス、質問への回答を得ることもできます。