「自社データでLLMを賢くしたい」という要件
企業がLLMを導入するとき、よく出てくる要望がある。「うちの業界用語を理解させたい」「自社の製品情報を正確に答えさせたい」「特定のトーンや文体で統一させたい」——こういった要件だ。
LLMのカスタマイズには主に3つのアプローチがある。プロンプトエンジニアリング、RAG（Retrieval-Augmented Generation）、そしてファインチューニングだ。それぞれ特性が異なり、「どれを使えば正解か」という問いに対して「状況による」という答えしかないのが実情だ。
とはいえ判断基準を整理することはできる。本記事では2026年時点での各手法の現状を踏まえ、具体的な判断基準を提示する。
3つのアプローチの基本整理
まず各手法が何をするのかを簡潔に整理する。
プロンプトエンジニアリングは、モデルの重みを変えず、入力するプロンプトを工夫することでモデルの振る舞いを変える。「あなたは医療専門家です。患者が理解できる言葉で説明してください」といった指示で、コンテキストやペルソナを与える。
RAGは、クエリに応じて外部のドキュメントを検索し、取得した情報をプロンプトに追加してからモデルに回答させる。モデル自体は変えずに「参照できる知識」を動的に注入する。
ファインチューニングは、既存のLLMに追加学習をさせてモデルの重みを更新する。特定の応答パターンやドメイン知識をモデル自体に「記憶」させる。
プロンプトエンジニアリング——まず試すべき手法
新しいユースケースに取り組む場合、最初はプロンプトエンジニアリングから始めるべきだ。コストはほぼゼロ、実装は即日できる、失敗してもやり直しが簡単。
System promptに業務のコンテキストを詳しく書く、Few-shotで具体的な入出力の例を見せる、Chain-of-Thoughtで段階的に考えさせる——これらの手法を組み合わせるだけで、驚くほどの品質改善が得られることが多い。
「プロンプトで解決できないか」を試す前にRAGやファインチューニングに飛びつくのは、コストと複雑さを無駄に増やすことになる。まずプロンプトを磨くことに時間を使う。
限界は明確だ。コンテキストウィンドウに収まらない量の情報を参照させたい場合、プロンプトで解決できない。そしてモデルが学習していないドメイン固有の情報（自社の製品仕様、社内データ）を正確に扱わせたい場合も限界がある。
RAG——最もコスパが良い選択
RAGは多くのユースケースで最善手になる。
「自社の過去の事例を元に回答させたい」「最新の情報を参照させたい」「大量のドキュメントを検索して答えさせたい」——このような要件はRAGの得意領域だ。
RAGの利点を整理する。
知識の更新がリアルタイムにできる。ファインチューニングは学習に時間とコストがかかるが、RAGはベクトルDBに新しいドキュメントを追加するだけで知識が更新される。製品情報が週次で更新される場合、RAGは圧倒的に管理しやすい。
根拠を示せる。モデルが参照したドキュメントをユーザーに提示できるため、「なぜそう答えたか」のトレーサビリティがある。ハルシネーションのリスクも、検索結果に基づいた回答という構造により低減できる。
コストが読みやすい。ベクトルDBと検索の費用は比較的予測しやすく、APIコールのコストと合わせて見積もりを立てやすい。
# シンプルなRAGパイプラインの例
from anthropic import Anthropic
client = Anthropic()
def rag_answer(query, retrieved_docs):
context = "\n\n".join(retrieved_docs)
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system="以下の情報を参考に質問に答えてください。参考情報にない内容は答えないでください。",
messages=[
{
"role": "user",
"content": f"参考情報:\n{context}\n\n質問: {query}"
}
]
)
return response.content[0].text
RAGが向かないケースもある。参照すべきドキュメントが存在しない「文体・トーンの統一」「特定の出力フォーマットへの誘導」「専門用語の定義を学習させる」といった要件はRAGでは解決できない。
ファインチューニング——2026年でも必要か
ファインチューニングの位置付けは2024〜2025年で大きく変わった。コンテキストウィンドウが100万トークンを超えるモデルが登場したことで、「大量の知識をモデルに記憶させる」という動機でのファインチューニングは意義が薄れた。多くの情報はコンテキストに入れてしまえばいいからだ。
それでもファインチューニングが有効なケースは残っている。
出力フォーマットの徹底が必要な場合。JSONの特定スキーマで必ず答えさせたい、特定のフィールドを絶対に欠かさないようにしたい——こういった「フォーマット遵守」の要件はファインチューニングが最も確実だ。プロンプトでも実現できるが、指示を無視するケースが散発的に起きる。
特定のドメイン言語への適応。医療・法律・製造業などの専門用語を大量に含む文書を扱わせる場合、専門用語での学習データでファインチューニングすると基礎精度が上がる。
推論コストの削減。小さなモデルをファインチューニングして、大きなモデルと同等の精度を特定タスクで実現する。スケールするプロダクトでは、推論コストを10分の1に下げられれば経済的なインパクトが大きい。
LoRAとQLoRAが変えたファインチューニングのコスト
かつてファインチューニングはGPUを大量に使う高コストな作業だった。7Bパラメータのモデルをフルファインチューニングするには、A100 GPU数枚を数日動かす必要があった。
LoRA（Low-Rank Adaptation）とQLoRA（量子化 + LoRA）の登場で状況は変わった。モデルの全パラメータを更新するのではなく、低ランク行列という小さな「差分」だけを学習する。QLoRAは量子化と組み合わせてVRAM消費をさらに削減する。
# QLoRAを使ったファインチューニングの概念コード（transformers + peft）
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
from peft import LoraConfig, get_peft_model
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_compute_dtype="float16"
)
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Meta-Llama-3-8B",
quantization_config=bnb_config
)
lora_config = LoraConfig(
r=16, # ランク。小さいほど学習パラメータが少ない
lora_alpha=32,
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# trainable params: 約3.5M || all params: 約8B || trainable%: 0.04%
2026年時点では、Google Colabの無料GPU（T4）でもLlama 3 8Bのファインチューニングが数時間で完了する。コストは劇的に下がった。
OpenAIやAnthropicもファインチューニングAPIを提供しており、自社でGPUを用意せずともファインチューニングができる。ただし学習データをOpenAI/Anthropicのサーバーに送ることになるため、プライバシー要件の確認が必要だ。
判断フロー
「自社データでLLMを賢くしたい」という要件を受けたときの判断フローを整理する。
まず「プロンプトエンジニアリングで解決できるか」を試す。Few-shotや詳細なsystem promptで求める出力に近づくなら、そこで止める。
プロンプトで解決できない場合、「参照させる情報が存在するか」を確認する。社内ドキュメント、製品情報、過去の事例——検索できる形で情報があるならRAGを選ぶ。
RAGでも解決しない場合、つまり「出力のスタイルや形式を根本的に変えたい」「大量の専門用語に適応させたい」「特定タスクのコストを下げたい」のいずれかが目的なら、ファインチューニングを検討する。
ファインチューニングを選ぶ場合も、まずは小さなデータセット（100〜1000件）で試して効果を測ってから本格的なデータ収集に進む。ファインチューニングはデータ品質が命で、ゴミデータを大量に使っても性能は上がらない。
まとめ
2026年時点での結論として、大多数のユースケースではRAGが最適解だ。知識の更新容易性、トレーサビリティ、コストの予測可能性という三点でバランスが良く、「自社データを参照して答えさせる」という最も一般的な要件を満たせる。
ファインチューニングはLoRAとQLoRAのおかげでコストは下がったが、「どうしてもファインチューニングが必要」という場面は意外と限られる。まずRAGを試し、それで足りない部分をファインチューニングで補う、という順序が現実的だ。プロンプトエンジニアリングは常に最初の一手として試す価値がある。
