# ログインできない GitHub アカウントに縛られた開発を、止めずに前へ進める ## この指示書が解く問題 過去に自動化スクリプトやAIエージェントが作った GitHub アカウントで開発を続けていたら、こうなった: - そのアカウントの Personal Access Token (PAT) に `workflow` スコープが無く、`.github/workflows/*.yml` を push すると拒否される - スコープを足すには Web UI でのログインが必要 - **しかしそのアカウントのパスワード・登録メールが誰も分からない**（2段階認証にも阻まれる） 「アカウントを復旧する」方向に走ると、2FA・リカバリコード不明で行き止まりになりやすい。 この指示書は**復旧を試みる前に、そもそも復旧が要らない経路が無いかを先に潰す**手順を示す。 --- ## 手順1: 復旧に走る前に、手元の別アカウントのスコープを確認する（最優先） **所要10秒。ここで解決する場合が非常に多い。** ```bash gh auth status ``` 出力の `Token scopes:` を見る。`'repo', 'workflow'` の両方があれば、**そのアカウントに置けば詰みは消える**。 ```bash # そのアカウントがリポジトリに対して何ができるか gh api repos// --jq '.permissions' # → 404 = private でアクセス権すら無い / push:false = 読めるが書けない ``` ### 判断基準 | 状況 | 取るべき手 | |---|---| | 手元アカウントに `workflow` スコープがある | **そこへ置き換える**（手順2へ） | | 対象リポが他の資産から独立している | 置き換えの副作用が無い。迷わず移す | | 対象リポが他リポと密結合 | 移す範囲を切り分けてから判断 | ### 移してよいかの確認（重要） 移す前に、そのリポが**他のリポジトリに依存していないか**を必ず確認する。 ```bash grep -nE "OTHER_REPO_NAME|http|api|import|require" <主要スクリプト> ``` 外部APIとローカルファイルだけで完結しているなら、そのリポだけ移しても他の資産は無傷。 **依存が無いことを確認してから移す**（確認せずに移すと、別の場所で参照が切れる）。 ### 設計書を先に読む そのリポの `README` / 引き継ぎドキュメントを読むと、**元の設計では別の置き場所が指定されていた**ことがよくある。 今の置き場所が後のセッションの逸脱だった、というケースは珍しくない。 その場合、置き換えは「逸脱の修正」であって新たな逸脱ではない。 --- ## 手順2: 置き換えを実行する ```bash 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 <自分のアカウント>/ --private git remote add origin https://github.com/<自分のアカウント>/.git git push -u origin main ``` ### 検証（push しただけで終わらせない） ```bash # ワークフローファイルがリモートに存在するか gh api repos///contents/.github/workflows --jq '.[].path' # Actions がワークフローとして認識したか（ファイルがあるだけでは動かない） gh workflow list --repo / # → state が active になっていること ``` ### private リポで定期実行する前の実測確認 private リポは Actions の従量枠を消費し、**予算ブロックに掛かると schedule が黙って全滅する**。 「動くはず」で進めず、同じアカウントの既存 private リポで実際に回っているかを見る。 ```bash gh run list --repo <自分のアカウント>/<既存のprivateリポ> --limit 5 # → 直近に schedule / success があれば、その枠は生きている ``` 止まっているならリポを public にする（public は Actions 無料無制限）。 --- ## 手順3: どうしても元アカウントが必要な時 — 登録メールを特定する 置き換えでは解決しない場合のみ。**登録メールは公開リポジトリのコミット author から割り出せる。** ```bash # アカウントの公開プロフィール（email は大抵 null なので当てにしない） gh api users/ --jq '{login,type,name,email,created_at}' # ★ 公開リポのコミット author から実際のメールを取る gh api "repos///commits?per_page=30" \ --jq '.[].commit.author | "\(.name) <\(.email)>"' | sort -u ``` GitHub が配る匿名化アドレス（`users.noreply` を含む形）でなく実在のドメインのアドレスが出れば、それが登録メールである可能性が高い。 **そのドメインを自社で管理している場合**、管理コンソールからそのメールボックスにアクセスし、 GitHub のパスワードリセットを受け取る経路が開く。 ただし次のリスクを**必ず事前に人へ提示してから**着手すること: - GitHub 側で 2FA が有効だと、パスワードリセットだけでは入れない（リカバリコードが必要） - そのメールアカウントを他の自動化（クラウド、DB、CI）が使っている場合、パスワード変更が**それらを巻き込んで壊す** 「入れるかもしれない」だけで他人のアカウントのパスワードを変更しない。影響範囲を洗ってから、人に判断させる。 --- ## 手順4: 権限を渡す — Web ログインなしで招待を受諾する 元アカウントに**書き込みだけさせたい**なら、アカウント復旧は不要。招待すればいい。 ### 招待する側 ```bash gh api -X PUT repos///collaborators/ -f permission=admin gh api repos///invitations --jq '.[] | "id=\(.id) invitee=\(.invitee.login) perm=\(.permissions)"' ``` ### ★ 招待される側（ここが最大の落とし穴） 招待の受諾は通常メールのリンクか Web UI で行う。 **しかしログインできないアカウントは、それができない。** 招待を送っただけでは詰みが解けない。 **API で受諾できる。既存 PAT の `repo` スコープだけで通る:** ```bash # 自分宛の招待を一覧 gh api /user/repository_invitations # 受諾（204 No Content なら成功） gh api -X PATCH /user/repository_invitations/ # 確認 gh api repos// --jq '.full_name, .permissions' ``` 招待は**送信から7日で失効する**。受諾手順を渡し忘れたまま放置すると振り出しに戻る。 --- ## 手順5: スコープの誤解を解く — secrets 登録に `workflow` は要らない ここを取り違えると、不要なトークン再発行を人に頼んでしまう。 | 操作 | 必要なもの | |---|---| | `.github/workflows/*.yml` を push | PAT に **`workflow` スコープ** | | **Actions secrets の登録** | **`repo` スコープ + リポジトリの admin 権限**（`workflow` は不要） | | Issue の作成・コメント | `repo` スコープ | つまり **「ワークフローを置く人」と「秘密鍵を入れる人」は別々でいい。** ワークフローはスコープを持つアカウントが push し、鍵は元アカウントが自分で入れる、という分担が成立する。 ```bash gh secret set --repo / --body '' gh secret list --repo / # 登録の確認（値は読み出せない） ``` **この分担の利点**: 鍵の値が人間のチャットやメールを一切経由しない。 「鍵を取得した本人が、その場で自分で投入する」形にできるので、秘密情報の中継事故が消える。 --- ## 手順6: 秘密情報を探す順序（人に聞き直す前に） 「キーをもう一度ください」と言う前に、必ずこの順で探す。 1. ローカルの環境ファイル ```bash find <プロジェクト群のルート> -maxdepth 4 -name ".env*" -print0 | xargs -0 grep -l -iE "" ``` 2. 過去のエージェント会話ログ（保存されている場合）を `\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つを潰すと、大抵そこへ行き着く前に解決する。 ---