Codex で WordPress のテーマとプラグインを開発する手順

Codex が WordPress 開発に向いている理由と2026年時点の対応範囲

WordPress の開発は、テーマとプラグインという二種類の拡張を書き分ける作業が中心になる。テーマは見た目とページ構成を、プラグインは機能を担当し、いずれも PHP を軸に HTML・CSS・JavaScript を組み合わせて作る。Codex はこの複数言語が混在するコードを一つの対話の中で扱えるため、「一覧ページのカードデザインを直して」「同時に投稿タイプの登録処理も追加して」といった横断的な依頼にも対応しやすい。テンプレートの作法やフックの名前をうろ覚えでも、Codex に確認しながら進められるので、WordPress 開発特有の学習コストを下げられる点が実務での利点になる（出典: https://openai.com/codex ）。

もう一つの利点は、既存サイトの改修に強いことだ。長年運用してきたテーマは関数が入り組んでいることが多いが、Codex にディレクトリを読ませて「この関数がどこから呼ばれているか教えて」と尋ねれば、影響範囲を整理したうえで修正案を返す。ゼロから作るよりも、既存コードの理解と安全な改修に価値を発揮する場面が多い。

Codex が扱える WordPress の制作物の範囲

Codex は、クラシックテーマ（PHP テンプレート）とブロックテーマ（theme.json ベース）のどちらも扱える。子テーマの作成、カスタム投稿タイプやカスタムタクソノミーの登録、ショートコードの実装、REST API のエンドポイント追加といった定番の拡張は、要件を伝えれば雛形を生成する。プラグインについても、管理画面に設定ページを追加する、フックで既存の挙動を差し替えるといった実装に対応する（出典: https://developer.wordpress.org/plugins/ ）。

一方で、外部サービスとの接続に必要な認証情報の取得や、サーバー側の設定は人が担う領域として残る。Codex は決済連携やメール送信の実装コードを書けるが、対象サービスのアカウント準備やキーの発行は利用者が行う。この分担を最初から意識しておくと、途中で手が止まりにくい。

2026年のモデル更新がもたらした変化

WordPress 開発で Codex が使いやすくなった背景には、モデルとツールの更新がある。2026年に登場した GPT-5.2-codex 系のモデルは、長い PHP ファイルや複数ファイルにまたがる依存関係を追う精度が向上し、テンプレート階層のような WordPress 固有の構造を踏まえた提案が返りやすくなった。あわせて Codex CLI v0.142.0 で強化されたインデックス付きウェブ検索を使うと、公式ドキュメントの関数リファレンスを参照しながら実装できるため、「この関数の引数を確認して使って」という依頼にも根拠を添えて応じられる（出典: https://openai.com/codex ）。

開発を始める前に整えるローカル開発環境と前提情報

Codex に WordPress のコードを書かせる前に、手元でサイトを動かせる環境を用意しておく。本番サイトを直接編集すると、不具合がそのまま公開されてしまうため、まずはローカルで試して確認するのが安全な進め方だ。環境が整っていれば、Codex が生成したコードをすぐに反映してブラウザで結果を見られる。

Step 1: ローカル開発環境を用意する

ローカルで WordPress を動かす方法はいくつかある。手軽なのは Local や wp-env のような専用ツールを使う方法で、数クリックで PHP・データベース・WordPress 本体がそろった環境が立ち上がる。Docker に慣れているなら公式の wp-env が扱いやすく、プロジェクトごとにバージョンを切り替えられる（出典: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-env/ ）。環境を用意したら、テーマなら wp-content/themes、プラグインなら wp-content/plugins の下に作業用フォルダを作り、そのフォルダで Codex を起動する。

Step 2: AGENTS.md にプロジェクトの前提を書く

作業フォルダのルートに AGENTS.md というテキストファイルを置くと、Codex は作業前にそれを読み込んで前提を把握する。WordPress 開発では「WordPress バージョン: 6.x、PHP: 8.2、対象: 子テーマ、コーディング規約: WordPress Coding Standards に準拠、命名接頭辞: myprefix_」のように書いておくと、複数回の指示をまたいでも一貫した書き方が保たれる。規約を明示しておくことは特に効果が大きく、関数名の衝突を避ける接頭辞のルールや、翻訳対応のテキストドメインを毎回そろえてくれる（出典: https://developer.wordpress.org/coding-standards/ ）。あわせて「この方針から外れる場合は理由を添えて提案する」と一文を加えておくと、Codex が独断で規約を崩しにくくなる。

テーマ開発を Codex で進める手順

テーマ開発は、サイト全体の見た目とページ構成を作る作業だ。既存テーマをそのまま書き換えると更新時に上書きされる恐れがあるため、親テーマを継承する子テーマとして作るのが定石になる。Codex にもこの前提を伝えたうえで、骨格から順に組み立てていく。以下では、子テーマの生成からブロックテーマ対応までを段階的に示す。

Step 3: テーマの骨格を生成する

