Claude Code セッション引き継ぎテンプレ｜次の自分とAIが秒で再開する書き方

金曜の夜。Claude Codeと3時間かけてバグの原因を半分まで追い込んだ。「続きは月曜」とだけメモして閉じた。

月曜の朝、その続きを開いた僕は、自分が何を確かめて何を確かめていないのか、まったく思い出せませんでした。会話履歴をスクロールして、触ったファイルを開き直して、結局1時間かけて「金曜の自分」に追いつくだけで午前が終わった。

これ、AIが優秀かどうかとは関係ない話です。セッションが切れた瞬間、頭の中にあった「どこまで進んだか」が消える。次に座る人間も、次に立ち上げるAIセッションも、そこから空っぽで始まる。だから毎回ゼロから読み直す羽目になる。

これを防ぐのが、たった十数行の引き継ぎメモです。今日はその中身を、コピペできるテンプレと一緒に置いていきます。

この記事の要点

• Claude Codeは会話を閉じると文脈を忘れる。次の自分・チーム・次のAIセッションのために、作業状態を短いメモで外に出しておく。
• 残すのは4つだけ。やったこと / 残タスク / 技術決定 / つまずき。長い日報ではなく、次の一手が打てる粒度で。
• CLAUDE.mdは「毎回守るルール」、引き継ぎメモは「今日だけの作業状態」。混ぜると両方が腐る。
• コンテキストが切れる前に書くのがコツ。最後の30秒で、未確認の項目こそ正直に残す。
• この記事のテンプレと自動生成スクリプトはそのままコピペで使える。git statusを埋め込んだメモを一発で作れます。

なぜ「続きは明日」で事故るのか

Claude Codeは賢いですが、記憶力は金魚です。セッション（一回の会話のまとまり）を閉じれば、そこで積み上げた文脈はほぼ消えます。あなたが「あのファイルは触らない方がいい」と学習したことも、「この仮説は外れた」と分かったことも、次の会話には引き継がれません。

人間も似たようなものです。3日前の自分が何を考えていたかなんて、本人ですら覚えていない。だから「会話履歴を読めばいいでしょ」は罠です。100往復のログを読み返すより、要点を15行にまとめたメモを1枚読む方が、はるかに速く再開できます。

引き継ぎメモが効く場面は、思っているより多いです。

場面	メモがないと起きること
翌日の自分が再開する	何を確認済みか思い出せず、同じ調査をやり直す
チームの別の人が引き継ぐ	触ってよい範囲が分からず、別担当の変更を上書きする
次のAIセッションに渡す	AIが文脈ゼロから始め、的外れな修正をする
CIの失敗をまたいで調べる	どのコミットで何が壊れたか追えなくなる
10言語の記事を順に直す	どの言語まで直したか分からなくなる

共通しているのは、「頭の中にしかない情報」が消えた瞬間にコストが跳ね上がる、という一点です。メモは、その頭の中を紙に移す作業にすぎません。

引き継ぎに残す4つの中身

何でもかんでも書くと、誰も読まないメモになります。残すのは次の4つに絞ってください。

1. やったこと（Current state） 今どのブランチで、どのファイルを触っていて、何が分かっているか。「商品カードのCSSを読んで、原因はmin-width周りだと当たりがついた」くらいの具体度で。

2. 残タスク（Next） 次に何をするか。ここがいちばん大事です。「次のセッションではgit statusとこのメモを照合して、未確認の項目から始める」のように、最初の一手を行動で書く。

3. 技術決定（Decisions） なぜその方針にしたか。「ライブラリAではなくBを選んだ。理由はバンドルサイズ」。理由を残さないと、次の人が同じ議論をもう一度やります。

4. つまずき（Risks / pitfalls） 外れた仮説、壊れやすい場所、触ってはいけないファイル。「config/配下は本番設定なので触らない」「Xという仮説は試したが違った」。これがあると、次の人が同じ落とし穴を踏みません。

