Codexを継続してブログ運営に使っていると、毎回同じ注意事項を書いたり、増えた情報をどこへ置くか迷ったりすることがあります。私のブログ運営でも、複数のブログを同じプロジェクトで扱うようになり、共通ルールとサイト固有ルールを分けるようになりました。
この記事では、CodexのAGENTS.mdに何を書くのかを、実際に使っている2階層の構成を例に説明します。AGENTS.mdの完全な仕様解説ではなく、個人ブログ運営で何をAGENTS.mdへ置き、何をKnowledgeや毎回のプロンプトへ分けているかが中心です。
AGENTS.mdには何を書くのか
私の運用での判断基準は「次回以降も守ってほしいことか」です。たとえば、推測で事実を補わない、指定外のファイルを変更しない、別サイトの情報を混ぜない、といったルールは、記事ごとに変わりません。そのため、毎回の指示ではなくAGENTS.mdに置く候補になります。
一方で、「今回は新記事の初稿を作る」「この見出しに内部リンクを追加する」のような依頼は、そのタスクだけの作業です。これはAGENTS.mdに書き足すのではなく、毎回のプロンプトで指定します。
CodexはAGENTS.mdをどう読むのか
OpenAI公式ドキュメントでは、AGENTS.mdはCodexにプロジェクトの追加指示やコンテキストを渡すためのファイルとして説明されています。プロジェクトの作法やテスト方法なども記載できます。Codexはプロジェクトのルートから現在の作業フォルダまで各階層を確認し、読み込んだ内容をルートから順に組み合わせます。現在の作業フォルダに近い指示ほど後から適用され、先の指示を上書きする関係になります。
私のブログ運営では、この階層ごとの適用範囲を使って、共通ルールとcodex-blog固有ルールを分けています。
詳しい仕様をすべて扱うのではなく、今回のブログ運営に必要な部分だけを図にすると、次のようになります。
プロジェクト
├─ AGENTS.md
└─ sites/
└─ codex_blog/
└─ AGENTS.md現在の作業ディレクトリがsites/codex_blog/以下にある場合は、公式の階層探索によって、ルート側からサイト側までのAGENTS.md系ファイルが読み込まれます。ただし、ファイルをこの位置に置くだけで、どの起動位置からでもサイト側の指示が自動的に読み込まれる、と考えているわけではありません。
このブログ運営プロジェクトでは、ルートAGENTS.mdにも、タスクの対象サイトに応じてsites/<site_id>/AGENTS.mdを参照し、サイト固有の作業では対象サイトのAGENTS.mdとREADME.mdを確認するルールがあります。つまり、階層配置による参照に加えて、ルートAGENTS.mdから対象サイト側AGENTS.mdを確認する運用も使っています。
この構成では、ルートのAGENTS.mdをプロジェクト全体の共通ルール、sites/codex_blog/AGENTS.mdをcodex-blogだけのルールとして扱っています。AGENTS.mdを書けば必ず性能や成果が上がる、という意味ではありません。私のブログ運営では、ルールの適用範囲を整理するために使っています。
仕様の確認には、OpenAI公式ドキュメント「Custom instructions with AGENTS.md」を参照しました。
私のブログ運営ではAGENTS.mdを2段階に分けている
共通ルールとサイト固有ルールを、実際の作業対象に近い場所へ分けています。
複数ブログを一つのCodexプロジェクトで管理する場合、すべてのルールを一つのファイルに詰め込むと、どのサイトに必要な内容かが分かりにくくなります。そこで、全体に共通するルールと、対象サイトだけに必要なルールを分けています。
プロジェクト共通
ルートAGENTS.mdには、複数のブログを同じプロジェクトで扱うときに共通するルールを置いています。対象サイトをタスク内で明示すること、サイトをまたいで固有情報を混ぜないこと、必要なファイルだけを参照することなどです。
サイト固有
codex-blog側のAGENTS.mdには、「ひとりブログ運営設計室」だけで必要なルールを置いています。たとえば、実績を誇張しない、実測値・推測・判断を分ける、OpenAI公式・公認・提携と誤認される表現を避ける、記事台帳やWeeklyの保存場所を定める、といった内容です。
ペット・ゲームブログにも同じルールが必要とは限りません。そのサイトのテーマ、公開方針、保存場所に固有のルールだけをサイト側へ置くことが、現在の分け方の基準です。複数ブログを同じプロジェクトで扱うようになった背景は、1サイト構成からマルチサイト構成へ再編した理由でも紹介しています。
ルートAGENTS.mdに置いている共通ルール
ルート側には、ブログのテーマが変わっても共通する作業上の境界を置いています。
代表例は、次の4つに分けられます。
変更範囲
必要なファイルだけを参照し、指定されていないファイルを変更しないというルールです。記事の初稿を頼んだときに、関係のない設定ファイルまで変更対象が広がらないようにするためです。
事実の扱い
不明なことを推測で補わず、実体験や一次情報が不足している場合は、勝手に本文を完成させないという考え方です。記事を長くすることより、確認できる事実と未確認のことを分けることを優先しています。
操作の境界
はてなブログ、外部管理画面、Git、認証情報などは、依頼で明示されない限り操作しません。原稿作成と公開操作を分けるためのルールでもあります。
完了報告
作業が終わったら、変更ファイル、確認結果、残課題、人間が判断することを報告します。作業を実行したことだけでなく、まだ確認できていない点を残すためです。
これらをルートに置いているのは、ペット・ゲームブログでもcodex-blogでも、作業の安全性と確認範囲に関わるからです。サイト固有の文章表現や記事台帳の場所まで、ルート側に集めているわけではありません。
サイト側AGENTS.mdに置いている固有ルール
codex-blog側では、Codexを使った個人ブログ運営の実践記録として公開するためのルールを置いています。
| 固有ルールの例 | このサイトで必要な理由 |
|---|---|
| 実績を誇張しない | 検証途中のブログなので、実測値と印象を分けて記録するため |
| 実測・推測・判断を分ける | どこまで確認できた情報かを読者に伝えるため |
| 完全自動などの表現を避ける | Codexだけを成果原因と断定せず、人間の確認を残すため |
| OpenAI公式と誤認させない | 個人ブログの実践例であることを明確にするため |
| 記事台帳やWeeklyの場所を定める | 記事の公開状態、履歴、次の作業を同じ運用で管理するため |
codex-blogだから必要なルールは、基本的にcodex-blog側へ置いています。ただし、公開安全に関する重要なルールなどは、ルートAGENTS.mdとサイト側AGENTS.mdの両方に存在します。完全に重複がないというより、サイト固有の内容を中心に分けている運用です。
AGENTS.mdとKnowledge・毎回の指示をどう分けるか
私の運用では、継続ルール・現在の状態・履歴・次の作業・今回の指示を5つに分けています。
Codexプロジェクトで参照するファイルでも、役割は同じではありません。私の運用では、次のように分けています。
| 置き場所 | 役割 | 書く内容の例 |
|---|---|---|
| AGENTS.md | 継続して守るルール | 推測で補わない、対象外を変更しない |
| Knowledge | 現在の状態・方針 | 公開済み記事、運用方針、記事台帳 |
| Weekly | 変更・判断の履歴 | 何を変更したか、何を判断したか、何が未確認か |
| Next Actions | 次に行う作業 | 本文レビュー、表示確認、次の記事候補など |
| 毎回のプロンプト | 今このタスクで実行する具体的指示 | 新記事の初稿を作る、特定記事へリンクを追加する |
たとえば、記事台帳に「記事マップに掲載した記事が公開済み」と書くのは現在の状態なのでKnowledgeです。「公開後に正式URLを台帳へ同期する」という作業ルールはAGENTS.mdやワークフロー側の内容、次に同期する作業はNext Actions、公開日に実際に何を更新したかはWeekly、今回その同期を依頼する文章はプロンプトへ置きます。
AGENTS.mdに何でも書けばいいわけではない
変わりやすい情報までAGENTS.mdに入れず、現在の情報や次の作業は別の場所で管理しています。情報を一か所に集めると安心できますが、変わりやすい情報までAGENTS.mdに入れると、更新されない古い前提になりやすくなります。公開済み記事や最新のURLはKnowledge側、次の作業はNext Actionsで管理しています。
同じルールを複数階層へ重複させすぎるのも避けています。修正時に片方だけ変わると、どちらを信じるべきか分かりにくくなるからです。ルールを増やすこと自体を目的にせず、実際に何度も守ってほしい内容だけを残しています。
自分のAGENTS.mdに何を書くか判断する基準
まず情報が「ルール・状態・履歴・次の作業・今回の指示」のどれかを判断します。
迷ったときは、まず情報の性質で分けると判断しやすくなります。
- 次回以降も守ってほしい？ → AGENTS.mdの候補
- 現在の状態・方針？ → Knowledgeの候補
- 過去の変更・判断？ → Weeklyの候補
- 次に行う作業？ → Next Actionsの候補
- 今回実行する具体的な作業？ → 毎回のプロンプト
複数の対象がある場合は、さらに「全体で共通するか」「特定の対象だけか」を見ます。全体で共通する作業ルールならルート側、特定のブログだけに必要なルールなら対象側です。
この基準なら、「何を書けばいいか」を最初から完璧に決めなくても、運用中に置き場所を見直せます。ルールではなく最新情報を置いてしまった、という場合も、Knowledgeへ移す判断ができます。
まとめ
私のブログ運営では、AGENTS.mdをCodexに継続して守ってほしい作業ルールを置く場所として使っています。OpenAI公式ドキュメントが示すように、AGENTS.mdにはプロジェクトの追加指示やコンテキストも記載できます。ブログについての情報を何でも詰め込む場所にはしていません。
私のブログ運営では、複数サイトで共通するルールをルートAGENTS.mdへ、codex-blogだけに必要な公開方針や管理場所をサイト側AGENTS.mdへ分けています。現在の状態はKnowledge、変更履歴はWeekly、次の作業はNext Actions、今回の作業は毎回のプロンプトに置きます。
継続ルール・現在の状態・履歴・次の作業・今回の指示を分けることが、AGENTS.mdを使うときの基本的な判断基準です。