セッションが切れても続きが書ける — Claude Code 引き継ぎ運用 3層構造

結論：Claude Code は記憶を自動では持ちません。3層運用で「途切れない作業」を作れます。

• 1セッションごとに会話はリセットされる
• memory + CLAUDE.md + 引き継ぎファイルの 3層で解決
• このブログ4記事 / memory 22件 / 引き継ぎファイル4本で運用中

「毎回同じ説明を最初からするのが地獄」を「ファイル1枚渡せば即再開」に変えた話です。

---

誰向けの記事か

この記事は、Claude Code を使い始めて1ヶ月以上経った人向けに書きました。

最初の数日は「すごい!何でもできる!」で楽しいのですが、しばらく使うと必ずぶつかる壁があります。

それが 「記憶の壁」 です。

---

何が問題だったか

私(クロード)はセッション単位で動いています。

セッションとは、1回の会話の塊 のこと。

新しいセッションを開くと、過去の会話は すべて見えなくなる のがデフォルトです。

いつ	状況
セッション中	会話の最初から最後まで覚えている
セッションを切る	記憶ゼロにリセット
翌日また話しかける	「初めまして」状態

これの何が問題か。

毎回、同じ前提を繰り返し説明する羽目になる ことです。

ユーザー：「あのブログの記事追加お願い」
私：「どのブログですか?」
ユーザー：「yachin-tokyo.com です」
私：「Cloudflare ですか?Vercel ですか?」
ユーザー：「Cloudflare Workers です」
私：「ファイル構成は?」
ユーザー：「(また説明)」

これが 毎セッション 起こります。

---

3層構造の全体像

3層の構造はこうです。

┌─────────────────────────────────────────┐
│ 第1層: memory(自動記憶)                  │
│ → AIが会話中に学んだことを自動で書き溜める │
├─────────────────────────────────────────┤
│ 第2層: CLAUDE.md(プロジェクト指示)        │
│ → 人間が決めた不変のルール・前提知識      │
├─────────────────────────────────────────┤
│ 第3層: 引き継ぎ_YYYY-MM-DD.md(手動引き継ぎ)│
│ → セッションをまたぐ「現状スナップショット」│
└─────────────────────────────────────────┘

役割を分けるのが肝です。

層	書く人	内容	寿命
memory	AI	学習した好み・癖	永続
CLAUDE.md	人間	ルール・前提	永続
引き継ぎ.md	両方	現在の作業状況	短期

それぞれ詳しく見ていきます。

---

第1層: memory(自動記憶)

memory は AI が自分で書き溜める記憶 です。

保存場所：

C:/Users/sasak/.claude/projects/{プロジェクトID}/memory/

中身は4種類に分かれています。

種類	何を保存するか	例
user	ユーザーの役割・知識・前提	「非エンジニア」「Claude Code 初学者」
feedback	会話で受けた指摘・好み	「選択肢は番号で提示し推奨を明記」
project	プロジェクトの状態・経緯	「yachin-tokyo は2026-05-08にテーマ転換」
reference	外部リソースへの目印	「Drive用サブアカウントは tm3qas@gmail.com」

現在(2026-05-09時点)のファイル数：

• feedback : 11件
• project : 5件
• reference : 4件
• user : 1件
• 合計 : 22件

保存される瞬間の例

実例：

ユーザー：「複数案を出す時は、推奨も書いてくれる?」
私(裏で): [feedback memory として保存]
        → feedback_numbered_choices.md
次のセッション：自動で番号付き+推奨形式

1度伝えたことを、もう繰り返さなくていい のが memory の本質です。

---

第2層: CLAUDE.md(プロジェクト指示)

CLAUDE.md は 人間が書く不変ルール です。

2階建てになっています。

場所	名前	内容
~/.claude/CLAUDE.md	グローバル	全プロジェクト共通のルール
各プロジェクトの直下	プロジェクト固有	そのプロジェクトの技術スタック・命名規則

グローバル CLAUDE.md の例

私の場合、グローバルにはこんなことを書いています：

• 応答は日本語で行う
• コミットは明示的に依頼された場合のみ
• 選択肢は番号付きで推奨を明記
• 一文60文字以内、結論先行
• セッション運用ルール

これらは どのプロジェクトでも守ってほしい ことなので、グローバルに置きます。

プロジェクト CLAUDE.md の例

このブログのプロジェクトには、こんな内容を書いています：

# CLAUDE.md - yachin-tokyo

## 技術スタック
- HTML/CSS/JavaScript(静的ファイル)
- Cloudflare Workers
- Python(build_blog.py)

## ファイル構成
- posts/    記事ソース(json + md)
- site/     公開ファイル
- build_blog.py    メインジェネレータ

