Claude Memoryツールで複数セッション開発を再開するパターン

Memoryツールを「復旧の仕組み」として使う

複数のエージェントセッションにまたがるソフトウェア開発プロジェクトでは、Memoryファイルをその場しのぎで書き足していくのではなく、あらかじめ決めた形で用意しておく運用パターンが公式ドキュメントで紹介されています。狙いは単純です。各セッションが、前のセッションが記録した状態から正確に再開できるようにする。Memoryを単なるメモ帳ではなく、セッションが切れても壊れない復旧の仕組みとして設計します。

ここで扱うMemoryツールは、Messages APIに自分で組み込む機能で、Claude Codeが自動で書き溜めるメモリとは別物です。両者の違いはClaudeの記憶の仕組みで扱っています。

このパターンは3段階に分かれます。最初のセッションがメモリファイルを準備する「初期化セッション」、以降のセッションがそれを読んで作業を再開する「後続セッション」、そして各セッションの終わりに進捗を書き戻す「終了時更新」です。

なぜMemoryが「復旧の仕組み」として機能するのか

Memoryツールの前提には、Just-in-time context retrieval(必要になった時点で文脈を取りに行く設計)があります。関連情報をすべて事前にコンテキストへ積み込むのではなく、エージェントが学んだことをメモリファイルに記録し、必要になったタイミングで読み戻します。この仕組みが効くのは、コンテキストウィンドウを圧迫しない長時間セッションの構成が可能になるからです。

複数セッション開発のパターンは、この「必要な時に読み戻す」を、セッションの境界そのものに適用したものだと捉えられます。1回のセッションが終わっても、次のセッションは進捗ログとチェックリストという最小限の情報をviewするだけで、それまでの作業全体を再度コンテキストに積み直すことなく再開できます。逆に、この準備がなければ、後続セッションはコードベース全体を読み直し、過去の設計判断を推測し直すところから始めることになり、セッションが増えるほどコストが積み上がっていきます。

初期化セッションで3点を用意する

実質的な作業に入る前に、最初のセッションで次の3点を用意します。

1. 進捗ログ: 何が完了し、次に何をするかを記録するファイル
2. 機能チェックリスト: 作業のスコープそのものを定義するファイル
3. 起動・初期化スクリプトへの参照: プロジェクトが必要とする起動手順への言及

公式ドキュメントはファイルの正確なフォーマットまでは規定していません。仕様から素直に導ける一例を挙げると、次のような構成になります(あくまで一実装例で、これが唯一の正解ではありません)。

/memories/progress.md       ← 進捗ログ(完了/次にやること/直近の判断理由)
/memories/checklist.md      ← 機能チェックリスト(スコープと完了条件)
/memories/setup.md          ← 起動・初期化スクリプトの場所と実行方法

progress.mdの中身は、時系列の追記式にしておくと後続セッションが読みやすくなります。

## 2026-09-01 セッション1
- 完了: 決済APIクライアントの雛形作成
- 未着手: 認証まわり
- 次にやること: OAuthトークンの取得処理から着手する
 
## 2026-09-02 セッション2
- 完了: 認証実装
- 未着手: リトライ処理
- 次にやること: 429応答時の指数バックオフを実装する

checklist.mdはスコープと完了条件を対にして書きます。「実装した」ではなく「何をもって完了とみなすか」まで書いておくと、終了時更新のときに完了マークを付けてよいかどうかを機械的に判断できます。

後続セッションは読むだけで再開できる

2セッション目以降は、作業を始める前にこれらのメモリファイルを読むところから入ります。ここが効いてくるポイントです。コードベースを再探索したり、過去の設計判断をもう一度たどり直したりせずに、プロジェクトの状態を復元できます。

Memoryツールを有効にすると、自動でシステムプロンプトに「まず自分のメモリディレクトリを確認せよ」という指示が追加されます。この指示と初期化セッションでの準備がかみ合って初めて、後続セッションは/memoriesをviewした瞬間に「前回どこまで進んだか」「次に何をすべきか」を把握できます。逆に言えば、初期化セッションが進捗ログとチェックリストを残していなければ、この自動指示は空振りに終わり、セッションはコードベースの再探索から始めることになります。

セッション終了前に進捗ログを更新する

セッションが終わる前に、進捗ログを「何を完了し、何が残っているか」で更新します。これによって、次のセッションが正確な出発点を持てます。ここを省略すると、進捗ログは初期化セッション時点の情報のまま古びていき、後続セッションが実態と異なる前提で再開してしまいます。

