In-Context Learningとは

In-Context Learning（ICL、文脈内学習）は、大規模言語モデルがモデルの重みを更新しないまま、入力として与えられた指示・例・途中情報を使って、その場のタスクに合わせた振る舞いを示すことです。たとえば「英語→日本語」の例を数組見せ、その直後に新しい英語文を与えると、モデルは例の対応関係や出力形式を手掛かりに翻訳らしい応答を返せます。

ここで最も重要なのは「学習」という言葉の読み方です。通常の機械学習でいう学習は、訓練データを使ってパラメータを更新する工程を指します。一方、ICLでは一般に推論時にモデルの重みは変わりません。モデルは与えられたコンテキストを条件として次の出力を計算しているだけです。この違いを押さえると、論文や製品説明で「few-shotで学習した」「例から学習した」という表現を読んだとき、追加訓練が行われたのか、その場の入力だけで適応したのかを区別できます。

どこで目にする言葉か

ICLは、LLMのベンチマークで「zero-shot」「one-shot」「few-shot」を比較するときによく現れます。GPT-3の論文では、タスクごとの重み更新を行わず、入力中の自然言語指示やデモ例だけを使う設定が大きく取り上げられました。現在では、APIで数件の入出力例をプロンプトに置く、会話履歴を使って回答形式を合わせる、長い文脈中のルールを読み取って処理する、といった場面もICLの観点から議論されます。

ただし、単に「長い入力を読める」こととICLは同じではありません。長いコンテキストウィンドウは、モデルが一度に参照できる情報量の上限に関する性質です。ICLは、その文脈に含まれる例や規則からタスク上の振る舞いを変える能力を指します。長い窓があっても例をうまく利用できるとは限らず、逆に短い文脈でも有効なICLが成立することがあります。

Few-Shot Promptingとの違い

Few-Shot Promptingは、少数の見本をプロンプトに入れる方法です。ICLは、その見本を手掛かりにモデルが推論時に適応する現象・能力です。両者は強く関連しますが、同義ではありません。

たとえば、次のような入力を考えます。

• 入力: 「赤」→ 出力: color
• 入力: 「犬」→ 出力: animal
• 入力: 「青」→ 出力: ?

モデルが color と答えたなら、提示された例から分類規則や出力形式を推測したとみなせます。ここではfew-shotの例がICLを誘発しています。しかしモデルは、必ずしも人間のように明示的な規則を内部で作っているとは限りません。近年の研究では、ICLの仕組みを「事前学習で獲得したパターンの選択」と見る立場や、文脈から新しい対応関係を組み立てる側面に注目する立場があり、メカニズムは単純な一枚岩ではありません。

Fine-tuningとの境界

Fine-tuningでは、訓練データを使ってモデルのパラメータを更新します。その結果は、通常は同じモデルを後で使うときにも残ります。ICLは原則として、現在の入力コンテキストがなくなれば、その場で与えた例も条件としては消えます。

この差は製品を読むときに実務上とても重要です。「自社データでモデルを学習させる」という説明が、Fine-tuningを意味するのか、RAGで情報を与えるのか、プロンプト中に例を置くICLなのかで、コスト、更新方法、プライバシー、再現性が大きく変わります。「学習」という日常語だけで判断せず、パラメータ更新があるかを確認するのが近道です。

例を増やせば必ず良くなるわけではない

ICLでは、例の数だけでなく、例の質、順序、ラベル表現、入力との類似性、指示との整合性が影響します。長い文脈に大量の例を詰め込んでも、ノイズや矛盾が増えれば性能が落ちることがあります。モデルやタスクによっては、zero-shotでも十分だったり、少数の良い例のほうが多量の雑な例より安定したりします。

また「コンテキストに情報が存在する」ことと「モデルがその情報を正しく利用できる」ことも別です。長い文書の途中に重要な規則が埋もれている場合、位置や構成の影響を受けることがあります。したがって「128kトークン対応だからICLも強い」といった単純な推論は避けるべきです。

会話中に覚えたことは恒久的な学習か

通常、ICLとして使われる会話履歴は、その会話の入力文脈として参照されているだけです。モデルの基礎パラメータが会話のたびに更新されているわけではありません。製品によっては別途「メモリ」「プロフィール」「保存された設定」などの仕組みがありますが、それはICLとは別レイヤーです。

そのため「さっき教えたからモデル自体が賢くなった」「この会話で覚えた事実が他ユーザーにも反映される」と考えるのは不正確です。元の画面や仕様書で、会話履歴、保存メモリ、Fine-tuning、ナレッジベースのどれが使われているのかを切り分けてください。

元の文脈へ戻ったときの読み方

研究論文なら、まず評価条件のshot数を確認します。zero-shotは例なし、one-shotは通常1例、few-shotは複数例という使い分けが一般的ですが、具体的な例数やプロンプトは論文ごとに異なります。「few-shotで高性能」という結果を、Fine-tuning済みモデルとの公平な比較とみなせるかは、使用したモデル、データ汚染、例選択、評価指標まで見る必要があります。

製品や開発記事なら、ICLに使う情報がどこから来るかを確認します。手作業のデモ例なのか、検索で取得した例なのか、会話履歴なのか、システム指示なのかで挙動は変わります。また、例に機密情報を入れる場合は、その入力がどのように処理・保存されるかという別のセキュリティ論点もあります。

次に起こりやすい誤解

