WordPress制作で使いやすいAIは？

WordPress制作で使いやすいAIは？という視点で、用途や条件ごとに検討候補になるAIの考え方を整理します。結論だけでなく、向く条件と向かない条件も分けて整理します。

確認日 2026年9月17日AIものさし編集部

Claude

WordPress制作でAIを使うとき、CSSを1行書かせるだけなら大きな差は出にくいです。難しくなるのは、テーマ構造、PHP、JavaScript、ブロック、プラグイン、既存サイトの挙動まで一緒に見なければいけない場面です。

先に整理すると、Git管理しているテーマ・プラグインを複数ファイルで改修したいならCodex、ローカル環境のログやコードをターミナル中心で追いたいならClaude Code、Google系のエージェントIDEでコードベースを見ながら進めたいならAntigravity系が候補です。WordPress実装品質の1位は、同じ案件・同じ要件で比較していないため断定しません。

結論：WordPressは「コードを書けるか」より「既存サイトを壊さず検証できるか」で選ぶ

表は横にスクロールできます

制作スタイル	まず見る候補
Git管理したテーマ・プラグインをまとめて改修したい	Codex
ローカル環境でログ・PHP・JSを追いながら直したい	Claude Code
Google系のエージェントIDEで開発したい	Antigravity系
CSSや短いPHPだけ相談したい	ChatGPT / Claude / Geminiのチャットでも候補
一番WordPressに強いAIを知りたい	同一案件・同一要件で実測

Codexはテーマ・プラグインの複数ファイル改修に向く候補

WordPressのカスタム制作では、functions.phpだけ直せば終わるとは限りません。テンプレート、CSS、JavaScript、ビルド設定、独自プラグインなどへ変更が広がることがあります。

Codexはリポジトリを扱うコーディングエージェントなので、ファイル単体ではなく、関連コードを調べながら複数ファイルの変更、テスト、レビューまで進める候補になります。

特にGitでテーマやプラグインを管理しているなら、AIが出したコードをコピーするより、差分として何が変わったかを確認できる形にした方が扱いやすいです。

ただし、WordPressの管理画面や本番DBへ直接変更を入れる仕事まで無条件で任せる、という意味ではありません。コード変更と本番反映は分けます。

Claude Codeはローカル環境で原因を追いながら直したい場合の候補

Claude Codeは、コードベースを読み、ファイル編集、コマンド実行、失敗したテストの調査などをターミナルから進められます。

WordPressでは、PHPエラー、フックの競合、JavaScript、ビルド、プラグイン同士の影響など、原因が一つに見えないことがあります。ローカル環境でdebug.logや関連ファイルを確認しながら原因を追う使い方と相性を考えやすいです。

WordPress公式も、テーマ開発では本番サイトと分けた開発環境を用意し、デバッグを有効にしてエラーを確認することを案内しています。

つまり、AIへ「直して」と投げる前に、再現できる開発環境とログを用意することが先です。

Antigravity系はIDE内でWordPressコードを見ながら進めたい場合の候補

Google Antigravity 2.0には、スタンドアロン環境、Antigravity IDE、CLIなどがあります。Antigravity IDEではコードベースを理解したエージェントと会話しながら、説明、生成、修正を進められます。

PHP、CSS、JavaScriptが混在するWordPress案件でも、別チャットへコード断片を貼るより、プロジェクト全体を見せた方が文脈は渡しやすくなります。

ただし、IDEがコードを理解できても、WordPress固有の運用ルールまで自動的に正しく判断するとは限りません。公式ドキュメント、既存テーマの設計、利用中プラグインの仕様へ戻って確認します。

WordPressではAIより先に「どの構成か」を確認する

WordPress公式のTheme Handbookでは、現在もブロックテーマとクラシックテーマを分けて説明しています。クラシックテーマは主にPHP、JavaScript、CSSを使い、ブロックテーマではHTMLやtheme.jsonなどの比重が大きくなります。

AIへ依頼する前に、

ブロックテーマ / クラシックテーマ
子テーマか独自テーマか
独自プラグインの有無
WordPress / PHPのバージョン
ビルド環境
利用中の主要プラグイン
ローカル / ステージング / 本番のどこで作業するか
WP_DEBUGやログの状態

を整理します。

また、WordPress公式のPlugin Handbookには「WordPressコアを直接編集しない」という基本原則があります。機能追加や変更はテーマやプラグイン側で行うのが前提です。

AIが「このコアファイルを直接直せば動きます」と提案しても、そのまま採用しない。こういうWordPress固有の前提を人が持っておく必要があります。

本番サイトへの変更は別工程にする

WordPressは、コードだけでなくDBや管理画面の設定も動作に影響します。

そのため、

