レッスン5：記憶とコンテキスト管理——短期・長期・エピソード記憶

このレッスンで学ぶこと

コンテキストウィンドウの限界と短期記憶の関係を理解する
Sliding Window・要約による圧縮など、短期記憶の管理手法を整理する
長期記憶をベクトルデータベースなどで実装する基本発想を持つ
エピソード記憶（過去のタスク・会話の経験）の役割を押さえる
RAG（検索拡張生成）とエージェントの記憶の接続を理解する
Lost in the Middle（Liu et al. 2024）など、長文コンテキストの落とし穴を意識する

前のレッスンでは、エージェントのプランニングパターン（ReAct・Plan-and-Execute・Reflection）を扱いました。本レッスンは、エージェントが過去の文脈をどう保持し参照するか——「記憶」の設計を深掘りします。エージェントが「賢く」見えるかどうかの大半は、記憶の設計で決まります。

なぜ記憶が必要か

LLM 単体は、原則として「与えられた入力（プロンプト）にのみ基づいて出力を生成する」設計です。前のループで何をしたか、ユーザーが先週何を質問したか、社内文書に何が書かれているか——これらは LLM 自身に内在しません。エージェントの「記憶」は、これらの情報を外部に保持し、必要時に LLM の入力に注入する仕組み全体を指します。

記憶の 3 種類（レッスン 2 の再掲）

種類	内容	例
短期記憶	現在のループ内で参照する直近の文脈	直近の Thought・Observation の履歴
長期記憶	永続的な知識・設定・ルール	ユーザーの嗜好、企業の社内文書、ナレッジベース
エピソード記憶	過去のタスクや会話の経験	「先週同じユーザーが何を質問したか」

本レッスンでは、それぞれを詳しく見ていきます。

短期記憶——コンテキストウィンドウとの戦い

短期記憶は、現在のループ内で「いま何が起きているか」を把握するための文脈です。具体的には、

ユーザーの最初の指示
これまでの Thought・Action・Observation の履歴
現在使えるツールの定義

これらすべてを LLM の入力として渡す必要があります。

コンテキストウィンドウの限界

2026 年 6 月時点で、主要 LLM のコンテキストウィンドウは大きく拡大しました。100 万トークン以上を持つモデルが珍しくありません。

Claude Opus 4.7：100 万トークン以上
Gemini 3.1 Pro：200 万トークン以上
GPT-5.5：100 万トークン以上

「十分な広さがあるから問題ない」と思えるかもしれません。しかし、エージェントは複数ループで動くため、ループが進むほど履歴が積み上がり、コンテキストを圧迫します。50 ステップを超えるエージェントでは、短期記憶の管理が必須になります。

コストとレイテンシ

コンテキストが大きいと、毎ループで全履歴を LLM に送信することになります。

入力トークンに対する料金が膨らむ
レイテンシが伸びる（モデルが大量入力を処理する時間）
Lost in the Middle 現象が発生しやすい（後述）

管理手法 1：Sliding Window

最も単純な方法は、「直近の N ステップだけ保持し、古いものから捨てる」スライディングウィンドウ方式です。

直近 10 ステップだけを文脈として渡す
古いステップは捨てる
実装が簡単

弱点は、「重要な古い情報も捨ててしまう」ことです。

管理手法 2：要約による圧縮

古い履歴を捨てるのではなく、要約に置き換える方式です。

直近 10 ステップは詳細のまま保持
それより古いステップは、LLM で要約して 1〜2 文に圧縮
さらに古い要約は、要約の要約に圧縮（階層化）

「要約は LLM を 1 回追加で呼ぶ必要があるため、コストとレイテンシが増える」というトレードオフがあります。

管理手法 3：構造化メモリ

Thought・Action・Observation を構造化して保持し、必要部分のみを LLM に渡す方式です。

「これまで実行したツール」「これまでの観察結果のサマリー」「現在のゴール状態」を構造化
次の判断に必要な部分だけを LLM に注入

実装は複雑になりますが、長期運用のエージェントでは威力を発揮します。

💡 ポイント 「コンテキストウィンドウが広いから何でも入る」と思って何も考えずに全履歴を渡すと、コスト・レイテンシ・Lost in the Middle で痛い目を見ます。短期記憶の管理は、エージェント運用の重要な投資領域です。

長期記憶——「永続的な知識」の格納

長期記憶は、エージェントを跨いで保持される永続的な知識・設定・ルールです。

典型的な内容

