Codexへ仕事を頼むたびに、同じ条件を何度も説明していませんか?
「本文は6,000文字以上」「画像はH2直下」「未確認の実績は書かない」「公開せず下書きで止める」など、毎回プロンプトへ書いていると、伝え忘れや条件のズレが起こります。
僕も最初は、会話の中で修正点を追加していました。しかし、仕事がnote、WordPress、メルマガ、コラム、Threadsへ広がるにつれ、会話だけでは管理できなくなりました。
そこで重要になったのが、担当ごとの仕事ルールを保存する「AGENTS.md」です。
AGENTS.mdを用意すると、Codexは作業前にプロジェクトの目的や禁止事項を確認できます。毎回ゼロから説明するのではなく、継続して使える指示書をプロジェクト内へ置けるわけです。
この記事では、AGENTS.mdの意味、配置場所、書き方、5項目テンプレートを初心者向けに解説します。僕が作ったnote投稿担当の実例や、運用中に見つかった失敗と改善方法も紹介します。
- CodexのAGENTS.mdが果たす役割
- ファイルを置く場所と読み込み範囲
- 目的・入力・手順・完了条件・禁止事項の書き方
- note投稿担当を例にした実用テンプレート
- 指示を書きすぎず改善する方法
CodexのAGENTS.mdとは?

AGENTS.mdは、Codexへプロジェクト固有の方針や作業ルールを伝えるためのMarkdownファイルです。
通常のプロンプトが「今回の依頼」だとすれば、AGENTS.mdは「この仕事を行うときに毎回守る就業規則」に近い存在です。
OpenAI公式ドキュメントでは、Codexが作業前にAGENTS.mdを読み、グローバルな指示とプロジェクト固有の指示を重ねて利用すると説明されています。
会話の記憶ではなくファイルとして残す
チャットで一度伝えた条件が、別の作業や新しい実行でも必ず同じように使われるとは限りません。
一方、AGENTS.mdはプロジェクトのファイルとして残ります。人間も内容を開いて確認でき、修正履歴も管理できます。
たとえば、WordPress記事に「カテゴリーはAIツール」「公開はしない」「本文はHTML形式」と記載しておけば、次の記事でも共通ルールとして参照できます。
AIに覚えてもらうのではなく、人間が確認できる場所へルールを外出しすることがポイントです。
↓CodexとChatGPTの仕事の進め方の違いはこちら↓
CodexとChatGPTの違いを初心者向けに比較。会話・相談、ファイル作成、検証、継続作業など目的別の使い分けと、須賀…
AGENTS.mdを使う3つのメリット

1.同じ説明を繰り返さずに済む
文章のトーン、保存場所、文字数、画像サイズ、確認方法などを毎回書くのは大変です。条件が多いほど、ひとつ抜ける可能性も高まります。
共通条件をAGENTS.mdへ移すと、その日の依頼は「第5記事を作成してください」のように短くできます。
2.担当ごとの役割を分離できる
ネタ探し担当に本文を書かせたり、本文担当に公開操作まで行わせたりすると、どこまでが責任範囲か分からなくなります。
担当フォルダごとにAGENTS.mdを置き、入力と出力を決めることで、仕事の境界が明確になります。
3.失敗を次回のルールへ反映できる
僕のnote投稿テストでは、CTA画像が二重に入る、H2画像が文章の途中へ入る、画像プレースホルダーが残るといった問題がありました。
その場で直すだけでなく、原因と正しい配置をAGENTS.mdや関連ルールへ追記すると、次回の再発防止につながります。
実行→確認→失敗の記録→ルール修正を繰り返し、仕事に合わせて育てるファイルです。
AGENTS.mdはどこに置く?読み込み範囲を理解しよう

AGENTS.mdは、どこへ置いても同じように働くわけではありません。Codexはプロジェクトのルートから現在の作業フォルダまで、階層に沿って指示を探します。
公式ドキュメントによると、ルート側の広い指示から読み込み、現在の作業場所に近い指示を後から重ねます。近い場所のルールほど、より専門的な条件として扱われます。
プロジェクト全体と担当別に分ける
僕の仕組みでは、WordPress部門の上位に全体ルールを置き、その下に本文、画像、品質確認、投稿などの担当フォルダがあります。
全体の目的や安全方針は上位へ置き、本文の文字数やHTML装飾は本文担当、画像サイズは画像担当、下書き保存の手順は投稿担当へ置きます。
上位:全担当が守る共通ルール
下位:その担当だけが守る専門ルール
同じ内容を何度も重複させず、適用範囲に合う場所へ置きます。
AGENTS.override.mdとの違い
特定の階層で一時的または優先的に指示を上書きしたい場合、AGENTS.override.mdを使える仕組みもあります。
ただし初心者は、最初から複雑な上書きを使う必要はありません。まずは担当フォルダにAGENTS.mdを1つ置き、どの仕事へ適用されるか確認しましょう。
書き方の基本は「5項目」に分ける

