第8章: メモリ階層と圧縮 ── 長時間ループの命綱
あるエンジニアが Claude Code でこう呟いた。
「前回の続きやって、って打ったら、Claude が普通に続きを始めた。覚えてるの?」
別のエンジニアは Cursor の Agent モードでこう驚いた。
「
.cursorrulesに書いた癖を、ちゃんと反映してくれる」
さらに別のエンジニアは Codex CLI でこう試した。
「3 時間動かしっぱなしで
/compactを 5 回打ったら、まだ動いてる」
LLM 自身は 何も覚えていない。前章で見た通り、机に置いた紙しか見ていない。 それなのに、なぜプロジェクト固有の流儀を「知っている」ことになり、長時間ループでも息切れせずに走り続けられるのか。
答えはひとつ ── ハーネスが 記憶を階層化し、必要なものだけを机の上に並べ直し続けている からだ。 この章では、その階層の正体に踏み込む。
8.1 そもそも、LLM は何も覚えていない
第7章までで何度か触れてきた前提を、もう一度はっきり書いておく。
LLM 自体は記憶を持たない。 「前回の会話を覚えている領域」も「ユーザーの好みを記録する変数」も、モデル本体には一切存在しない。 ChatGPT も Claude Code も Cursor も Devin も、毎ターン過去の会話全部をテキストとして渡し直しているだけ ── そう見せかけているだけだ。
つまり「エージェントに記憶を持たせる」とは、本当は 「ハーネスが何を、どこから、いつ机の上に並べるか」 を設計することに等しい。
前章で見たように、机（コンテキストウィンドウ）には物理的な上限がある。 だから記憶は 机の上にすべて積むわけにはいかない。必要なものを、必要なタイミングで、必要な分だけ並べ直す ── そのための仕組みが「メモリ階層」だ。
8.2 四つの層 ── 寿命と置き場所で分ける
現代のコーディングエージェントの記憶は、寿命と置き場所でだいたい 四つの層 に分かれる。
| 層 | 寿命 | 置き場所 | 共有範囲 |
|---|---|---|---|
| システムプロンプト | エージェントのバージョン中ずっと | ハーネス本体にハードコード | プロダクトのユーザー全員 |
| プロジェクトメモリ | リポジトリが残るかぎり | CLAUDE.md / AGENTS.md / .cursorrules 等 | git で他人と共有 |
| セッションメモリ | セッションを閉じると消える | 机の上 (コンテキストウィンドウ) | そのセッションだけ |
| スクラッチパッド (外部記憶) | ファイルが残るかぎり | 任意の Markdown ファイル、Notepad MCP 等 | 設計次第 |
イメージ図にすると、こうなる。
順に見ていく。
8.3 システムプロンプト ── ハーネスに焼き付いた憲法
一番上の層は システムプロンプト。各プロダクトのハーネス本体に焼き付いている「あなたは Claude Code です」「あなたは Cursor の Composer です」といった根本指示文だ。
| プロダクト | システムプロンプトの位置づけ |
|---|---|
| Claude Code | Anthropic がハーネスに同梱。ユーザーは直接書き換えない |
| Cursor | Cursor 社がハーネスに同梱 |
| Codex CLI | OpenAI / コミュニティ実装に同梱 |
| Devin | Cognition 社がハーネスに同梱 |
| Aider / OpenHands | OSS なのでソース上で確認・改変可能 |
ユーザーが触りにくい代わりに、プロダクト固有の「らしさ」 はここから滲み出る。Claude Code がやけにテスト駆動っぽく動くのも、Devin が PR をやけに丁寧に立てるのも、ほとんどはこの層に書き込まれた指示文の差で説明がつく。
8.4 プロジェクトメモリ ── リポジトリに住む引き継ぎ書
二つ目の層が、本書で最も実務寄りの話 ── プロジェクトメモリ だ。
各プロダクトには、リポジトリのルートに置く Markdown / テキストファイル という共通の慣習がある。名前は違うが、役割は驚くほど揃っている。
| プロダクト | プロジェクトメモリのファイル名 |
|---|---|
| Claude Code | CLAUDE.md / AGENTS.md |
| Cursor | .cursorrules / .cursor/rules/*.mdc |
| Codex CLI | AGENTS.md |
| Cline / Continue | .clinerules / .continuerules |
| Aider | CONVENTIONS.md |
| OpenHands | .openhands_instructions |
プロジェクトメモリリポジトリのルート（またはサブディレクトリ）に置く、エージェント宛の Markdown / テキストファイル。 ハーネスは起動時にこれを読み込み、システムプロンプトの末尾に差し込む か、最初のユーザーメッセージとして注入する。 git で他人と共有されるので、チーム全員のエージェントの挙動が揃う。
中身として書くのは、プロダクトを問わずだいたい同じだ。
- このプロジェクトのコンセプト、扱うドメインの前提
- ディレクトリ構成、命名規則、設計判断の理由
- ビルド・テスト・デプロイのコマンド
- やってはいけないこと、つまづきポイント
2026 年時点では、AGENTS.md が エージェント横断の事実上の標準 になりつつある。Claude Code も Codex CLI も他のエージェントも、両方を読む実装が一般的だ。
プロジェクトメモリは “リポジトリに同梱された、エージェントへの引き継ぎ書” だ。
git で版管理され、PR でレビューされ、main に取り込まれた瞬間、チーム全員のエージェントの挙動が揃う。
プロダクト名は違っても、この発想はプロダクト横断で共通している。
8.5 セッションメモリ ── 机の上の会話履歴
三つ目の層は セッションメモリ ── 第7章で「机」と呼んでいた、その本体だ。
ユーザーが入力した質問、LLM の応答、ツール呼び出しの引数と戻り値 ── これらが時系列に机の上に積み上がっていく。濃いけど短命 という性質を持つ。
- 濃い: 直近のやり取りの全文を保持するので、いま話している話題に関する情報量は最大
- 短命: ターミナルを閉じる、
/clearする、別の作業に切り替えると、全部消える
ここで自然に出てくる疑問がある。
机が満杯になってきたとき、ハーネスは具体的に何をしているのか?
答えは大きく二つに分かれる ── 捨てる か、畳む か、だ。
/clear ── 机を全部リセットする
/clear は 机の上を一気に綺麗にする 操作。
新しい話題に移るとき、あるいは context rot で挙動が雑になってきたとき、机を全消去して仕切り直す。
- メリット: 机が完全に空になるので、context rot が一掃される
- デメリット: 直前までの作業文脈が 完全に失われる
「ファイルを直す」「テストを走らせる」など、文脈の連続性が必要な作業の途中で /clear を打つと、エージェントは振り出しに戻る。話題が切り替わるとき に限って使うのが鉄則だ。
/compact ── 机の上を畳んで小さくする
一方の /compact は これまでの会話を要約して、机を整理する 操作。
圧縮 (compaction)これまでのセッションメモリを LLM に要約させ、要約だけを残して詳細な履歴を捨てる操作。 作業文脈は保ったまま、机のサイズだけ小さくなる のが特徴。 Claude Code の
/compact、Cursor の自動要約、Codex CLI の/summarizeなど、各プロダクトに同等の機能がある。
イメージはこうだ。
圧縮前: [system] [user] [Read結果 5,000tok] [Bash結果 8,000tok]
[Edit結果] [Read結果] [Bash結果] ... ← 机ぎっしり
圧縮後: [system] [要約: これまでに parser.ts のバグ
3 つを修正し、テスト 2 つが緑、残り 1 つが赤 ...]
← 机がすっきり、作業文脈は保たれる| 操作 | 何が残るか | 何が消えるか | いつ使うか |
|---|---|---|---|
/clear | システムプロンプト + プロジェクトメモリだけ | 会話履歴 全部 | 話題が切り替わるとき |
/compact | 要約された作業文脈 | 詳細な履歴・ツール出力 | 同じ作業を続けたいが机が重いとき |
/clear は離婚、/compact は引っ越し。
前者は関係そのものを終わらせる。後者は持ち物を整理して、新しい小さな部屋で関係を続ける。
長時間タスクの命綱になるのは圧倒的に後者だ。
8.6 スクラッチパッド ── 机の外に置く外部記憶
四層目の スクラッチパッド は、最近のエージェント運用で急速に重要度が増している層だ。
発想はシンプルで、「机に乗せきれない情報を、ファイルに書き出して、必要なときだけ道具で読み戻す」 というもの。 ハーネスや LLM 自体が記憶を持つのではなく、ファイルシステム自体を外部記憶として使う。
具体的な姿はこういう形を取る。
- 作業計画を
plan.mdに書き出し、後でReadし直す - 中間的な調査結果を
notes/2026-05-19.mdに保存する - TodoWrite ツールが内部で持つタスクリスト
- Anthropic の Memory tool（モデルがファイル経由で長期記憶を扱う公式機能）
- Notepad MCP など、メモ専用のサーバーをツールとして接続する
スクラッチパッド (外部記憶)机（コンテキストウィンドウ）の外に情報を書き出し、必要時に道具で読み戻す仕組み。 書き出したテキストは机の上から消えるので、机を圧迫しない。 「巨大な調査結果は要約だけ机に置き、本体はファイルに残す」「計画は再起動後も読み戻せるよう外部に書く」など、長時間タスクの肝になる発想。
スクラッチパッドの何が偉いかというと、机のサイズと記憶の量を完全に切り離せる ことだ。
- 机 (コンテキストウィンドウ) は 200k トークンしかない
- でもファイルなら 100MB 書ける
- 必要なときだけ、机の上に一部を取り出して使う
これは人間が手帳やドキュメントに頼るのと、原理的に同じ構造をしている。
8.7 長時間ループという新しい地平
ここまでの四層を理解すると、長時間ループ という、近年急に現実味を帯びてきた話題が読めるようになる。
長時間ループ1 つのタスクで、エージェントが 数時間〜数日にわたって走り続ける 運用形態。 Devin の「数日かけてリポジトリを書き換える」、Claude Code を起動しっぱなしで一晩動かす、サブエージェントを並列に何十も走らせる ── などが典型例。短時間の対話型エージェントとは桁が違うタイムスケールで動く。
長時間ループでは、机が満杯になる頻度がぐっと上がる。ハーネスは次のような延命技術を組み合わせて使う。
| 技術 | 何をするか |
|---|---|
自動 /compact | 机が一定割合埋まったら、ハーネスが自動で圧縮を発火する |
| チェックポイント書き出し | 重要な進捗をスクラッチパッドに定期的に保存し、再起動に備える |
| サブエージェント分割 | 重い調査を別の机（別ループ）にやらせ、結果だけ受け取る（第9章で詳述） |
| メモリ tool / 永続ストア | 長期で再利用したい知見を、セッションを越えてファイルに残す |
長時間ループの命綱は、机そのものを広げることではなく、机の外を上手に使うことだ。 机を広げる（コンテキストウィンドウを増やす）には LLM 側の進化が必要だが、机の外を使う技術は、ハーネス側だけで今すぐ進化させられる。 だから 2026 年現在、エージェント勢力争いの主戦場のひとつが メモリ階層と圧縮の設計 になっている。
8.8 図解 ── 階層と読み込みタイミング
最後にもう一度、四層がいつ机の上に並ぶかを整理しておく。
| タイミング | 並ぶもの |
|---|---|
| エージェント起動時 | システムプロンプト + プロジェクトメモリ（毎ターンの先頭に常駐） |
| ユーザーがターンを打つ | セッションメモリに新しいユーザーメッセージが追加 |
LLM が Read/Bash を呼ぶ | ツール結果がセッションメモリに追加 |
LLM がスクラッチパッドを Read する | 必要な分だけ、外部記憶の一部がセッションメモリに転写 |
/compact 発火 | セッションメモリが要約に置き換わる |
/clear 発火 | セッションメモリがリセット（システム + プロジェクトは残る） |
私が長時間ループを回すときに守っているのは、3 つだけだ。
- プロジェクトメモリは “新人への引き継ぎ書” として書く ── 命令ではなく文脈と理由を書く
/compactを惜しまない ── 机が重くなったら畳む。判断が鈍ってから畳むのは遅い- 重要な進捗はスクラッチパッドに必ず書き出す ── ハーネスが落ちても再開できる状態を作る
この三つだけで、Claude Code でも Cursor でも Codex CLI でも、長時間ループの安定性が体感で 2 倍くらい変わる。 プロダクト固有のテクニックよりも、四層モデルの上でどう振る舞うか のほうがずっと効く。
8.9 この章の振り返り
- LLM は何も覚えていない。記憶とはハーネスが机の上に何を並べるかの設計 のこと
- 記憶は四層 ── システムプロンプト / プロジェクトメモリ / セッションメモリ / スクラッチパッド
- プロジェクトメモリ は
CLAUDE.md/AGENTS.md/.cursorrulesなどプロダクト横断で共通の発想 - セッションメモリ は机の上の会話履歴。濃いけど短命
/clearは机を全消去、/compactは机を要約して縮める。後者が長時間ループの命綱- スクラッチパッド は机の外にファイルとして書き出す外部記憶。机のサイズと記憶の量を切り離せる
- 長時間ループの安定性は、机を広げるより 机の外を上手に使う ことで決まる
この章で読めるようになるツイート / ブログ
- 「
CLAUDE.md長くなりすぎて、毎ターンのトークンが地味に痛い」 → プロジェクトメモリは毎ターン机の先頭に乗り続けるので、長さがそのままトークンコストになる - 「Cursor の
.cursorrulesと Claude Code のCLAUDE.mdって、結局同じこと書くよね」 → プロダクトを越えてプロジェクトメモリ層は共通の発想。ファイル名だけが違う - 「
/clearするか/compactするかで毎回迷う」 → 話題が切り替わるなら/clear、同じ作業を続けたいなら/compact。後者は作業文脈が残る
次章は、いよいよ 計画とサブエージェント に踏み込む。 ひとつの机では捌けない仕事を、複数の机に分割する という発想 ── それが、長時間ループのもう一つの命綱となる。 本章で残した「机の分割」という宿題は、次章で正面から扱う。