Codex を部門で使い始めると、「毎回同じ前提を説明している」「部署独自の用語や禁止事項が抜ける」といった課題が出やすくなります。AGENTS.md は、こうした業務ルールや作業時の前提を Codex に継続的に読ませるための入口です。本記事では、AGENTS.md の書き方について、配置場所、優先順位、書く内容の例、rules との使い分けまで、部門導入の現場で使いやすい形に整理します。

i

本記事の結論: AGENTS.md は「業務上の判断基準」、rules は「コマンド実行の制御」と分け、全社共通・部門共通・業務別の順に重ねて整備するのが出発点です。

AGENTS.md は「毎回伝える前提」を置く場所

AGENTS.md は、Codex が作業を始める前に読むカスタム指示ファイルです。公式ドキュメントでは、Codex は実行開始時に AGENTS.md を読み、グローバルな指示とプロジェクト固有の指示を重ねることで、どのリポジトリを開いても一貫した期待値から作業を始められると説明されています。Custom instructions with AGENTS.md

部門利用では、AGENTS.md を「Codex に業務ルールを覚えさせるファイル」と捉えると分かりやすいです。ただし、厳密には人間のように記憶するのではなく、実行時に対象の指示ファイルを読み込み、その内容を前提として応答・作業するイメージです。

書くべき内容は、毎回プロンプトに含めると長くなるが、作業品質に影響するものです。たとえば、社内用語の定義、成果物の確認観点、変更してはいけない範囲、レビュー前に確認する手順などが該当します。一方で、一度きりの依頼内容や、その場限りの判断は通常のプロンプトに残す方が適しています。

Codex を部門で広げる際は、いきなり細かい例外を大量に書くより、「共通の前提」「業務別の例外」「確認が必要な操作」を分けることが重要です。対象業務の切り分け方は、Codex の業務別ユースケース整理と合わせて考えると、AGENTS.md に載せるべきルールの粒度を決めやすくなります。

配置場所と優先順位を理解する

AGENTS.md の書き方で最初につまずきやすいのが、「どこに置くと、どの指示が有効になるのか」です。公式ドキュメントでは、Codex は実行開始時に指示のチェーンを作り、グローバルスコープ、プロジェクトスコープの順に探索すると説明されています。Custom instructions with AGENTS.md

グローバルスコープでは、Codex のホームディレクトリにある AGENTS.override.md があればそれを読み、なければ AGENTS.md を読みます。Codex のホームディレクトリは、既定では ~/.codex とされています。ここには、どのリポジトリでも共通に使う作業方針を置くのが向いています。

プロジェクトスコープでは、通常は Git ルートのようなプロジェクトルートから、現在の作業ディレクトリまでを下りながら指示ファイルを確認します。各ディレクトリでは、AGENTS.override.md、AGENTS.md、設定されたフォールバック名の順に確認し、各ディレクトリで最大ひとつのファイルを含めます。

重要なのは、ルートから現在のディレクトリに向かって結合され、現在のディレクトリに近いファイルほど後に現れるため、より近い指示が前の指示を上書きする扱いになる点です。たとえば、部門全体の AGENTS.md では「原則として部署長確認」と書き、特定業務のディレクトリでは「定型レポート更新は担当者確認」と補足する、といった分け方ができます。

置き場所 向いている内容 例
グローバル 個人または共通の作業姿勢 依存関係追加前に確認する
プロジェクトルート 部門・業務全体のルール 用語、成果物の形式、レビュー観点
下位ディレクトリ 特定業務・チームの例外 支払、契約、顧客対応などの個別ルール
override ファイル 一時的または強い上書き 特定期間だけ別手順を使う

指示ファイルは、空のファイルはスキップされます。また、結合サイズが project_doc_max_bytes で定義された上限に達すると追加が止まり、既定値は 32 KiB と説明されています。指示が長くなりすぎる場合は、上限の調整や、ネストしたディレクトリへの分割が案内されています。Custom instructions with AGENTS.md

AGENTS.md に書く内容の型：用語、禁止事項、確認手順

