はじめに
こんにちは。Algomatic AI Transformation(AX) のsergicalsix(@sergicalsix)です。
本記事では大規模言語モデル(LLM)を用いたアプリケーションないしAIエージェントの構築において切っても切り離せない「コンテキストエンジニアリング」について2025年10月時点での知見を備忘録としてまとめます。
コンテキストエンジニアリングとは
コンテキストエンジニアリングとは、LLM に与える情報(コンテキスト)を制御する技術です。
コンテキストエンジニアリングはよくプロンプトエンジニアリングと対比されます。
プロンプトエンジニアリングはあくまで特定のタスクに特化したエンジニアリング手法であるのに対して、コンテキストエンジニアリングは複数回の推論、反復的な推論など、より長い時間軸で動作する処理を対象とするエンジニアリング手法です。
また適切な情報を取得してプロンプトに注入するといったRAGの機構も広くコンテキストエンジニアリングに属していると言えます。
コンテキストエンジニアリングは技術的に非常に広い領域にまたがっていると言えます。
コンテキストエンジニアリングの重要性
コンテキストエンジニアリングが重要である理由は、LLMが処理可能なコンテキストの量が限られており、コンテキストの品質でシステムの出力の品質が大きく変わるからです。
前者はContext Rotという現象で知られており、一般的にコンテキスト量を増やすほどコンテキストの中から回答に有効な情報(Needleと言ったりします)を抽出/活用できなくなる傾向が高くなります。
この現象はモデルで設定されている最大コンテキスト長よりも短い範囲で発生し、モデルには最大コンテキスト長よりも短い有効コンテキスト長(effective context length)があると言えます。
余談で少し前に発表されたLost in the Middleといった現象もContext Rotと大きく性質は同じであるといえます。
Lost in the Middle: How Language Models Use Long Contexts - ACL Anthology
ここで重要なことはモデルが取り扱えることができる情報は有限であり、モデルには必要な情報のみを入力すべきであるということです。
コンテキストエンジニアリングの手法
コンテキストエンジニアリングは大きく以下3つから構成されます。
Context Retrieval & Generation
Context Processing
Context Management
個々の詳細手法は以下をご覧ください。
Context Retrieval & Generation(コンテキスト取得 & 生成)
Context Retrieval & GenerationではLLMがタスクを遂行するために必要な情報を取得・生成します。
こういった今必要な情報を取得して プロンプトに入れるという考えはjust in timeなアプローチと言われます。
メモリ・外部データベースからの情報の取得(ex. RAG)やユーザークエリの書き換え、コンテキストの生成(ex. HyDE, Self-RAG)などが該当します。
Context Processing(コンテキスト処理)
取得したコンテキストをそのまま使うと冗長であったり、ノイズが多いため、使える状態に加工する必要があります。
RankingやFilteringによる並べ替えと除去のほか、Claude Codeなどで見られるSummarization(要約)やCompression(圧縮)などが該当します。
特に要約した情報の活用はRAGとの相性が良いことでも知られており(ex. FG-RAG)、コンテキストエンジニアリングでも有効です。
またノイズが多いデータについては複数のソースを統合して整合性を高めるContext Fusion/Aggregationといった手法が有効です。
またAIシステムのレイテンシやコストなどを考えたとき、KVキャッシュを上手く使うことが重要になってきます。
そこでKVキャッシュをうまく使うためにコンテキストを入れ替えたり、削除しないといったテクニックが有効です。
上記の分類だとシステムプロンプト等のプロンプトエンジニアリングもContext Processingに該当します。
システムプロンプトは曖昧すぎず、専門的すぎないバランスの取れたプロンプトが良いとされています。
Few-shotプロンプティングではコンテキストを均一にせず、多様性を高めることが推奨されています。
Context Management(コンテキスト管理)
一度獲得したコンテキストを次回以降に活かすためにコンテキストの管理は重要です。
コンテキストの管理は大きくセッション単位で記憶しておくShort-term Contextと永続的に保持しておくLong-term Memoryの2種類が存在します。また一部のコンテキストは状況に応じて動的に更新されます(Dynamic Context Updating)。
さらにShort-term ContextはScratchpadとStateに分類されます。
ここでいうScratchpadはClaude CodeでいうところのTODO.mdやNOTES.mdなどに該当します。こういったファイルに残すという考え方はManusの知見においても再現性を考慮すると文脈で紹介されています。
またエージェントの失敗をコンテキストに残しておくといった知見も紹介されています。
余談ですが、弊社で開発しているAIエージェントでも過去の失敗ログをコンテキストに注入することで同一の失敗をしづらくなり、安定性が高まっているのを実感しています。
またマルチエージェントにおけるコンテキストは複数のAIエージェントが共有する知識・記憶・状態の整合性を保つことが重要になります。エージェント間でのコンテキストの同期(Context Synchronization)は必須であり、要約/圧縮情報の共有(Context Summarization for Exchange)や共通のDBへの情報保存(Shared Context Repository)などの方法が有効です。
おわりに
いかがだったでしょうか。
コンテキストエンジニアリングについて、少しでも情報の整理に役立てば幸いです。
最後にAlgomaticでは一緒に働くメンバーを募集しています!
以下よりお気軽にカジュアル面談をお申し込みいただけると幸いです!