AI・信頼性・評価

AIエージェントの記憶の設計：RAG・要約・引き継ぎの使い分け

2026/8/2 （更新: 2026/10/14）

🤖 AIを使用して執筆

知識は忘れる前提でメモリ階層に外部化する

常に最新の知識を安く用意できる。だがエージェントのコンテキストウィンドウは有界で、しかもセッションをまたぐと記憶は白紙に戻る。載せられる知識には上限があり、覚えていることには頼れない。置き場は層で分けて考える。手前がコンテキストウィンドウ、その外が取り出しつきの外部ストア、いちばん奥がセッションを越える永続要約だ。

まず手前から。全部をコンテキストウィンドウに詰め込む。単純で、取り出しの仕組みも要らず、載せたぶんは忘れない。だがコンテキストウィンドウは有界だ。ハードな上限があり、埋まるほどコストとレイテンシが増え、肝心の信号が薄まる。長いコンテキストの真ん中に置いた情報は見落とされやすい¹。そしてコンテキストウィンドウを超える知識は、そもそも扱えない。ただし薄まり方はモデル依存で、公称のコンテキストウィンドウの広さはそのまま当てにできない。2024年にロングコンテキストモデル17本を13課題で測ったRULERは、32K以上を公称しながら32Kで十分な性能を保てたのは約半数だったと報告する²。コンテキストウィンドウを広げるだけで足りるかどうかは、そのモデルで実測して確かめるほかない。逆に、GPT-5 にホテル経費の明細化を50課題こなさせた実測では、全履歴を持たせるほうが完了率を下げる方向に出た。ただしこの一段については、原典自身が95%信頼区間は少し重なると断っている³。

次の層は、外部のストアに置き、必要なぶんだけ取り出す（RAG＝検索して取り出す仕組み）⁴。知識はコンテキストウィンドウの上限に縛られず増やせ、課金は取り出した分だけで済む。だが品質は取り出しの品質で頭打ちになる。正しい断片を外せば、エージェントはそれ無しで、しかも自信を持って進む。欠落は静かだ。索引の保守と鮮度、断片の境界が文脈を分断する問題も残る。

いちばん奥は、要約して圧縮し、永続する層だ（継続的な要約・記憶）。セッションの境界を越えて、要点を安く持ち越せる。連続性が生まれる。だが要約は lossy だ。あとで要る詳細を落とす。しかも要約が誤れば、以後の想起はその誤りを土台にするため、影響は一度きりでは終わらない。落ちてはならない一文が要約から消えても、エージェントはその欠落に気づかないまま先へ進む。

初期値は、どれか一つを選ぶことではない。三つはメモリ階層への写像であって、排他ではない。いま動かしているタスクの作業集合は、高速なコンテキストウィンドウに。大きく低頻度の知識は、外部ストアに置いて必要分だけ取り出す（バッキングストア）。セッションを越えて残すべき要点は、明示的に要約して永続する（checkpoint）。「忘れる」を欠陥でなく前提として設計する。失って困る知識を、暗黙の「覚えている」に頼らせない。明示的に外部化する。ただし、どの詳細を落として安全かの見切りまでは、外部化は肩代わりしない。そこから先、つまりどう忘れるかは、それ自体が設計の対象になる。

この三層は机上の設計ではない。Anthropic は、トークンを使うほど想起が落ちる context rot を挙げ、モデルの「注意の予算」を有限資源として扱うコンテキスト設計の指針を公開している⁵。そこで挙がる手立てには、常時読み込む規約ファイル、glob や grep でその場で読みに行く随時取得、別のコンテキストで探索して要約だけを返すサブエージェントがある。原典が長い時間軸への手立てとして自ら名指しするのは compaction, structured note-taking, and multi-agent architectures の三つで、ファイル基盤の記憶についても maintain project state across sessions と述べている。三層という束ね方は本稿の整理で、原典が三層と名づけているわけではない。