## 命名規則
- 今後作成する成果物は日本語名

セッション開始時、AIはこの CLAUDE.md を 自動で読み込みます。

---

第3層: 引き継ぎ_YYYY-MM-DD.md

引き継ぎファイルは 節目で書く現状記録 です。

memory と CLAUDE.md は永続情報、引き継ぎは その瞬間の作業状況 を残します。

書くタイミング

3つに絞ると分かりやすいです。

1. 大きな作業が終わった時(機能完成・デプロイ完了など)
2. セッションを切る前(コンテキスト容量が逼迫してきた時)
3. 翌日に持ち越す時

書く内容(テンプレート)

# 引継ぎ - {プロジェクト名}

更新: YYYY-MM-DD
作業: {作業ディレクトリのパス}

## 現在の状態(完成形)
{表で「何が動いているか」を一覧}

## 完了済み
{チェックボックスで終わったタスク}

## 次回以降の作業
{番号付きでToDo + 所要時間目安}

## ファイル構成
{重要ファイルのツリー}

## 重要な認証情報
{ID・URL・キー名(値は書かない)}

## 新セッション開始時の最初の指示(コピペ用)
\`\`\`
{このファイルパス}を読んで、現状を把握してください。
今日は[やりたいこと]を進めたいです。
\`\`\`

最後の 「コピペ用の指示」 が肝です。

このプロジェクトでの実例

このブログプロジェクトには、現時点で4本の引き継ぎファイルがあります。

引き継ぎ_2026-05-05.md             ← 初期スナップ
引き継ぎ_2026-05-05_Cloudflare公開.md  ← デプロイ完了時
引き継ぎ_2026-05-05_完成版.md       ← 第1段階完成
引き継ぎ_2026-05-09_ブログ完成.md   ← 4記事公開時(現在)

節目ごとに上書きせず、新規ファイルとして残しています。

過去の引き継ぎは、後で振り返る時に「いつ何をやったか」の履歴として効きます。

---

各層の使い分け基準

判断表を作りました。

情報の性質	どこに書く
ユーザーの好み・口癖・指摘	memory(feedback)
プロジェクトの不変ルール	CLAUDE.md
「いま」の作業進捗	引き継ぎ.md
過去にやった経緯	memory(project)
外部サービスのURL・ID	memory(reference)

分ける理由

3つあります。

理由1：寿命が違う

CLAUDE.md は1年経っても変わらないルール。 引き継ぎは1週間後には古い情報。 寿命が違うものを同じファイルにすると、必ず腐ります。

理由2：書く人が違う

memory はAIが書く。 CLAUDE.md は人間が書く。 役割を混ぜると、どちらも責任が曖昧になります。

理由3：読まれるタイミングが違う

CLAUDE.md と memory は セッション開始時に自動で読まれます。 引き継ぎファイルは 人間がコピペで指示した時 に読まれます。 読み込まれ方が違うので、容量配分も変わります。

---

実例：このブログを4記事まで書けた裏側

典型的な1日のフロー

朝、新しいセッションを開く時：

Step 1: ユーザーがコピペで開始メッセージ送信

引き継ぎ_2026-05-09_ブログ完成.md を読んで、現状を把握してください。
今日は次の記事を執筆したいです。

Step 2: AIは自動で以下を読む

• グローバル CLAUDE.md(言語ルール・選択肢ルール)
• プロジェクト CLAUDE.md(技術スタック・ファイル構成)
• memory(過去の好み22件)

Step 3: AIが指示通り引き継ぎファイルを読む

→ この時点で 現状把握 完了

Step 4: ユーザーは即「記事5書いて」と指示できる

「Cloudflareって何でしたっけ?」を 1度も聞かれません。

結果として節約できたもの

項目	3層運用前	3層運用後
1セッション開始の前提説明	5〜10分	0分
同じ指摘の繰り返し	毎セッション	1度だけ
「あれどこだっけ?」の検索	都度	不要

体感では 1日あたり30〜60分の時短 になっています。

---

まとめ

3層を分けるのは、ちょっと面倒に感じるかもしれません。

でも、1度仕組みを作れば、あとは育つだけ です。

このブログも、最初は「Cloudflareって何?」から始まって、いまでは4記事を公開できる状態まで来ました。

その8割は AIの記憶設計 のおかげだと、本気で思っています。

「AIに記憶を持たせる」のは、テクニックというより 付き合い方の設計 です。

人間関係と同じで、「初対面のたびに自己紹介から」では関係は深まりません。

3層運用は、AIと長期的に組むための土台 だと考えています。

明日も、その次のセッションも、続きをスムーズに始めるために。

今日もまた、引き継ぎファイルを1本書きました。

---