Codexへサイト修正を頼むとき、私は「作業が終わった状態」まで書くようにしています。変更する場所だけでなく、残す内容、確認方法、公開するかどうかも伝えます。指示文を長くすることより、最後に何を確認できれば完成なのかを決めるほうが役に立ちました。
私は営業職の会社員で、Web制作は未経験から始めました。このサイトもCodexに手伝ってもらいながら作っていますが、最初から意図どおりの文章や画面になったわけではありません。
公開した記事に対して、私は一度「AIっぽくて面白くない」と伝えました。感じていた不満は本物でも、どの段落がなぜ嫌なのかまでは共有できていません。その後、「書き出しにサイトを作ろうと思った気持ちがない」と具体的に伝えて、やっと直したい場所がはっきりしました。
長い指示より、完成した状態を一文で書く
「文章を自然にして」「もっとSEOを意識して」だけでは、作業後に合否を判断できません。自然さの基準も、SEOのために残す情報も人によって変わるからです。
私は最初に、完成した状態を一文で書きます。
対象記事の冒頭を、レンがサイトを作ろうと思った理由から始まる文章へ直す。
事実と内部リンクは残し、修正後に文章ルールの検査とビルドを通す。
今回は公開せず、変更したファイルと確認結果を報告する。これなら、文章を直す範囲、残すもの、検査、公開の可否が分かります。細かな言い回しは、必要な箇所だけ後ろへ足します。
OpenAIのCodex Prompting Guideにも、計画だけで止めず、必要な情報を確認して実装とテストまで進める考え方が載っています。これは開発者向けの公式ガイドです。以下のテンプレートは公式の決まった形式ではなく、このサイトの修正で私が使いやすい形にしたものです。2026年8月29日に内容を確認しました。
私が使っている指示文のひな型
記事でも画面でも、私は同じ欄から埋めます。分からない欄は無理に作らず、「不明なので確認する」と書きます。
対象：
今回直す理由：
確認できている事実：
変更してほしい内容：
残してほしい内容：
確認方法：
公開範囲：
完了時に知りたいこと：「対象」にはURLだけでなく、分かればファイル名も書きます。「残してほしい内容」には、削られたくない数字、リンク、広告コード、デザインを入れます。
私が忘れやすかったのは公開範囲です。記事ファイルを直すだけなのか、GitHubへ反映して公開まで進めるのかで、行う作業が変わります。迷ったまま外部へ反映されないよう、今は毎回書き分けています。
記事を直すときのプロンプト例
2026年8月28日には、二つの記事にあるClaudeの採点結果を対応させ、内部リンクとOpenAI公式URLも確認しました。その依頼を、別の記事にも使える形へ直すと次のようになります。
対象：
- /articles/記事A/
- /articles/記事B/
今回直す理由：
同じ事例を扱っているのに、記事同士の関係が読者へ伝わらない。
確認できている事実：
- 2記事の点数は同じ記事を直したときのもの
- 採点は50点満点
変更してほしい内容：
- 両記事に同じ事例だと分かる一文を加える
- 採点基準の要旨を1〜2文で説明する
- 外部URLが公式か確認する
残してほしい内容：
- 記事タイトルとURL
- 事実確認と文章確認を分ける方針
確認方法：
- 本文内のリンクを開く
- 文章ルールの検査、型チェック、ビルドを行う
公開範囲：
ローカルの修正まで。公開はしない。
完了時に知りたいこと：
変更したファイル、リンクの確認結果、検査結果を報告する。この形にすると、Codexへ文章の修正とリンク確認を同じ作業として頼めます。URLが正しいか、ページが存在するか、文章が自然かは別の確認なので、検査方法も分けて書きました。
記事の文章ルールを作り直した経緯は、AIっぽい文章をどう直したかに残しています。ChatGPT、Claude、Codexへ渡す仕事の違いは、3つのAIを記事制作で使い分けた記録で確認できます。
見た目の修正では、変えない場所を先に決める
画面を直す依頼では、好みを表す言葉だけだと範囲が広がります。たとえば「ロゴを整えて」では、文字、色、余白、ヘッダー全体のどこまで変えるか判断できません。
このサイトでは、ロゴ左側の記号だけを「実」から「AI」へ変えたことがあります。依頼をひな型へ入れるなら、次の書き方です。
対象：ヘッダーとフッターのサイトロゴ
変更：左側の「実」を「AI」へ変える
残す：サイト名、色、文字サイズ、リンク先、周囲の余白
確認：スマートフォン幅とPC幅で、文字切れと位置ずれがないか見る
公開：ビルド成功後に公開まで進める
報告：変更箇所と公開URLを知らせる変更箇所が一つでも、表示場所はヘッダーとフッターの二つでした。「ロゴ全体は変えない」と書けば、意図していないデザイン変更を防ぎやすくなります。
繰り返すルールはAGENTS.mdへ移した
記事を頼むたびに、改行、句読点、架空の体験、未使用サービスの扱いを貼り直すと、肝心の修正内容が埋もれます。このサイトでは、毎回守る執筆方針をリポジトリ内のAGENTS.mdと編集用ファイルへまとめました。
OpenAIのAGENTS.md公式ガイドでは、Codexが作業前にAGENTS.mdを読み、プロジェクトごとの指示を受け取る仕組みを説明しています。私はここへ「未経験の体験を作らない」「記事修正後に検査する」といった常設ルールを置き、その日に直す内容だけを会話で伝えています。
ただし、ファイルへ書けば考えなくてよいわけではありません。今回だけ変えたい条件と常設ルールがぶつかったときは、どちらを優先するか指示文に書きます。ルールが増えすぎたら、同じ内容の重複も見直します。
Codexへ任せた後も、私は公開画面を読む
型チェックやビルドが通れば、ページが壊れていないことは確認できます。冒頭に人の気持ちがあるか、句読点が読みやすいか、広告への流れが強引ではないかは、私が公開画面で読みます。
Codexへ「確認して」と頼むだけで終わらせず、何を機械で検査し、何を自分で読むかを決めます。外部URLや料金は元ページを開き、文章はスマートフォン幅でも読み直します。
私は今後も、記事修正ではこのひな型を使います。短い修正なら全項目を埋めず、対象、残す内容、確認方法、公開範囲の四つは省きません。サイトをゼロから作る依頼は、CodexでWebサイトを作る6つの工程へ分けてあります。実際の企画から公開まで知りたい人は、このサイトをCodexで作った記録を続けて読めます。