5-3 Best of N プロンプト術｜Claude Code に 3 案出させる

このレッスンで身につくこと

このレッスンは第 5 章「プロンプト術」の締めくくりです。5-1 で CLAUDE.md という常設の前提、5-2 で 1 発のプロンプトを磨く コツを学びました。ここで扱うのは、1 発勝負ではなく統計勝負に持ち込む もう一段上の発想です。

Best of N とは、同じ課題を N 通り の方向性で並列に依頼し、出てきた候補を比較して 1 つを選ぶ手法。N はだいたい 3、多くても 5。1 つの「正解っぽい答え」 を出させるのではなく、3 つの方向性のうちのベスト を選ぶことで、ヒット率を統計的に底上げします。

所要時間 — 約 30 分（手を動かしながらなら 45 分） 難易度 — ★★☆☆☆（5-1 / 5-2 を読み終えていれば OK）

Best of N の発想 — 1 発勝負ではなく統計勝負

AI コーディングでも、ほとんどの人は無意識に 1 発勝負 をしています。「ログイン画面を作って」と投げて、返ってきた 1 案に「うーん、惜しい」と感じ、追加プロンプトで直す。ループ 3〜5 回で 30 分 がよくあるパターンです。

Best of N の発想は逆向きです。「最初から 3 通り出して」 と頼んで、3 案を並べてから「B が一番近い、少しだけ修正して」と進めます。1 案 → 修正 → 1 案 → 修正 の直列ループを、3 案を並列に作る + 1 回の選択 にショートカットするわけです。

なぜ 3 案を並べると速いのか

「3 案作ってから 1 つ選ぶ」 ほうが 「1 案を 3 回直す」 より速い理由は 3 つあります。方向性のすり合わせが先に終わる（3 案並べた瞬間に意思決定が 30 秒で完了）、自分の好みが言語化される（「B が好き」の理由を考えると評価軸が顕在化）、コンテキスト消費が少ない（中間の往復が圧縮されて、第 9 章の ==/compact== 前にトークンを節約できる）。

直列ループ  依頼 → 案 1 → 直して → 案 2 → 直して → 案 3   合計 6 ターン
Best of N   依頼（3 案で）→ A・B・C → B を選んで少し直す   合計 3 ターン

半分の往復で同じ結論 にたどり着きます。慣れてくると、Best of N をデフォルトの作業スタイルにする人も多くなります。

いつ使うか / いつ使わないか

Best of N は便利ですが、万能ではありません。解が 1 つに定まらない仕事 すべてに有効です — デザイン・UI、API / DB 設計、アルゴリズム選択、文章生成（メール / PR タイトル / リリースノート）、リファクタ方針、アーキテクチャ、テスト戦略。共通するのは、「正解」がプロジェクトのフェーズや好みや制約で変わる ことです。

逆に、正解が 1 つに決まっている作業 では Best of N は むしろ無駄 です — バグ修正、フォーマット変換、単純なリネーム、仕様が明確な実装、CI / lint 設定。3 案出させても似たような実装が並ぶだけで、トークン代と時間の無駄になります。

見落としやすい場面

意外と効くのに忘れがちなのは、プロンプト自体の設計（CLAUDE.md の章立てを 3 案、メタな仕事ほど効く）、コミットメッセージ / リリースノート（小さい仕事ほどコストが安く ROI が高い）、エラーメッセージの文言（「謝罪・案内・行動促し」の 3 トーンで UX が変わる）の 3 つ。

3 通り依頼の実例

ここから 実際に使えるプロンプト を 3 つの領域で見ていきます。コピペして自分のプロジェクトに当てはめれば、今日から Best of N が回せます。

実例 1 — API 設計

新しい機能の API を設計するとき、REST / RPC / 状態遷移を URL に明示 など方向性で答えが変わります。3 案を並べる典型例です。

> 「ユーザーの予約状態を管理する API」を、3 つの設計案で出して。

案 A — REST らしく、リソース指向（GET/POST/PATCH/DELETE /reservations）
案 B — RPC らしく、アクション指向（POST /reservations.create / .cancel）
案 C — 状態遷移を URL に明示（POST /reservations/:id/confirm）

