同じプロジェクトを複数のClaude Codeセッションで動かしても、コンフリクト（サイレント上書き・デプロイ巻き込み）を起こさないための前提知識・設定方法・ルール・運用フロー・コピペ用プロンプト集
Claude Codeで同じプロジェクトフォルダを複数セッションで開いた場合、各セッションが持っているのは「自分専用のコピー」ではありません。全セッションが同じ1つの作業ツリー（＝ディスク上の同じファイル）を直接読み書きします。
2つのセッションの画面にまったく同じ差分の数字が出ていたら、それは「それぞれの変更」ではなく「共有している1つの作業ツリー」を両側から眺めているサインです。
| 状況 | 何が起きるか | 気づけるか |
|---|---|---|
| 別ブランチ・別worktreeで同じ箇所を編集してマージ | Gitコンフリクト（マーカーが出て手動解決） | ✅ 必ず気づける |
| 同じ作業ツリーを2セッションが同時編集 | 後から保存した方が勝つ「サイレント上書き」 | ❌ 警告ゼロ。消えたことに気づけない |
ここが最大の誤解ポイント。「Gitがあるからコンフリクトで守られる」はブランチを分けている場合だけの話です。コンフリクトはマージ時の仕組みなので、同一ツリー・同一ブランチでの同時編集はGitの保護の外側。セッションAが仕込んだ変更を、セッションBがそのファイルを書き直した瞬間に無言で消します。
同じ作業ツリー・同じブランチにいる限り、どちらのセッションから「PRを作成」を押してもまったく同じ差分のPRができるだけです。PRが分離してくれるものが何もありません。PRフローが活きるのは、後述の worktree 分離（セッションごとに別ブランチ）を導入してからです。
GitHub連携でデプロイするプロジェクトなら「コミットしたものだけが本番に出る」ですが、Vercel CLI直デプロイ（vercel --prod）のプロジェクトは違います。CLIはローカル作業ツリーの「今この瞬間の状態」をそのままアップロードします。
片方のセッションがデプロイすると、もう片方の「作業途中の中途半端な変更」も一緒に本番に出ます。コミットしているかどうかは関係ありません。だから「デプロイは全セッションの作業が合流してから、1回だけ」が鉄則になります。
この事故を構造的に消す恒久対策が「デプロイのGitHub連携化」——mainにマージされたコミットだけが本番に出る方式への切り替えです（手順と注意は 3-5）。
| A. 直列運用 | B. ファイル分担 | C. worktree分離 | |
|---|---|---|---|
| やり方 | 同時に動かすのは常に1セッションだけ | 同じフォルダで並行するが、触るファイルを完全に分ける | セッションごとに別ブランチ＋別フォルダ（worktree） |
| 設定の手間 | ゼロ | ゼロ（宣言だけ） | コマンド1本＋合流時にマージ |
| 並行度 | なし | 中 | 高 |
| 安全性 | 高（運用を守れば事故ゼロ） | 中（スコープ宣言が頼り） | 最高（構造的に上書き不可能） |
| 合流作業 | 不要 | 不要 | マージが必要（コンフリクトはここで顕在化＝解決できる） |
| 向いている場面 | 短いタスクの連続、共有ファイルを触る修正 | 新規ファイル中心の作業（新しい課題ページ追加など） | 大きい改修を長時間並行、実験的な変更 |
Q1. 2つのタスクが触るファイルは重なる？
→ 重なる（例：両方とも kadai-data.js を直す）── 迷わず A（直列）。片方が終わってコミットしてから次を走らせる。
Q2. 重ならない場合、作業は新規ファイル中心？
→ Yes（例：片方は新しい課題ページの新規作成、片方は既存ページの文言修正）── B（ファイル分担）で並行OK。ただし共有ファイルへの追記は「最後に片方だけが」やる。
Q3. 数時間〜数日単位の大きい改修を並行したい？
→ Yes ── C（worktree分離）。初期コストを払う価値がある。
実務のデフォルトは A か B。Cは「並行を日常化したくなったら」でいい。今日のタスクが30分で終わるならworktreeを作る時間の方がもったいない。
git worktree は、1つのリポジトリから複数の作業フォルダ（それぞれ別ブランチ）を同時にチェックアウトするGit標準機能です。たとえるなら「同じ原稿を、机を分けてコピーして書く」。それぞれの机（フォルダ）で自由に書き、最後に1つの原稿にマージ（合流）します。クローンし直すのと違って履歴・オブジェクトは共有されるので軽量。セッションBに専用フォルダを渡せば、物理的に同じファイルを触れなくなるため、サイレント上書きが構造的に不可能になります。
入力欄の「⎇ main ☑ ワークツリー」のチェック＝この機能のスイッチです。ONで作ったセッションは、プロジェクトの隔離コピー（worktree）＋専用ブランチで動きます。公式ドキュメントにも「Gitリポジトリでは、セッションごとに専用のworktreeで隔離され、コミットするまで他のセッションに影響しない」と明記されています。
公式ドキュメントの整理（どこで何がデフォルトか）：
| 環境 | worktree | 意味 |
|---|---|---|
| デスクトップアプリ | ✅ デフォルトで有効 | 新規セッションを作るたびに自動的にworktreeが作成される（チェックは最初からON。外すと同じフォルダを直接触る＝第1章の危険な状態） |
| claude.ai（Web／クラウド版） | ➖ そもそも使われない | worktreeという仕組み自体を使わず、専用VM＋自動割り当ての独自ブランチという別方式で隔離される（デフォルトで隔離済み） |
つまり「worktreeがデフォルト」なのはデスクトップアプリだけ。Web版は別方式（VM＋ブランチ）で、結果としてどちらも「新しく作るセッションは最初から隔離されている」状態です。
今回の2セッションが上書きリスクを抱えていたのは、このチェックがOFF（＝同じフォルダを直接共有）で走っていたからです。デスクトップの新規セッションは基本ONで始まるので、チェックを外さない限りこの状態には戻りません。確認したいときは、セッションに「git worktree list を実行して結果を教えて」と貼るだけ（自分でターミナルを開く必要はありません）。1行しか出なければ、全セッションが同じフォルダを共有しています。
基本はできません。公式ドキュメントに「既存セッションを後からworktreeに移す」機能の記載はなく、チェックはこれから作るセッションに効きます。すでに共有フォルダで作業した未コミット変更が、後から自動で隔離されることもありません。
実務的な移行手順はこの3手：
デスクトップアプリ派は「☑ ワークツリー」チェックだけでOK。ターミナルを使う人向けには claude --worktree 名前（短縮 -w）という開き方もありますが、使わなくて大丈夫です。
チェックボックスは無いですが、それは「worktreeとは別の方式で、最初から隔離されているから」です。各クラウドタスクはAnthropic管理の専用VM（仮想マシン）上で実行され、自動で独自のブランチが割り当てられます。公式ドキュメントの表現も「並行タスクは、複数のworktreeを管理することなく、それぞれ独立したセッション・ブランチで実行できる」——つまりworktreeを使わず、VM＋専用ブランチで隔離する方式です。ローカルの作業フォルダとは物理的に別＋ブランチも別なので、「同じフォルダの共有によるサイレント上書き」はそもそも起きません。
成果の受け取りはブランチをpush → PRを作成（またはteleportでローカルセッションに取り込み）。つまりクラウドセッションを本格的に使うなら、合流はGitHub経由が前提になり、次の3-5（デプロイのGitHub連携化）とセットにするのが自然です。
| 形態 | 隔離 | 合流のしかた |
|---|---|---|
| ローカル・チェックOFF（あえて外した場合） | ❌ なし（フォルダ共有） | 合流不要だが上書き事故リスク（＝第1章の状態） |
| ローカル・☑ ワークツリーON（デスクトップの既定） | ✅ worktree（隔離コピー＋専用ブランチ） | ローカルマージ or PR |
| クラウドセッション | ✅✅ 専用VM＋自動の専用ブランチ（worktreeは使わない別方式） | PR（GitHub経由） |
デスクトップアプリのセッションには実行モードがあり、並行運用の設計に直結します。
| モード | 実行場所 | 隔離方式 | 複数リポジトリ | 特徴・制約 |
|---|---|---|---|---|
| ローカルセッション | 自分のPC | worktree（デフォルトON） | ❌ 1つだけ | 低レイテンシ。統合ターミナル・ファイルペイン・@メンションのファイル参照が使える。ネイティブアプリのテストやブラウザ実機検証向き。PCを閉じるとセッションも止まる。ローカルのCPU/メモリを消費 |
| SSHセッション | リモートサーバー | 接続先のフォルダ次第 | ❌ 1つだけ | 自前のサーバー上で実行したい人向け。単一リポジトリ制約はローカルと同じ |
| WSLセッション | Windows上のLinux | worktree可 | ❌ 1つだけ | Windowsの本格開発向き。ただし統合ターミナル・ファイルペインが使えない |
| クラウド（Remote）セッション | Anthropic管理VM | VM＋自動の専用ブランチ | ✅ 複数可（唯一） | PCを閉じても動き続ける。長時間ジョブ・放置したい作業向き。成果はPRで受け取る |
ポイント：「複数リポジトリを選べない」のはデスクトップアプリの制約ではなく、ローカル／SSH／WSLセッション共通の制約。複数リポジトリを1セッションで横断したいときだけ、クラウド（Remote）セッション一択になります。
並行運用での使い分け（実務指針）：
ローカル×クラウド並行の注意：クラウドセッションはGitHub上のリポジトリを元に動くため、ローカルの未コミット・未pushの変更はクラウドからは見えません。クラウドに仕事を投げる前に「コミット→push」で最新をGitHubに上げておくこと（鉄則3の区切りコミットがここでも効く）。
基本は3-2の「☑ ワークツリー」チェックで足ります。この節は、チェックを使わずにフォルダの場所やブランチ名を自分で決めたいときの方法。ターミナルは不要——下のプロンプトをセッションに貼れば、コマンドはAIが実行します。
並行作業用のworktree（隔離された作業コピー）を作ってください。 【1】git worktree add で、プロジェクトの隣に専用ブランチ付きの作業フォルダを作る。 フォルダ名は「＜プロジェクト名＞-sub」、ブランチ名は「work/＜作業内容＞」。 作る前に、フォルダ名とブランチ名を私に1回確認して。 【2】作ったフォルダのフルパスとブランチ名を報告して。 私はそのフォルダを新しいセッションで開いて作業する。 【3】マージはまだしない。私が「合流して」と言ったら： 元のフォルダで git merge → コンフリクトが出たら一緒に解決 → git worktree remove で片付け、まで面倒を見て。
参考：AIが実行するコマンドの中身（読める人向け）：
# ① メインフォルダで実行：隣に専用ブランチ付きの作業コピーを作る
cd /Users/hika/Documents/Cursor_メインMAC/奇跡を起こす
git worktree add "../奇跡を起こす-sub" -b work/sub-task
# ② セッションBは「奇跡を起こす-sub」フォルダを開いて作業する
# （メインのセッションAは今まで通り元のフォルダで作業）
# ③ セッションBの作業が終わったら、sub側のフォルダに移動してコミット
# （セッションBに指示すればやってくれる）
cd "/Users/hika/Documents/Cursor_メインMAC/奇跡を起こす-sub"
git add -A && git commit -m "サブタスク完了"
# ④ メインフォルダに戻ってマージ（合流）
cd /Users/hika/Documents/Cursor_メインMAC/奇跡を起こす
git merge work/sub-task
# → 同じ箇所を触っていたらここでコンフリクトが「目に見える形で」出る
# → 解決してコミットすれば合流完了
# ⑤ 後片付け
git worktree remove "../奇跡を起こす-sub"
git branch -d work/sub-task注意①：同じブランチを2つのworktreeでチェックアウトすることはGitが拒否します（これが安全装置）。worktreeを作るときは必ず -b 新ブランチ名 を付ける。
注意②：.gitignore されているファイル（.env、school/.vercel/ 等）はworktreeにコピーされません。sub側でローカルサーバやデプロイが必要なら別途配置が要る——が、そもそもデプロイはメインフォルダからだけ行うルールなので通常は不要。
セッションBのブランチ（work/sub-task）をpushしてPRを作れば、mainに入る前に差分レビューができる＋マージ時のコンフリクト検出もGitHub上で機能します。ローカルマージ（3-3の④）とPRマージ、どちらでもOK。なお「この作業は隔離worktreeでやって」とセッションに頼めば、AI側でworktreeを作って作業し、終了時にマージ確認まで持ってくることもできます。
1-4の「デプロイ巻き込み」を構造的に消すのがこれ。VercelプロジェクトをGitHubリポジトリに接続すると、デプロイの起点が「ローカル作業ツリーの現状」から「mainにマージされたコミット」に変わります。
切り替えると何が良くなるか：
vercel --prod を手で打つ作業自体が消えるこのプロジェクト（school）での切り替え手順：
school プロジェクト → Settings → Git → Connect Git Repository → GitHubの kiseki-uniko-school を選択school に設定（リポジトリのルートではなく school/ 配下が公開対象のため。ここを忘れると404になる）注意①：切り替えた瞬間から「mainへのpush＝即・本番デプロイ」になる。main直コミットの運用のままだと、中途半端なコミットもそのまま本番に出る。ブランチ／PR経由でmainに入れる運用とセットで切り替えること。
注意②：接続操作はVercelダッシュボードでの手動作業（AIは代行しない）。チームの認証ウォール設定（Require Log In＝OFF）と安定URLは切り替え後もそのまま。
同じファイルを2つのセッションが同時に触った時点で負け。タスクを振る前に「触るファイルが重ならないか」を必ず確認する。重なるなら直列。
どのタスクでも触りがちなファイル（データ定義・ナビ・設定など）を事前に洗い出す。並行作業ではホットスポットへの追記は「最後に片方のセッションだけが」行う。
コミット済みの変更はGitから必ず復元できる。上書き事故で本当に失われるのは未コミット分だけ。作業の区切り（タスク1個完了）ごとにコミットして「戻れる地点」を作る。
各セッションに「指示があるまで commit / push / deploy しない」とプロンプトで縛る。複数セッションが勝手にコミットすると、区切りが崩れて何がどの作業か追えなくなる。
CLI直デプロイは作業ツリーの現状を丸ごと上げる。全セッションの作業が終わり、コミットで区切ってから、1つのセッションが1回だけ実行する。恒久対策はデプロイのGitHub連携化（→ 3-5）——mainにマージされたコミットだけが本番に出る方式に切り替えれば、このルール自体が不要になる。
各セッションのタスク開始時に「触る予定のファイル」を宣言させ、終了時に「実際に触ったファイル」を報告させる。宣言外のファイルに触る必要が出たら、作業を止めて報告させる。
同じフォルダでの並行はB（ファイル分担）が上限。それ以上に同時進行したい・不安が残るなら、迷わずworktreeでフォルダごと分ける。
生成スクリプトで作られるファイルは、両セッションがそれぞれ再生成すると必ず衝突する。各セッションの締めではやらず、合流したメインセッションがデプロイ前に1回だけ実行する。
やりたいことを「触るファイルが重ならない単位」に分ける。重なるものは同じセッションにまとめるか、直列にする。
プロンプト①を貼ってタスクを依頼。セッションが「触る予定ファイル」を宣言してから作業に入る。宣言が重なっていたらこの時点で気づける。
待機側のセッションにプロンプト⑤を貼ると、mainに新コミットが入った瞬間に自動検知して報告してくれる。人間が画面を見張る必要がなくなる。
プロンプト②で「ファイル一覧報告 → 担当ファイルだけをコミット → push → デプロイ禁止」の順に締めさせる。これで「戻れる地点」が確定する。自動生成ファイルの再生成はここではやらない（合流時に1回）。
全セッションのコミットが揃ったら、プロンプト③で「状態確認 → 自動生成ファイルの再生成 → 実機検証 → デプロイ → 本番確認」。デプロイはここが唯一の実行ポイント。未コミットの取り残しがあればデプロイは止まる。
サブのブランチをmainにマージし、コンフリクトが出たらここで解決。合図は毎回「mainにマージして」の一言——マージは自動では起きない（言うまで各ブランチは分かれたまま＝安全機能）。
マージ完了後の worktree 削除（git worktree remove）まで「mainにマージして」の一言にセットで含める運用（2026-07-20 ルール化＝CLAUDE.md に固定済み。「消して」を毎回言い足す必要はない。ただし自分がいま動いている worktree は消さない＝別セッション終了後にメイン側から掃除）。
そのままセッションに貼って使う。＜＞の部分だけ書き換える。コマンドを自分で打つ場面はゼロ——全部AIに貼って任せる。
このタスクを始める前に、まず以下を宣言してください。 【担当スコープ】 - このタスクで編集・新規作成する予定のファイルを全て列挙する - 共有ファイル（kadai-data.js / nav.js / SKILL.md・CLAUDE.md等の正典ドキュメント）に触る場合は明記する 【禁止事項】 - 宣言したファイル以外は編集しない。必要になったら作業を止めて報告する - git commit / push / デプロイ（vercel --prod）は指示があるまで実行しない - Skill・CLAUDE.md等の正典ドキュメントへの追記はしない。学びはテキストで報告し、合流後にメインセッションが追記する - 今、別のセッションも同じフォルダで作業している。同じ作業ツリーを共有している前提で動くこと 宣言が終わったら作業を開始してください。 タスク内容：＜ここにタスクを書く＞
作業が終わったら、締めとして次を順番にやってください。 【1】今回のタスクで編集・新規作成したファイルの一覧を報告 （特に共有ファイル kadai-data.js / nav.js / SKILL.md等の正典 に触ったかを明記） 【2】【1】で報告した自分の担当ファイルだけを git add ＜担当ファイルを列挙＞ でステージ → コミット → push でチェックポイントを作成。 git add -A は使わないこと（別セッションの作業途中の変更を巻き込むため）。 git status に担当外の変更が見えても、ステージせずに報告だけする。 コミットメッセージは作業内容が分かるように書く。 【3】自動生成ファイル（_kadai.js）の再生成はここではやらないこと。 合流時にメインセッションが1回だけ実行する運用です。 【4】デプロイ（vercel --prod）も実行しないこと。 別セッションの作業と合流したあと、最後に1回だけ実行する運用です。 コミットのハッシュとファイル一覧を報告して終了してください。
直列運用（パターンA）の例外：他に作業中のセッションが1つもないことが確実なら、【2】は git add -A で作業ツリー全体をまとめてチェックポイントにしてよい（巻き込む相手がいないため。むしろ取り残しが出ない分安全）。並行中は必ず担当ファイル列挙方式で。
全セッションの作業がコミット済みです。合流確認とデプロイをお願いします。 【1】git log --oneline -5 と git status で最新コミットと作業ツリーの状態を確認 【2】未コミットの変更が残っていたら、内容を報告してデプロイせずに停止し、指示を待つこと （勝手に消したりコミットしたりしない。CLI直デプロイは未コミットの変更も そのまま本番に上げるため、ここが最後の安全ゲートです） 【3】課題ページの更新が含まれる場合は node banner/gen-kadai-knowledge.mjs で _kadai.js を再生成してコミット 【4】主要ページをローカルで実機検証（ローカルサーバを起動して表示・ナビ・今回変えた箇所を確認） 【5】問題なければデプロイを1回だけ実行（このプロジェクトでは school/ から vercel --prod） 【6】デプロイ後、本番の安定URLで今回の変更ページを開いて表示確認 検証で問題が見つかったらデプロイせずに報告してください。
ファイルが別セッションに上書きされた可能性があります。復旧調査をお願いします。
対象ファイル：＜ファイルパス＞
消えたかもしれない変更：＜覚えている範囲で内容を書く＞
【1】git status と git diff HEAD -- ＜ファイルパス＞ で現在の状態を確認
【2】git log --oneline -10 -- ＜ファイルパス＞ でこのファイルの直近コミット履歴を確認
【3】直近コミットの内容と今の内容を照合して、消えた変更がないか調べる
【4】復元が必要なら「どの時点に・どの部分を」戻すか選択肢を提示すること。
勝手に git checkout / restore で上書きしない（今の状態も消える可能性があるため）
別セッションが作業中で、終わるとmainにコミットが入ります。 mainに新しいコミットが入ったら検知して報告するバックグラウンド監視を仕掛けてください。 検知したら： 【1】新しいコミットの内容（ハッシュ・メッセージ・変更ファイル）を確認して報告 【2】作業ツリーに未コミットの取り残しがないかも確認 【3】その報告だけして、次の指示を待つこと 監視中、このセッションは共有ファイルに一切触らないでください。 ※これは同一フォルダ運用（パターンA/B）用です。worktree運用（パターンC）では サブセッションのコミットはmainではなくサブのブランチ（例：work/sub-task）に 入るので、そちらを監視対象に読み替えてください。
100%戻せます。プロンプト④を貼ればAIが調査・復元まで代行します。参考として、AIが実行するコマンドの中身：
# このファイルの履歴を見る
git log --oneline -10 -- path/to/file
# 特定コミット時点の内容を確認（今のファイルは触らない）
git show コミットハッシュ:path/to/file
# 丸ごとその時点に戻す場合
git checkout コミットハッシュ -- path/to/file
# ※部分的に戻したい場合は git show の内容から必要な箇所だけ手動で移す一度も git add していない変更は、Gitからは戻せません。これが「区切りごとにコミット」を鉄則にする理由。ただし諦める前に3つ確認：
git add していた内容なら、git fsck --lost-found で dangling blob として中身が残っている場合がある（AIに「git fsckで消えた変更を探して」と頼めばよい）# 直前の正常なコミットに作業ツリーを合わせてから再デプロイ…はNG
# （もう片方のセッションの未コミット作業が消えるため）
# 正しい手順：
# ① まず両セッションの作業を止めて、未コミット分をコミットで確保
# ② その上で正常な状態を作って（必要ならrevert）、デプロイし直す
# ③ Vercelのダッシュボードから「前のデプロイにロールバック」も使える
# （Deployments → 正常だったデプロイ → Promote to Production）「奇跡を起こす（#ユニコスクール）」プロジェクトで、複数のタスクが同時に触りがちなファイル一覧。並行作業の前にこの表と照合する。
| ファイル | 役割 | 危険度 | 運用ルール |
|---|---|---|---|
school/kadai-data.js |
課題メタデータの単一の真実（一覧・並び替えの元） | 🔴 最高 | 課題を足す作業は必ずここに触る。同時に触るの禁止・追記は片方だけ |
school/nav.js |
全ページ共通サイドバーのNAV配列 | 🔴 最高 | ページ追加・改名で必ず触る。kadai-data.jsとセットで同じセッションが担当 |
.claude/skills/*/SKILL.md |
正典ドキュメント（各セッションがタスクの締めに学びを追記しがち） | 🔴 最高 | タスク内容を問わず全セッションが触り得る最頻出の衝突源。並行中は追記を保留し、合流後にメインセッションが一括追記 |
school-rinen-report.html |
理念・憲法の可視化正典（FBで原則が増えたら同期更新） | 🟡 中 | 原則の追記は合流後にメインセッションが1回だけ行う（複数セッションで同時に追記しない） |
school/api/_kadai.js |
AI用課題ナレッジ（自動生成・手編集禁止） | 🟡 中 | 合流するメインセッションが node banner/gen-kadai-knowledge.mjs をデプロイ前に1回だけ実行 |
school/api/_cs-ai.js |
AI共通モジュール（system＋askClaude。ask.js・cs.js共用） | 🟡 中 | CS系とAI応答系のタスクを並行させる場合はどちらか一方のセッションだけが触る（触るなら宣言必須） |
school/index.html |
TOP（全体ロードマップ・各弾への導線） | 🟡 中 | 新課題の導線追加で触ることがある。触るなら宣言必須 |
school/kadai-list.html |
課題一覧ページ | 🟡 中 | 基本はkadai-data.jsが真実なので触らないことが多いが、表示仕様変更時は宣言 |
school/dan1/〜, api01/ 等の各課題ページ |
課題ページ本体（弾ごとに独立） | 🟢 低 | 別々の弾なら並行安全。同じ弾を2セッションで触るのは禁止 |
新規ディレクトリ（新しい課題ページ） |
新設課題 | 🟢 最低 | 新規ファイルは衝突しない。並行作業に最適な担当単位 |
① git 側が持つもの＝「変更の指示書（マイグレーションファイル）」
Prisma / Rails / Django / Flyway など、どのツールも考え方は同じ。スキーマ変更を1つずつ番号付きファイルにして git にコミットする。
migrations/
20260701_create_users.sql ← usersテーブルを作れ
20260710_add_email_column.sql ← emailカラムを足せ
20260718_create_orders.sql ← ordersテーブルを作れこれはただのコードなので、GitHubで差分レビューも履歴追跡もできる。ここまでが「GitHubの世界」。
② DB 側が持つもの＝「適用済みの記録」（ここが“GitHubの外”）
DBの中に、ツールが自動で作る管理テーブルがあり、「どのマイグレーションを・いつ実行したか」が1行ずつ記録される。名前が違うだけで役割は全ツール共通。
| ツール | DB内の管理テーブル名 |
|---|---|
| Rails | schema_migrations |
| Prisma | _prisma_migrations |
| Django | django_migrations |
| Flyway | flyway_schema_history |
migrate コマンドを打つと、ツールはgit側のファイル一覧とDB側の管理テーブルを突き合わせて、「まだ適用されていない分だけ」を順番に実行する。だから同じコマンドを何度打っても二重適用されない。
git revert してもDBは1ミリも戻らない。戻るのは指示書だけ。DBを戻すには「逆向きの指示書（down migration）」を実行するか、バックアップから復元するしかない。
さらに、指示書でも守れない領域が2つある：
・カラム削除・データ変換は不可逆。DROP COLUMN した瞬間、そこにあったデータは down migration を書いても復活しない。守れるのはDB側のバックアップ（スナップショット／ポイントインタイムリカバリ）だけ。
・データ（行）の変更履歴はマイグレーションの守備範囲外。マイグレーションが記録するのは「箱の形（スキーマ）の変更」まで。「誰がいつこのレコードを変えたか」まで追いたい場合は、監査ログテーブルや CDC（変更データキャプチャ）という別の仕組みを足す。
git のブランチは全員共通だが、本番DB・ステージングDB・ローカルDBはそれぞれ自分の管理テーブルを持ち、進み具合がバラバラ。
「コードは最新なのにDBが古い（またはその逆）」というズレが事故の典型。だから普通はデプロイパイプラインの中で自動的に migrate を実行して、コードとDBを常にセットで進める。鉄則5の「GitHub連携デプロイ＝mainに入ったものだけが本番へ」のDB版。
鉄則7の worktree 分離はフォルダを分けるだけ。DBは1個のまま全セッションから共有される。ファイルは分離できてもDBは分離できない。
・並行運用では「スキーマを触るのは1セッションだけ・他は読み取りのみ」が原則（鉄則2の共有ファイルリストに、DBを最初から載せておくイメージ）。
・これを本気で解決したのが Neon や PlanetScale の「DBブランチ」機能。git のブランチと同じようにDB自体を枝分かれさせ、マージで本番に反映する＝「GitHubの考え方をDBまで拡張した」サービス。
このプロジェクトにはRDBがなく、意図的にマイグレーション問題を回避した設計。Vercel Blob は「1投稿=1ファイル・不変」なのでスキーマ変更も上書き競合も起きない。
受講者の進捗は localStorage の doneKey が担っている。doneKey の名前を変えると全員の進捗が消える＝これがこのサイトにおける「マイグレーション事故」に相当。kadai-data.js を単一の真実にしているのはその予防。
GitHub Issue（プラン置き場・やることリスト）
│ 「Issue #12 を実装して」とセッションに渡す
▼
クラウドセッション（専用ブランチ claude/〜 で実装・コミット・push）
│ 終わったら「PRを作成」
▼
Pull Request（差分レビュー・修正依頼はここで）
│ 人間がマージボタンを押す
▼
main に合流 ──「Fixes #12」効果で Issue が自動クローズ
│
▼（デプロイをGitHub連携化していれば → 3-5）
本番に自動反映・リポジトリを claude.ai/code に接続しておく（リポ作成→接続→許可モード「自動」。手順は 3-2 の課題と同じ）。
・Issue は GitHub 標準機能なので追加の設定は不要。リポジトリの「Issues」タブがそのままプラン置き場になる。
・クラウドセッションは接続リポに対して Issue の読み書き権限を持っているので、Issueの作成も読み取りもAIに任せられる。
クラウドセッションを開いて、これを貼る：
これから「＜やりたいこと＞」を作りたい。 まず実装プランを次の構成でまとめて： - 目的（1〜2行） - やることリスト（チェックボックス形式） - 触る予定のファイル - 受け入れ条件（何ができたら完了か） まとめたら gh issue create でこのリポジトリのIssueにして、Issue番号とURLを教えて。 実装はまだ始めないで。
プランと実装を分ける効果：プランがIssueとして残るので、①実装セッションを何度作り直しても迷子にならない ②「何を頼んだか」を後から人間が読める ③複数プランを積んでおいて好きな順に消化できる。5章の「スコープ宣言」を、セッションの外（GitHub）に永続化した形。
新しいクラウドセッションを立てて、これを貼る：
gh issue view ＜Issue番号＞ でこのリポジトリのIssueを読んで、 書かれているプラン通りに実装して。ルール： - 作業はこのセッションのブランチ上で行う（mainには直接触らない） - 区切り（やることリスト1項目完了）ごとにコミットして push - プランに無い変更が必要になったら、作業を止めて報告 - 全部終わったらPRを作成。PR本文の先頭に「Fixes #＜Issue番号＞」と 変更サマリーを書く - mainへのマージはしない（マージは私がGitHubで行う）
push＝保存、と覚える。クラウドのVMは使い捨てで、pushしていない変更はセッションと一緒に消え得る。鉄則3（区切りごとにコミット）のクラウド版は「区切りごとにコミット＋push」。
・GitHubのPR画面で差分（Files changed）を確認する。
・直したい所があれば、同じセッションに「PRのこの部分、〜に直して」と続ける。直してpushすれば同じPRに自動で追加される（ブランチにコミットが積まれる＝PRは常にブランチの最新を映す）。
・OKならMerge ボタンは人間が押す。本文に「Fixes #N」があるので、マージと同時にIssueが自動でクローズされる（GitHub標準機能）。
・デプロイをGitHub連携化（3-5）していれば、mainマージ＝本番反映。鉄則4・5の「マージ＝デプロイ級の操作は明示的に人間が」の形がここで完成する。
1 Issue = 1 セッション = 1 ブランチ = 1 PR。この対応を崩さなければ、Issueを3つ積んで3セッション同時に走らせても、それぞれ別ブランチ・別VMなので上書き事故は起きない。
ただし同じファイルを触るIssue同士は、PRマージの段階でコンフリクトになる（＝1-2の表の「✅ 必ず気づける」側なので事故ではない）。先に片方をマージし、もう片方のセッションに「mainの最新を取り込んで、コンフリクトを解消してpushして」と頼めばPRが更新される。鉄則1「触るファイルが重なるなら直列」はIssueの切り方にもそのまま適用される。
ローカルのClaude Codeで一度 /install-github-app を実行してGitHub Actions連携を入れると、Issueのコメント欄に「@claude このIssueを実装して」と書くだけで、Claudeが実装してPRを作ってくれるようになる（クラウドセッションを開く必要すらない）。
スマホのGitHubアプリからIssueを書いて@claudeにメンション→帰宅したらPRができている、という運用が可能。まずは 10-3〜10-5 の手動ルートで型を掴んでから移行するのがおすすめ。
VS Codeのソース管理グラフ相当を、説明付きの白ベースHTMLでいつでも出せる。コマンドは覚えない——言うだけ。
| 言うだけワード | GitHubで言うと | 何が起きる |
|---|---|---|
| 「ワークツリー図を更新して」 | グラフ表示 | AIがgitから現状を集めて admin/worktree-graph.html を再生成→ブラウザで開く |
| 「合流して」（メインフォルダのセッションに） | PRをマージ | 全 worktree-* ブランチを main に集める。ぶつかりはAIが解消して報告→ _kadai.js 再生成 |
| 「合流してデプロイして」 | マージ→リリース | ↑＋本番デプロイ1回＋済んだ机の掃除を提案 |
| 「最新を取り込んで」（各ワークツリーのセッションに） | Pull | mainの最新を自分の机に引き込む（任意・長期並走時だけ） |
| 図の要素 | 意味 |
|---|---|
| 🟣 紫レーン（main） | 本番の正史。メインフォルダがチェックアウト中 |
| 🔵 青い枝（worktree-◯◯） | 各セッションの机。枝の長さ＝未合流コミット数（バナーの「+N」） |
| 🟢 緑の点線 | 「合流して」で起きる未来のマージルート |
| 🖥 バッジ | その机を使っているセッション |
置き場所は admin/worktree-graph.html（ローカル専用＝デプロイされない）。開いた時点のスナップショットなので、履歴が進んだら再度「図を更新して」。常時リアルタイムで見たい時だけVS Codeのソース管理グラフを併用。
ワークツリー図を更新して。 やること： 1. git worktree list ／ git branch -a ／ git log --all（直近15件・parents付き）／ main と各 worktree-* ブランチの ahead/behind を収集 2. admin/worktree-graph.html を再生成（白ベース #f8f9fc・文字18px・アクセント #4f46e5→#0ea5e9）： ・上部バナー＝合流待ちコミット数「+N」／机の数 ・机の一覧テーブル（場所・ブランチ・先頭コミット・役割・🖥使用中セッション） ・コミットグラフSVG（紫=main、青=worktree枝、緑点線=「合流して」の未来ルート、上が新しい） ・読み方の凡例 3. 完成したら file:// のフルパスでブラウザで開く