ICL（In-context Learning）とは？Few-shot・Many-shot・ファインチューニングとの違いと使い分け
AI新規事業
AI新規事業のPoC・立ち上げ、何から始めるべきかご相談ください
要件定義からリリースまで、Mojiがワンチームで伴走します。
1992年生まれ鳥取県出身、高専にてソフトウェア開発を学ぶ⚙️ レシピアプリや通話アプリなどのMVP開発を担当し、合計1000万DLを突破。 その経験を経てMojiを創業、生成AIやその周辺システムの開発マネジメントを行っている。 趣味はキャンプと二郎、筋トレ（ベンチ100kg）。
ICL（In-context Learning、文脈内学習）とは、LLMに推論時のプロンプト内で指示や入出力例を与え、その文脈に合わせてタスクを実行させる方法です。重要な点は、代表的なICLの設定ではモデルのパラメータ（重み）を更新しないことです。GPT-3の研究では、タスクと少数の例をテキストで与え、勾配更新やファインチューニングを行わずにタスクへ適用する設定が示されています。Language Models are Few-Shot Learners
たとえば、問い合わせ文を「請求」「障害」「契約」のいずれかへ分類する業務で、望む分類例を数件示してから新しい問い合わせを渡すとします。このとき、例を通じてラベルの意味、回答形式、判断の境界をモデルへ伝える設計がICLです。
ICLは、頻繁に変わるルールを短期間で試したい場合や、少数の見本で出力形式・判断基準を寄せられるか確かめたい場合の候補です。一方、更新される社内規程を根拠付きで答えさせたい場合はRAG、毎回長い例を送らずに同じ種類の処理を繰り返したい場合はファインチューニングも比較対象になります。形式の厳守が主目的なら、例を増やす前に構造化出力とアプリケーション側の検証を組み合わせる方法も検討します。
ICL、Few-shot、Many-shotの効果は一律ではありません。モデル、入力データの品質、例と実データの近さ、評価指標、許容できない誤りによって結論は変わります。本記事の判定表・手順・テンプレートは、特記がない限りMojiによる実務上の提案です。
ICLとZero-shot・One-shot・Few-shot・Many-shotの関係
Zero-shot、One-shot、Few-shotは、推論時にプロンプトへ与える例示（demonstration）の数を表す呼び方です。GPT-3の論文では、例を与えない設定をZero-shot、1例を与える設定をOne-shot、少数の例を与える設定をFew-shotとして扱っています。Language Models are Few-Shot Learners
Many-shotは、拡張されたコンテキスト内に数百～数千件規模の例を入れる研究で使われる呼び方があります。本記事では、固定した件数の閾値を設けず、少数例を超えて多数の例をコンテキストへ入れる設計をMany-shotと呼びます。これは本記事での実務上の整理です。Many-Shot In-Context Learning
呼び方 | プロンプト内の例 | 向く初期用途 | 運用上の注意 |
|---|---|---|---|
Zero-shot | なし | 指示だけで成立する要約、一般的な文章作成、仮説検証 | 形式・判定基準が曖昧な場合は、出力を評価して不足条件を特定する |
One-shot | 1件 | 期待する形式を最小限で見せたい場合 | 1件だけでは、例外や判断境界を伝えきれない場合がある |
Few-shot | 少数 | 分類、抽出、変換、文体・フォーマットの統一 | 採用した例、並び順、ラベル定義を固定して評価ログへ残す |
Many-shot | 多数 | 少数例ではカバーしにくい例外・表記揺れを含むタスクの比較検証 | 件数は対象モデルのコンテキスト長と評価目的で決める。コンテキスト長、推論時間、コスト、重複・矛盾した例も確認する |
Few-shot ICLの例は、単に「正解を覚えさせる」ものとは限りません。デモンストレーションの役割を調べた研究では、正解ラベルをランダムに置き換えても一部の分類・多肢選択タスクで性能低下が小さい結果が報告されました。同研究は、例がラベル空間、入力テキストの分布、系列全体の形式を示すことが、性能に寄与しうると分析しています。Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?
この研究結果をそのまま個別業務の設計規則にはできません。本記事では、正例を無制限に追加するのではなく、ラベルの定義、迷いやすい境界、実際に届く入力の表記揺れ、必要な出力形式を評価セットで確認し、不足した情報だけを例や指示として補うことを提案します。
また、情報が不足したデモンストレーションを対象にしたGPT-3の研究では、どの特徴をラベル予測に用いるかという特徴バイアスが調べられています。同研究では、感情極性を句読点のような浅い語彙的特徴より優先する傾向や、自然言語の指示・意味的に関連するラベル語が、特定の特徴を選ぶ傾向に影響しうることが報告されています。これは、同研究のデータセットと設定に限定された結果です。実務では、モデルに判断してほしい条件を指示と評価データで明示し、意図しない特徴に依存していないかを確認します。Measuring Inductive Biases of In-Context Learning with Underspecified Demonstrations
ICLは「学習」なのか：ファインチューニングとの違い
日本語では「ICL学習」と呼ばれることがありますが、ファインチューニングのようにモデルを再学習する工程とは分けて捉える必要があります。ICLは、リクエストごとに渡す文脈を変えてモデルの振る舞いを誘導します。対してファインチューニングは、学習データセットを使ってモデルを調整する処理です。OpenAIのAPIリファレンスでも、学習用ファイルとハイパーパラメータを指定してファインチューニングジョブを作成する仕組みが案内されています。OpenAI API Reference: Fine-tuning
比較軸 | ICL | ファインチューニング |
|---|---|---|
モデルの重み | 通常は更新しない | 学習処理で調整する |
変更の反映 | プロンプトや例を差し替えれば、次の実行から反映できる | データ準備、学習、評価、モデル切替を伴う |
主な比較対象 | リクエストごとのコンテキスト量、推論時間、出力品質 | 学習データ整備、学習・評価、モデル更新後の運用 |
比較候補に入れる状況 | ルールや例外が頻繁に変わる、まず効果を試したい | 大量・反復利用で毎回の長い例を減らせるか検証したい |
確認すべき点 | 例の追加で品質が改善するか、入力が過度に長くならないか | 学習データの誤り・偏り、更新時の再評価負荷 |
選択は「ICLかファインチューニングか」の二択ではありません。本記事では、まずZero-shotまたはFew-shotで評価基準を固め、品質、入力長、応答時間、修正作業を測ることを提案します。その後にRAG・構造化出力・ファインチューニングを同じ評価セットで比較します。生成AIシステム全体の評価方法は、AIの評価とは？評価指標や評価方法、その費用についても参照してください。
Many-shotはFew-shotの上位互換ではない
Many-shotでは、少数例では含めにくい例外や表記揺れをコンテキストへ追加できます。ただし、例が増えるほど長いコンテキストを処理する必要があります。多数のデモンストレーションを扱う研究では、Transformerアーキテクチャにおけるメモリ・計算コストが大きなコンテキスト長のボトルネックになると説明されています。In-Context Learning with Many Demonstration Examples
また、テキストLLMを対象に数百～数千例のMany-shot ICLを検証した研究では、評価した生成・識別タスクで性能向上が報告される一方、推論コストは例数に対して線形に増加し、フロンティアLLMごとの改善度も異なると報告されています。これは同研究の実験条件における結果であり、すべてのモデルや業務タスクでの改善を保証するものではありません。Many-Shot In-Context Learning
つまり、「例を増やせば精度が上がる」とは一般化できません。特に次の状態なら、Many-shot化の前に例と評価条件を見直すことを提案します。
- 同じ判断を示す例が重複している
- 古い運用ルールと新しいルールが混在している
- ラベル定義が曖昧で、人間同士でも判断が割れる
- 成功例しかなく、誤答しやすい境界事例がない
- 実際の入力より整った理想的な文章だけを例にしている
同一タスクで見る：Zero-shotからFew-shotへの変化
以下は、問い合わせ分類を題材にした架空の例です。実際のラベル名、入力してよい情報、保存期間、確認フローは自社のルールに合わせてください。
Zero-shotのプロンプト（架空の例）
次の問い合わせを「請求」「障害」「契約」のいずれか1つに分類してください。
出力はラベル名だけにしてください。
問い合わせ: 昨日から管理画面にログインできません。この設定では、ラベルの定義や、複数の問題が混ざった場合の優先順位が不明確です。モデルが一般的な知識から回答することはありますが、実データの境界条件を再現できるかは別途評価する必要があります。
Few-shotのプロンプト（架空の例）
あなたは一次振り分け担当です。次の定義で分類してください。
- 請求: 請求額、領収書、支払い方法、返金に関する問い合わせ
- 障害: ログイン不能、表示不良、機能が動かない問い合わせ
- 契約: プラン変更、解約、契約条件に関する問い合わせ
入力: 今月の請求額の内訳を確認したいです。
出力: 請求
入力: 契約更新の条件を教えてください。
出力: 契約
入力: 昨日から管理画面にログインできません。
出力:Few-shotで追加しているのは、例の数だけではありません。ラベルの定義、入力と出力の区切り、出力形式を固定するための見本です。このため、精度の変化を確認するときは、「例を増やした結果」なのか、「定義や形式を明示した結果」なのかを分けて評価します。
ICL・RAG・ファインチューニング・構造化出力の使い分け
用途ごとに比較すべき方式は異なります。以下は設計上の目安であり、モデル、入力品質、評価指標、許容誤差によって結論は変わります。
最優先したいこと | まず比較する方式 | 比較する理由 | 確認すべき失敗 |
|---|---|---|---|
新しい分類ルールを短期間で試す | Few-shot ICL | 例と定義を差し替えて評価しやすい | 例外ケースで誤分類しないか |
更新される規程・マニュアルを根拠付きで回答する | RAG | 回答時に関連文書を検索してコンテキストへ渡せる | 古い文書の混入、検索漏れ、権限逸脱 |
JSONなど決まった形式でシステム連携する | 構造化出力＋スキーマ検証 | 生成結果を機械的に検証できる | 必須項目欠落、型不一致、検証後の再試行ループ |
大量・反復実行で毎回の長い例を削減したい | ファインチューニングを含む比較検証 | 推論時のプロンプト量と品質を比較できる | 学習データの偏り、更新・再評価の負荷 |
判断規則が明確で誤りを許容しにくい | ルールエンジン・通常のプログラム | 生成による推測を避け、処理条件を明示できる | 例外規則の保守性 |
RAGは、検索でアクセスする外部メモリと生成モデルを組み合わせる枠組みです。原論文では、事前学習済みの生成モデルと、明示的な非パラメトリックメモリへのアクセスを組み合わせるRAGが提案されています。更新される規程を扱う場合は、正しい版の文書を検索し、回答時に根拠として渡せる構成を比較対象に入れます。Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks RAGの対象業務、導入手順、評価の切り分けは、RAG（検索拡張生成）とは？向く業務・他方式との違い・導入から評価までの実践ガイドで解説しています。
ICL導入の実務手順：例を増やす前に評価を作る
- タスクを1つに絞る
「問い合わせ対応を改善する」ではなく、「一次振り分けで担当部署を返す」「商品名からカテゴリを返す」のように、入力と期待出力を固定します。 - 許容できない失敗を定義する
正答率だけでなく、誤った部署への振り分け、必須項目の欠落、不明な入力を断定することなどを失敗として定義します。 - 評価セットを分けて作る
プロンプト例に使うデータと、評価だけに使うデータを分けます。通常例、境界例、表記揺れ、情報不足、複数意図を含めます。 - Zero-shotを基準値にする
最初からMany-shotにせず、指示だけの結果を記録します。これにより、例示が改善へ寄与したかを比較できます。 - Few-shotで不足した判断だけを補う
誤答を見て、代表例、境界例、例外、出力形式のうち何が欠けたかを特定して追加します。同種の成功例を無制限に増やしません。 - コスト・遅延も同じ表で比較する
正答率だけでなく、入力トークン、応答時間、再試行率、人の修正時間を記録します。 - RAG・構造化出力・ファインチューニングと比較する
ICLの例が「知識の持ち込み」になっているならRAG、「書式の検証」が必要ならスキーマ検証、「大量の反復例」になっているならファインチューニングを比較対象にします。
ICL評価シートのテンプレート
次の項目は、PoCで再利用できるテンプレートです。数値の合格ラインは、誤答時の影響、現行業務の品質、レビュー可能な件数に応じて決めてください。
項目 | 記入内容 |
|---|---|
対象タスク | 入力、期待出力、利用者、後続処理 |
正解の定義 | 正答条件、許容する表現差、必須項目 |
失敗の分類 | 誤分類、根拠不足、形式不正、情報不足時の断定、禁止情報の出力 |
比較条件 | Zero-shot、Few-shot、Many-shot、RAGなど。モデル・温度・システム指示・評価日を固定 |
例示データ | 採用理由、対応する失敗類型、順序、更新日、機密区分 |
評価データ | 通常例、境界例、表記揺れ、情報不足、複合ケースの件数 |
測定値 | 品質指標、入力・出力トークン、応答時間、再試行率、人の修正時間 |
導入判断 | 採用、例の再設計、RAG比較、構造化出力追加、保留・中止のいずれか |
導入前チェックリスト
- ICLで解きたいタスクの入力と出力を1つに固定したか
- 例示データと評価データを分離したか
- 通常例だけでなく、例外・境界・情報不足の入力を評価に含めたか
- 例は「量」ではなく、ラベル定義・形式・判断境界を伝えているか
- Many-shot化の前に、重複例・古い例・矛盾する例を除いたか
- 最新情報を答えさせる問題を、例示だけで解こうとしていないか
- JSONなどの形式要件を、プロンプト例だけに依存していないか
- 品質だけでなく、トークン量、遅延、人の確認時間を測る設計にしたか
- 入力してよい情報、ログ、権限、確認者を業務ルールとして決めたか
まとめ
ICLは、代表的な設定ではモデルの重みを変えずに、プロンプト内の指示・例・制約によってLLMの出力を目的へ寄せる方法です。Few-shotは少数例を与えるICLの設定であり、Many-shotは多数例をコンテキストへ入れる設計です。Many-shotに標準的な件数閾値はなく、対象モデルのコンテキスト長と評価目的を踏まえて扱う必要があります。
Many-shotは、研究条件によっては性能改善が報告されていますが、例数の増加に伴う推論コストや、モデル・タスクによる差も報告されています。まずはZero-shotを基準にし、Few-shotで不足した判断だけを補ってください。そのうえで、変わる知識にはRAG、厳密なデータ形式には構造化出力と検証、大量・反復利用にはファインチューニングを比較します。LLMへ渡す情報全体を設計する観点は、コンテキストエンジニアリングとは｜プロンプトエンジニアリングとの違いと実務での設計対象もあわせて確認してください。