🤖 AI運用ルール

recover

最終更新 2026年07月14日 ／ 22_AI運用ルール/コマンド集/recover/recover.md

/recover — 壊れたセッションを引き継ぐコマンド

使う場面: あるセッションが壊れて操作不能になった時（英語のツール呼び出しXMLが画面に出て止まる / フリーズ / /handoff すら効かない / 英語が混ざりまくる）。
その壊れたセッションは諦めて閉じ、新しいセッションで /recover と打つだけ（「引き継ぎたい」等の自然文でも同じフローが自動発火する）。会話ログは消えてないので、そこから復旧できる。

/recover を打ったら、聞き返さず即 Step1（候補一覧）を実行する。 大串は番号を選ぶだけ。「引き継ぎたい」とメッセージを打つ手間もこのコマンドで省ける。

仕組み（なぜ復旧できるか・なぜ固まらないか）

壊れたセッション = モデルが壊れてるので /handoff も含め何も正常動作しない
  ↓ でも
会話の中身は ~/.claude/projects/.../{session}.jsonl に全部保存されてる(消えてない)
  ↓
新セッション(正常)で 候補一覧(0.2秒)→番号選択→ session_picker.py --handoff が
「作業Dir/発言の流れ/編集ファイル/コマンド/中断点」を機械抽出して引き継ぎ書を生成
  ↓（モデルは巨大jsonlを読まない=固まらない）
引き継ぎ書を提示して一旦停止 → 大串が「続きやって」と言ってから続行

実行フロー

2026-07-13 大串FB（設計刷新・最重要）: 旧フロー（「最後のメッセージを貼って」→ grep）は廃止。壊れたセッションに戻ってメッセージをコピーする往復がダルく、完全フリーズだとコピーすらできず詰む。新フロー＝大串は何も貼らず、候補一覧から番号を選ぶだけ。/recover を打たなくても、自然文「このセッション引き継ぎたい」でも同じフローが自動発火する（CLAUDE_global「セッション引き継ぎの自然文トリガー」）。

Step 1: 候補一覧を即出す（大串に何も貼らせない・聞き返さない）

脱線禁止（2026-07-13・8分ハング事故の対策）: このフローは他のどのルール（システム話→スタートカード/3点セット読み・git照合）より優先。候補を出す前に CLAUDE.md・スタートカード・リポ・git を読みにいくのは絶対禁止（モデルがハングして数分固まる）。「①候補を出す→②番号を待つ（応答を一旦終える）→③番号後に精読・git」を厳守。

起動したら、まず候補一覧スクリプトを実行する:

python3 "$(dirname "$(readlink ~/.claude/commands/recover.md)")/session_picker.py" 10

→ 直近セッションが 「時刻・プロジェクト・発言数・開始テーマ・最後の発言」付き で番号一覧される。この出力をそのまま大串に見せて、こう促す:

 直近のセッション一覧です。引き継ぎたいものを番号で選んでください。
