ClaudeCodeで『検証手順』を組み込まないヤツは、自爆してる
ClaudeCodeに長時間任せて、最後に見たら「あ、ここ違う」と気づく。
このパターン、実は検証ステップを組み込まなかったからです。
検証ステップ=自爆防止装置
プロンプトに「途中で止めて確認する」指示を組み込むだけで、修正の手戻りが劇的に減ります。
良いプロンプトの3層構造
バズっているプロンプトをよく見ると、3つの層がかならず含まれています。
【レイヤー1】ゴール
「最終的にこうなっていてほしい」
【レイヤー2】制約
「何をしてはいけないか」「何を必ず含めるか」
【レイヤー3】検証
「途中で止めて、確認する」「問題があれば報告する」
特に大事なのがレイヤー3の検証。ここを忘れると、気づかないうちに間違った方向へ進んでしまいます。
検証ステップの3パターン
パターン1️⃣:段階的確認
長いタスクを複数ステップに分割し、各ステップ後に確認する。
【タスク】売上データの整理&分析
■ ステップ1:データ読み込み
→ 読み込み完了後、データの形状と最初の5行を表示
■ ステップ2:クリーニング
→ 処理内容を説明してから実行
■ ステップ3:分析
→ グラフを生成する前に「このグラフで良いか」と確認
■ ステップ4:レポート生成
→ 確認後に最終出力
こうすることで、「あ、ここ違う」と思ったら、そこで止められます。
パターン2️⃣:エラーハンドリング
処理中にエラーが発生したときの対応を明示。
■ ファイルが見つからない場合
→ 処理を止めて、ファイルパスを確認するよう促す
■ データ形式が期待と違う場合
→ 現在のデータ形式を表示して、修正方法を提案
■ 計算結果が異常値の場合
→ グラフを表示して、「この結果で良いか」と確認
「そこで止める」という指示が、手戻りを防ぐ最強の武器になります。
パターン3️⃣:最終確認チェックリスト
すべてが完了した後に、チェックリストを走らせる。
完成前に、以下を確認してください:
□ ファイル形式は正しいか(.xlsx / .md / .pptx)
□ 文字数は指定範囲か
□ 禁止ワードが含まれていないか
□ 全ての必須要素が含まれているか
□ グラフやテーブルが正しく表示されるか
□ 日本語は自然か
全てOKなら最終出力。問題があれば報告してください。
実例:Excelデータ整形での検証
📊 実例:顧客データの整形
【タスク】customers.csv を整形する
【ステップ1】データの読み込みと状態確認
→ 行数・列数・列名を表示
【ステップ2】データクリーニング
→ 以下の処理を実行:
– 列名を日本語に統一
– 日付をYYYY-MM-DD形式に統一
– 電話番号をハイフン付きに統一
– 重複行を削除
→ 処理後に「何行削除されたか」を報告
【ステップ3】品質チェック
→ 空白セルがあれば「どの行か」をリストアップ
【ステップ4】出力
→ CSV と XLSX 両方で出力
→ 「完成しました」と報告。ユーザーの確認を待ってから終了
結果:
– ステップ2後に「4行削除されました」と報告 → ユーザー確認OK
– ステップ3で空白セル3行をリストアップ → ユーザー確認OK
– 最終出力 → 問題なし
検証を組み込むメリット
- 気づかないミスを早期発見できる
- 修正が必要な場合、手戻り回数を最小化できる
- ユーザーの「安心感」が上がる(途中で見守られてる感覚)
- AIの出力理由が明確になり、信頼性UP
まとめ:失敗の科学の応用
「検証ステップ」は、失敗の科学という書籍で紹介されている「フォールトトレランス思考」の応用です。
つまり、「人間(またはAI)が失敗するのは前提。その失敗を途中で気づいて止める仕組みを作っておく」という考え方。
ClaudeCodeでこれを実装すれば、修正のストレスは激減します。
検証ステップを組み込むと
初回正答率 95% → 99%
にまで向上します



コメント