ログインできない GitHub アカウントに縛られた開発を、止めずに前へ進める

この指示書が解く問題

過去に自動化スクリプトやAIエージェントが作った GitHub アカウントで開発を続けていたら、こうなった:

• そのアカウントの Personal Access Token (PAT) に workflow スコープが無く、.github/workflows/*.yml を push すると拒否される
• スコープを足すには Web UI でのログインが必要
• しかしそのアカウントのパスワード・登録メールが誰も分からない（2段階認証にも阻まれる）

「アカウントを復旧する」方向に走ると、2FA・リカバリコード不明で行き止まりになりやすい。 この指示書は復旧を試みる前に、そもそも復旧が要らない経路が無いかを先に潰す手順を示す。

---

手順1: 復旧に走る前に、手元の別アカウントのスコープを確認する（最優先）

所要10秒。ここで解決する場合が非常に多い。

gh auth status

出力の Token scopes: を見る。'repo', 'workflow' の両方があれば、そのアカウントに置けば詰みは消える。

# そのアカウントがリポジトリに対して何ができるか
gh api repos/<OWNER>/<REPO> --jq '.permissions'
# → 404 = private でアクセス権すら無い / push:false = 読めるが書けない

判断基準

状況	取るべき手
手元アカウントに workflow スコープがある	そこへ置き換える（手順2へ）
対象リポが他の資産から独立している	置き換えの副作用が無い。迷わず移す
対象リポが他リポと密結合	移す範囲を切り分けてから判断

移してよいかの確認（重要）

移す前に、そのリポが他のリポジトリに依存していないかを必ず確認する。

grep -nE "OTHER_REPO_NAME|http|api|import|require" <主要スクリプト>

外部APIとローカルファイルだけで完結しているなら、そのリポだけ移しても他の資産は無傷。 依存が無いことを確認してから移す（確認せずに移すと、別の場所で参照が切れる）。

設計書を先に読む

そのリポの README / 引き継ぎドキュメントを読むと、元の設計では別の置き場所が指定されていたことがよくある。 今の置き場所が後のセッションの逸脱だった、というケースは珍しくない。 その場合、置き換えは「逸脱の修正」であって新たな逸脱ではない。

---

手順2: 置き換えを実行する

cd <ローカルの作業フォルダ>
printf '__pycache__/\n*.pyc\n.env\n.env.local\n' > .gitignore
git init -b main
git add -A
git commit -m "初期コミット"

gh repo create <自分のアカウント>/<REPO> --private
git remote add origin https://github.com/<自分のアカウント>/<REPO>.git
git push -u origin main

検証（push しただけで終わらせない）

# ワークフローファイルがリモートに存在するか
gh api repos/<OWNER>/<REPO>/contents/.github/workflows --jq '.[].path'

# Actions がワークフローとして認識したか（ファイルがあるだけでは動かない）
gh workflow list --repo <OWNER>/<REPO>
# → state が active になっていること

private リポで定期実行する前の実測確認

private リポは Actions の従量枠を消費し、予算ブロックに掛かると schedule が黙って全滅する。 「動くはず」で進めず、同じアカウントの既存 private リポで実際に回っているかを見る。

gh run list --repo <自分のアカウント>/<既存のprivateリポ> --limit 5
# → 直近に schedule / success があれば、その枠は生きている

止まっているならリポを public にする（public は Actions 無料無制限）。

---

手順3: どうしても元アカウントが必要な時 — 登録メールを特定する

置き換えでは解決しない場合のみ。登録メールは公開リポジトリのコミット author から割り出せる。

# アカウントの公開プロフィール（email は大抵 null なので当てにしない）
gh api users/<USERNAME> --jq '{login,type,name,email,created_at}'

# ★ 公開リポのコミット author から実際のメールを取る
gh api "repos/<USERNAME>/<PUBLIC_REPO>/commits?per_page=30" \
  --jq '.[].commit.author | "\(.name) <\(.email)>"' | sort -u

GitHub が配る匿名化アドレス（users.noreply を含む形）でなく実在のドメインのアドレスが出れば、それが登録メールである可能性が高い。

そのドメインを自社で管理している場合、管理コンソールからそのメールボックスにアクセスし、 GitHub のパスワードリセットを受け取る経路が開く。

ただし次のリスクを必ず事前に人へ提示してから着手すること:

• GitHub 側で 2FA が有効だと、パスワードリセットだけでは入れない（リカバリコードが必要）
• そのメールアカウントを他の自動化（クラウド、DB、CI）が使っている場合、パスワード変更がそれらを巻き込んで壊す

「入れるかもしれない」だけで他人のアカウントのパスワードを変更しない。影響範囲を洗ってから、人に判断させる。

---

手順4: 権限を渡す — Web ログインなしで招待を受諾する

元アカウントに書き込みだけさせたいなら、アカウント復旧は不要。招待すればいい。

招待する側

gh api -X PUT repos/<OWNER>/<REPO>/collaborators/<USERNAME> -f permission=admin
gh api repos/<OWNER>/<REPO>/invitations --jq '.[] | "id=\(.id) invitee=\(.invitee.login) perm=\(.permissions)"'

★ 招待される側（ここが最大の落とし穴）

招待の受諾は通常メールのリンクか Web UI で行う。 しかしログインできないアカウントは、それができない。 招待を送っただけでは詰みが解けない。

API で受諾できる。既存 PAT の repo スコープだけで通る:

# 自分宛の招待を一覧
gh api /user/repository_invitations

# 受諾（204 No Content なら成功）
gh api -X PATCH /user/repository_invitations/<INVITATION_ID>

# 確認
gh api repos/<OWNER>/<REPO> --jq '.full_name, .permissions'

招待は送信から7日で失効する。受諾手順を渡し忘れたまま放置すると振り出しに戻る。

---

手順5: スコープの誤解を解く — secrets 登録に workflow は要らない

ここを取り違えると、不要なトークン再発行を人に頼んでしまう。

操作	必要なもの
.github/workflows/*.yml を push	PAT に workflow スコープ
Actions secrets の登録	repo スコープ + リポジトリの admin 権限（workflow は不要）
Issue の作成・コメント	repo スコープ

つまり 「ワークフローを置く人」と「秘密鍵を入れる人」は別々でいい。 ワークフローはスコープを持つアカウントが push し、鍵は元アカウントが自分で入れる、という分担が成立する。

gh secret set <NAME> --repo <OWNER>/<REPO> --body '<VALUE>'
gh secret list --repo <OWNER>/<REPO>   # 登録の確認（値は読み出せない）

この分担の利点: 鍵の値が人間のチャットやメールを一切経由しない。 「鍵を取得した本人が、その場で自分で投入する」形にできるので、秘密情報の中継事故が消える。

---

手順6: 秘密情報を探す順序（人に聞き直す前に）

「キーをもう一度ください」と言う前に、必ずこの順で探す。

1. ローカルの環境ファイル

   find <プロジェクト群のルート> -maxdepth 4 -name ".env*" -print0 | xargs -0 grep -l -iE "<KEY_NAME>"
   

2. 過去のエージェント会話ログ（保存されている場合）を <KEY_NAME>\s*[=:]\s*['\"]?[A-Za-z0-9_\-]{15,} で検索
3. 本番環境の設定（vercel env ls 等）

見つかっても流用してはいけない場合がある

別プロダクト用に発行された鍵を使い回さない。 似た名前のプロジェクトの鍵が見つかっても、それが別アカウント・別サービス向けなら流用は事故になる （投稿先が混ざる、請求が混ざる、片方の失効で両方止まる）。 見つけた鍵の発行元と用途を確認してから使う。

GitHub secrets は読み出せない

一度登録した secrets は API でも UI でも値を取り出せない。 「別のリポに既に入っているはずだから、そこからコピーする」は原理的に不可能。 その場合は発行元のポータルで再生成するしかない。

---

手順7: どうしても人に頼む部分の渡し方

機械で代替できないのは次だけ:

• アカウントの新規作成（電話・メールの本人確認を伴う）
• 開発者登録・規約への同意
• 支払い、物理操作

依頼文はそれ単体で完結させる。過去の会話を探させない。

必ず入れる要素:

1. 背景（なぜこれが要るのか、これが最後の1ステップであること）
2. すでに完了していることの一覧 — 相手に重複作業をさせない。これが無いと同じものを二度作られる
3. 入力する値そのもの（プロフィール文、申請理由の英文、候補ID）— 相手に考えさせない。コピペで済む形にする
4. 既知の落とし穴を独立した見出しで警告
5. 成果物の渡し方（できれば手順4の分担にして、秘密情報を人に運ばせない）
6. チェックリスト

依頼文を共有ドキュメントにする時の注意

社内の共有ドライブに置くと、相手側のエージェントが直接読めるので転送作業がゼロになる。ただし:

• Markdown で流し込むと表と番号付きリストが崩れる（表の見出しが生の **項目** になる、番号が「1.」の繰り返しになる）。 プレーンテキストで整形する（■ ◆ ● □ と全角スペースのインデント）と崩れない
• 多くのドライブAPIは作成後の本文差し替えができない。修正＝作り直しになるので、URLを配る前に読み戻して検証する
• 既にURLを渡してしまった後で作り直す場合、古い方を削除せずタイトルを「【旧版・使用しないでください】…」に変えて残す。 相手が古いURLを踏んでも迷子にならない

---

つまずいた時の判断順

1. gh auth status でスコープを見たか？ → 手元のアカウントで解決しないか
2. その設計書に、本来の置き場所が書かれていないか？
3. 移す対象は他リポに依存していないか？
4. 権限を渡すだけで済まないか？（招待 + API受諾）
5. 秘密鍵は「本人が自分で入れる」形にできないか？
6. 人に頼むのは、本人確認・同意・支払いだけになっているか？

「アカウントを復旧する」は最後の手段。 先に上の5つを潰すと、大抵そこへ行き着く前に解決する。