ICLを理解すると、次に「ではコンテキストを増やせばFine-tuningは不要なのでは」と考えがちです。しかし両者は置き換え関係ではありません。ICLはすばやく条件を与えられる一方、毎回コンテキストへ情報を入れる必要があり、入力長やコストの制約を受けます。Fine-tuningは特定の振る舞いや分布へモデルを継続的に適応させられますが、学習データや訓練工程が必要です。RAGは外部情報を検索してコンテキストへ供給する仕組みで、これもまた別です。

つまり、ICLという語だけから「モデルが恒久的に知識を獲得した」「モデル内部が更新された」「例が多いほど高性能」「長い文脈なら正確」と推論してはいけません。

確認チェックリスト

元のニュース、論文、製品説明へ戻ったら、①重み更新があるか、②何件の例をどの形式で入れているか、③例は固定か動的取得か、④評価はzero-shot/one-shot/few-shotのどれか、⑤コンテキスト長と実際の利用性能を混同していないか、⑥会話履歴・製品メモリ・Fine-tuning・RAGのどれを指しているか、を確認してください。

ICLのポイントは、「モデルを再訓練しなくても、今ここに与えられた文脈によって振る舞いが変わる」ということです。その便利さと、恒久的な学習ではないという境界を同時に理解すると、LLMの説明をかなり正確に読めるようになります。

ICLの性能を左右する「例の設計」

Few-shotの例は、単なる追加情報ではなく、モデルにタスクの境界を伝える信号になります。入力形式、出力ラベル、例外処理、望ましい文章量などを例の中に示せます。逆に、例同士が矛盾していたり、ラベル名が曖昧だったりすると、モデルはどの規則を採用するか不安定になります。

また、例の順序にも注意が必要です。最後に置いた例へ強く引っ張られる、特定ラベルが多いとそのラベルを出しやすくなる、といった位置・頻度の影響が報告されています。したがって評価では、1組のfew-shot promptだけを使った結果を「モデル固有の能力」と断定せず、例セットや順序を変えたときの頑健性を見ることが望まれます。

ICLと「新しい知識を教える」こと

コンテキスト内に未知の固有語と定義を置き、その後の質問で使わせることはできます。たとえば「Zorpとは青い三角形を表す」というローカル規則を与えれば、その会話内ではZorpを使った分類に対応できる場合があります。これもICLの一例として理解できます。

しかし、これはモデルの長期知識ベースが更新されたことを意味しません。コンテキストがなくなれば、その定義を再提示しない限り利用できないのが基本です。製品側が別のMemory機能を持つ場合は、保存された情報が後続会話のコンテキストへ再投入されることがありますが、それは「重みが学習した」とは別です。

研究結果を読むときの注意

ICL研究では、モデルが事前学習中に評価データや非常に近いパターンを見ていた可能性が問題になります。few-shotで新しいタスクを理解したように見えても、事前学習で類似形式を十分経験していた可能性があります。このため「未知の課題をその場で学習した」という強い主張には、データ汚染やタスク新規性の検討が必要です。

一方で、ICLを単に「暗記したパターンの再生」とだけ説明するのも十分ではありません。研究では、文脈中の新しい対応規則へ適応する挙動も観察されており、どこまでが既存スキルの呼び出しで、どこからが文脈内での新しい関係の獲得かは継続的な研究対象です。

実務での使いどころ

ICLは、モデルを再訓練せずに出力形式や判断基準をすばやく変えたいときに便利です。たとえば、問い合わせ分類で「この会社では返品理由をA/B/Cの3分類にする」という例を数件与える、文章校正で望ましいbefore/after例を示す、といった使い方があります。

ただし例を毎回プロンプトへ入れるため、入力トークンとコストが増えます。例が多いほどコンテキストを消費し、ユーザー入力やRAG文書に使える領域が減ります。運用では「何をプロンプトに置くか」「何をFine-tuningへ移すか」「何を外部検索で補うか」を分けて設計します。

まとめ：ICLを読むための三つの軸

ICLの説明を読むときは、「入力に何が置かれたか」「モデル重みは更新されたか」「その適応はどこまで持続するか」の三つに分けると整理できます。入力中の例だけで振る舞いが変わり、重み更新がなく、コンテキストを離れると保持されないなら、典型的なICLです。

逆に、訓練ジョブが走って新しいモデルが作られるならFine-tuning、外部ストアから毎回情報を取り出すならRAG、製品がユーザー情報を保存して後の会話へ再投入するならMemoryです。実際の製品はこれらを組み合わせるため、「AIが学習した」という一文だけで方式を決めず、データフローを見ることが大切です。

ICLはLLMの大きな利点ですが、例に依存するがゆえの不安定さもあります。再現性が必要な業務では、代表的な入力セットで評価し、例順序やラベル偏りを変えても性能が維持されるかを確認すると、単発デモの印象に頼らずに済みます。

要点

ICLは「その場の文脈で適応する」能力です。重み更新、長期記憶、外部検索を自動的に意味しません。元資料では、何を文脈に入れ、何を更新せず、どの条件で評価したかを確認してください。

関連するAI用語

• Few-Shot Prompting
• Zero-Shot Prompting
• RAG
• AI Memory
• ファインチューニング

注・出典

1. Brown et al. 2020, Language Models are Few-Shot Learners：https://arxiv.org/abs/2005.14165
2. Dong et al. 2022/2024, A Survey on In-context Learning：https://arxiv.org/abs/2301.00234
3. Mao et al. 2024, A Survey to Recent Progress Towards Understanding In-Context Learning：https://arxiv.org/abs/2402.02212

AI協働制作について

本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。 AI協働制作方針