WordPressに実装する——Claude DesignのHTMLをテーマに落とし込む罠と回避策

Claude DesignからHTML/CSSを出力させると、一見完璧なコードが出てくる。ブラウザで単体表示すれば問題ない。でもWordPressに突っ込むと、たいてい崩れる。これ、最初にやらかしたときはかなり萎えた。

なぜWordPressでは崩れるのか

原因は明快だ。WordPressにはテーマのstyle.cssやブロックエディターのスタイルシートがあって、Claude Designが生成した汎用CSSと衝突する。h1のサイズが変わったり、ボタンのpaddingがおかしくなったり、フォントが巻き戻ったりする。

Claude Designは「独立したHTMLページ」として設計したコードを出力する。WordPress前提で書いてくれるわけじゃない。ここをわかっていないと、修正の沼にはまる。

※Claude Design: Anthropic Labsが開発したAIビジュアルデザインツール。テキストプロンプトからUI・スライド・マーケ資料などを生成する。

ページビルダー経由のほうがはるかに楽

直接テーマに組み込むより、ElementorやSB Advanced Blocksを使うほうが現実的だった。

手順はこれだけ:

1. Claude Designでデザインを生成するとき「CSSはインラインスタイルで書いてください」と追加指示する
2. ElementorのHTMLウィジェットに貼り付ける
3. クラス名をユニークなプレフィックス付きに変更する（例: .hero → .cd-hero）

Elementorならスタイルのスコープがウィジェット内に閉じやすく、テーマのCSSが干渉しにくい。!importantを乱発しなくて済む。

Gutenbergで使う場合の現実

カスタムHTMLブロックにそのまま貼ると、Gutenbergのエディタースタイルが適用されてプレビューと本番で表示が変わる罠がある。実際、レビュー画面ではきれいに見えたのに、公開したら崩れていた、という体験を一度やった。

対策として効いたこと:

• add_editor_style() のスコープを絞るか、エディタースタイルの干渉を最小化する
• Claude Designに「Gutenberg カスタムHTMLブロック向けに、スタイルはルート要素の属性セレクタで閉じてください」と指示する

ただし正直に言うと、GutenbergとClaude Designの相性はElementorより悪い。作業コストで比べると、ElementorかWPBakeryが使える環境のほうが圧倒的に楽だった。

CSSの衝突を減らすプロンプトのコツ

生成前にこのブロックをプロンプトの先頭に入れると、衝突が大幅に減った。

このHTMLとCSSをWordPress環境で使います。
テーマのデフォルトスタイルとの衝突を避けるため：
- 全クラス名に「cd-」プレフィックスをつける
- グローバルセレクター（h1, p, a など）は直接指定しない
- スタイルのスコープをルートクラス内に限定する
- 外部フォントは @import で内包する（WordPressのenqueueは使わない）

これを入れておくと、手修正が必要な箇所が8割ほど減った感覚がある。残り2割はWordPress固有の問題で、どうしても手作業になる。

※プロンプト: AIへの指示文。Claude Designでは自然言語でデザインを指示する。

向いている用途・向いていない用途

WordPress + Claude Designが噛み合う

• 独立したセクション単位のLP（ヒーロー、CTA、特徴紹介など）
• 既存テーマを壊さずに特設ページだけ作りたいケース
• カスタムHTMLブロックを使う前提のキャンペーンページ

向いていない

• テーマ全体をClaude Designで作り直すアプローチ
• WooCommerceの商品ページへの適用（構造が複雑すぎて衝突が多い）
• マルチサイトで複数テーマをまたぐ実装

WordPressを捨てずにClaude Designを使うなら、「ページ単位で切り分ける」というスタンスが正解だった。テーマ全体を置き換えようとすると、コスト対効果が一気に悪くなる。

※CTA: Call To Action（行動喚起）。ボタンやリンクでユーザーに次の行動を促す要素。※LP: ランディングページの略。特定のCTAに向けて設計されたWebページ。