strategy.mdをagentが守る3つの型

「strategy.md に書いたから、agent は守るはず。」そう思って私が 2026-07-09 に書いたルールは、7週間後にゲートを足して確認するまで、一度も適用されていませんでした。

私は harness-ops という自分の運営自動化リポジトリで、4つのドメイン (kenimoto-dev / zenn / qiita / devto) の agent を strategy.md で統率しています。11週間動かした結果、わかったのはこうです。agent は書いたルールの一部しか守りません。守る・守らない・時々守るの 3つの型があって、それぞれ対処が違います。

今日はその 3つの型を、実際の事故ログ付きで解剖します。

事例1: 書いたのに一度も適用されなかったルール

2026-07-09、私は strategy.md に「SERPタイトル長さルール」を書きました。EN は 60字、JA は 32字で検索結果が切れるので、新規記事のタイトルはそれ以内に収めるルールです。しっかり書きました。例まで添えました。

7週間後の 2026-08-26、既存記事のタイトルを lint-title スクリプトで一括検査しました。結果はこうでした。

タイトル中央値は EN 80字 (上限60) / JA 46字 (上限32)。agent が守った形跡がゼロです。

なぜゼロなのか。私は strategy.md に書いて満足して、「marketer が記事を書き終えたあとに lint を通す」ゲートを足していませんでした。agent は strategy.md を読んではいます。生成するタイトルを比較する手順がないだけです。読むのと測るのは別の仕事で、agent は後者を頼まれない限りやりません。

対処は decide-title スキルを独立させて、本文確定後に lint-title.py が自動で走るようにしました。★★★ が残っていたら公開を止めます。書くだけでは守らせられない、という事実を認めるのに 7週間かかりました。

事例2: 壊れた計測の上で判断していた期間

もう1件、もっと静かな失敗がありました。

Observer (GSC からデータを取る agent) が長らく dimensions: ["query", "page"] でクエリを混ぜて集計していました。GSC は検索ボリュームが極小のクエリを行ごと返しません (匿名化)。kenimoto.dev のようなロングテール依存サイトは、この次元で集計すると大半の表示が消えます。

実際の差はこうでした。

表示の 77% を数ヶ月間取りこぼしていました。 strategist はこの壊れた数字を基に「320/324本が表示ゼロ」と判定し、増産凍結の判断を下していました。agent は strategy.md の「増産凍結条件」を正しく守っています。基になる数字が壊れていただけです。

これは「書いたルールは守るが、計測が壊れていると agent は気づかない」型の典型です。agent は strategy.md の規範に対しては忠実で、入力データの質に対しては無防備です。strategy.md に「GSC の次元に注意」なんて書いても意味がありません。計測コードを別途テストするしかありませんでした。

事例3: 書けば守るが、暗黙の前提は破る型

2026-08の 21日間、strategist (リライト対象を選ぶ agent) が同じ2本の記事を延べ17回選出し続けました。strategy.md のルール上は正当です。「リライト候補の中から選ぶ」としか書いていなかったからです。

ただ、私の暗黙の前提は「同じ記事を 2-3日連続で選ぶのは変」でした。前回のリライトが Google に再インデックスされる前に次を重ねれば、効果の計測ができません。実測では pos 7.4 → 7.5 とほぼ動かず、clicks は 0 のままでした。副作用として EN 新規枠が食われ、8/18・8/21・8/22 の 3日は新規記事ゼロでした。

対処は strategy.md に「直近14日以内に更新した記事は Observer が候補から自動で外す」ルールを追加しました。agent 側ではなく Observer 側で物理的に候補リストから消す。書けば守るタイプの agent は、書いたとおりにしか動けないので、書き落とした前提は破ります。暗黙を全部明示する覚悟がないなら、ゲートで物理的に不可能にするほうが早いです。

11週間で見えた3つの型

事例を整理するとこうなります。

共通するのは、「strategy.md を書く」だけでは守らせられないことです。agent が守るのは、書かれた規範ではなく、ゲートがあるルールと、壊れていない計測の数字です。書いた瞬間に守られる前提で設計すると、7週間経ってから既存記事の 91% が上限超過に気づく、みたいな事故が起きます。

いまの harness-ops は、strategy.md のルール 1項目ごとに「どの Phase で検査するか」をコメントで併記するように変えつつあります。書いたルール数と、実際に走る検査スクリプトの数が同じになるまで、「書けば守る」とは言えません。

関連する角度の記事として、却下ログを「学習信号」として拾う仕組み と 自己進化エージェントを3ヶ月動かした話 もあります。前者は暗黙知を strategy.md に書き足していく側、後者は agent が strategy.md を書き換える側の話で、本記事とは別軸です。

まとめ

• strategy.md に書いただけでは、agent はほぼ守らない。守る・守らない・時々守るの 3つの型がある
• 「書けば守る」agent は、書いた前提にしか従わない。暗黙の前提はゲートで物理的に強制する
• 計測が壊れていると、agent は strategy.md に忠実なまま誤った判断を下す。計測コードを別途テストする
• 生成物の長さ・形式ルールは「読む」のとは別工程で、生成後の lint が無い限り守られない

ハーネス運用の設計パターンをまとめた本を書いています。

ハーネスエンジニアリング実践ガイド