私は AI の出力を、もうほとんど読んでいません。AI が出力するテスト結果も、AI が書き足す知見メモ（メモリ）も、メインの会話を引き継がずに別に立ち上げた AI（サブエージェント）の作業ログも読んでいません。読んでいないのは私だけではなく、AI 自身も、自分の出力を読まずに済む形にしてあります。読む量は注意の予算を食い、足すほど薄まるので、1 つ足すと、ほかの全部が少し弱くなります。

それで品質が落ちたかというと、落ちていません。このシリーズは、読まずに済む形を仕組み一つずつで作っていく連載です。

各回の終盤には「検証手順」という節があります。先に読む必要はありません。置いた仕組みがなぜ要るのかを、自分の目で確かめたくなったときに戻ってください。

症状から対処法を学ぶ

各回は、うまくいかない症状から始まります。その対処法には、関連する AI の性質や仕様と、なぜその対処が適切かの解説が付いています。

先に、なぜその対処が適切かを覚える必要はありません。仕組みを一つ置けば、対処はできます。

AI の性質や仕様を覚えても、組み合わせ次第で、AI は間違えることがあります。通常の設計開発では気付きにくい、複数の性質や仕様が絡む落とし穴を、症状から順に学べます。

まず、心当たりを確かめる

まず一つだけ、思い出してみてください。

AI コーディングエージェントには、CLAUDE.md や AGENTS.md という名前の、ルールの置き場を渡しています。それはいま何行あって、その中で先週足した行がどれか思い出せますか。その行は、AI との一続きのやり取りである今日のセッションで、守られたでしょうか。

まだ AI と一緒に開発していないなら思い出せなくて当然ですが、ここから先は、指示ファイルが 3 週間でどうなるかを順に見ていきます。

手元にターミナルがあれば、行数を数えておくと次の節の数字が自分の話になります。

wc -l CLAUDE.md   # AGENTS.md など、使っているファイル名に読み替えてください

3 週間で動かなくなる

よくある経過として、1 週目、10 行の指示ファイルで AI はよく動きます。2 週目、失敗するたびに「〜しないこと」を 1 行足して 30 行になり、まだ動きますが、前に足したルールを破る日が出てきます。3 週目、60 行まで来ると、1 週目に AI ができていたことが、できなくなっています。

整理して優先順位を付け、大事なものを太字で先頭へ移すと 80 行です。AI はもっと守らなくなります。

改善の努力そのものが、状態を悪くする側に回るところが、いちばん厄介です。

原因は AI の能力ではなく、注意の配り方です。AI は、応答のたびに読み込む作業記憶、つまりコンテキストの全部を一度に見て、どこをどれだけ見るかを配ります。指示ファイルも、蓄積したメモも、いまのタスクの会話も、ツールの出力も、同じ一つのコンテキストに並びます。コンテキストが長くなるほど、その中から必要な 1 行を正しく取り出す精度は落ちます。関係のない行は、1 つ混じるだけで精度を下げます。

ルールは足すほど薄まる。1 つ足すことは、他の全部を少し弱くすることです。だから「守らせるためにルールを足す」は構造的に負けが決まっています。

Anthropic はこれを逓減する有限の資源と書いています。LLM には注意の予算があり、トークン数が増えるほど、その中から正確に思い出す能力は落ちるとあります。

Claude Code のドキュメントはもっと直接で、指示ファイルは1 ファイル 200 行未満を目標に、長いファイルはより多くのコンテキストを消費し、遵守率を下げると書いてあります。

並べ替えが効かないことも測られています。長い入力から必要な行を探させる課題があります。そこでは、筋の通った順に並べた文書より、順序をばらした文書のほうが成績が良く出ました。順序を整えることは、取り出す精度の側には効いていません。増えたのは行数だけです。

ただし、200 行という数字に、測定の結果は公開されていません。公式も「目標」と書いています。引いた測定が測ったのも、長い入力から必要な行を探せるかであって、指示に従う率ではありません。自分の指示ファイルが何行から効かなくなるかは、自分で数えるほかありません。

flowchart TB
  subgraph K["毎セッション、応答のたびに読み込まれるもの"]
    direction TB
    k1["指示ファイル"]
    k2["メモリの一覧"]
    k3["いまのタスクの会話"]
    k4["ツールの出力（テスト結果・差分…）"]
  end
  K --> B["注意の予算は、増えない"]
  B --> R["1 行足すことは、<br/>他の全部を少し弱くすること"]

私の手元の本番プロジェクトもここを通りました。typingtube という、YouTube の音楽動画でタイピング練習ができる Web サービスで、個人で運営しています。

指示ファイルが 101 行、蓄積したメモリが 89 ファイル・約 1.1MB まで育ちました。AI のコマンド実行に割り込む仕掛けである hook でルールの一覧を毎回注入するだけで、約 26KB がコンテキストに入る状態まで行きました。

置いた hook も毎回載るので、仕掛けを 1 つ足すことは、読む量を足すことでもあります。このシリーズは、そこから引き返した記録です。

読まない技術

引き返した先にあったのは「もっと読ませる」の逆でした。

テスト結果は、私にも AI にも失敗だけが届き、メモリは勝手に増えず、サブエージェントは見張らなくても止まるべきところで止まります。読まされていたものが一つずつ消えて、そのぶん楽になります。

なぜルールではなく、仕組みなのか。ルールは、読まれたときにだけ効きます。読まれるかどうかは、そのときのコンテキストの長さで決まります。仕組みは、読まれなくても効きます。条件を満たさないかぎり、AI はその先へ進めません。だから、コンテキストがどれだけ長くなっても、効き目は変わりません。

Claude Code のドキュメントも同じ線を引いています。指示ファイルについては厳密な遵守の保証は無いと書いています。そして、特定の時点で必ず走らせたいなら hook に書け、と続けています。

仕組みは置くだけで効き、理解は、使い始めてからで間に合います。置いた仕組みの中身を読み込んでから始める必要はありません。

多くの回で hook を使いますが、Claude Code なら hooks の設定で、使っているツールになければ作れば足ります。要るのは「読んでいなければ動けない構造」で、hook は実装手段の一つにすぎません。

失敗する前に先回りして置くとうまくいかないことが多いので、全部を今日置く必要はありません。小さなプロジェクトがメモリ肥大化と無縁なように、規模や構成によっては、そもそも起きない失敗もあります。

多くの回の冒頭には、自分の環境で症状を確かめる操作を一つ置いてあります。症状が出ていたら、その回が仕組みの置きどきです。

失敗してから置く仕組みは、なぜ要るかを目撃した直後なので、よく馴染みます。

シリーズの構成

基本編は、この連載が渡す仕組みをそのまま使う人向けです。あなたが置いて、確かめれば効きます。

応用編は、仕組みを自分で作ってチームに渡す人向けです。規模が大きくなっても崩れない形にします。

最終回では、ここまでの部品がどうつながって私が読まなくても回るかをまとめます。

テストをいつ・何本・どの手段で走らせるかは、この連載では扱いません。

次回は一番手前の話から。AI がテストを走らせて流れてくる 26,147 行を、私は読んでいません。それで見落としたことは、まだ一度もありません。

連載「読まない技術」