順番にも意味があります。やったこと → 残タスク → 技術決定 → つまずき。最初の2つで「今どこにいて、次どこへ行くか」がわかり、後ろの2つで「なぜそうなったか、どこが危ないか」が補える。次の作業者は、上から読むだけで再開できます。

CLAUDE.md と引き継ぎメモの使い分け

初心者がいちばん混同するのが、CLAUDE.mdと引き継ぎメモの役割です。両方とも「Claudeに文脈を渡す」ものなので、つい一緒くたにしてしまう。でも寿命がまったく違います。

CLAUDE.mdは、毎回守ってほしいプロジェクトの規約です。ビルドコマンド、コード規約、レビュー観点、触ってはいけない領域。数週間後も有効な、長持ちする情報を置きます。

引き継ぎメモは、今日の作業状態です。「このslugの韓国語だけまだ未確認」「このPRはDB移行をまだ見ていない」。明日には古くなる、使い捨ての情報です。

	CLAUDE.md	引き継ぎメモ
寿命	数週間〜数ヶ月	今日〜数日
内容	守るべきルール	今の作業状態
例	「descriptionは120字以内」	「今日このバグの原因を半分追えた」
置き場所	リポジトリ直下のCLAUDE.md	handoffs/やIssue、Slack

判定はかんたんです。「同じ注意を何度も書いているな」と感じたら、それは引き継ぎではなく規約。CLAUDE.mdに昇格させてください。逆に「今日だけの状況」は引き継ぎメモに留める。この線引きができると、CLAUDE.mdが一時メモで汚れず短いまま保てます。短いCLAUDE.mdは人にもAIにも読まれます。

CLAUDE.mdそのものの書き方を詰めたい人はCLAUDE.mdベストプラクティスを、既存コードの全体像をAIに把握させる前段は既存コードベースの地図化を合わせて読むと、引き継ぎとつながります。CLAUDE.mdやメモリの公式な扱いはMemoryが一次情報です。

コンテキストが切れる前に書く

引き継ぎメモは、書くタイミングが9割です。

よくある失敗が、「全部終わってから書こう」と思って、力尽きてそのまま閉じるパターン。僕は何度もやりました。疲れている金曜の夜に限って、いちばん複雑な状態を抱えている。そして翌週、何も思い出せない自分が待っている。

おすすめは、作業の区切りごとに30秒だけメモを更新することです。1つの仮説を検証し終わったとき、1ファイル直し終わったとき。そのたびに「今やったこと」と「次やること」を上書きする。長い会話の終盤になってコンテキストが圧迫される前に、外部に逃がしておく感覚です。

特に正直に書いてほしいのが、未確認の項目です。npm run buildが通っただけでは、公開URL・スマホ表示・クリック計測・フォーム送信が正しいかは分かりません。「ビルドは通った、でも本番URLは未確認」と書く方が、「たぶん大丈夫」より100倍安全です。次のセッションが、最小の確認から入れます。検証の残し方を仕組みにしたいなら検証レシートのワークフローが参考になります。

コピペで使える引き継ぎテンプレ

まずはこの型から始めてください。完璧な文章は要りません。次の作業者が判断できる粒度が正義です。

# Claude Code 引き継ぎメモ

## やったこと（Current state）
- branch:
- 触ったファイル:
- いま分かっていること:

## 残タスク（Next）
- 次の一手:
- 完了条件:

## 技術決定（Decisions）
- 採用した方針と理由:

## つまずき（Risks / pitfalls）
- 外れた仮説:
- 壊れやすい場所 / 触らないファイル:
- 承認が必要な操作:

## 次のプロンプト
git status とこのメモを照合し、「やったこと」と差分を確認してから、
未確認の残タスクだけを進めてください。報告は変更点と確認結果だけで構いません。

チームで集計したい、Issueやダッシュボードに流したい場合は、これにJSONを添えると機械が読めます。

