WordPressのバックエンド——カスタム投稿タイプの定義、REST APIの設計、管理画面のカスタマイズ。こうした作業は、仕様が明確でパターン化しやすい。
前回までの連載で「デザインやアニメーションなど、人間の感性に頼る部分はAIだけでは難しい」という話をしました。じゃあ逆に、感性があまり求められないバックエンドの作業は、どこまでAIに任せられるのか？
このサイトの開発ではClaude Codeの「Agent Teams」機能を使い、バックエンド担当・フロントエンド担当といった形でAIエージェントに役割を分担させています。今回はそのうちのバックエンド——WordPressの実装をAIに全任せした結果を振り返ります。
AIに渡した要件
今回のサイトはヘッドレスCMS構成です。WordPressはコンテンツ管理だけを担当し、フロントエンドはNuxt 4で構築しています。つまりWordPress側に必要なのは、テーマの見た目ではなく「データを正しく管理・配信する仕組み」です。
もうひとつ意識していたのが、バックエンドにはできるだけお金をかけないということ。WordPressをレンタルサーバーで動かしているのもそうですし、有料プラグインを使わずに実装するのもその一環です。コンテンツ管理に毎月のランニングコストをかけたくなかった。
AIに渡した要件をざっくりまとめると、こんな感じでした。
- 複数のカスタム投稿タイプ（ブログ、実績、スキル、経歴、FAQ など）の定義
- それぞれに必要なACFフィールドの設計と実装
- REST APIのカスタマイズ（不要フィールドの除外、タクソノミーのターム名解決、セキュリティ対策）
- サイト設定の管理画面（キャッチコピー、ヒーロースライド、SNSリンクなどを管理画面から更新できるように）
- フロントエンドのキャッシュをWordPressの更新と連動してパージする仕組み
- 有料プラグインは使わない（ACF PROなどに頼らず、WordPress標準の機能で実現する）
コストをかけずに、ヘッドレスCMSとして必要な機能をひと通り揃える。これが今回AIに出したお題です。
出来上がったもの
結論から言うと、AIはこれらをかなりの精度で実装してくれました。
カスタム投稿タイプとフィールド定義
必要なCPTがすべて定義され、各投稿タイプに適切なACFフィールドが設定されました。
| 投稿タイプ | 主なACFフィールド |
|---|---|
| ブログ | 難易度、読了時間、TLDR（要約） |
| 実績 | プロジェクトタイプ、担当範囲、成果 |
| スキル | 習熟度、使用開始年 |
| 経歴 | 期間、役職、説明 |
| クライアントの声 | 評価、企業名、担当者名 |
| FAQ | 質問、回答 |
タクソノミーも、ブログカテゴリ・タグ、技術スタック（複数CPTで共用）、業界カテゴリなど、必要な分類体系が整理されていました。
REST APIのカスタマイズ — チーム開発が効いた部分
ヘッドレスCMS構成で地味に重要なのが、REST APIのレスポンスを最適化することです。ここは「バックエンドが返すデータ」と「フロントエンドが受け取りたいデータ」のすり合わせが必要になる領域で、今回のAgent Teamsの体制が特に活きました。
たとえば、タクソノミー（カテゴリやタグ）。WordPress標準のREST APIはタクソノミーをIDでしか返しません。フロント側で表示名を使いたければ、別途リクエストを投げて名前を取得する必要がある。これに対して、バックエンド担当のエージェントがレスポンスに名前とスラッグも含めるようにしたことで、フロント側の追加リクエストが不要になりました。
アイキャッチ画像のURLも同じです。通常はひと手間かけないと画像URLが取れないんですが、バックエンド側で直接返すようにした。フロントエンド担当のエージェントが「こういう形でデータが欲しい」、バックエンド担当が「じゃあこう返す」——このやり取りがPM（自分の場合はClaude Code本体）の調整のもとで自然に回っていたのは、Agent Teamsの強みだと思います。
その他にも、ヘッドレス構成では不要なフィールドの除外や、セキュリティ周りの対策も漏れなく揃っていました。
管理画面のカスタマイズ
一番感心したのがここです。WordPressのSettings APIを使って、サイト全体の設定を管理画面から編集できるUIが作られていました。
- タブ形式で設定項目を整理（キャッチコピー、ヒーロースライド、SNSリンク、サービス一覧など）
- メディアライブラリとの連携
- リピーターフィールド（項目の追加・削除・並び替え）
ACF PROがなくてもノーコードで管理画面が構築できていたのは、正直驚きました。
キャッシュパージ連携
WordPressで記事を更新したら、Nuxt側のキャッシュを自動でクリアする仕組みも実装されていました。投稿タイプごとにパージ対象のパスがマッピングされていて、たとえばブログ記事を更新したら/api/blogsと/blogのキャッシュが消える。サイト設定を変えたらトップページのキャッシュが消える、という具合です。
非同期で実行されるため、投稿の保存処理がブロックされないのも好印象でした。
実際に使ってみて見つかった問題
ここまでは良い話。ただ、実際に管理画面を使い始めると、いくつか問題が出てきました。
キー名の不一致問題
サービス一覧の設定で、管理画面からクラス名を入力しても、フロント側に反映されないという現象が発生しました。
原因を調べると、管理画面のフォームで保存しているキー名と、REST APIが読み出そうとしているキー名が違っていた。いわゆるcamelCaseとsnake_caseの不一致です。
AIが書いたコードとしては一貫しているつもりだったんでしょうが、管理画面とAPIで別々に実装しているうちにキー名がズレた。結局、REST API側で両方のキーを参照するフォールバック処理を追加して解決しました。
運用を想定していない設計
スキルの「経験年数」は当初、管理画面から直接数字を入力する仕様でした。
これ、今年は正しくても来年になったら全スキルの年数を手動で更新する必要がある。スキルの数が増えるほど管理の手間が増えます。
「使用開始年」を入力して、フロント側で現在年から差し引いて表示する方式に変更しました。年が変わっても自動で更新されます。
これはAIのバグというより、「運用視点の欠如」という問題です。仕様通りに動くコードは書けるけれど、「このデータを誰がいつ更新するのか」まで想像するのはまだ難しいようです。
タブ間のデータ消失
管理画面がタブ形式になっている関係で、あるタブの設定を保存したときに、別のタブの設定が消えてしまう問題がありました。
Settings APIの仕様上、フォームに含まれないデータは空で上書きされてしまう。タブを切り替えたときに「今表示していないタブのデータを保持する」処理が必要で、既存の保存値をフォールバックとして使うよう修正しました。
後から必要になった並び順の変更機能
ヒーロースライドやSNSリンクの表示順を管理画面から変更したいという要件が後から出てきました。初期実装では順番が固定だったため、ドラッグによる並び替え機能を追加する必要がありました。
これもAIが実装しましたが、並び替えたあとにフォームのデータ構造を整合させる処理が必要で、見た目以上に手間のかかる対応でした。
バックエンドはAI向きなのか？
振り返ると、バックエンドの実装はAIの得意領域だと感じます。
- パターンが明確 — 投稿タイプの定義、フィールドの登録、REST APIのカスタマイズ。どれもWordPressの定番パターンに沿った実装で、仕様を伝えれば適切な仕組みを使って実装してくれる
- 感性の出番が少ない — フロントエンドと違って「この余白がなんか違う」みたいなフィードバックがほとんど発生しない。仕様通りに動けば正解
- 修正が軽微 — 問題が見つかっても局所的な修正で済む。大規模なリファクタリングが必要になるような設計ミスはなかった
一方で、「実際に使ってみないとわからない問題」は必ず出るというのも事実です。キー名の不一致、運用を考慮していない設計、タブ間のデータ消失——どれもコードとしては正しく動いているけれど、人間が管理画面を触ってはじめて気づく類のものでした。
まとめ
バックエンドこそAIに任せるべきか？という問いに対する自分の答えは、「任せるべき。ただし、使い始めてからの微調整は前提」です。
定型的な実装をAIに一気に作ってもらって、自分は管理画面を実際に操作しながら「ここ使いにくい」「この仕様だと運用が回らない」というフィードバックを返す。このサイクルが回れば、バックエンド開発はかなり効率化できます。
逆に、AIが書いたコードを一切触らずにそのまま本番に持っていくのは危険です。動くことと使いやすいことは別の話なので。
技術ブログの次回は、このサイトのインフラ構成とデプロイ戦略について書く予定です。