Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin Chain SAFU CryptoTax DeFAI AGI Claude Me Claude Skill Claude Design Claude Cowork
独立メディア
いかなるプロジェクトとも無提携
Claudeスキルを学んで、すべてをもっとうまくやろう
claudeskill-me.com
最新
Superpowersフレームワークレビュー:「テストより先に書かれたコードは削除する」をルール化したTDD手法  ·  CLAUDE.md、Rules、Skill、Hook、Subagent——どれを使うべきか?Anthropic公式の7つの指示方法の決定フレームワーク  ·  公式Frontend Design Skillレビュー:なぜインストール数が2位の57倍なのか?  ·  初めてのSkill作成:3回説明した作業を1つのコマンドに変える  ·  初めてのSystem Prompt作成:「あなたはアシスタントです」から実際に使える役割設定へ  ·  Claude CodeがMarketplaceの組織単位ワイルドカード制御を追加——1つのルールでGitHub組織全体を許可・ブロック可能に
用語解説 · Prompt Engineering

Few-Shot Prompting

Few-Shotプロンプティング
Prompt Engineering beginner

30秒バージョン · 忙しい方へ
求める出力を言葉で説明する代わりに、いくつかの具体的な「入力と出力」のペア例を直接示し、Claudeがその例自体から求めるスタイルやフォーマットを読み取れるようにする手法。文章による説明よりも細部を正確に伝えられることが多い。
詳しく読む +
01 · これは何?

Few-Shotプロンプティングとは何ですか?求める出力を純粋に言葉だけで説明することとどう違いますか?

Few-Shotプロンプティングとは、プロンプトの中にいくつかの具体的な例——入力内容と期待される出力を組み合わせたもの——を含めることで、Claudeがそれらの例から直接、求めるスタイル、フォーマット、細部の加減を読み取れるようにする手法であり、抽象的な文章による説明で伝えるのではない。例えばClaudeにコミットメッセージを書く手伝いをしてほしい場合、「簡潔でプロフェッショナルなトーンで変更を説明してください」と書く代わりに、「これはどんなコード変更か」と「これが導き出されるべきコミットメッセージである」という実際の事例を2〜3組直接示すことができる。

純粋な文章による説明との最大の違いは、伝達の正確さにある。文章による説明はあいまいな部分が生じやすい——「簡潔」「プロフェッショナル」といった形容詞は、人によって認識する基準が完全には一致しない。一方、例はあなたの頭の中にある「正確な姿」を直接Claudeに見せるものであり、「スタイルを言葉で説明する」という途中で失われがちな翻訳のプロセスを省くことができる。

02 · なぜ存在する?

Few-Shotプロンプティングはなぜ必要とされ、どんな問題を解決するのですか?

出力要件を純粋に文章だけで説明すると、ある具体的な限界にぶつかる。言語そのものが「スタイル」「トーン」「きめ細かなフォーマットルール」といったものを表現する能力には限りがあるという点である。「親しみやすいがプロフェッショナルなトーンで」と書くことはできるが、「親しみやすいがプロフェッショナル」が実際に文章としてどう表れるべきかは、人によって心の中に描くイメージがかなり異なる可能性がある。このギャップは指示の書き方が十分丁寧でなかったからではなく、言葉そのものがこの種の微妙なニュアンスを伝える際に、本質的に限界を持っているからである。

Few-Shotプロンプティングが解決するのは、まさにこの「言語の表現力不足」という問題である。求めるスタイルに近づけようと形容詞を積み重ね続けるよりも、直接例を示す方がより直接的なコミュニケーション方法である。ちょうど新しい同僚に報告書の書き方を教えるようなもので、「だいたいこんな感じ」と口頭で説明するよりも、過去にうまく書けた報告書を2〜3部直接見せた方が、本人がその「感じ」が何であるかを自分でつかみやすい。例が伝える情報密度は、同じ分量の文章による説明よりも高いことが多い。

03 · 意思決定にどう影響する?

Few-Shotプロンプティングは実際にどのように機能し、例はいくつ与えるべきで、どう選べば効果的ですか?

仕組みとしては、Claudeが提供された例から共通するパターン(フォーマットの構造、トーン、判断ロジック)を読み取り、そのパターンを新しい入力に適用する。例の数に絶対的な決まりはないが、実務上は通常2〜3組で明確な効果が見られる。重要なのは数の多さではなく、その例自体があなたが気にしている重要なバリエーションをカバーしているかどうかである。例えば、Claudeに作成してほしい内容が2つのよくある状況(機能追加とバグ修正という2種類のコミットなど)にまたがる場合、両方それぞれ少なくとも1組ずつ含めた方がよく、片方の状況の例だけを与えるべきではない。そうしないと、Claudeがもう一方の状況に遭遇したときに、類推するための十分な参考が得られない可能性がある。