まず「Twenty Twenty-Five を親にした子テーマを作りたい。style.css のヘッダーコメントと functions.php を用意して、親テーマのスタイルを読み込む設定を入れて」と伝える。Codex は style.css に必要なテンプレートヘッダーを書き、functions.php で親テーマのスタイルを読み込むエンキュー処理を生成する。生成後はローカルの管理画面でテーマを有効化し、崩れがないかを確認する。意図と違えば「フォントを Noto Sans JP に変えて」と追加指示を出せば、該当箇所だけが修正される。

Step 4: テンプレート階層に沿って各ページを組む

WordPress は、表示するページの種類に応じて読み込むテンプレートファイルが決まっている。この仕組みがテンプレート階層で、index.php を土台に、single.php で個別投稿、archive.php で一覧、page.php で固定ページというように役割が分かれる（出典: https://developer.wordpress.org/themes/basics/template-hierarchy/ ）。Codex には「個別投稿ページに関連記事の一覧を追加したいので single.php を編集して」のように、対象テンプレートを名指しで伝えると精度が上がる。どのファイルを触るべきか迷うときは「この表示を変えるにはどのテンプレートを編集すべきか」と先に尋ねるとよい。

Step 5: ブロックテーマと theme.json に対応する

近年の WordPress はブロックエディターを中心に据えており、theme.json でサイト全体の色やタイポグラフィ、余白を一括管理するブロックテーマが主流になりつつある。Codex に「theme.json でカラーパレットを5色定義して、本文のフォントサイズを3段階のスケールで設定して」と伝えると、JSON の構造に沿った設定を生成する（出典: https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/ ）。PHP テンプレートを直接書く従来の方法と、theme.json とブロックテンプレートで構成する方法は考え方が異なるため、AGENTS.md にどちらの方式で作るかを明記しておくと、Codex が方式を取り違えにくくなる。

プラグイン開発とセキュリティ対策

プラグインは、テーマに依存せず機能を追加する拡張だ。フックという仕組みを通じて WordPress の動作の途中に処理を差し込むのが基本で、この作法を踏まえたコードを Codex に書かせる。機能追加と同じ比重で重要になるのが、外部からの入力を安全に扱うセキュリティ対策だ。

Step 6: プラグインの雛形とフックを実装する

「問い合わせ件数を管理画面に表示するプラグインを作りたい。プラグインヘッダーと有効化フック、管理メニューへの追加までを myprefix_ 接頭辞で実装して」と伝えると、Codex はプラグイン本体のヘッダーコメントと初期化処理を生成する。WordPress のフックには、処理を差し込む action と値を書き換える filter の二種類があり、Codex には「投稿保存時に action フックで集計を更新して」のように、どちらのフックをどのタイミングで使うかを具体的に指示すると意図どおりに動く（出典: https://developer.wordpress.org/plugins/hooks/ ）。

入力値の検証とエスケープを徹底する

プラグインで最も注意すべきなのが、フォーム入力や URL パラメータなど外部から渡る値の扱いだ。受け取った値はサニタイズ関数で検証し、画面に出力する際はエスケープ関数で無害化するのが WordPress の基本方針になる。Codex に「この設定フォームの保存処理に、入力値のサニタイズと nonce による検証を追加して」と伝えると、sanitize_text_field や wp_verify_nonce を使った処理を組み込む（出典: https://developer.wordpress.org/apis/security/ ）。生成されたコードに対しては「エスケープ漏れがないか確認して」と点検を依頼し、出力箇所すべてで esc_html や esc_url が使われているかを見直すと安全性が高まる。認証情報を含む値をコードに直接書き込まない方針も、あわせて AGENTS.md に記しておくとよい。

本番反映と公開後の運用

ローカルで動作を確認できたら、本番サイトへ反映する。いきなり本番を書き換えるのではなく、本番と同じ構成のステージング環境で一度動かしてから反映すると、想定外の不具合を公開前に見つけられる。多くのレンタルサーバーやマネージド WordPress サービスがステージング機能を備えているため、そこにコードを移して確認する流れが安全だ。

反映の際は、テーマやプラグインのフォルダを差し替えるか、バージョン管理と連携してデプロイする。差し替え前には Codex に「今回の変更点を要約して、影響を受ける機能を挙げて」と依頼しておくと、レビューの観点が整理され、確認漏れを減らせる。公開後に不具合が見つかった場合も、エラーメッセージを Codex に伝えれば、原因の候補と修正案を返すため、切り戻しと再修正のサイクルを短くできる。

公開後の運用でも Codex は役立つ。WordPress 本体やプラグインの更新に伴って非推奨になった関数を洗い出したり、PHP のバージョン更新に合わせてコードを調整したりといった保守作業を、対話しながら進められる。テーマやプラグインを一度作って終わりにせず、テキストの指示でメンテナンスを続けていける点が、Codex を WordPress 開発に取り入れる価値の中心にある（出典: https://developers.openai.com/codex/quickstart ）。