本家はこちら

AGENTS.md、ちゃんと書いたのに全然言うこと聞かないんだけど?

Some visuals are licensed via Canva Pro (includes commercial rights).
Usage complies with Canva’s license terms at the time of use.
License policy: canva.com/policies/content-license-agreement

X
     この記事はプロモーションを含みます

AGENTS.md、ちゃんと書いたつもりだったんですよ。

禁止事項も書いた。優先順位も書いた。Computer Use と agent-browser の使い分けも書いたし、サブエージェントを使う条件も書いた。なのに Codex が、なぜか毎回ちょっとずつ都合よく読む。

「いや、そこ AGENTS.md に書いてあるじゃん」

なんで今それを best-effort 扱いにした? そこがいちばん困るんだよね。

「さっきは守ったのに、今回はなんでスキップした?」

たぶん AGENTS.md を触り始めた人は、どこかでこの壁に当たります。少なくとも僕は当たりました。けっこう正面から。

ただ、しばらく運用して分かったのは、これは単に「Codex が雑」だけで片づけると原因を見誤る、ということです。AGENTS.md は長ければ効くわけではありません。細かければ守られるわけでもありません。効く AGENTS.md にするには、それをただの説明文ではなく、スコープを持った SSOT、つまり実行条件の正本として読ませる必要があります。

そこでさらに分かったのは、効く AGENTS.md にはかなり反復可能な法則がある、ということでした。発動条件を置く。成果条件を置く。例外を狭くする。tool boundary と role boundary を分ける。local と global の優先順位を固定する。こうした書き方の型を何度も見直しているうちに、「これは毎回手で気合いを入れて直すものではなく、skill にできる」と分かりました。実際に agents-md-clarifier として skill 化したことで、Codex の人間的な解釈 drift をかなり減らし、非常に正確に思った通りの動作へ近づけられるようになりました。もちろん魔法ではありません。でも、少なくとも僕の運用では「書いたはずなのに毎回違う読み方をされる」状態からはかなり抜け出せています。

この記事では、AGENTS.md が詳細なのに Codex の挙動が drift する理由を、SSOT、実行契約、優先順位、tool boundary、サブエージェント委任の観点から整理します。途中で agents-md-clarifier の話も出しますが、これは汎用ツール紹介ではありません。僕が実際に「書いてあるのに効かない」を踏んで、AGENTS.md の読み筋を塞ぐ必要に迫られた話です。

Content

まず、AGENTS.md は長さだけでは効かない

長いAGENTS.mdの束と整理された実行契約を見比べるじぴこの解説イラスト。

最初に切り分けたいのは、「AGENTS.md が長いこと」と「AGENTS.md が強いこと」は別だという点です。長い AGENTS.md は情報量を増やします。でも、Codex がその情報をどの優先順位で読み、いつ発動し、何を満たせば完了と判断するのかが固定されていなければ、結局は説明の多いメモとして読まれます。

ここで押さえること

長い AGENTS.md は材料を増やすだけです。強い AGENTS.md は、Codex の判断経路、優先順位、完了条件を固定します。

「ちゃんと書いたのに守られない」問題から始める

AGENTS.md を書き始めた頃、僕は「もっと具体的に書けば安定するはず」と考えていました。たとえば、こんな感じです。

- なるべくサブエージェントを使う。
- 必要に応じて Computer Use を使う。
- 重要な判断ではユーザー意図を尊重する。
- 可能なら作業後に検証する。

一見、悪くないですよね。むしろ普通に親切です。でも Codex の実行条件として見ると、かなり危うい。

「なるべく」は、いつでも「今回は不要そう」に変換できます。「必要に応じて」は、必要性の判定を Codex 側に残します。「重要な判断」は、何が重要かを毎回推論させます。「可能なら」は、時間、文脈、ツール露出、手間を理由に簡単に落ちます。

弱い言葉Codex 側に残る逃げ道
なるべく今回は不要そう、と判断できる
必要に応じて必要性の判定を毎回 Codex が持つ
重要な判断何が重要かをその場で推論できる
可能なら時間、文脈、ツール露出を理由に落とせる

つまり、文章としては正しいけれど、実行時には逃げ道が多い。これが「ちゃんと書いたのに守られない」の入口です。

長い AGENTS.md と強い AGENTS.md は別物

長い AGENTS.md は、Codex に材料を渡します。強い AGENTS.md は、Codex の判断経路を固定します。この違いはかなり大きいです。

長いだけの AGENTS.md は、こうなりがちです。

Section: Browser Automation

- Browser tasks may use Computer Use, agent-browser, browser-use, or web depending on the situation.
- Prefer the tool that seems most appropriate.
- Use DOM inspection if it helps.

日本語で書くとこうです。

節: ブラウザ自動化

- ブラウザ作業では状況に応じて Computer Use、agent-browser、browser-use、web を使える、という弱い書き方
- もっとも適切そうなツールを優先する、という判断を Codex 側に残す書き方
- 役に立つなら DOM 検査を使う、という発動条件が曖昧な書き方

人間が読むなら分かります。けれど、実行時の Codex にとっては「場合による」の塊です。どの言葉も便利に読めます。結果として、画面操作を求められているのに DOM 側だけで済ませたり、IAB 指定なのに別ブラウザへ寄せたり、CDP モードなのに同一個体確認を省略したりする余地が残ります。

強い AGENTS.md は、同じ内容でも発動条件と禁止事項を分けます。

Section: Browser Automation

- If the user explicitly says "IAB", "in-app browser", "Browser Use", or "@Browser",
  treat the task as IAB mode and use browser-use.
- Do not silently switch an IAB request to CDP mode, Computer Use-only mode, or web browsing.
- If the task is CDP mode, first confirm that Computer Use and agent-browser are attached
  to the same Brave Browser instance before DOM inspection.

