Codexで記事を作るたびに同じ指示を書いても、文体や確認結果が変わることがあります。原因は指示の長さより、全記事で守るルールと、記事ごとに変わる条件が混ざっていることです。
AGENTS.mdは長いプロンプトの保管庫ではなく、制作ルールの入口として使います。文体、禁止表現、確認手順を固定し、検索意図やタイトルは記事ブリーフへ分ける設計を紹介します。
この記事でわかること
- ブログ制作のAGENTS.mdへ書く内容
- 記事ごとの指示と共通ルールの分け方
- 詳細ファイルを増やしても迷わない構成
- ルールが読み込まれたか確かめる方法
AGENTS.mdは制作ルールの「入口」にする
Codexは作業前にAGENTS.mdを読み、プロジェクト内の指示を組み立てます。上位のフォルダから作業場所まで順に読み、近い場所の指示があとから加わる仕組みです。
同じフォルダでは、AGENTS.override.mdがあればAGENTS.mdより優先されます。サイト全体の共通ルールと、記事フォルダだけの追加ルールを分けられます。
ただし、入口へすべてを書けばよいわけではありません。プロジェクト内で読み込む指示には既定のサイズ上限があり、長大な一枚へ詰めると必要な規則が埋もれます。
入口の役割は、次の3つです。
- このプロジェクトで何を作るか示す
- 参照する一次資料と順番を決める
- 作業後に通す確認を指定する
文体の細部や長いチェック項目は別ファイルへ置き、AGENTS.mdから読む順番を明記します。
変わらない指示と記事ごとの条件を分ける
記事制作の指示は、毎回変わらないものと、一記事だけで使うものに分かれます。ここを混ぜると、以前の記事タイトルやCTAが次の原稿へ残ります。
| 置き場所 | 書く内容 | 例 |
|---|---|---|
| AGENTS.md | 全記事で守る約束 | 文体、禁止表現、保存先、事実確認 |
| 詳細ルール | 判断基準と具体例 | 一文の長さ、CTAの温度、校正項目 |
| 記事ブリーフ | 今回だけの条件 | 検索意図、対象読者、内部リンク |
たとえば「一文は70字まで」は共通ルールです。「AI文章が薄い原因へ答える」は、その記事だけの検索意図です。
CTAの公開パスや安全方針も、記事ごとに手入力しないほうが安定します。登録済みのサービス一覧を別ファイルへ置き、そこから選ぶようにします。
反対に、タイトル、主軸キーワード、読後の行動をAGENTS.mdへ固定しません。記事が変わるたびに入口を書き換えると、共通ルールまで誤って変えるためです。
曖昧な好みを、確認できる規則へ直す
「自然に書く」「AIっぽくしない」だけでは、完成条件を確かめられません。読む人ごとに意味が変わり、修正理由も残らないからです。
文章の好みは、出力後に数えたり検索したりできる規則へ直します。
## 文章
- 日本語の敬体で書く
- 1段落は1〜3文にする
- 一文は70字までにする
- 同じ語尾を3文続けない
- 説明には理由、条件、具体例のどれかを含める
- 「〜しましょう」「〜が可能です」は使わないこの規則だけで良い記事になるわけではありません。少なくとも、どこが条件から外れたかは同じ基準で確認できます。
書き手らしさは、口癖の一覧より判断基準へ置きます。何を詳しく説明し、どの相談を対象外とし、どこで作業を止めるか。その選択が記事の声になります。
入口から詳細ファイルへ読む順番を作る
ルールを分割するときは、ファイル数より「どれを正とするか」を決めるほうが先です。同じ文体規則を3か所へコピーすると、一か所だけ古くなります。
構成は、次の程度から始められます。
AGENTS.md
├─ docs/editorial-policy.md
├─ rules/writing-style.md
├─ rules/safety.md
├─ services/service-map.md
└─ checks/draft-checklist.mdAGENTS.mdには「記事を書く前に、この順番で読む」と書きます。リンクを置くだけで自動的に意図が伝わるとは考えず、読む対象と目的を動詞で指定します。
文体の基準は一つのファイル、サービスURLも一つのファイル。別の資料と食い違ったときにどちらを優先するかまで、入口で決めておきます。
さらに細かいフォルダだけ規則を変えるなら、その場所へAGENTS.override.mdかAGENTS.mdを置けます。全体の入口を複製せず、違うところだけを書くほうが管理しやすくなります。
確認手順は「読む」だけでなく実行できる形にする
「公開前に確認する」と書くだけでは、どの作業が終わったか分かりません。確認項目には、対象と合格条件を付けます。
## 完了条件
1. メタ情報のID、スラッグ、画像名が台帳と一致する
2. 本文の内部リンクが記事ブリーフと一致する
3. CTAは登録済みの公開パスから一つ選ぶ
4. 料金、仕様、数値は元資料へ戻って照合する
5. 未確認事項があれば公開状態へ進めない文字数、禁止表現、ファイル名は数えれば分かります。検索意図への答え、事実の正しさ、公開可否は、読まないと分かりません。
この2つを同じ「チェック」と呼ばないのが要点です。分けておけば、条件を満たしたことを記事の正しさと取り違えずに済みます。
読み込まれた指示と完成物を別々に確かめる
ルールを書いたあと、まずCodexがどの指示ファイルを使っているかを確かめます。別のフォルダで作業すると、適用される階層も変わるためです。
次に、小さな下書きで完成条件を試します。最初から記事群を作らず、一文の長さ、禁止表現、保存先、チェック結果が意図どおりかを見ます。
確認は2段階です。
- どの指示ファイルが読まれ、どれが優先されたかを確かめる
- 出力されたファイルを、決めた基準で見る
1段目で食い違えば、文章を直す前に指示の置き場所へ戻ります。2段目だけを繰り返すと、毎回同じ崩れを原稿側で修正し続けることになるからです。
工程全体は企画・下書き・校正・公開判断の分け方へつながります。文章の中身が一般論へ薄まるなら、判断・理由・具体例を足す校正も参考になります。
人が決める項目をAGENTS.mdの外へ逃がさない
AGENTS.mdを整えても、記事の企画や公開責任まで自動化されるわけではありません。人が判断する項目を、明示的な完了条件として残します。
- 本当に受けたい読者の悩みか
- 実際の資料で事実を確認できるか
- 対応範囲外の相談を増やさないか
- 既存記事と違う答えがあるか
- 未確認のまま公開しようとしていないか
AIは候補を整理し、規則との違いを示せます。どの企画を残し、どの事実を公開し、どこで保留にするかは人の仕事です。
この境界まで書いておくと、AGENTS.mdはAIへ指示する文書だけではなくなります。制作チームが同じ基準で止まるための運用ルールになります。
おわりに
ブログ制作のAGENTS.mdには、全記事で変わらない文体、禁止表現、参照順、確認手順を置きます。検索意図やタイトルは記事ブリーフへ分け、詳細ルールは正本を一つにして読み込む順番を決めます。
入口と5つの完了条件を作るところまでは、自分でも試せます。階層ごとの指示や既存資料が食い違う場合は、原稿を増やす前に、どれを正とするか決める段階です。
指示を書き足すほど、かえって出力が安定しない。そう感じたら、ルールを増やす前に置き場所を見直す段階です。入口の設計から一緒に考えることもできますので、お気軽にご相談ください。
実際にどう運用しているかは、運営者・仕事の進め方にも書いています。