ローカルで再現する
差分を確認する
PHPエラーやログを見る
テーマ・プラグインの基本チェックを行う
ステージングで表示と管理画面を確認する
バックアップと戻し方を確認してから本番へ反映する

という流れを残します。

AIで実装速度が上がっても、本番確認を省略していい理由にはなりません。

AIものさし編集部の判断

WordPress制作では、モデル名よりWordPress固有の構造を踏まえ、ローカルで変更→デバッグ→確認できるかで選ぶ方が実用的です。

Git管理したテーマ・プラグインを広く改修するならCodex。ローカル環境のログやコードをターミナル中心で追うならClaude Code。Google系のエージェントIDEへ寄せるならAntigravity系。

実装品質、WordPress理解、バグ率、作業速度は同じ案件で試していません。比較するなら同じテーマ・同じ要件・同じ検証項目で確認します。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

Claude
公式サイトを見る Tool詳細を見る比較を見る

WordPressの依頼前に作る「サイト構成カード」

WordPress案件では、同じ「ヘッダーを変える」でもブロックテーマ、クラシックテーマ、子テーマ、ページビルダーで触る場所が違います。AIへコードを渡す前に、構成をカードにしておくと、違う種類のテーマや別環境向けの提案を混ぜにくくなります。

表は横にスクロールできます

項目	記録例
テーマ	ブロック / クラシック、親 / 子、自作 / 配布
機能の置き場	テーマ、子テーマ、独自プラグイン
実行環境	WordPress・PHPの版、ローカル / ステージング
再現手順	管理画面の操作、対象URL、入力値
影響範囲	表示テンプレート、投稿種別、権限、外部連携
戻し方	Gitの基準点、DBとuploadsのバックアップ

たとえばメニュー表示の変更を頼むなら、「ブロックテーマか」を先に確認します。ブロックテーマではサイトエディター上のテンプレートやtheme.jsonが関わる可能性があり、クラシックテーマではPHPテンプレートやフックが中心かもしれません。AIが最初に出したファイル名を正解と見なさず、既存テーマの構成と公式ハンドブックを照合します。

ステージングで確認する順番

本番の前に、次の順で確認します。

Gitの差分を見て、WordPressコアや無関係なプラグインを変更していないか確認する。
PHPの構文、テーマ・プラグインの基本チェック、lintや既存テストを実行する。
ステージングで対象ページだけでなく、ヘッダー・フッター、投稿一覧、管理画面も見る。
ログを確認し、画面に出ないPHP NoticeやJavaScriptエラーが増えていないか調べる。
画像、フォーム、権限別表示、キャッシュ後の表示など、依頼に関係する状態を再現する。
バックアップと切り戻し手順を確認したあと、人が本番反映を判断する。

表は横にスクロールできます

AIの提案	採用前の確認
コアファイルを編集する	コア更新で失われるため、テーマ / プラグインで実現できないか
functions.phpへ処理を追加する	既存フックと読み込み順、子テーマの有無
プラグインを一時停止する	本番データや決済・認証に影響しない検証環境か
データベースを直接更新する	対象件数、バックアップ、ロールバック、権限
表示だけ確認して完了する	ログ、モバイル、管理画面、キャッシュ後も確認したか

「サイトが表示された」は最低限の確認です。WordPressのテーマテスト資料が扱うように、投稿、コメント、画像など実際のコンテンツ状態も表示に影響します。テスト用データが少ない環境で一ページだけ見て完了にすると、長いタイトルや空欄、権限違いで起きる崩れを見落とします。

変更の種類ごとにテスト範囲を決める

サイトのヘッダー変更と、決済プラグインの処理変更を同じ手順で確認する必要はありません。対象に応じて、最低限のQAを組み替えます。

表は横にスクロールできます

変更	追加で見るところ
テーマの見た目	PC / mobile、長い見出し、投稿・固定ページ、画像なし
テンプレートやフック	投稿種別、ログイン状態、権限、空データ
プラグインの機能	有効 / 無効状態、他プラグインとの競合、入力検証
管理画面	編集権限、保存後の再読込、エラー時のデータ保持
DBや移行処理	影響件数、バックアップ、再実行安全性、復元手順

不具合が出たら、まずテーマ変更とプラグイン変更を同時に入れないようにします。変更を一つずつ戻すか、差分を分けて再現し、ログの先頭に出た原因候補を確認します。AIに「直った」と言われても、同じ操作を再実行して症状が消えたこと、関連機能が壊れていないことを人が確かめます。

検証環境を用意できない、またはバックアップから戻せるか分からない場合は、本番変更を急がず、AIには調査・コード案・チェック項目までを頼みます。これはAIの性能ではなく、変更の影響範囲と復元可能性で決まる運用判断です。