WordPressのボタンや余白を少し直したいだけなのに、どのファイルを触ればよいか分からない。本番へ変更を入れてから表示崩れに気づき、元へ戻せなくなるのも避けたい。Codexへ作業を頼む場合も、対象を曖昧にしたままでは、意図しないファイルまで変更される可能性があります。
この記事は、実際の改修成功を示す検証記事ではなく、WordPressを変更する前に使う計画テンプレートです。記事専用に新しく用意する架空のWordPressを前提に、既存の子テーマへ小さなCSS変更を1件だけ加える場合の確認項目を整理します。ポイントは、Codexに任せる前に、人が対象、完了条件、確認方法、停止条件を決めることです。本番サイトや実在企業の環境は使いません。
検証状況：2026年9月27日、記事専用の架空WordPressを使った検証を試みました。変更前後のCSS fixtureとバックアップのチェックサムは記録できましたが、検証サーバーが安定して応答せず、最終のREST API実行はタイムアウトしました。PC／スマートフォンの画面確認、コード表示比較、変更後と復元後の一連の確認も完了していません。以下の表では、未確認項目を成功扱いにせず記載します。
最初に、WordPressの変更対象を3つへ分ける
WordPressの変更は、大きくファイル、データベース、REST API経由の操作に分けて考えます。どれを変更する作業なのかを最初に固定すると、バックアップと確認範囲を決めやすくなります。
| 対象 | 主な内容 | 今回の扱い |
|---|---|---|
| ファイル | テーマ、プラグイン、アップロード画像、設定ファイル | 既存の子テーマにある style.css だけを変更候補にする |
| データベース | 投稿本文、固定ページ、サイト設定、ユーザーなど | 変更しない。復元に備えてファイルと同時点のバックアップを取る |
| REST API | HTTP経由での投稿取得・更新など | 架空のコード付き記事について、取得・保存・再取得の確認に限る |
REST APIは、ファイルやデータベースそのものではなく、WordPressとJSONでやり取りするための窓口です。認証したからといって何でも操作できるわけではなく、認証ユーザーの権限が適用されます。外部スクリプトからApplication Passwordsを使う場合はHTTPSを前提とし、検証専用のユーザーと失効手順も用意します。
今回は「子テーマのCSS」というファイル変更を中心にし、投稿本文を変更する確認とは別の作業として実施します。ファイル、DB、REST APIを一度に変更しないことが、原因を切り分けやすくする第一歩です。
変更前に、隔離環境とバックアップを用意する
本番の複製をそのまま記事素材にするのではなく、架空データだけを入れた専用の検証環境を用意します。実在するドメイン、IPアドレス、アカウント、顧客情報、認証情報は、依頼文、画面、ログへ含めません。
変更前に、次の情報を1つの作業記録へ残します。
- 検証日と担当者
- WordPress、PHP、DB、子テーマ、Codex CLIのバージョン
- 検証用URLと対象ページ。ただし公開資料には例示用の値だけを使う
- 変更してよいディレクトリとファイル
- ファイルとDBのバックアップ識別子、作成時刻、保存先
- 復元先、復元手順、復元後に確認する項目
WordPress公式資料では、一般的なサイトを完全に復元するにはファイルとデータベースの両方が必要と説明されています。両方を近い時点で取得し、1つのバックアップセットとして対応づけます。典型的な順序はDBを先に、続いてファイルを保存し、復元時はファイルを先に、続いてDBを戻す流れです。
今回のCSS変更で直接更新するのはファイルだけです。それでも作業中に管理画面の設定や投稿が変わる可能性を考え、変更前のDBも同じセットへ保存します。復元テストでは、まず変更した子テーマファイルだけを戻します。DBまで戻すのは、DBにも変更が入った場合や、セット全体の整合を戻す必要がある場合だけです。
Codexへ対象と完了条件を具体的に伝える
Codexは作業開始前に AGENTS.md を読みます。プロジェクトルートから現在の作業ディレクトリまでの指示が順に加わり、現在地に近い指示が優先されます。ここには、作業ごとに変わらない禁止事項と最小限の確認コマンドを置きます。
|
1 2 3 4 5 6 7 8 |
# AGENTS.md の例 - 作業対象は `wp-content/themes/example-child/` のみ。 - 変更してよいファイルは `style.css` のみ。 - WordPress本体、親テーマ、プラグイン、アップロード、DBは変更しない。 - 実在する認証情報、環境変数、ログ、履歴を探索・表示しない。 - 変更前後の差分と、対象外ファイルが変わっていないことを報告する。 - 指示外の変更が必要なら作業を止め、理由だけを報告する。 |
個別の依頼文では、対象URL、期待する見た目、確認項目まで指定します。次の値はすべて記事用の例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
記事専用の検証用WordPressで、子テーマのCSSを1か所だけ変更してください。 対象ディレクトリ: wp-content/themes/example-child/ 変更してよいファイル: style.css 対象URL: https://wp.example.test/sample-page/ 変更内容: body.page-id-123 内の .wp-block-button__link の角丸を 6px にする。 完了条件: 1. 変更差分を提示する。 2. style.css 以外は変更しない。 3. PC幅とスマホ幅で対象ボタンの表示を確認する。 4. 代表ページ、内部リンク、フォーム、管理画面を確認する。 5. 対象URLと代表ページのHTTP状態を記録する。 6. 判断できない項目は成功扱いにせず「未確認」とする。 停止条件: 対象外ファイルの差分、バックアップ不整合、認証情報の表示、 または復元不能が見つかったら、それ以上変更しない。 |
Codexのサンドボックスと承認設定は、読み取り・書き込み・ネットワークの境界を狭めるための仕組みです。たとえば workspace-write では作業領域内の編集に限定できます。ただし、この設定だけで変更内容の正しさや復元成功が保証されるわけではありません。作業ディレクトリ、書き込み可能範囲、ネットワーク設定、承認設定を実行前に確認します。
子テーマのCSSを1か所だけ変更する
変更前に対象ファイルのコピーまたはバージョン管理上の基準点を作り、差分がない状態を記録します。今回は、架空の固定ページID 123にあるボタンだけを対象にしました。
|
1 2 3 4 5 6 |
--- a/wp-content/themes/example-child/style.css +++ b/wp-content/themes/example-child/style.css @@ +body.page-id-123 .wp-block-button__link { + border-radius: 6px; +} |
検証用fixtureでは、変更前後の差分が上記3行の追加だけであることを静的に確認しました。変更前fixtureのSHA-256は 2462f46f…d8146、変更後fixtureは 255efae5…8fe3 です。ただし、今回の最終実行では検証環境への変更適用、対象外ファイルの不変確認、変更前ファイルへの復元を一連で完了できていません。画面上の反映確認も未完了です。
CSSが反映されない場合も、すぐ別ファイルへ変更を広げません。キャッシュ、CSSの読み込み順、セレクターの一致を読み取り中心で確認します。原因が分からなければ、変更を戻して停止します。
コード付き記事は保存・再取得・表示を分けて確認する
投稿本文にコードブロックがある場合、保存できたことだけでは確認が足りません。HTMLのエスケープ、ブロック変換、テーマやプラグインによる表示処理で内容が変わる可能性があるためです。
- 架空のコード付き記事をREST APIまたは管理画面で取得し、変更前の本文を保存する
- 同じ記事を検証用の内容で保存する
- REST APIで再取得し、コード文字列とHTML構造を変更前の期待値と比較する
- 公開画面で
<、>、&、引用符、改行、インデントが意図どおり表示されるか目視する - 確認後、記事を変更前の状態へ戻し、再取得と画面表示をもう一度確認する
Application Passwordやユーザー名をコマンドへ直書きした例は公開しません。検証記録にも認証ヘッダーや秘密値を残さず、作業後に検証用の認証情報を失効できるようにします。
表示・機能・HTTP状態を同じ表で確認する
対象ページだけが正しく見えても、共通CSSが別ページへ影響することがあります。変更後と復元後で同じチェック表を使うと、「戻したつもり」を減らせます。
| 確認項目 | 期待状態 | 変更後 | 復元後 |
|---|---|---|---|
| 対象ページ・PC幅 | 対象ボタンだけ角丸が6px | 未確認 | 未確認 |
| 対象ページ・スマホ幅 | 文字切れ、重なり、横スクロールがない | 未確認 | 未確認 |
| 代表ページ | 対象外のボタンとレイアウトに差分がない | 未確認 | 未確認 |
| 内部リンク | 検証対象のリンクが期待先へ移動する | 未確認 | 未確認 |
| フォーム | 記事専用のテスト送信が完了し、二重送信しない | 未確認 | 未確認 |
| HTTP状態 | コード記事がHTTP 200を返す | タイムアウト | 未確認 |
| コード表示 | 保存前後の文字、改行、インデントが一致する | 未確認 | 未確認 |
| 管理画面 | ログインと対象記事の表示に異常がない | 未確認 | 未確認 |
| 対象外ファイル | 変更前から差分が増えていない | 未確認 | 未確認 |
HTTP状態は、ブラウザーの見た目とは別に記録します。キャッシュを使う構成では、通常表示、キャッシュ消去後、ログアウト状態を区別します。フォームは外部へ通知しない検証設定にし、送信先や個人情報を使わないテストデータだけで確認します。
復元を実際に再現し、止める条件を決める
バックアップが存在することと、復元できることは同じではありません。今回は変更前の style.css fixtureとバックアップのチェックサムを記録しましたが、変更適用からファイル復元、復元後の画面確認までを一連で完了できていません。そのため、復元テストは未完了として扱います。
DBを変更していなければ、通常はこのCSS復元のためだけにDBを巻き戻しません。コード付き記事の保存確認などでDBへ変更を入れた場合は、その作業を分けて記録し、対応するバックアップへ戻します。復元順や方法はホスティング環境で異なるため、事前に管理者と手順を確認してください。
次のどれかが起きたら、追加修正を重ねずに作業を止めます。
- 依頼していないファイルやDBに差分がある
- ファイルとDBのバックアップ時点や対応関係が分からない
- 復元後も差分、表示崩れ、機能異常が残る
- 認証情報、顧客情報、実環境の内部情報が出力へ含まれた
- キャッシュの影響と実ファイルの状態を切り分けられない
停止後は、作業時刻、実行した操作、確認できた差分、未確認事項を残し、権限を広げずに人へ引き継ぎます。
まとめ
CodexでWordPressを変更するときは、先にファイル、DB、REST APIの役割を分け、隔離環境で対象ファイルと完了条件を限定します。今回のようにAPI検証がタイムアウトした、または画面確認を完了できない場合は、作業を成功扱いにせず止めることが重要です。ファイルとDBは同時点のバックアップセットとして管理し、差分、表示、機能、HTTP状態、コード表示を確認できてから、本番反映を別の作業として判断してください。
資料確認日：2026年9月27日。参照：OpenAI「Custom instructions with AGENTS.md」、OpenAI「Agent approvals & security」、WordPress「Backups」、WordPress「Authentication」。Codex CLIとWordPressの仕様は変わる可能性があるため、実行時と公開直前にも公式資料を確認してください。
