Few-shot と Chain of Thought

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

入力: 「営業時間は 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 の落とし穴

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

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

wzxhzdk:1

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

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

wzxhzdk:2

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

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

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

推論を見せる vs 見せない

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

wzxhzdk:3

CoT を試す

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

営業時間の自然言語記述から JSON を抽出するプロンプトを Few-shot で 書いてください。

入力例: 「平日 10 時から 19 時、日祝休み」

期待出力: 期待出力:

境界ケース (24 時間営業 / 中休みあり / 不明な記述) も含むテストを 3 件作って試してみましょう。

次のパズルを CoT 無し と CoT 有り で解かせて、正答率を比較してみましょう。

A・B・C の 3 人がいる。A は嘘つき、B は正直者、C はランダムに答える。 あなたは 3 人を区別できないが、Yes/No 質問を 1 回だけできる。 どんな質問をすれば、正直者がどれかを必ず特定できるか?

(これは古典的な難問で、CoT 無しだとモデルがしばしば誤ります)