私は AI の出力を、ほとんど読まなくなりました。AI が出力するテスト結果も、AI が書き足す知見メモも、サブエージェントの作業ログも。読んでいないのは私だけではなく、AI 自身も、自分の出力を読まずに済む形になっています。連載「読まない技術」は、その状態を仕組み一つずつで作ってきた記録で、この記事が最終回です。ここまでの部品が一つの作業の流れとしてどう回っているかをまとめます。各回の仕組みは序論の一覧から辿れるので、初めての方はそちらからどうぞ。

先に一つ、驚かれそうな事実から。方針を検討するとき以外、私が AI に入力する言葉は、ほぼ次の 2 文だけです。

次の作業を進めてください

ここまで不足点はないですか？確認して不足点がなければ次のセッションに引き継いでください

この 2 文の間で何が起きているか。コマンドは決まった入口から入り、テストは失敗と件数だけが届き、サブエージェントは用途カタログを通ったものだけが動く。ルールは自動テストと hook が守り、失敗が繰り返されそうな瞬間に方針が差し込まれ、メモリの保存は入口で絞られる。終わり際、報告の隣に機械の数字が並び、2 文目の問いで締まります。どの部品がどの回かは下の図のとおりです。

flowchart TB
  S(["1 文目「次の作業を進めてください」"]) --> W

  subgraph W["AI の作業中 — 人間は読まされない・口を挟まない（第11回）"]
    direction LR
    a1["コマンドを打つ"] --> g1["入口の hook が止めて案内する<br/>第4回"]
    a2["テストを走らせる"] --> g2["ラッパーが失敗と件数だけ返す<br/>自動テスト = ルールはここで落ちる<br/>第1回・第3回・第6回"]
    a3["サブエージェントを起動する"] --> g3["用途カタログを通ったものだけ動く<br/>第5回"]
    a4["同じ失敗を繰り返しそうになる"] --> g4["その瞬間に方針が差し込まれる<br/>第8回"]
    a5["メモリを保存する"] --> g5["入口で絞る・保存後に差分を突きつける<br/>第2回・第7回"]
  end

  W --> Z

  subgraph Z["終わり際"]
    direction TB
    F["報告の隣に機械の数字が並ぶ<br/>第9回"] --> V["道具の数字を写していなければ終われない<br/>第10回"] --> Q(["2 文目「ここまで不足点はないですか？」<br/>第12回"])
  end

  Z --> N(["次のセッションへ<br/>人間が読むのは「不足なし」か「引き継ぎ完了」だけ"])

  classDef human fill:#FFF3E0,stroke:#E38B2C,stroke-width:1.5px,color:#3A2A14
  classDef ai fill:#F7F7F7,stroke:#9E9E9E,color:#333
  classDef part fill:#E6F0FB,stroke:#3B7DC4,stroke-width:1.5px,color:#14304F
  class S,Q,N human
  class a1,a2,a3,a4,a5 ai
  class g1,g2,g3,g4,g5,F,V part
  style W fill:#FCFCFC,stroke:#C8C8C8,color:#555
  style Z fill:#FCFCFC,stroke:#C8C8C8,color:#555

一つひとつは、置くだけの小さな工夫です。それが結合すると、複数のセッションとサブエージェントが走る作業の全体が、定型文 2 つで回ります。この間、私はほとんど何も読んでいません。そして、ほとんど何も言っていません。

逆に、この 2 文がないと、仕組みをどれだけ重ねても品質は落ちます。1 文目は、人間が作業の中に口を挟まないという約束です（第 11 回）。2 文目は、どの仕組みからもこぼれたものを最後に拾う網です（第 12 回）。仕組みが止められるのは検知できる形の問題だけなので、この 2 文の代わりを仕組みで作ることはできません。

この 2 文の先で動いているのが、typingtube という Web サービスです。YouTube の音楽動画でタイピング練習ができるサービスで、個人で運営し、本番で動いています。この連載に出てきた数字は、26,147 行のテスト出力も、13 体の 173 万トークンも、全部そこから出てきました。

——という連載を、ここまで書いてきました。最後に白状します。

必要なところは、全部読みました

この連載で、私は同じ嘘を何度もつきました。「私は読んだことがありません」「読んでいません」。

嘘です。正確に言います。隅々まで毎回読んでいたわけではありません。必要なところは、全部読みました。テストの生ログも、サブエージェントの作業ログも、AI の途中経過の出力も——必要になったときに、必要なだけ、読みたいだけ。

証拠は各回の仕組みの中にあります。要約がどの行を grep するか。変異を「当たるはずの行」に選ぶ基準。カタログの requires に並べる、中央（サブエージェントを指揮する側の AI）のツール。自動テストに併置した走査対象の下限。方針を保存の後に差し込むという位置。あれは、読まずに書けるものではありません。生ログを読んだから要約の形が決められて、写しのテストを読んだから変異の入れ場所が分かって、13 体が無駄にした日も、1 体分のログを読んだからガードレールの場所が決まりました。要約の形を決めるためには、26,147 行の生ログを最後まで読みました。読まない技術を仕組みにする作業は、ほとんどが読む作業でした。この連載の読者の誰よりも、私は AI の出力を読んでいます。各回の仕組みは、読まない時間に読んだ結果です。

では、何が本当だったのか

