読む量を減らすのではありません。確かめ方を渡すのです。
ここまでの3回で、頼み方は上達しました。依頼は目的・制約・確認方法の型になり、間違いはCLAUDE.mdに積み上がるようになりました。それでも1つだけ、まったく変わっていないものがあります。「見る」の重さです。
はっきり言います。全部読んでいる限り、何体たりとも同時には動かせません。読む速度がそのまま上限になるからです。1件の資料なら隅々まで読めても、100件は読み切れません。では、どうするか。
答えは、無条件に手放すことではありません。手放す先は信頼ではなく、確かめ方です。信頼は後からついてきます。まず、確かめ方を先に作る。これが、ステップ1という段で越えるべき最大の山です。
「全部読む」が壊れる理由
読む量を増やし続けるやり方は、規模が大きくなると必ず破綻します。理由は2つあります。1つは、あなたの時間が有限であること。もう1つは、注意力は読む量に比例して落ちることです。10本目の原稿を読むときの集中力は、1本目とは違います。
さらに厄介な問題があります。「読んで、問題なさそうだった」という印象は、正しさの証明にはなりません。見た目が整っていることと、中身が正しいことは別の話です。人間が流し読みで見落とすのと同じように、AIが作ったものも「できているように見える」だけで実際には誤っていることがあります。
成果物の全文を毎回読む。件数が増えるほど、読む時間がそのままボトルネックになる。あなたがいなければ何も先に進みません。
Claude自身が実行できる確認手段を持つ。あなたは結果の要約を見て、必要なときだけ深く踏み込みます。
検証ループとは何か
検証ループとは、Claude自身が実行できて、正しさを客観的に判定できる手段のことです。テストを走らせる、ビルドを通す、実行結果を確認する、変更前後のスクリーンショットを比べる。形はいろいろありますが、共通しているのは「あなたが毎回目を通さなくても、Claude自身が自分の仕事を測れる」という点です。
“Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from.”
筆者訳Claudeに、自分で実行できる確認手段を与える。テスト、ビルド、比較用のスクリーンショット。それが、あなたが張り付いて見ているセッションと、席を立てるセッションの違いになる。
第0回で読んだ、公式ドキュメントの続きの一文を思い出してください。確認手段がなければ、「できたように見える」だけが唯一の手がかりになり、あなた自身が検証ループになってしまう。ここまでの3回でやってきたことは、実はすべてこの一文に向かう準備でした。
この確かめ方には、強さの段階があります。同じ「確認して」でも、頼み方によって効き目が変わるからです。
この講座はまだ、最初の段(01)にいます。ここから先の回で、同じ「確かめる」という発想を、少しずつ仕組みの側に寄せていきます。
確かめ方の種類：自分の仕事に当てはめる
検証ループは、エンジニアだけのものではありません。原稿、スライド、データ整理にも、Claude自身が実行できる確かめ方は必ず存在します。
多くの分野にはもともと、この発想と同じ構造があります。見た目の印象で判断を終わらせず、独立したテストやチェックで客観的に裏を取るという文化です。検証ループは、この考え方をそのまま原稿やスライドの作業に持ち込むだけです。
大事な条件が1つあります。確かめ方は、Claude自身が実行できるものでなければ機能しません。「なんとなく良い感じ」という人間の感覚は、検証ループにはなり得ません。件数を数える、実在を確認する、比較するといった、実行可能な形にまで具体化する必要があります。
検証ループの設計手順
検証ループの作り方は、4つの手順に落とし込めます。
完了の定義を先に書く
「できた」とはどういう状態か、頼む前に1文にする
確認方法を選ぶ
上の表を参考に、そのタスクに合う確かめ方を1つ以上選ぶ
確認方法ごとClaudeに渡す
「終わったら◯◯を実行して、結果を見せて」まで指示に含める
最初の数回は自分でも確認する
確認方法自体が正しく機能しているかを、信頼が積み上がるまで自分の目でも見る
第5回で依頼の型に入れた「確認方法」は、実はここまでの布石でした。あのときは1行で済ませていたものを、ここで具体的な手順にまで落とし込みます。
手順01から03までが実際にどう変わるか、公式ドキュメントに載っている例で見てみます。
確認方法を依頼に含めると、一文がこう変わる
implement a function that validates email addresses
メールアドレスを検証する関数を実装して、とだけ頼む書き方です。完了の基準も確認方法も、Claude側の判断に委ねられています。
write a validateEmail function. example test cases: user@example.com is true, invalid is false, run the tests after implementing
関数名と、期待する結果つきのテストケース(user@example.comなら正しい、invalidなら誤り)を先に渡し、実装後にそのテストを実行するところまで指示に含めています。
BeforeとAfterの差は、文章の長さではありません。完了の定義(手順01)と確認方法(手順02)を先に決め、それを依頼そのものに含めている(手順03)かどうかです。
まず1件で試して10件へ
検証ループを作るとき、見落としやすい落とし穴があります。確かめ方自体が間違っている可能性です。常に通ってしまう緩いチェックは、チェックがない状態より始末が悪い。安心して見なくなるからです。
“definitely recommend that you start small. So, like, test it on one test. ... Then scale it up to 10.”
筆者訳小さく始めることを強く勧めます。まず1件でテストする。それから10件に広げる。
10件に一気に適用する前に、まず1件で確認方法そのものを検証します。わざと誤りを混ぜたものを試し、確かめ方がその誤りをちゃんと拾うかを見る。これが「検証の検証」です。
$社外発表用に、この資料の要点をスライド1枚にまとめて。文字数は1枚300字以内。作った後、実際の文字数を数えて教えて。
スライド案を作成しました。本文の文字数は287字です。 確認方法として文字数チェックを実行し、上限300字以内に収まっていることを確認済みです。 残り9件の資料でも同じ形式で作成してよろしいですか。
この1件で確認方法が機能することを確かめてから、残り9件に同じ形を広げます。1件目を飛ばして10件に一気に適用すると、確かめ方の欠陥ごと10倍に増えることになります。
よくある誤解と罠
注意
検証ループで崩れやすい3点
「チェックがあれば安心」という誤解。常に通ってしまう緩いチェックは、チェックがない状態より危険です。安心して見なくなるからです。
確認方法を後から考える。頼んだあとに「どう確認しよう」と考え始めると、そもそも完了の基準があいまいなまま作業が進んでしまいます。確認方法はいつも先に決めます。
検証ループができた瞬間に見るのをやめる。この段の卒業は「一切見ない」ではありません。確認方法自体への信頼がまだ薄いうちは、結果と一緒に中身も見ます。完全に手を離すのは、もっと先のステップ3の話です。
ステップ1の卒業条件
以下がすべて言えるようになったら、ステップ1を卒業です。
- 少なくとも1つの作業に、Claudeが自分で実行できる確認手段(文字数チェック・件数照合・スクリーンショット比較など)を渡せている
- その確認手段を、まず1件で試し、狙った誤りをちゃんと検知することを確かめている
- 新しいタスクを頼むとき、「目的・制約」だけでなく「確認方法」まで先に決めてから頼めている
- 「見る」時間の中心が、成果物の全文から、確認結果の要約に移っている
- まだ全部を手放したわけではない。ただし「全部読まないと不安」ではなく、「確かめ方があるから部分的に手を離せる」に変わっている
今日のまとめ
- 「全部読む」は規模が増えると必ず壊れる。読む量ではなく確かめ方を渡す
- 確かめ方はClaude自身が実行できるものだけが機能する。人間の感覚は検証ループにならない
- 確かめ方自体も、まず1件で検証してから10件に広げる
- 確かめ方には強さの段階がある。今日身につけるのは「頼むとき」の段だけで十分、仕組みでの強制は第9回・第13回で扱う
明日のアクション
明日実際に使うタスクを1つ選び、確認方法を最低1つ決めてから頼んでください。
結果が出たら、その確認方法が本当に機能したかを、1件だけ自分の目でも確かめてください。
それができたら、あなたはもうステップ1の卒業に近いところにいます。次回は、いよいよ2体目を立てます。