制作会社のCloud Build CI/CDをClaude Codeで整える: 顧客LPの公開事故を減らす

制作会社で顧客LPを直していると、公開ボタンの前で毎回ざわつきます。価格表を直しただけのはずが、古いキャンペーン画像が戻る。フォームIDを検証用のまま出す。広告タグを消す。別案件の環境変数でビルドする。急ぎの修正ほど、誰が何を確認したのか残りません。

この記事では、制作会社がCloud BuildのCI/CDをClaude Codeで棚卸しし、顧客LPの公開事故を減らす流れを書きます。狙いは大企業向けの重いDevOpsではありません。小さな制作チームでも、差分、承認、ビルドログ、権限、戻し方を公開前に見られる状態へ寄せることです。

この記事の要点

• 制作会社のCI/CDは、ビルドより先に顧客名、公開URL、フォームID、広告タグ、承認者を確認します。

• Cloud Buildにはトリガー、承認ゲート、リポジトリ連携、サービスアカウント、ログがあり、公開前の証跡を残せます。

• Claude Codeには、cloudbuild.yaml、差分、環境変数名、承認チェック表、戻し手順の下書きを作らせます。

• 人が見る範囲は、顧客承認、価格、法務表記、広告タグ、問い合わせ先、本番公開タイミングです。

• ROIは、公開前レビュー時間、公開後差し戻し件数、タグ事故、フォーム事故、休日対応回数で見ます。

現場で起きる失敗シーン

制作会社の公開事故は、コードの難しさより確認漏れから起きます。LPのテキスト修正で、料金表は直ったのにCTAの下に古い税込表記が残る。フォームの送信先だけ本番へ切り替え忘れる。OGP画像だけ前回キャンペーンのまま残る。Gitの差分では小さく見えても、顧客には大きな事故です。

もうひとつの失敗は、公開作業が人の手順書だけに残ることです。Aさんはnpm build、Bさんはwrangler、Cさんは手元のFTP、DさんはCloud Buildを使う。誰かが休むと公開経路が変わり、ログも承認も残りません。制作会社では、このばらつきが利益を削ります。

参考にする公式情報は、Cloud Buildの概要、トリガー、承認ゲート、2nd genリポジトリ連携、ユーザー指定サービスアカウント、デフォルトサービスアカウントの注意点です。この記事では、顧客LPを安全に出すための小さなCI/CDへ落とします。

• Google Cloud: Cloud Build

• Google Cloud: Cloud Build triggers

• Google Cloud: Gate builds on approval

• Google Cloud: Cloud Build repositories

• Google Cloud: Configure user-specified service accounts

• Google Cloud: Default Cloud Build service account

業務フロー: 公開前に顧客LPの見落としを潰す

最初に作るのはcloudbuild.yamlではありません。案件ごとに、顧客名、公開URL、Gitブランチ、確認URL、フォームID、広告タグ、問い合わせ先、料金表、法務表記、OGP画像、承認者を1枚の表にします。これがないと、CI/CDは速い公開ボタンになるだけです。

次に、公開前チェックを3段に分けます。1段目は機械で見られる項目です。ビルド、リンク切れ、環境変数名、フォームID、sitemap、robots、画像ファイルの存在を確認します。2段目はClaude Codeが差分から表にできる項目です。料金表、CTA、文言、タグ、公開URL、変更理由です。3段目は人が見る項目です。顧客承認、キャンペーン日付、景表法や医療広告のような業界表記、広告開始時刻です。

| 見るもの | Claude Codeが作る下書き | 人が確認する点 |

| --- | --- | --- |

| cloudbuild.yaml | build, test, deploy, rollbackの段取り | 本番公開の承認者 |

| 差分 | 変更ファイル、料金、CTA、タグの表 | 顧客が承認した内容か |

| 環境変数 | 必須キーと検証/本番の違い | 秘密値を本文へ貼っていないか |

| フォーム | action, formId, thanks URL | 本番の送信先か |

| 公開ログ | build id, commit, approver, URL | 戻し方が残っているか |

