LLMアプリのメモリ設計は、モデルの性能以前に「品質・コスト・運用」のバランスを決める設計判断です。 本記事では、3つのメモリ方式（都度全文・要約・外部記憶）を定義し、5つの業務シナリオでトークン数とコストを試算。「この条件ならこの方式」を判断できる選定ガイドと、入力パラメータ式の試算表を公開します。
この記事の前提と使い方
本記事は、AIエージェントの4設計要素（TMPE）を前提知識とし、4要素のうち特にM（メモリ）をプロダクト設計としてどう実装するかを扱います。
使い方: まず「3方式の違い」をデータフローで掴み、次に試算表のセクションで自社のシナリオに近い数字を確認してください。最後の選定ガイドで、どの方式を主戦略にするかの判断に落とせます。
対象読者と前提
本記事はビジネスサイドの方を主な読者として想定しています。技術内容は正確に記述しますが、ソースコードやJSON・スクリプトは掲載しません。「何ができるか」「なぜそうするか」を中心に、図解・表・箇条書きで表現しています。
背景と前提：なぜメモリ設計が必要なのか
LLMは基本的にステートレスです。毎回の推論は「その時点で渡したコンテキスト（入力トークン）」にのみ依存します。会話が長くなるほど、同じ履歴を繰り返し送ることになり、入力トークン課金と遅延が膨らみます。
「コンテキストウィンドウが大きければ解決」は半分だけ正解
長文対応モデルは進歩していますが、二つの構造的な制約は残ります。
| 制約 | 内容 |
|---|---|
| コスト | トークン課金は入力長に比例する。長いほど高い構造は変わらない |
| 計算負荷 | Transformerはコンテキスト長に対して計算・メモリ負荷が増えやすい |
ドリフト：長い対話で起きる「ズレ」
さらに、長い対話ではドリフト（意図・制約から徐々にズレる）が現実的な問題になります。研究でもmulti-turnの文脈ドリフトが定義され、リマインダーなどの軽い介入で改善できる「運用でコントロール可能な現象」と整理されています。
メモリ設計の最短ルート
メモリは 短期（コンテキスト内）／長期（プロフィールや合意事項）／外部記憶（検索して参照） に分け、どれを「毎回そのまま入れるか」「要約して入れるか」「必要時に取りに行くか」を決めるのが最短ルートです。
3方式の定義とデータフロー
ここでは「都度全文」「要約メモリ」「外部記憶（RAG/DB）」を、データの流れで定義します。実装では混在し得ますが、比較のために「主戦略」で分類します。
短期・長期・外部を分ける最小モデル
| 記憶層 | 何を入れるか | 特徴 |
|---|---|---|
| 短期（コンテキスト） | 直近の会話、ツール結果、タスク状態 | 「最後のNターン」が扱いやすい |
| 長期（プロフィール） | ユーザー嗜好、制約、合意事項 | 再利用価値が高いが頻繁に変わらない情報 |
| 外部記憶（RAG/DB） | 全文ログ、社内ナレッジ、ドキュメント | 普段は入れず、必要時に検索して参照する層 |
この3層をどう使うかが、次の3方式の違いです。
方式1：都度全文（毎回、履歴を全部送る）
| 観点 | 評価 |
|---|---|
| 強み | 履歴の忠実性が最大。要約による情報落ちや改変が起きない |
| 弱み | 会話が伸びると入力トークンが累積し、同じ履歴を繰り返し課金する |
| ありがちな誤算 | ツール出力（検索結果・ログ・表）が長いと、1ターンでも入力が跳ねる |
方式2：要約メモリ（直近N＋古い履歴の要約）
| 観点 | 評価 |
|---|---|
| 強み | 長い対話でも、入力に入れる"過去"を要約で固定化でき、コストと遅延を抑えやすい |
| 弱み | 要約は「脱落・誤重み付け・誤りの混入」リスクがあり、更新を繰り返すと誤りが蓄積する（context poisoning） |
方式3：外部記憶（検索して必要な断片だけ持ってくる）
| 観点 | 評価 |
|---|---|
| 強み | 大容量を外に逃がし、必要な断片だけを持ってくる。更新と根拠提示に向く |
| 弱み | 検索の品質・遅延・運用（インデックス更新、権限、監査）がプロダクト品質を左右する |
要約メモリのドリフトと最新対策
要約メモリは「安い・長持ち」になりやすい一方で、ビジネス側が期待する"継続性"を壊す典型要因がドリフトです。
ドリフトは「要約の誤差が時間方向に増幅する」問題
要約には次の4種類の誤差が入り得ます。
- (a) 重要情報の脱落：合意事項や制約が消える
- (b) 曖昧な表現への置換：具体的な数値が「適切な範囲」に変わる
- (c) 事実の取り違え：AとBの属性が入れ替わる
- (d) ニュアンス変更：強い言い換えで意味が変わる
これが"次の要約"の入力になると、誤差が連鎖し、誤った前提が固定化する危険があります。一方で、ドリフトは一定水準で安定し、リマインダー（目標・制約の再提示）など軽い介入で下げられることも示されています。
更新戦略：4つの原則でドリフトを抑える
| 原則 | 内容 |
|---|---|
| 矛盾チェック | 要約がシステム指示・ツール定義・ログと矛盾していないかを要約時に点検する |
| 時系列（最新優先） | 出来事を時間順に並べ、後から上書きされた情報は「最新が勝つ」形にする |
| UNVERIFIEDラベル | 会話に書かれていない事実を推測で補完しない。曖昧なものは未検証として残す |
| チャンク化（見出し分割） | 長文段落より、カテゴリ別の短い箇条書きにして後から取り出しやすくする |
要約は「状態（state）」として扱う
要約が状態なら、監査（ログ保存）、差分比較、回帰テストが可能になります。要約生成の入力・出力・プロンプトをログして、品質の変化を追跡できるようにしましょう。
評価（eval）はメモリの品質保証として必須
要約・外部記憶は、誤りが入っても即座に気づきにくく、後になって事故が顕在化します。推奨される評価手法は次の通りです。
- Transcript Replay：長い会話ログを再生して、次ターン精度や制約保持を測る
- 要約品質のLLM採点：要約の正確性・網羅性をLLMで自動評価
- トークン圧迫監視：重要文脈が落ちていないかを定量的にチェック
安全性と運用上の注意：メモリは攻撃面になる
"長期に残るメモリ"は、ユーザー価値の源泉である一方、攻撃面にもなります。
- 知識ベース汚染：RAG知識ベースや長期メモリを汚染して、特定条件で悪性挙動を誘発する攻撃が報告されている
- メモリポイズニング：通常のユーザー入力だけで長期メモリを汚染し、将来の応答を歪める脅威
メモリは「真実」ではなく「入力データの一種」
メモリを安全に運用するには、次の4点をプロダクト要件に含める必要があります。
- (1) 書き込み条件：何をメモリに保存するかのルール
- (2) 出典（provenance）：そのメモリはどこから来たか
- (3) 削除/訂正：誤ったメモリを修正できる仕組み
- (4) 権限境界：誰のメモリを誰に見せるか
外部記憶（RAG/DB）運用の実際
外部記憶は「必要なときだけ参照できる」ため、長期運用でコストが読みやすくなりますが、品質は検索設計に強く依存します。
ハイブリッド検索は"用語一致"と"意味一致"を両取りする
| 検索方式 | 強み | 弱み |
|---|---|---|
| BM25（全文検索） | 用語・固有名詞・型番の一致に強い | 言い換えや概念の類似に弱い |
| ベクトル検索 | 言い換え・概念類似に強い | 固有名詞の完全一致に弱い場合がある |
| ハイブリッド（RRF等） | 両方の強みを統合、実運用の定番 | 設計空間が広く、チューニングが必要 |
リランキングのトレードオフ
ハイブリッド検索にリランキングを加えるとPass@10（上位10件の適合率）が改善し得る一方、追加の遅延とクエリあたりコストが発生します。効果とコストの見合いで判断しましょう。
レイテンシは平均ではなく「P95/P99」で見る
検索はLLM本体より高速でも、ユーザー体験では「遅い時がある」が致命傷になります。ベンチマークでは平均ではなくP95/P99のテールレイテンシを重視し、スループットと同時に評価することが推奨されています。
外部記憶で本当に大事な3つのポイント
| ポイント | 内容 |
|---|---|
| データ鮮度 | 古い文書を取ってくると、LLMは自信満々に古い手順を生成する（=もっともらしい誤り） |
| チャンク設計 | 小さすぎると文脈が欠け、大きすぎるとノイズが増え入力トークンも増える |
| 権限と監査 | 誰の記憶を誰に見せるかを誤ると、情報漏洩とコンプライアンス事故に直結する |
トークンとコスト試算の枠組み
ここでは「価格は変動する」前提で、スプレッドシートにそのまま移せる入力パラメータ式に落とします。金額は「単価パラメータ」として置き、固定値断定を避けます。
変数定義（シートの入力欄に相当）
セッション特性| 変数 | 意味 |
|---|---|
| T | 1セッションのターン数（ユーザー発話回数） |
| Δ | 1ターンで増える会話ログ量（ユーザー＋アシスタント＋ツール出力の平均トークン） |
| N | 短期として保持する「直近ターン数」 |
| 変数 | 意味 |
|---|---|
| B | 毎回ほぼ固定で入るトークン（システム指示、ツール仕様、プロフィール等） |
| S | 要約メモリの長さ（トークン） |
| R | 外部記憶から注入する参照コンテキストの長さ（トークン） |
| 変数 | 意味 |
|---|---|
| q | 1ターンあたりの検索回数（0, 1, 2...） |
| c_db | 検索1回あたりの外部基盤コスト |
| 変数 | 意味 |
|---|---|
| p_in | 入力1トークン単価 |
| p_out | 出力1トークン単価 |
| p_cached | キャッシュされた入力トークン単価 |
| h | キャッシュヒット率（0〜1） |
キャッシュの書き込みコスト
プロバイダによってはキャッシュの「書き込み」に追加コストがある体系もあるため、必要なら p_cache_write を別立てにしてください。
3方式の入力トークン概算（セッション単位）
都度全文：T に対して二次で増える
各ターン t（1..T）で入力は概ね B + tΔ。セッション総入力は：
Tok_full ≈ T・B + Δ・T(T+1)/2
ポイントは T に対して二次で増えることです。長い会話ほど同じ履歴を何度も送るため、コストの伸びが急激になります。
要約メモリ：一次に近い伸び
各ターンの入力は概ね B + S + min(t,N)・Δ。セッション総入力（T > N のケース）は：
Tok_sum ≈ T・(B+S) + Δ・(N(N+1)/2 + (T−N)・N)
要約更新の追加LLM呼び出しがある場合は、更新頻度Kを置いて更新回数 U ≈ ⌊T/K⌋ を加算します。
要約更新のスパイク
要約更新は「別モデルで安くやる」設計もありますが、更新時にコストと遅延のスパイクが発生します。式で見える化しておくのが実務的です。
外部記憶：一次＋検索コスト
各ターンの入力は概ね B + min(t,N)・Δ + R。セッション総入力（T > N）：
Tok_ext ≈ T・(B+R) + Δ・(N(N+1)/2 + (T−N)・N)
これに加えて、外部検索コストを Cost_search ≈ (T・q)・c_db と置きます。
トークン増加の比較：会話が長くなるほど差が開く
この図の核心は単純です。都度全文は会話が長くなると二次曲線で急増し、要約・外部記憶は一次に近い伸びに留まる。10ターン以下なら差は小さいですが、20ターンを超えると差が顕著になります。
キャッシュが入ると比較がどう変わるか
Prompt/context caching は「同一（または同一プレフィックス）のプロンプトを繰り返すと、遅延と入力コストが下がる」機構で、各社が提供しています。
| 観点 | 内容 |
|---|---|
| 削減効果 | 長いエージェントタスクでAPIコストを41〜80%削減し、TTFT（最初のトークンが返るまで）も改善し得る |
| 注意点 | 「どこをキャッシュ可能な塊にするか」を誤ると、ナイーブな全コンテキストキャッシュが逆にレイテンシを悪化させ得る |
| 効く条件 | 繰り返しが多い固定部分（システム指示など）で効果が大きい |
キャッシュの効き方は方式によって異なります。
- 都度全文：システム指示部分はキャッシュが効くが、毎ターン伸びる履歴部分は効きにくい
- 要約メモリ：要約が安定している間はキャッシュが効きやすい
- 外部記憶：検索結果が毎回変わるため、参照部分のキャッシュヒット率は低い
シートでは 「キャッシュ対象トークン比率 α」 と 「キャッシュ割引係数」 を変数化するのが安全です。
3方式 × 5シナリオの試算表
以下は「比較ができる」ことを目的にした例です。金額は上のパラメータ（p_in, p_out, p_cached, h, c_db）を差し込んで計算します。
シナリオ一覧と入力パラメータ
| シナリオ | T | Δ | B | N | S | R | q |
|---|---|---|---|---|---|---|---|
| 短尺FAQ | 6 | 200 | 800 | 4 | 250 | 0 | 0 |
| 中尺の継続サポート | 20 | 250 | 900 | 6 | 350 | 0 | 0 |
| 長尺のコーチング/要件定義 | 60 | 250 | 900 | 6 | 450 | 0 | 0 |
| ナレッジQA（参照が主役） | 12 | 200 | 850 | 4 | 0 | 1200 | 1 |
| 分析エージェント（検索＋ツール多用） | 30 | 400 | 1000 | 6 | 450 | 2000 | 3 |
トークン概算の比較
| シナリオ | 都度全文 Tok_full | 要約 Tok_sum | 外部記憶 Tok_ext | 都度全文 vs 最安の比率 |
|---|---|---|---|---|
| 短尺FAQ | T=6: 9.0千Δ相当 | 11.5千（S加算） | 7.2千 | 約1.0倍（差が小さい） |
| 中尺サポート | T=20: 70.5千Δ相当 | 39.5千 | 39.5千 | 約1.8倍 |
| 長尺コーチング | T=60: 511.5千Δ相当 | 81.0千 | 81.0千 | 約6.3倍 |
| ナレッジQA | T=12: 25.8千 | 18.0千 | 24.6千（R大） | 約1.4倍 |
| 分析エージェント | T=30: 216.0千 | 73.5千 | 114.0千（R+q大） | 約2.9倍 |
表の読み方
- 都度全文は T が大きいほど Δ の二次項が支配的になり、伸びが速い
- 要約と外部記憶は「短期N＋一定量（SまたはR）」に概ね抑えられるため、伸びが一次に近い
- 外部記憶は R（参照コンテキスト長）と q（検索回数）がコストと遅延の主要ドライバになる
- 短尺FAQでは方式間の差が小さいため、最もシンプルな都度全文でも問題ない
外部記憶の「保管コスト」も忘れずに
外部記憶にはトークンコストとは別に、ベクトルストレージ（日次課金）や検索ツール呼び出し課金もかかります。シートでは c_db にこれらを含めて計算してください。
3方式の特性レーダーチャート
選定ガイド：この条件ならこの方式
都度全文が向く条件
| 条件 | 理由 |
|---|---|
| 短く終わる会話（10ターン以下） | 二次曲線の影響が小さく、コスト差がほぼない |
| 厳密な再現性が必要 | 要約による改変がなく、ログそのものが事実になるため、デバッグ・監査が単純 |
| キャッシュが効くプロンプト構造 | 固定部分を安定化し、動的部分を末尾に寄せる構造にすれば、長めの会話でも成立し得る |
要約メモリが向く条件
| 条件 | 理由 |
|---|---|
| 会話が長い（20ターン超） | 都度全文の二次増加を避けられる |
| 過去の合意・制約・進捗を持ち続ける必要がある | コーチング、要件定義、長期案件管理など |
| ドリフト対策をセットで導入できる | 構造化、時系列、矛盾チェック、UNVERIFIEDラベル、回帰評価が必須 |
要約メモリ単体の導入は危険
要約メモリを「安いから」という理由だけで導入し、ドリフト対策を省略すると、長期運用で品質が劣化します。(1) 構造化、(2) 時系列、(3) 矛盾チェック、(4) 未検証ラベル、(5) 回帰評価をセットにしてください。
外部記憶が向く条件
| 条件 | 理由 |
|---|---|
| 参照すべき情報量が大きい | 社内ナレッジQA、規程、製品DB、履歴検索 |
| 更新頻度がある | 外部に持つことで、最新化が容易 |
| 根拠提示が必要 | 「何を根拠に回答したか」を示せる |
| 検索の運用体制がある | ハイブリッド検索、リランキング、テールレイテンシ評価など、検索の運用がプロダクト品質の中心になる |
実務での結論：三層分離＋"参照に行く"を標準にする
多くのプロダクトで安定する結論は次の三層構造です。
| 層 | 内容 | 運用のポイント |
|---|---|---|
| 短期 | 直近Nターン＋直近ツール結果 | 短く保つ。不要なツール結果は省略 |
| 長期 | プロフィール/合意事項 | 小さく、構造化し、更新は厳格に |
| 外部 | ログとナレッジを保持し、必要時に検索して注入 | 検索品質＝プロダクト品質 |
そして、要約・外部記憶・キャッシュのいずれを使う場合でも、「メモリは入力であり、品質保証とガードレールが必要」 という姿勢が重要です。
メモリの運用設計は省略できない
永続メモリは価値を生む一方で攻撃面にもなります。書き込み・取り出し・削除・監査の運用設計を、プロダクト要件の一部として最初から組み込んでください。
この記事の著者
Agentic Base 編集部
AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。
