vercel --prodの同時実行は、vercel inspectでコミットが分からなくなる

結論

GitHub連携ではなくVercel CLIから直接vercel --prodを叩いてデプロイする運用では、デプロイ結果にgitのコミットが紐付かない。複数人が同時にvercel --prodを実行すると後勝ちで上書きされるが、vercel inspectで確認しても「どちらのビルドにどちらのコミットが入っているか」を示す情報が無く、後から判別できない。

症状

2026-09-16の午前、同じVercelプロジェクトに対して、2つの作業が同時にvercel --prodを実行し、3回衝突した。

このプロジェクトのデプロイは、GitHubのpushをトリガーにする連携ではなく、ローカルからvercel --prodを叩いてビルドをアップロードする運用になっている。連携が無いぶん、デプロイのたびにgitの状態を意識せず即座に本番へ反映できる一方、Vercel側にはそのビルドがどのコミットから作られたかという情報自体が渡らない。

実際にvercel inspectで本番デプロイを確認しても、出力に含まれるのはデプロイID・プロジェクト名・状態・作成日時・エイリアスの一覧・ビルド成果物の一覧で、gitのコミットハッシュやコミットメッセージに相当する項目は無い。これはこの時だけの一時的な表示崩れではなく、CLIアップロードでデプロイした結果を今あらためて確認しても同じで、コミットに関する情報はどこにも出てこない。

そのため、2つのビルドが3回衝突したとき、後からvercel inspectを見ても「今本番に乗っているのはどちらの変更か」を判定する手掛かりが無かった。片方が自分の変更を含んでいるはずだと思い込んで進めることもできず、確定させ直すためには本流の最新コミットから改めてデプロイをやり直すしかなく、結果として2回分の余計なデプロイが発生した。

原因

原因は、GitHub連携を使わない運用を選んだ時点で、デプロイとgitコミットを紐付ける仕組みそのものが存在しないことにある。

GitHub連携のデプロイは、Vercel側がpushを検知してビルドするため、そのビルドがどのコミットから作られたかを常に記録できる。一方、CLIアップロードはローカルのビルド成果物を送るだけの経路で、送信元がどのコミットの作業ツリーだったかをVercelに伝える標準的な手段が無い。

このプロジェクトはCLIアップロード運用を選んでいたため、複数の作業が同時にデプロイを叩いても、Vercel側にはそれを区別する材料が最初から無かった。後勝ちで上書きされることそのものは通常のデプロイでも起きうるが、GitHub連携ならそこにコミット情報が残るぶん「どちらが今本番か」を確認できる。CLIアップロードにはその情報が存在しないため、確認する手段そのものが無いという違いがある。

直す

CLI運用を維持したまま連携方式を変えずに対処するため、コード側の変更は行っていない。代わりに、デプロイを実行する前に、同時に他の作業がデプロイしようとしていないかを確認してから実行するという運用上の手順を明文化した。

デプロイのたびにこの確認手順を踏むことで、そもそも同時にvercel --prodが2つ走る状況自体を作らないようにする。vercel inspect側に手を入れて事後に判別可能にする方向ではなく、衝突が起きる前に防ぐ方向で対処している。

再発防止

この事故は本番の顧客には実害を与えていない。実行したのは2つの作業のいずれも自分（同一の運用者）だったため、確定させ直すための2回分の余計なデプロイで収束している。

GitHub連携を使わずにCLIアップロードでデプロイする運用を選ぶ場合、「デプロイ後にgit側の情報で後から確認できる」という前提が成立しないことを認識しておく必要がある。これはVercelの不具合ではなく、連携方式を選んだ時点で最初から存在しない機能であり、事後の確認手段を用意する方向では解決できない。同時に実行される可能性そのものを、実行前の確認でつぶすしかない。