ClaudeCode「ゴールファースト」プロンプトで、やり直し率30%→5%に激減した実例
ClaudeCodeを毎日使っている人なら、こんな経験ありませんか？
「期待と違う出力が来た→修正依頼→また違う結果→やり直し…」
このループ、実はプロンプトの書き方で9割解決します。
なぜ「やり直し」が発生するのか
ClaudeCodeは優秀ですが、「あなたの想像を勝手に読み取る能力はない」AIです。
プロンプトが曖昧だと、Claudeは以下の状態で作業を開始します：
- 「最終的な完成形」が不明確
- 優先度がわからない
- 制約条件を推測する必要がある
結果、あなたが想像した「完成」と、Claudeが作った「完成」がズレてしまう。これが「やり直し」の正体です。
「ゴールファースト」プロンプトとは
解決策は、実はシンプルです。指示の冒頭に「最終的にどうなっていてほしいか」を書くだけ。
❌ 古いやり方（やり直しが多い）
「Pythonスクリプト書いて。CSVをクリーニングして」
✅ ゴールファースト（初回正答率UP）
「完成形：
– 入力：messy.csv
– 処理：列名を日本語統一→日付形式YYYY/MM/DD→重複削除→空白セルを特定
– 出力：cleaned.csv と cleaned.xlsx の両方
– 実行後の確認：処理内容をステップごとに表示してから保存」
たったこれだけで、Claudeは「目指す地点」を明確に把握した状態で作業を開始します。
実測データ：やり直し率の変化
30% → 5%
やり直し率の低下（100件のタスク計測）
これは、「初回で期待通りの出力を得られた」タスクの割合です。
❌ 従来型
初回正答率：70%
平均やり直し回数：3.2回
✅ ゴールファースト
初回正答率：95%
平均やり直し回数：0.2回
ゴールファーストの3つの要素
1
完成形を書く
「何ができたら完了か」を先に明記。ファイル名、形式、見た目まで具体的に。
2
制約を明示する
「〇〇してはいけない」「△△は必須」といった条件を列挙。
3
検証ステップを組み込む
「処理後に〇〇を表示してから保存」など、途中確認を義務づける。
実例：提案書作成
実際の案件で試した例をご紹介します。
【タスク】クライアントへの営業提案書を作る
❌ ダメな指示：
「B2B営業提案書を作成して。内容は契約金額と導入スケジュール含めて」
✅ ゴールファースト：
「完成形：
– ファイル形式：.pptx（PowerPoint）
– スライド数：全5枚
1. タイトルページ（ロゴ・日付・会社名）
2. 現状分析（クライアントの課題を箇条書き、グラフ1枚）
3. 提案内容（3つのメリット、図解付き）
4. 導入スケジュール（ガントチャート）
5. 契約条件（価格表）
– トーン：丁寧かつプロフェッショナル（フレンドリーすぎない）
– 文字サイズ最小値：18pt（プレゼン時に見やすく）
– 作成後：スライド一覧で確認、問題あれば指摘して」
このように書くと、Claudeは以下を自動的に判断できます：
- 「ロゴをどこに置くか」
- 「グラフの形式」（円グラフ？棒グラフ？）
- 「スライドの配色」（会社イメージに合わせるべき）
- 「ガントチャートの粒度」（月単位？週単位？）
ゴールファーストで避けられるムダ
❌ あるある
- 「もっとシンプルに」で修正
- 「グラフはこの形で」と修正
- 「色がダサい」と修正
- 計3回のやり直し
✅ ゴールファースト
- 最初から完成形を提示
- 初回で条件をすべて満たす
- 微調整1回で完了
- 時間節約：3倍速
ClaudeCode公式の推奨
この「ゴールファースト」は、単なる我流ではなく、Anthropic公式ドキュメントでも推奨されている手法です。
「Claude Codeは指示文を上から順に処理するため、ゴールが先頭にあれば全体の方向性を正しく把握した上で作業を開始します」
— Anthropic公式「Claude Code Prompt Engineering」
まとめ：プロンプト≠「お願い」、プロンプト＝「仕様書」
ClaudeCodeをうまく使いこなしている人の共通点は、プロンプトを「仕様書」として書いていることです。
仕様書には「最終形」「制約」「検証」が必ず含まれます。これを意識するだけで、やり直しは劇的に減ります。
コメント