公式ドキュメントが明記する原則が1つあります。一度に1つの機能だけを進めることです。そして、ある機能を「完了」と記録してよいのは、エンドツーエンドの検証で実際に動くことを確認できたときだけで、コードを書き終えた時点ではありません。この線引きを緩めると、進捗ログの「完了」表示が信用できなくなり、後続セッションが「完了しているはずの機能」の上に積み増して壊す、という事故につながります。

具体例で見る3段階の流れ

決済APIの実装を3セッションに分けて進める場合を考えます。

セッション1(初期化): 要件を確認し、checklist.mdに「決済APIクライアントの実装」「エラー時のリトライ処理」「結合テスト」の3項目を書き、progress.mdに「決済APIクライアントの雛形を作成、認証まわりは未着手」と記録して終了します。

セッション2(後続、1回目): /memoriesをviewし、progress.mdから前回の到達点を、checklist.mdから残タスクを把握します。コードベースを読み直す必要はありません。認証処理を実装し、str_replaceでprogress.mdを「認証実装済み、リトライ処理は未着手」に更新して終了します。

セッション3(後続、2回目): 同様にprogress.mdを読んで再開し、リトライ処理と結合テストまで終えます。ここで初めてchecklist.mdの3項目すべてに完了マークを付けます。エンドツーエンド検証(結合テストの実行)を経ているため、この「完了」は信頼できる状態です。

この流れのポイントは、各セッションが前セッションの詳細な作業ログではなく、要約された状態(進捗ログ)とスコープ(チェックリスト)だけを読んで再開している点です。会話ログそのものを持ち越すわけではないので、セッションをまたいでもコンテキストウィンドウは圧迫されません。

その場しのぎで書いたメモリは何が問題か

このパターンを使わず、Claudeにその場その場で自由にメモリファイルを書かせるとどうなるでしょうか。公式ドキュメントは明言していませんが、パターンが解決しようとしている課題から逆算すると、起きやすい問題は2つに整理できます。

1つ目は、ファイルの粒度と役割がセッションごとにばらつくことです。あるセッションはnotes.txtに何でも書き込み、別のセッションはtodo.mdを新設する、といった状態になると、後続セッションはview /memoriesで一覧を見ても、どのファイルを読めば現在の状態が分かるのか自分で推測しなければなりません。進捗ログとチェックリストという2つの役割をあらかじめ固定しておけば、この推測コストは発生しません。

2つ目は、「完了」の基準が曖昧になることです。決められた形式がなければ、あるセッションは実装が終わった時点で完了と書き、別のセッションは検証まで終えてから完了と書く、という揺れが生まれます。一度に1つの機能だけを進め、エンドツーエンド検証を経てから完了と記録するという原則を全セッションで共有して初めて、進捗ログは後続セッションが無条件に信頼できる情報源になります。

Context editingやCompactionとの役割分担

長時間稼働するエージェントの文脈管理には、MemoryツールのほかにContext editingとCompactionがあります(いずれもベータ機能で、専用のベータヘッダーが必要です)。役割は分かれています。Context editingは古くなったツール結果や思考ブロックを選択的に消す仕組み、Compactionは会話全体がコンテキストウィンドウの上限に近づいたときに自動で要約する仕組みです。どちらも「今の会話」の中で効きます。

一方、Memoryはセッションをまたいで残るという点で性質が異なります。Compactionが会話を要約してしまっても、要約から漏れた詳細やまだ実装していないタスクの理由は、Memoryファイルに書いてあれば失われません。長時間稼働するエージェントでは、この2つを併用するのが公式の推奨です。Compactionでクライアント側の管理コストをかけずに文脈を小さく保ちながら、要約を超えて残すべき情報だけをMemoryに書く、という役割分担になります。複数セッション開発のパターンは、この「Compactionを超えて残すべき情報」を進捗ログとチェックリストという形に定型化したもの、と捉えると位置づけが分かりやすくなります。

まとめ

複数セッションにまたがる開発では、Memoryファイルをその場しのぎで書くのではなく、初期化セッションで進捗ログ・機能チェックリスト・起動スクリプト参照の3点を用意します。後続セッションはそれを読むだけで再開でき、終了前には進捗ログを検証済みの事実だけで更新します。関連トピックとしては、ツール呼び出しループ全体の自動化を扱うTool RunnerでAnthropic APIのツール呼び出しループを自動化する、長時間セッションのトークンコストを抑える別の手段であるAnthropic APIのPrompt Cachingを理解する、Memoryツールの各コマンドの仕様を扱うClaude Memoryツールの6コマンド実装、複数セッションにまたがる運用で確認しておきたいClaude Agent SDKはプランの利用上限を消費するかがあります。