各案について比較表で報告。
- 利点 / 欠点
- フロントエンドからの呼び分けやすさ
- 既存の openapi.yaml との一貫性
- マイクロサービス化したときの拡張余地

案 A / B / C の方向性を プロンプト側で先に決めておく のがコツです。「3 案出して」と丸投げすると、Claude Code は微差の 3 案を返してきます。軸を 3 つ用意 することで、本当に違う 3 案になります。

実例 2 — 文章生成（リリースノート）

文章はとくに トーンと粒度 で印象が変わる領域。リリースノート 1 本でも 3 案出してみる価値があります。

> 以下の Pull Request の内容から、ユーザー向けリリースノートを 3 案書いて。

PR 内容: ダッシュボードの読み込み速度を 4 秒 → 1 秒に短縮（キャッシュ層追加）

案 A — 技術的な詳細を含む（開発者ブログ向け、200 文字）
案 B — シンプルで一般ユーザー向け（変更内容のみ、80 文字）
案 C — マーケティング寄り（メリットを強調、120 文字）

それぞれ「想定読者」と「狙う印象」も 1 行で添えて。

案 A / B / C で 読者を明確に分ける のがポイントです。同じ PR でも「開発者向け」「一般ユーザー向け」「マーケティング寄り」で良い文面はまったく違います。3 案並べて初めて、「うちのリリースノートのトーンは案 B 寄りだな」と気づけます。

実例 3 — リファクタ方針

「このコードをリファクタして」 は、5-2 の失敗パターン「全部やって族」の典型例です。Best of N で 3 つの方針を先に出させる流れに変えると、安全に進められます。

> app/routes/dashboard.tsx をリファクタしたい。
> まず実装には入らず、3 つの方針を比較表で提示して。

案 A — 関心の分離を優先（データ・ロジック・表示を 3 ファイルに分割）
案 B — 1 ファイル内の整理を優先（同ファイル内で関数分割、diff 最小化）
案 C — Server Component への移行（クライアントロジックを Server Action に）

比較項目: 変更行数 / テスト影響 / リスク / 期待効果
私が 1 つ選んだら実装に進む。

「私が選ぶまで実装しない」 の一文が、Best of N をリファクタで使うときの お守り です。これがないと、Claude Code は親切心で 3 案を全部実装し始めかねません。

プロンプトのバリエーション軸

3 案を出させるとき、軸が下手だと 3 案が似てしまいます。せっかく Best of N を回しても、微差の 3 案 からは何も学べません。ここでは、現場で効きやすい バリエーション軸 3 種 を紹介します。

軸 1 — 視点軸

同じ問題を「誰が見るか」で揺らす 軸です。同じ機能でも、エンドユーザー視点と運用者視点では設計が変わります。

案 A — エンドユーザーが使いやすいことを最優先
案 B — 運用担当者がメンテしやすいことを最優先
案 C — 開発者が拡張しやすいことを最優先

役割を明示的に振る ことで、3 案が確実にバラけます。5-2 で扱った ロールプレイ指示 の応用形でもあります。「あなたは UX デザイナーとして」「あなたは SRE として」「あなたは開発リードとして」と振ることで、Claude Code が それぞれの観点のチェックリスト を内部で立てて返してくれます。

軸 2 — 制約軸

制約条件をずらす 軸です。同じ機能でも、ライブラリの有無、行数制限、依存関係の許容度が違うと出てくるコードはまるで別物です。

案 A — 外部ライブラリ自由（react-hook-form + zod + radix-ui）
案 B — 既存依存のみで実装（追加 npm install なし）
案 C — Vanilla（フレームワーク・ライブラリの最小集合のみ）

制約軸の Best of N は、技術選定の前段階 でとくに有効です。「ライブラリを足す価値があるか」を、実際のコード量で比較 できるので、判断が一気に楽になります。

軸 3 — フォーマット軸

出力の見せ方を変える 軸です。同じ情報でも、表 / 図 / 散文 / JSON で受け手の理解度が変わります。

案 A — Markdown 表（比較項目を列で並べる）
案 B — Mermaid 図（フローを視覚化）
案 C — JSON（自動処理しやすい構造化データ）

それぞれの「強み・弱み」と「向いている用途」を最後に 3 行でまとめて。

