# アプリ開発の主体を別アカウントの 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///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///collaborators/<相手GitHub> -f permission=push gh api repos///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/` で受諾してから <リポ>/docs/<引き継ぎ書> の §1 から順に進めて。判断が要るものは §6 の [判断依頼] で送って」 ## 5. 判断依頼を移管元の人に確実に届ける 相手の Claude が `[判断依頼]` 付きで送った文を、移管元 PC の「判断待ちキュー」（JSONL など）に自動登録し、朝夕のダイジェストとセッション冒頭 hook に出す。経路は2本用意する（PC 間メッセージ本線＋チャットチャンネル予備）。移管元の Claude は他作業より先に本人に聞いて返信する。 ## 6. カットオーバー条件 相手が「不具合1件を end-to-end（実装→検証→本番反映→done 化→報告者 DM）」で完了した報告を合図に、移管元の取り込みジョブを止める。それまでは二重処理防止のため移管元を止めない。 ## 7. 移管先を途中で変えるとき 招待の削除（`DELETE .../invitations/`。既に受諾されていたら `DELETE .../collaborators/`）、Drive 権限の削除、引き継ぎ書の差し替え、旧宛先への訂正メッセージ、判断待ちキューの本文更新、の5点を同じ順で行い、全部 read-back する。 ## 落とし穴 - 実装 AI（サンドボックス）に git と権限操作を任せる場合、サンドボックス外（ホームディレクトリ、別フォルダの `.git`）は読み取り専用。git は作業ディレクトリ内に clone/bare 複製してから行い、ローカルの送受信ログは監督側で実行する - 相手の PC 名・GitHub アカウント・Discord ID は推測せず名簿で確認する（同姓が複数いると DM 先を間違える） - 「引き継ぎ書を送った」で終わらせず、アクセス付与の read-back と相手の初回報告までを完了条件にする ---