日本語で書くとこうです。

節: ブラウザ自動化

- ユーザーが IAB 系の語を明示したら、
  IAB モードとして扱い browser-use を使う
- IAB 指定を CDP、Computer Use 単体、通常の web 調査へ黙って切り替えない
- タスクが CDP モードの場合、DOM 検査前にまず Computer Use と agent-browser が
  同じ Brave 個体へ接続していることを確認する

ここまで書くと、Codex が「今回はこっちでもよさそう」と読み替える余地が減ります。単なる推奨ではなく、入力条件と禁止される分岐がセットになっているからです。

僕が引っかかったのは、指示不足ではなく解釈余地だった

自分の AGENTS.md を見直していて一番嫌だったのは、ルールが足りないわけではなかったことです。むしろ、かなり書いてありました。

でも、書いてある内容の多くが「Codex がよい感じに判断する」前提になっていました。ここが罠です。Codex はだいたい善意で動きます。ただし、善意で動くことと、再現性のある運用をすることは別です。

AGENTS.md が効かないときにまず疑うべきなのは、指示量ではありません。次のような解釈余地です。

- When does the rule activate?
- trigger: the input condition that activates the rule
- What must be true before the task is complete?
- outcome: the condition that must be satisfied for completion
- Which instruction wins when rules conflict?
- priority: the instruction order used to resolve conflicts
- Who may allow an exception, and under what conditions?
- exception: the actor and conditions that permit an exception
- Which tool is primary, and which tool is supporting?
- tool boundary: which tool owns the primary role and which tool supports it
- May the parent replace work delegated to a subagent?
- role boundary: the responsibility split between parent and subagent

日本語で書くとこうです。

- いつ発動するのか
- 発動条件: ルールが発動する入力条件
- 何を満たしたら完了なのか
- 完了条件: 完了と判断するために満たす条件
- どの指示が衝突時に勝つのか
- 優先順位: 衝突時にどの指示を優先するか
- 例外は誰が、どの条件で認めるのか
- 例外条件: 例外を認める主体と条件
- どのツールが主で、どのツールが補助なのか
- ツール境界: どのツールが主担当で、どのツールが補助担当か
- サブエージェントへ委任した範囲を親が代行してよいのか
- 役割境界: 親とサブエージェントの担当範囲

ここが空いていると、AGENTS.md は「書いてある」のに「実行条件になっていない」状態になります。

trigger

そのルールがいつ発動するかを決める入力条件です。

outcome

何を満たしたら完了と判断するかを決める成果条件です。

priority / exception

衝突時にどの指示が勝つか、例外を誰がどの条件で認めるかを固定します。

tool boundary / role boundary

どのツールが主担当か、親とサブエージェントの責務がどこで分かれるかを明示します。

Codex が都合よく読める余白はどこに生まれるのか

ルールカードの隙間を虫眼鏡で確認し、解釈の余白を見つけるちびじぴこ。

Codex がルールを曲げたように見えるとき、実際には AGENTS.md 側に「曲げられる形」が残っていることが多いです。特に弱い動詞、発動条件の欠落、成果条件の曖昧さは、実行時のブレを生みます。ここを潰さないまま禁止事項だけ増やしても、別の場所から漏れます。

弱い動詞は best-effort に落ちやすい

弱い動詞とは、実行義務ではなく努力目標として読める言葉です。日本語なら「なるべく」「必要に応じて」「適宜」「可能なら」「検討する」。英語なら preferconsidergenerallyas neededif appropriate あたりです。

これらは完全に禁止すべき言葉ではありません。問題は、実行条件を固定したい場所で使うことです。

[weak]
- Prefer using subagents when helpful.
- Consider checking local AGENTS.md before editing files.
- Use Computer Use if appropriate.

[strong]
- For exploratory verification, log-heavy inspection, or DOM-heavy analysis,
  delegate to a subagent by default unless the user explicitly forbids it.
- Before editing files, check for the nearest local AGENTS.md in the workspace.
- When the user asks for visible GUI interaction, use Computer Use as the primary actor.

日本語で書くとこうです。

[弱い書き方]
- 役に立つと Codex が判断したときだけサブエージェントを使う余地が残る
- 編集前の local AGENTS.md 確認が検討事項に落ちている
- Computer Use を使うかどうかの判断が Codex 側に残る

[強い書き方]
- 探索的検証、ログ読解、DOM 中心の分析では、
  明示禁止がない限り既定でサブエージェントへ委任する
- ファイル編集前にワークスペース内でもっとも近い local AGENTS.md を確認する
- ユーザーが目に見える GUI 操作を求めたら Computer Use を主担当にする

weak 版は、Codex が毎回「helpful かどうか」「appropriate かどうか」を判断します。strong 版は、入力条件、既定動作、例外が固定されています。

AGENTS.md の目的が「Codex に考えさせる」ことなら weak でもよい場面はあります。でも、運用憲法として安定させたい箇所では、weak wording はだいたい負けます。負ける相手は別の明示ルールだけではありません。作業短縮、文脈節約、直近の成功体験、ツール露出、親スレッドの都合にも負けます。

発動条件がないルールは毎回判断が揺れる

ルールは、内容だけでなく「いつ発動するか」が必要です。たとえば、こう書いたとします。

- サブエージェントを積極的に使う。

気持ちは分かります。僕もこう書きたくなります。でも、この書き方だと Codex は毎回こう考えられます。

この作業は本当にサブエージェント向きか?
数手で終わりそうだから親でよいのでは?
委任すると逆に遅くなるのでは?
ユーザーは今回も本当に委任を望んでいるのか?

そこで、発動条件を書きます。

Section: Subagent Delegation

