# 連携が「権限不足」に見えて実は「身元違い」のとき — 両側のアカウントを先に実測する ホスティングサービスとコードホストの連携（例: デプロイサービス ↔ 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. 資源側の所有者と種別 ```bash gh repo view / --json owner,isPrivate --jq '"owner=\(.owner.login) private=\(.isPrivate)"' gh api users/ --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 は**招待された側としてログインできる人**にしか完了できない。その認証情報が手元に無いなら、 自動化では最後まで到達できない。先に確認する: ```bash 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・デプロイすると、未検証のコードが本番に出る。 ---