同じ階層が、出荷されている製品の中に具体的な仕掛けとして入っている。Claude Code の自動メモリは、索引ファイルの先頭200行（または先頭25KB）までを毎回の会話の冒頭に読み込み、話題別のファイルは起動時には読まず、必要になったときにモデルが自分で読みに行く。索引が上限に近づけば短くするよう促し、超えた場合は書き込み自体は通したうえで、索引を書き直せというエラーを返す。上限を超えた部分は次の読み込みで落ちるからだ⁶。常駐させる量の上限を、覚えている側の裁量ではなく、コードが握っている。

手前の層に何を載せるかを決める側も、機構にできる。Aider はリポジトリ全体の地図のうち「最も関係のある部分だけ」を送る。選び方は、各ソースファイルを節点、依存関係のあるファイル同士を辺とするグラフに対するランキングだ。大きさのほうは --map-tokens（既定1kトークン）という目安で、原典はチャットの状態に応じて動的に調整するとし、たいていは設定値に収まるが時に大きく展開するとも書く。予算は上限ではない⁷。それでも、何を載せるかをグラフの側が決めるなら、モデルが指示を守るかどうかは、この選択には効かない。埋め込み検索だけが外部ストアの取り出し方ではない、ということでもある。

これは新しい規律ではない。レジスタ、キャッシュ、RAM、ディスクという、速度と容量を引き換えにするメモリ階層も、いま使う作業集合だけを速い層に置くというDenningのworking-set理論⁸も、状態を書き出して復元するcheckpoint/restoreも、ずっと計算機が持っていた。LLM にこの階層をそのまま当てた設計も既にある。2023年の MemGPT は、OS の階層メモリに倣って速い記憶と遅い記憶のあいだでデータを動かし、有界のコンテキストウィンドウの外に記憶の層を置いた⁹。要約とは、lossy な圧縮の別名だ。新しいのは、エージェントの「記憶」が毎セッション白紙に戻ること。だから、覚えていることを当てにせず、外部化を設計に組み込む。

忘れ方を圧縮か引き継ぎかで決める

コンテキストウィンドウは必ず溢れる。溢れたときに何が落ちるかを決めていなければ、忘却は設計ではなく事故になる。だから実運用のハーネスは、忘れ方をコードに書いている。Cline の Auto Compact は、コンテキストウィンドウが上限に達したとき履歴を切り詰めるのでなく、包括的な要約に置き換えて作業を続ける¹⁰。Claude Code も同じ側で、コンテキストの上限に近づくと古い履歴を要約して場所を空ける自動コンパクションを持ち、/compact に指示を添えれば、要約のあいだ何を残すかを指定できる¹¹。ただしどちらも圧縮するのは一つの作業の中で伸びた履歴であって、セッションをまたぐ永続化そのものではない。

そして、ここで判断は割れた。Amp は2025年10月、圧縮を名指しで拒んだ。「まず、それは lossy だ。スレッドを圧縮するたび、コンテキストウィンドウの中にあるものは要約に置き換わる」。代わりに置いたのが Handoff で、「スレッドを要約するのではなく、次の仕事に効くものをそこから取り出す」と説明する。取り出したものを新しいスレッドへ移す。同じ記事は、さきほどの Claude Code の指示つき要約を、lossy であることへの手当てとして名指しで認めている。それでも Amp は、長く蛇行するスレッドを招くとして圧縮を製品から外した¹²。要約の上に要約を積む運用をインフラとして受け入れるか、作業の境目でいったん捨てて必要なものだけを持ち出すか。好みの違いではない。lossy な自己要約を、以後の判断の土台にし続けてよいかという判断だ。ただし Amp はこの立場を撤回した。2026年5月、Handoff を撤去して自動圧縮を既定に戻している。「いまの主要なフロンティアのモデルは圧縮の扱いが上手い」というのが理由で、根拠として挙がるのは利用者の反応であり、課題成績の測定ではない¹³。

