11月2日、InfoQが「Systemic Approach to Memory, Knowledge, and Context in Agentic AI Architectures」と題した記事を公開した。エージェントAIアーキテクチャにおけるメモリ・知識・コンテキストの設計論を体系的にまとめた内容で、中でも「ハルシネーションの多くはモデルの問題ではなく、コンテキストの失敗である」という主張が論考の核心をなす。LLMの能力向上が続く中、本当のボトルネックはモデル選択ではなく「エージェントに何を・いつ・どの程度渡すか」の設計にある、という視点はエージェント開発者にとって耳の痛い指摘でもある。
「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ
LLMを使ったエージェントシステムの開発が進む中、アーキテクチャ上の本質的なボトルネックが浮き彫りになってきた。問題はデータの取得そのものではない。エージェントが「何を」「いつ」「どの程度」知るべきか——その設計にある。
記事はまず、次の3概念を明確に分離することから議論を始める。
- Context（コンテキスト）: エージェントが現時点で使用している、即時的・一時的な情報。コンピュータのRAMに相当し、LLMのアクティブなコンテキストウィンドウ内に置かれる。
- Memory（メモリ）: 単一のインタラクションを超えて情報を保持する永続化レイヤー。過去の経験から学習し、ユーザーへの適応を可能にする。
- Knowledge（知識）: ユーザーとのインタラクション前からエージェントが持つ、ファクト・概念・ルールの基盤。ビジネスロジックやポリシー、ドメイン固有データなど、高度にキュレーションされたデータ群。
この3つを混同した設計は、ハルシネーション（幻覚）や推論コストの増大を招く。記事の核心的な主張は「ハルシネーションの多くはコンテキストの失敗である」という点だ。
なお、「コンテキストエンジニアリング」という用語自体はまだ業界標準の定義が定まっておらず、この記事が独自に整理・提唱している概念に近い。プロンプトエンジニアリングやRAG（Retrieval-Augmented Generation）といった既存概念と部分的に重なりつつも、より上位のアーキテクチャ設計思想として位置付けている点に留意が必要だ。
Context Engineという設計思想
記事が提唱するのが「Context Engine」という概念だ。LLMの推論エンドポイントに情報が届く前に、情報を選択・フィルタリング・ランク付け・構造化・圧縮・保護・配信するオーケストレーターである。
この考え方はコンパイラの比喩で説明される。コンパイラが高水準のソースコードを機械実行可能な命令に変換するように、Context Engineは「非構造化・断片化された生データや履歴データ」を「推論可能な状態（reasoning-ready state）」へと変換する。加えて、入力の認証、ビジネスロジックへの照合、PII（個人識別情報）の除去、サンドボックス化もこのレイヤーで行う。
「プロンプトエンジニアリングは『より良い指示をどう書くか』を問う。コンテキストエンジニアリングが問うのは、『モデルが今この瞬間に推論するために必要な、最小かつ最高品質のコンテキストは何か』だ。」
設計上の3つの対立構造
1. 履歴メモリ vs リアルタイム入力
ベクトルDBが得意とする長期的な「エピソード記憶」と、直近のツール出力やライブテレメトリといった「感覚入力」をいかに融合するかが鍵になる。
記事はAI DevOpsエージェントを例に挙げる。サーバー障害のトリアージにおいて、ベクトルストアから過去のアーキテクチャ・ランブックを取得するだけでは不十分で、直近5秒のエラーログストリームも同時に必要だ。この2つを非同期に融合する設計が求められる。
履歴に偏りすぎると、エージェントは古い前提を現在に投影し続ける。リアルタイムに偏りすぎると、広いコンテキストを失って反射的な行動しかとれなくなる。どちらかを最大化するのではなく、制約下での「有用性」を最大化するのが設計目標だ。
2. SELECT * 問題——知識 vs 生データ
RAGパイプラインにありがちな失敗として、「大量のデータを取得すれば良い」という発想がある。記事はこれを「SELECT *」に例える。編集されていない10のWikiページをそのままプロンプトに詰め込んでも、LLMはノイズの中に埋もれた重要なシグナルを見つけられず、推論コストだけがかさむ。
解決策はKnowledge Curation（知識のキュレーション）だ。バックグラウンドワーカーやMLパイプラインが、生データを蒸留・集約・ランク付けして構造化する。例として、100万件のデータエントリを12時間ごとに1エントリに要約するパイプラインが挙げられている。モデルが受け取るのは、混沌としたデータストリームではなく、コンパクトに合成された知識体だ。
3. コンテキストに「汎用解」はない
GPT-4やClaudeといったファウンデーションモデル、PineconeやMilvusといったベクトルDBはコモディティ化した。しかしコンテキストの設計は、ドメインごとに固有である。
フィンテック企業の不正分析エージェントなら、タイムスタンプ・ジオロケーション異常・コンプライアンスルールを優先する。リーガルテック企業の契約生成エージェントなら、州法のコンテキストが中心になる。コンテキスト設計は、製品ドメインのロジック・セキュリティ境界・語彙を反映したものでなければならない。
コンテキストのライフサイクル管理
記事は最後に、コンテキストを「継続的なライフサイクル」として管理するフレームワークを提示する。4つのステージで構成される。
- Selection（選択）: タスクに対して価値の高いデータを特定する。セマンティック検索（Dense）とキーワード検索（Sparse、例: BM25）を組み合わせたハイブリッド検索や、ナレッジグラフのトラバーサルを活用する。実装上の落とし穴として、検索精度がそのままコンテキスト品質に直結するため、クエリの設計やリランキング戦略を軽視すると下流の推論精度が大きく劣化する点に注意が必要だ。LangChainやLlamaIndexはこのステージのオーケストレーションを抽象化するOSSとして広く使われている。
- Injection（注入）: 選択された情報をLLMが処理できる形でコンテキストウィンドウに渡す。単純に連結するだけでは情報の順序や境界が曖昧になりがちで、構造的なフォーマット（XMLタグやMarkdownセクション区切りなど）を使って情報を整理することが推論精度の向上につながる。
- Compression（圧縮）: コンテキストウィンドウの制限に対して、情報を損失最小で圧縮する。要約モデルの利用や、重要度スコアに基づくチャンクの間引きが代表的な手法だが、圧縮によって失われる情報が推論に致命的かどうかを評価する仕組みを別途設けないと、圧縮ロスに気付けないまま精度が低下するリスクがある。長期記憶とコンテキスト圧縮を組み合わせたアーキテクチャとしてはMemGPTの設計思想も参考になる。
- Expiration & Refresh（失効と更新）: 陳腐化した情報を破棄し、新しい情報に入れ替える。TTL（Time To Live）の設定やイベント駆動の無効化戦略を持たないと、エージェントが古いコンテキストを正として推論し続ける「ステール問題」が発生しやすい。特に外部APIやリアルタイムデータに依存するエージェントでは、更新頻度の設計がシステム全体の信頼性を左右する。
各ステージは専用モジュールまたは独立したサービスとして実装できる構成だ。
この記事で一貫して強調されているのは「コンテキストを最大化するのではなく、最適化せよ」という原則だ。小さくても関連性の高いコンテキストは、大きくてノイジーなプロンプトよりも推論精度が高い。エージェントAIの実装に取り組む開発者・アーキテクトにとって、設計指針を整理する上で参照に値する論考である。
詳細はSystemic Approach to Memory, Knowledge, and Context in Agentic AI Architecturesを参照していただきたい。