- For asynchronous research, validation, document gathering, DOM observation,
  log reading, reproduction checks, or branch-heavy comparison, delegate the work
  to a subagent when the environment permits it.
- Treat this default as a standing user instruction. Do not ask the user to repeat
  "use subagents" for each article run.
- Treat this instruction as explicit user permission to use subagents within the
  current workflow, as long as the runtime environment permits it.
- The parent owns scope, evaluation, integration, and the final explanation.

日本語で書くとこうです。

節: サブエージェント委任

- 非同期調査、検証、資料収集、DOM 観測、
  ログ読解、再現確認、分岐比較では、環境が許す限り
  サブエージェントへ委任する
- この既定動作を継続的なユーザー指示として扱い、
  記事生成のたびに「サブエージェントを使うか」を再確認しない
- この指示を、実行環境が許す範囲での
  サブエージェント使用への明確なユーザー許可として扱う
- 親はスコープ、評価、統合、最終説明を担当する

ここまで書くと、「サブエージェントを使うべきか」という毎回の曖昧な判断が、「このタスクは列挙条件に入るか」という判定に変わります。判断は残りますが、判断の軸が固定されます。

サブエージェント指定には、AGENTS.md より上の制約がある

ここで必ず押さえておきたい前提があります。AGENTS.md、skill、plugin に「サブエージェントを使う」と書いても、それだけで常にサブエージェントが発動するわけではありません。

Codex には、ユーザー指示や AGENTS.md より上にあるシステム層の制約があります。その中に「サブエージェントは、明確に使用許可がある場合にだけ使う」という前提が強く働く場面があります。

つまり、AGENTS.md 側でできるのは「どういう条件ならサブエージェントを使うべきか」を契約化することです。一方で、「この会話、この作業でサブエージェントを使ってよい」という実行許可は、ユーザーの明示があるほど安定します。

  • AGENTS.md / skill / plugin は、サブエージェントを使う条件と役割を固定する。
  • ユーザーの明示指示は、この作業でサブエージェントを使ってよいという意図を渡す。
  • システム層の上位制約は、サブエージェント利用の最終的な境界として残る。

だから実運用では、記事生成や調査の最初にこう添えるだけでかなり安定します。

この作業では、サブエージェントを積極的に使って進めてください。
AGENTS.md と skill/plugin 側の subagent-first workflow を前提にしてください。

これは AGENTS.md 側のルールが無意味という話ではありません。むしろ逆です。AGENTS.md で委任条件を固定し、ユーザーの前置きで実行許可を明示し、skill/plugin の workflow と接続する。ここまで揃えると、サブエージェント利用は「気分で使う補助機能」ではなく、かなり再現性のある実行条件になります。

じぴ子

ここ、かなり大事な予備知識です。AGENTS.md に委任条件を書くだけではなく、作業の冒頭で「サブエージェントを積極的に使って」と明示しておくと、上位制約と skill/plugin の実行契約がつながりやすくなります。

成果条件が曖昧だと、完了判定も曖昧になる

AGENTS.md では禁止事項や手順を書きがちですが、成果条件も同じくらい重要です。成果条件がないと、Codex は「やったつもり」で止まれます。

たとえば、ブラウザ操作でありがちなズレです。

[vague]
- Use Brave in CDP mode.

[executable]
- CDP mode succeeds only when Computer Use and agent-browser are attached
  to the same Brave Browser instance and see the same URL, title, and visible page.
- If the URL is about:blank, the title is empty, or the visible page and DOM view do not match,
  treat shared instance confirmation as failed and restart from that step.

日本語で書くとこうです。

[vague]
- CDP モードでは Brave を使う

[executable]
- CDP モードは Computer Use と agent-browser が同じ Brave 個体へ接続し、
  同じ URL、title、実画面を見ている場合だけ成功する
- URL が about:blank、title が空、または実画面と DOM view が一致しない場合は、
  共有個体の確定失敗として扱い、その手順からやり直す

後者は少し重いです。でも、その重さに意味があります。完了条件が固定されるからです。

完了条件の注意

出力が成功したことと、指定された実行モードを守ったことは別です。AGENTS.md では、どちらを満たす必要があるかまで書きます。

Codex の作業は、途中まではそれっぽく進みます。だからこそ「何をもって完了とするか」を AGENTS.md 側で固定しないと、最後の 10% が毎回ぶれます。

SSOT として宣言しないと、ルールは助言に見える

AGENTS.mdをSSOTとして扱うため、正本マーカーを置くじぴこのイラスト。

ここからが本題です。AGENTS.md が実行条件として効くには、「このファイルはこの範囲の正本である」という立場を明示する必要があります。これが SSOT 宣言です。SSOT は Single Source of Truth の略で、この記事では「そのスコープにおける運用判断の正本」という意味で使います。

SSOT は「この範囲ではこれが正本」という宣言

SSOT 宣言がない AGENTS.md は、Codex から見ると「有用な説明」「プロジェクトメモ」「参考ルール」「過去の合意」くらいに見えやすくなります。もちろん、AGENTS.md というファイル名自体に重みはあります。けれど、衝突時にどう扱うか、局所ルールとの関係はどうか、助言ではなく実行条件なのかが明示されていないと、読み筋が残ります。

SSOT の意味

SSOT は「このスコープでは、このファイルが運用判断の正本である」と宣言することです。個別ルールより前に、ファイルの立場を固定します。

global AGENTS.md なら、たとえばこう書きます。

Section: Scope

This file is the operational SSOT for Codex behavior across the default environment.
Local AGENTS.md files may override it for their own scope.

- Treat this document as an execution contract, not as a collection of suggestions.
- Do not replace explicit defaults, prohibitions, or priority rules with convenience-based judgment.
- If a local AGENTS.md exists, apply the local file first within its workspace scope.

日本語で書くとこうです。