{
  "slug": "claude-code-session-handoff-template",
  "branch": "fix/product-card-overflow",
  "status": "原因を特定、修正は未着手",
  "files": ["site/src/pages/products.astro"],
  "decisions": ["min-width撤廃ではなくmax-width追加で対応する"],
  "checksRun": ["frontmatter parse", "build"],
  "checksMissing": ["本番URLでのモバイル表示確認"],
  "nextAction": "390px幅で再現を取り、max-widthを当てて差分を確認"
}

JSONは状態だけを持たせ、判断理由はMarkdown本文に書くのが扱いやすい配分です。JSONに理由を詰め込むと、なぜそうしたかが読み取れなくなります。

引き継ぎメモを自動で作るスクリプト

毎回手で型を起こすのは面倒です。gitの現在状態を埋め込んだメモを一発で作る、Node.jsだけで動くスクリプトを置いておきます。scripts/write-handoff.mjsとして保存してください。

import { execSync } from "node:child_process";
import { mkdirSync, writeFileSync } from "node:fs";
import { join } from "node:path";

// gitコマンドを叩いて、失敗してもメモ作成は止めない
function run(command) {
  try {
    return execSync(command, { encoding: "utf8" }).trim() || "(出力なし)";
  } catch (error) {
    return `ERROR: ${error.message}`;
  }
}

const date = new Date().toISOString().slice(0, 10);
const branch = run("git branch --show-current");
const status = run("git status --short");
const recentCommit = run("git log -1 --oneline");
const outDir = "handoffs";
const outFile = join(outDir, `${date}-handoff.md`);

mkdirSync(outDir, { recursive: true });

// 現在のgit状態を埋め込んだ引き継ぎメモのひな型
const body = `# Claude Code 引き継ぎメモ

## やったこと（Current state）
- branch: ${branch}
- 直近コミット: ${recentCommit}
- 触ったファイル:
\`\`\`text
${status}
\`\`\`
- いま分かっていること:

## 残タスク（Next）
- 次の一手:

## 技術決定（Decisions）
-

## つまずき（Risks / pitfalls）
-

## 次のプロンプト
git status とこのメモを照合し、未確認の残タスクから再開してください。
`;

writeFileSync(outFile, body, "utf8");
console.log(`書き出しました: ${outFile}`);

確認はこの2行です。1行目は構文チェックだけ、2行目で実際にファイルを作ります。

node --check scripts/write-handoff.mjs
node scripts/write-handoff.mjs

handoffs/2026-06-07-handoff.md のようなファイルができ、ブランチ名・直近コミット・変更ファイル一覧がすでに埋まっています。あとは「やったこと」と「次の一手」を一言ずつ足すだけ。30秒で済みます。これを習慣にすると、メモを書くハードルがほぼゼロになります。

実務で効く4つの使い方

1. 多言語記事の公開作業 日本語を直したあと英語・中国語・韓国語…と展開すると、どの言語まで直したか必ず分からなくなります。対象slug、触った言語、残っている検証、内部リンク、CTAの確認をメモに入れる。「日本語と英語は確認済み、韓国語と中国語は文字化け再チェックが必要」と書いておけば、次のセッションがそこだけ拾えます。

2. バグ調査の途中停止 「390px幅で商品カードのCTAが横にはみ出す」と分かったのに原因を書かずに終えると、次の人はCSS全体を読み直します。再現条件、怪しい箇所、外れた仮説、次の最小修正を残す。それだけで再開が数分になります。

3. コードレビューの交代 認証・課金・DB移行のような危ない差分で「レビュー中」とだけ残すのは危険です。どのリスクを見たか、どのテストが足りないか、承認前に誰が確認すべきか。レビュー観点をチームで揃えるならチーム引き継ぎルールにつなげると運用が安定します。

4. 複数AIエージェントの並行作業 別ブランチ・別slugを他の人やAIが触っているとき、「触ってよいファイル」と「触らないファイル」を必ず書く。これを省くと、品質改善のつもりで別担当の変更を丸ごと上書きする事故が起きます。僕は一度やって、半日分のコミットを溶かしました。

