Claude Codeに本番デプロイを任せる前の「空打ち」チェック手順

金曜の夕方、僕はClaude Codeに「この記事の修正、本番に出しといて」と頼みました。返ってきたのは「公開しました」の一言と、緑色のチェックマーク。安心して帰ったら、翌朝サイトのトップが真っ白でした。

原因はくだらないものでした。プレビューを誰も開いていなかったんです。Claude Codeはビルドが通ったログだけ見て「成功」と判断していた。でも実際のページは、別記事のテンプレートを読み込んでいて中身が空。HTTPは200を返すから、機械的には「公開成功」に見えてしまう。

このとき痛感したのは、速さと安全は別物だということです。デプロイを丸ごと任せると一瞬で終わったように見える。でも何を確かめたかが残っていないと、転んだあと何を戻せばいいのかが分かりません。今日はその対策として、本番権限を渡す前に「空打ち（dry run）」で証拠をそろえる手順を書きます。

この記事の要点

• Claude Codeにデプロイを任せる事故の多くは、本番に触る前の確認を飛ばしたことが原因です。
• 本番権限を渡す前に、ビルド・差分・プレビューURL・戻し担当・触っていない範囲の5点を空打ちで確認します。
• 「機械が判定できる確認」と「人が目で見る判断」を分けると、夜中の事故が減ります。
• コピペで使えるプロンプト雛形と、確認結果を機械チェックするコードを置いておきます。
• 最初から完璧な運用ルールは要りません。1つの修正で試し、転んだ場所をチェックリストに足していきます。

デプロイ事故は「賢さ」ではなく確認不足で起きる

Claude Codeは賢いです。でも賢いことと、本番で安全に動けることは別の話です。

テストで満点を取る学生が、初めてのアルバイトでレジを壊すのと同じで、能力の問題ではなく足場の問題なんですね。デプロイで言えば、足場とは「本番に触る前に何を確かめるか」のことです。

特に静的サイトのデプロイは、失敗が静かに進みます。ビルドが通り、HTTPが200を返すと、見た目には全部うまくいったように見える。中身が空でも、別ページにすり替わっていても、ステータスコードだけ見ていたら気づけません。だから「コードが動いたか」ではなく「正しいページが正しく出ているか」を、人の目で一度見る必要があります。

本番に触る前の空打ち5ステップ

僕がいま使っている手順はこれだけです。順番が大事なので、上から下に並べています。

1. まずローカルでビルドを通す。 ここが落ちるなら本番の話は早い。コードの問題か環境の問題かを、本番に触る前に切り分けます。
2. 差分を読む。 機密情報（APIキー、トークン）や課金に関わる変更が混ざっていないかを目で確認します。
3. プレビューURLを開く。 見出し（h1）、正規URL（canonical）、申し込みボタンの行き先が想定どおりか、実際の画面で確かめます。
4. 戻し担当と戻し方を決める。 失敗したとき誰が、どのコマンドで前の状態に戻すか。これを先に決めておかないと、事故った瞬間に固まります。
5. 証拠がそろってから本番権限を頼む。 1から4の結果が出てはじめて、Claude Codeに本番デプロイを依頼します。

この順番を守るだけで、冒頭の「トップが真っ白」事故はほぼ起きません。なぜなら3でプレビューを必ず開くからです。

AIに任せる範囲と、人が判断する範囲

全部をAIに任せるのでも、全部を手作業に戻すのでもありません。役割を分けます。下の表が、僕の現場での線引きです。

場面	Claude Codeに任せること	人が見る証拠
記事の公開	distのビルドと公開URLの自動チェックを先に走らせる	ビルド結果・差分・URL
申し込みボタンの変更	リンク先と相談導線をプレビューで突き合わせる	ビルド結果・差分・URL
Workersの修正	環境変数に触らず、空打ちのログだけ出す	ビルド結果・差分・URL

ポイントは、読む・並べる・機械チェックする作業はAIに任せ、本番に不可逆な変更を加える操作は人が承認するという分け方です。削除、本番データベースへの書き込み、課金、force pushは、最初は全部「人に聞く」に倒しておきます。安全だと分かった操作だけ、あとから自動に格上げすればいい。

権限の線引きをもっと細かく決めたい人は、Claude Codeの権限設定ガイドとデプロイ前の権限監査が参考になります。

コピペで使えるプロンプト雛形

依頼を丸投げにせず、「まだ本番には出すな」と明示するのがコツです。次の雛形をそのまま貼って使えます。

この変更を本番にデプロイする前の「空打ちチェックリスト」に変換してください。
次の項目を表で返してください。
- ビルド結果（成功 / 失敗とログの要点）
- 差分のリスク（機密情報・課金・削除が含まれるか）
- プレビューURL
- 戻し担当と戻しコマンド
- 触っていない領域
- 再試行の条件
本番デプロイはまだ実行しないでください。私がチェックを確認するまで待ってください。

最後の2行が効きます。「まだ実行するな」「私が確認するまで待て」と書いておくと、Claude Codeが気を利かせて勝手に公開してしまう事故を防げます。プロンプトで安全側に倒す書き方は、上級者向けのプロンプト設計にもまとめています。

コピペで動く検証スクリプト

確認結果を「人の感覚」ではなく機械で判定すると、見落としが減ります。次のスクリプトは、空打ちの結果オブジェクトを受け取り、本番権限を頼んでいい状態かどうかを真偽値で返します。Node.jsがあればそのまま動きます。

// 空打ちの結果。実際の確認内容をここに入れる
const deployCheck = {
  build: "passed",              // ローカルビルドが通ったか
  diffReviewed: true,           // 差分を目で確認したか
  previewUrl: "https://example.pages.dev", // プレビューURL
  rollbackOwner: "Masa",        // 戻し担当
  changedAreas: ["content", "cta-copy"],   // 触った範囲
};