では、どちらが良いのかは分かっていないのか。ここは正確に書く必要がある。測定はある。ただしそれが測っているのは二つの立場の優劣ではなく、圧縮そのものの代償のほうだ。素朴な要約圧縮を全コンテキストと比べた ACON（エージェントと圧縮器はともに gpt-4.1）では、AppWorld で全体12.5ポイント、難しい課題では15.9ポイント落ちた¹⁴。Qwen・Gemma・Devstral の24B〜31Bのモデル3種を後継に置き、引き渡し方を比べた研究でも、生の履歴をそのまま渡したほうが解決率は高い方向に出た。ただし原典自身が、付録の95%信頼区間は3組とも渡し方の間で重なると書き、さらに後継モデルを替えると好ましい形式が入れ替わるため一つの普遍的な順位は出ない、と断っている。表の上で後継モデルごとに入れ替わるのは、解決率で2位以下の順と、入力トークンを最も減らす形式のほうだ。構造化ノート、つまり引き継ぎ側の設計も、点推定では3組の後継モデルのうち2組で自由記述の要約に届いていない¹⁵。自前の圧縮を SWE-bench Verified の全件で on/off 比較した報告では、解決数が203から200へわずかに下がり、費用は40ドル増えた。買えたのは品質ではなく応答の速さだった（単一実行で有意性検定はない）¹⁶。

ただし符号は一定しない。その ACON 自身は、自分たちの手法では圧縮が効いたとも報告している。ただ、その勝ちが誰を相手にした勝ちかは見ておく必要がある。ACON が明確に上回るのは、無圧縮ではなく他の圧縮手法のほうだ。無圧縮を対照に置いた欄では、AppWorld は原典の言い方で「無圧縮という上限の精度を保った」水準にとどまる。手順の長い難問63課題に絞ると、同じ表で平均が最も高かった ACON の設定でも30.2で、無圧縮の39.7に届かない。OfficeBench では圧縮手法が全て無圧縮を下回る。しかもその成績は、圧縮の指針を課題ごとに最適化したうえでのものだ（学習用に取り分けた90課題で指針を最適化している）。素の要約モデルをそのまま当てた比較のほうは、先に見た通り無圧縮に負けている。だから「圧縮は情報を失う」と「圧縮は成績を上げる」は、同じ土俵の話ですらない。

残る空白は、もっと狭いところにある。出荷されているコーディング・エージェントで、フロンティアのモデルを使い、自動圧縮と引き継ぎを同じ課題で比べた公開の比較は見当たらない。だから今言えるのは、素の要約モデルを全コンテキストと比べれば情報が落ちるということであって、「圧縮は常に損だ」でも「引き継ぎのほうが良い」でもない。先に引いた実測³は、むしろ逆向きの符号を出している。直近5ツール呼び出しへの刈り込みに自動要約を足した構成が91.6%で、刈り込み単独の79.0%を上回る。同論文が信頼区間の明確な分離を認めたのはこの一組だけで、エージェントを Claude Sonnet 4.5 に替えた追試でも向きは変わらない（92.0%→94.5%）。ただしこれが比べているのも要約の有無であって、自動圧縮と引き継ぎではない。

どちらを採るにせよ、共通して効く規律が一つある。圧縮のあとにも会話の履歴は要約として残るが、何が残るかは要約次第だ。Claude Code のドキュメントは「/compact のあとで指示が消えたように見える」場合の説明として、プロジェクト直下の規約ファイルなら圧縮後にディスクから読み直して再注入するが、会話の中だけで与えた指示はそうしない、と書く。処方は「会話だけの指示を規約ファイルに足せ」である。つまりファイルへ書き出せ、ということだ⁶。要約に残ることを期待するのではなく、要約の外に置く。

残るのは、落としたこと自体をどう扱うかだ。ここに一つ、踏み込んだ実装がある。OpenHands の condenser は、履歴を圧縮するとき、圧縮したという事実を Condensation というイベントとしてイベント列に残す。そのイベントは、忘れられるイベントのIDと、任意の要約を持つ¹⁷。原文はこのIDを「LLM に渡す View から取り除かれるイベントのID」と書く。忘却が「気づいたら消えていた」ではなく、「いつ・何を落としたか」を後から辿れるデータになる。外部化の発想を、外部化する対象ではなく、コンテキストの管理そのものへ折り返した形だ。

