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

それでも、AIが作るものの品質は、読んでいた頃と同じです。この連載では、私とAIが読まずに済む形を、仕組みを一つずつ置いて作っていきます。あわせて、うまくいかない症状がなぜ起き、置いた仕組みでなぜ解決するのかを、確かめながら解説します。

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

症状から対処法を学ぶ

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

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

AIの性質や仕様を覚えても、それらの組み合わせ次第で、AIは間違えることがあります。だからこの連載の入口は、症状です。症状から順にたどれば、通常の設計開発では気付きにくい、複数の性質や仕様が絡む落とし穴の原因を突き止め、対処することができます。

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

AIコーディングエージェントを使っているなら、AIに守らせたいルールを書いておく指示ファイルについて、思い出してみてください。

指示ファイルの名前は、CLAUDE.md や AGENTS.md などです。そのファイルはいま何行あって、その中で先週足した行がどれか思い出すことができますか。その行は、AIとの一続きのやり取りである今日のセッションで守られたでしょうか。

AIコーディングエージェントをまだ使っていないなら、思い出すことができなくて当然です。ここから先は、指示ファイルが3週間でどうなるかを順に見ていきます。

手元にターミナルがあれば、行数を数えておいてください。次の節の数字を、自分のファイルの行数と比べながら読むことができます。

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

3週間で動かなくなる

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

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

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

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

ルールは足すほど薄まる。ルールを1つ足すと、ほかのルールに向く注意が少しずつ減ります。そのため、守らせるために足したルールが、ほかのルールを守られにくくします。

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

Anthropicの説明では、コンテキストは逓減する有限の資源です。LLM には注意の予算があり、トークン数が増えるほど、その中から正確に思い出す能力は落ちる、としています。

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

指示の数と、指示が守られる割合の関係も測られています。報告書を書かせる課題に、キーワードを入れる指示を最大500個まで並べた測定では、指示を増やすほど守られる割合が落ち、500個のときは、最良のモデルでも68%でした。Claude Codeのベストプラクティスも、禁じるルールがあるのにAIが望まないことを続けるなら、たぶんファイルが長すぎて、ルールが埋もれている、と書いています。

整理で増えたのは、行数と、太字にした行です。太字について、同じベストプラクティスは、多くの行を強調すれば、どれも目立たない、と書いています。

ただし、200行という数字の根拠になった測定は公開されていません。公式も「目標」と書いています。上で引いた測定も、測ったのは、長い入力から必要な行を探すことができるかどうかと、報告書にキーワードを入れる指示を守るかどうかで、指示ファイルの行数とルールの守られ方は測っていません。自分の指示ファイルを何行からAIが守らなくなるかは、自分で数えるほかありません。

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

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

このhookのように、AIに読ませるための仕組みは、注入したものが毎回コンテキストに載ります。読ませる仕組みを1つ足すことは、読む量を足すことでもあります。置いたhookも毎回載る、ということです。この連載は、その状態から抜け出すまでの記録です。

読まない技術

私がしたのは、私とAIが読むものを、仕組みで一つずつ減らすことでした。

テストを走らせても、私とAIに届くのは失敗だけです。AIがメモリに知見を書き足すことも、ほとんどなくなりました。サブエージェントは、私が見張っていなくても、止まるべきところで止まります。読まされていたものが一つずつ消えて、そのぶん私は楽になりました。

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

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

多くの回でhookを使いますが、Claude Codeならhooksの設定で置くことができます。使っているツールにhookがなければ、作ればよいだけです。要るのは、AIが必要なものを読んでいなければ動けない構造で、hookは実装手段の一つにすぎません。

全部を今日置く必要はありません。失敗してから置くと、なぜ要るかを目撃した直後なので、仕組みを受け入れやすくなります。先回りして置くと、うまくいかないことのほうが多いです。小さなプロジェクトがメモリ肥大化と無縁なように、規模や構成によっては、そもそも起きない失敗もあります。

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

連載の構成

基本編は、この連載が渡す仕組みを、手を加えずにそのまま使う人向けです。各回の仕組みを置き、検証手順で確かめるところまでを扱います。

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

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

第1回と第3回はテストの話ですが、テストをいつ・何本・どの手段で走らせるかは、この連載では扱いません。

次回は、読まされるものの中で一番手前にある、テスト結果の話から。AIがテストを走らせて流れてくる26,147行を、私は読んでいません。それでも、拾うべき失敗は毎回届いています。

連載「読まない技術」