スポンサーリンク

ClaudeCodeで『検証手順』を組み込まないヤツは、自爆してる

スポンサーリンク
生成AI
スポンサーリンク

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%

にまで向上します

コメント