この記事を、二人の対話で。
記事より古い内容です。新しい音声を準備しています。
AI 合成音声 · VOICEVOX Nemo（女声1・男声1）
音声の一覧・再生リストへメモリと状態管理
この記事の目的
Agent の「記憶」を短期(コンテキスト内)・作業状態・長期(セッション横断)の 3 層に分けて捉え、履歴の肥大化への対処(刈り込み・要約・外部化)と、セッションをまたぐ中断・再開を設計できるようになります。
対象読者
- 長いタスクや複数セッションにまたがる Agent を設計するエンジニア
- 「会話が長くなると Agent の品質が落ちる / コストが増える」問題に直面しているエンジニア
前提知識
- AI Agent とは何か — メモリが Agent の構成要素である位置づけ
- Agent ループ — 履歴が単調増加する仕組み
本文
概要: 「メモリ」は 1 つではない
大前提として、LLM 自体は呼び出しと呼び出しの間で何も覚えません(ステートレス)。Agent が「覚えている」ように見えるものはすべて、アプリケーション側が管理して入力に渡しているデータです。この「渡しているデータ」は性質の異なる 3 層に分けられます。
| 層 | 実体 | 寿命 | 典型的な内容 |
|---|---|---|---|
| 短期記憶 | LLM に渡す会話履歴・ツール結果(コンテキスト) | 1 タスク〜1 セッション | 直近のやり取り、作業中の情報 |
| 作業状態 | アプリが管理する構造化データ | タスクの開始〜完了 | 計画、進捗、中間成果物、決定事項 |
| 長期記憶 | 外部ストレージ(ファイル・DB・検索インデックス) | セッション横断 | ユーザーの好み、過去の決定、ナレッジ |
この 3 層を区別せず「全部会話履歴に入れる」ことが、肥大化・再開不能・コスト増の根本原因になります。
詳細: 短期記憶はコンテキストウィンドウとの戦い
Agent ループLLM が「観測 → 思考 → 行動」のサイクルを繰り返し、完了・失敗・上限のいずれかの停止条件まで自律的に処理を続ける制御構造。では履歴が 1 周ごとに増え続けます(Agent ループ 参照)。制約は 3 つあります。
- トークン上限 — コンテキストウィンドウを超えた瞬間にエラーになる(または古い情報が silently 失われる実装になっている)
- コスト — 入力トークンは毎回の呼び出しで課金されるため、履歴の長さはコストに直結する
- 品質 — 長大なコンテキストでは重要な制約・指示が埋もれ、参照されにくくなる
2026 年時点ではコンテキストウィンドウの大きいモデルが一般的ですが、コストと品質の理由から「入るから全部入れる」は最適になりません。
詳細: 履歴圧縮の基本手法
| 手法 | 内容 | 注意点 |
|---|---|---|
| 刈り込み(truncation) | 古いツール結果・中間ログを落とす、または要点だけ残す | 何を落としてよいかはタスク依存 |
| 要約(summarization) | 古いターンをまとめて要約テキストに置換する | 損失圧縮。制約・決定事項が消える事故が起きる |
| 外部化 | 大きな成果物をファイル・DB に置き、履歴には参照だけ残す | 参照を辿る手段(読み出しツール)が必要 |
要約は便利ですが万能ではありません。「ユーザーが指定した制約」「すでに下した決定」「やってはいけないこと」など、圧縮後も必ず残す情報のリストを先に定義してから圧縮ルールを作ります。
詳細: セッション管理と長時間タスクの再開
会話履歴の生ログは、再開可能な状態ではありません。中断からの再開・別プロセスからの参照・進捗の可視化には、作業状態を構造化して外部に持つ必要があります。
- チェックポイント長時間タスクの「ここまで完了した」を再開可能な形で永続化したもの。ツール実行の完了やフェーズ境界などの意味のある単位で切る。信頼性とトークンコスト制御の両方の仕組み。: 「完了したステップ / 残りのステップ / 中間成果物の場所 / 決定事項」を構造化データとして保存します
- 再開: 「経緯の要約 + 構造化された作業状態」からコンテキストを再構築します。全履歴の再投入は不要です
- 長時間・マルチセッションで動く Agent では、この設計が実装の中心課題になります
詳細: 長期記憶と RAG の関係
長期記憶からの読み出しは、検索(retrieval)そのものです。実装はファイルベース・全文検索・ベクトル検索などで、検索の設計論は RAG と Agent の関係・使い分け と共通です。
読み出しより難しいのは書き込みです。「すべてを保存する」はノイズの山を作るだけなので、何を(事実・好み・決定)、どの粒度で(生ログではなく要約・構造化)、いつ(タスク完了時・ユーザーの明示指示時)保存するかの基準を決めます。
保存時には内容・粒度・時点に加え、出所(誰が・どの経路から)、信頼性・検証結果、保存してよい情報か(機微情報の最小化・期限・削除手段)を記録します。外部資料の命令やモデルの推測を、承認済みの決定として保存しません。読み出した記憶も外部入力として再検証し、指示や権限の根拠に昇格させません(記憶汚染)。
設計判断: 何をコンテキストに残し、何を外部化するか
| データの性質 | 置き場所 |
|---|---|
| 毎ターン参照する(直近のやり取り・現在の指示) | コンテキスト(短期記憶) |
| ときどき参照する(過去の詳細・大きな資料) | 外部 + 検索・読み出しツール |
| 再開・監視に必要(計画・進捗・決定) | 構造化して永続化(作業状態) |
| セッションを越えて使う(好み・ナレッジ) | 長期記憶 + 保存基準 |
コンテキスト全体(システムプロンプト・ツール定義も含む)をどう組み立てるかは コンテキストエンジニアリング で扱います。
実務での注意点
アンチパターン
- 全履歴を無限に持ち回る → ある日突然トークン上限で壊れ、コストは会話長に比例して増える → 圧縮戦略を最初のバージョンから組み込む
- 要約で制約・決定事項が消える → 圧縮後の Agent が過去の決定と矛盾する行動を取る → 「圧縮しても必ず残す情報」のリストを先に定義する
- 状態を会話履歴だけに置く → 中断・クラッシュで再開不能になり、進捗の外部監視もできない → 作業状態は構造化して履歴の外に持つ
チェックリスト
- コンテキスト上限に近づいたときの挙動(圧縮する / 停止して報告する)が定義されている
- 圧縮後も保持すべき情報(制約・決定・ユーザー指示)のリストがある
- 長時間タスクがチェックポイントから再開できる
- 長期記憶への書き込み基準(内容・粒度・時点・出所・信頼性・機微情報の最小化と削除)が決まっている
- 履歴の長さとコストの関係を見積もった
関連トピック
- Agent ループ — 履歴が増える仕組みの根本
- 長期記憶の実装 — 本記事の長期記憶層の実装編(抽出・保存・想起・忘却)
- RAG と Agent の関係・使い分け — 長期記憶の読み出し(検索)の設計
- プランニングと推論 — 計画を作業状態として持つ運用
- コンテキストエンジニアリング — コンテキスト全体の組み立ての設計論
- コンテキストの圧縮と隔離 — 本記事の圧縮手法の先(トリガ・階層化・隔離・仕切り直し)
参考資料
- Effective context engineering for AI agents(Anthropic) — コンテキストを有限資源として設計する考え方(アクセス日: 2026-07-05)