私は AI の出力を、もうほとんど読んでいません。AI が出力するテスト結果も、AI が書き足す知見メモ（メモリ）も、メインの会話を引き継がずに別に立ち上げた AI（サブエージェント）の作業ログも。読んでいないのは、私だけではありません。AI 自身も、自分の出力を読まずに済む形にしてあります。それで品質が落ちたかというと、落ちていません。このシリーズは、その状態を仕組み一つずつで作っていく連載です。

先に、読み方を書いておきます。この連載は、読むだけで追えます。各回は、現場で何が起きたかから始まり、何を置いて、その結果として何を読まなくなったかまで続きます。各回の終盤に「検証手順」という節がありますが、読み飛ばして構いません。自分の環境で試したくなったときに、戻ってくれば足ります。

まず一つだけ、思い出してみてください。AI コーディングエージェントに渡している指示ファイル（CLAUDE.md や AGENTS.md など、ルールの置き場です）は、いま何行あるでしょうか。その中で、先週足した行がどれか思い出せますか。その行は、今日のセッション（AI との一続きのやり取り）で AI に守られたでしょうか。

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

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

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

3 週間で動かなくなる

よくある経過です。1 週目、指示ファイルは 10 行。AI はよく動く。2 週目、AI が失敗するたびに、あなたは「〜しないこと」を 1 行足して 30 行。AI はまだ動くが、前に足したルールを破る日が出てくる。3 週目、60 行。1 週目に AI ができていたことが、できなくなっている。あなたはルールを整理し、優先順位を付け、大事なものを太字で先頭へ。80 行。AI はもっと守らなくなる。あなたの改善の努力そのものが、状態を悪くする側に回る——ここがいちばん厄介なところです。

原因は AI の能力ではなく構造です。指示は、AI が応答のたびに読み込む作業記憶（コンテキスト）の中で、他の全部と注意を奪い合っている。ルールは足すほど薄まる。1 つ足すことは、他の全部を少し弱くすることです。だから「守らせるためにルールを足す」は構造的に負けが決まっています。

Anthropic はこれを逓減する有限の資源と書いています——LLM には注意の予算があり、トークン数が増えるほど、その中から正確に思い出す能力は落ちる。Claude Code のドキュメントはもっと直接で、指示ファイルは1 ファイル 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。ルールの一覧を hook（AI のコマンド実行に割り込む仕掛け）で毎回注入するだけで、約 26KB がコンテキストに入る状態まで行きました。このシリーズは、そこから引き返した記録です。

読まない技術

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

やることは各回一つだけです。ファイルやスクリプトを一つ置き、確かめる手順も一つ。仕組みは置くだけで効きます。理解は、使い始めてからで間に合います。中身を読み込んでから始める必要はありません。

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

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

多くの回の冒頭には、自分の環境で症状を確かめる操作を一つ置いてあります。症状が出ていたら、その回の置きどきです。失敗してから置く仕組みは、なぜ要るかを目撃した直後なので、よく馴染みます。

シリーズの構成

基本編は、この連載が渡す仕組みをそのまま使う人向けです。置くだけで効きます。

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

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

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

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

連載「読まない技術」