AGENTS.md は Markdown で書けるため、部門の担当者にも読み書きしやすい形式です。最初から完璧な運用規程を作るより、Codex に毎回守ってほしい観点を短く、曖昧さが少ない形で並べるのが実務的です。

特に部門導入で役立つのは、用語、禁止事項、確認手順の三つです。用語は、社内でしか通じない略語や帳票名を定義します。禁止事項は、Codex に提案してほしくない操作や、確認なしに進めてほしくない判断を書きます。確認手順は、作業完了前に見るべき資料、チェックすべき観点、担当者に確認すべき条件を示します。

以下は、業務一般向けのテンプレート例です。特定製品や個別システムの仕様を断定するものではなく、自社の業務に合わせて書き換える前提で使ってください。

# AGENTS.md

## 業務の前提

- 本業務では「案件」は、問い合わせ受付から完了報告までの一連の対応を指します。
- 「一次確認」は、担当者が内容を確認し、次の対応方針を決める工程を指します。
- 不明な略語や社内用語が出た場合は、推測で補完せず、確認事項として明示してください。

## 禁止事項

- 個人情報、契約条件、金額に関する判断を、確認なしに確定しないでください。
- 既存の承認フローを省略する提案はしないでください。
- 根拠が確認できない数値を、事実として記載しないでください。

## 作業時の確認手順

- 変更案を出す前に、目的、対象範囲、影響を受ける関係者を整理してください。
- 判断が分かれる箇所は、推奨案と代替案を分けて提示してください。
- 完了前に、禁止事項に触れていないかを確認してください。

## 出力形式

- 非エンジニアにも伝わるように、専門用語には短い補足を付けてください。
- 最初に要点、次に詳細、最後に確認事項の順でまとめてください。

このように、AGENTS.md には「望ましい行動」と「避けるべき行動」を両方書くと、担当者がレビューしやすくなります。Codex の活用をチームで広げる場合は、Skills、Automations、worktrees などのチーム利用の考え方と併せて、どの前提を AGENTS.md に置き、どの作業を別の仕組みに分けるかを整理すると運用しやすくなります。

Code Review Rules は「指摘してほしい観点」を近い場所に置く

公式ドキュメントでは、Codex code review in GitHub 向けに、対象コードに最も近い AGENTS.md に ## Code Review Rules セクションを追加できると説明されています。リポジトリ全体のチェックはルートに、サービス固有のチェックはネストしたファイルに置く考え方です。Custom instructions with AGENTS.md

部門利用では、コードレビューに限らず、「レビュー時に見落としやすい業務観点」を近い場所に置く発想が参考になります。たとえば、顧客向け文面を扱うディレクトリなら、表現の統一、確認が必要な表現、法務・管理部門に確認すべき条件などを、該当ディレクトリの AGENTS.md にまとめます。

書き方のポイントは、抽象的な理念だけでなく、「何を見つけたら指摘するか」と「安全な代替案」をセットにすることです。公式ドキュメントでも、ルールは簡潔にし、フラグすべき挙動と安全な経路または例外を説明することが案内されています。Custom instructions with AGENTS.md

## Code Review Rules

### 顧客向け文面

- 契約上の確約に見える表現がある場合は指摘してください。
  安全な書き方: 条件、前提、確認が必要な事項を併記してください。

### 社内レポート

- 根拠資料が示されていない数値を断定している場合は指摘してください。
  安全な書き方: 出典、集計条件、未確認事項を分けて記載してください。

ここで大切なのは、AGENTS.md を「何でも書く場所」にしないことです。表記ゆれのように機械的に検出できるものは別のチェックに任せ、AGENTS.md には業務判断に近い観点を残す方が、読みやすく保守しやすくなります。

rules は AGENTS.md ではなく「コマンド実行の制御」に使う

AGENTS.md は自然言語の指示を重ねるための仕組みですが、rules は Codex がサンドボックス外で実行できるコマンドを制御するために使うものです。公式ドキュメントでは、rules は実験的で変更される可能性があるとされています。Rules

rules ファイルは、アクティブな設定レイヤーの隣にある rules/ フォルダ配下に .rules ファイルとして作成します。例として、~/.codex/rules/default.rules のような配置が示されています。Codex は起動時に、アクティブな設定レイヤー配下の rules/ をスキャンします。また、プロジェクトローカルの <repo>/.codex/rules/ は、プロジェクトの .codex/ レイヤーが信頼されている場合に読み込まれると説明されています。Rules

