あるチームが「私たち固有のユースケースをAIがもっと上手に処理できるようにしてほしい」という要件を受け取ったとします。実現方法にはいくつかの選択肢があります。より良いプロンプトを書くことも、関連データをモデルに与えるRAGシステムを構築することも、ドメインの事例でモデルをファインチューニングすることもできます。
これらは互いに置き換えられるものではありません。解決する課題が異なります。選択を誤ると、より良いプロンプトで済んだのに3か月と予算を費やしてファインチューニングすることになります。あるいは、ファインチューニングの方が単純だったのに手の込んだRAG基盤を構築したり、モデルには根本的に必要なことができないのにプロンプトにこだわり続けたりします。
この記事では、それぞれが適切な手段となる場面、組み合わせるべき場面、各手法の現実的なコスト、本番環境でうまくいくことと失敗しがちなことを判断するためのフレームワークを解説します。
それぞれが実際に行うこと
明確に区別すると、次のようになります。
プロンプティングは、モデルに何を求めるかを変えます。 より良い指示、例、形式要件、コンテキストをモデルに与えます。モデル自体は変わらず、入力が変わります。
RAGは、モデルが見るデータを変えます。 クエリ時に関連情報を検索し、プロンプトに含めます。モデルは、そのデータで訓練されていなくても、最新かつ具体的で動的なデータを利用できます。
ファインチューニングは、モデルが知っていることや振る舞い方を変えます。 事例でモデルを訓練し、その重みを変更します。モデル自体が更新されます。
これらが解決する課題は異なります。
- 指示のギャップ： 正しく依頼すれば、モデルはタスクを実行できる。→ プロンプティング。
- 知識のギャップ： モデルが持っていない情報を必要とする。→ RAG。
- 能力のギャップ： 良いプロンプトとコンテキストを与えても、モデルがタスクを確実に実行できない。→ ファインチューニング。
どのギャップがあるのかを把握できれば、問題の半分は解決したも同然です。
ギャップを診断する
AIが必要なことをしてくれない場合は、次のように考えます。
賢い人なら、プロンプトだけを渡されてこのタスクを実行できるでしょうか？
できるなら、指示のギャップです。より良いプロンプトで修正できるはずです。
できないなら、関連する参考資料を渡せば実行できるでしょうか？
できるなら、知識のギャップです。RAGで修正できます。
できないなら、十分な練習とフィードバックを受ければ実行できるでしょうか？
できるなら、能力のギャップです。ファインチューニングで修正できる可能性があります。
それでもできないなら、そのタスクはLLMでは解決できないのかもしれません。課題自体を再検討してください。
「AIが動かない」という問題の多くは指示のギャップであり、より良いプロンプティングで解決できます。次に多いのが知識のギャップです。本当の能力のギャップは最も少ない一方で、対処が最も困難です。
プロンプティング：過小評価されている手段
プロンプティングは最も安く、最も速く、そして最も頻繁に正解となる手段です。それでもチームはこれを飛び越え、RAGやファインチューニングへ進みがちです。
プロンプティングだけでできることには、次のようなものがあります。
- トーン、形式、長さを変える。
- 推論パターン（思考の連鎖、自己批評）を適用する。
- 制約（Xを行い、Yは行わない）を組み込む。
- ポリシーとガードレールを組み込む。
- 特定のユースケースに適応させる（機能ごとに異なるプロンプトを使う）。
- few-shotの例によって一貫性を高める。
プロンプティングだけではできないことは、次のとおりです。
- モデルが知らない事実を把握させる。
- 小規模モデルを大規模モデルのように振る舞わせる。
- モデルの語り口やスタイルを根本から大きく変える。
- モデルの推論を高速化する。
妥当な原則は、RAGやファインチューニングに手を伸ばす前に、まずプロンプティングを試し、少なくとも1週間は反復改善することです。ほとんどの場合、プロンプティングで問題を解決できると分かります。
プロンプトエンジニアリングにかかる労力
1週間集中的にプロンプトを反復改善すると、劇的な向上が得られることがあります。典型的な推移は次のとおりです。
- 1日目：ベースライン。平凡な結果。
- 2～3日目：構造を変更。形式を改善し、指示を明確化。大幅に向上。
- 4～5日目：例とエッジケース。失敗モードを捉える。
- 6～7日目：トーン、制約、仕上げ。最後の10%を改善。
1週間後には、プロンプティングから得られるものの大半を引き出せています。それでも満足できないなら、おそらく知識か能力にギャップがあります。
良いプロンプトの姿
参考までに、優れたプロンプトには通常、次の要素があります。
- 明確な役割とタスク。
- 具体的な形式要件。
- 代表的な例を1～5件（必要な場合）。
- 明示的な制約（何を行い、何を行わないか）。
- エッジケースの処理。
- 出力スキーマ。
通常は5～10段落です。短すぎれば指定不足になり、長すぎればモデルの焦点がぼやけます。
RAG：知識を補う手段
RAGが適切なのは、次のような場合です。
- モデルが持っていない事実情報を必要とする。
- 情報が変化する（ライブデータ、最近の出来事、アカウント固有のデータ）。
- 情報が自社のドメインや組織に固有である。
- 引用や、根拠を証明できる回答が必要である。
RAGが適切でないのは、次のような場合です。
- 問題が知識ではなく指示にある。
- データが小さく、プロンプトに直接収まる。
- モデルに別のことを知ってほしいのではなく、別のやり方で何かをしてほしい。
現実的なコスト
RAGシステムの構築は、本格的なエンジニアリングです。
- 構築： 本格的なものなら4～12週間（取り込み、チャンク分割、埋め込み、検索、リランキング、評価）。
- 運用： 継続的に必要。インデックスを最新に保ち、品質を監視し、問題を修正する。
- インフラ： ベクトルDB、埋め込みAPI、リランキングのコスト。中規模システムなら通常、月額€200～2000。
- クエリあたりのコスト： プロンプティングだけの場合より高い（追加の埋め込み、検索、より大きなコンテキストのコスト）。通常、従来のAPI呼び出しの2～5倍。
適切な課題には、十分に投資する価値があります。しかし、プロンプティングと比べれば大きな投資です。
RAGの品質向上には時間がかかる
1週目に動作するRAGシステムの品質は、通常60～70%です。本番品質（85%以上）に達するには、チャンク分割の改善、リランキングの追加、失敗モードの修正、評価の構築に、さらに1～2か月かかります。
これを計画に織り込んでください。1週目の状態でリリースすれば、ユーザーの不満を招きます。
ファインチューニング：プロンプティングとRAGでは不十分なとき
ファインチューニングが適切なのは、次のような場合です。
- 明確な能力のギャップがある。良いプロンプトとコンテキストを与えても、モデルがタスクを確実に実行できない。
- 高品質な訓練事例を十分に用意できる。非常に狭い範囲のLoRAでも最低数百件、信頼できる一般的な振る舞いには通常1,000件以上。手法ごとの正確なしきい値は、ファインチューニングの記事を参照してください。
- 一貫した狭い範囲の振る舞い（特定のスタイル、出力形式、ドメイン）が必要である。
- 推論コストやレイテンシーが重要である（ファインチューニングした小規模モデルは、汎用の大規模モデルより安くできる）。
ファインチューニングが適切でないのは、次のような場合です。
- データが流動的である（ファインチューニング済みモデルはすぐに古くなる）。
- プロンプティングとRAGをまだ十分に試していない。
- 良い評価がない（ファインチューニングが役立ったか判断できない）。
- タスクが非常に新しい情報を必要とする（ファインチューニングはある時点のスナップショット）。
- 事実を教えようとしている（RAGの方が適しており、信頼性が高く、引用もできる）。
ファインチューニングの種類
フルファインチューニング： モデルのすべての重みを更新します。最も強力で、最も高価です。相当な計算資源が必要で、通常は基盤モデルを開発する研究所に限られます。
LoRA（Low-Rank Adaptation）： 重みの一部だけを訓練します。はるかに安価です。狭い範囲のタスクでは、フルファインチューニングに匹敵する結果を得られることがよくあります。
QLoRA： 量子化したLoRAです。さらに安価です。大規模になると品質は下がりますが、多くのタスクには十分です。
プロンプトチューニング／プレフィックスチューニング： さらに小規模で、ソフトプロンプトだけを訓練します。最も安価ですが、能力は限定的です。
指示チューニング： 指示に従うようモデルを訓練します。通常は基盤モデルの段階で行われ、エンドユーザーに役立つことはまれです。
RLHF／DPO／KTO： 選好データ（回答AとBの比較）に沿うようモデルを訓練します。行動の変更には強力ですが、適切に行うのは複雑です。
2026年には、ファインチューニングを行うチームの多くが、強力なベースモデル上でLoRAを使用しています。大半のユースケースにおいて、コストと能力のバランスが最も優れています。
現実的なコスト
ファインチューニングのコストは手法と規模によって異なりますが、中規模のオープンモデルを5K～10K件の事例でLoRAファインチューニングする場合の典型は次のとおりです。
- データ準備： 1～4週間。多くの場合、作業の大半を占める。事例の選定、クリーニング、整形。
- 訓練： データセットの規模とインフラに応じて数時間～数日。計算コストは€100～2000。
- 評価： 1～2週間。評価スイートを構築し、ファインチューニング済みモデルとベースモデルを比較。
- 反復： 本番投入できるものになるまで1～3サイクル。
- デプロイ： マネージドAPI（OpenAIのファインチューニング、Anthropic、Vertex）を使うなら単純。自社運用するなら作業が増える。
- 保守： データの更新時、ベースモデルの更新時、ユースケースの変化時に再訓練。
合計は、6～12週間の作業、€1K～€20Kの計算コスト（規模による）、そして継続的な保守です。
大きな投資です。投資に見合うことを確認してください。
ファインチューニングが真価を発揮する場面
ファインチューニングが明確に優位となる具体的なシナリオは、次のとおりです。
厳密な形式要件。 出力が特定のスキーマやスタイルに一貫して従う必要がある場合です。プロンプティングなら95%まで、ファインチューニングなら99%まで到達できます。
専門分野。 医療用語、法律文書の表現、社内DSLのコードなどです。ファインチューニングによって、その固有の「方言」をモデルに教えられます。
パーソナリティ／語り口。 何千回ものやり取りを通じて、一貫した語り口が必要な場合です。プロンプトでは揺らぐことがありますが、ファインチューニングならモデルに定着させられます。
レイテンシー／コストの最適化。 特定のタスクを処理できるようファインチューニングした7Bモデルは、汎用の70Bモデルより安く高速にできます。処理量が多ければ、その効果は大きくなります。
行動上の安全性。 特定の要求を拒否したり、特定の安全策を追加したりするようモデルをファインチューニングすると、プロンプトによるガードレールより堅牢にできる場合があります。
ファインチューニングが失敗する場面
ファインチューニングで期待外れになりやすい典型例は、次のとおりです。
データ不足。 100件の事例でファインチューニングしても、通常はあまり効果がありません。非常に狭い範囲のLoRAなら数百件で機能することもありますが、信頼できる一般的な振る舞いには1,000件以上の高品質な事例を見込んでください。
悪いデータ。 入力が悪ければ出力も悪くなります。一貫性のない低品質な事例からは、一貫性のない低品質なモデルが生まれます。
破滅的忘却。 狭いタスクで強くファインチューニングすると、一般能力が損なわれることがあります。対象タスクは得意になっても、それ以外は不得意になります。
古い知識。 ファインチューニング済みモデルは、ある時点のスナップショットです。新しい情報には再訓練が必要です。動的な分野では、これが恒常的なコストになります。
ベースモデルの進歩がファインチューニングを追い越す。 ベースモデルが十分に改善され、ファインチューニング済みモデルの方が優れているとは言えなくなります。その時点で、古いベースモデルのファインチューニング版を保守していることになります。
評価の問題。 確かな評価がなければ、ファインチューニングが改善、悪化、あるいは何の効果ももたらさなかったのか分かりません。「成功」したとされるファインチューニングの多くは、プラセボ効果にすぎません。
組み合わせのパターン
本番環境で最も優れたシステムは、3つすべてを組み合わせています。
組み合わせ1：プロンプトを活用したRAG（最も一般的）
知識を多く必要とするアプリケーションの標準です。
- 入念に設計したプロンプトで、指示、形式、制約を組み込む。
- RAGで、最新かつ具体的な情報を提供する。
- ファインチューニングは行わず、強力なベースモデルを利用する。
これは2026年に最も一般的な本番パターンです。大半のユースケースに対応できます。
組み合わせ2：ファインチューニング済みモデル + RAG
行動の特化と動的な知識の両方が必要な場合です。
- 語り口、形式、ドメインに合わせてファインチューニングする。
- 最新情報にはRAGを使う。
- プロンプトでオーケストレーションする。
例として、特定企業のカスタマーサポートの語り口に合わせてファインチューニングしたモデルと、最新のポリシーやドキュメントを対象とするRAGの組み合わせがあります。ファインチューニングが一貫した語り口を担い、RAGが変化する知識を担います。
組み合わせ3：特定タスク向けの専用ファインチューニング
システムの各部分に、異なるファインチューニング済みモデルを使います。
- ルーティング用の分類ファインチューニング。
- ダイジェスト用の要約ファインチューニング。
- 顧客対応用の生成ファインチューニング。
- それぞれを小さく、高速に、専門化する。
規模とコストの最適化が重要な場合に使われます。それぞれのファインチューニング済みモデルが狭い範囲の仕事をうまくこなし、オーケストレーション層が呼び出します。
組み合わせ4：ファインチューニング済みルーター + 汎用モデル
クエリを確実に分類できるようルーターをファインチューニングします。分類後、実際の作業は汎用モデルに振り分けます。
ファインチューニング済みルーターは小さく、高速で、狭い範囲に特化しています。高価な汎用処理は、最新に保たれた汎用モデルが担当します。
これにより、経済性（ファインチューニング対象が小さい）と能力（難しい作業には汎用モデルを使う）を両立できます。
意思決定フレームワーク
実用的な意思決定フローは次のとおりです。
質問1： 現在のモデルと良いプロンプトで、問題を解決できますか？
できるなら、プロンプトを書きます。1週間反復改善し、リリースします。
できないなら、質問2へ進みます。
質問2： モデルが持っていない知識が、この問題に関係していますか？
関係しているなら、RAGを構築します。数か月をかけ、本番品質まで高め、強力なプロンプトと組み合わせます。
関係していないなら、質問3へ進みます。
質問3： 一貫した形式、狭いドメイン、特定の振る舞いに関する問題ですか？
そうであり、かつ高品質な事例が少なくとも数百件（理想は1,000件以上）あるなら、ファインチューニングします。プロンプティングと、場合によってはRAGも組み合わせます。
事例がないなら、収集に投資するか、ファインチューニングへ進む前にプロンプティング／RAGをさらに改善してください。
質問4： どの手法が実際に役立つかを把握するための評価を行いましたか？
これは、すべての段階に当てはまる質問です。評価がなければ、推測しているにすぎません。
本番環境の例
実際にあり得る組み合わせをいくつか紹介します。
例1：AIカスタマーサポート
構成： SaaS企業のカスタマーサポートAIが、ティア1の問い合わせを処理します。
コンポーネント：
- トーン、形式、エスカレーションポリシーのための強力なプロンプト。
- 最新のドキュメント、ポリシー、チケット履歴を対象とするRAG。
- 企業固有の語り口とエスカレーションパターンに対する軽量なファインチューニング（過去のチケットから選定した1,500件の事例）。
結果： チケットの65%を自律的に処理します。ファインチューニングが一貫した語り口を担い、RAGが正確性を保ち、プロンプトがポリシーを扱います。
例2：法的文書のレビュー
構成： リーガルテック製品が、契約書のリスクをレビューします。
コンポーネント：
- 確認事項（法的カテゴリー、重大度の評価基準）を組み込んだ詳細なプロンプト。
- 関連する判例法と先例を対象とするRAG。
- ファインチューニングは行わず、推論モデルが難しい処理を担う。
結果： モデルにはすでに法務分野の訓練が施されているため、プロンプト + RAGだけでうまく機能します。ファインチューニングをしても改善はわずかと見込まれ、投資に見合いませんでした。
例3：カスタムDSLのコード補完
構成： 独自のDSLを持つ専門的なデータツールです。
コンポーネント：
- 例を含むプロンプト。
- RAGは使わない（DSLが小さく、コンテキストに収まる）。
- DSLの事例10K件を使ったLoRAファインチューニング。
結果： ファインチューニングが不可欠でした。ファインチューニングなしでは、モデルは有効なDSLを確実に生成できませんでした。プロンプトとコンテキストだけでは不十分でした。
例4：社内アシスタント
構成： 従業員向けの汎用アシスタントです。
コンポーネント：
- 強力なシステムプロンプト（語り口、振る舞い、拒否）。
- 社内wiki、Slack、ドキュメントを対象とするRAG。
- ファインチューニングは行わない。企業の「語り口」はプロンプトで表現する。
結果： RAG + プロンプトで大半のユースケースに対応できます。企業の語り口に、ファインチューニングが必要なほどの独自性はありません。
よく見られる誤り
リソース配分を誤る典型的なパターンを紹介します。
誤り1：最初からファインチューニングに手を出す。 チームが「自社モデルをファインチューニングすべきだ」と聞き、そこから始めます。90%の場合、プロンプティング + RAGの方が速く、安く、同等の成果を得られます。
誤り2：RAGが正解なのに使わない。 クエリ時に明らかに検索すべき企業情報をモデルに「思い出させる」ため、チームが複雑なプロンプトを構築します。単純に検索する方が適切です。
誤り3：評価なしでファインチューニングする。 「ファインチューニングして良くなった」と言いながら、指標がありません。実際には、何の効果もなかったり、悪化していたりすることがよくあります。評価がなければ分かりません。
誤り4：古くなったファインチューニング済みモデル。 GPT-4が最高だった6か月前のファインチューニング済みモデルより、ファインチューニングしていない現在のフロンティアモデルの方が優れています。分野の進歩に合わせ、ファインチューニングを再評価する必要があります。
誤り5：事実をファインチューニングで覚えさせようとする。 モデルが「自社について知る」ようファインチューニングしようとします。これはうまく機能しません。モデルはいくつかの事実を記憶し、ほかの事実についてハルシネーションを起こします。RAGは事実を扱い、ファインチューニングは振る舞いを扱います。
誤り6：プロンプトの反復改善を十分に続けない。 2日間のプロンプト改善は出発点にすぎません。2週間取り組めば、本当の答えが見えてきます。
誤り7：プロンプティングで済むのにRAGを過剰設計する。 50Kトークンの社内文書をプロンプトにそのまま投入する方が、RAGより単純な場合があります。特に小規模なコーパスではそうです。
コストと労力の比較
典型的な中規模プロジェクトにおける大まかな比較は、次のとおりです。
| 手法 | 労力 | コスト（1回限り） | コスト（クエリあたり） | 保守 |
|---|---|---|---|---|
| プロンプティング | 1～2週間 | 最小限 | 基本APIコスト | 低 |
| RAG | 6～12週間 | インフラ構築（約€1K～5K） | 基本の2～5倍 | 中（取り込み、評価） |
| ファインチューニング（LoRA） | 6～12週間 | 訓練用計算資源（約€500～5K） | 基本（小規模モデルなら安くなる場合が多い） | 高（データ、再訓練、評価） |
| プロンプティング + RAG | 8～14週間 | インフラ | 基本の2～5倍 | 中 |
| 3つすべて | 12～20週間 | 合算 | 条件による | 高 |
適切な選択は、課題とリソースによって決まります。大半のチームにとって、プロンプティング + RAGが最適なバランスです。ファインチューニングへの全面的な投資なしに、能力を有意に高められます。
要点
プロンプティング、RAG、ファインチューニングは、それぞれ異なる問題を解決します。正しく選ぶには、指示のギャップ、知識のギャップ、能力のギャップのどれなのかを率直に診断する必要があります。
試すべき順序は、率直に言えば次のとおりです。
- プロンプティング（1～2週間反復改善）。最も安く、最も速く、最も多くの場合に十分です。
- 明確な知識のギャップがあるなら RAG。大きな投資ですが、範囲は明確です。
- プロンプティング + RAGでは埋められない明確な能力のギャップがあるなら ファインチューニング。最も高価なので、最後に行います。
- 成熟した本番システムでは 組み合わせ を使います。
成功するチームは、自分たちにどのギャップがあるのかを率直に捉え、規律を持って評価を行います。評価がなければ、どの手法が役立ったのか分かりません。評価があれば、進むべき道は通常明確になります。
「自社モデルをファインチューニングする必要がある」というプロジェクトの多くは、よく調べると「より良いプロンプトを書き、RAGを追加する必要がある」プロジェクトです。本当に必要な場合のために、ファインチューニングは取っておいてください。
その結果、より良いシステムを、より速く、より低いコストで実現できます。本番AIをリリースする目的は、まさにそこにあります。
