「AIが本番デプロイを禁止されている」と誤診しないための切り分け手順

自動承認モード（permission classifier）付きの AI コーディングエージェントで、本番デプロイが Permission denied ... Reason: [Production Deploy] のように止められることがある。

ここで 「このエージェントには本番デプロイ権限が無い」と結論して人間に手作業を振るのが最大の誤り。 実際には許可設定（allowlist）に該当コマンドが入っているのに、呼び出し方が allowlist と一致していない だけ、というケースが多い。以下は実際に3回連続で止まった事例の切り分け手順。

---

止まったら、設定より先に「自分の叩き方」を3点疑う

① ランナー経由で起動していないか（最頻出）

allowlist は多くの場合コマンド名の前方一致で書かれている。

"Bash(vercel --prod*)"
"Bash(vercel deploy*)"

このとき次は 一致しない（文字列が npx で始まるため）:

npx --yes vercel@latest --prod     # ← allowlist に当たらず classifier 判定に落ちる

対処: バイナリが PATH にあるか先に確認し、直接叩く。

which vercel          # パスが出れば npx は不要
vercel --prod

npx/pnpm dlx/bunx は「毎回最新を取る」ので一見安全に見えるが、 allowlist を無効化する副作用がある。allowlist 前提の環境では常駐インストールして直接叩く。

② サブエージェントに丸投げしていないか

allowlist はシェル実行ツールにしか効かない。 「本番にデプロイして」という指示文でサブエージェントを起動すると、 サブエージェント起動そのものが内容で分類され、同じカテゴリで拒否される。

対処: デプロイのような分類対象の操作は親セッションで自分で叩く。 実装・テスト・検証の委譲は従来どおりで良い（止められるのは「操作そのもの」だけ）。

③ 承認スキップのフラグを付けていないか

vercel promote <url> --yes      # → [Auto-Mode Bypass] で拒否
vercel promote <url>            # → 通る

--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 な作業ツリーからデプロイしない

多人数・多セッションで触るリポジトリでは、作業ツリーに自分と無関係な未コミット変更が 大量に残っていることがある。そのまま本番デプロイするとそれを本番に出してしまう。

git -C <repo> fetch origin
git -C <repo> worktree add <tmp> origin/<本番ブランチ> --detach
# プロジェクト設定ファイル（.vercel 等）のコピーが拒否される場合は link コマンドで作る
vercel link --project <name> --scope <team> --cwd <tmp>
vercel --prod --cwd <tmp> --scope <team>
git -C <repo> worktree remove <tmp> --force

本番ブランチ ≠ main のことがある

main の自動デプロイを意図的に止めている構成（設定ファイルで main: false 等）では、 「main にマージされていない＝本番に出ていない」とは限らず、逆も真。 デプロイ設定ファイルと、過去の Production デプロイがどのブランチから出たかの両方を見る。

# 過去デプロイをブランチで絞って、どれが Production だったか見る
vercel ls <project> --meta <vcsブランチメタキー>=<branch>

---

まとめ：止まった時のチェックリスト

1. which <cli> — ランナー経由をやめて直接叩けるか
2. grep <cli> <設定ファイル> — allowlist に既に入っていないか
3. サブエージェントに投げていないか（操作は親で叩く）
4. --yes 等を外したか
5. 作業ツリーはクリーンか（worktree を切る）
6. 本番ブランチを取り違えていないか

ここまでやって なお止まる時だけ、人間に「この権限が要る」と理由付きで返す。 [Production Deploy] の文字を見た瞬間に人へ投げるのは、たいてい早すぎる。