企業の社内文書、マニュアル、FAQ
ユーザーの嗜好・履歴・プロファイル
業務ルール・閾値・基準
過去の意思決定の記録

実装の典型例

長期記憶の実装には、いくつかの代表的なアーキテクチャがあります。

アーキテクチャ	内容	用途
ベクトルデータベース	文書を埋め込みベクトルに変換して保存。意味検索で取り出す	社内文書、FAQ などの非構造データ
構造化 DB	リレーショナル DB に構造化された情報を保存	ユーザー属性、ルール、設定など
グラフ DB	エンティティ間の関係を保存	知識グラフ、人物関係、製品関連性
ファイル	テキストファイルや Markdown で保存	軽量な設定、ナレッジベース

ベクトルデータベースと埋め込み

非構造データ（文書）を扱う場合、ベクトルデータベースが事実上の標準になりました。

文書を「埋め込みベクトル」（高次元の数値列）に変換して保存
クエリも埋め込みベクトルに変換
ベクトル間の類似度（コサイン類似度など）で検索

代表的な製品として、Pinecone、Weaviate、Qdrant、Milvus、pgvector（PostgreSQL の拡張）などがあります。

📝 補足 ベクトルデータベースの選定は、規模・クエリパターン・既存システムとの統合性で決まります。小〜中規模なら pgvector（PostgreSQL の拡張）で十分というケースも多く、最初からマネージドサービスを選ぶ必要はありません。

「記憶」と「知識」の境界

長期記憶は「エージェント固有の経験を保存する」とも、「組織のナレッジを参照する」とも捉えられます。実装上はどちらもベクトルデータベースを使うことが多いため、両者の境界は曖昧です。本コースでは、両者をまとめて「長期記憶」として扱います。

エピソード記憶——「過去のタスク・会話の経験」

エピソード記憶は、過去のタスクや会話の経験を保存し、後で参照する記憶です。

典型的な使い方

「先週、このユーザーが何を質問したか」を思い出す
「同じような問題を以前どう解決したか」を参照する
「このユーザーは○○の対応に満足しなかった」を覚えている

実装

会話履歴 DB（タイムスタンプ付きで保存）
各セッションの要約スナップショット
ユーザー固有のプロファイル（属性＋過去履歴）

エピソード記憶を持つエージェントは、ユーザーから「賢い」「私をわかってくれている」と感じられやすくなります。

プライバシーと倫理

エピソード記憶は強力な反面、ユーザー情報を保存する以上、プライバシーへの配慮が必須です。

個人情報保護法・GDPR への対応
ユーザーが自分のデータを削除できる権利
保存期間の明示
機密情報の取り扱いルール

⚠️ 注意 エピソード記憶は「便利だから」と無設計で導入すると、コンプライアンスで重大な問題を抱える可能性があります。法務・コンプライアンス部門と連携した設計が必須です。

RAG（検索拡張生成）とエージェントの接続

RAG（Retrieval-Augmented Generation、検索拡張生成）は、長期記憶を活用するための代表的なアーキテクチャです。Patrick Lewis 氏らが 2020 年に「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で提唱しました。

基本フロー

flowchart LR
  Q[ユーザー質問] --> E1[埋め込み生成]
  E1 --> V[ベクトル検索]
  V --> D[関連文書取得]
  D --> L[LLM へ注入]
  Q --> L
  L --> A[回答]

ユーザーの質問を埋め込みベクトルに変換
長期記憶（ベクトル DB）から関連文書を取得
質問と関連文書を組み合わせて LLM に渡す
LLM が文書を参照して回答を生成

エージェントにおける RAG の位置づけ

エージェントの 5 要素で言えば、RAG は次のように位置づけられます。

道具（Tools）：search_knowledge_base というツールとして、エージェントが呼び出す
記憶（Memory）：長期記憶へのアクセスメカニズム

「エージェントが必要なときに RAG ツールを呼んで知識を取得する」という設計が、標準的なパターンです。

RAG の落とし穴

検索精度の問題：関連性の低い文書が取得されると、LLM が誤った回答を作る
文書の更新：社内文書が更新されたとき、ベクトル DB の再生成タイミング
検索クエリの質：ユーザー質問をそのまま検索クエリにするより、LLM で書き直す方が精度が上がることが多い
複数文書の整合性：複数の文書が矛盾する内容を含んでいると、LLM が混乱する

