LLMを自社の業務に合わせる方法は、大きく2つに分かれます。プロンプトの中に指示や例、資料を入れて振る舞いを変える方法と、モデルそのものを追加で学習させるファインチューニングです。後者では、元の重みを固定したまま小さな追加部分だけを学習するLoRA(Low-Rank Adaptation)が定番になっています。
しかし現場では、「追加学習させたら、もともとできていたことができなくなった」「LoRAで学習させたのに、業務の手順どおりに動かない」「プロンプトの工夫で済むのか、学習させるべきなのか判断できない」といった悩みが尽きません。
この記事では、各社の公式ドキュメントをもとに4つの方法(プロンプト設計・少数例・RAG・ファインチューニング)の違いとコストの考え方を整理し、「どんなときに、どの方法を選ぶか」の判断材料になる論文4本を紹介します。結論を先に言うと、評価の仕組みを先に作り、プロンプトから始め、学習は「プロンプトで直らない誤り」があるときに、元の能力が落ちていないかを確かめながら入れるのが基本です!
4つの方法は「どこを変えるか」が違う
プロンプト設計と少数例:モデルはそのまま、渡す内容を変える
プロンプト設計は、指示文で目的や出力の形式、守るべき条件を伝える方法です。少数例(few-shot)は、そこに「この入力にはこう答える」という例をいくつか添える方法です。Anthropic は、例は出力の形式や口調、構成をそろえる最も確実な方法の1つで、実際の用途に近く、変化に富んだ例を3〜5個入れると良いと説明しています(Anthropic「Prompting best practices」)。
RAG:最新の情報や社内の資料を、そのつど渡す
RAG(検索拡張生成)は、質問に関係する社内文書などを検索してプロンプトに入れ、それをもとに答えさせる方法です。OpenAI は、モデルの学習データにない情報、たとえば社内のデータベースの内容や最新の情報は、プロンプトの文脈として渡すよう勧めています(OpenAI「Model optimization」)。RAGの設計と落とし穴はRAGの記事で詳しく扱っています。
ファインチューニングとLoRA:モデルの重みを変える
ファインチューニングは、入力と望ましい出力の組を学習させて、モデル自体を変える方法です。Google Cloud の解説では、全パラメータを更新するフルファインチューニングは高品質を狙える一方で学習と運用の計算資源が大きく、一部だけを更新するパラメータ効率の良い学習は少ない計算資源とデータで済む、と整理しています(Google Cloud「Introduction to tuning」)。LoRAはその代表です。原論文は、GPT-3 175Bをフルファインチューニングする場合と比べて、学習するパラメータを1万分の1、GPUメモリを3分の1にでき、推論時の遅延も増えないと報告しています(Hu ほか「LoRA」)。
| 方法 | 変えるもの | 向いていること | 主なコスト |
|---|---|---|---|
| プロンプト設計 | 指示文 | 試作、形式や条件の指示 | 指示文の入力トークン(毎回) |
| 少数例 | 指示文+例 | 出力の形式や判断の基準をそろえる | 例の入力トークン(毎回) |
| RAG | 渡す資料 | 社内文書や最新情報に基づく回答 | 検索の仕組みの構築と運用 |
| ファインチューニング | モデルの重み | 分類・抽出・決まった形式など | データ作り、学習費、評価、作り直し |
選び方とコストの考え方
「測ってから、プロンプトで始める」が共通点
3社の説明には共通点があります。Anthropic は、プロンプトを工夫する前に、成功の基準とそれを実際に測る方法を用意するよう求めています(Anthropic「Prompt engineering overview」)。OpenAI は、まず評価(eval)を作って基準を測り、プロンプトを工夫し、用途によってはファインチューニングし、評価して直すことを繰り返す流れを示しています。Google は、まずプロンプトで最適な形を探し、性能をさらに上げたいときや同じ誤りが繰り返されるときに学習へ進むこと、データを足す前にどこで間違えているかを評価することを勧めています。目安は、ラベル付きのデータが100件以上あることです(OpenAI「Model optimization」、Google Cloud「Introduction to tuning」)。学習が向く作業として、両社とも分類などの定型的な作業を挙げています。
「毎回払う」か「先に払って、持ち続ける」か
コストの性質も違います。プロンプトと少数例は学習費がかからない代わりに、長い指示や例の分の入力トークンを呼び出しのたびに払います(トークン課金の仕組みは推論コストの記事を参照)。学習すれば例や長い指示を外せるので、推論の費用と遅延を下げられる、というのが OpenAI と Google の説明です。一方、学習費は Google の場合「学習データのトークン数×エポック数」で決まります(Google Cloud「Agent Platform Pricing」)。
見落としやすいのが、作ったモデルを持ち続けるコストです。OpenAI では、学習済みモデルは土台のモデルが廃止されるまでしか使えません。さらに2026年10月時点で、利用者が自分で学習を実行するファインチューニングの仕組みは段階的に終了しつつあります。2026年5月7日から学習の実績がない組織は新しい学習を始められず、7月2日からは直近60日間に学習済みモデルを使っていない組織も対象になりました。残る利用者も2027年1月6日以降は新しい学習を始められないと告知されています(OpenAI「Deprecations」)。学習データと評価の仕組みを手元に残し、別のモデルで作り直せるようにしておくことが大切です。
研究で見る「プロンプトか、学習か」
📄 論文: 少ないデータでの3方式の比較
A Comparative Analysis of LLM Adaptation: SFT, LoRA, and ICL in Data-Scarce Scenarios(Bernd Bohnet ほか、2025年10月投稿・11月改訂、arXiv:2511.00130)は、査読前の論文(プレプリント)です。
対象はGoogleの公開モデル Gemma 3 の4B版1つで、品詞の付与や計画問題などの「技能」系の課題と、質問応答などの「知識」系の課題を、主に数件〜数百件の少ないデータで、フルファインチューニング・LoRA・プロンプト内の例示の3方式で比べました。フル学習は技能を素早く身につける一方で、無関係な質問に答える力が数ステップで失われ、ある実験では一般知識の質問の正答率が0まで落ちました。LoRAは一般知識を保ちながら技能を学べましたが、品詞付与の実験では標準設定のままだと16件では足りず、64件以上で大きく改善しました。また、データや学習を増やすとLoRAでも一般知識の正答率は下がりました。例示は重みを変えないので忘れることはありませんが、計画問題では学習した2方式に大きく及びませんでした。
運営者にとっての意味は、「LoRAなら忘れない」とは言い切れないことです。著者らも、すでにある能力を例で引き出せる作業ならプロンプト内の例示が最も効率的で安全だ、とまとめています。
📄 論文: 偽情報や有害投稿の判定では、学習した小さなモデルが強い
Are LLMs Enough for Hyperpartisan, Fake, Polarized and Harmful Content Detection? Evaluating In-Context Learning vs. Fine-Tuning(Michele Joshua Maggini ほか、2025年9月、arXiv:2509.07768)は、査読前の論文(プレプリント)です。
英語・スペイン語・ポルトガル語・アラビア語・ブルガリア語の公開データセット10種で、偏向報道・偽ニュース・有害投稿・政治的立場の判定を題材にしました。Llama 3.1 8B など公開モデル3つに、定義を詳しく書く、判定基準の手引き(コードブック)を渡す、例を添える、段階的に考えさせる、といったプロンプトを試し、LoRAで学習させたモデルや、学習させた小型の分類モデル(RoBERTa など)とF1スコアで比べています。結果は、学習させたほうが良かった場面がLLMで33件中28件にのぼり、10データセット中6つでは、学習させた小さな分類モデルがLLMの学習より良い成績でした。プロンプトの中ではコードブックが比較的有効で、段階的に考えさせる方法は分類ではあまり効きませんでした。
運営者にとっての意味は、ラベル付きのデータがそろう分類作業なら、大きなモデルへのプロンプトより、小さなモデルの学習のほうが有力な選択肢になりうることです。ただし著者らは、再現性と予算の理由から商用のクローズドなモデルを対象から外し、GPUの制約でより大きなモデルも試せなかったと述べています。
研究で見る「LoRAとフル学習の向き不向き」
📄 論文: 分岐のある業務手順は、通常のLoRAでは身につきにくい
Procedural Knowledge Is Not Low-Rank: Why LoRA Fails to Internalize Multi-Step Procedures(Simon Dennis ほか、2026年5月、arXiv:2607.21612)は、査読前の論文(プレプリント)です。
旅行予約・ビデオ会議のサポート・保険請求という3つの業務手順(14〜55の段階と分岐)について、別のLLMで作った合成の会話データでQwen系の3Bと8Bのモデルを学習させ、LLMが演じる利用者と200回ずつ会話させました。採点もLLMが5段階で行っています。3Bで試した旅行予約では、ランク16〜128のすべてのLoRAで手順の成功度が2.54以下にとどまり、フル学習の4.11に遠く及びませんでした。会話はほぼすべて何らかの終わり方に達していましたが、正しい分岐を通って正しく終えたわけではなく、「会話は最後まで続くのに手順は守れていない」状態です。ランクは32を超えるとかえって下がり、8Bの2つの手順でも差は埋まりませんでした。別のLLMで採点し直しても傾向は同じでしたが、差は小さくなりました。
運営者にとっての意味は、「会話が完了したか」ではなく「手順どおりに正しく終えたか」で評価する必要があることです。なお著者らは、対象は顧客対応型の手順とQwen系のモデルに限られ、層ごとにランクを変えるLoRAは未検証だと述べています。
📄 論文: 小さなモデルでは、フル学習が逆効果になることがある
The Fine-Tuning Trap: Evaluating Negative Transfer and the Role of PEFT in Sub-1B Mathematical Reasoning(Rahul Nair ほか、2026年6月、arXiv:2606.06920)は、査読前の論文(プレプリント)です。
1億3500万〜5億パラメータの小型モデル3つと、比較用の10億・20億パラメータのモデル2つを、数学の文章題1万件で学習させ、H100のGPUで、4種類の数学の試験問題の完全一致の正答率で比べました。3億6000万パラメータのモデルでは、学習に使った種類の問題でも、フル学習後の正答率が学習しないときを下回りました(11.5%→9.2%)。LoRAでは逆に上がっています。指示に従うよう調整済みの5億パラメータのモデルでも、4種類すべてでLoRAがフル学習を上回りました。一方、10億パラメータ以上ではフル学習がおおむね最も良い結果です。著者らは、調整済みの10億未満のモデルではLoRAなどを既定にし、5億未満ではフル学習を避けるよう勧めています。
運営者にとっての意味は、端末で動かすような小型モデルほど、まずLoRAのような部分的な学習から試し、学習した課題以外の力が落ちていないかを確かめるべきだということです。ただし数学の課題だけの小規模な実験で、試行ごとのばらつきも示されていないので、自社の用途で確かめる前提で受け止めてください。
現場でやること
評価用の質問を先に用意する
実際の問い合わせや業務データから、正解付きの質問を数十件用意します。学習の効果を見る質問に加え、学習と関係のない一般的な質問も入れておくと、「覚えた代わりに忘れた」を見つけられます。評価の作り方はLLM評価の記事も参考になります。
「プロンプトで直らない誤り」を洗い出す
指示の書き方を改め、例を3〜5個添えて試します。社内規程や最新情報が足りずに間違えるならRAGを足します。それでも同じ種類の誤りが残り、ラベル付きのデータが100件以上そろうときに、初めて学習を検討します。データが足りない場合は学習データの合成の記事も参考にしてください。
学習するなら、比べ方と残し方を決めておく
- 学習前のモデル+プロンプトと、学習後のモデルを同じ質問で比べる
- 手順を守らせたい用途では、会話の完了率ではなく「正しい分岐で終えたか」を数える
- 学習データ・設定・評価結果を残し、土台モデルが変わったら作り直せるようにする
ファインチューニングとプロンプトを使い分ける鍵は次の3点です
- 評価の仕組みを先に作り、プロンプトから始める
各社とも、成功の基準と測り方を用意し、プロンプトから始めるよう勧めています。例と資料で済むなら、それが最も手軽で安全です。 - 学習は「プロンプトで直らない誤り」があるときに、LoRAから試す
分類のような定型作業では、学習した小さなモデルが有力です。ただしLoRAでも忘れることはあるので、一般的な質問で確かめます。 - 多段階の業務手順は、学習だけに頼らず結果で確かめる
手順の成功は会話の完了とは別物です。通常のLoRAで身につかない場合があることを前提に、正しく終えたかで評価します。
まとめ:「学習させるか否か」から「何をどの方法で身につけさせるか」へ!
プロンプト設計・少数例・RAG・ファインチューニングは、変えるものも、コストの払い方も違います。最新情報や社内資料はRAGで渡し、形式や判断の基準はまず例で示し、それでも直らない定型作業を学習で補う、という順に考えると迷いにくくなります。学習したモデルは、土台モデルの廃止とともに作り直す必要がある点も忘れずに。
まずは、自社の業務で「プロンプトでは何がどう間違うのか」を数十件の質問で測るところから始めてみてください。学習が要るかどうかは、その結果が教えてくれます!
参考文献
- Anthropic「Prompt engineering overview」(https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview)2026-10-01 確認
- Anthropic「Prompting best practices」(https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)2026-10-01 確認
- OpenAI「Model optimization」(https://developers.openai.com/api/docs/guides/model-optimization)2026-10-01 確認
- OpenAI「Deprecations」(https://developers.openai.com/api/docs/deprecations)2026-10-01 確認
- Google Cloud「Introduction to tuning」(https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/tuning)2026-10-01 確認
- Google Cloud「Agent Platform Pricing」(https://cloud.google.com/gemini-enterprise-agent-platform/generative-ai/pricing)2026-10-01 確認
- Edward J. Hu ほか「LoRA: Low-Rank Adaptation of Large Language Models」arXiv:2106.09685(https://arxiv.org/abs/2106.09685)2026-10-01 確認
- Bernd Bohnet ほか「A Comparative Analysis of LLM Adaptation: SFT, LoRA, and ICL in Data-Scarce Scenarios」arXiv:2511.00130(https://arxiv.org/abs/2511.00130)2026-10-01 確認
- Michele Joshua Maggini ほか「Are LLMs Enough for Hyperpartisan, Fake, Polarized and Harmful Content Detection? Evaluating In-Context Learning vs. Fine-Tuning」arXiv:2509.07768(https://arxiv.org/abs/2509.07768)2026-10-01 確認
- Simon Dennis ほか「Procedural Knowledge Is Not Low-Rank: Why LoRA Fails to Internalize Multi-Step Procedures」arXiv:2607.21612(https://arxiv.org/abs/2607.21612)2026-10-01 確認
- Rahul Nair ほか「The Fine-Tuning Trap: Evaluating Negative Transfer and the Role of PEFT in Sub-1B Mathematical Reasoning」arXiv:2606.06920(https://arxiv.org/abs/2606.06920)2026-10-01 確認
2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、LoRAと例示の得意・不得意、小型モデルの対象範囲と例示との比較、LoRAとDoRAの比較、LoRAの限界の適用範囲の記述の誤りを修正しました

