CodexにWordPressのテーマやプラグインを作らせるなら、最初から「サイト全体をいい感じにして」と頼むより、一つの困りごとを、一つの変更として渡すほうが確かめやすくなります。たとえば「スマホで比較表が画面からはみ出す。表だけ横にスクロールできるようにする」です。完成の条件まで短く書けば、AIが作ったものを見て判断できます。
コードを書けることと、公開中のサイトを任せられることは別です。この記事では、表示の小さな修正を例に、依頼から公開判断までの進め方を整理します。特定の案件で効果を実測した手順ではなく、編集部が勧める作業設計です。
まず「テーマで直すこと」と「機能として残すこと」を分ける
文字の大きさ、記事カードの並び方、比較表の余白は、基本的にはテーマ側の仕事です。一方、問い合わせ記録、独自の計測、記事の審査など、テーマを替えても必要な機能はプラグイン側へ分けます。見た目の変更で記録や業務処理まで壊さないためです。WordPress公式にも、テーマの構成とプラグインの役割が分けて説明されています。
判断に迷うときは「別のテーマに替えても、この機能を残したいか」と考えてください。残したいなら、表示のコードと切り離せないかを先に検討します。既存のテーマがある場合、テーマ本体を直接編集すると更新時に消えることがあるため、子テーマや既存の変更管理方法も確認します。
そのまま使える、比較表の修正依頼例
記事内の比較表がスマートフォンで横にはみ出しています。本文全体の幅は変えず、表を包む領域だけ横スクロールできるようにしてください。見出しと最初の列が読め、画面全体に横スクロールが出ないことを完成条件にします。390・768・1440pxで確認してください。記事本文、広告URL、計測コード、WordPress設定は変更しません。最初はローカル環境だけに適用し、差分と確認結果を見せてください。
この依頼には「症状」「直す範囲」「触らない対象」「合格条件」が入っています。ファイル名まで分からなくても構いません。先に対象を調べさせ、変更予定のファイルと理由を説明させれば、関係のない修正が混ざった時点で気づけます。
コードができたら、差分と実画面の両方を見る
差分は、以前の状態から何が変わったかの一覧です。Codexのレビューでは、対象のファイルや変更範囲を指定して確認できます。ただしレビューの指摘がないことは、サイトが期待どおり動く証明ではありません。公式のコードレビュー案内を参考にしつつ、次の二種類を分けて確認します。
- コードの確認：対象外のファイルを変更していないか、構文エラーがないか、秘密情報を含まないか。
- 利用者としての確認：表のない記事は崩れていないか、長い表は読めるか、リンクやボタンが隠れていないか。
比較表だけなら、短い表、列が多い表、表がない記事を一つずつ選ぶと違いを見つけやすくなります。画面を縮めただけで安心せず、実際にスクロールして読めるか、キーボードでも操作できるかまで確認します。
本番へ出す前に「戻すもの」を用意する
必要なのは「バックアップがあります」という言葉ではなく、どのファイルを、どの版へ戻すかです。記事やデータベースも変更するなら、その復旧手順を別に用意します。表示だけの修正に、データベース全体の復元を安易に組み合わせると、その後に入った問い合わせまで失うおそれがあります。
公開する変更を一つに絞り、旧版を保存し、反映直後に同じ画面を再確認する。想定外の表示やエラーが出たら、追加修正を重ねる前に戻す。この順番なら、何が原因だったかを追いやすくなります。
最初の依頼は、サイト全面刷新より「読めない表を直す」「一つの画像が切れるのを直す」程度がおすすめです。確認方法が分かる変更を積み重ねれば、AIの作業を自分で判断できる範囲も広がります。具体的な確認順は、公開前に検証する3段階へ進んでください。