Cloud Buildのトリガーは、pushやPRなどのイベントからビルドを起動できます。さらに承認付きトリガーにすると、ビルドをすぐ走らせず、承認待ちにできます。制作会社では、mainへmergeしただけで本番公開するより、顧客確認が絡むLPだけ承認待ちにする方が合う場面があります。

Claude Codeに任せる範囲と人が見る範囲

Claude Codeに任せる範囲は、公開前に見落としやすい項目を表にする作業です。cloudbuild.yaml、package.json、環境変数名、フォーム部品、LPの差分、過去の公開手順書、READMEを読ませ、公開前チェック表と戻し手順を作らせます。

人が見る範囲は、顧客との約束に関わる判断です。料金表、キャンペーン期日、広告タグ、法務表記、問い合わせ先、公開時刻、顧客承認は人が見ます。Claude CodeがOKと言っても、顧客が見た確認URLと同じ内容かは担当者が見るべきです。

権限も分けます。Cloud Buildのデフォルトサービスアカウントは用途によって広すぎる場合があります。LP公開用には、対象のホスティング、対象のSecret、対象のログへ必要な権限だけ持つサービスアカウントを用意します。制作会社で複数顧客を扱うなら、顧客Aのビルドが顧客BのSecretを読めない形が理想です。

3つのUse case

Use case 1: 顧客LPごとの公開前チェック表を作る

• 入力: cloudbuild.yaml、package.json、LP差分、確認URL、顧客承認メモ、フォーム設定。

• 出力: 料金表、CTA、フォームID、広告タグ、OGP、thanks URL、承認者を並べた公開前チェック表。

• 人の確認: 顧客が承認した文言か、公開日時が合っているか、問い合わせ先が本番かを見る。

このUse caseでは、Claude Codeに差分を読ませて、ページ上の収益に近い部分から表にします。見出しの誤字より、CTA、料金、フォーム、広告タグを先に見ます。

Use case 2: Cloud Buildの承認ゲートを入れる

• 入力: Cloud Build trigger設定、対象ブランチ、公開対象、承認者、緊急公開の例外ルール。

• 出力: 承認待ちにする条件、承認者、build id、commit、公開URL、却下時の対応を持つ運用メモ。

• 人の確認: 顧客確認が必要な案件か、代理承認してよい担当者か、公開時刻に広告開始が合うかを決める。

承認ゲートは、全部のビルドを止めるためではありません。テスト環境へのデプロイは自動、本番LPは承認待ち、緊急修正は別ルール、という分け方にします。

Use case 3: サービスアカウントを顧客案件ごとに分ける

• 入力: Cloud Buildのサービスアカウント、Secret Manager参照、ホスティング先、顧客別プロジェクト、公開先URL。

• 出力: 顧客名、実行サービスアカウント、読めるSecret、デプロイ先、不要な権限、削除候補の表。

• 人の確認: 顧客Aの担当者やビルドが顧客BのSecretを読めないか、退職者や外部協力者が残っていないかを見る。

AIエージェントがCI/CDを直す時は、サービスアカウントの境界が特に大事です。Claude Codeには権限の候補を出させますが、付与や削除の実行は承認後にします。

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

あなたは制作会社のCloud Build CI/CD点検担当です。目的は、顧客LPの公開事故を減らすことです。速く公開するより、公開前に顧客名、URL、フォーム、広告タグ、料金表、承認者、戻し方を確認できる状態を作ってください。



対象:

- cloudbuild.yaml

- package.json

- LPの差分

- 環境変数名とSecret参照名

- フォームID、thanks URL、問い合わせ先

- Cloud Build trigger、承認設定、サービスアカウント



作ってほしいもの:

1. 公開前チェック表

2. Claude Codeが確認できる項目、人が見る項目、顧客確認が必要な項目の3列表

3. 承認ゲートを入れるべき条件

4. サービスアカウントの権限が広すぎる候補

5. 公開後に戻す手順



制約:

- 秘密値は本文に再掲しない

- 変更コマンドは実行せず、まず差分案だけ出す

- 顧客承認が必要な文言をAIだけでOKにしない