僕がやらかした引き継ぎの失敗

正直に書きます。最初の頃の引き継ぎメモは、ほぼ役に立っていませんでした。

ひとつ目は、ファイル名だけ並べたこと。「products.astroを見た」と書いても、なぜ重要かが抜けていれば次の人は結局開き直します。「価格カードのmin-widthが390px表示ではみ出すため」と理由まで書いて初めて意味が出る。

ふたつ目は、成功した検証しか書かなかったこと。ビルドが通ったことだけ誇らしげに書いて、本番URLもモバイル表示も確認していなかった。曖昧な合格は、未確認より質が悪いです。今は「確認したこと」と「確認していないこと」を必ず2つに分けて書きます。

みっつ目は、長い日記にしたこと。会話ログの要約を20行並べて満足していましたが、肝心の「次の一手」がなかった。次の人は、結局どこから手をつければいいか分からない。今はメモの最後を必ず「次のプロンプト」で締めます。

よっつ目は、秘密情報をそのまま貼ったこと。APIキーや社内URLをメモに残してヒヤッとしました。今は「環境変数STRIPE_SECRET_KEYが必要」のように名前だけ書くか、安全な場所へのリンクに留めています。

よくある質問

Q. メモはどこに置けばいいですか？ リポジトリ内のhandoffs/フォルダが手軽です。チームで共有するならGitHub IssueやSlack、Notionでも構いません。大事なのは場所より、次の人が必ず見る導線に置くことです。

Q. CLAUDE.mdに全部書けば引き継ぎは要らないのでは？ 混ぜると両方が腐ります。CLAUDE.mdは毎回守るルール、引き継ぎは今日だけの状態。今日の状態をCLAUDE.mdに書くと、明日には嘘になった規約が残ってAIを混乱させます。寿命で分けてください。

Q. 次のセッションでメモをどう読み込ませますか？ 新しいセッションの最初に、メモのパスを渡して「このメモとgit statusを照合してから残タスクを進めて」と指示します。claude --resumeで会話を再開する手もありますが、要点を1枚のメモにしておく方が、別の人や別AIにも渡せて応用が利きます。CLIの再開オプションはCLI referenceが一次情報です。

Q. どれくらい詳しく書けばいいですか？ 「次の作業者が会話履歴を読まずに最初の一手を打てる」を基準にしてください。それより細かいと書く手が止まり、粗いと再開できません。15行前後が目安です。

Q. 自動化するメリットは？ 書くハードルが下がって、実際に書くようになります。手作業だと「面倒だから今日はいいや」が続いて、結局いちばん必要な日に何も残りません。git statusを自動で埋めるだけでも、最初の数行を考えなくて済みます。

実際に試した結果

冒頭の「月曜に1時間溶かした」あと、僕は作業の区切りごとに30秒メモを更新する癖をつけました。効果は地味だけど確実で、翌朝に「どこまで見たっけ」を探す時間がほぼ消えました。

いちばん変わったのは、次のセッションに打つ最初のプロンプトです。前は長々と状況説明を書いていたのが、「このメモとgit statusを照合して、未確認だけ進めて」の一行で済むようになった。人間相手でも、別のAIセッション相手でも、同じ一行で渡せる。

賢いAIを使いこなすコツは、たぶん巨大なプロンプトを書くことではありません。頭の中にある「今どこにいるか」を、こまめに外へ逃がしておくこと。それだけで、一回限りの相談相手だったClaude Codeが、翌日の自分やチームに引き継げる道具に変わります。

型をまとめて手元に置きたい人は商品一覧に実務チェックリストがあります。チームでCLAUDE.md・権限・レビュー・引き継ぎ運用まで設計したいならClaude Code研修・導入相談が現実的です。まずは今日の作業の最後30秒、4項目のメモから始めてみてください。