Codexにトップページを直してほしいのですが、関係ない記事や設定まで変わったら怖いです。「ほかは触らないで」だけで伝わりますか？
もう一歩だけ具体的にしよう。「進めてよい」「禁止」「直前に確認」の三つへ分けると、Codexが迷わないよ。
安全のために、ファイルを読む時もテストする時も毎回聞いてもらった方がいいですか？
それでは調査が止まり続けるね。対象内の読み取り・小さな編集・テストは続けてよく、公開・削除・外部送信など影響が大きい操作だけ直前確認にしよう。
CodexへWordPress作業を頼む時は、作業を「そのまま進めてよい」「行ってはいけない」「実行直前に確認する」の三つへ分けます。 「勝手に変えないで」の一言だけでは、ローカルファイルの編集、CMSへの保存、一般公開のどこを指すか分かりません。
この記事では、対象URL・ファイル・機能の指定から、公開、削除、契約、外部サービス、既存の未保存変更までを初心者向けに整理します。基本的な依頼の組み立て方は、先に CodexへWordPress作業を頼む基本プロンプト を読むと理解しやすくなります。
結論：作業範囲は三つの箱で伝える
| 区分 | 意味 | WordPress作業の例 |
|---|---|---|
| 進めてよい | 目的達成のため継続してよい作業 | 対象ファイルの読取り、対象内の編集、構文検査、公開画面の表示確認 |
| 禁止 | 今回の依頼では実施しない作業 | 別サイト変更、記事削除、認証情報の表示、指定外サービスの利用 |
| 直前確認 | 必要になった時点で理由と影響を示して止まる作業 | 本番公開、DB変更、購入、外部送信、既存変更との上書き |
最初からすべての操作を列挙できなくても大丈夫です。まず対象を狭くし、取り返しにくい操作と外部に影響する操作を境界として明示します。
そのまま使える変更範囲・禁止事項の基本テンプレート
目的：
【誰が、何をできる状態にするか】
対象：
・サイト：【公開URL】
・ページ：【ページ名とURL】
・作業場所：【分かればフォルダ、ファイル、管理画面】
そのまま進めてよいこと：
・対象に関係するファイルと公開画面の読み取り
・対象範囲内の小さな編集
・構文検査、表示確認、リンク確認
禁止すること：
・対象外のページ、フォルダ、別サイトの変更
・ファイル、記事、画像、データの削除
・パスワード、APIキー、秘密鍵、個人情報などの秘密値を、会話・ログ・報告へ表示、転載、保存、外部送信
・指定していない外部API、AI、Worker、Cronの利用
実行直前に確認すること：
・本番公開、CMSの公開状態変更
・データベース変更、契約、購入、外部送信
・既存の未保存変更と同じ箇所の編集
・対象や戻し方を一意に確認できない作業
停止条件に当てはまったら、まだ実行せず、必要な理由・対象・影響・戻し方を報告してください。
作業後は「変更済み」「公開済み」「未実施」を分け、確認した証拠とともに報告してください。
「トップページ」と書くだけでなく、公開URLと作業場所も分けるんですね。同じ名前のページが複数あっても間違いにくそうです。
そう。読者が見るURLと、実際に変更するテンプレートやCMS記事は別物の場合がある。分からなければ、まず変更元を調べてもらおう。
テーマのファイル名が分からない時は、たぶんfront-page.phpだと思って書いてよいですか？
推測した名前で範囲を固定しない方がいいよ。「公開URLから変更元を特定し、候補が複数なら止める」と頼めば安全だね。
対象はURL・画面・変更元の三段で指定する
| 指定 | 役割 | 記入例 |
|---|---|---|
| 公開URL | 読者が見る完成画面 | https://example.com/service/ |
| 管理画面 | 記事・固定ページなどの保存先 | 固定ページ「サービス案内」 |
| 変更元 | テーマ、CSS、プラグイン等 | 子テーマ内で実際に使われるファイルだけ |
| 除外対象 | 今回触らない境界 | 申込みフォーム、決済、別ドメイン、親テーマ |
変更元が不明なら、「先に読取り調査を行い、対象候補と根拠を報告。候補が複数なら編集前に停止」と書きます。存在しないファイル名を初心者が推測する必要はありません。
「変更」の中には別の状態がいくつもある
WordPressでは、ローカルでファイルを書き換えただけの状態と、一般の読者が見られる公開状態は違います。ここを一語でまとめると、完了報告を取り違えます。
| 状態 | 外部への影響 | 依頼文での扱い |
|---|---|---|
| 読取り | 通常はなし | 対象内なら継続可 |
| ローカル編集 | 通常はまだ公開されない | 対象内の小変更は継続可 |
| テスト | 方法による | 送信・課金しない検査に限定 |
| CMS保存 | 下書きやRevisionが残る | 保存先と状態を指定 |
| 本番公開 | 読者・検索エンジンへ影響 | 公開可否を明記 |
| 削除・DB更新 | 復元困難な場合がある | 原則禁止または直前確認 |
| 外部送信・購入 | 第三者・費用へ影響 | 必ず境界を明示 |
「記事を直して保存して」と頼んだら、読者にも見えると思っていました。下書き保存やRevision保存とは別なんですね。
別だよ。「CMSへ保存済み・未公開」「本番公開済み・公開URL確認済み」のように、状態名と証拠をセットで報告してもらおう。
公開ボタンを押せたら終わりではなく、公開URLを実際に開くところまで必要ですか？
必要だね。PCとスマホの表示、リンク、画像、横はみ出しを読者側で確認して、初めて公開確認済みと言えるよ。
作業別に使える具体的な依頼文
既存記事の本文だけを直す
対象は【記事URL】の本文です。タイトル、URL、公開日、カテゴリ、既存画像、商品リンクは変更しないでください。
本文の【対象見出し】だけを修正し、ほかの段落は維持してください。
CMSでは新しいRevisionとして保存し、保存後に変更箇所を報告してください。
記事削除、URL変更、非公開化、一括置換は行わないでください。
本番公開まで依頼されている場合も、公開後に対象URLをPC幅と390px幅で表示確認してください。
テーマやCSSを直す
対象は【URL】で発生する【現象】です。まずブラウザで再現し、実際に読み込まれている変更元を特定してください。
子テーマまたはこのプロジェクト内の対象ファイルだけを編集してください。
親テーマ、WordPress本体、別プラグイン、別サイトは変更しないでください。
共通CSSへ影響する場合は、対象ページだけに限定できる方法を先に提示してください。
既存の未コミット変更と重なる場合は上書きせず、差分を示して止まってください。
公開まで任せる
この記事は、内容・リンク・表示の検査に合格したら本番公開まで進めてください。
許可する公開対象は【記事タイトル／URL】の一件だけです。ほかの記事や共通設定は公開しないでください。
公開後は公開URLを開き、1280pxと390pxで、見出し、会話、表、コード、画像、リンク、横スクロールを確認してください。
不具合があれば対象内で修正、再公開、再確認を行ってください。削除、URL変更、外部送信、契約が必要なら実行前に停止してください。
作業フォルダに、自分が途中まで直したファイルが残っているかもしれません。Codexの変更で消えませんか？
最初に差分を確認し、既存変更は利用者のものとして残すよう頼もう。同じ行に重なるなら、自動で戻したり上書きしたりせず止める。
「一度きれいな状態に戻して」も危ないんですね。自分の未保存作業まで消えるかもしれません。
そう。リセット、チェックアウト、削除、一括置換は便利でも対象が広い。正確な対象と復元方法を確認できない時は実行しない、と決めよう。
既存の変更は「知らない差分」ではなく利用者の作業
作業開始時に差分や未追跡ファイルが見つかっても、不要物と決めつけてはいけません。今回の作業と無関係なら維持し、同じファイルへ触れる必要がある時だけ重なりを確認します。
- 既存差分を勝手に戻さない。
- 未追跡ファイルを勝手に削除しない。
- 同じファイルでも、離れた箇所なら既存内容を保持して編集する。
- 同じ行や設定値へ重なるなら、差分と選択肢を示して止まる。
- 「整理のため」という理由で対象外まで整形・改名しない。
禁止事項は理由と代替行動まで書く
| 禁止すること | 理由 | 代わりに行うこと |
|---|---|---|
| 秘密値を表示・転載・外部送信する | 漏えいにつながる | 設定確認が必要でも秘密値そのものは出力しない |
| 外部API・別AIへ送る | 情報が外へ出る | ローカル資料と許可済み画面で判断する |
| Worker・Cronなどの継続実行を新規作成・変更する | 作業終了後も処理が続く可能性がある | 今回の手動作業内で完結する |
| 対象外の一括修正 | 影響範囲が広がる | 候補を報告し別依頼に分ける |
| 削除・強制リセット | 利用者の作業を失う | 差分を維持し安全な修正案を示す |
単に「禁止」と書くだけでなく、見つけた時にどう報告するかを決めると作業が止まりっぱなしになりません。
安全ルールを増やしたら、「ファイルを読んでよいですか？」と何度も止まりそうです。結局、自分で判断する回数が増えませんか？
安全なローカル調査と対象内テストは事前許可しよう。止まるのは、外部へ影響する時、取り返しにくい時、範囲が変わる時だけでいい。
作業中に別ページの問題を見つけたら、つい一緒に直してほしくなります。
今回は直さず「次の候補」として場所と重要度だけ報告してもらおう。今の完成条件を崩さず、一件ずつ確実に終えられるよ。
止まりすぎないための安全な自律範囲
「何をするにも聞く」では、読み取り確認すら毎回中断します。安全な範囲を先に許可し、判断が必要な境界だけで止めます。
次の範囲は確認を挟まず続けてください。
・対象サイトとプロジェクト内の読み取り調査
・対象ファイル内の必要最小限の編集
・外部送信や課金を伴わない構文検査と表示確認
・対象内の不具合修正と再確認
次の場合だけ実行直前に止まってください。
・対象ページ、ファイル、目的を広げる必要がある
・本番公開、削除、DB変更、契約、購入、外部送信が新たに必要になる
・既存変更と衝突する
・バックアップ、復元方法、正しい対象を確認できない
完了報告で公開済みと未実施を混ぜない
完了報告は次の順序で書いてください。
1. 完了した目的
2. 変更したページ・ファイル・Revision
3. 公開済み／保存のみ／未実施の区別
4. 実行した検査と結果
5. 維持した対象と触っていない範囲
6. 見つけたが今回直していない問題
7. 戻し方
8. 次に行う一作業
特に「公開済み」と「未実施」を同じ箇条書きに混ぜないことが重要です。公開URLを開いた結果、画面幅、リンクの遷移先など、読者側の証拠を添えます。
初心者がよく使う曖昧な表現を直す
| 曖昧な表現 | 起きる迷い | 安全な言い換え |
|---|---|---|
| ほかは触らないで | ファイル・ページ・設定の範囲が不明 | 対象URLと対象ファイル以外は変更しない |
| 問題なければ公開 | 何を検査すれば合格か不明 | 指定したPC・スマホ・リンク検査後に一件だけ公開 |
| 全部自動で | 削除や外部操作まで含むか不明 | 対象内の編集・再検査は継続、境界操作だけ停止 |
| 元に戻して | 利用者の既存変更まで失う可能性 | 対象Revisionだけ戻す案と影響を先に報告 |
| 必要なら何でも使って | 外部サービスへ情報が出る | 許可したローカル・ブラウザ手段だけ使う |
依頼前のチェックリスト
- 公開URLと対象ページ名を書いた。
- 分かる範囲で変更元を書き、不明なら調査を頼んだ。
- 対象外のページ、機能、別サイトを明記した。
- 読取り、編集、保存、公開を分けた。
- 削除、DB変更、契約、購入、外部送信の扱いを決めた。
- 認証情報や個人情報などの秘密値を、表示・転載・保存・外部送信しないよう指定した。
- 既存変更を上書きしないよう指定した。
- 停止条件と、止まった時に必要な報告を決めた。
- 完了条件と公開後の確認方法を書いた。
サーバー未契約なら公開先の境界も確認する
依頼文の作成やローカル作業に、新しいサーバー契約は不要です。完成したWordPressの公開先がまだない人だけ、契約先、料金、バックアップ、解約条件を自分で確認してください。既存環境で問題なく運用できている人は乗り換え不要です。
エックスサーバー
WordPressの公開先をまだ持っていない人だけが確認できる候補です。
向いている人： サーバー未契約で、公開環境とバックアップ条件をこれから用意する人。
不要な人： 現在のサーバーでWordPressが正常に動き、復元方法も確認できている人は契約不要です。
注意点： Codexとは別契約です。プラン、契約期間、初回総額、更新料金を申込画面で確認してください。
公開環境の条件を確認する広告・PRを含みます。この記事の依頼文を使うだけなら契約は必要ありません。
よくある質問
禁止事項は多いほど安全ですか？
多さより境界の明確さが重要です。安全な読取りや対象内テストまで禁止すると作業が止まります。外部影響、破壊性、範囲拡大を中心に決めてください。
ファイル名が分からない時はどうしますか？
推測せず、公開URLから実際の変更元候補を読み取り調査してもらいます。候補が複数なら編集前に報告してもらいます。
公開まで任せる時も確認は必要ですか？
今回の一件を公開まで進めると明示していれば、その範囲で進められます。別記事や共通設定へ範囲が広がる場合は止めてもらいます。
CMS保存と公開は何が違いますか？
下書きやRevisionへの保存は、一般公開と同じではありません。状態、公開URL、公開後確認を分けて報告してもらいます。
既存の変更を見つけたら消してよいですか？
消しません。利用者の作業として維持し、今回の変更と重なる時は差分を示して止まります。
外部サービスを使わない指定もできますか？
できます。外部API、別AI、Worker、Cronなど、使用しない手段を具体名で書き、今回許可したローカル作業とブラウザ確認だけで進めるよう指定します。
削除が本当に必要になったらどうしますか？
対象、件数、必要な理由、影響、バックアップ、復元方法を報告してもらい、実行直前に判断します。曖昧な一括削除は行いません。
次のチャットへルールを引き継げますか？
恒久ルールはプロジェクトのMarkdownへ保存し、開始時に全文を読むよう指定できます。公開済み状態と未実施事項も分けて記録します。
対象の読み取りと小さな修正は進めてよく、公開・削除・外部送信は別に扱う、と整理できました。「全部触らないで」よりずっと分かりやすいです。
いいね。Codexが動ける範囲と止まる場所の両方が分かるから、安全を保ちながら作業も進みやすいよ。
ただ、初めて見るサイトでは対象ファイルを自分で決められないかもしれません。その時は調査だけ先に頼めばいいんですよね。
その通り。分からない名前を作らず、URLと目的を伝えて変更元を調べてもらおう。候補と根拠を確認してから、三つの箱を更新すれば大丈夫だよ。
まとめ：安全とは、止めることではなく境界が分かること
CodexへWordPress作業を頼む時は、対象をURL・画面・変更元で示し、作業を「進めてよい」「禁止」「直前確認」の三つに分けます。読取り、ローカル編集、CMS保存、本番公開も別の状態として扱ってください。
安全な対象内作業は続けてもらい、外部影響・破壊的操作・範囲拡大の時だけ止めるのが、実用的な境界です。 作業前には バックアップ完全チェックリスト 、全体の学習順は CodexでWordPressサイトを作る完全ガイド も確認してください。