Codexが指示を読まない？ブログ執筆の確認手順

Codexでブログを書きたいのに、AGENTS.mdに書いた指示がうまく反映されない。そんなときは、指示を増やす前に、作業場所と読み込んだ内容を確認するところから始められます。この記事は、執筆ルールを用意したものの、期待した記事にならず困っている方に向けた確認手順です。

実際に、Codexでブログを書かせたいという相談の中で、フォルダー構成と指示の読み込み順について話しました。ここでは、その相談で扱った考え方を整理します。相談時の原因特定や、修正後の成功を報告する記事ではありません。

まず「読んだか」と「反映したか」を分ける

書いた指示・読まれた内容・原稿への反映を、それぞれ確認します。

記事の構成や保存先を指定しても、出力が期待と違うことがあります。その状態だけでは、ファイルを読んでいないのか、読んでも適用できていないのかは分かりません。

確認する場所は、大きく分けて次の3つです。

・作業場所：どのフォルダーを起点に仕事をしているか。

・読み込んだ指示：どのAGENTS.mdやスキルを参照したか。

・完成した原稿：指示と成果物が対応しているか。

ファイルの存在と、指示の反映は別の確認事項です。読ませたいファイルに届いていないなら、同じファイルに説明を追加しても、そこまで届くようにする工夫が必要です。

一方、内容が読めているのに出力が違うなら、矛盾する指示や曖昧な完成条件を見直す対象になります。フォルダー構成だけが原因だと決めつけず、段階を分けて調べます。

フォルダーを仕事の入口として整理する

工程名は説明用の例です。方針・手順・実行の制御を分けて配置します。

ブログ制作には、企画、調査、構成、執筆、編集・校正、画像制作、公開管理、振り返りがあります。会社全体の約束と、部署ごとの約束に置き換えると、指示の置き場所を整理しやすくなります。

たとえば、次のような配置です。部署名と成果物の分類は、この記事の説明用の例です。

・ブログ制作/AGENTS.md：全体の執筆方針、工程の案内、保存先。

・ブログ制作/.agents/skills/：繰り返し使う作業手順。各スキルの入口はSKILL.md。

・ブログ制作/.codex/rules/：必要な場合に設ける、コマンド実行を制御する設定。

工程ごとのフォルダーは、次の8つです。

・企画部：テーマ、想定読者、目的を決める。

・リサーチ部：根拠と未確認事項を整理する。

・アウトライン部：見出しと話の順序を考える。

・執筆部：構成に沿って本文を作る。

・編集・校正部：事実、表現、表記を確認する。

・画像制作部：本文に合う画像を用意する。

・公開管理部：原稿や設定を確認し、公開結果を記録する。

・振り返り部：確認できた反応と改善案を整理する。

各工程のフォルダーにAGENTS.mdを置き、その仕事で守る基準を書きます。全体のAGENTS.mdを入口にして、工程ごとの指示へつなぐ設計です。

成果物は「下書き・完成原稿・画像」程度の分類から始められます。この保存上の分類は、Codexの読み込み順を決める仕組みではありません。

AGENTS.md・Skills・Rulesの役割を分ける

AGENTS.mdの階層と、Skills・Rulesの仕組みは分けて考えます。

AGENTS.mdは、開始時にユーザー共通の指示を確認し、プロジェクトルートから作業場所までの指示を組み合わせる仕組みです。

リサーチ部を作業場所として開始する例なら、「ユーザー共通のAGENTS.md → ブログ制作/AGENTS.md → ブログ制作/リサーチ部/AGENTS.md」という順に考えます。

配下の全部署のAGENTS.mdが、一括で読み込まれるわけではありません。 ブログ制作フォルダーから開始するなら、全体のAGENTS.mdに「調査前にリサーチ部/AGENTS.mdを読む」と記すなど、必要なファイルを明示する方法があります。

また、同じ階層にAGENTS.override.mdがある場合は、通常のAGENTS.mdより優先されます。想定と違う指示が出るときは、この違いも確認します。

役割も分けておきましょう。

・AGENTS.md：仕事で守る方針と指示。

・Skills：必要な作業で使う手順。利用するときにSKILL.mdを読む。

・Rules：.rulesファイルによる、コマンド実行の許可・確認・禁止などの制御。

プロジェクト側のRulesには、設定階層が信頼されているという読み込み条件もあります。執筆方針を書き込むために、必ず用意するものではありません。

「AGENTS.mdの次に必ずRulesを読む」という固定の順番ではありません。 執筆の指示、作業手順、実行の制御を分けて確認します。

次の記事を書く前に行う確認

作業場所、適用した指示、短い原稿を順に照合する確認例です。

まず、短い確認依頼を出してみてください。次は、そのための文例です。

まだ記事本文は書かず、現在の作業ディレクトリと、適用しているAGENTS.mdのパスを示してください。採用する執筆方針を要約し、使うスキルと参照資料も確認してください。すでに適用されていた指示と、今回追加で読んだ資料を分けて報告してください。

確認は次の順で進めます。

1. 作業場所とファイルのパスが、意図したものかを見る。

2. 返された要約に、守ってほしい執筆方針があるかを見る。

3. 短い原稿を作り、構成、根拠、保存先を照合する。

「読みました」という返答だけで確認を終えないことも大切です。読み取りの履歴を確認できる環境なら、返答と合わせて見ます。

ファイルに届いていなければ、作業場所や参照先を見直します。読めているのに反映されないなら、指示の矛盾や完成条件を確認します。

この記事の配置や依頼文は設計例であり、同じ構成にすれば解決するという保証ではありません。まずは、ひとつの執筆ルールを、参照した内容と原稿の両方で確認するところから始めてみてください。