ルールを文書に足しても違反は減らなかった。コードに落とした8件だけ再発0だった

Posted at 2026-09-22

AIエージェントに守らせたいルールがある。まずAGENTS.mdに書く。守られない。もっと詳しく書く。まだ守られない。条文を増やす。

48日間そうやって運用した結果、常駐指示ファイルは 90KB から 147KB になりました。

そして違反は減りませんでした。

数字を出します。すべて自分の環境1台の実測です（n=1）。

1. トークンの 94.4% は「同じテキストの読み直し」だった

まず、指示ファイルを増やすとコストがどう動くか。48日間の集計です。

常駐指示は4ファイルで 204,309 バイト。これが毎ターン再注入されます。

つまり「累計トークン量」はエージェントの作業量ではなく、指示ファイルの長さ × ターン数の関数です。ここを自分の稼働規模の指標に使うと、指示を長く書いた人ほど「よく使っている」ように見えてしまいます。

キャッシュヒット率 99.3% も同じで、効率の証拠ではなく「同じ文脈を繰り返し投げている」証拠でした。

自分の環境には、指摘を受けるたびにルール単位で回数を数える仕組みを入れてあります。「どの条文が何回破られたか」を記録するだけの小さなスクリプトです。

条文を書き足した後もカウンタは止まりませんでした。むしろ、前日に新設した条文が翌日に破られるということが起きました。

条文を増やすことは解決ではなく、症状でした。

記録されている24ルールは、たまたま2群に分かれていました。

同じ環境、同じエージェント、同じ期間です。

群	ルール数	再発したルール	累計再発回数	ルールあたり
A: コードゲートあり	8	0件（0%）	0回	0.00
B: 文書の条文のみ	16	16件（100%）	19回	1.19

B群は全滅でした。16件すべてが最低1回は再発しています。

A群はゲート設置後、無再発ターン数が 2,500〜4,053ターン 続いています。

反論を2つ検討します。

反論1: 選択バイアス。ゲートを付けたのは元々ひどいルールでは？

その通りです。運用上、同じ違反が3回を超えたものだけコードに落とす決まりにしています。つまりA群はもともと最も再発しやすかった8件です。それが0回になっているので、バイアスは結論を弱めるのではなく強める方向に働きます。

反論2: 逆因果。ゲート設置時点ですでに学習が終わっていたのでは？

これは否定できません。「3回目でゲートを付ける」という手順自体が、時間の経過と相関します。ただ、B群にも2回再発したまま止まっていないルールが3件あり、時間だけでは説明がつきません。

反論3: そもそも文書を読んでいないのでは？

読んでいます。204KBは毎ターン全量がコンテキストに入っています。読んだ上で守られていない、というのがこの測定の意味です。

指摘を受けるたびにキューへ積み、条文化まで追跡する仕組みも動かしています。累計の内訳です。

却下率 49.8%。 拾った学習シグナルの半分が条文にならずに消えています。そして「人の判断待ち」が63件溜まっている。自動化したつもりの仕組みが、結局人間をボトルネックにしていました。

ルールの置き場所を3段階に分けました。

3段階目が重要でした。「条文を直しました」で閉じられる限り、同じ違反が4回目に来ます。

上位3件だけを注入するのも意図的です。件数を増やすと、また読まれなくなります。読まれない条文を増やしたことがそもそもの原因だったので。

正直に書いておきます。

n=1 です。 1台の環境、1人の運用です。他の環境で再現するかは分かりません。
ゲートの精度を測っていません。 回帰テストの判定器自体に、1サンプルでの誤検知率66%という測定があります（確定と報告された回帰3件のうち2件が3サンプル再測定でPASS）。ゲートが正しく動いているかの検証はこれからです。
「守られた」の定義が弱い。 再発カウントは人間の指摘が起点です。指摘されなかった違反は数えられていません。実際の違反率はこれより高いはずです。

自分のマシンで同じ測定をした人がいたら、数字を見たいです。特にB群の再発率が環境によって変わるのかどうか。

この計測は untactit を作る過程での実測です。AIエージェントが読むスキル・指示・メモリを一箇所で管理する control plane で、現在アーリーアクセスです。ドリフト検出の部分は agent-drift としてMITで公開しています（依存なし・単一ファイル）。