1.0UX TIMEShttps://uxdaystokyo.com/articles高橋 祐哉https://uxdaystokyo.com/articles/author/yuya-takahashi/rich600338<blockquote class="wp-embedded-content" data-secret="1G3rIfwlHX"><a href="https://uxdaystokyo.com/articles/glossary/few-shot-prompting/">Few-shotプロンプティング</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://uxdaystokyo.com/articles/glossary/few-shot-prompting/embed/#?secret=1G3rIfwlHX" width="600" height="338" title="“Few-shotプロンプティング” — UX TIMES" data-secret="1G3rIfwlHX" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script> /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll('iframe[data-secret="'+t.secret+'"]'),o=l.querySelectorAll('blockquote[data-secret="'+t.secret+'"]'),c=new RegExp("^https?:$","i"),i=0;i<o.length;i++)o[i].style.display="none";for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute("style"),"height"===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):"link"===t.message&&(r=new URL(s.getAttribute("src")),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener("message",d.wp.receiveEmbedMessage,!1),l.addEventListener("DOMContentLoaded",function(){for(var e,t,s=l.querySelectorAll("iframe.wp-embedded-content"),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute("data-secret"))||(t=Math.random().toString(36).substring(2,12),e.src+="#?secret="+t,e.setAttribute("data-secret",t)),e.contentWindow.postMessage({message:"ready",secret:t},"*")},!1)))}(window,document); //# sourceURL=https://uxdaystokyo.com/articles/wp-includes/js/wp-embed.min.js </script> https://uxdaystokyo.com/articles/wp-content/uploads/2026/08/few-shot-p-3.png10241024Few-shotプロンプティング（Few-shot Prompting）とは、解いてほしいタスクの手本をいくつか示すことで、モデルを追加学習させずに望む形の答えを引き出す指示の出し方である。手本をまったく与えずに指示だけで解かせる「ゼロショット」、手本を1つだけ与える「ワンショット」と並ぶ、手本の数で分かれるプロンプト技法の一つにあたる。 たとえば、商品のレビューが好意的か否定的かをAIに判定させたいとき、「最高だった → 肯定」「二度と買わない → 否定」といった手本を2〜3組先に示してから、判定させたい文章を最後に置く。すると、モデルは手本から「言葉→判定」という型を読み取り、同じ形式で新しい文章にラベルを付ける。ルールを言葉で細かく説明しなくても、見せた手本がそのまま指示の代わりになる。 手本のパターンをその場でまねる Few-shotプロンプティングの核心は、プロンプトに置かれた手本の「入力と出力の対応」を、モデルがその場で読み取ってまねる点にある。 これは文脈内学習（In-Context Learning）と呼ばれる。モデルの中身（パラメータ）を書き換えず、与えられた文脈だけを手がかりに振る舞いを変える仕組みである。言葉だけでは説明しづらいタスクほど、この方式が活きる。「丁寧な文体に直して」と指示するより、崩れた文とその整えた後を2〜3組見せるほうが、望む文体は正確に伝わる。手本が、ルールを言語化する手間を肩代わりする。 語源・提唱者 「言語モデルは少数の手本で学べる」という考え方を広く知らしめたのは、2020年にOpenAIのTomトム Brownブラウンらが発表した論文『Language Models are Few-Shot Learners』である。この論文は、1750億個のパラメータを持つ大規模言語モデルGPT-3を示し、タスクごとに追加学習をしなくても、プロンプトに手本を数個入れるだけで多くの課題を解けることを実証した。 それ以前は、新しいタスクにモデルを対応させるには、そのタスク専用のデータでモデルを鍛え直す「ファインチューニング」が当たり前だった。同論文は、手本の数に応じてゼロショット・ワンショット・Few-shotを区別し、モデルが大きくなるほど手本から学ぶ力が伸び、Few-shotとゼロショットの差が広がることを示した。なお「Few-shot learning（少数事例学習）」という言葉自体は、少ない教師データで画像を分類する研究など、GPT-3以前の機械学習でも使われていた。プロンプトに手本を並べる今の使い方は、大規模言語モデルの登場で一般化した。 ルールを書かずに精度を底上げする 文体やトーン、分類の境目のように、ルールとして明文化するのが難しい要求も、崩れた文とその整えた後を手本として見せれば型として伝わる。出力の形式をそろえたいときも同じで、見出しの付け方や決まったデータ形式を手本で示すと、モデルの出力がその形に近づき、後続の処理で扱いやすくなる。手本が2〜3個あるだけでも、指示だけのときより解釈のぶれが減り、答えが安定する。 ただし手本はプロンプトの文字数（トークン）を消費する。長い入力を扱う場面では、手本を増やしすぎると処理の負担と釣り合わなくなるため、必要な数にとどめる。 手本の選び方と並べ方で結果が変わる Few-shotプロンプティングの効果は、手本の作り方に大きく左右される。 まず、すべての手本で「入力→出力」の書き方をそろえる。区切り記号やラベルの表記がばらつくと、モデルが型を読み違える。分類させるなら、特定のラベルばかりに偏った手本を並べない。手本の順番によっても結果が変わることが知られているので、答えがかたよったら並べ替えて確かめる。 注意したいのは、手本が語尾や長さといった表面的な特徴だけを示していると、モデルがその見た目をまねてタスクの本質を外すことがある点である。手本は「何を判断してほしいか」が伝わる代表例を選ぶ。 指摘の通り、単なる汎用ラベルの例示（バグ報告・機能要望など）では前半の解説と内容が重複してしまいます。社内のSlackやTeamsの履歴、提出された過去ドキュメントを活用し、「手本（ルール）の作成自体をAIに任せる」実務的な活用法へと差し替える改訂案を作成しました。 社内ツールや提出文書からAIに手本を作らせる 問い合わせ文の仕分けを行う際、Few-shotに必要な「手本」を人間がゼロから作成・言語化する必要はない。社内ツール（SlackやTeams）のやり取りや提出された過去ドキュメントをAIに提示し、手本となるルール自体をAIに抽出・作成させることができる。 実データからの手本抽出: 過去の対応ログや資料をAIに提示し、「この内容から『問い合わせ文 ➔ 対応ラベル』の型となる手本ペアを3つ作成して」と指示 文脈・表記揺れの自動吸収: 社内用語や独自の分類基準が含まれていても、AIが提出文書の文脈を読み取り、適切な表記で手本を整理できる ルールのメンテナンス性: 分類基準が変わった際も、人間がルールブックを書き直すのではなく、最新の提出文書を読み込ませて「手本」を再生成させるだけで運用の更新が完了 ルール化の手間（言語化の摩擦）をAI自身に肩代わりさせることで、現場の実データに即した分類プロンプトを素早く構築できる。 関連用語 https://uxdaystokyo.com/articles/glossary/pronpt/ https://uxdaystokyo.com/articles/glossary/chain-of-thought/ https://uxdaystokyo.com/articles/glossary/zero-shot-chain-of-thought/