Claude CodeでLPをCMSに実装する — コピー確定後のコード化と反映の流れ
コピーが固まったランディングページを、Claude CodeでHTML/CSSに落とし、WordPressやWebflowに反映するまでの役割分担と手順をまとめます。
LP(ランディングページ)の実装は、コピーが固まった後の作業をClaude Codeに寄せると進めやすくなります。文章の推敲はclaude.ai側で終え、確定した原稿をコードとCMSの設定に変換する部分だけをClaude Codeが受け持つ分担です。ここでは、その一連の流れをWordPressとWebflowの2つの反映先に分けて説明します。
LP実装でClaude Codeに任せる範囲
Claude Codeは、コードベースを読み、ファイルを編集し、コマンドを実行する開発向けのエージェントです。ターミナル、IDE、デスクトップアプリ、ブラウザで動きます。つまり得意なのは、手元のリポジトリにあるHTML・CSS・テンプレートを書き換え、結果を確かめる作業です。
コピーの検討は別の場所で済ませておきます。役割は次のように切ると混線しません。
| 工程 | 担当 | 成果物 |
|---|---|---|
| ターゲットと訴求の整理、見出し・本文の推敲 | 担当claude.aiなどの対話 | 成果物確定コピー(Markdown等) |
| セクション構成の決定 | 担当人が判断 | 成果物ワイヤー(箇条書きで可) |
| HTML/CSS/テンプレート化 | 担当Claude Code | 成果物リポジトリ内のコード |
| 見た目の検証 | 担当Claude Code + ブラウザ | 成果物スクリーンショットと差分メモ |
| CMSへの反映 | 担当Claude Code(MCP)または人 | 成果物公開前プレビュー |
この分担のポイントは、コピーを「確定したファイル」として渡すことです。コピーを直しながらコードも書かせると、どちらの変更か分からなくなります。コピーが変わるたびにコード側の差分も追いづらくなるため、原稿はcopy/lp-main.mdのような1ファイルに固めます。
作業ディレクトリとCLAUDE.mdを先に用意する
最初に、LP専用のディレクトリを作ります。原稿・デザイン素材・出力コードを分けておくと、Claude Codeへの指示が短く済みます。
mkdir -p lp-project/{copy,assets,src}
cd lp-project
git init
claude起動したら/initでCLAUDE.mdの雛形を作らせます。CLAUDE.mdは、Claude Codeが毎回の会話の冒頭で読むファイルです。ベストプラクティスでは、コマンドや規約のうちコードから推測できないものだけを短く書くことを勧めています。LPの場合は、次のような内容が候補になります。
# LP実装ルール
- コピーは copy/lp-main.md が正。文言を勝手に変えない
- CSSはBEM風のクラス名。インラインstyleは使わない
- 画像は assets/ に置き、altを必ず付ける
- ブレークポイントは 768px と 1024px の2つだけ
- 変更後は必ず preview のスクリーンショットで確認する
# 反映先
- WordPress: block themeの templates/ と theme.json を編集
- Webflow: MCPサーバー経由で操作(手作業のDesigner編集と混ぜない)「文言を勝手に変えない」の1行は、LPでは効果が大きい項目です。放置すると、見出しの言い回しがコード化の途中で少しずつ変わることがあります。ルールは短く保ちます。長すぎるCLAUDE.mdは指示が埋もれるので、消しても間違いが増えない行は削るのが基本です。
コピーからHTML/CSSを組み立てる
コードへの変換は、一度に全部を頼まず、構成から段階を踏みます。ベストプラクティスにある「調べる、計画する、実装する」の順が、LPにもそのまま使えます。
- 確定コピーを読ませ、セクション構成(ヒーロー、課題、機能、実績、料金、CTA)の案を出させる
- 案を人が直してから、HTMLの骨格だけを作らせる
- CSSを当てる。デザインカンプがあれば画像として貼る
- レスポンシブ調整と細部の修正を重ねる
最初の指示は、次の形が扱いやすくなります。
@copy/lp-main.md を読んで、LPのセクション構成案を出して。
まだコードは書かないで。各セクションの見出しと、
使うコピーの範囲を対応させた表にして。構成に合意したら、骨格の実装に進みます。デザインカンプがある場合は、画像をそのまま貼り付けられます。「この画像を実装して。結果のスクリーンショットを撮って元画像と比べ、差分を列挙して直して」という指示が、検証つきの依頼の例として挙げられています。
過剰な実装は、LPでよく起きる失敗です。フレームワークやアニメーションのライブラリを頼まれていないのに足し始めることがあります。防ぎ方はClaudeの過剰実装を防ぐプロンプトの書き方で扱っています。LPは静的なHTML/CSSで足りる場面が多いため、使う技術を最初に固定しておくと安定します。
スクリーンショットで見た目を検証する
見た目の確認は、人が毎回ブラウザを開いて目視すると往復が増えます。Claude CodeにはChrome連携があり、ローカルで動かしているページを開いて結果を確かめさせられます。Chrome連携の機能一覧にも、Figmaのモックから作ったUIをブラウザで開いて一致を確かめる「デザイン検証」が載っています。
起動はフラグ1つです。
claude --chrome使うには条件があります。
- Chrome拡張機能(バージョン1.0.36以降)が必要
- Pro、Max、Team、Enterpriseのいずれかの直接契約プランが必要
- APIキーや
claude setup-tokenのトークンで認証している場合、Chrome連携は有効にならない - Amazon Bedrockなどのサードパーティ経由では使えない
- WSLではサポートされない
この条件に当てはまらない環境では、ローカルサーバーを立て、自分でスクリーンショットを撮って貼る運用に切り替えます。貼り付けた画像を比較させる方法は、Chrome連携がなくても使えます。
検証を頼む文面は、見るべき観点を絞ります。
localhost:4321 を375px幅と1280px幅で開いて、
ヒーローのCTAボタンが画面内に収まっているか確認して。
はみ出している場合は原因のCSSを直して、もう一度確認して。ベストプラクティスは、確認方法を渡すことを最初の工夫として挙げています。テストやスクリーンショットのように、Claudeが読み取れる合否があると、Claudeは自分で確かめて直す反復に入ります。人が毎回の確認役にならずに済みます。
編集のたびに自動で検査するHooksを足す
「文言を勝手に変えない」のような規則は、CLAUDE.mdに書いても助言にとどまります。毎回必ず実行したい処理には、Hooksを使います。CLAUDE.mdが助言であるのに対し、Hooksは決定的に実行される点が違いです。
たとえば、HTMLを編集するたびに検査スクリプトを走らせる設定は、.claude/settings.jsonに次のような形で書けます(構成例です。スクリプト名は各自の環境に合わせます)。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "./scripts/check-lp.sh" }
]
}
]
}
}check-lp.shには、画像のalt欠落や、コピーファイルにない見出しが混ざっていないかの簡単な照合を入れておけます。設定の全体像はClaude Code Hooksの解説に、編集後の自動修正の型はPostToolUse hookのLint自動修正にあります。
Claude自身にHooksを書かせる使い方もあります。「HTMLの編集後にリンク切れを検査するhookを書いて」と頼み、生成された設定を/hooksで確認する流れです。
WordPressに反映する場合
WordPressは、テーマの作り方で反映の道筋が変わります。公式のテーマハンドブックによると、ブロックテーマはHTMLベースのブロックテンプレートと、theme.jsonによるグローバルな設定・スタイルで構成されます。クラシックテーマはPHPベースのテンプレートで、現在も使われています。
| 反映先 | Claude Codeが編集するもの | 向く状況 |
|---|---|---|
| ブロックテーマ | Claude Codeが編集するものtemplates/のHTML、theme.json | 向く状況新しくLP用テーマを作る、既存のブロックテーマを改修する |
| クラシックテーマ | Claude Codeが編集するものPHPテンプレート、CSS | 向く状況既存のクラシックテーマにLP用テンプレートを足す |
ブロックテーマなら、Claude Codeの編集対象はHTMLとJSONのファイルです。手元で組んだLPのHTMLを、テンプレート側のブロックマークアップに移す作業が中心になります。theme.jsonには、色やタイポグラフィのトークンを定義できます。LPのCSSに書いたブランドカラーをtheme.jsonに寄せておくと、後からサイト全体のスタイルと揃えやすくなります。
依頼の文面は、次のようになります。
src/index.html のLPを、このブロックテーマの
templates/page-lp.html に移して。
CSSの色とフォントサイズは theme.json の値として定義し直して。
既存の他のテンプレートは触らないで。「既存の他のテンプレートは触らないで」のような範囲指定は、既存サイトに手を入れる場面で欠かせません。生成後は必ず差分を確認します。
実サイトへの反映は、ステージング環境を経由します。ファイルを配置する方法は、SFTP、Gitによるデプロイ、テーマのZIPアップロードなど、契約しているホスティングによって異なります。ここはClaude Codeの機能というより、運用環境の手順です。本番へのデプロイ操作を自動で許可する設定は避け、権限は/permissionsで必要なコマンドだけ許可します。信頼できる操作だけを事前に許可する使い方が基本です。
WordPressのREST APIには、投稿や固定ページを操作するエンドポイントがあり、認証手段としてApplication Passwordsも用意されています。LPの固定ページの中身をAPI経由で更新する方法もありますが、本記事ではテーマのファイル編集を軸にしています。プラグイン側の開発はClaude CodeでWordPressプラグイン開発を始めるで扱っています。
Webflowに反映する場合
Webflowには公式のMCPサーバーがあります。Claude Codeを含むAIツールをWebflowのプロジェクトに直接つなぎ、ページの作成やCMSの操作を任せられる仕組みです。ドキュメントでは、次のような操作が対象とされています。
- セクションやグリッドなどのレスポンシブなレイアウトの作成
- 要素の追加・並べ替え・編集と、クラスやCSSプロパティの管理
- コンポーネントの作成と管理
- サイト単位・ページ単位のカスタムコードの読み書き
- CMSコレクションの管理
接続はClaude CodeのMCP追加コマンドで行います。書式は次の通りです。
claude mcp add --transport http <name> <url><url>にはWebflowのドキュメントに記載されたMCPサーバーのURLを入れます。接続時に、Webflowの認可を通します。1回の認可で権限が付くのは1つのワークスペースだけです。別のワークスペースを使うときは、再度認証します。
MCP経由の操作は、Webflowの既存の権限とロールの範囲内で動きます。サイトごとに用意できるエージェント向けの指示(Agent Instructions)で、そのサイトでの作業方針を伝えることもできます。
一方で、ドキュメントに載っている制限を先に知っておくと、実装の途中で止まらずに済みます。
- 従来型(Classic)のインタラクションは扱えず、GSAPベースのものだけが対象
- 新規のローカライズ済みCMSアイテムは作れない(既存の読み取りと更新は可能)
- サイトやワークスペースのアクセス設定(ユーザー追加やロール割り当て)は変更できない
- 要素のスナップショット取得など一部の機能は、Webflow Designerを開きBridge Appを接続している必要がある
- ブランチ操作(作成からマージまで)にはEnterpriseプランが必要
- リモート配信のGoogle FontsやAdobe Fontsは扱えず、アップロード済みのカスタムフォントのみが対象
この分担を踏まえると、Webflowでは次の流れが取りやすくなります。ヒーローや料金表のような構造はMCPでWebflow上に組み、独自のCSSやスクリプトが必要な部分だけ、リポジトリのコードとして管理しカスタムコードに反映します。CLAUDE.mdに「Designerでの手作業編集とMCP操作を混ぜない」と書いたのは、この境界を崩さないためです。両方から同じ要素を触ると、どちらの変更が正か判別できなくなります。
MCPサーバー全般の追加や設定は、Claude Code側の共通の仕組みです。Webflow以外のCMSにMCPサーバーがあるなら、同じ手順で接続できます。
公開前チェックの型
反映が終わったら、公開する前に確認項目を固定して回します。次の表は、LPで確認しやすい項目と、Claude Codeに任せられる度合いをまとめたものです。
| 確認項目 | 任せ方 | 注意点 |
|---|---|---|
| コピーとの一致 | 任せ方原稿ファイルと出力の文言を照合させる | 注意点改行や記号の差は人が判断 |
| モバイル表示 | 任せ方375px幅のスクリーンショットで確認 | 注意点Chrome連携の条件を満たす場合のみ自動 |
| 画像のalt | 任せ方hookまたはスクリプトで欠落を検出 | 注意点内容の妥当性は人が見る |
| フォームの送信先 | 任せ方設定値を読み上げさせて人が照合 | 注意点実送信テストは人が行う |
| 計測タグ | 任せ方挿入位置の確認まで | 注意点実際の計測はCMS上で確認 |
フォームの送信先や計測タグは、間違うと被害が大きく、後から気づきにくい項目です。ここは「Claude Codeが見た」を根拠にせず、公開前に人が実機で確かめます。
つまずきやすい点
コピーが途中で変わる: CLAUDE.mdで原稿を正と定めても、コード生成の途中で言い換えが混ざることがあります。差分を確認するときは、コード側の文言と原稿を機械的に突き合わせると気づけます。
CMS側の編集がリポジトリに戻らない: WordPressやWebflowの画面上で誰かが直すと、リポジトリのコードとずれます。どちらを正にするかを、運用の最初に決めます。
Astroなど別の静的サイトジェネレーターに寄せたくなる: 本文が長くなければ、CMSに載せる前段としてまず静的なLPを作る選択肢もあります。手順はClaude CodeでAstroブログを作ると共通する部分があります。ただし、CMSへ反映する前提のLPでは、最終的な配置先の制約(テンプレート形式やクラス名の扱い)に合わせて書く必要があります。
1回の指示が大きすぎる: 「LP全体を作って」と頼むと、確認のしようがない大きな差分が返ります。セクション単位で区切り、1つ終わるごとに確認します。
まとめ
LPの実装は、コピーの確定とコード化を分けると進めやすくなります。コピーはclaude.aiの対話で固め、確定原稿をリポジトリに置き、Claude Codeは原稿を正としてHTML/CSSやテンプレートを組みます。CLAUDE.mdで規約を、Hooksで機械的な検査を、Chrome連携やスクリーンショットで見た目の確認を受け持たせると、人の確認は公開前の判断に集中できます。
反映先がWordPressのブロックテーマなら、編集対象はHTMLテンプレートとtheme.jsonです。Webflowなら、公式のMCPサーバーでページ構成とCMSを直接操作できますが、Classicのインタラクションやアクセス設定など、対象外の領域があります。どちらの場合も、フォームの送信先や計測タグは人が実機で確かめる項目として残します。