2025.10.14 AI

コンテキストの構成要素と最適化の実装｜メモリ・RAG・compactionでコンテキストロットを防ぐ

この記事は、コンテキストエンジニアリングの実装面に絞り、AIエージェントに渡すコンテキストが何で構成され、それをどう最適化して精度低下（コンテキストロット）を防ぐかをまとめます。用語の定義やプロンプトエンジニアリングとの違いは、Prompt Engineeringとの違いで理解するContext Engineeringの本質と全体像を参照してください。

まとめ

  • コンテキストは、指示・ツール・取得データ（RAG）・メモリ・履歴で構成される情報環境全体を指す。
  • 会話やエージェントの実行が長くなると無関係なトークンが増え精度が落ちる「コンテキストロット」が起きる。
  • 対策の中心はcompaction（要約して新しい窓に引き継ぐ）、note-taking、構造化コンテキスト、必要分だけを入れるRAG。
  • コンテキスト窓が大きくても、埋め方が悪ければ劣化する。窓サイズより「何を入れるか」の設計が効く。

コンテキストを構成する要素

コンテキストエンジニアリングが扱うのは、単一のプロンプト文言ではなく、エージェントが多段のタスクで見る情報環境の全体です。具体的には、システムプロンプトなどの指示、呼び出せるツールの定義、検索で取得したデータ（RAG）、過去のやり取りを保持するメモリ、そして会話履歴です。これらが最初のトークンから最後の要約まで、トークンのライフサイクル全体を占めます。

コンテキストロット（長くなるほど精度が落ちる問題）

実行が長引くほど無関係なトークンが蓄積し、信号対雑音比が下がって、モデルの判断が悪化します。これはコンテキスト窓のサイズに関わらず、どのモデルでも起こる測定可能な現象です。窓を大きくするだけでは解決せず、窓を「正しいトークンで満たす」設計が必要になります。

最適化の実装手法

compaction（圧縮）は、窓の上限に近づいた会話を要約し、その要約で新しい窓を作り直す手法です。Anthropicはこれを自動compactionとして製品化しています。note-takingは、重要事項を外部メモに書き出して必要時に読み戻す方法です。構造化コンテキストは、ICLR 2026で提案されたACE（Agentic Context Engineering）のように、コンテキストを構造化された箇条書きとして保持し、全体を書き換えずに逐次更新する考え方です。Anthropicはこの領域向けに、コンテキスト編集とメモリツールという基盤も提供しています。

コンテキスト窓の管理とRAGの役割

現在のモデルのコンテキスト窓は、モデルによって十数万から百万トークン規模まで幅があります（正確な値は各モデルの公式情報で確認してください）。ただし前述のとおり、窓が大きいこと自体は精度を保証しません。窓が何をどこまで数えるのか、上限を超えたときにAPIがどう振る舞うのかはコンテキストウィンドウの定義とトークン上限の数え方に整理しています。RAGは「その時点のタスクに必要なデータだけ」を取得して入れることで、無関係トークンの混入を抑え、コンテキストロットを避ける実装上の要になります。メモリと組み合わせ、必要な情報を必要なタイミングだけ窓に載せる設計が中心になります。メモリ側の分類と保存先の選び方は、エージェントメモリの短期・長期記憶の設計と実装判断で扱っています。

よくある質問

コンテキストは何で構成されますか？

指示（システムプロンプト等）、ツール定義、取得データ（RAG）、メモリ、会話履歴です。これら情報環境の全体を設計するのがコンテキストエンジニアリングの実装面です。

コンテキストロットとは何ですか？

実行が長くなるほど無関係なトークンが増え、モデルの判断精度が下がる現象です。窓のサイズに関わらず起こり、compactionや構造化などで緩和します。

compactionとは何をする手法ですか？

窓の上限に近づいた会話を要約し、その要約で新しいコンテキスト窓を作り直す手法です。古い部分を要約に置き換えることで、必要な情報を保ちながらトークンを節約します。

コンテキストエンジニアリングとプロンプトエンジニアリングの違いは？

プロンプトエンジニアリングが指示の書き方に着目するのに対し、コンテキストエンジニアリングはツール・データ・メモリ・履歴を含む情報環境全体を扱います。定義と違いの詳細は正準の解説記事を参照してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る