AIエージェントに守らせたいルールがある。まずAGENTS.mdに書く。守られない。もっと詳しく書く。まだ守られない。条文を増やす。
48日間そうやって運用した結果、常駐指示ファイルは 90KB から 147KB になりました。
そして違反は減りませんでした。
数字を出します。すべて自分の環境1台の実測です（n=1）。
まず、指示ファイルを増やすとコストがどう動くか。48日間の集計です。
| 項目 | 実測値 |
|---|---|
| 累計トークン | 62,250M |
| うちキャッシュ読み出し | 58,751M（94.4%） |
| 純粋な生成出力 | 185.9M（0.30%） |
| メッセージ数 | 268,766 |
| メッセージ1件あたりの読み直し | 約 219k トークン |
常駐指示は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は毎ターン全量がコンテキストに入っています。読んだ上で守られていない、というのがこの測定の意味です。
指摘を受けるたびにキューへ積み、条文化まで追跡する仕組みも動かしています。累計の内訳です。
| 状態 | 件数 |
|---|---|
| 条文に昇格 | 231 |
| 検証済み | 178 |
| 却下 | 229 |
| 未処理 | 12 |
| 人の判断待ち | 63 |
却下率 49.8%。 拾った学習シグナルの半分が条文にならずに消えています。そして「人の判断待ち」が63件溜まっている。自動化したつもりの仕組みが、結局人間をボトルネックにしていました。
ルールの置き場所を3段階に分けました。
3段階目が重要でした。「条文を直しました」で閉じられる限り、同じ違反が4回目に来ます。
上位3件だけを注入するのも意図的です。件数を増やすと、また読まれなくなります。読まれない条文を増やしたことがそもそもの原因だったので。
正直に書いておきます。
自分のマシンで同じ測定をした人がいたら、数字を見たいです。特にB群の再発率が環境によって変わるのかどうか。
この計測は untactit を作る過程での実測です。AIエージェントが読むスキル・指示・メモリを一箇所で管理する control plane で、現在アーリーアクセスです。ドリフト検出の部分は agent-drift としてMITで公開しています（依存なし・単一ファイル）。