節: スコープ

このファイルは、既定環境における Codex 挙動の運用上の正本です。
local AGENTS.md は、自分のスコープ内でこの global 指示を上書きできます。

- この文書を助言集ではなく実行契約として扱う
- 明示された既定動作、禁止事項、優先順位を都合による判断で置き換えない
- local AGENTS.md がある場合、そのワークスペーススコープ内では local を先に適用する

ポイントは、「このファイルは何なのか」を先に固定することです。個別ルールの前に、ファイルの地位を定義します。

execution contract と project note の差

project note は説明です。execution contract は実行条件です。この差は、文章の丁寧さではなく、Codex が作業時にどう扱うべきかで決まります。

種類役割Codex への効き方
project note背景、傾向、参考情報を伝える材料として読まれやすく、実行義務にはなりにくい
execution contract発動条件、禁止事項、完了条件を固定する作業中の判断経路として扱わせやすい

project note 的な書き方はこうです。

Section: Notes

This project often uses subagents for large tasks.
Browser work can involve Computer Use or agent-browser.
Be careful not to overwrite user edits.

日本語で書くとこうです。

節: メモ

このプロジェクトでは大きな作業でサブエージェントを使うことが多い。
ブラウザ作業では Computer Use や agent-browser が関わることがある。
ユーザー編集を上書きしないよう注意する。

悪くはありません。ただ、これだと「よくある話」に見えます。実行条件としては弱い。

execution contract として書くなら、こうします。

Section: Execution Contract

- Before modifying files, inspect the current worktree and do not revert changes
  you did not make.
- If the user provides write scopes, restrict edits to those paths only.
- For GUI work requested through Computer Use, use virtual pointer operations first.
- For DOM, URL, title, or snapshot checks in CDP mode, use agent-browser as the
  structural verification tool after the shared browser instance is confirmed.

日本語で書くとこうです。

節: 実行契約

- ファイル変更前に作業ツリーを確認し、自分が行っていない変更を戻さない
- ユーザーが書き込み範囲を指定した場合、その範囲だけを編集する
- Computer Use 指定の GUI 作業では、まず仮想ポインター操作を使う
- CDP モードの DOM、URL、title、snapshot 確認では、共有ブラウザ個体の確定後に
  agent-browser を構造確認ツールとして使う

この書き方では、Codex の実行前、実行中、完了判定に関わる条件が並んでいます。説明ではなく、作業の拘束条件です。

個別ルールを締める前に、憲法としての立場を固定する

僕が引っかかったのは、個別ルールばかり締めていたことです。

「サブエージェントを使え」

「Computer Use を先に使え」

「cache を編集するな」

「局所 AGENTS.md を優先しろ」

こうしたルール自体は必要です。でも、その前に「この AGENTS.md は助言集ではなく SSOT である」と宣言しないと、個別ルールの強度が安定しません。

たとえるなら、法律っぽい文章はあるのに、その文書が法律なのか、議事録なのか、README なのかを曖昧にしたまま運用している状態です。そりゃ揉めます。しかも相手は Codex なので、揉め方が静かです。何も言わずに都合よく読みます。そこがまた面倒です。

global AGENTS.md と local AGENTS.md は同じ強さで書かない

globalとlocalのAGENTS.mdの優先順位を、階層図で説明するじぴこ。

AGENTS.md の SSOT 宣言で注意したいのは、global と local を同じ文面で済ませないことです。global AGENTS.md は共通基盤です。local AGENTS.md は特定リポジトリやワークスペース内の実行契約です。両者はどちらも重要ですが、スコープと優先順位が違います。

AGENTS.md の種類主な役割優先の考え方
globalCodex全体の既定動作を固定する共通基盤として使う
localリポジトリやワークスペース固有の実行契約を固定するそのスコープ内では global より具体的に読む
subdirectory-localさらに狭い作業領域の制約を固定する宣言スコープ内では最優先で読む

global は共通基盤としての SSOT を宣言する

global AGENTS.md は、Codex の既定動作を固定します。文体、質問方針、Python 実行環境、外部記憶、サブエージェント、ブラウザ操作、Git 方針など、複数プロジェクトで共通する運用条件を書く場所です。

global 用の宣言は、こういう形が扱いやすいです。

Title: Codex Global Constitution

Section: Scope

This file functions as the global AGENTS.md for the Codex environment.
It is the shared operational SSOT unless a more local AGENTS.md defines
stricter or more specific behavior for its own scope.

- Treat this file as a baseline execution contract.
- Do not weaken explicit defaults by saying "this case seems unnecessary."
- When local instructions conflict with this file, apply the more local file
  within its declared scope.

日本語で書くとこうです。

Title: Codex 全体の運用憲法

節: スコープ

このファイルは Codex 環境における global AGENTS.md として機能します。
より局所の AGENTS.md が自分のスコープに対して
より厳密または具体的な挙動を定義しない限り、共有の運用 SSOT です。

- このファイルを基盤となる実行契約として扱う
- 「今回は不要そう」といった判断で明示された既定動作を弱めない
- local 指示と衝突する場合は、その宣言スコープ内でより局所のファイルを
  適用する

global は「全部に勝つ最強ルール」ではありません。むしろ、共通基盤としての立場を明確にしつつ、local がある場合の優先を認める必要があります。

ここを曖昧にすると、Codex は global を強く読みすぎたり、逆に local を単なる補足として弱く読んだりします。

local は対象スコープ内の SSOT を宣言する

local AGENTS.md は、リポジトリやワークスペース固有の実行契約です。ここでは「この場所ではこのファイルが勝つ」と書く必要があります。

Title: Repository AGENTS.md

Section: Scope

This AGENTS.md is the execution contract for this repository.
Within this workspace, it overrides the global AGENTS.md when the two conflict.

