Few-Shotプロンプティングはプロンプトにいくつかの完全な「入力→出力」デモ例を提供し、AIがこれらの例から期待するタスクパターンを学習させ、新しい入力に同じパターンを適用させます。
Zero-Shotとのコアの違い：Zero-Shotは「Xをしてほしい」と直接言い、例はありません。Few-Shotは「こうやってXをしてほしい」と言い、例を提供します。適している場合：特定の非標準フォーマット；言葉で説明しにくいスタイル；高一致性のバッチタスク。
良いFew-Shotのデモ例はどのように設計すべきですか？よくある設計ミスは？
良いデモの設計原則：
原則1：タスクの主な変形をカバーする。タスクに異なるケースがある場合、異なるケースの処理方法を例に含める。
原則2：例には多様性を持たせ、Claudeが過度に狭いパターンを学習するのを避ける。
原則3：デモのアウトプット品質は期待する最高水準を代表すべき。
よくある設計ミス：品質が参差多様な多すぎる例；エッジケースをカバーしない；実際のタスクの入力分布と異なる例。
Few-Shotの例はプロンプトのどこに配置すべきですか？順序は重要ですか？
例の配置：最も一般的な構造は「タスクの説明→デモ例→新しいタスク入力」です。Claudeはまずタスクの全体的な目標を理解し、次に例から具体的なフォーマットとスタイルを学習し、最後に新しい入力に適用します。
例の順序は重要ですか？研究によると、最後に配置された例（新しいタスク入力に最も近い）がClaudeに最も大きな影響を与えます。
Claude Projectsでの使用：固定のデモ例がある場合、Project Instructionsに入れてください——毎回の会話で例を貼り付ける必要はありません。
Few-ShotとFine-tuning（微調整）の違いは何ですか？いつFew-ShotからFine-tuningにアップグレードすべきですか？
両方ともモデルに「特定のスタイルまたはタスクパターンを学習させる」アプローチですが、メカニズムとコストが全く異なります：
Few-Shot：デモ例をプロンプトに入れます；各APIコールにこれらの例が必要です。長所：トレーニング不要、いつでも例を変更可能。短所：例がコンテキストウィンドウを消費する。
Fine-tuning：大量のデモ例でモデルを再トレーニングし、スタイルとタスクパターンを「内部化」させます。長所：プロンプトに例が不要（トークンコスト節約）。短所：大量の高品質な訓練データが必要。
いつFine-tuningにアップグレードすべきか：ほとんどの場合、Few-Shotで十分です。
コンテンツマーケティング会社が毎日クライアントが提供する20本の長文記事をソーシャルメディア用の短文版（各150字以内、最も重要な洞察を保持、活発なトーン）に圧縮する必要があります。
Few-Shotなし（Zero-Shot）：毎回詳細に要件を述べます。各アウトプットのフォーマットとスタイルが若干異なる場合があり、微調整に時間がかかります。
Few-Shotを使用：初期設定時に3つの「長文→短文」のデモ例を提供し、Claude Project Instructionsに入れます。その後は元の長文を貼り付けて「デモフォーマットに従ってこの記事を圧縮してください」と言うだけです。
これはバッチの繰り返しタスクでのFew-Shotのコアバリューを示しています：デモを一度設定し、後続のすべてのアウトプットが一貫した品質とフォーマットを維持します。
Few-Shotのコアなトレードオフ：アウトプットの一貫性 vs コンテキストウィンドウの消費。デモ例はプロンプトにあり、各APIコールでこれらのデモのトークン転送が必要です——例が多いほど、コストが高く、コンテキストウィンドウの消費が大きくなります。実用的なアプローチ：最小の例（2つ）から始め、アウトプットが十分に一致しない場合は増やします——無闇に例を追加するのではなく、必要な一貫性レベルを達成する最小のデモ数を見つけてください。