確かめる段：完了の前に自分で確かめさせる

前のレッスンで、CLAUDE.md・スキル・フックという3層を見ました。この3層は「何を守らせるか」の話でしたが、ここからは「終わったと言う前に、本当に終わっているかをどう確かめるか」という話に移ります。

Claudeが「完了しました」と報告してくるたびに、毎回手元で動かして確認するのは現実的ではありません。かといって、報告をそのまま信じ続けると、あとから壊れていたコードに気づくのが遅れます。ここで効くのが、Claude自身に自分の作業を確かめさせる仕組みです。

2つの確かめ方を区別する

「確かめる」には性質の違う2つがあります。作業の途中で繰り返し回すフィードバックループと、作業の完了時に新しい視点でチェックする検証です。

完了後の検証には、意図・仕様・計画をつなぐ書類で見たプランと同じように、実装のセッションとは別のサブエージェントが使えます。「変更箇所を確認し、plan.mdとのズレを報告するだけで自分では直さない」検証専用のサブエージェントを立てておくと、実装側の思い込みをそのまま見逃す事故を減らせます。サブエージェントは独立したコンテキストで調査するので、探索した内容ではなく、結論だけをメインの会話に返します。

どちらか一方だけでは足りません。フィードバックループだけに頼ると、同じ思い込みのまま堂々巡りになることがあります。完了後の検証だけに頼ると、根本的な設計ミスに気づくのが遅れ、直す範囲が大きくなってから発覚します。両方を組み合わせて、初めて「思ったより早く、かつ思ったより安全に」が両立します。

バグ修正は、先に失敗するテストを書かせる

バグ修正では、直す前にまず失敗するテストを書かせ、そのテストでバグを再現・確認させてから直す、という順番が効きます。直したあとにテストを書くと、テストがバグに合わせて甘くなりがちだからです。

この順番を毎回徹底させたいなら、CLAUDE.mdに「テストが失敗したらコードを直す、テストを直さない」と書くだけでなく、修正中にテストファイルの編集そのものを止めるフックを重ねると、なし崩しにテストを緩めてしまう事故を防げます。

完了報告の前に、検証を済ませる

完了報告そのものを、検証込みにしてしまうのも効果的です。CLAUDE.mdに「完了を報告する前に、テストを実行し、その出力を示すこと」と明記しておくと、Claudeは「多分できているはず」ではなく、実行結果という証拠を添えて報告するようになります。

自己申告で済ませたくなる理由もわかります。実行結果を貼り付けるより、「完了しました」と書くほうが速いからです。ただし、貼り付けにかかる一手間はわずかで、あとから壊れたコードに気づいて原因を調べ直す時間のほうがずっと大きくなります。最初の一手間を惜しまないほうが、結果として速く進みます。

やってみよう

演習1：自分の「完了」の基準を書き出す

いま自分が「終わった」と判断している基準を書き出してみてください。テストを実行した結果を見ているのか、それとも動かした感触だけで判断しているのか、正直に振り返ってみましょう。

演習2：検証の担当を分けてみる

直近で実装したものを1つ選び、実装した本人以外の目(別のセッション、検証専用のサブエージェント、あるいは人間のレビュー)で見直すとしたら、何を確認してほしいかを3つまで書き出してください。

今日のまとめ

3行で振り返ります。

• 作業中に繰り返すフィードバックループと、完了後にまっさらな視点で確かめる検証は、別の仕組みとして用意する
• バグ修正は、直す前に失敗するテストを書いてバグを再現させてから直す
• 完了報告には、テストの実行結果という証拠を添えさせる

次のレッスンでは、この確かめる段を通過したコードを、実際にどう出し、出したあとどう保つかを見ていきます。検証をフックで強制する考え方は、自己検証を組み込むでも扱っています。