フォーマット軸 は、ドキュメント作成や設計レビュー でとくに価値が出ます。後で別ツール（Notion、Figma、社内 Wiki）に貼り直すなら、最初から 貼り先に合う形 を Best of N で見つけておくと、二度手間が消えます。

結果の比較方法 — 客観基準とチェックリスト

3 案を出させたあと、どう選ぶか。「なんとなく B が好き」だけで決めると、後で説明できない選択 になります。チーム合意も難しくなります。

比較の鉄則 — 軸を 3 つに絞る

3 案を比較するとき、評価軸も 3 つに絞る のが鉄則です。10 個並べると判断不能になるので、プロジェクトの優先度から トップ 3 を選びます。

> 案 A / B / C を以下の 3 軸で評価し、表で示して。
軸 1 — 実装コスト（人月換算）
軸 2 — メンテナンスコスト（半年後の改修しやすさ）
軸 3 — リスク（壊れる可能性、依存の安定性）
最後にプロジェクト状況（中小向け、開発者 2 名）を踏まえて
おすすめを 1 つ選び理由を 3 行で。

Claude Code に推薦理由まで書かせる のが地味に効きます。3 案 + 比較表 + 推薦理由 + 自分の最終判断、というフローで 判断の透明性 が一気に上がります。

よくある評価軸

評価軸の候補は「実装コスト」「メンテコスト」「パフォーマンス」「可読性」「拡張性」「学習コスト」「依存リスク」「ユーザー体験」の 8 つを覚えておけば十分。「実装コスト + メンテコスト + 依存リスク」は社内ツールで効く 3 点セット、「ユーザー体験 + パフォーマンス + 可読性」はプロダクト機能で効く 3 点セット。フェーズに合わせて使い分けます。

客観基準を「数値」で持つ

比較を 主観の言い合い にしないコツは、数値化できる軸を 1 つでも混ぜる ことです。実装コストは行数、パフォーマンスは初回ロード秒数、可読性は関数最大行数、依存リスクは追加 npm パッケージ数で数値化。1 つでも数値 があると、「B が好き」が「B のほうが行数が 30% 少ない」に変わります。説明可能な判断 は、チーム共有でも半年後の振り返りでも武器になります。

コスト試算 — 3 通り走らせるとどれくらい

「Best of N って、3 倍のトークン使うんでしょ？」とよく聞かれます。実態を数値で見ておきます。

トークン消費の実感

3 案出させるときの実消費は 単純な 3 倍ではない ことが多いです。入力プロンプト は 1 回分しか課金されず、出力 だけが N 倍されるため、合計は 1.5〜2 倍程度 に収まります（入力 2,000 + 出力 1,500 → 入力 2,100 + 出力 4,000 で計 1.7 倍が典型）。Sonnet で 1 セッションあたり 数円〜十数円 の差。「30 分の意思決定を短縮できる」と考えれば ROI は圧倒的にプラスです。

頻度が高い場面（1 日 100 回投げる中重度ユーザー、大規模リファクタを丸ごと Best of N で進める場面）では、月数千〜数万円の差 が出てきます。第 9 章で扱う ==/cost== コマンドで、Best of N を回したセッションのトークン消費を週 1 で確認しておくと、過剰投資の癖が早めに見つかります。

安く Best of N するコツ

コストを抑えるテクニックを 3 つ。軸だけ先に出させる（「3 案の方向性だけ 3 行ずつ」で軽く方針出し、選んでから 1 案だけフル実装）、Haiku で N 案 → Sonnet で詳細 の 2 段構え、キャッシュを効かせる（入力トークンが 90% 引きになる）。

失敗パターン

実務でやりがちな Best of N の失敗 5 つ を整理します。出会ったら自分のプロンプトを 1 行ずつ見直してください。

対処は次のとおりです。

プロンプトテンプレート

すぐ使える形 にまとめます。コピペして自分のプロジェクトに当てはめてください。

テンプレ 1 — 設計検討（API / アーキテクチャ向け）

[対象] を 3 つの設計案で出して。

案 A — [軸 1 の極]
案 B — [軸 2 の極]
案 C — [軸 3 の極]

各案で記述: 概要 3 行 / 主な API / データモデル影響 / 既存との整合性
比較軸: 実装コスト / メンテコスト / リスク
推薦: プロジェクト状況（[フェーズ / チーム規模]）を踏まえて 1 案 + 理由 3 行
重要: 私が選ぶまで実装しない

