第16回 自己検証 ─ テスト駆動 & 高度なHook
Claudeに「自分の仕事を自分で検証する手段」を渡す。テストを渡せばClaudeは失敗を見つけて自分で直す自己修正ループになる。ブラウザを開いて見た目を確かめさせることもできる。さらに第8回のHookを発展させ、型チェック・Claude同士のレビューまで踏み込む。Claude Codeの使い方コース 第16回（難易度🔴 エンジニア向け）。
自己検証
第16回スタート。テーマは「自己検証」。今日のゴールは2つ。①テストで品質を上げる ②Hookで検証を仕組み化する。前半がテスト駆動、後半が第8回から発展した高度なHook。Claudeに自分で答え合わせさせる回。
応援お願いします！
共通テンプレート（src/deck-shared.tsx の CtaSlide）。高評価・チャンネル登録・メンバーシップ・noteメンバーシップのお願い。内容はテンプレート側で一括管理。
ここからエンジニア向け
正直に断っておく。第16回からはプログラムを書く方向けの内容。非エンジニアの方は第15回までで実用上は十分。ここから先は難易度🔴だけど、たとえ話を交えて噛み砕いて説明するので、興味があればぜひ。
指示するだけ vs 検証を渡す
公式が言う最もレバレッジが高いこと＝Claudeに「自分で走らせて合否が読めるもの」を渡すこと。公式ドキュメントの例をそのまま使う。ダメな指示＝「メールアドレスを検証する関数を作って」。良い指示＝「validateEmailを書いて。[email protected]はtrue、invalidはfalse、[email protected]はfalse。書いたらテストを実行して」。Claudeは「できたっぽい」と思った時点で止まる生き物なので、止まる基準を機械が判定できる形で渡すのが肝。
テストって何？
テストという言葉を知らない方向けに、ここで一段落。テスト＝「この入力ならこの答えになるはず」を書き並べた対応表。さっきのメールアドレスの例で言えば、[email protected]ならtrue、invalidならfalse、[email protected]ならfalse、の3行。これをコードで書いておくと、実行するだけで機械が○×を付けてくれる。ここでは「テストは動作を保証する仕組みじゃなくて、機械が自動採点してくれる答案だ」という感覚だけ持ち帰ってもらえばいい。画面のnpm testで、1つ失敗している様子を見せる。
テスト駆動の自己修正ループ
テストを渡す→Claudeが実行→失敗→原因を直す→再実行→成功。この自己修正ループが回る。人間が逐一チェックしなくても、テストが合格するまでClaude自身が直し続ける。テスト駆動開発(TDD)と非常に相性が良い。ターミナル演出で実演。
見た目もClaudeが自分で確かめる
検証はコードのテストだけじゃない。公式のプロンプト例＝「［デザイン画像を貼る］このデザイン通りに実装して。できたらスクリーンショットを撮って元画像と見比べて、違うところを列挙して直して」。ポイントは「よくして」ではなく比べる対象を渡すこと。そしてここを強調＝Claude Code自身がブラウザを開いて見ることができる。claude --chrome でChrome拡張（Claude in Chrome）とつなぐと、Claudeが自分でlocalhost:3000を開き、フォームに値を入れ、スクショを撮り、コンソールのエラーまで読む。人がスクショを撮って貼り付ける必要すらない。実際の指示例は「ログイン画面を開いて、わざと不正な値を入れて、エラーメッセージが正しく出るか確かめて」。
Hookの応用へ
ここで橋渡し。第8回で学んだHook（特定のタイミングで自動実行する仕組み）を、ここからは検証に応用する。手動で検証するのではなく、Hookで検証そのものを自動化していく。基本から高度な実例へ。
型チェックHook
高度なHook①。ファイルを編集するたびに自動でtsc --noEmit（型チェック）を走らせる。型エラーが出たらその内容をClaudeに返し、Claudeが自動で修正する。人が見張らなくても、編集と検証がワンセットで回る。ターミナル演出で実演。
Claude→Claudeの審査
高度なHook②。Hookからclaude -pで別のClaudeインスタンスを起動し、新しく書いた関数が既存と重複していないか審査させる。ここで強調したいのは「claude -p に一言投げれば動く」わけではないこと ─ 別のClaudeはこちらの会話を一切引き継がないので、必要な文脈は全部プロンプトに書く必要がある。画面のスクリプトの3点を指差しながら説明する。①何を見ればいい＝Hookのstdinに届くJSONからjqでfile_pathを取り出してプロンプトに埋める ②どう調べればいい＝探す場所(src/以下)と、Read/Grepを使ってよいことを --allowedTools で明示 ③どう答えればいい＝出力の形をDUP:またはOKに固定する。だからシェル側で合否を判定できる。判定結果は exit 2 の標準エラー出力で本体のClaudeに返り、Claudeがそれを読んで直しにいく。--model haiku にしているのは、この程度の審査なら安く速く回るから。
Hookの定番3パターン
Hookのよくある使い方を3つ。①ファイル編集のあと（PostToolUse）＝eslintやprettierを自動で走らせ、整形と指摘をその場で返す。②ファイル編集のまえ（PreToolUse）＝DBのmigrationsフォルダなど触ってほしくない場所への書き込みをブロック。③作業を終えるとき（Stop）＝テストを走らせ、失敗している間はターンを終わらせない。最後に一番言いたいこと＝Hookは自分で書かなくていい。「ファイル編集のたびにeslintを走らせるHookを書いて」とClaudeに頼めば作ってくれる。
検証は仕組みに組み込む
今日の核心。検証を「人に毎回やらせる」のではなく「仕組みに組み込む」。テストもHookも、一度作れば自動で回り続ける。人間は基準を決める側に回り、答え合わせはClaudeと仕組みに任せる。これが品質を底上げする一番の近道。
テスト駆動ループを回す
実演はこれ1本に絞る。画面のプロンプトをそのまま打つ ─「メールアドレスを検証する validateEmail を作って。TDDで進めて。」「テストが全部通るまで、自分で直し続けて。」。あとは口を出さず、Claudeがテストを書いて失敗させ、実装し、実行し、直して、通るまでを黙って見せる。見どころを口頭で実況する＝①先にテストを書くので最初は必ず失敗する ②失敗した出力をClaude自身が読んでいる ③こちらは一度も「直して」と言っていない。締めの一言＝極端な話「TDDで進めて」と書くだけでもループは回りはじめる。
今日のまとめ
自己検証はレバレッジ最大。テストを渡せば失敗→修正→成功の自己修正ループが回る。見た目はClaude自身がブラウザを開いて確認。Hookは型チェック・Claude同士の審査まで発展できる。検証は人ではなく仕組みに組み込む。
次回予告
次回は第17回「大規模開発 ─ CI/CD・SDK」。個人の道具から、チームと本番運用のスケールへ。CI/CDへの組み込みやSDKでの自動化を扱う。チャンネル登録とメンバーシップもよろしく！
応援お願いします！
共通テンプレート（src/deck-shared.tsx の CtaSlide）。最後にもう一度、高評価・チャンネル登録・メンバーシップ・noteメンバーシップのお願い。