// 本番権限を頼んでいい状態かを判定する門番
function canRequestProductionAccess(check) {
  return (
    check.build === "passed" &&          // ビルドが通っている
    check.diffReviewed &&                // 差分を見た
    /^https:\/\//.test(check.previewUrl) && // プレビューURLがhttpsで存在する
    check.rollbackOwner.length > 0 &&    // 戻し担当が決まっている
    !check.changedAreas.includes("secrets") // 機密領域を触っていない
  );
}

const ready = canRequestProductionAccess(deployCheck);
console.log({ ready });
// ready が false の項目を埋めるまで、本番デプロイは頼まない

このコードの値打ちは、changedAreas に "secrets" が入った瞬間に false を返すところです。機密情報をうっかり触った状態では、絶対に本番権限の依頼まで進まない。人が忙しくて見落としても、門番が止めてくれます。

実際に効いた3つの場面

1つ目は記事の公開。 「ブログ出しといて」だけだと、ビルドが通った時点で公開まで走られます。空打ちを挟むと、公開URLを開いて見出しと中身が一致しているかを先に見るので、冒頭の白画面事故が止まります。

2つ目は申し込みボタンの差し替え。 リンク先を1文字打ち間違えただけで、せっかくの導線が404に落ちます。プレビューでボタンを実際に押して行き先を確かめる手順を入れてから、リンク切れがゼロになりました。

3つ目はCloudflare Workersの修正。 ここは環境変数を1つ消すだけで本番が落ちます。だから空打ちでは環境変数に触らせず、ログだけ出させる。Workers特有の注意点はCloudflare Workers連携の記事にもまとめています。

ありがちな落とし穴と直し方

僕が実際にやらかした失敗と、その直し方を3つ。

落とし穴1：ビルドの前に本番コマンドを叩く。 いきなり wrangler deploy を走らせると、失敗したときコードが悪いのか環境が悪いのか切り分けられません。直し方は単純で、ローカルビルドを必ず先に通すこと。順番を1つ変えるだけで原因究明が一気に速くなります。

落とし穴2：戻し担当を決めていない。 失敗してから「誰が戻す？」を相談し始めると、その数分でアクセスが直撃します。直し方は、空打ちの段階で戻し担当と戻しコマンドを文字に書いておくこと。previousDeployId を控えておくだけでも、復旧が落ち着きます。

落とし穴3：プレビューを開かずステータスコードだけ信じる。 HTTP 200は「サーバーが何か返した」だけで、「正しいページが出た」ではありません。直し方は、プレビューURLを必ず1回ブラウザで開き、見出しと正規URLとヒーロー画像を目で見ること。これが冒頭の白画面を見抜く唯一の方法でした。

証拠を「次回も使えるメモ」として残す

空打ちで確認したことは、その場で消さずに短いメモにまとめておくと、次の作業がぐっと速くなります。

残すのはこのくらいで十分です。最初に出した依頼文、Claude Codeが読んだ範囲、触らなかった範囲、実行した確認コマンド、公開URLやスクリーンショット、判断に迷った点。長文の議事録は要りません。あとから「なぜこの判断をしたのか」を追えれば目的は達成です。

特に効くのが「判断の分かれ目」を一行で書くこと。たとえば「プレビューURLは正しいが戻し担当が未設定なので本番はまだ」のように書いておく。次に同じ作業をするとき、自分でも他の人でも、同じ確認を再現できます。デプロイ以外の自動化でも同じ考え方が使えるので、非エンジニア向けのClaude Code入門とあわせて読むと、任せ方の感覚がつかめると思います。

よくある質問

Q. 空打ちって、結局ただの手間が増えるだけでは？ 最初はそう感じます。でも事故が一度起きると、復旧と原因究明に何時間も溶けます。空打ちは数分。割に合う保険だと思って続けています。

Q. ローカルビルドが通れば、プレビューは見なくていい？ だめです。ビルドが通っても、テンプレートのすり替えや空ページは起こります。HTTP 200と「正しいページ」は別物なので、目視は省けません。

Q. 戻し担当は自分一人でも決める意味ある？ あります。一人でも「失敗したらこのコマンドで戻す」と先に文字にしておくと、いざ事故ったとき迷いません。決めること自体が手順になります。

Q. Claude Codeが「公開しました」と言ったら信じていい？ 返答そのものより、空打ちの証拠を見てください。ビルド・差分・プレビュー・戻し担当がそろっているかで判断します。言葉は雰囲気、証拠は事実です。

Q. 小さなサイトでもここまでやる必要ある？ 規模より「戻せるか」で考えてください。小さくても本番が落ちれば困ります。まずはプレビューを開く1ステップだけでも入れると、効果が実感できます。

実際に試した結果

冒頭の白画面事故のあと、僕はこの空打ち手順を自分のブログ運用に組み込みました。

確かめたのは3点です。1つ目、プレビューURLを必ず開くルールにしたら、テンプレートすり替えによる空ページがゼロになりました。2つ目、上の検証スクリプトを公開前に走らせるようにしたら、機密領域を触った変更が ready: false で止まり、本番権限の依頼まで進まなくなりました。3つ目、戻し担当と戻しコマンドを毎回メモするようにしたら、ヒヤッとした場面でも数分で前の状態に戻せるようになりました。

賢いAIに全部任せて祈るより、転んでもケガしない足場を先に作る。遠回りに見えて、これが結局いちばん速い、というのが今の実感です。まずはプレビューを開く1ステップから、自分のデプロイに門番を足してみてください。

チームで本番デプロイの線引きやレビュー体制まで整えたい場合は、研修・相談で一緒に手順化できます。公式の運用基準はAnthropic公式のClaude Codeドキュメントも参照してください。