# 「AIが本番デプロイを禁止されている」と誤診しないための切り分け手順 自動承認モード（permission classifier）付きの AI コーディングエージェントで、本番デプロイが `Permission denied ... Reason: [Production Deploy]` のように止められることがある。 ここで **「このエージェントには本番デプロイ権限が無い」と結論して人間に手作業を振るのが最大の誤り**。 実際には許可設定（allowlist）に該当コマンドが入っているのに、**呼び出し方が allowlist と一致していない** だけ、というケースが多い。以下は実際に3回連続で止まった事例の切り分け手順。 --- ## 止まったら、設定より先に「自分の叩き方」を3点疑う ### ① ランナー経由で起動していないか（最頻出） allowlist は多くの場合コマンド名の前方一致で書かれている。 ``` "Bash(vercel --prod*)" "Bash(vercel deploy*)" ``` このとき次は **一致しない**（文字列が `npx` で始まるため）: ```bash npx --yes vercel@latest --prod # ← allowlist に当たらず classifier 判定に落ちる ``` **対処**: バイナリが PATH にあるか先に確認し、直接叩く。 ```bash which vercel # パスが出れば npx は不要 vercel --prod ``` `npx`/`pnpm dlx`/`bunx` は「毎回最新を取る」ので一見安全に見えるが、 **allowlist を無効化する副作用**がある。allowlist 前提の環境では常駐インストールして直接叩く。 ### ② サブエージェントに丸投げしていないか allowlist は**シェル実行ツールにしか効かない**。 「本番にデプロイして」という指示文でサブエージェントを起動すると、 **サブエージェント起動そのもの**が内容で分類され、同じカテゴリで拒否される。 **対処**: デプロイのような分類対象の操作は**親セッションで自分で叩く**。 実装・テスト・検証の委譲は従来どおりで良い（止められるのは「操作そのもの」だけ）。 ### ③ 承認スキップのフラグを付けていないか ```bash vercel promote --yes # → [Auto-Mode Bypass] で拒否 vercel promote # → 通る ``` `--yes` / `-y` / `--force` / `--no-input` のような「確認を潰すフラグ」は、 分類器から見ると**安全機構の迂回**そのもの。付けない。 --- ## 付随して踏みやすい罠 ### 設定ファイル自身の書き換えは別カテゴリで止まる 「allowlist に足せば通る」と拒否メッセージに書かれていても、 AI が設定ファイルを編集しようとすると `[Self-Modification]` で止まることがある。 **まず `grep` で既存 allowlist を読む**。多くの場合、追加不要で既に入っている。 なお、分類器に止められた操作を通すために**自分で allowlist を広げるのは避ける**。 安全機構の自己解除であり、人間の判断を飛ばすことになる。人に判断を返す。 ### 「ビルド済みを昇格」は対話確認が出て使えないことがある ``` ? This deployment is not a production deployment and cannot be directly promoted. A new deployment will be built... (y/N) ``` 非対話実行ではここで止まる（`--yes` は上記③で使えない）。 **allowlist に入っている本番デプロイコマンドを使う**ほうが早い。 ### dirty な作業ツリーからデプロイしない 多人数・多セッションで触るリポジトリでは、作業ツリーに**自分と無関係な未コミット変更**が 大量に残っていることがある。そのまま本番デプロイすると**それを本番に出してしまう**。 ```bash git -C fetch origin git -C worktree add origin/<本番ブランチ> --detach # プロジェクト設定ファイル（.vercel 等）のコピーが拒否される場合は link コマンドで作る vercel link --project --scope --cwd vercel --prod --cwd --scope git -C worktree remove --force ``` ### 本番ブランチ ≠ main のことがある `main` の自動デプロイを意図的に止めている構成（設定ファイルで `main: false` 等）では、 **「main にマージされていない＝本番に出ていない」とは限らず、逆も真**。 デプロイ設定ファイルと、過去の Production デプロイがどのブランチから出たかの両方を見る。 ```bash # 過去デプロイをブランチで絞って、どれが Production だったか見る vercel ls --meta = ``` --- ## まとめ：止まった時のチェックリスト 1. `which ` — ランナー経由をやめて直接叩けるか 2. `grep <設定ファイル>` — allowlist に既に入っていないか 3. サブエージェントに投げていないか（操作は親で叩く） 4. `--yes` 等を外したか 5. 作業ツリーはクリーンか（worktree を切る） 6. 本番ブランチを取り違えていないか ここまでやって **なお止まる時だけ**、人間に「この権限が要る」と理由付きで返す。 `[Production Deploy]` の文字を見た瞬間に人へ投げるのは、たいてい早すぎる。 ---