AGENTS.mdへ何を書けばよいか迷ったら、次の5項目に分けてください。
- 目的:何を達成する担当か
- 入力:何を受け取って作業するか
- 手順:どの順番で処理するか
- 完了条件:何を確認できれば終了か
- 禁止事項:何をしてはいけないか
目的は一文で書く
目的が複数あると、作業の優先順位が曖昧になります。「読者に役立つnote記事を、画像付きの下書き状態へする」のように、到達点を一文へまとめます。
入力と出力を具体的にする
「前の担当から受け取る」だけではなく、テーマ選定ファイル、タイトル、根拠パックなど、必要な成果物を列挙します。
出力も「記事を作る」ではなく、HTMLファイル、画像フォルダ、品質レポート、投稿IDのように確認可能な形へします。
完了条件は数えられる形にする
「高品質にする」だけでは判定できません。H2が8個なら画像も8枚、文字数は6,000〜10,000文字、内部リンクは2〜3件など、検品できる条件へ変えます。
完了条件が曖昧な仕事は、Codexが止まる場所も、人間が確認する場所も曖昧になります。
そのまま使えるAGENTS.mdの5項目テンプレート

次のテンプレートは、文章作成、資料作成、調査、投稿準備などへ応用できます。
## 目的
この担当が達成する状態を一文で書く。
## 入力
・前工程から受け取るファイル
・参照してよい資料
・使用する設定やテンプレート
## 手順
1. 入力を確認する
2. 必要な作業を順番に行う
3. 成果物を指定場所へ保存する
4. 完了条件を検品する
## 完了条件
・必要ファイルが揃っている
・数値条件を満たしている
・未確認事項を明記している
## 禁止事項
・根拠のない事実を作らない
・指定外のファイルを変更しない
・公開、送信、削除を行わない
テンプレートを埋める順番
最初に目的と完了条件を書きます。その次に、完成へ必要な入力と手順を考え、最後に事故を防ぐ禁止事項を追加します。
手順から書き始めると、細かな操作ばかり増え、何のための仕事か見失いやすくなります。
実例:note投稿担当のAGENTS.md

僕のnote投稿担当を、先ほどの5項目へ当てはめると次のようになります。
目的
品質確認済みの記事、画像、CTA、ハッシュタグを、須賀ともひろのnoteアカウントへ入力し、公開せず下書き保存する。
入力
- 構成確認に合格した本文
- 記事タイトル
- アイキャッチ画像
- H2ごとの本文画像
- CTAバナーとリンク
- 本文末尾へ置くハッシュタグ
手順
- ログイン状態と既存下書きを確認する
- タイトルと本文を入力する
- アイキャッチ、CTA、H2画像を対応位置へ入れる
- ハッシュタグを本文末尾へ追記する
- 下書き保存する
- 画像数、位置、リンク、仮文字の残存を検品する
完了条件
- 新しい下書きが1件だけ作成されている
- アイキャッチが設定されている
- 各H2直下に画像が1枚ある
- CTAが指定の2か所に1セットずつある
- 投稿は公開されていない
- 編集URLと結果が記録されている
禁止事項
- 本人未確認の経験、実績、数字を追加しない
- 公開ボタンを押さない
- 接続切断後に新しい下書きを重複作成しない
- ログイン情報を成果物へ記録しない
このように、操作方法だけでなく「失敗したときに何をしないか」まで決めると運用が安定します。
↓Codexをブログやメルマガへ活用する実例はこちら↓
非エンジニア向けのCodex活用法7選を実例で解説。ブログ、note、メルマガ、SNS、画像、PowerPoint、定期…
AGENTS.mdへ書きすぎないための注意点

ルールを増やせば増やすほど、結果が安定するとは限りません。
長すぎる指示には、同じ内容の重複、古い条件、矛盾する条件が混ざりやすくなります。大切な指示が埋もれ、どれを優先するか分かりにくくなる場合もあります。
具体例と原則を分ける
AGENTS.mdには、常に守る原則と手順を残します。長い文章例、HTMLテンプレート、画像見本などはreferencesやtemplatesなどの別ファイルへ置き、必要なときだけ参照させます。
一つの指示は一度だけ書く
「公開しない」を複数の場所へ書くと安心に見えますが、将来ルールを変更したときに一部だけ古くなる危険があります。
安全上とても重要な条件は明確に記載しつつ、同じ説明を無意味に繰り返さないようにします。
変化する情報を固定しすぎない
画面のボタン位置やサービス仕様は変わります。「右上から3番目のボタン」のような固定表現より、表示名や達成したい状態で書く方が長く使えます。
出力が安定しないときの改善方法

