Few-Shotプロンプティングとは何ですか?求める出力を純粋に言葉だけで説明することとどう違いますか?
Few-Shotプロンプティングとは、プロンプトの中にいくつかの具体的な例——入力内容と期待される出力を組み合わせたもの——を含めることで、Claudeがそれらの例から直接、求めるスタイル、フォーマット、細部の加減を読み取れるようにする手法であり、抽象的な文章による説明で伝えるのではない。例えばClaudeにコミットメッセージを書く手伝いをしてほしい場合、「簡潔でプロフェッショナルなトーンで変更を説明してください」と書く代わりに、「これはどんなコード変更か」と「これが導き出されるべきコミットメッセージである」という実際の事例を2〜3組直接示すことができる。
純粋な文章による説明との最大の違いは、伝達の正確さにある。文章による説明はあいまいな部分が生じやすい——「簡潔」「プロフェッショナル」といった形容詞は、人によって認識する基準が完全には一致しない。一方、例はあなたの頭の中にある「正確な姿」を直接Claudeに見せるものであり、「スタイルを言葉で説明する」という途中で失われがちな翻訳のプロセスを省くことができる。
Few-Shotプロンプティングはなぜ必要とされ、どんな問題を解決するのですか?
出力要件を純粋に文章だけで説明すると、ある具体的な限界にぶつかる。言語そのものが「スタイル」「トーン」「きめ細かなフォーマットルール」といったものを表現する能力には限りがあるという点である。「親しみやすいがプロフェッショナルなトーンで」と書くことはできるが、「親しみやすいがプロフェッショナル」が実際に文章としてどう表れるべきかは、人によって心の中に描くイメージがかなり異なる可能性がある。このギャップは指示の書き方が十分丁寧でなかったからではなく、言葉そのものがこの種の微妙なニュアンスを伝える際に、本質的に限界を持っているからである。
Few-Shotプロンプティングが解決するのは、まさにこの「言語の表現力不足」という問題である。求めるスタイルに近づけようと形容詞を積み重ね続けるよりも、直接例を示す方がより直接的なコミュニケーション方法である。ちょうど新しい同僚に報告書の書き方を教えるようなもので、「だいたいこんな感じ」と口頭で説明するよりも、過去にうまく書けた報告書を2〜3部直接見せた方が、本人がその「感じ」が何であるかを自分でつかみやすい。例が伝える情報密度は、同じ分量の文章による説明よりも高いことが多い。
Few-Shotプロンプティングは実際にどのように機能し、例はいくつ与えるべきで、どう選べば効果的ですか?
仕組みとしては、Claudeが提供された例から共通するパターン(フォーマットの構造、トーン、判断ロジック)を読み取り、そのパターンを新しい入力に適用する。例の数に絶対的な決まりはないが、実務上は通常2〜3組で明確な効果が見られる。重要なのは数の多さではなく、その例自体があなたが気にしている重要なバリエーションをカバーしているかどうかである。例えば、Claudeに作成してほしい内容が2つのよくある状況(機能追加とバグ修正という2種類のコミットなど)にまたがる場合、両方それぞれ少なくとも1組ずつ含めた方がよく、片方の状況の例だけを与えるべきではない。そうしないと、Claudeがもう一方の状況に遭遇したときに、類推するための十分な参考が得られない可能性がある。
例を選ぶ際は、量よりも質が重要である。5つの平凡な例を詰め込むよりも、「良い」と「まだ十分でない」の違いを明確に示せる2〜3個の例を厳選する方がよい。タスク自体に明確な出力フォーマットのルール(固定された項目の順序など)がある場合、例と組み合わせて明示的なフォーマットテンプレートを追加することで、Claudeが「ルールそのもの」と「ルールが実際に適用された姿」の両方を把握でき、この2つを組み合わせる方が、どちらか一方だけを与えるよりも通常はより安定する。
Few-Shotプロンプティングは私にとって実際どんな意味があり、いつ例を使うべきで、いつ文章による説明で十分ですか?
判断基準は「この出力要件は明確な文章で言い尽くせるかどうか」という問いに立ち返るとよい。求めているものが明確な論理ルール(「担当者欄があるかどうかをチェックする」といった二択的な判断など)であれば、文章による説明で通常十分正確であり、追加の例は必要ない。しかし求めているものが「スタイル」「トーン」「きめ細かなフォーマットの加減」といった、数語では言い尽くせないものであれば、例の方が形容詞を積み重ねるよりも通常はClaudeに要点を早くつかませることができる。
実務上役立つ習慣は、ある要件を説明するために形容詞を何文もかけて書いたのに、それでも「これでは十分正確に伝わっていない」と感じたとき、それが例に切り替えることを検討すべきサインだということである。また、Few-Shotプロンプティングは毎回ゼロから例を考える必要はない。もしすでに過去にうまくできた実際の成果物(以前書いたよい報告書、よいコミットメッセージなど)が手元にあれば、その実際の成果物をそのまま例として使う方が、自分で新たに架空の例を作るよりも、本当に求めている基準に近いことが多い。
Anthropic公式のSkill作成ベストプラクティス文書は、コミットメッセージ生成Skillの書き方を示している。「入力されるコード変更の説明」と「出力されるコミットメッセージのフォーマット」の具体的な組み合わせを3組直接提供し、例の最後に「このスタイルに従うこと:type(scope): 簡潔な説明、続けて詳細な説明」という一文を付け加えることで、Claudeが例そのものとルールの文章による説明の両方を把握できるようにしている。
The advantage is bypassing the inherent limitations of written description when it comes to conveying style, tone, and fine-grained formatting rules, using concrete cases to more precisely communicate the standard you want — especially effective for subtle nuances that are hard to describe exhaustively in words; the drawback is that it takes time to prepare examples of good enough quality that cover different scenarios, and if the examples themselves are poorly chosen or only cover a single scenario, Claude may actually learn an overly narrow pattern, performing inconsistently when it encounters a scenario the examples didn't cover.