（壊れたセッションを開き直す必要はありません・見た最後の発言でどれか分かります）
  • 今このセッション（引き継ぎ依頼を打っている本人）が上位に出る → --exclude "<今大串が言った文言の一部>" で除外するか、「[N]は今のセッションなので除外」と注記する。
  • 大串が最初から最後のメッセージや作業名を書いていたら、grep -rl "<文言>" ~/.claude/projects/*/*.jsonl で即特定してよい。でも基本は一覧提示が先（大串に手間をかけさせない）。

Step 2: 番号が選ばれたら、引き継ぎ書を「スクリプトで機械生成」

大串が番号を選んだら、その id（session_id）で引き継ぎ書を機械生成する:

python3 "$(dirname "$(readlink ~/.claude/commands/recover.md)")/session_picker.py" --handoff <session_id>

→ 作業ディレクトリ・最初の依頼・大串の発言の流れ・編集したファイル・実行した主要コマンド・中断点を抽出したコンパクトな引き継ぎ書が出る（0.1秒・巨大ログでも軽い）。この出力をそのまま大串に見せれば引き継ぎ完了。

jsonl本体を Read で精読しない（最重要・2026-07-14）: 巨大セッション(1.9MB級)を Read や --file でモデルに流し込むと 十数分ハングする（大串が15分待たされた実例）。必ず --handoff の機械生成で完結させる。深掘りが要る時も Read全読みでなく grep/--handoff に留める。

Step 3: 引き継ぎ書を大串に見せる（--handoff 出力がそのまま引き継ぎ書）

Step2 の --handoff 出力に、システム名/作業ディレクトリ・大串の発言の流れ・編集ファイル・実行コマンド・中断点が 既に機械抽出されている。これをそのまま大串に提示すれば引き継ぎ完了（要約で削らない・捏造しない）。
- 情報が足りない箇所だけ grep で該当jsonlの特定キーワードを拾う（Read での全読みはしない＝ハングの元）。

Step 4: 詳細な引き継ぎメッセージを生成（/handoff 級の濃さ・必須）

要約で済ませない。 ログから抽出できる情報を全部入れた「完全な引き継ぎ書」を作る。
別端末・別セッションに渡してもそのまま続行できるレベルにする（/handoff と同等の詳細度）。

ログを読んで、以下を漏れなく抽出して引き継ぎメッセージにまとめる:

項目 内容
システム/案件 何のシステムの作業か（TERASU CRM等）
作業ディレクトリ フルパス（/Users/oogushiyuuki/株式会社SCALE/hp/terasu/ 等）
本番URL / ver 本番URL・最新ver番号（分かれば）
やっていたこと タスクの目的・全体像
完了済み どこまで終わったか（編集したファイル・実装した機能を具体的に）
途中・残り 何が未完か・次にやるべきこと（具体的な手順で）
編集したファイル パス + 行番号 + 何を変えたか（ログから拾えるだけ全部）
デプロイ/バックアップ デプロイ実施有無・backup tar.gz のパス（あれば）
試したが駄目だったこと 同じ失敗を繰り返さないため
直前の指示/FB 大串が最後に言っていた指示・FB
注意点/退化リスク 触ってはいけない箇所・既知の罠
次の選択肢 続きとして取り得る具体的アクション

これを コードブロックで 出力（コピペしやすく）+ 状況サマリを添える:

 復旧しました。直前セッション（{番号}: {システム名} {時刻}）の完全引き継ぎ:

​```
【システム/案件】 TERASU CRM（本番 crm.terasu.scale-group.co.jp / v3.0.308）
【作業ディレクトリ】 /Users/oogushiyuuki/株式会社SCALE/hp/terasu/
【目的】 掲載許可フラグを案件本体に1つ持たせ、キックオフMTGと受注案件シートの両画面で共有・自動同期する

【完了済み】
- 現状調査: pm_projects.js の受注案件シート構造を把握（churned列の位置特定）
- kickoff.js の「その他」タブ構造を把握（KO_TABS）

【途中・残り（次にやる）】
1. 案件本体(projects)に publish_consent フラグを追加
2. キックオフMTG「その他」タブ一番上に掲載許可チェックを追加
3. 受注案件シートの「解約」列の左に掲載許可チェックボックス列を追加
4. 両者を publish_consent で同期（同じフラグを参照）
5. deploy（terasu-mgmt 直接prod・backup必須）+ ver記録

【編集予定/編集済みファイル】
- lib/pm_projects.js（受注案件シート・解約列付近）
- kickoff.js（その他タブ・KO_TABS）

【直前のFB/中断理由】 「また英語出ちゃってるよ」→ 言語混入でセッション中断

【注意点】
- TERASU CRM は直接prod OK だが tar.gz backup + node --check + 本番URL確認は必須
- ver報告は実測（sed+grepでchangelog bullet数）・推測+1禁止

【質問（未回答）】 キックオフのSlack報告の通知先 → 大串に確認要
​```

このまま続きを実行しますか？
  [a] 続きをやる（上記「残り」を実装から再開）
  [b] この引き継ぎメッセージをコピーして自分で確認/別端末で使う
  [c] 違うセッションだった → 一覧から別の番号を選び直す

上はフォーマット例。実際はログから読み取れた本物の内容で埋める。情報が無い項目は「（ログに記載なし）」と正直に書き、捏造しない。

Step 4.5: システム作業テーマは git で「実際の最新状態」を確認（必須・GitHub照合）

会話ログ(.jsonl)は"そのセッション時点"の記憶。別PC/時間が経っている場合、システムの実際の最新状態はGitHub側が正（他PCやこのPCの別セッションが先に進めていることがある）。ログの記憶を鵜呑みにして古い状態に戻さない。

引き継ぎ対象にシステム作業が含まれる場合、続き（Step 5 の a）を実行する前に必ず:

cd <該当リポ>           # 例: ~/dev/terasu-hp / ~/dev/scale-brain
git pull                # 別PCでも最新化（GitHubの履歴を取り込む）
git log --oneline -20   # 実際にどこまで進んでいるか
git status              # 未コミット差分の有無

→ ログの記憶と git の実態が食い違ったら git を正として続きを組み立てる（会話ログの思い込みで過去verに戻さない）。相談・思考テーマ（git に乗らない）は会話ログの引き継ぎが主。

Step 5: 引き継ぎ書を見せたら一旦停止し、大串の選択を待つ

勝手に続行しない（最重要・2026-07-14）: 引き継ぎ書を提示したら「続きをやりますか？」と聞いて応答を一旦終える。大串の明示なしに サーバー起動・デプロイ(git push)・長い読み込み等の続行作業を自動で始めない（勝手に走ると英語混入・死んだlocalhost案内で事故る）。引き継ぎ書内の localhost/http.server/preview URL は前セッションのもので既に死んでいるので今のプレビューとして出さない。

選択 動き
a 続きをやる git pull で最新照合 → 必要なサーバーを起動し直し → 短く1つずつ進める（引き継ぎ直後は英語が混ざりやすいので余計な読み込みをしない）
b コピーして使う 上の引き継ぎ書を pbcopy でクリップボードにコピー（別端末/別セッション用）
c 違うセッションだった Step1の候補一覧に戻り、別の番号を選び直す

b の時は pbcopy でクリップボードにコピーして「コピーしました」と一言。

振る舞いルール

  • 読み取り中心・いきなり変更しない: まず状況把握→提示→大串の承認を得てから作業再開
  • 言語ルール厳守: 復旧後も応答は100%日本語（CLAUDE_global「🇯🇵 言語ルール」）。壊れた原因が英語混入なら、新セッションでは特に注意
  • 長いセッションが壊れる主因: 復旧後の作業が長くなりそうなら、こまめに /handoff で区切るよう促す

そもそも壊さない予防

予防策 内容
こまめに /handoff 1タスク完了ごと・長くなる前に区切る（壊れる前に引き継ぐ）
巨大出力を避ける 巨大ファイルの全文catや大量ログ出力はモデル/アプリを壊す一因
英語混入が出たら早めに新セッション 混入はコンテキスト肥大のサイン。放置せず /handoff か新セッションへ

他メンバーが使えるようにする（導入手順）

/recover はメンバーのPCでも使える。手順（各メンバーのPCで1回）:

cd <scale-brainのclone先>        # 例: ~/dev/scale-brain
git pull                          # 最新の recover.md / session_picker.py を取得
bash 22_AI運用ルール/コマンド集/install.sh recover   # /recover を ~/.claude/commands/ に配置

→ これで /recover が使える。session_picker.py は recover.md と同じフォルダに git 配布されており、実行時は recover.md のリンク先を辿って 隣の session_picker.py を呼ぶので、clone先がどこでも・~/.claude/scripts のリンクが消えても動く（リンク切れ耐性あり）。

関連

  • 正常時の引き継ぎ: /handoff
  • セッションログ場所: ~/.claude/projects/{プロジェクト}/{session-id}.jsonl
  • メタ: meta.md