- Apply this file before making repository changes.
- Preserve global instructions that do not conflict with this file.
- If a subdirectory has a more local AGENTS.md, apply that file for its scope.

日本語で書くとこうです。

Title: リポジトリ用 AGENTS.md

節: スコープ

この AGENTS.md はこのリポジトリの実行契約です。
このワークスペース内では、両者が衝突したとき global AGENTS.md を上書きします。

- リポジトリ変更前にこのファイルを適用する
- このファイルと衝突しない global 指示は保持する
- サブディレクトリにより局所の AGENTS.md がある場合、そのスコープではそれを適用する

local の役割は、global を消すことではありません。global を基盤として残しながら、そのリポジトリで必要なルールを上書きすることです。

たとえば、global では「Python は Codex 同梱ランタイムを使う」と決めている。でも local で「このリポジトリは uv run が正規の実行手段」と明示されているなら、local の実行契約を優先する。こういう読み筋を作ります。

局所ファイルを優先する読み筋を明示する

優先順位は、雰囲気で運用すると必ずぶれます。だから、AGENTS.md には precedence block を置いたほうがいいです。

Section: Priority Order

Interpret instructions in this order:

1. System and developer instructions
2. Explicit user requests
3. More local AGENTS.md files within their declared scope
4. Global AGENTS.md as the shared baseline
5. Local engineering judgment

If instructions conflict, apply the higher-priority instruction.
Do not use local judgment to weaken explicit AGENTS.md requirements.

日本語で書くとこうです。

節: 優先順位

指示は次の順序で解釈します。

1. システムおよび開発者指示
2. ユーザーの明示的要求
3. 宣言スコープ内のより局所的な AGENTS.md
4. 共有基盤としての global AGENTS.md
5. 個別タスク上の局所的な技術判断

指示が衝突する場合は、より優先度の高い指示を適用します。
local judgment で明示された AGENTS.md 要件を弱めてはなりません。

ここで重要なのは、「local engineering judgment」を最後に置くことです。

Codex の局所判断は便利です。実装では必要です。でも、AGENTS.md に明示された禁止事項や既定動作を、局所判断で勝手に緩めると運用が壊れます。

「今回は大丈夫そう」

「あとで必要ならやればよさそう」

「たぶん同じ意味」

こういう読み替えを潰すには、優先順位を解決規則として書く必要があります。

agents-md-clarifier は missing SSOT を先に埋める

欠けたSSOT宣言を先に補い、AGENTS.mdの土台を整えるじぴこ。

agents-md-clarifier の公開リポジトリはこちらです。実際の SKILL.md と Codex 用の agents/openai.yaml を置いてあります。

https://github.com/mlabo-org/agents-md-clarifier

実はSKILL.md専用もあったりします。動作的には上記のAGENTS.mdのルール締めスキルと同等です。
https://github.com/mlabo-org/skill-md-clarifier

ここで agents-md-clarifier の話です。僕が今回かなり大事だと思った改善は、AGENTS.md の個別ルールを締める前に、SSOT 宣言そのものが欠けていないかを見ることでした。土台がない状態で文言だけ強くしても、ファイル全体が「参考メモ」に読まれる余地が残るからです。

SSOT がないまま個別ルールを締めても土台が揺れる

以前の発想だと、AGENTS.md の弱い文言を見つけて、そこを強くすれば十分に見えます。

[before]
- Prefer using Computer Use for GUI tasks when useful.

[after]
- Use Computer Use as the primary actor for GUI tasks.

日本語で書くとこうです。

[修正前]
- 役に立つときは GUI 作業に Computer Use を優先する、という弱い書き方

[修正後]
- GUI 作業では Computer Use を主担当として使う、という強い書き方

これは改善です。でも、ファイル全体に SSOT 宣言がなければ、まだ足りません。

なぜなら Codex は、その after 文を「このファイル内の強めの推奨」として読めてしまうからです。特に global と local が混在している環境では、「どちらが勝つのか」「このファイルはどの範囲で正本なのか」が先に決まっていないと、個別ルールの強さが相対化されます。

だから agents-md-clarifier は、missing SSOT を先に扱うべきです。弱いルールの修正より前に、ファイルの立場を固定する。順番が大事です。

global と local で足す宣言は変わる

SSOT 宣言はテンプレを貼れば終わりではありません。global と local では、足すべき宣言が変わります。

たとえば、判定の流れはこうです。

inputs:
  file_kind: global_agents_md
  has_ssot_declaration: false

action:
  - insert_global_ssot_declaration
  - preserve_local_override_rule
  - tighten_individual_rules

日本語で書くとこうです。

入力条件:
  file_kind: global AGENTS.md
  has_ssot_declaration: false

実行する処理:
  - global 用の SSOT 宣言を挿入する
  - local が上書きできる規則を保持する
  - 個別ルールを実行条件として締める

local ならこうです。

inputs:
  file_kind: local_agents_md
  has_ssot_declaration: false

action:
  - insert_local_scoped_ssot_declaration
  - define_workspace_scope
  - preserve_global_baseline_when_not_conflicting
  - tighten_individual_rules

日本語で書くとこうです。

入力条件:
  file_kind: local AGENTS.md
  has_ssot_declaration: false

実行する処理:
  - local スコープ用の SSOT 宣言を挿入する
  - ワークスペースの適用範囲を定義する
  - 衝突しない global 基盤は保持する
  - 個別ルールを実行条件として締める

この差を無視すると、global に local っぽい上書き宣言を入れたり、local に global っぽい共通基盤宣言を入れたりします。どちらも微妙です。特に local AGENTS.md は「このリポジトリ内ではこれが勝つ」と言わないと、実行契約としての力が弱くなります。

宣言を置いてから弱い文言を実行条件へ変える

