エージェントに読ませる規約を、規約自身の基準で検査しました。出てきたのは、動いていた仕組みが動かなくなったのに文章だけが残っていたもの、機械で守れるかだけを見て要否を考えていなかったルール、そして直したはずが直っていなかった修正です。
GitHubGitHub - LabeeHive/standards: Shared standards repository for Labee LLC projects — a Claude Code plugin marketplace of skills, agents, and workflowsShared standards repository for Labee LLC projects — a Claude Code plugin marketplace of skills, agents, and workflows - LabeeHive/standards「自動で読み込まれる」が事実でなくなっていた
スキルには参照ファイルを添えられます。長い手順や判断基準を SKILL.md 本体から切り出して置く場所です。
そのうち、必ず読ませたいものには接頭辞 _ を付ける規約にしていました。読み込ませるための印です。8つのスキルが、その参照について「これは自動で読み込まれるので、明示的に読む必要はない」とエージェントに伝えていました。
実際に呼び出して測ったところ、Skillツールが返すのは SKILL.md だけでした。参照の中身は届いておらず、エージェントは自分でファイルを開くまで1行も引用できません。
問題は、規約が最初から嘘だったことではありません。書いた時点では読み込まれていて、モデルの更新で読み込まれなくなり、文章だけが残ったという順序です。仕組みが変わったのに、それを説明する文章が追随しませんでした。
実害は出ていませんでした。エージェントはどのみちファイルを開くからです。それでも直した理由が、コミットの本文に書いてあります（訳は筆者）。
実害は出ていない。エージェントはどのみちファイルを開くからだ。しかし、事実でないのに「これはもうここにある」と言う指示は、素直な読み手がまさに間違える種類のものだ。
素直に読む相手に対して、事実でないことを言っている。それだけで直す理由になります。該当の8つは「このファイルを、この時点で読むこと」という書き方に変えました。
ルールが守れるかと、要るかは別の問い
同じ夜に、文書のリンターの設定も見直しています。きっかけは行の長さでした（以下も訳は筆者）。
決め手は行長だった。もとのファイルから引き継がれ、その日の全パスを生き延びたのは、ルールをツールで検査できるかしか問わず、そのルールが存在すべきかを一度も問わなかったからだ。
折り返しは、文書がどう表示されるかを何も変えません。それでいてハード折り返しを強制すると、1語直すだけで以降の全行が流れ直し、差分が変更を実際より大きく見せます。このルールを外したことで、指摘が192件消えました。
同じ問いを他のルールにも当てて、4つが退役しました。表の余白の統一は、どちらかに揃えるだけで577件か1,134件の機械的な編集が発生して、得るものがない。コードブロックの言語指定は、本物のコードならハイライトで元が取れる一方、ASCIIの図に text と付けさせるのは有用なルールを儀式に変えるだけでした。
エージェントに規約を守らせようとすると、判定できるルールばかりを足しがちになります。判定できることと、判定する価値があることは別です。
直したはずが直っていなかった
その直後に、もう一度同じ文書を監査しています。前回の修正を信用せず、検査し直す形です。
2回目の監査は、前回の修正をそのまま信じるのではなく検査した。10件のうち6件は持ちこたえたが、残りは解決ではなく言い換えられていただけで、しかもそのパス自体が新しい問題を持ち込んでいた。
出てきたものが、規約の自己記述の誤りとして分かりやすいものでした。
- 設定の説明が「ルールを有効化することはなく、オプションを取るものを固定するだけ」と書いていた。実際には16項目のうち7つが無効化されていた
- 「知っておくべき4項目」と書いてあったが、実際は7つあった
- 「何にも強制されていない」という見出しの節に、既定で有効な2つのルールが入っていた
- 言語指定を「常に付ける」と書いた文書が、自分自身では言語指定なしのコードブロックを使っていた
最後のものが厄介です。片方の文書は「常に付けろ」と言い、もう片方はそのルールを切る決定を記録している。両方を渡されたレビュアーには、どちらが標準なのか判定できません。
直した回数ではなく、直っているかを測る
3つに共通しているのは、書いた本人の申告を検査していなかったことです。
「自動で読み込まれる」は、書いた時点では正しかったので疑われませんでした。リンターのルールは、機械が判定できるので通っていました。修正の1回目は、修正したという事実だけで完了とみなされました。
対策は、いずれも同じ形になりました。実際に呼び出して何が返るかを測る、ルールを外したら指摘が何件消えるかを数える、修正後にもう一度独立して監査する。申告ではなく結果を見るという一点です。
エージェントに読ませる文書は、この検査から漏れやすいところにあります。コードなら型検査もテストも通りますが、規約の文章が現実と食い違っても何も落ちません。読み手が素直であるほど、書いてあるとおりに間違えます。
環境が動くことは前提に入っていなかった
いちばん効いた発見は、規約が古くなる経路が2つあることでした。
1つは、こちらが変えたのに文章を直し忘れる場合です。これは撤回した決定の伝播漏れと同じ話で、対処の仕方も分かっています。
ブログエージェントが決めたADRを撤回する設計判断をADRとして積む運用で、サブエージェントが「ユーザー決定」と書いて自分で起票したADRが混ざりました。本文を書き換えず撤回ADRを足して取り消し、ADRには誰が決めたかを書かせる規約を足した話です。もう1つが、今回のものです。こちらは何も変えていないのに、足元の仕組みが変わって記述が事実でなくなる。書いた時点では正しく、レビューでも通り、それでも半年後には嘘になっています。
こちらには、今のところ検出の仕組みがありません。モデルやツールの更新のたびに、規約が前提にしている挙動を測り直す必要がありますが、どの記述がどの挙動に依存しているかの一覧を持っていません。「この参照は自動で読み込まれる」が挙動への依存だと気づけたのは、たまたま疑って測ったからです。
依存しているものを先に列挙しておけば、次は測り直すだけで済みます。まずはその一覧から作ります。