目次
まずProductionが配信しているcommitを確認する
Git providerへ新しいcommitをpushしたのにVercelのProductionで古い内容が表示されるなら、最初にブラウザの見た目ではなく、現在Productionとして扱われているDeploymentのbranchとcommit SHAを確認します。VercelのDeployments画面でProductionのDeploymentを開き、Git reference、commit、状態、作成時刻を記録してください。そのあとGitHubなどのproduction branchの最新SHAと比べます。Preview URLで新しい内容が見えても、Production domainがそのPreviewを配信しているとは限りません。
Vercelは接続されたGit repositoryのbranch pushをもとにPreview deploymentを作り、設定されたProduction branchへのcommitをProductionへdeployします。Production branchは通常 main ですが、Project Settingsで別branchに変更できます。したがって「mainへpushしたか」だけで判断せず、Vercel Projectが接続するrepositoryと、Production Branchの設定を確認します。
commitがDeploymentになっていない場合
Production branchにcommitがあるのに該当SHAのDeploymentが見つからない場合、Git integration、branch設定、deployment skip条件を順に確認します。Vercel Project Settingsが意図したrepositoryを接続しているか、最新commitが本当にそのrepositoryへpushされたか、対象branchがProduction Branchとして追跡されているかを照合してください。似た名前のfork、別organization、別projectへpushしていると、Git上で最新でも確認中のProjectには新しいDeploymentが作られません。
VercelはProjectの設定や vercel.json のIgnore Build Stepで、commitに対するbuildをskipできます。Project Settingsにignore commandがあるか、設定されたscriptがどの差分を「変更なし」と判定するかを確認します。VercelのProject Settings Docsでは、Ignored Build Stepがbuildを継続するかskipするかを決める仕組みを説明しています。monorepoで特定folderのみを見る条件が誤っていると、影響のある変更があってもbuildがskipされることがあります。
DeploymentがCanceledやSkippedに見えるときは、commitが拒否されたと即断せず、Deployment詳細のbuild stepとignore command結果を確認します。buildが作られなかったのか、buildが開始して失敗したのか、成功したPreviewだけでProduction branchではないのかを分けて記録してください。状況が違えば対応も異なります。
DeploymentはあるのにProductionが古い場合
対象commitのDeploymentが存在するなら、EnvironmentがProductionかPreviewか、状態がReadyか、どのbranch/refから作られたかを確認します。Previewでは新しいコードが動いていても、Production domainが指すdeploymentが古ければ公開URLは変わりません。VercelのEnvironments Docsでは、Production deploymentが成功するとProduction domainsが新しいdeploymentを指すと説明しています。Deploymentの成功・昇格状態とdomain割当を併せて確認します。
同じSHAが複数branchに存在する場合は、commit SHAだけでなくbranch configurationとDeploymentの環境を見ます。VercelのGit docsは同じcommitが複数branchにある場合、適切なbranch設定を選ぶことが重要と説明しています。環境変数、build設定、Production branch判定が変わる可能性があるため、別branchのPreviewが新しく見えることだけでProduction反映済みとしないでください。
カスタムdomainに古い内容が出る場合は、どのProject / Deploymentへdomainが割り当てられているかを確認します。成功したProduction deploymentではdomainが更新されるのが標準動作ですが、手動promotionなどの設定や運用によって自動反映を管理している場合があります。Production domainの割当先とDeployment詳細をownerが照合し、無関係なProjectへdomainを付け替えないようにします。
原因候補ごとの確認表
最新commitのDeploymentが存在しない：Git repository接続、push先branch、ProjectのProduction Branch、Deploymentが無効化されていないかを確認する。
Canceled deploymentがある：Ignored Build Step / ignoreCommand、branch条件、monorepoの差分判定、build logを確認する。
新しいDeploymentがPreview：Production Branchとdeployment environmentを確認し、PreviewをProductionと取り違えていないか見る。
Production Deploymentは新しいがURLが古い：Production deploymentの状態、promotion、custom domainの割当先、確認しているhostを照合する。
最新commitのbuildが失敗：Deployment logでinstall/build errorを確認する。新しいcommitが反映されない問題と、反映対象のbuildが失敗する問題を分ける。
同じSHAが複数branch：Deployment詳細のbranchとProject environmentを確認し、対象のProduction Branchから作られたdeploymentかを確認する。
調査の手順
-
Git providerで対象repositoryとproduction branchの最新commit SHAを確認します。ブラウザ画面やローカル作業treeのHEADではなく、remoteへpush済みのcommitを基準にします。
-
Vercelで同じProjectを選び、Production deploymentのcommit SHA、branch、environment、status、作成時刻を記録します。Project名が似ているときはrepository connectionも開いて確認します。
-
commit SHAが一致しない場合、VercelのDeploymentsに新しいdeploymentがあるか探します。なければGit連携・production branch・Git pushイベントを確認し、CanceledならIgnored Build Stepとその出力理由を見ます。
-
一致するcommitのDeploymentがPreviewなら、そのbranchがProduction Branchか、Production環境でbuildされたかを確認します。Previewの成功を本番反映の証拠にしないでください。
-
Production Deploymentが対象SHAでReadyなのに公開hostが古い場合、Deploymentのpromotion状態とcustom domainの割当先を確認します。ドメイン設定を変更する前に、対象Projectと既存のRollback先をownerと照合します。
-
buildが失敗している場合は、build logの最初のエラー、使われたcommit、environmentを記録します。修正commitを作るか、必要なら承認済みのDeployment手順へ進むかはrelease ownerが判断します。
無確認の再deployを避ける
最新commitのDeploymentが見当たらないとき、まず任意のSHAやbranchから手動Production deploymentを作るのは避けてください。VercelはDashboardからGit referenceを指定してDeploymentを作成できますが、どのbranch configurationやenvironmentを使うかが結果に影響します。Gitの最新branchを誤認した状態で手動deployすると、Productionへ意図しないcommitを出す可能性があります。
再deploy前には、対象project、接続repository、commit SHA、branch、Production environment、最新の成功Deployment、rollback候補を確認します。Git連携の自動deploymentを直す問題なのか、特定commitの手動deploymentが承認済みなのかを分け、Production ownerの通常のrelease gateに従います。
VercelのProduction Branch設定、Git deploymentを無効にする設定、Ignored Build Stepは、今後の複数commitに影響します。単一の古いDeploymentを直すつもりでProject-wide設定を変えると、別branchや将来のreleaseを止める可能性があります。原因が設定にある場合は、その設定を誰が管理し、変更がどのProject / branchへ及ぶかを確認してから調整します。
確認結果の記録例
Git側：repository、production branch名、最新remote SHA、push時刻。Vercel側：Project、Git接続先、Production Branch、対象Deploymentのenvironment・branch・SHA・status・作成時刻。Build側：ignore step有無、build結果、失敗箇所。公開側：確認したdomainとDeploymentへの割当を記録します。
記録があれば、「pushが別branchだった」「Vercelが別repositoryを見ている」「buildがskipされた」「Previewだけ成功した」「Production domainが旧Deploymentを指す」「新build自体が失敗」のどれかを管理者と判断できます。commit SHAやdomainを曖昧な「最新」「本番」とだけ書かず、具体的な値と画面を結び付けてください。
完了条件と次の行動
Reader Jobの完了条件は、Git provider上のremote commit、VercelがProductionとして扱うDeployment、Production domainの割当を照合し、どの段階で新しいcommitが止まったか特定できることです。対象SHAのDeploymentがなければ連携・branch・ignore設定を、Preview止まりならProduction Branch / environmentを、Deploymentが新しいのにdomainが古ければpromotionとdomain割当を調べます。
Productionへ手動deployする、domainを付け替える、ProjectのGit設定やProduction Branchを変える必要がある場合は、release ownerの承認済み手順に従ってください。原因がbuild failureならlogの最初の具体的なエラーを開発者へ渡し、古いProductionを残したまま復旧案を決めます。
この記事は特定のVercel Projectを操作した実測記録ではありません。Vercel公式Docsに基づき、Git commit、Production Branch、Ignored Build Step、deployment environment、domain assignmentを区別する確認手順を示しています。
Sources
Vercel Docs, Deploying Git Repositories with Vercel: https://vercel.com/docs/git（新しいタブで開く）
Vercel Docs, Environments: https://vercel.com/docs/deployments/environments（新しいタブで開く）
Vercel Docs, Project settings (Ignored Build Step): https://vercel.com/docs/project-configuration/project-settings（新しいタブで開く）
Vercel Docs, Git Configuration: https://vercel.com/docs/project-configuration/git-configuration（新しいタブで開く）
確認日：2026-10-15。Production Branch、Git push deployment、Ignored Build Step、Production domain割当の現行仕様をVercel Docsで確認。