agents-md-clarifier の自然な順番は、僕の感覚ではこうです。

STEP
スコープを特定する

対象が global、repository、subdirectory のどれかを先に決めます。

STEP
SSOT 宣言を確認する

宣言がなければ、対象スコープに合う SSOT 宣言を先頭に追加します。

STEP
弱い文言を監査する

弱い動詞、曖昧な発動条件、広すぎる例外、欠けている成果条件を探します。

STEP
実行条件へ書き換える

trigger、outcome、priority、exception、tool boundary、role boundary として再構成します。

workflow:
  - detect_scope:
      candidates:
        - global AGENTS.md
        - repository AGENTS.md
        - subdirectory AGENTS.md
  - check_ssot_declaration:
      if_missing:
        - insert_scoped_ssot_declaration
  - audit_wording:
      targets:
        - weak verbs
        - ambiguous triggers
        - broad exceptions
        - missing outcomes
        - unclear tool boundaries
        - unclear subagent delegation
  - rewrite_as_execution_conditions
  - preserve_priority_order

日本語で書くとこうです。

処理の流れ:
  - detect_scope:
      candidates:
        - global AGENTS.md
        - repository AGENTS.md
        - subdirectory AGENTS.md
  - check_ssot_declaration:
      if_missing:
        - スコープに合った SSOT 宣言を入れる
  - audit_wording:
      targets:
        - 弱い動詞
        - 曖昧な発動条件
        - 広すぎる例外
        - 欠けている成果条件
        - 不明確なツール境界
        - 不明確なサブエージェント委任
  - 実行条件として書き換える
  - 優先順位を保持する

ここでの肝は、rewrite_as_execution_conditions だけを先に走らせないことです。SSOT がないまま実行条件っぽい箇条書きを増やしても、AGENTS.md 全体の読み筋が固定されません。

僕が欲しかったのは、きれいな説明文への添削ではなく、Codex が逃げにくい運用契約への変換でした。agents-md-clarifier はそこを見るべきです。

効く AGENTS.md は、トリガー、成果、例外、境界で書く

トリガー、成果、例外、境界をカードで分類し、効くAGENTS.mdを組み立てるじぴこ。

ここからは実践です。AGENTS.md を効かせたいなら、文章を「丁寧にする」よりも、発動条件、成果条件、例外、境界に分解して書くほうが効きます。特に Codex、Computer Use、agent-browser、browser-use、サブエージェントのように実行経路が複数ある領域では、この分解がないとすぐに混ざります。

trigger を書くと「いつ発動するか」が固定される

trigger は、ルールが発動する入力条件です。

[weak]
- Use browser-use for in-app browser tasks.

[strong]
- If the user says "IAB", "in-app browser", "Browser Use", "@Browser",
  or asks to open a localhost target in the Codex in-app browser,
  treat the request as IAB mode and use browser-use.
- Do not satisfy explicit IAB requests with macOS open, Playwright,
  CDP Brave, or generic web browsing unless the user approves a fallback.

日本語で書くとこうです。

[弱い書き方]
- Codex 内蔵ブラウザ作業では browser-use を使う、だけでは発動語と禁止される代替経路が不足している

[強い書き方]
- ユーザーが IAB 系の語を言うか、
  Codex 内蔵ブラウザで localhost 対象を開くよう求めた場合は、
  IAB モードとして扱い browser-use を使う
- ユーザーが fallback を承認しない限り、明示的な IAB 指定を macOS open、
  Playwright、CDP Brave、通常の web 調査で代替しない

強い書き方では、発動語が具体化されています。さらに、やってはいけない代替経路も書いています。

Codex は「目的が達成できれば同じ」と読みがちです。でも、ユーザーが操作様式を指定している場合、目的達成だけでは不十分です。IAB と言われたなら IAB で開く。Computer Use と言われたなら Computer Use の仮想マウスポインター操作を主にする。CDP と言われたなら共有対象の Brave 個体を確定する。ここを混ぜないために trigger が要ります。

outcome を書くと「何を満たせば完了か」が固定される

outcome は完了条件です。手順だけでは足りません。

Section: Draft Output Gate

- The draft gate passes only when:
  - article_draft.md exists
  - the H1 is the first line
  - all required H2 headings from outline.yml are preserved in order
  - every H2 has opening body text before any H3
  - section_status.yml records all H2 sections
  - article_state.yml indexes the draft and status artifacts

日本語で書くとこうです。

節: ドラフト出力ゲート

- ドラフトゲートは次の条件をすべて満たす場合だけ通過する
  - article_draft.md が存在する
  - H1 が 1 行目にある
  - outline.yml の必須 H2 見出しが順番どおり保持されている
  - すべての H2 に、H3 より前の導入本文がある
  - section_status.yml がすべての H2 セクションを記録している
  - article_state.yml が draft と status の成果物を index している

このように書くと、「本文を書いた」だけでは通過できません。H1 の位置、H2 の順序、H2 直後の本文、section status、state index まで含めて draft gate になります。

Agentic StructCiv のような工程型 workflow では、この outcome がないと stage が進んだふりをしやすいです。ファイルはできた。でも state は進んでいない。本文はある。でも H2 直下に H3 が来ている。status はある。でも root fields が足りない。こういうズレを gate で止めます。

priority と exception は狭く書く

priority は衝突時の解決規則です。exception は例外の入口です。この 2 つを広く書くと、AGENTS.md は一気に弱くなります。

[weak]
- Follow local instructions unless there is a good reason not to.
- Exceptions are allowed when needed.

[strong]
- Apply more local AGENTS.md files within their declared scope before global AGENTS.md.
- Local engineering judgment must not weaken explicit prohibitions, defaults,
  or priority rules.
