AI・信頼性・評価

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

2026/8/2 （更新: 2026/11/3）

🤖 AIを使用して執筆

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

エージェントが覚えているのは、その回の入力に入れたものだけである。入力の枠には上限があり、セッションを閉じれば履歴ごと白紙に戻る。だから知識を置く先を、三つの層に分けて考える。手前がコンテキストウィンドウ、その外が検索で取り出す枠の外の保存先（外部ストア）、いちばん奥がセッションを越えて持ち越すために書き出したもの（引き継ぎのメモや規約ファイル）である。

手前の層は、全部をコンテキストウィンドウに入れるやり方である。取り出しの仕組みが要らず、入れたものは落ちない。代わりに、枠を超える知識はそもそも扱えず、入力が長いほど費用と応答の遅れが増え、要る情報が読み落とされやすくなる。長い入力の中ほどに置いた情報は、モデルが見落としやすい⁶。

どれだけ読み落とすかはモデルによって違い、公称のコンテキストウィンドウの広さはそのまま当てにできない。2024年にロングコンテキストモデル17本を13課題で測ったRULERは、32K以上を公称しながら32Kで十分な性能を保てたのは約半数だったと報告する⁷。コンテキストウィンドウを広げるだけで足りるかどうかは、そのモデルで実測して確かめるほかない。逆に、GPT-5 にホテル経費の明細化を50課題こなさせた実測では、全履歴を持たせるほうが完了率を下げる方向に出た。ただしこの結果については、原典自身が95%信頼区間は少し重なると断っている⁸。

次の層は、資料を外部ストアに置き、要るぶんだけ検索して取り出す RAG である²。知識の量は枠の上限に縛られず、入力の費用は取り出した分だけで済む。ただし、答えの質は検索が当てた断片の質を超えない。依頼の文が触れていない指示は、検索に当たらない。要る断片を外せば、エージェントはそれ無しで、しかも自信を持って進み、外れたことは誰にも知らされない。索引を最新に保つ手間と、断片の切れ目で前後の文脈が分かれる問題も残る。

いちばん奥は、作業の区切りで次に要るものをセッションの外に書き出し、次のセッションへ持ち越す層で、引き継ぎがこれに当たる。少ない量で前の作業の続きを渡せる。だが書き出すのは履歴の一部だけで、あとで要る詳細を落とす。書き出したものが誤れば、以後の想起はその誤りを前提にするので、影響は一度では終わらない。落ちてはならない一文が書き出しから漏れても、エージェントは気づかないまま先へ進む。

三つの層は、どれか一つを選ぶものではなく、同時に使う。いま進めている作業で使うもの（作業集合）はコンテキストウィンドウに入れる。大きく、たまにしか使わない知識は外部ストアに置き、要るぶんだけ取り出す。セッションを越えて残す要点は、区切りで明示的に書き出して引き継ぐ。計算機のメモリ階層でいえば、それぞれ速い層、ディスクのような遅く大きい記憶、状態を書き出して後で戻す checkpoint に当たる。一つの作業の中の要約は、手前の層を枠に収めるための操作で、元の履歴を復元できない形に縮める圧縮（lossy な圧縮）である。どの層も、忘れることを前提にしている。失って困る知識は「覚えている」に頼らせず、枠の外へ書き出す。ただし、どの詳細を落としても安全かは、書き出すだけでは決まらない。どう忘れるかは、それ自体が設計の対象になる。

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

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

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

これは新しい規律ではない。レジスタ、キャッシュ、RAM、ディスクという、速度と容量を引き換えにするメモリ階層も、いま使う作業集合だけを速い層に置くというDenningのworking-set理論⁴も、状態を書き出して復元するcheckpoint/restoreも、ずっと計算機が持っていた。LLM（Large Language Model）にこの階層をそのまま当てた設計も既にある。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組で自由記述の要約に届いていない¹⁵。

OpenHands が自前の圧縮を 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付きの必須項目へ強制する。「言い忘れた」種類の誤りを防ぎ、受け取る側の機械が解析できる。だが硬直的だ。スキーマの外は表現できず、締めすぎれば、本当の意図が自由記述の備考欄に書かれるようになる。

初期値は、意図を「完全に formal 化する」ことではない。曖昧さのコストが高い所だけを固定する。ニュアンスや判断が要る所は、散文で渡し、人のレビューで意図とのずれを直す。誤りが可逆で、機械的に判定できる所は、受入基準（テスト・eval）で固定する。繰り返し使い、機械が読む入力は、構造化スキーマで必須項目を強制する。関数名の書き方のように形を機械で調べられる指示は検査に、文の読みやすさのような指示は散文に振り分ける。

どの形を選んでも、意図の全部は書き出せない。前提に置くのは、Naurが『Programming as Theory Building』で論じたことだ¹⁸。プログラムの本質は書き手の頭の中の理論であって、文書だけからその理論を復元することはできない。Naurの射程は自然言語の仕様に限らない。彼は理論を「表現されえない」ものとし、だから記法や形式化の選び方は二次的な問題にとどまると書く。原典は、仕様書もまた理論に対して従属する成果物として挙げている。形式化すれば埋まる、という道はここには無い。だから意図は一度で固定しようとせず、対話で収束させる。返してもらった計画をこちらが読み、ずれを指す。そのやり取りで詰めていく。狙うのは「言った通り」ではなく「意図した通り」だ。

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

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

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

曖昧な意図を機械で確かめられる形へ寄せる規律を、ソフトウェア工学は長く育ててきた。形式仕様（Z、VDM（Vienna Development Method）、契約による設計）と、その射程の限界を早くに指摘したNaur、要求工学、受入基準がそれにあたる。テストを実行可能な仕様として書くTDD（Test-Driven Development）と、特定領域に絞ったDSL（Domain-Specific Language）もある。新しいのは、仕様の受け手が、欠けたところを黙って埋めてしまうエージェントになったこと。だから、埋めさせたくない所だけを固定し、残りは対話で合わせる。どの曖昧さが高くつくかという判断も、誤ることはある。固定すべき所を散文のまま流したり、散文で渡すべきニュアンスをスキーマの項目に押し込めたりする。だからこの振り分け自体も一度では決めず、ずれが見えるたびに、対話の往復の中で引き直す。

別のエージェントや製品の記憶の設計を読むときも、性質の違う指示をいくつか置いて追えばよい。長い会話の先で、どの指示が入力に入っているか、落ちたことを後から確かめられるか、入っていても従わないときに何が止めるかを順に見る。白紙を越えて残るのは、枠の外へ書き出したものだけだ。だから、何を残すかを決めるのと同じだけ、何を落としたかを書き残す。

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