例を選ぶ際は、量よりも質が重要である。5つの平凡な例を詰め込むよりも、「良い」と「まだ十分でない」の違いを明確に示せる2〜3個の例を厳選する方がよい。タスク自体に明確な出力フォーマットのルール(固定された項目の順序など)がある場合、例と組み合わせて明示的なフォーマットテンプレートを追加することで、Claudeが「ルールそのもの」と「ルールが実際に適用された姿」の両方を把握でき、この2つを組み合わせる方が、どちらか一方だけを与えるよりも通常はより安定する。

04 · どうすればいい?

Few-Shotプロンプティングは私にとって実際どんな意味があり、いつ例を使うべきで、いつ文章による説明で十分ですか?

判断基準は「この出力要件は明確な文章で言い尽くせるかどうか」という問いに立ち返るとよい。求めているものが明確な論理ルール(「担当者欄があるかどうかをチェックする」といった二択的な判断など)であれば、文章による説明で通常十分正確であり、追加の例は必要ない。しかし求めているものが「スタイル」「トーン」「きめ細かなフォーマットの加減」といった、数語では言い尽くせないものであれば、例の方が形容詞を積み重ねるよりも通常はClaudeに要点を早くつかませることができる。

実務上役立つ習慣は、ある要件を説明するために形容詞を何文もかけて書いたのに、それでも「これでは十分正確に伝わっていない」と感じたとき、それが例に切り替えることを検討すべきサインだということである。また、Few-Shotプロンプティングは毎回ゼロから例を考える必要はない。もしすでに過去にうまくできた実際の成果物(以前書いたよい報告書、よいコミットメッセージなど)が手元にあれば、その実際の成果物をそのまま例として使う方が、自分で新たに架空の例を作るよりも、本当に求めている基準に近いことが多い。

具体例 +

Anthropic公式のSkill作成ベストプラクティス文書は、コミットメッセージ生成Skillの書き方を示している。「入力されるコード変更の説明」と「出力されるコミットメッセージのフォーマット」の具体的な組み合わせを3組直接提供し、例の最後に「このスタイルに従うこと:type(scope): 簡潔な説明、続けて詳細な説明」という一文を付け加えることで、Claudeが例そのものとルールの文章による説明の両方を把握できるようにしている。

よくある誤解 +
✕ 誤解 1
× 誤解:与える例が多ければ多いほど、Claudeは求めるスタイルをよく把握できる、実際は:例の質と、それがカバーするバリエーションの種類の方が量よりも重要であり、異なる状況をカバーする厳選された2〜3個の例の方が、似たり寄ったりの5個の例よりも通常は効果的である
✕ 誤解 2
× 誤解:例があれば、ルールの文章による説明は不要になり省略できる、実際は:例は「ルールが実際に適用された姿」を示し、文章による説明は「ルールそのものが何であるか」を伝えるものであり、両方を組み合わせる方が、特にフォーマットに明確な要件があるタスクでは、どちらか一方だけを与えるよりも通常は安定する
The Missing Link +
直接的な影響

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.

質問する
10文字以上入力してください
関連トピック
Claude SkillsとProjectsの実際の違い:実際に使ってみて分かった使い分け基準
Claude Me
Projectsが管理するのは「この会話の背景は何か」、Skillsが管理するのは「これはどうやるべきか」——これを明確にしないと無駄な遠回りをすることになる。
#prompt-engineering#system-prompt
Claudeが一度で理解できる指示の書き方:プロンプトの良し悪しを決める2つの軸
Claude Cowork Me
使えないプロンプトは、たいてい書いた量が足りないのではなく、1つの軸が完全に見落とされているのだ。
#prompt-engineering#system-prompt
プロンプトのデバッグと反復:系統的な方法でプロンプト問題の根本原因を見つけ、各修正を意味のあるものにする
Claude Cowork Me
プロンプトが機能しないとき、「少し修正して再試行」は通常最も効率が低いアプローチです——問題がどこにあるかわからないから。系統的な診断(コンテキスト不足?指示が曖昧?フォーマット要件が不明確?期待が非現実的?)により、各修正が推測ではなく根拠のある仮説検証になります。
#prompt-engineering#system-prompt
初めてのAI生成ランディングページ:一文から使える画面までの実践ステップ
Claude Design Me
AIに何枚のカードを置くか決めさせるより、自分で先に決める方がいい——レイアウトの具体性は最も見落とされがちだが最も効果的なプロンプトのレバーだ。
#prompt-engineering