テンプレ 2 — 文章生成（リリースノート / メール文面向け）

[文章の用途] を 3 案書いて。

元情報: 変更点 / 読者 / 媒体
案 A — [トーン 1 と想定読者]
案 B — [トーン 2 と想定読者]
案 C — [トーン 3 と想定読者]
制約: 文字数上限、含めるキーワード、含めないもの
出力: 案ごとに「想定読者 / 狙う印象 / 本文」の 3 セクション

テンプレ 3 — リファクタ方針（コード変更向け）

[対象] のリファクタ方針を 3 つ提案。今回は実装しない。

案 A — 大胆な変更（関心の分離、ファイル分割）
案 B — 変更最小化（同ファイル内の整理）
案 C — 中庸

各案で記述: 概要 2 行 / 変更行数目安 / 触るファイル / テスト影響 / リスク
比較: 変更コスト / 期待効果 / リスク
進め方: 私が 1 つ選んだら、小さい diff 単位で実装に進む

CLAUDE.md と組み合わせる

Best of N は CLAUDE.md と組み合わせると さらに強力になります。プロジェクトのデフォルト評価軸 を CLAUDE.md に書いておくと、毎回のプロンプトに軸を書かなくても、Claude Code が 自動で当てて くれます。

## 設計判断の評価軸（優先順位順）
1. メンテコスト — 開発者 2 名、半年後の改修しやすさ最優先
2. 実装コスト — 短期で動かす必要あり、最小追加を優先
3. 依存リスク — 重要システムへの依存は避ける

## 3 案検討のデフォルト軸
- A: シンプル優先（既存依存のみ、変更最小）
- B: 拡張性優先（ライブラリ追加可、将来を見越す）
- C: パフォーマンス優先（コードが増えても速さ重視）

これを書いておけば 「3 案で出して」 とだけ言うだけで軸が自動適用され、プロンプトが短くなり結果は安定 します。

まとめ

このレッスンのポイントを 6 点で振り返ります。

1. Best of N は 1 発勝負ではなく統計勝負。3 案を並列に出させてベストを選ぶ
2. 使うのは 解が 1 つに定まらない仕事（設計・文章・リファクタ）。正解が 1 つの作業 には使わない
3. バリエーション軸 は「視点 / 制約 / フォーマット」の 3 種
4. 評価軸は 3 つに絞る。1 つは数値化できる軸を入れる
5. コストは 単純 3 倍ではなく 1.5〜2 倍。「方向性だけ Best of N」が最もコスパが高い
6. 失敗 5 つ — 似通った 3 案 / 評価軸なし / 採用判断曖昧 / 案を出しすぎ / 場面違い

<Quiz question="Best of N を使うべき場面はどれですか？" options={["新機能の API 設計やリファクタ方針のように、解が 1 つに定まらない場面","JSON から CSV への変換のように、入力と出力が決まっている場面","既存テストが定義する挙動を、テストどおりに実装する場面"]} answer={0} />

<Quiz question="3 案を出させるときに「似通った 3 案」になるのを防ぐコツはどれですか？" options={["プロンプトの中で「視点 / 制約 / フォーマット」のどれかを軸にして、3 つの極を明示的に振り分ける","Claude Code に「自由に 3 案考えて」と任せ、軸の指定は一切しない","案の数を 10 個以上に増やして、バリエーションが自然に出るのを待つ"]} answer={0} />

<Quiz question="Best of N のコストについて正しい説明はどれですか?" options={["単純に 3 倍ではなく、入力プロンプトは 1 回分なので 1.5〜2 倍程度に収まることが多い","案の数だけ完全に倍のコストがかかるため、必ず 3 倍以上の料金を見込む必要がある","API 利用料は完全に無料なので、コストを気にせず 10 案以上出すのが推奨される"]} answer={0} />

次のレッスン 6-1: はじめての Web アプリ では、ここまでの CLAUDE.md × プロンプト 5 大原則 × Best of N をフル動員して、実際に動く Web アプリをゼロから作っていきます。第 5 章で身につけた 言語化と設計の力 が、次の章でいよいよ目に見える成果物になります。