Claude Codeでのランディングページ構築
Claude Codeでマーケティングページを構築、出荷、改善するための動作設定。 ほとんどの作業を行う5つの要素: リポジトリ、ホスト、ブランドキット、パフォーマンス、そしてファネルデータ。 これらを適切に設定すれば、残りはすべてイテレーションです。
ページが出荷前に表示される2つの方法（セクション4）: あなたとClaudeのためのローカル開発サーバーと、非技術者向けのClaude Design。Designを使用する場合は、まずセクション4のハードルールを読んでください。そこには元に戻す機能はありません。
一貫したテーマ: 仕事はデプロイで終わらない。 ライブでトラッキングされていないページは、改善できないページです。
作業の順序
これらの順序で実行してください。各ステップが次のステップをより簡単にします。
- リポジトリを最初に — コードの前に。バージョン管理は、他のすべてのための元に戻すボタンです。
- ホスト + デプロイパイプラインを2番目に — サイトが簡単で、壊れたデプロイが何もコストしないうちに。
- ブランドキットを3番目に — コピーを1文字も書く前に、最初のドラフトがすでにブランドに沿っているように。
- ページを構築 — 最初にビジュアル/静的、次にインタラクティブ、最後にトラッキング。
- 初日に最小限のトラッキングで出荷 — その後、実際のデータに基づいて速度とコピーを最適化します。
1. リポジトリを使用する（GitHubなど）
すでにClaude Codeを使用しているなら、これは明白です。まだ試しているだけなら、これはウォームアップです。リポジトリはバージョン管理、クラウドバックアップ、そして最も重要なことにデプロイ戦略を提供します。
mainはプロダクションであり、あなたがマージするプルリクエストを通じてのみそこに着地します。そのルールをCLAUDE.mdに明示的に記述してください — starters/CLAUDE.mdを参照。
ループ
これが全体のサイクルです。どんなに小さな作業でも、すべての作業に対してこれを実行します。
- バージョン番号に同意する。 Claudeが推奨し、あなたが同意する — またはあなたが望むものを指定するだけ。どちらにせよ、番号は作業が始まる前に確定し、決定はClaudeではなくあなたのものです。
- Claudeがブランチを作成する —
git checkout -b v1.03。 - あなたがブランチで作業を行う。 コミットはそこに着地し、他のどこにも着地しません。
- ClaudeがブランチをGitHubにプッシュする。
- Claudeがプルリクエストを開く。
- あなたがGitHubでレビューして承認し、マージする。 これがデプロイです。プロダクションが変更される唯一の瞬間であり、常に人間の判断です。
git checkout mainしてからgit pullする。 これをスキップしないでください。ローカルのmainは1回のマージ分だけ遅れており、古くなったmainから次のブランチを開始すると、分岐、幻の競合、そしてfast-forwardを拒否するgit pullが発生します。- 次のバージョン番号でステップ1から繰り返す。
Claudeが提案し、あなたが決定し、Claudeが実行する。 バージョン番号、マージ、デプロイはあなたのもの。ブランチ作成、プッシュ、PRの作成はClaudeのもの。あいまいな場合は、Claudeが質問します。
うまくいくバージョン命名: パッチ（コピー、設定、小さな修正）には v1.0x、マイナーな作業（新しいページ、新機能）には v1.x、再設計には v2.x。
維持する価値のある2つのレビューゲート:
- 各コミットだけでなく、マージ前にブランチ全体の差分をレビューする。 個々には問題ないコミットでも、組み合わさると実際のバグになることがあります。ブランチポイント以降のすべてを読む」パス（理想的には2番目のレビュー担当者または新しいエージェントによる）は、タスクごとのレビューでは構造的に見逃されるものをキャッチします。
- ユーザーデータを収集するデプロイの前に、セキュリティレビューを実行する。 フォーム処理ブランチでの1回のレビューで、生のオブジェクトスプレッドにより訪問者がサーバー管理フィールドの値を送信できるという実際の脆弱性を発見しました。これをゲートとして扱い、おまけとして扱わないでください。
2. 実際のデプロイパイプラインがある場所でホストする
AWS Amplifyはうまく機能します。低トラフィックのランディングページをカバーする無料枠と、それを超えると少額の請求があります。現在の条件を確認してください — AWSは2025年に無料枠を再編成しました。Netlify、Vercel、Cloudflare Pagesも同じ形を提供しています。
本当の利点はデプロイパスです。PRをマージすれば、サイトが再構築されてライブになります。
リポジトリをホストに接続する これは人々が行き詰まるステップであり、設定ファイルではなくクリックパスです。ホストのコンソールで、新しいWebアプリを作成 → GitHubアカウントに対して承認 → リポジトリとmainブランチを選択 → ビルド仕様を検出 → 最初のデプロイが実行されます。以降、そのブランチへのプッシュごとに再構築されます。サイトが単一の「Hello」ページのうちにこれを行い、壊れたパイプラインのデバッグにコストがかからないようにします。
初日、安いうちにセットアップする:
mainからの自動デプロイ。- HTTPS付きのカスタムドメイン。
- 請求アラーム。 クラウドアカウントにカードを紐付けたところです。驚くような数字で予算アラートを設定しましょう — 2分で完了し、低確率の厄介な驚きをメールに変換します。
- セキュリティヘッダー — 静的ホストはデフォルトで何も提供しません。
- コンテンツハッシュされたビルドアセットへの長期キャッシュ
Cache-Control。簡単で永続的で、何もブロックしないため永遠に延期されます。
ドメインとDNS — 落とし穴は予測可能です:
- ベアドメインはCNAMEを使用できません —
www.example.comは使用できますが、example.comは使用できません。DNSプロバイダーのALIAS/ANAMEレコードまたはホスト自身のapexオプションが必要です。正規URLにwwwを含めるかどうかを早期に決定し、もう一方をリダイレクトします。 - HTTPS証明書は検証のためにDNSレコードを必要とし、そのレコードが解決されるまで発行されません。DNS変更には、それが間違っていると判断する前に数時間かけてください。伝搬遅延はまったく障害のように見えます。
実際に時間を浪費するデプロイの落とし穴:
- どの部分が自動デプロイされ、どの部分がされないかを正確に把握する。 スタックの一部（サーバーレス関数、バックエンド、ワーカー）が別の手動コマンドでデプロイされる場合は、それを
CLAUDE.mdに大文字で記述してください。古典的なサイレント障害は、表示されるサイトは更新されるがバックエンドは更新されず、すべてが正常に見えるブランチをマージすることです。 - 自動デプロイは最後のチェックポイントを削除します。 マージからデプロイでは、PRレビューがゲートです。検証はマージの前に行う必要があり、後ではありません。
- ビルドホストでの
npm ciは、ローカルのnpm installよりも厳格です。 新しいnpmではローカルで正常にインストールされるロックファイルがpackage.jsonと微妙に同期していないと、ホストの古いnpmでビルドが失敗します。ビルドがホストで失敗するがローカルでは失敗しない？最初にロックファイルを疑ってください。 - ランタイムをビルド仕様で固定し、バージョンファイルだけに頼らない。
.nvmrcだけでは確実に尊重されません — ビルドコマンドでもバージョンマネージャーを呼び出してください。 - 新しい環境変数は、それを読み取るコードとは別に、ホストのコンソールで追加する必要があります。 これは驚くほど頻繁な「なぜ壊れているのか」の答えです。
- Content-Security-Policyはあなたを噛むヘッダーです。 ページが実際に通信するすべてのサードパーティオリジン（アナリティクス、タグマネージャー、ピクセル、フォント、フォームエンドポイント）は、適切なディレクティブで許可リストに登録する必要があります。そうしないと、ローカル開発では完全に機能しているのに、プロダクションでサイレントにブロックされます。症状：「トラッキングはローカルで機能し、ライブでは何も発行しない。」他の何かをデバッグする前に、ブラウザコンソールでCSP違反を確認してください。
- ソースファイルではなく、デプロイされたアーティファクトに対して検証する。 実際のプロダクションレスポンス（
curl -I、ブラウザ開発ツール）を検査して修正を確認し、それを生成するはずだった設定を読むのではありません。「変更が実際にデプロイされたか」についても同様です — マージが発生したことを確認するだけでなく、ビルドID/タイムスタンプを確認してください。
フォームが実際に送信する方法
静的ホスティングにはバックエンドがありません。静的なページの単純な<form>は何も有用なことをしません — これは初日に人々を驚かせ、それがページの全体のポイントです。3つの現実的なオプション:
| オプション | 適している場合 | 注意点 |
|---|---|---|
| ホスト型フォームサービス | 今日中に動作させたい場合 | ボリュームあたりの月額コスト; そのブランディング; データは彼らと共に存在する |
| サーバーレス関数（Lambda、Netlify/Cloudflare Functions） | 制御とほぼゼロコストが必要な場合 | 検証、スパム、CORSを自分で管理する |
| CRMの埋め込みフォームまたはWebhook | リードがCRMに届く必要がある場合 | 埋め込みの重さとスタイルの制限; 読み込みが遅いことが多い |
どれを選んでも:
- CORSが最初のエラーになります。 ページとは異なるオリジンにあるサーバーレスエンドポイントは、そのオリジンを明示的に許可リストに登録する必要があります。そうしないと、ブラウザはリクエストが送信される前にブロックします。ローカルホストも許可リストに追加してください。そうしないとローカルでテストできません。
- ハニーポットフィールドを追加する（人間が記入せずボットが記入する隠し入力）そしてそれを記入したものをすべて拒否します。最も安価なスパムフィルターです。
- 生のリクエストボディをそのままデータベース書き込みにばらまかないでください。 それが、訪問者がサーバー側で制御する予定のフィールドを設定してしまう方法です。必要なフィールドを明示的に選び出してください。
- 可能であればエンドポイントをウォーム状態に保つ。 コールドスタートするサーバーレス関数は、ページ上で最も重要な瞬間 — 送信を押す — を壊れているように感じさせます。
3. Claudeにブランドキットを渡す — そしてそれを強制的にロードさせる
これはリストの中で最もレバレッジの効くものです。最低限、キットには以下が含まれます:
あなたのオファー · ターゲット市場/クライアントプロファイル · メッセージング戦略 · カラー · フォント · ロゴ
フォルダ（brand/）に配置します。テンプレート: starters/brand-kit/brand.md。
そして自動的にロードされるようにします。 CLAUDE.mdの「ブランドキットを読め」という指示は助言に過ぎません — 一貫性なく従われます。ファイルをcatでコンテキストに入れるSessionStartフックはオプションではなく、スキップされません。この1つの変更が、「時々ブランドに沿う」と「デフォルトでブランドに沿う」の違いです。starters/settings.jsonを参照。
セッション開始時にロード: ブランドキット、短いアーキテクチャドキュメント（サイトの構築、ホスティング、デプロイ方法）、および最新のセッションログ。
適切に構造化する:
- 「ブランドの見た目」と「ブランドの話し方」を分ける。 常にオンにするファイルはスリムに保つ — パレット、フォント、ロゴ、オファー、オーディエンス。より深いボイス/メッセージング資料は「コピー作業時にこれを読め」として参照する。自動ロードされるものはすべて、すべてのセッションで永遠にコンテキストを消費します。
- 色には役割を与え、単なる16進コードではない（「プライマリーアクセント — メインCTAに使用」）。役割は、Claudeが必要なときに色を発明するのを防ぐものです。ルールを明確に述べてください: キット外の色はどこにも現れません。テンプレートやジェネレーターからのブランド外のデフォルトは、そうしないと静かに忍び込みます。
- 2〜3の前後のトーンの例は、形容詞のリストよりも声を速く教えます。
- メッセージングが商用機密の場合はgitignoreする が、それでも
CLAUDE.mdから参照する — 戦略や価格をリポジトリに公開せずに一貫したロードを実現します。 - 外部と同期されたブランドドキュメントは古くなります。 共有ドライブからコピーされたボイスやオーディエンスのドキュメントは、コピーパスの前にソースと再検証してください — マーケティング上の決定は、ドキュメントに戻ってこない会話で行われることがあります。
ブランドキットが強制すべきコピーの規律:
- メールをキャプチャすることが仕事のページで、「サインアップ不要/メール不要」を約束しない。 フォームが現れるまでは摩擦を減らしているように読めますが、その後は信頼が必要なまさにその瞬間に矛盾します。代わりに時間、コスト、見返りについて安心させてください —「2分 · 無料 · 結果をすぐにメールでお届け。」
- オファーが変更されるたびに、安心させるマイクロコピーを再監査する。 これはページバリアント間でコピーされ、それが書かれたオファーよりも長生きします。まさに役立つように聞こえるからです。
- 広告の約束、ページの約束、フォームの実際の要求はすべて一致しなければならない。 不一致は、不一致が導入されたステップではなく、真実が到着するステップでの離脱として現れます。ステップが漏れている場合、その前のステップを疑ってください。
4. 出荷前に確認する
デプロイせずにページを見る2つの方法。両方を使用してください — 対象者が異なります。
ローカル開発サーバー
あなたとClaudeのために、ビルド中に。Claudeは開発サーバーを起動し、実際のブラウザを操作し、結果をスクリーンショットし、コンソールとネットワークログを読むことができます。したがって、「これは正しくレンダリングされるか」はコードを検査するのではなく、見ることで回答されます。
- 同じプロジェクトで2つの開発サーバーを同時に実行しないでください。 既存のプロセスを最初に確認し、別のプロセスを開始する前に強制終了してください — 特にパラレルエージェントがそれぞれ起動する可能性がある場合。
- 自動リトライループを約3回試行に制限する。 開発サーバーとブラウザ自動化をラップした「動作するまでリロードとタイミングの変更を続ける」オープンエンドのループは、単なる煩わしさではなく、真のリソース枯渇リスクです — マシンを完全にクラッシュさせたことがあります。
- クリーンアップを信頼するのではなく検証する。 「サーバーを停止してタブを閉じた」は他の主張と同様に検証されていない主張です — プロセスリストを確認してください。
- ローカルが意図的にプロダクションと異なることを期待する。 実際のアナリティクスIDやライブAPIエンドポイントの背後にあるものは、通常ローカルではノーオペレーションです。これは予期された動作であり、バグではありません — 数週間ごとに再診断されないように文書化してください。
- エンドツーエンドテストはデフォルトでlocalhostを指すようにし、実際のデプロイ済みURLを指すことは意図的な別のアクションにしてください。そうしないと、ルーチンテストの実行がプロダクションに対して実際の送信を行います。
Claude Design (claude.ai/design)
他のすべての人のために。ClaudeはページをClaude Designプロジェクトにプッシュでき、クライアント、デザイナー、または非技術的なパートナーがブラウザで視覚的にコピーとレイアウトを編集できる共有可能なURLを提供します。ローカルセットアップは不要です。ページが実際のサイトに配線される前の承認に最適です。
1つのハードルール: Designにブラインド書き込みを決してしない
Claude Designプロジェクトに何かを書き込む前に、Claudeは現在のリモートバージョンを取得し、差分を確認し、上書きする前にあなたに確認しなければならない。 毎回。
Design側にはバージョン履歴、元に戻す機能、ゴミ箱はありません — キャンバスファイルは、追跡されていないローカルファイルよりも壊れやすいです。共同編集者の編集内容のブラインド上書きは永久に回復不可能であり、すでに手書きのコピーで一晩中費やしたことがあります。
- ページを自己完結型の静的HTML/CSS/JSとして作成する。