連携が「権限不足」に見えて実は「身元違い」のとき — 両側のアカウントを先に実測する

ホスティングサービスとコードホストの連携（例: デプロイサービス ↔ Git ホスティング）が Failed to connect / access denied / could not find repository で通らないときに使う。

エラー文が「private リポジトリへのアクセス権を確認してください」と読めるため、 資源側（リポジトリ所有者）の権限をいじり続けて何往復も溶かすのが典型的な失敗。 実際には、要求側が別のアカウントとして名乗っていることがある。その場合、 資源側でいくら許可を足しても永久に繋がらない。

判定: 権限か、身元か

次のどちらかに当てはまるなら、権限ではなく身元を疑う。

• 資源側で権限を追加・変更したのに、エラーの文言が1文字も変わらない
• 資源側の管理画面では「アプリに許可済み」と表示されているのに、要求側からは見えない

手順: 両側の「誰として動いているか」を確定させる

この2つを、人に手作業を頼む前に必ず自分で実測する。

1. 要求側が外部プロバイダで名乗る名前

CLI の whoami 相当はそのサービス内のアカウント名しか返さない。 外部プロバイダ側でどの名前を名乗るかは別の情報なので、必ず 「ログイン接続 / Login Connections / Connected Accounts」の画面を見る。

<デプロイサービス>/account/login-connections

ここに出ている Git ホスティングのアカウント名が、連携で実際に使われる身元。

2. 資源側の所有者と種別

gh repo view <owner>/<repo> --json owner,isPrivate --jq '"owner=\(.owner.login) private=\(.isPrivate)"'
gh api users/<owner> --jq '"login=\(.login) type=\(.type)"'

type は User か Organization かを返す。組織だと思っていた名前が実は個人アカウント だったというケースがあるので、名前の見た目（-org で終わる等）で判断しない。

3. 突き合わせ

1 と 2 が別人格なら、資源側の設定変更はすべて無駄。取れる道は3つしかない。

方法	内容	コスト
A	資源に、要求側の身元を collaborator (admin) として追加する	その身元でログインして招待を承諾する操作が1回必要
B	資源をその身元の配下へ transfer する	承諾が1回必要。URL が変わるので remote 更新も要る
C	要求側のログイン接続を、資源の所有者に張り替える	同じ接続を使う他プロジェクトの連携を壊すリスクがある

A・B は招待された側としてログインできる人にしか完了できない。その認証情報が手元に無いなら、 自動化では最後まで到達できない。先に確認する:

gh auth status
ls ~/.<設定ディレクトリ>/*.env

詰まったら手段ではなく目的に戻る

連携そのものは目的ではなく手段であることが多い。 「push だけで自動デプロイしたい」の裏にある本当の目的が **「人間のデプロイ手作業をゼロにする」**なら、連携を諦めても達成できる。

エージェント実行環境なら、デプロイコマンドを許可リストに入れる形で同じゴールに届く。

"permissions": {
  "allow": [
    "Bash(node *<デプロイCLIのエントリ>.js deploy*)",
    "Bash(node *<デプロイCLIのエントリ>.js redeploy*)"
  ]
}

ただしこれは安全機構の緩和なので、必ず人間に説明して明示の承認を取ってから足す。 エージェントが自分の制限を勝手に外すのは禁止。以下を伝えたうえで判断を委ねる。

• 何ができるようになるか（デプロイ系コマンドのみ。環境変数の追加や削除は含まない）
• 何が起きなくなるか（毎回の承認プロンプトが出なくなる）
• 元に戻す方法（該当行を消す）

併せて踏みやすい罠

• 環境変数はデプロイ作成時にスナップショットされる。 変数を足した後に再デプロイしないと反映されない。 「変数は設定済み」「本番は最新コード」の両方が真でも、作られた順番が逆なら動かない。 デプロイの created 時刻と変数の追加時刻を必ず突き合わせる。
• CLI が exit 0 で終わってもデプロイが失敗していることがある。 出力の末尾まで読む （Error: Not authorized などが最後の1行に出る）。成功判定は CLI の終了コードではなく、 エイリアスが指すデプロイの ID と作成時刻で行う。
• リポジトリを複数のエージェントが並行で触っていることがある。 着手前に git log --oneline -3 と git status -sb を見て、未 push のコミットが他人の作業でないか 確認する。他人の作業途中のコミットを push・デプロイすると、未検証のコードが本番に出る。