Few-shotとChain-of-Thought
ストーリー
「パターンは覚えた? じゃあ次はもう一段上のテクニックだ」
中島先輩がホワイトボードに「Zero-shot」「Few-shot」「CoT」と書いた。
「この3つを使い分けられると、AIの回答精度が格段に上がる」
「Zero-shot... Few-shot... 聞いたことあるような」
「機械学習の用語だけど、プロンプトでも同じ概念が使える。 百聞は一見にしかず、実際にやってみよう」
Zero-shot vs Few-shot
Zero-shot(例なしで指示)
例を一切示さず、指示だけで回答を求める方法です。
プロンプト:
以下のコミットメッセージを日本語に翻訳してください。
"Fix bug in user authentication flow"
→ AIの回答: "ユーザー認証フローのバグを修正"
簡単なタスクならZero-shotで十分ですが、複雑なタスクやフォーマットの統一が重要な場合には不十分です。
Few-shot(例を示して指示)
具体的な入出力の例を数個示してから、同様のタスクを依頼する方法です。
プロンプト:
以下のルールでコミットメッセージを生成してください。
例1:
変更内容: ログイン画面にバリデーションを追加した
コミットメッセージ: feat(auth): ログインフォームにバリデーションを追加
例2:
変更内容: ユーザー一覧のページネーションが壊れていたのを修正した
コミットメッセージ: fix(users): ユーザー一覧のページネーション不具合を修正
例3:
変更内容: テストのsetup処理を共通化した
コミットメッセージ: refactor(test): テストsetup処理を共通ヘルパーに抽出
では、以下の変更内容に対するコミットメッセージを生成してください:
変更内容: 商品検索のレスポンスタイムが遅かったのでインデックスを追加した
AIの回答:
コミットメッセージ: perf(products): 商品検索のレスポンス改善のためDBインデックスを追加
Few-shotの効果
| 手法 | 精度 | フォーマット一貫性 | 適用場面 |
|---|---|---|---|
| Zero-shot | 中 | 低(AIの判断) | 単純なタスク |
| One-shot(1例) | 中〜高 | 中 | フォーマットのヒントが欲しい時 |
| Few-shot(2-5例) | 高 | 高 | 出力の統一が重要な時 |
Few-shotの実践テクニック
テクニック1: 正例と負例を両方示す
プロンプト:
TypeScriptの関数名を命名規則に従って生成してください。
良い例(正例):
- ユーザーを取得する → fetchUserById
- 注文を作成する → createOrder
- メールを送信する → sendNotificationEmail
悪い例(負例):
- ユーザーを取得する → ✗ get_user(スネー クケースは不可)
- 注文を作成する → ✗ order(動詞なし)
- メールを送信する → ✗ doEmail(曖昧な命名)
では、以下の処理の関数名を生成してください:
- 在庫数を確認する
- CSVファイルをパースする
- パスワードをハッシュ化する
テクニック2: エッジケースを含める
プロンプト:
APIのレスポンスコードを判定する関数を作成してください。
入力と期待出力の例:
- 200 → { status: "success", retry: false }
- 201 → { status: "success", retry: false }
- 400 → { status: "client_error", retry: false }
- 401 → { status: "auth_error", retry: false }
- 429 → { status: "rate_limit", retry: true }
- 500 → { status: "server_error", retry: true }
- 503 → { status: "unavailable", retry: true }
上記のパターンに従い、全HTTPステータスコードに対応する
TypeScript関数を実装してください。
テクニック3: 複雑な変換ルールを伝える
プロンプト:
データベースのカラム名からTypeScriptのプロパティ名を生成する関数を作ってください。
変換例:
- user_name → userName
- created_at → createdAt
- is_active → isActive
- order_item_id → orderItemId
- html_content → htmlContent
変換ルール(例から推測してください)を適用する関数を
TypeScriptで実装してください。
Chain-of-Thought(CoT)
CoTとは
AIに段階的に考えさせるテクニックです。いきなり答えを出させるのではなく、「ステップバイステップで考えて」と指示することで、推論の精度が向上します。
Zero-shot CoT
最もシンプルなCoT。「ステップバイステップで考えてください」を追加するだけ。
プロンプト(CoTなし):
以下のコードのバグを見つけてください。
[コードを貼り付け]
プロンプト(CoTあり):
以下のコードのバグを見つけてください。
ステップバイステップで分析してください。
1. まず、コードの全体的な構造を把握してください
2. 次に、各関数の入出力を確認してください
3. そして、エッジケースを検討してください
4. 最後に、見つかったバグと修正案をまとめてください
[コードを貼り付け]
CoTが効果を発揮する場面
| 場面 | なぜCoTが有効か |
|---|---|
| 複雑なバグの分析 | 段階的に原因を絞り込める |
| アーキテクチャの比較 | 各観点を順番に評価できる |
| パフォーマンス最適化 | ボトルネックを段階的に特定 |
| セキュリティレビュー | OWASPの各項目を順番にチェック |
| リファクタリング判断 | 変更のリスクを段階的に評価 |
実践例:パフォーマンス問題の分析
プロンプト:
以下のAPIエンドポイントでレスポンスが5秒以上かかっています。
ステップバイステップで原因を分析し、改善案を提案してください。
分析ステップ:
1. コードを読んで処理フローを把握する
2. N+1問題やループ内の非効率な処理がないか確認する
3. データベースクエリの効率性を評価する
4. 不要な処理や重複処理がないか確認する
5. キャッシュ可能な処理を特定する
6. 各改善案を効果の大きい順にリストアップする
[コードを貼り付け]
Few-shot + CoT の組み合わせ
最も強力な組み合わせです。例と思考過程の両方を示します。
プロンプト:
以下のコードレビューの例を参考に、新しいコードをレビューしてください。
--- 例 ---
コード: app.get('/user', (req, res) => { ... })
思考過程:
1. このエンドポイントはRESTの命名規則に従っているか?
→ /user は単数形。リソースが複数返る場合は /users が適切
2. 認証・認可のチェックはあるか?
→ ミドルウェアが適用されていない。認証が必要なエンドポイントか確認必要
3. エラーハンドリングは適切か?
→ try-catchがない。エラー時に500が返る可能性
結論: 重要度 Warning - 命名規則の統一と認証ミドルウェアの追加を推奨
--- レビュー対象 ---
上記と同じ分析ステップで、以下のコードをレビューしてください:
[新しいコードを貼り付け]
使い分けのガイドライン
タスクの複雑さで判断:
単純なタスク(翻訳、フォーマット変換)
→ Zero-shot で十分
フォーマットの統一が重要なタスク
→ Few-shot(2-3例)
複雑な分析・推論が必要なタスク
→ CoT(ステップバイステップ指示)
高精度な複雑タスク
→ Few-shot + CoT(例 + 思考過程を提示)
まとめ
| テクニック | 説明 | 使いどころ |
|---|---|---|
| Zero-shot | 例なしで指示 | 単純なタスク |
| Few-shot | 入出力の例を提示 | フォーマットの統一、変換ルール |
| Chain-of-Thought | 段階的に考えさせる | 複雑な分析、推論 |
| Few-shot + CoT | 例と思考過程の両方を提示 | 最高精度が必要な場面 |
チェックリスト
- Zero-shotとFew-shotの違いを説明できる
- Few-shotの例を2-3個作成して使える
- Chain-of-Thoughtの指示方法を理解した
- タスクの複雑さに応じてテクニックを使い分けられる
次のステップへ
Few-shotとCoTをマスターしたら、次は「システムプロンプトとロール設定」を学びます。
AIの振る舞いを根本から制御する、より強力なテクニックです。
推定読了時間: 30分