AGENTS.md に「確認してから進めてください」と書くことはできますが、コマンド実行の許可・確認・禁止を機械的に扱いたい場合は rules の領域です。prefix_rule() では、コマンドの接頭辞を示す pattern、一致した場合の decision、理由を示す justification、読み込み時に検証する match と not_match を指定できます。decision には、許可、確認、禁止に相当する allow、prompt、forbidden があり、複数一致した場合は最も制限の強い判断が適用されます。Rules

部門で考えるなら、AGENTS.md には「なぜ確認が必要か」「どの業務判断を避けるか」を書き、rules には「どのコマンドを確認対象または禁止対象にするか」を書く、という分担が分かりやすいです。

# 例: 特定のコマンド接頭辞に対して確認を求める
prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "PR の内容確認は承認後に実行する",
    match = [
        "gh pr view 1234",
    ],
    not_match = [
        "gh pr list",
    ],
)

rules の適用確認には、公式ドキュメントで codex execpolicy check が案内されています。指定した rules ファイルに対して、あるコマンドがどの判断になるかを確認でき、整備前のテストに使えます。Rules

部門導入での整備手順と運用の注意点

AGENTS.md は一度作って終わりではなく、部門の運用に合わせて更新していく前提で設計するのが現実的です。最初は、全社・部門で共通する作業姿勢をグローバルまたはプロジェクトルートに置き、個別業務の例外を下位ディレクトリに置く形から始めると、ルールの重複を避けやすくなります。

共通ルールを先に書く — 用語、確認が必要な判断、出力形式など、どの業務でも使う前提を AGENTS.md にまとめます。

業務別の例外を近い場所に置く — 特定のチームや業務だけに関係するルールは、対象ディレクトリに近い AGENTS.md または AGENTS.override.md に分けます。

実行制御は rules に分ける — コマンドの許可、確認、禁止を扱う場合は、AGENTS.md の文章ではなく rules の利用を検討します。

設定後は、Codex に現在の指示を要約させることで、読み込まれている内容を確認できます。公式ドキュメントでは、リポジトリルートから現在の指示を要約させる方法や、サブディレクトリを指定して有効な指示ファイルを確認する方法が紹介されています。指示が古いように見える場合は、対象ディレクトリで Codex を再起動します。Codex は実行ごと、また TUI セッション開始時に指示チェーンを再構築するため、手動で消すキャッシュはないと説明されています。Custom instructions with AGENTS.md

運用面では、AGENTS.md の管理者を曖昧にしないことも重要です。部門の誰が更新し、どのタイミングでレビューし、業務変更があった場合にどのファイルを直すのかを決めておくと、古いルールが残りにくくなります。特に禁止事項や承認フローは、現場判断だけで変更せず、関係部門と確認してから反映するのが安全です。

まとめ

AGENTS.md の書き方で大切なのは、Codex に毎回伝えたい業務上の前提を、読みやすく、保守しやすい形で置くことです。グローバル、プロジェクトルート、下位ディレクトリの役割を分けると、全体方針と業務別ルールを無理なく重ねられます。

書く内容は、用語、禁止事項、確認手順から始めると実務に乗せやすくなります。レビュー観点は ## Code Review Rules のように近い場所へ置き、コマンド実行の許可・確認・禁止は rules と分けて考えると、AGENTS.md が肥大化しにくくなります。

部門導入では、最初から細かいルールを網羅するより、よく使う業務から小さく整備し、実際の利用結果を見ながら更新する進め方が適しています。Codex に任せる範囲と、人が確認する範囲を明確にすることが、安定した運用の第一歩です。

デジライズでは、Codex を部門で使い始める企業向けに、法人研修や導入コンサルティングを通じて、AGENTS.md の設計、業務ルールの整理、運用フローづくりを支援しています。自社の業務に合わせた指示ファイルの作り方や、部門展開時のルール整備に不安がある場合は、無料相談で現在の利用状況をお聞かせください。

関連記事