「読まされていない」は本当で、「読んでいない」は嘘でした。ただ、この連載で言いたかったのは、そこではありません。誰が読んだか、読んでいないかは、どうでもいいことでした。 読んで何をしたかが全部です。振り返ると、各回でやっていたことは同じでした。うまくいかない問題を一つ見つける。なぜうまくいかないのかを理解する。その理解に合わせて、簡単な仕組みを一つ置く。壊して、効くことを確かめる。それだけを 11 回繰り返しました。

そうやって理解を重ねていくと、別々に見えていた問題の共通点が見えてきます。回をまたいで何度も同じ言葉が出てきたのは、そのためです。

  • 「ルールは読まれたときだけ効く。足すほど薄まる」——テストの出力も、メモリも、スキルの説明文も、指示ファイルの禁止事項も、全部この一つの問題でした
  • 「AI は止められると探す。読んでいなければ動けない形にする」——テストのラッパーの案内（第 1 回）、pre-commit hook の案内（第 4 回）、サブエージェントのカタログ（第 5 回）、リトライの瞬間の方針（第 8 回）は、同じ仕組みの置き場所違いです
  • 「読んだかは測れない。読まなければ作れないものの実在だけを見る」——第 4 回の hook を、第 5 回はそのまま当てただけでした
  • 「方針は、差し込む瞬間で効き方が決まる」——第 7 回の保存の後を一般化したのが第 8 回です
  • 「自己申告は完了に寄る。数は落ちない」——サブエージェントの報告も、引き継ぎ文も、同じ扱いで済みました

共通点が見つかると、仕組みは小さくなります。新しい問題に新しい仕組みを作るのではなく、既にある仕組みの置き場所を一つ増やすだけになる。第 11 回で「新しく置くものはありません」と書けたのは、そこまでの回で置いた仕組みが、人間が口を挟みたくなる場面の代役になっていたからです。

共通点は、序論に書いた一つの構造に戻ります。AI は応答のたびに、指示ファイルもメモリもツールの出力も目の前のタスクも、全部を一つの作業記憶（コンテキスト）に入れて読み、その中でいま一番強いものに従って次の一手を決めます。強さを決めるのは、正しさでも、書いてある場所の目立ち方でもありません。学習で何億回と見てきた標準の振る舞い、直前に届いたエラー、進行中のタスクの目的、人間の直接の指示——こういうものが強く、数週間前に指示ファイルへ足した 1 行は、その競争に毎回参加して、たいてい負けます。

上の五つは、全部この一つのことでした。ルールが薄まるのは、足した行が互いに強さを削り合うから。止められると探すのは、直前に届いたエラーがその瞬間の一番強い入力だから。読んだかを測れないのは、読むことが「あるかないか」ではなく「どれだけ強く効いたか」の問題だから。差し込む瞬間で効き方が決まるのは、同じ文でも決める瞬間に近いほど強いから。報告が完了に寄るのは、報告を書く瞬間のコンテキストが「完了させる」に向いた作業の続きだから。ただし、構造が一つだと分かっても、次にどこで何が負けるかまでは分かりません。構造は起きたことの説明であって、予告ではない。どの場面で負けるかは、うまくいかない問題が実際に起きて、初めて見えます。

だから、AI が指摘されるまで対応できないのは、能力が欠けているからではありません。指摘はその瞬間のコンテキストで一番強い入力になるので効く。同じ内容をルールとして先に書いておいても、決める瞬間には弱くなっていて効かない。AI が自分で選べる対処は「コンテキストに何かを足す」ことだけで（教訓を保存する、指示ファイルに 1 行足す）、それは薄まる側の解です。効くのは、決める瞬間に何が届くかを変えること——ラッパーの案内、hook のエラー、実在しないと通れないファイル、保存の直後の差分——で、それは AI の外にある経路なので、外にいる人間にしか置けません（書くのは AI でも構いません。どこに何を置くかを決めるのが、人間の仕事です）。

「読まない」技術は、この構造を踏まえた上で成り立ちます。AI の出力を読んで、そこに書かれたことに振り回される——足りないと言われればルールを足し、失敗したと言われれば読み直す——のではなく、決める瞬間に何が届くかを変える。うまくいかない問題を見つけて、なぜかを理解して、仕組みを一つ置いて、壊して確かめる。それを繰り返して、読まずに済む範囲を一つずつ広げていくことです。読まされていた時間が減ったぶんが、次の問題を探しに行く時間になりました。

付け加えるなら、これらは一度に置いたものではありません。どの仕組みも、その失敗を踏んだ直後に一つずつ置きました。あなたも全部を今日置く必要はありません。

「AI に書かせたコードは理解する必要がある」「読まないと、設計を見る目が育たない」という批判は、その通りだと思います。そして、この連載はその批判と対立しません。読む量は、正直に言えば減りました。ただし減ったのは読まされていた浅い読みで、残ったのは問題を探しに行く読みです。読まなくなったのは、読まされていた出力だけです。

結論

読まない技術は、うまくいかない問題を仕組みに置き換え続ける技術です。

置いた仕組みは、壊して効くことを確かめたら、あとは読まなくていい。これは一部の人の上級テクニックではなく、AI と開発するときの基本になるべきものだと思っています。読まない技術を身につけて、次の問題を探しに行く余裕を身につけてください。

各回の仕組みの置き方は序論の一覧からどうぞ。この仕組みで作られたものは typingtube で動いています。読まなくなった時間で作った画面が、そこに並んでいます。

次の連載は「AIの意見を聞かない技術」。AI の提案を、私は検討していません。だけど、開発が雑になったことはありません。

連載「読まない技術」