この差は小さくない。記録のない忘却は、静かに壊れる側の典型だからだ。落ちたこと自体が記録されていなければ、失われたと気づく手段は「本来あるはずのものが無い」と誰かが後から思い当たることだけになる。逆に落としたことがデータとして残っていれば、失われた事実の発見は、思い当たりではなく照合の問題になる。

初期値はこうなる。落ちて困る一文は、要約に託さず先に外へ書き出す。圧縮は一つの作業の内側で使い、作業の境目では引き継ぎを使い、新しいコンテキストを始める。圧縮と引き継ぎを同じ課題で比べた公開の測定は見当たらないので、この使い分けは測定で裏づけた結論ではない。Cline も同じ分担を運用手順として書き、コンテキストウィンドウが埋まるあいだは Auto Compact に任せ、新しい段階に入ったら /newtask で要点だけを持ち出せとする¹⁰。そして境目で何を持ち出すかも、上で見たとおりまだ決着していない。点推定で最も高かったのは3組とも生の履歴をそのまま渡す側だった¹⁵。持ち出す量を絞れば手数や費用が下がるかについても、この研究は形式ごとに測っている。手数の側では最も量の多い生の履歴が3組とも最大の削減（57〜59%）を出し、絞ったノート類は20〜46%にとどまる一方、入力トークンの削減では3組のうち1組だけノート類が生の履歴を上回った¹⁵。もっとも同じ研究は考察の節で、生の履歴は大きく雑多で際限がなく、長く走る仕事では全履歴の再生が実用にならず、何を先へ渡すかも制御しにくくなると自ら断っている¹⁵。そして、何を落としたかは記録に残す。忘れること自体は避けられない。避けられるのは、忘れたことに気づけないほうだ。

意図は曖昧さの高い所だけ仕様で固定する

もう一つの問題に移る。意図を仕様に落とすのも、それを生成させるのも安くなった。だが自然言語の仕様は曖昧だ。書いた通りに伝わるとは限らない。何を仕様の担い手にするかで分けて考える。散文のまま渡すか、実行可能な受入基準にするか、構造化スキーマで縛るかだ。三択を貫く軸は、検証可能性と表現力の引き換えにある。そのうえで効くのは、振り分けを一度で決めず、対話の往復で引き直すという運用の側だ。

• 散文の自然言語でそのまま伝える（プロンプトが仕様）。最も速く、最も表現力が高い。翻訳のステップが要らないから、ニュアンスも文脈も判断の余地も、そのまま渡せる。だが自然言語は本質的に曖昧で、必ずどこかを言い落とす。欠けた仕様を、エージェントは「聞き返す」より「もっともらしく埋める」。ズレは沈黙のうちに入り込む。意図が一致したかを、機械で確かめる術もない。
• 実行可能な受入基準で固定する（テストやevalが仕様）。検査点で意図が一意に決まり、機械で可検になる。合否が客観的だ。だが、判定の手順に落とせる意図しか書き込めない。趣味やトーンは載りにくい。字面を固定して精神を逃す危うさ（テストに最適化してしまう）もあり、そもそも良いevalを作ること自体が高い。
• 構造化スキーマやフォームで制約する（スキーマが仕様）。曖昧な依頼を、型やenum付きの必須項目へ強制する。「言い忘れた」クラスの誤りを潰し、境界で機械が parse できる。だが硬直的だ。スキーマの外は表現できず、締めすぎれば、本当の意図が free-text の備考欄へ逃げていく。

