アプリ開発の主体を別アカウントの Claude Code へ移管する（権限付け替え＋判断依頼の経路つき）

社内アプリ（Web アプリと GAS アプリ）の「不具合・要望フォームの処理と改修」を、自分の Claude Code から別アカウント（別 PC）の Claude Code へ引き継ぐときの型。引き継ぎ書を書くだけでなく、アクセス付与・判断の経路・カットオーバー条件まで一度に済ませ、相手側の人の操作を「起動文を1回貼る」と「OAuth 同意1回」に抑える。

前提

• 移管元 Claude Code は gh（移管元 GitHub アカウント）と、Google Drive をサービスアカウント（ドメイン全体委任）で操作できる認証を持つ
• 移管先は <相手メール>（Google Workspace 同一ドメイン）、GitHub <相手GitHubアカウント>
• 本番の秘密値・デプロイ権限・DB は移管元に残す（移管先には渡さない。渡す場合は鍵配布サーバー経由のみ）

1. 事実収集（1レスポンスで並列に）

• 各アプリのリポジトリ remote、本番デプロイの実態（ドキュメントと実運用が食い違うことが多い。memory や deploy 履歴から確認）
• 不具合・要望の蓄積先（DB テーブル名／スプレッドシート ID と列）、取得スクリプト名、done 化の方法
• 現在の collaborator / invitation（gh api repos/<o>/<r>/collaborators、.../invitations）
• remote が無いローカルリポ（GAS アプリに多い）は、この機会に private リポを作って全ブランチを push する

2. 引き継ぎ書を書く（秘密値ゼロ）

見出しは固定: 0 役割分担表 / 1 アクセス表（済・要の2列） / 2 秘密値の受け渡し経路 / 3・4 アプリごとの運用実態と罠 / 5 「フォーム0件」ループ（取得→分類→実装委譲→2段検証→本番反映→done 化→報告者 DM→日次通知） / 6 判断依頼プロトコル / 7 カットオーバー手順 / 8 関連 memory 名。 判断依頼プロトコルは「判断が要る条件（仕様の二択・本番データ削除/統合・課金・権限拡大・社外送信・2回連続失敗）」「本文の型（対象/背景/選択肢/推奨/保留中の扱い/期限）」「未回答時の扱い（削除・統合・課金は期限超過でも進めない）」の3点を必ず書く。

3. アクセス付与（全部コマンド。read-back 必須）

gh api -X PUT repos/<o>/<r>/collaborators/<相手GitHub> -f permission=push
gh api repos/<o>/<r>/invitations --jq '.[] | {id, invitee: .invitee.login, permissions, expired}'

Drive（スクリプト・シート）は Drive v3 permissions に {role:"writer", type:"user", emailAddress:"<相手メール>"} を POST（sendNotificationEmail=false）し、GET で read-back。GAS スクリプトファイルへの POST が 500 を返すことがあり、permissions を再取得してから1回再試行すると通る。 GitHub の招待は7日で失効するので、引き継ぎ書に「失効したら再招待を依頼」と書く。

4. 引き継ぎ書の置き場と送付

• 引き継ぎ書は移管対象の private リポの docs/ にコミット（公開リポに ID を置かない）。複数アプリなら正本1つ＋コピー
• 相手 PC が PC 間メッセージ（共有メールボックス方式）の名簿にあればそれで送る。無ければ起動文を1つ用意して人が1回貼る: 「<アプリ名> の移管を始めて。gh auth status で <相手GitHub> 認証を確認し、招待を gh api -X PATCH user/repository_invitations/<id> で受諾してから <リポ>/docs/<引き継ぎ書> の §1 から順に進めて。判断が要るものは §6 の [判断依頼] で送って」

5. 判断依頼を移管元の人に確実に届ける

相手の Claude が [判断依頼] 付きで送った文を、移管元 PC の「判断待ちキュー」（JSONL など）に自動登録し、朝夕のダイジェストとセッション冒頭 hook に出す。経路は2本用意する（PC 間メッセージ本線＋チャットチャンネル予備）。移管元の Claude は他作業より先に本人に聞いて返信する。

6. カットオーバー条件

相手が「不具合1件を end-to-end（実装→検証→本番反映→done 化→報告者 DM）」で完了した報告を合図に、移管元の取り込みジョブを止める。それまでは二重処理防止のため移管元を止めない。

7. 移管先を途中で変えるとき

招待の削除（DELETE .../invitations/<id>。既に受諾されていたら DELETE .../collaborators/<user>）、Drive 権限の削除、引き継ぎ書の差し替え、旧宛先への訂正メッセージ、判断待ちキューの本文更新、の5点を同じ順で行い、全部 read-back する。

落とし穴

• 実装 AI（サンドボックス）に git と権限操作を任せる場合、サンドボックス外（ホームディレクトリ、別フォルダの .git）は読み取り専用。git は作業ディレクトリ内に clone/bare 複製してから行い、ローカルの送受信ログは監督側で実行する
• 相手の PC 名・GitHub アカウント・Discord ID は推測せず名簿で確認する（同姓が複数いると DM 先を間違える）
• 「引き継ぎ書を送った」で終わらせず、アクセス付与の read-back と相手の初回報告までを完了条件にする