AGENTS.mdを作っても、一度で完璧にはなりません。実際の成果物を見ながら改善します。
失敗を症状・原因・対策に分ける
「画像がおかしい」だけでは改善できません。
- 症状:H2画像が文章の途中へ入った
- 原因:挿入位置を文字列検索だけで決めた
- 対策:H2要素の直後へ挿入し、保存後に全H2を再検品する
対策のうち、毎回守る必要がある部分だけをルールへ加えます。
一度に複数の変更をしない
ルールを10個同時に変えると、どれが効果を出したのか分かりません。問題を一つ選び、条件を一つ追加して、同じ種類の仕事で再テストします。
古いルールを定期的に整理する
新しいルールを追加するだけではファイルが肥大化します。現在の画面や運用に合わない条件、別ファイルと重複した説明、使われていない例を定期的に削ります。
良いAGENTS.mdは長い指示書ではなく、失敗から学び続ける短い運用ルールです。
AGENTS.mdを更新したら同じテストを再実行する
ルールを直しただけで安心せず、問題が起きたときと同じ入力条件でもう一度実行します。
たとえば、記事画像の配置を改善した場合は、H2が複数あるテスト原稿を用意し、すべての見出し直下へ画像が入るかを確認します。成功した回だけでなく、ブラウザ接続が途中で切れた場合や、画像ファイルが一部不足した場合の動きも確認すると安心です。
僕の運用では、正常に終わる条件だけでなく、停止すべき条件も完了判定へ含めています。ログインが切れている、根拠が足りない、画像が揃わないといった場合は、無理に完成扱いにせず、途中状態と必要な対応を残します。
品質確認担当から逆算してルールを作る
AGENTS.mdの改善点が思いつかないときは、最後に人間がどこを見ているかを書き出してください。
タイトル、文字数、見出し、リンク、画像、事実、公開状態など、毎回目視している項目は完了条件の候補です。機械的に数えられるものはCodex側で事前確認し、読者への伝わり方や本人らしさなど、人間の判断が必要な部分だけを最終確認へ残します。
すべてを自動判定しようとせず、「自動で確認できること」と「須賀本人が確認すること」を分けると、AGENTS.mdが現実の運用に合うようになります。
変更理由を短く記録する
ルールを追加した日付と理由を別の履歴ファイルへ残す方法も有効です。
「2026年8月、CTA画像が二重表示されたため、保存後に同一画像数を確認する」のように背景を残せば、後から見たときに必要なルールか判断できます。理由が分からない禁止事項は、将来消してよいのか迷うからです。
AGENTS.md本体は短く保ち、詳しい失敗記録やテスト結果はhistoryやstateなどの別ファイルへ分けると、読みやすさと再現性を両立できます。
初心者は一つの担当フォルダから始めよう

いきなり複数部門と多数のAGENTS.mdを作る必要はありません。
まず「参考資料から要点をまとめる」など、小さな担当フォルダを一つ作ります。その中にsources、output、AGENTS.mdを置くだけで十分です。
練習プロジェクト/
├─ AGENTS.md
├─ sources/
│ └─ 参考資料.txt
└─ output/
AGENTS.mdには、参考資料を読むこと、1,000文字以内で要約すること、outputへ保存すること、元資料を変更しないことを書きます。
実行後に「文字数を超えた」「ファイル名が違った」などの問題があれば、完了条件を具体化します。
一つの担当が安定してから、調査担当、文章担当、品質確認担当というように分けてください。
↓Codexの画面と最初の依頼方法はこちら↓
Codex Windowsアプリの始め方・使い方を初心者向けに解説。準備、サインイン、画面の見方、プロジェクトフォルダ、…
まとめ|AGENTS.mdはCodexへ渡す仕事の設計図

AGENTS.mdは、Codexへ毎回同じ方針とルールを伝えるためのプロジェクト指示書です。
初心者は、次の5項目から始めましょう。
- 目的
- 入力
- 手順
- 完了条件
- 禁止事項
特に重要なのは、完了条件と禁止事項です。何をもって完成とするのか、公開や削除などどこで人間へ戻すのかを明確にしてください。
僕のSUGA AI Content Engineも、最初から完成していたわけではありません。実際の下書きを確認し、画像や接続の失敗をルールへ反映しながら育てました。
AGENTS.mdは、AIへ長い命令を押し付けるファイルではありません。人間とCodexが同じ完成イメージを共有するための仕事の設計図です。
まずは一つの小さな担当を選び、5項目だけを書いたAGENTS.mdで試してみてください。


