Few-shot と Chain of Thought

Few-shot Prompting

入力と理想の出力例をいくつか並べてから本番のタスクを与えると、フォーマット・スタイルの再現性が劇的に上がります。

入力: 「営業時間は 9-17 時です」
出力: {"open": "09:00", "close": "17:00"}

入力: 「土日休み、平日 10 時から 19 時」
出力: {"open": "10:00", "close": "19:00", "closed": ["sat", "sun"]}

入力: 「24 時間営業」
出力:

数件 (3〜5) で十分なことが多く、これを few-shot と呼びます。 1 件は one-shot, 例なしは zero-shot です。

Few-shot の落とし穴

• 例の偏り がそのまま出力の偏りになる (例が全部敬語 → 出力も全部敬語)。
• 例が長くなりすぎるとコストが膨れる。
• 境界ケース を含む例を選ぶと頑健になる。

Chain of Thought (CoT, 連鎖思考)

複雑な推論を要するタスクでは、Claude に 「考えながら答える」 よう促すと正答率が上がります。

質問を解く前に、ステップバイステップで思考過程を <thinking>...</thinking> に書いてください。
最終回答だけを <answer>...</answer> に書いてください。

Extended Thinking (拡張思考) との関係

Claude Opus 4.7 / Sonnet 4.6 などには Extended Thinking モードがあり、 モデル内部で長い思考連鎖を行ってから回答します。 プロンプトで明示的に CoT を書く代わりに、API パラメータで thinking を有効化できます。

client.messages.create(
    model="claude-opus-4-7",
    max_tokens=8000,
    thinking={"type": "enabled", "budget_tokens": 4000},
    messages=[...],
)

CoT を書くべきとき / 書くべきでないとき

✅ 書くべき: - 数学・論理パズル - 多段の推論を要する分析 - バグ調査などの探索 - 複雑な分類タスク

❌ 書かなくていい: - 単純な分類・抽出 (むしろノイズになる) - レイテンシが厳しいリアルタイム応答 - 大量バッチ処理 (コスト爆増)

推論を見せる vs 見せない

ユーザーに CoT 部分を見せない 設計が一般的です。XML タグで分離してから抽出。

import re
m = re.search(r"<answer>(.*?)</answer>", text, re.DOTALL)
final = m.group(1).strip() if m else text

CoT を試す

実際に CoT 有無で答えが変わるか比べましょう。