AIにWordPressテーマを作らせた。ボタンの文字が消えるまでは順調だった。

PR この記事にはアフィリエイト広告のリンクを含みます。リンク経由で申込があった場合、当サイトは報酬を受け取ることがあります。評価は実際に使った結果に基づいて書いています。

AIツール 2026.08.10 CHOCHO LAB

結論から書きます。
AIにWordPressテーマを作らせると、9割は一発で正しく動きます
問題は残りの1割です。

筆者はウェブデザイナーとして15年、CSSを書いて食べてきました。
その人間が、このサイトのテーマをAI(Claude Code)に作らせた記録です。
できあがったものは想像より良く、そして事故り方が人間とは違いました

この記事は「AIにデザインを任せると何が起きるか」の実測記録です。
コードが読めなくても分かるように書きます。

図|制作結果のまとめ(2026.08.06 実測)

出力は速いが、確認は人間がやるしかない

問題なかったこと

  • テンプレート12ファイルの構成
  • レスポンシブ対応(スマホで崩れない)
  • 構造化データ、パンくず
  • PHPの構文エラー ゼロ
  • 指示していない機能の先回り実装
事故ったこと

  • ボタンの文字が消える
  • ダークモードで文字が背景に溶ける
  • 本文の余白が全部潰れる
  • 作った図が編集画面に出ない

そもそも、なぜ既製テーマを使わなかったのか

前提 / 制作時間 約3時間

既製テーマを買わず、
ゼロから作らせた理由

機能を足すより、要らない機能が最初から無い状態のほうが速いと判断しました。

PHP 12ファイル
CSS 約1,200行
制作費 0円


日本のWordPressテーマは高機能です。
ランキング作成、吹き出し、アフィリエイトボタン、目次。
だいたい全部入っています。

ただ、全部入りには代償があります。
使わない機能のコードも読み込まれるので重くなる。
デザインの微調整が、テーマの想定した範囲でしか効かない。
そして「どのテーマを使っているか」がひと目で分かる

今回は、必要な機能だけを持つ軽いテーマを作らせるほうが速いと判断しました。
結果、必要な12ファイルとCSS約1,200行が3時間ほどで揃いました。

指示は日本語の会話だけ

コードの書き方は一切指示していません。
伝えたのは、こういう内容です。

  • 参考にしたいサイトのURL(実際にAIが見に行って構造を分析した)
  • 「白地に極細の罫線でグリッドを作る」「影は使わない」といったデザインの方針
  • 「アフィリエイトリンクがある記事だけPR表記を自動で出して」といった機能要件

色コードもフォント名も、こちらからは指定していません。
AIが参考サイトから読み取って提案し、こちらが確認する流れです。

事故1:ボタンの文字が消えた

TROUBLE 01 / 原因特定 8分

緑のボタンはある。
でも文字が無い

プレビューを見たら、ボタンがのっぺりした緑の板になっていました。文字だけが消えています。

CSSの詳細度
クリックはできる


記事にCTAボタンを置いたときのことです。
プレビューを見ると、緑の角丸ボタンはあるのに、中の文字が見当たりません。

最初はフォントの読み込み失敗を疑いました。
違いました。
文字は存在していて、背景と同じ色になっていたのです。

犯人はCSSの「詳細度」というルール

CSSには、同じ要素に複数の指定が当たったとき、どれを優先するかのルールがあります。
詳細度(Specificity)と呼びます。

ざっくり言うと、より具体的に指定したほうが勝ちます。
今回はこうなっていました。

/* 本文中のリンクは緑にする、という指定 */
.prose a { color: 緑; }

/* ボタンの文字は白にする、という指定 */
.cta__btn { color: 白; }

人間の感覚だと、後から書いた「ボタンは白」が勝ちそうです。
ところがCSSのルールでは、要素名を含む .prose a のほうが強い
結果、ボタンの文字も緑になり、緑の背景に緑の文字で消えました。

この事故が示しているのは、AIの弱点の場所です。
AIはCSSを1つずつ見れば正しく書きます。
しかし「あとで別の指定とぶつかる」ことは、実際に描画してみるまで分からない
そしてAIは、自分が書いた画面を目で見ていません。

対処:ボタンには明示的に上書き指定を足す

.prose a.cta__btn { color: 白; }

指定を1行足しただけです。
ただし、この1行が必要だと気づくには、実際に画面を見る必要がありました。

 

事故2:ダークモードで文字が溶けた

このサイトは、閲覧者の端末設定に合わせて明るい配色と暗い配色が切り替わります。
暗い配色のとき、アクセントの緑は明るい緑に反転します。
背景が暗いので、そうしないと見えないからです。

ここで問題が起きました。
ボタンの文字色が「白」で固定されていたのです。

  • 明るい配色:濃い緑の背景 + 白い文字 → 読める
  • 暗い配色:明るい緑の背景 + 白い文字 → ほぼ読めない

コントラスト比を計算すると約1.9対1でした。
ウェブアクセシビリティの国際基準(WCAG)が求める最低ラインは4.5対1です。
半分にも届いていません。

対処:「アクセント色の上に乗る文字色」も変数にする

色を直接書かず、配色ごとに切り替わる変数を使う形に直しました。
明るい配色では白、暗い配色では濃い緑になります。

これはAIが悪いというより、指示していなかった筆者の設計漏れです。
ただ言えるのは、AIはコントラスト比を自分で確かめないということ。
数値としては知っているのに、自分の出力に適用してくれるとは限りません。

 