- 主CTAは /training/ にする

動く確認コード

下のNode.jsコードは、公開前チェック表の最低限を確認します。Cloud Buildへ接続するコードではありません。案件メモやJSONに落とした項目を、フォームID、確認URL、承認者、戻し手順の抜けでチェックします。

const releases = [

  { client: "Aクリニック", url: "https://example.com/lp", formId: "prod-contact", approver: "[email protected]", rollback: "git revert bc48be8b" },

  { client: "B工務店", url: "https://example.net/campaign", formId: "stg-contact", approver: "", rollback: "" }

];



const findings = releases.flatMap((release) => {

  const issues = [];

  if (!release.url.startsWith("https://")) issues.push("公開URLがhttpsではない");

  if (!release.formId || /stg|test|dev/i.test(release.formId)) issues.push("フォームIDが検証用に見える");

  if (!release.approver) issues.push("承認者が空");

  if (!release.rollback) issues.push("戻し手順が空");

  return issues.map((issue) => ({ client: release.client, issue }));

});



if (findings.length > 0) {

  console.table(findings);

  process.exitCode = 1;

} else {

  console.log("Landing page release checklist passed.");

}

実行例は、release-check.mjs として保存し、node release-check.mjs です。B工務店の行に検証用フォームID、承認者なし、戻し手順なしが出れば、公開前に止める理由が見えます。

Pitfall: CI/CDを入れたのに公開事故が増える落とし穴

原因: Cloud Buildを入れると、pushから公開までが速くなります。ところが制作会社では、速さそのものが事故の原因になる場面があります。料金表、フォーム、広告タグ、顧客承認が未確認のまま、自動で本番へ出ると、手作業より大きく燃えます。

直し方: 自動化する範囲と止める範囲を分けます。リンク切れ、ビルド、環境変数名、フォームIDの形式は機械で見ます。顧客承認、料金、法務表記、広告開始時刻は人が見ます。Cloud Buildの承認ゲートは、この境目を残すために使います。

もうひとつの落とし穴は、全案件で同じサービスアカウントを使うことです。顧客ごとにSecret、公開先、権限が違うのに、同じ実行IDでまとめると、事故の範囲が広がります。まずはLP公開用の権限を小さくし、顧客ごとの分離を表で見ます。

よくある質問

Q. 制作会社でもCloud Buildは重すぎませんか。

A. すべての案件へ入れる必要はありません。公開頻度が高いLP、フォームがあるLP、広告開始時刻があるLPから入れると効果が見えます。

Q. GitHub ActionsではなくCloud Buildにする理由はありますか。

A. GCP上のSecret、Cloud Run、Cloud Storage、Artifact Registry、ログと近い場合はCloud Buildが扱いやすいです。GitHub Actionsで足りる案件もあります。大事なのはツール名ではなく、承認、証跡、権限、戻し方です。

Q. Claude Codeにデプロイまで任せてよいですか。

A. 最初は任せない方が無難です。Claude Codeには差分表、チェック表、cloudbuild.yaml案、権限候補を作らせ、本番公開は人の承認後にします。

Q. 相談導線は何に寄せますか。

A. CI/CD、承認、権限、顧客別運用が絡むので、主CTAは研修・相談です。制作会社ごとの案件数、顧客業種、公開頻度に合わせて設計した方が早いです。

相談へ進むなら

ClaudeCodeLabの研修・相談では、制作会社のCloud Build、公開前チェック表、承認ゲート、顧客別サービスアカウント、戻し手順を一緒に整えられます。今日やるなら、まず直近3件のLP公開で、フォームID、広告タグ、料金表、承認者、戻し手順が記録に残っているか確認してください。

実際に試した結果

この記事では、frontmatter、本文文字数、公式リンク、Use case 3本、入力・出力・人の確認、コードフェンス、/training/へのCTAを確認しました。確認コードはNode.jsで構文を通し、検証用フォームID、承認者なし、戻し手順なしを検出するところまで見ました。Cloud Buildの承認やサービスアカウント付与は実行せず、公開前に人が承認する前提として残しました。