Few-Shot Prompting

少数例プロンプティングとは、指示にいくつか（通常二から五個）の「入力と対応する出力」の具体的な例を添え、フォーマット、トーン、判断ロジックが何であるかをClaudeに例から直接読み取らせることを指す。すべての細部を文章で説明する必要はない。これは zero-shot prompting（ゼロショットプロンプティング）と同じスペクトラムの反対側にある。zero-shot は例を一切与えず、指示の文章だけで要求を明確にするが、few-shot は例にその説明の負担を分担させる。特に、言葉で正確に説明するのは難しいが例を見れば一目で分かるような場面、たとえばトーンの微妙な違い、ある項目の長さの目安、境界条件への対応方法などに向いている。例が実際に行っているのは、あなたの頭の中にある暗黙の基準を、Claudeが直接模倣できる具体的な対象に変換することだ。

このニーズが生じるのは、ある種の要求は言葉で正確に説明するコストが、例を一つ示すコストよりはるかに高いからだ。「プロフェッショナルだが硬すぎないトーンで」という指示は、十人いれば十通りの解釈がありうるが、あなたがちょうど良いと感じた過去のメールを例として添えれば、Claudeはその塩梅を直接つかむことができ、「硬すぎない」の境界をあなたが定義する必要はない。同じ理屈はフォーマットの細部にも当てはまる。レポートの要約はどこまで簡潔にすべきか、箇条書きに完全な文が必要かどうかといったルールは、文章にすると長く曖昧になりがちだが、例を一つ示せば一目で分かる。少数例プロンプティングが存在する理由は、多くの品質基準が本質的に暗黙的であり、ルールとして網羅的に書き出すのが難しいという現実を認めている点にある。例は、その種の暗黙の基準を外部化する最も効率的な方法なのだ。

実務では、品質を左右する三つの要点がある。第一に例の数だ。通常二から五個で十分であり、少なすぎる（一つだけ）とClaudeがその例の偶然の特徴をルールだと誤解しやすく、多すぎるとプロンプトが長くなりコストが増える。五個を超えると限界効果は通常はっきりしなくなる。第二に例の代表性だ。例は実際に遭遇する状況のばらつきをカバーする必要があり、順調で標準的なケースだけを与えてはならない。実際のタスクの二割がデータ欠損や書式の不統一といった境界ケースであれば、例にも少なくとも一つそうしたケースを含めるべきであり、そうしなければClaudeは順調なケースの扱い方しか学ばず、境界ケースに直面したときに拠り所がなくなる。第三に例の並べる順序だ。見落とされがちだが実際に影響のある細部で、最も異質な例を最後に置くと、モデルはそれを「直近の指示が前の例より優先される」と捉え、最後の例の特徴を過度に模倣してしまうことがある。この部分問題については example ordering（範例排序）という概念でより詳しく論じられており、あわせて参照する価値がある。

あなたにとって、少数例プロンプティングの本当の価値は、自分の中では基準がはっきりしているのに正確な定義を言葉にできないときに現れる。そうしたケースでは、文章のルールとして無理に書き出すより、例を一つ見つける方が確実だ。これは職場の場面で特に有用だ。多くの品質基準は本質的に暗黙的で経験の積み重ねによるものだからだ。「このメールのトーンは対外的な基準に合っている」というのは、見れば分かるが文章のルールにするのは難しいことが多い。本当に検討すべきなのは例を手に入れるコストだ。手元にちょうど良い例が既にあれば、few-shot の追加コストはほぼゼロだ。既存の例がなくその場で例を作らなければならない場合、その作成プロセス自体が誤りを生む可能性があり、明確に書かれたゼロショット指示の方がかえって信頼できることもある。注意すべきリスクは、例の数が少なすぎたり代表性が不足していたりすると、Claudeが「学びすぎる」傾向があることだ。例の中の重要でない細部（たまたま使った言葉、たまたま長かった段落など）をルールだと誤認し、そのまま模倣してしまう。この場合、問題は多くはプロンプトの書き方が悪いのではなく、例そのものが本当に学ぶべきものをカバーしていなかったことにある。