事故3:本文の余白が全部潰れた

記事の見た目で「なんとなく読みにくい」と感じ、調べたときのことです。
見出しの下の段落が、見出しにぴったり張り付いていました。

原因はまた詳細度でした。

/* 要素と要素の間に余白を空ける、という指定 */
.prose > * + * { margin-top: 1.5em; }

/* 段落の上下の余白はゼロにする、という指定 */
.prose p { margin-block: 0; }

2つ目の指定のほうが強かったため、段落の余白が全部ゼロになりました。
AIが書いたコードは、1行ずつ読めばどちらも正しいのです。
組み合わさったときだけ壊れます。

これが人間のミスとの決定的な違いでした。
人間は書きながら画面を見るので、この種の事故はその場で気づきます。
AIは全部書き終わってから、まとめて壊れます。

 

事故4:作った図が編集画面に出ない

この記事にも入っている図やイラストは、画像ファイルではありません。
すべてHTMLとCSSで描いています。
画像をアップロードする手間をなくすためです。

ところが、WordPressの編集画面では、それが素のテキストにしか見えませんでした。
公開後のページでは正しく表示されるのにです。

原因は単純でした。
WordPressの編集画面には、テーマのCSSが自動では読み込まれません。
テーマ側で「編集画面でもこのCSSを使う」と宣言する必要があります。

add_theme_support( 'editor-styles' );
add_editor_style( 'style.css' );

2行足すだけで解決しました。
AIはこの2行を最初から書きませんでした。
「表示側が正しく動くこと」しか確認していなかったからです。

 

やってみて分かった、AIにデザインを任せるときのコツ

 

1. 参考サイトのURLを渡すのが一番速い

「シンプルで」「おしゃれに」といった形容詞は、ほぼ機能しません。
URLを渡すと、AIが実際にそのサイトを見に行き、構造を言語化して設計に落とします。

今回も、参考サイトから「カードではなく罫線で区切る」「影を使わない」「タグは黒い丸型」といった特徴を読み取り、それをこのサイトのジャンルに置き換えていました。
そのまま真似るのではなく、要素の役割を移植する形です。

2. 「必ず実際に描画して見せて」と言う

今回の事故4件のうち3件は、実際に画面を描画させた時点で見つかりました。
コードを読むだけでは見つかりません。

AIに作らせるときは、コードを出させて終わりにせず、スクリーンショットまで出させるのが効きます。
そこまでやらせると、AI自身が「ボタンの文字が見えていません」と気づきます。

3. 配色は最初に変数として決めさせる

色を各所に直接書かれると、後から一括で直せません。
最初に「配色は変数にまとめて、明暗2パターンを定義して」と伝えておくと、事故2のような問題を減らせます。

で、既製テーマとどちらがいいのか

 

自作(AIに作らせる)が向くケース

  • デザインに明確な方向性があり、それを再現したい
  • 不要な機能を持ちたくない
  • CSSが読める、または読めなくても検証に付き合える

既製テーマが向くケース

  • ランキングや比較表など、アフィリエイト向け機能をすぐ使いたい
  • デザインより記事執筆に時間を使いたい
  • 不具合が出たとき、公式マニュアルやユーザーコミュニティを頼りたい

正直に書くと、収益化を急ぐなら既製テーマのほうが速いです。
自作テーマには、比較表もランキングも吹き出しも最初は付いていません。
必要になるたび自分(とAI)で作ることになります。

筆者が自作を選んだのは、テーマ制作そのものを検証記事にできると考えたからです。
実際、この記事がその成果物です。

よくある質問

 

Q. コードが読めなくてもテーマは作れますか。

作れます。
ただし「壊れていることに気づけるか」は別問題です。
今回の事故4件のうち、コードを読まずに気づけるのは「文字が見えない」「余白が変」の2件でしょう。
残りは画面を注意深く見るか、指摘されないと分かりません。

Q. 制作にどれくらいかかりましたか。

初回の形になるまで約3時間、その後の修正が2時間ほどです。
ただしこれは筆者がCSSを読めるからで、指示と確認が速いぶん短くなっています。

Q. 既製テーマから自作に乗り換えられますか。

記事の中身はテーマとは別に保存されているので、テーマを切り替えても記事は消えません。
ただし既製テーマ独自の装飾(吹き出しやランキング)を使っていた場合、その部分の見た目は崩れます。
乗り換えるなら記事数が少ないうちが楽です。

Q. AIが作ったテーマは公開して大丈夫ですか。

セキュリティ面では、出力のエスケープ処理などは適切に書かれていました。
ただし筆者が確認したうえで公開しています。
確認せずに公開するのは、内容を読まずに契約書へ署名するようなものです。

まとめ:AIは9割作る。残り1割を見るのが人間の仕事

AIにWordPressテーマを作らせて分かったのは、役割分担の形でした。

AIは、書く速さと網羅性で圧倒的です。
12ファイル、1,200行を数時間で、構文エラーゼロで出してきます。
レスポンシブ対応も構造化データも、言わなくても入っていました。

一方で、AIが苦手なのは「組み合わせたときに何が起きるか」でした。
今回の事故4件は、すべて個々のコードは正しく、合わさったときだけ壊れる種類のものです。

つまり人間に残るのは、書く仕事ではなく見る仕事です。
画面を開いて、おかしいところを指差す。
それだけで、AIは直します。

このテーマを載せているサーバーと、立ち上げ手順は別記事にまとめています。

WordPress MCPでできないこと7つ。詰まった全記録

関連する検証