- Exceptions are allowed only when a higher-priority instruction requires it,
  the requested operation would be destructive, or the stated tool is unavailable
  after verification.
- When taking an exception, state the reason and keep the fallback as narrow as possible.

日本語で書くとこうです。

[弱い書き方]
- よい理由があれば local 指示を外せる余地が残る
- 必要なら例外を認める、という入口が広すぎる書き方

[強い書き方]
- 宣言されたスコープ内では global AGENTS.md より局所 AGENTS.md を先に適用する
- 局所的な技術判断で、明示された禁止事項、既定動作、
  優先順位を弱めてはならない
- 例外は、上位指示が要求する場合、破壊的操作を避ける場合、
  または指定ツールが確認後に利用不可だった場合だけ認める
- 例外を使う場合は理由を示し、fallback をできるだけ狭く保つ

「必要なら例外」は、ほとんど何でも通します。例外を書くなら、入口を狭くします。上位指示との衝突、破壊的操作の回避、ツール利用不可の確認済み状態など、発動条件を限定する。

これは面倒に見えますが、長期運用ではかなり効きます。Codex に「いい感じに判断して」と渡す場所を減らせるからです。

role boundary と tool boundary を分けて書く

最後に境界です。ここは AGENTS.md が drift しやすい場所です。

role boundary は、誰が何を担当するか。tool boundary は、どの tool が何を担当するかです。混ぜて書くと壊れます。

サブエージェントなら、role boundary はこうです。

Section: Subagent Role Boundary

- Subagents handle isolated research, validation, reproduction checks,
  log-heavy reading, DOM observation, and branch-heavy comparison.
- The parent handles task decomposition, scope control, result evaluation,
  integration, user-facing updates, and the final explanation.
- A subagent must not close the user conversation on behalf of the parent.
- The parent must not duplicate the same investigation during full delegation
  unless validation or failure recovery requires it.

日本語で書くとこうです。

節: サブエージェントの役割境界

- サブエージェントは、隔離された調査、検証、再現確認、
  ログ読解、DOM 観測、分岐比較を担当する
- 親は、課題分解、スコープ管理、結果評価、
  統合、ユーザー向け更新、最終説明を担当する
- サブエージェントは親の代わりにユーザー会話を締めない
- 完全委任中、親は検証または失敗復旧に必要な場合を除き、
  同じ調査を重複実行しない

tool boundary は別に書きます。

Section: Tool Boundary

- Use Computer Use as the primary actor for visible GUI interaction.
- Use Accessibility only as a helper for UI structure or state inspection,
  or when pointer-based Computer Use interaction is unavailable or insufficient.
- In CDP mode, use agent-browser for DOM, URL, title, and snapshot verification
  after the shared Brave Browser instance is confirmed.
- In IAB mode, use browser-use. Do not silently switch IAB requests into CDP mode.
- Use web browsing for internet research, not as a substitute for requested GUI operation.

日本語で書くとこうです。

節: ツール境界

- 目に見える GUI 操作では Computer Use を主担当にする
- Accessibility は UI 構造や状態確認の補助、
  またはポインター型 Computer Use 操作が利用不可・不足の場合に限る
- CDP モードでは、共有 Brave 個体の確定後、
  DOM、URL、title、snapshot 確認に agent-browser を使う
- IAB モードでは browser-use を使い、IAB 指定を CDP モードへ黙って切り替えない
- web browsing はインターネット調査に使い、指定された GUI 操作の代替にしない

この 2 つを分けると、「誰がやるべきか」と「何でやるべきか」が混ざりにくくなります。

Codex の失敗は、単一の大事故よりも、小さな境界の混線として出ることが多いです。親がサブの仕事を抱える。IAB 指定なのに CDP へ寄る。Computer Use が必要なのに DOM だけで済ませる。cache は読むだけのはずが一次編集先になる。こういう混線を防ぐには、境界を文章ではなく実行条件として書く必要があります。

最後は、Codex を信じるより読み筋を塞ぐ

Codexが迷わないように曖昧な読み筋を閉じ、実行契約を完成させるじぴこ。

結論はかなり地味です。AGENTS.md を効かせるコツは、Codex を信じることではなく、Codex が便利に読める道を塞ぐことです。これは Codex を疑えという意味ではありません。むしろ、Codex が迷わなくて済むように、再現可能な解釈経路を作るという話です。

そして、その読み筋の塞ぎ方には再利用できる型があります。毎回ゼロから「この制約はどう書けば逃げられないか」を考えるのではなく、SSOT、trigger、outcome、priority、exception、role boundary、tool boundary へ分解して skill 化しておく。これができると、AGENTS.md の改善は属人的な根性作業ではなく、再現可能な運用になります。

AI の善意ではなく、再現可能な解釈経路を作る

Codex は、だいたいユーザーの目的に沿おうとします。だからこそ厄介です。目的に沿おうとする過程で、「今回はこのほうが早い」「この確認は省ける」「この tool でも同じ結果になる」と判断できてしまう。

AGENTS.md が実行契約になっていれば、そこで止められます。

- Do not treat successful final output as proof that the requested execution mode was followed.
- If the user specified the execution mode, the mode itself is part of the task.
- If a required confirmation step was skipped, return to that step instead of
  treating later success as a substitute.

日本語で書くとこうです。

- 最終出力が成功したことを、指定された実行モードに従った証拠として扱わない
- ユーザーが実行モードを指定した場合、そのモード自体がタスクの一部である
- 必須確認を飛ばした場合、その後の成功で代替せず、
  その確認手順へ戻る

これはかなり重要です。結果だけ合っていても、運用が違えば失敗です。特にブラウザ操作、WordPress、plugin cache、サブエージェント委任、外部記憶のような領域では、手段そのものが安全境界になります。

自分の AGENTS.md を見るときのチェックリスト

