以前のは、確かめるためにプロダクトを動かしていました。テストを走らせて直すときも、画面を開いて確かめるときも、本番で起きたことから学ぶときもです。いまは、プロダクトを動かす代わりに、正解が先に分かっている課題を作っています。AI が、の渡したものを読んだかは測れないからです。に測ることができるのは、読まなければ作ることのできないものが実在するかどうかだけです。この連載で、は、前の 4 作で「こうすれば効く」と書いてきたことを、一つずつ実験で測り直します。
この連載は、読むだけで追うことができます。各回が扱うのは、症状から、が何を置き、何をしなくなったかまでです。各回の終盤の「実験手順」という節は後回しにして、の数字があなたの環境でも出るかを確かめたくなったときに、戻ってきてください。
症状から対処法を学ぶ
各回は、うまくいかない症状から始まります。その対処法には、その症状に関わるAIの性質や仕様と、なぜその対処が適切かの解説が付いています。
なぜその対処が適切かを覚える前でも、症状への対処に要るのは、仕組みを一つ置くことだけです。
AI の性質や仕様を一つずつ覚えても、それらが組み合わさると、AI は間違えることがあります。通常の設計開発では気付きにくい、複数の性質や仕様が絡むこの落とし穴を、症状から順に学ぶことができます。
心当たりを確かめる
まず一つだけ、思い出してみてください。
思い出してほしいのは、AI の使い方について、あなたが「こうすれば効く」と信じていること 1 つです。指示ファイル（CLAUDE.md や AGENTS.md）の書き方でも、AI への頼み方でも構いません。
それを最後に確かめたのはいつで、そのとき何回ぶんの結果を数えましたか。
まだAIと一緒に開発していないなら、信じていることが無くて当然です。
4 作 44 本の根拠は、ほとんどの実感です
この連載は 5 作目です。
- 1 作目「読まない技術」: AI の出力を、読まなくて済む形にした
- 2 作目「AIの意見を聞かない技術」: AI の提案・判断を、二度検討しなくて済む形にした
- 3 作目「言わない技術」: 人間の入力を、言わなくて済む形にした
- 4 作目「確かめない技術」: 確認そのものを、その場で決めなくて済む形にした
- 5 作目（この連載）: その 4 作で置いた仕組みのおかげで、本当にうまくいっていたのかを測る
前の 4 作の 44 本は、全部、1 つの本番プロダクトで起きたことから書きました。typingtube という、YouTube の音楽動画でタイピング練習ができる Web サービスです。が個人で運営していて、いまも本番で動いています。
その書き方には、弱点がありました。ほとんどの回の根拠は、仕組みを置いたら、そのあとうまくいくようになった、というの実感でした。が見ていたのは、仕組みを置いたあとの日だけです。置かなかった日と比べるには、本番をもう 1 つ用意するか、時間を巻き戻す必要がありました。
だから、44 本に書いてきたことのうち、どれが本当なのかは、未確認のままです。が置いた仕組みのおかげでうまくいったのかもしれませんし、置かなくても同じ結果だったのかもしれません。本番を動かしている限り、はどちらなのかを一生確かめることができません。それが、この連載の出発点です。
動かさないのは、プロダクトのほうです
題は「動かさない技術」ですが、この連載で、は前の 4 作のときより多く実行します（毎回、サブエージェント、つまりが起動して作業を任せるAIを、何回も起動します）。がやめたのは、書いてきたことが本当かを確かめるために、プロダクトを動かすことのほうです。
前の 4 作でが減らしてきたのは、目の前の作業がちゃんとできているかを確かめるための実行です。
残っていたのは、書いてきたことが本当かを確かめるための実行、つまり、プロダクトを動かして、起きたことから学ぶことでした。この実行は 44 本の根拠そのものの作り方なので、は 4 作を通して、ここだけはずっと続けていました。
プロダクトの代わりにが題材にするのは、正解が先に分かっている課題です。
Claude Code の best practices は、AI の仕事をどう確かめるかを、こう書いています。成功を主張させる代わりに、証拠を見せさせよ。同じページには、走らせることのできる自動テストが無ければ「終わったように見える」が唯一の信号になる、ともあります。先に正解表を作っておけば、は AI に聞かずに、返ってきた答えを正解表と突き合わせることができます。
たとえば、ログを模したファイルを 12 本置き、サブエージェントがそこから拾うべき値を、スクリプトに決めさせて正解表にします（が後から正解表を作ると、返ってきた答えに合わせてしまうからです）。正解表を置くのは、サブエージェントに渡すディレクトリの外です。同じ課題を、条件を 1 つだけ変えて、会話を引き継がないサブエージェント（前のやり取りを持たずに起動したもの）に何回か渡し、返ってきた答えを正解表と突き合わせます。合っているかどうかを決めるのは、の実感の代わりに置いた、この正解表です。
サブエージェントへの渡し方も、AI の性質に合わせて決めました。Turpin ほかは、利用者が答えを示唆すると、モデルの答えはその答えに寄り、理由の説明ではそのことに触れないと報告しました。だからは、依頼文には答えの形を書かずに渡します。
この測り方でが作ることのできる課題は、正解をスクリプトで決めることのできるものに限られます。この測り方の外に残るのは、正解を人が判断するしかない仕事です。
渡すのは、実験手順です
前の 4 作では、各回で「置けば効くファイル 1 枚」を読者に渡していました。hook や、ラッパー（標準のコマンドの代わりに置いたプロジェクト固有の入口）や、指示文です。読者が持ち帰るのは、そのファイルでした。
この連載では、そのファイルの代わりに、各回の終わりの「実験手順」の節に、が使った題材の作り方と、条件の変え方と、数え方を書きます。
同じ数字があなたの環境でも出るかどうかを、あなた自身が確かめることができます。
の数字は、実験手順を走らせるだけで確かめることができます。信じるかどうかは、そのあとで決めれば間に合います。
各回の中身は、1 つの思い込み・1 つの測り方・1 つの実験手順です。思い込みの出どころは、たいてい公式ドキュメントの記述か、広く勧められている作法です。どの回でも、はその思い込みを仮説として立て、実験で確かめ、出た数字まで書きます。
外れた回も、そのまま入れてあります
測ってみたら、の予想が外れた回もありました。外れた回を落とせば、この連載は実験の記録から演出に変わります。
外れ方は、回ごとに違いました。の予想と逆に出た回もあれば、条件をまたいで差がまったく出なかった回もあります。2 回目までの実験の結果から出しかけた結論が、3 回目の実験で外れた回もあります。外れたことは、どの回にもそのまま書きました。
そして、各回の終わりには、その実験の結果が示していないこと（母数がいくつなのか、どの原因とどの原因が混ざったままなのか、どの数字がモデルの世代によって変わるのか）も並べます。この連載の数字は、1 つのモデルの、ある時点の測定結果です。あなたに持ち帰ってほしいのは、数字そのものより、各回で分かったことのほうです。
前の 4 作を読んでいない人も、この連載から読み始めることができます。
ただし、この連載は、前の 4 作の仕組みを置き終えた人の話です。まだ置いていないなら、1 作目から読むほうが近道です。
連載の構成
前半の 4 本は、同じものを渡したサブエージェントが、実際に何をしたかを数えます。
中盤の 3 本は、同じことを頼んでいても、頼み方の一文の違いや、セッションの往復の数で、AI の答えが変わるかを測ります。
終盤の 2 本は、作業が終わったあとに残るものだけを見ていると、見えないものがあるという話です。扱うのは、出来上がったファイルと、次に作業する AI へ渡す申し送りです。
最終回では、9 回で確かめたAIの性質を組み合わせて、どの回でも測っていない症状の原因をたどります。
どの回から読んでもかまいません。
次回は「手順を守らせない技術」。は、AI に守られなかった指示を書き直すのをやめました。 それでも、その指示は守られるようになりました。