初期値は、意図を「完全に formal 化する」ことではない。曖昧さのコストが高い所だけを固定する。ニュアンスや判断が要る所は、散文で渡し、人のレビューで写像のズレを直す。誤りが可逆で、判定を operational にできる所は、受入基準（テスト・eval）で固定する。繰り返し使い、機械が読む入力は、構造化スキーマで必須項目を強制する。核心は、Naurが『Programming as Theory Building』で論じたことを前提に置くことだ¹⁸。プログラムの本質は書き手の頭の中の理論であって、文書だけからその理論を復元することはできない。Naurの射程は自然言語の仕様に限らない。彼は理論を「表現されえない」ものとし、だから記法や形式化の選び方は二次的な問題にとどまると書く。原典は、仕様書もまた理論に対して従属する成果物として名指ししている。形式化すれば埋まる、という逃げ道はここには無い。だから意図は一度で固定しようとせず、対話で収束させる。返してもらった計画をこちらが読み、ズレを指す。そのやり取りで詰めていく。狙うのは「言った通り」ではなく「意図した通り」だ。

意図を書き出す先として広く使われているのは、「毎セッション自動で読み込まれる規約ファイル」だ。製品ごとに呼び名は違うが、ベンダーをまたぐ共通の形式として AGENTS.md もあり、運営側の一覧は OpenAI の Codex、Google の Gemini CLI、Aider、Amp などを対応ツールとして挙げる¹⁹。規約ファイルには強制力がない。Claude は規約ファイルを、強制される設定ではなくコンテキストとして扱う、とドキュメント自身が書く⁶。コンテキスト設計の側から見ると、もう一つの限界のほうが効く。分量だ。Claude Code のドキュメントは、規約ファイルを1ファイル200行未満に収めよという目安を示し、理由を「長いファイルはコンテキストを消費し、遵守を下げる」と書く⁶。書けば書くほど守られる、ではない。ここでも載せる量は予算であり、意図の固定は無料ではない。

配達だけを機構にした設計もある。Cline の Focus Chain は、依頼を受けた時点で必要な手順に番号を振った一覧を作り、以後の各段階でその一覧を確認して進捗を記し、残りを直す。一覧は作業のあいだコンテキストに付いて回る。原典が動機として挙げるのは、生成が進むにつれ先に踏んだ段階が実効的な注意の窓から外れ、同じ操作のやり直し・前の決定との矛盾・脱線が起きること、そして「長いコンテキストだけでは決め手にならない」ことだ²⁰。superpowers はもっと単純で、セッション開始のフックが指示文書の全文を毎回冒頭へ入れ直す。v6.2.0 が定義するフックはそれ一つで、実行時に操作をブロックするフックは持たない²¹。

二つに共通するのは、届くことは機構が保証し、従うことは保証しないという形だ。本稿ではこれを「機構が配達する指示」と呼び、守らせる機構ではなく指示の一種として扱う。コンテキスト設計の側から足しておきたいのは、配達の周期のほうだ。Focus Chain は一覧を繰り返し入れ直す。間隔は設定でき、既定は6メッセージごとだとドキュメントは書く¹⁰。一方 superpowers のフックは SessionStart の一つだけで、起動時と /clear・/compact の後に入る。これは規約ファイルを冒頭で読ませ、圧縮後に読み直させる設計と同じ周期である。届け直す仕組みを持つことと、窓から外れる前に届け直すことは、別のことだ。それでも、入れ直したから守られる、とは読めない。

曖昧な意図を機械可検な形へ寄せる規律を、ソフトウェア工学は長く育ててきた。形式仕様（ZやVDM、契約による設計）と、その射程の限界を早くに言い当てたNaur、要求工学、受入基準、テストを実行可能な仕様として書くTDD、特定領域に絞ったDSLがそれにあたる。新しいのは、仕様の受け手が、欠けたところを黙って埋めてしまうエージェントになったこと。だから、埋めさせたくない所だけを固定し、残りは対話で合わせる。どの曖昧さが高くつくかという判断も、誤ることはある。固定すべき所を散文のまま流し、逃がすべきニュアンスをスキーマで潰す。だからこの振り分け自体も一度では決めず、ズレが見えるたびに、対話の往復の中で引き直す。相手が覚えていてくれることを前提に組んだ設計は、次の白紙で破綻する。白紙を越えて残るのは、層に写した知識と対話で詰めた意図、つまり外部化したものだけだ。だから、何を残すかを決めるのと同じだけ、何を落としたかを書き残す。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。