💡 ポイント 「RAG を入れれば自社ナレッジを LLM が使えるようになる」と単純化されがちですが、運用は意外に難しいです。検索精度、文書更新、クエリ書き直し、整合性管理など、長期的な投資が必要です。本コースでは RAG の詳細には踏み込みませんが、エージェントとの接続点を理解しておくと、後の学習がスムーズです。

Lost in the Middle——長文コンテキストの落とし穴

Liu 氏らが 2024 年に TACL（Transactions of the Association for Computational Linguistics）で発表した論文「Lost in the Middle: How Language Models Use Long Contexts」は、LLM の長文処理における重要な発見を報告しました。

主な発見

LLM は、コンテキストの「冒頭」と「末尾」の情報を強く参照する
「中間」の情報は無視されやすい傾向がある
コンテキストウィンドウが広くても、中間に置かれた情報の参照精度は落ちる

設計上の含意

重要な情報は、コンテキストの冒頭または末尾に配置する
長い履歴をすべて渡すより、要約と関連部分のみを渡す方が精度が高いことが多い
RAG で取得した関連文書も、配置順を意識すると効果が変わる

2026 年時点での状況

論文発表（2024 年）以降、各 LLM ベンダーは Lost in the Middle 問題への対応を進めています。2026 年 6 月時点では、改善は進んでいるものの、完全には解決していません。

📝 補足 「コンテキストウィンドウが広い＝何でも入れて大丈夫」ではないことを、Lost in the Middle は示しています。長期運用のエージェントでは、「何を入れるか」だけでなく「どの順で入れるか」も設計対象になります。

講師の現場メモ：「文脈を全部入れたら精度が下がった話」

私（高梨）が AI スタートアップで CTO だった頃、社内向けの「過去のすべての会話を記憶する万能アシスタント」を試作していました。Claude のコンテキストウィンドウが 100 万トークンに拡大したタイミングで、「過去 6 か月のチャット履歴と社内文書を全部入れれば、最強のアシスタントになる」と楽観視していたのです。

実装してみると、初期の評価で確かに精度が高く出ました。「先月のキックオフで○○を決めましたよね」「3 月の方針書では××と書いてあります」など、過去の文脈を踏まえた回答ができたのです。

ところが、3 か月運用して気づいたのは、「最近の質問への回答精度が下がった」という現象でした。新人エンジニアからの「いまの開発環境の構築手順」のような単純な質問に、6 か月前の古い手順を参照して間違った答えを出すことが頻発したのです。

調査して原因がわかりました：

100 万トークンの中に「2025 年 12 月の古い手順」「2026 年 1 月の改訂」「2026 年 5 月の最新版」が混在していた
LLM は中間に置かれた「最新版」を読み飛ばし、冒頭の「古い手順」を引用していた（Lost in the Middle）
コンテキスト圧縮が機能しておらず、矛盾する複数版が同時に存在していた

私たちは設計を全面的に見直しました。

RAG 化：必要なときだけ関連文書を検索して取得（全部一括投入を止める）
タイムスタンプ重視：検索時に「最新版」を優先する設定
配置順の工夫：取得した文書を、最新版が末尾になるよう配置
エピソード記憶の分離：会話履歴は別の DB に保存し、必要時に要約して呼び出す

3 つの対策を入れた結果、回答精度が元の水準に戻り、コストとレイテンシも 70% 削減できました。

このときに学んだのが、「コンテキストウィンドウが広いから何でも入れる」のではなく、「何を、どの順で、どれだけ入れるか」を設計する重要性です。Lost in the Middle 論文を読んだことはあったのですが、実際に痛い目を見るまで、完全には実感できていなかったのです。本コースで記憶設計を 1 レッスン取って深掘りするのは、この経験が背景にあります。

まとめ

このレッスンでは、以下のことを学びました。

記憶は短期・長期・エピソードの 3 種類があり、それぞれ実装が違う
短期記憶はコンテキストウィンドウ内で、Sliding Window・要約・構造化の手法で管理する
長期記憶はベクトルデータベース・構造化 DB・グラフ DB などに保存し、検索で取り出す
エピソード記憶はユーザー体験を「賢く」する一方、プライバシー設計が必須
RAG（Lewis et al. 2020）は長期記憶へのアクセスメカニズムで、エージェントの道具として組み込む
Lost in the Middle（Liu et al. 2024）の発見により、「何を」だけでなく「どの順で」入れるかが設計対象
「広いコンテキストウィンドウ」≠「無制限に入れて大丈夫」ではない

次のレッスンでは、エージェントを 1 体ではなく複数連携させるマルチエージェント協調を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。