LESSON 30分

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分