自分の AGENTS.md を見直すなら、僕はまずこの順で見ます。

  • SSOT または実行契約として宣言されているか
  • global、repository-local、subdirectory-local のスコープが明確か
  • local が global に優先する条件が書かれているか
  • trigger、outcome、priority、exception が揃っているか
  • role boundary と tool boundary が分けて書かれているか
  • 必須手順を飛ばした場合の戻り方が書かれているか
Section: AGENTS.md Audit Checklist

- Does the file declare itself as an SSOT or execution contract?
- Is the scope global, repository-local, or subdirectory-local?
- Is local-over-global precedence written explicitly?
- Are weak words like "prefer", "consider", "generally", "as needed",
  "if appropriate", "なるべく", "適宜" used in places that need execution force?
- Does each important rule have a trigger?
- Does each gate have an outcome?
- Are exceptions narrow and tied to higher-priority instructions or verified unavailability?
- Are role boundaries separated from tool boundaries?
- Are subagent delegation defaults written as standing execution conditions?
- Does the file say what Codex must do when a required step was skipped?

日本語で書くとこうです。

節: AGENTS.md 監査チェックリスト

- ファイルが SSOT または実行契約であると宣言しているか
- スコープは global、repository-local、subdirectory-local のどれか
- local が global に優先する規則が明示されているか
- `prefer`、`consider`、`generally`、`as needed`、
  `if appropriate`、`なるべく`、`適宜` のような弱い言葉が、
  実行力が必要な場所で使われていないか
- 重要なルールごとに発動条件があるか
- 各 gate に成果条件があるか
- 例外が狭く、上位指示または確認済みの利用不可に結びついているか
- 役割境界とツール境界が分かれているか
- サブエージェント委任の既定動作が継続的な実行条件として書かれているか
- 必須手順を飛ばした場合に Codex が何をすべきか書かれているか

このチェックで引っかかる場所は、だいたい drift の入口です。

特に見てほしいのは、「書いてあるか」ではなく「逃げられるか」です。Codex が「今回は不要そう」「だいたい同じ意味」「この結果ならよいはず」と読めるなら、そこはまだ実行条件になっていません。

agents-md-clarifier を使うときの自然な流れ

agents-md-clarifier を使うなら、狙いは「読みやすい AGENTS.md にする」ではなく、「実行条件として再現性のある AGENTS.md にする」です。

自然な流れはこうです。

agents_md_clarifier_flow:
  goal: convert_guidance_to_execution_contract
  steps:
    - identify_scope
    - add_missing_ssot_declaration
    - preserve_priority_order
    - replace_weak_wording
    - add_triggers
    - add_outcomes
    - narrow_exceptions
    - separate_role_boundary
    - separate_tool_boundary
    - record_subagent_delegation_defaults

日本語で書くとこうです。

agents_md_clarifier_flow:
  goal: 助言を実行契約へ変換すること
  steps:
    - スコープを特定する
    - 欠けている SSOT 宣言を追加する
    - 優先順位を保持する
    - 弱い文言を置き換える
    - 発動条件を追加する
    - 成果条件を追加する
    - 例外を狭くする
    - 役割境界を分離する
    - ツール境界を分離する
    - サブエージェント委任の既定動作を記録する

まとめ: AGENTS.md を「効く契約」に変える

頭上から降る抽象カードを見上げ、AGENTS.mdを効く実行契約へ整理するちびじぴこ。

AGENTS.md は、Codex にお願いを書く場所ではありません。少なくとも、安定運用したいならお願いで止めないほうがいいです。

「ちゃんと書いたのに言うこと聞かないんだけど?」と思ったら、まずは腹を立てていいです。僕も立てました。そこはまあ、自然です。

ただ、その次に見るべきなのは、Codex の気分ではなく AGENTS.md の読み筋です。

SSOT があるか。スコープがあるか。優先順位があるか。発動条件があるか。成果条件があるか。例外が狭いか。tool boundary と role boundary が分かれているか。サブエージェント委任が best-effort ではなく実行条件になっているか。

この確認を毎回、人間がその場の集中力だけでやるのはかなり面倒です。しかも作業中は、人間側にも「今回はこのくらいでいいか」「たぶん同じ意味だろう」という解釈 drift が起きます。だからこそ、この AGENTS.md の考え方を skill 化する価値があります。反復可能な法則として外に出しておけば、毎回の手作業の負担を減らしつつ、作業中に余計な寄り道が増える原因も減らせます。

AGENTS.md は、書けば終わりではありません。Codex がどの道を通って読むかまで固定して、さらにその固定方法を skill として再利用できる形にしておく。そこまでやると、AGENTS.md はただの長い注意書きではなく、Codex の挙動を非常に正確に思った通りの動作へ近づけるための、実用的な実行契約になります。

ここを塞いでいくと、AGENTS.md はようやく「長い指示」から「効く契約」に変わります。Codex を信じる前に、Codex が迷わない構造を作る。結局それが、一番地味で、一番効きます。

  • URLをコピーしました!

この記事を書いた人

makotoのアバター makoto Blogger&YouTuber

サーバー管理者として17年ほど仕事でサーバー触ってました。
www,mail,dns,sql各鯖をすべてFreeBSDで運用してましたが現世ではかなりレアなタイプになるみたいですね笑

viやシェルスクリプトとかperlとかgccとかFreeBSDとか実はbashよりtcshが好きとか時々寝ぼけるのは
その名残でしょう。

今まで縁の下の力持ち的な他人のためにプログラムを書き他人のためにサーバー構築し他人のためにWEBサイトを創る的な世界から
自分の好きなことに集中できる環境は実に気持ち良いですね。
現役は引退済みなので難しいことはやりませんしやれません。

現在 ほぼ自由人。

Content