AI開発会社2社から提案を受け取ったら、片方は RAG、もう片方はファインチューニングを提案していた。提案書にはそれぞれ「最新情報に強い」「専門用語を理解した高精度な出力」と書かれていて、どちらも正しそうに見える。しかし2週間後の役員会では「なぜこの手法を選んだのか」を自分の口で説明しなければならない——このような状況で検索している方は少なくないはずです。
困っているのは、おそらく「RAG とファインチューニングの違いを知らないこと」ではありません。違いを説明した記事はいくらでも見つかります。本当に詰まっているのは、その違いを自社の業務条件に翻訳する作業です。「最新情報に強い」と書かれていても、自社の技術規程が年に1回しか改定されないなら、その強みは意思決定に効きません。比較表を読めば読むほど、どの行が自社にとって重要なのかが分からなくなっていきます。
この翻訳作業が難しいのは無理もありません。総務省の令和7年版 情報通信白書でも、生成AIの活用における課題・懸念事項として日本企業の回答が最も多かった項目は「効果的な活用方法がわからない」だったと報告されています（図表Ⅰ-1-2-15）。手法の知識ではなく、自社業務への当てはめ方が全国的なボトルネックになっているということです。
そこで本記事では、RAGとファインチューニングの使い分けを「どちらが優れているか」ではなく「自社の条件ではどちらか」という問いに置き換えて整理します。発注判断に効く5つの比較軸、提案書と社内の実情だけで即答できる5つの問い、12ヶ月の総額で見る費用比較、そして稟議資料に書ける選定理由の文面までを順に解説します。
読み終えたときに手元に残るのは、次の3つです。1つめは RAG・ファインチューニング・併用のどれを選ぶかという自社の判定結果、2つめはベンダーに追加で確認すべき質問リスト、3つめは「なぜこの手法か」を3〜4行で説明する稟議用の文面です。技術の内部構造を理解する必要はありません。自社の業務条件を5つ答えられれば、判断は自力で出せます。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
RAGとファインチューニングの使い分けは「どちらが優れているか」では決まらない
RAGとファインチューニングの使い分けを考えるとき、最初に捨てたほうがよい前提があります。それは「どちらかが技術的に優れている」という前提です。両者は同じ問題を別の方法で解いているのではなく、そもそも解いている問題が違います。
RAGは「モデルに正しい情報を渡す」ための技術です。ファインチューニングは「モデルの振る舞いを変える」ための技術です。前者は情報の鮮度と正確さに効き、後者は出力の形式と語彙の統一に効きます。つまり比較すべきなのは手法の優劣ではなく、自社が困っているのが「情報」なのか「振る舞い」なのかという点です。
ベンダーの提案が手法レベルで食い違う3つの理由
同じ要件を伝えたのに提案が分かれた場合、その差は必ずしも技術的な判断の差ではありません。主な理由は次の3つです。
1つめは、各社の実装資産の差です。 RAGの構築実績が多い会社は、チャンク分割の設計、検索精度のチューニング、ベクトルデータベースの運用ノウハウを既に持っています。ファインチューニングの実績が多い会社は、学習データの整備フローと評価の仕組みを持っています。どちらも「自社が短期間で確実に納品できる構成」を提案するのは合理的な行動です。
2つめは、ヒアリング時に何を強調して伝えたかの差です。 「社内マニュアルを検索したい」と伝えた会社はRAGを、「専門用語が多くて汎用AIでは的外れな回答になる」と伝えた会社はファインチューニングを提案します。同じ業務を説明しても、どの症状を強く訴えたかで提案は変わります。
3つめは、要件の粒度が足りていない場合に各社が置いた仮定の差です。 「更新頻度」「出力形式」「想定利用者数」が RFP に明記されていないと、各社は自社の得意な前提を仮に置いて提案を組み立てます。提案が食い違っているのは、多くの場合この仮定が食い違っているということです。
したがって最初にやるべきは、提案書を見比べることではなく、各社が置いた仮定を自社の実情で上書きすることです。そのための出発点となる条件を次に整理します。
判断の出発点になる4つの自社条件
RAGとファインチューニングの使い分けは、次の4条件でほぼ方向が決まります。いずれもベンダーに聞く必要はなく、社内を確認すれば答えが出るものです。
条件 | 確認すること | 確認先 |
|---|---|---|
知識の更新頻度 | 参照させたい文書（規程・マニュアル・仕様書）が年に何回改定されるか | 文書管理部門・品質保証部門の改定履歴 |
求める出力の型 | 欲しいのは「調べた答え」か、「決まった書式の文章」か | 要望を出した現場部門 |
想定利用規模 | 1日あたり何人が何回使う想定か（部門限定か全社か） | 現場部門・情報システム部の利用者数見込み |
社内データの整備状況 | 文書が電子化・検索可能な形式になっているか、過去の対応履歴が残っているか | 共有フォルダ・文書管理システム・問い合わせ管理台帳 |
この4条件を埋めたうえで、次の章で手法の違いを5軸に分解して比較します。技術の仕組みそのものは、判断に必要な範囲だけ扱います。
RAGとファインチューニングの違いを5つの軸で整理する
RAGとファインチューニングの違いを説明する比較表は数多く存在しますが、行数が多いほど判断は難しくなります。ここでは発注判断に直接効く5軸に絞って整理します。
RAGとは：知識を外に置き、回答時に検索して参照する
RAG（Retrieval-Augmented Generation／検索拡張生成）は、社内文書を外部のデータベースに置いておき、質問が来たタイミングで関連する箇所を検索し、その内容をモデルに渡して回答を作らせる仕組みです。モデル自体には手を加えません。図書館の司書が、質問を受けてから該当する資料を棚から探してきて、その資料を見ながら答えるイメージに近いです。
この方式の出発点はLewis らが2020年に発表した論文で、知識を必要とするタスクにおいて、外部から取得した情報を根拠として回答を生成する手法として提案されました。回答が取得済みの文書に紐づくため、どの文書のどの箇所を根拠にしたかを示せる点が構造上の特徴です。
社内文書を追加・改定したい場合は、データベース側を更新すれば次の質問からその内容が反映されます。モデルを作り直す必要はありません。
ファインチューニングとは：知識と振る舞いをモデル内部に覚えさせる
ファインチューニングは、既に学習済みのモデルに対して自社のデータで追加学習を行い、モデルの内部パラメータ（重み）を更新する手法です。「こういう入力にはこう答える」という例を大量に与えることで、出力の書式・語調・語彙の使い方をモデル自身の癖として定着させます。
先ほどの図書館の例で言えば、司書に社内用語の使い方と報告書の書き方を研修で覚えさせるようなものです。覚えた内容は資料を参照しなくても出てきますが、内容が変わったら再研修（再学習）が必要になります。
ファインチューニングの仕組みそのものや、外注する場合の費用内訳についてはファインチューニングとはで詳しく整理しています。本記事は手法の選定判断に絞るため、以降は選定に効く性質のみを扱います。
発注判断に効く5軸の比較表
提案書を読み比べる際は、次の5軸で対応させると差が明確になります。
軸 | RAG | ファインチューニング |
|---|---|---|
知識の持ち方 | モデルの外（データベース）に置く。文書はそのままの形で残る | モデルの内部に取り込む。元の文書とは切り離される |
更新への強さ | データベースを更新すれば即日反映。日次・週次の改定に耐える | 更新には再学習が必要。反映までに準備期間と費用が発生する |
コスト構造 | 検索基盤の維持費と、参照文書をプロンプトに載せる分のトークン費用が継続的に発生 | 学習時に費用が集中。以降は推論の単価が主な変動費 |
出力の制御範囲 | 参照する情報は制御できるが、文章の書式・語調の統一は苦手 | 書式・語調・専門用語の使い方を安定させやすい |
出典提示とデータ管理 | 根拠となった文書名・箇所を回答に添えられる。文書単位のアクセス制御も設計しやすい | 出典の提示は原理的に困難。学習データはモデルに溶け込むため、後から特定データだけ取り除くことが難しい |
この表を提案書に当てはめると、冒頭で悩んでいた「最新情報に強い」「専門用語を理解した高精度な出力」という2つの抽象表現が、それぞれ「更新への強さ」と「出力の制御範囲」の話をしていたことが分かります。つまり2社は別の軸で自社の強みを述べていたのであり、対立していたわけではありません。
稟議資料に書くときは、この抽象表現を具体的な業務表現に置き換えてください。「最新情報に強い」は「技術規程の改定を当日反映できる」、「高精度な出力」は「報告書の書式と社内用語を統一できる」と書けば、役員にも判断材料として伝わります。
比較表で「引き分け」になったときに見る優先順位
5軸のうち複数で判断が分かれた場合は、次の優先順位で見てください。上から順に、後から取り返すのが難しい項目です。
- 出典提示とデータ管理 — 業務上「根拠を示せない回答は使えない」場合、ファインチューニング単独では要件を満たせません。ここは後から追加できない性質です
- 更新への強さ — 更新頻度が高い知識をファインチューニングで扱うと、運用が回り始めた後で行き詰まります
- 出力の制御範囲 — 書式の統一は、プロンプトの工夫やテンプレートで一定範囲まで代替できます。優先度は相対的に下がります
- コスト構造 — 利用量の実測値が出るまで精度の高い比較はできません。判断は後回しにできます
- 知識の持ち方 — 上記4つの結果として決まる項目です
引き分けになるケースの多くは、実は1番目か2番目で決着します。このあと、この5軸を「答えられる問い」の形に変換します。
使い分けを決める5つの問い（判断フロー）
ここが本記事の中核です。RAGとファインチューニングのどっちを選ぶかは、次の5つの問いに答えれば判定できます。いずれも提案書と社内の実情だけで答えられる問いに絞ってあります。技術的な見積もりや将来予測は必要ありません。
各問いには「なぜこの問いが効くのか」を添えています。この根拠ごと稟議で使えるようにするためです。
問い1 参照する知識は月単位で変わるか
YESなら、RAGがほぼ必須になります。
社内規程、製品仕様、価格表、業務マニュアルなど、参照させたい情報が月に1回以上改定されるかを確認してください。判断材料は文書管理システムの改定履歴です。感覚ではなく、直近2年の改定回数を数えてください。
この問いが効く理由は、更新コストの構造がまったく違うためです。RAGなら改定版の文書を登録し直せば済みますが、ファインチューニングでは改定内容を学習データに反映し、再学習を実施し、出力を再検証するという工程が毎回発生します。改定が年1回なら許容できても、月1回なら運用が破綻します。
なお「改定されるのは一部の文書だけ」というケースもよくあります。この場合は、更新頻度の高い文書群だけをRAGで扱う切り分けが可能です。
問い2 求めているのは「正しい情報」か「決まった型の出力」か
「正しい情報」ならRAG、「決まった型の出力」ならファインチューニングが有効です。
現場部門の要望を読み返してください。「規程のどこに書いてあるか知りたい」「この部品の仕様を確認したい」は情報の要求です。一方で「日報を定型のフォーマットに整えたい」「顧客への回答文を社内の言い回しに揃えたい」は出力の型の要求です。
この問いが効く理由は、両者で失敗の形が違うためです。情報の要求に対する失敗は「間違った内容を答える」ことであり、これは根拠となる文書を渡せば防げます。型の要求に対する失敗は「毎回違う書式で出てくる」ことであり、これは文書を渡しても解決しません。出力の癖を変える必要があります。
要望書に両方が混在している場合は、この時点では両方YESとして次に進んでください。後述する併用の検討対象になります。
問い3 回答の根拠（出典）を利用者に示す必要があるか
YESなら、RAGを選択肢から外せません。
利用者がAIの回答をそのまま使うのか、原典を確認してから使うのかを確認してください。品質記録、安全基準、契約条件など、誤りが業務リスクにつながる領域では、ほぼ確実に出典提示が必要になります。
この問いが効く理由は、出典提示の可否が後から変更できない構造的な性質だからです。RAGは検索してきた文書を根拠に回答を生成するため、どの文書を参照したかを回答に添えられます。ファインチューニングでは学習データがモデルの重みに溶け込むため、「この回答の根拠はどの文書か」を特定する仕組みを原理的に持ちません。
この問いを軽く扱ってしまうと、運用開始後に現場から「出典が分からないから確認作業が増えただけ」という声が上がり、利用率が伸びない結果になりがちです。稟議前に現場部門へ確認しておくことをおすすめします。
問い4 学習に使える対話・文書のペアデータが何件そろうか
数百件を下回るなら、ファインチューニングは時期尚早です。
ファインチューニングには「この入力にはこう答える」という入出力のペアデータが必要です。過去の問い合わせ対応履歴、承認済みの報告書、作成済みの回答テンプレートなどが該当します。共有フォルダや問い合わせ管理台帳を確認し、そのまま学習に使える形で何件あるかを数えてください。
この問いが効く理由は、必要件数の目安が主要プロバイダの公式ドキュメントで示されているためです。MicrosoftのAzure OpenAI ファインチューニングのガイドでは、学習に必要な最小件数を10件としつつ「この最小件数ではモデルの応答に大きな影響を与えない」と明記し、まず丁寧に作った50件から始め、目標は数百件規模とすることを推奨しています。OpenAIのファインチューニングのガイドも、最小10件・改善が見え始めるのは50〜100件程度という同水準の目安を示しています。つまり数百件という水準は、提供元をまたいでおおむね共通する目安だと考えてよいことになります。
ここで重要なのは、既存文書の量ではなく入出力ペアとしての質だという点です。マニュアルが1万ページあっても、それは学習データではなくRAGの検索対象です。「質問と模範回答の組」が何件あるかを数えてください。前述のMicrosoftのガイドも「低品質の例はパフォーマンスに悪影響を及ぼす可能性がある」「まず最も質の高い例を選別しないまま大量の内部データでモデルを学習させると、性能が予想以上に低下する可能性がある」と注意しています。この数が足りない場合、ファインチューニングは費用を投じても効果が出ない可能性が高く、まずRAGで運用しながらペアデータを蓄積するほうが合理的です。
あわせて、2026年時点では「どの経路でファインチューニングを実施するのか」も確認が必要な項目になっています。 OpenAIは廃止予定の一覧で、2026年5月7日付でセルフサーブのファインチューニングプラットフォームを段階的に終了すると告知しています。同日以降はファインチューニングの実績がない組織は新規の学習ジョブを作成できず、2026年7月2日以降は直近60日間にファインチューニング済みモデルで推論を行っていない組織も対象外となり、2027年1月6日をもって既存の利用組織も新規の学習ジョブを作成できなくなる予定です（既存のファインチューニング済みモデルについては、基盤モデルが廃止されるまで推論での利用は継続できるとされています）。実際、上で引用したガイドと後述する料金ページにも「OpenAI is winding down the fine-tuning platform」という注記が掲載されています。
ファインチューニングという手法そのものが使えなくなるわけではなく、Microsoft Foundry（Azure OpenAI）のようなクラウド事業者経由の提供や、オープンウェイトモデルを自社・ベンダー環境で学習させる構成など、実施経路は複数残っています。ただし提案書に「OpenAIのAPIでファインチューニングします」と書かれている場合は、どの経路で実施するのか、その経路が契約期間中も提供され続けるのかを必ず確認してください。手法の選定以前に、実施経路が前提として成立しているかを確かめる作業です。
問い5 想定利用規模はどれくらいか
利用が大量かつ定型的に反復されるなら、ファインチューニングの費用面の検討価値が上がります。
1日あたりの想定利用回数を確認してください。部門限定で1日数十回なのか、全社展開で1日数千回なのかで判断が変わります。
この問いが効く理由は、両手法でリクエスト1回あたりのコスト構造が違うためです。RAGでは検索してきた文書をプロンプトに載せるため、1回の問い合わせで消費するトークン数が多くなります。ファインチューニングでは必要な振る舞いがモデル側に入っているため、プロンプトを短く保てます。利用回数が増えるほど、この差は積み上がります。
ただし、ここは誤解が生じやすい箇所なので注意してください。「規模が大きければファインチューニングのほうが安い」と単純には言えません。ファインチューニング済みモデルの推論単価は、基盤モデルとは別に、より高い水準で設定されるのが一般的です。参考値として、OpenAIの料金ページでは gpt-4o-mini のファインチューニング済みモデルが入力100万トークンあたり0.30ドル・出力1.20ドルで、基盤モデル（入力0.15ドル・出力0.60ドル）のちょうど2倍に設定されています（このページにも前述の段階的終了の注記が併記されているため、単価は「傾向を示す参考値」として読んでください）。
さらに見落としやすいのが、推論単価以外にかかる費用です。前述のMicrosoftのガイドでは、デプロイしたファインチューニング済みモデルについて「APIの呼び出しがあるかどうかに関係なく、1時間ごとのホスティング費用が発生する」と明記されています。利用回数が少ないうちは、この固定費が1回あたりコストを大きく押し上げます。
つまり「プロンプトが短くなる分の削減」と「単価が上がる分＋固定費の増加」のどちらが大きいかは、1回あたりのトークン数と利用回数で変わります。
したがってこの問いの答えは「大量ならファインチューニング」ではなく、「大量なら、トークン単位で損益分岐点を計算する価値がある」です。計算の考え方は、後述する費用の整理方法のなかで具体化します。
回答の読み方：どの組み合わせなら併用を検討するか
5つの問いへの回答を、次の表で判定してください。
回答パターン | 判定 |
|---|---|
問い1がYES、または問い3がYES | RAGを選ぶ。問い2・4・5の結果にかかわらず、まずRAGが土台になります |
問い1がNO、問い3がNO、問い2が「型」、問い4が数百件以上 | ファインチューニングを選ぶ。知識が固定的で、求めているのが出力の型である典型ケースです |
問い1または問い3がYES、かつ問い2が「両方」、かつ問い4が数百件以上 | 併用を検討する。ただし後述する順序で段階的に進めてください |
問い4が数百件未満 | RAGから始める。ファインチューニングは学習データが貯まるまで保留します |
どの問いも決め手にならない | RAGから始める。手戻りコストが小さい側から着手するのが合理的です（後ほど詳述します） |
判定結果が出たら、次の章で自社の業務名に紐づけて確認してください。
ユースケース別：RAGが向く業務とファインチューニングが向く業務
判定結果を業務単位の具体例に接続します。稟議では「当社の◯◯業務はこの類型に当たる」と説明できると伝わりやすくなります。
RAGが向く業務
RAGのユースケースは、その場で正しい情報を探し出す業務に集まります。
業務 | 扱う情報の性質 | 求める出力 |
|---|---|---|
社内規程・技術マニュアルの検索 | 改定が入る。原典の参照が必要 | 該当箇所の要約＋出典 |
問い合わせの一次対応（社内ヘルプデスク） | 問い合わせ記録・過去対応履歴が随時追加される | 回答候補＋根拠となった記事 |
製品仕様・部品情報の照会 | 型番ごとに大量。誤りが業務リスクに直結 | 該当仕様の提示＋出典 |
議事録・報告書からのナレッジ共有 | 日々増える。蓄積されるほど価値が出る | 関連情報の要約＋元資料へのリンク |
見積・過去案件の類似検索 | 案件ごとに追加される | 類似案件の提示＋参照元 |
共通しているのは、情報が増減し、かつ利用者が原典にたどり着きたいという点です。冒頭で挙げた「社内マニュアル・技術規程をAIで検索できるようにしてほしい」という現場要望は、この類型に該当します。
RAGを選んだ場合の構築・外注の進め方についてはRAG開発・構築ガイドで、内製と外注の判断基準や費用の見方を整理しています。
ファインチューニングが向く業務
ファインチューニングが向くのは、出力の型を揃えることが価値になる業務です。
業務 | 扱う情報の性質 | 求める出力 |
|---|---|---|
定型文書の生成（報告書・検査記録・顧客向け回答文） | 書式が固定。内容の元データは別途与えられる | 決まった構成・語調の文章 |
分類・タグ付け（問い合わせの振り分け、不具合の類型判定） | 分類体系が安定している | 決まったラベル |
業界特有の言い回しへの統一 | 用語の対応関係が固定 | 社内標準の表現に揃えた文章 |
抽出処理（帳票・仕様書から所定項目を取り出す） | 対象書式が安定している | 決まった項目セット |
共通しているのは、正解の形が事前に決まっており、過去の成果物が入出力ペアとして蓄積されているという点です。逆に言えば、過去の成果物が残っていない業務ではファインチューニングの土台がありません。
判断に迷う中間ケースの見分け方
実務でよく出てくるのは、次のような中間ケースです。
ケース1：専門用語が多いが、参照する規程は毎月改定される。 用語の統一はファインチューニング寄り、更新頻度はRAG寄りです。この場合は「用語の問題が本当にモデル側の課題か」を切り分けてください。用語の対応表を検索対象に含めるだけで解決するなら、RAG単独で足ります。解決しないならハイブリッドの検討対象です。
ケース2：回答は定型フォーマットだが、中身の数値は最新の台帳を見る必要がある。 これは典型的な併用候補です。フォーマットの安定は出力の型の課題、数値の鮮度は情報の課題であり、別々の技術で解くほうが素直です。ただし後述するとおり、まずRAGとプロンプトのテンプレート化で足りるかを確認してください。
ケース3：現場が「精度が低い」と言うが、何が不満か具体化されていない。 判定の前に不満の内訳を分解してください。「答えが間違っている」なら情報の課題、「言い方が社内の慣習と違う」なら型の課題、「そもそも該当文書を見つけてくれない」なら検索の課題です。3つめはファインチューニングでは改善しません。手法選定の前に、この分解を現場と一緒に済ませておくと判断がぶれません。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
RAGとファインチューニングの併用（ハイブリッド）はいつ検討するか
RAGとファインチューニングの併用は、両者の役割が競合しないため技術的には両立します。ただし「両方やれば精度が上がる」という理由で選ぶと、費用と運用負荷だけが増える結果になりがちです。併用が正当化される条件を明確にしておきましょう。
併用が効く条件
併用の検討に入る条件は、次の3つが同時に成立する場合です。
- 参照する知識の更新頻度が高い（月単位以上で改定が入る）
- 出力の形式・語調の統一も業務要件になっている（現場が書式の揺れを問題視している）
- 入出力ペアのデータが数百件以上そろっている（過去の成果物が学習に使える形で残っている）
1つめだけならRAG単独、2つめだけならファインチューニング単独で足ります。3つめが欠けている場合は、併用したくてもファインチューニング側が成立しません。
逆に、併用が不要なサインもあります。現場の不満が「答えが間違っている」に集約されている場合、それはRAG側の検索精度の課題であり、ファインチューニングを追加しても改善しません。この見極めを飛ばすと、原因と対策がずれた投資になります。
併用時の役割分担と運用負荷の増分
併用する場合の役割分担は明確です。
担当 | 役割 |
|---|---|
RAG | 回答に必要な最新の知識を供給する。出典の提示を担う |
ファインチューニング | 供給された知識を、決まった書式・語彙・語調でまとめ上げる |
一方で、運用の負荷は単純な足し算では済みません。増える作業は次のとおりです。
- 評価の複雑化：出力が期待どおりでなかったとき、検索が悪かったのか、モデルの書式が崩れたのかを切り分ける必要があります。どちらの層に原因があるかを判定する手順を、運用設計に含める必要があります
- 改修時の影響範囲の拡大：基盤モデルのバージョンが更新された場合、ファインチューニング済みモデルは追従のための再学習判断が必要になります。RAG単独ならモデルの差し替えで済んだ変更が、2層の検証を伴います
- 担当者の負荷：検索基盤の運用（文書の追加・再インデックス）と学習データの管理（追加・再学習）の2系統を維持することになります。社内に専任がいない場合、この2系統を誰が持つのかを稟議前に決めておく必要があります
併用を「最初から」狙わないほうがよい理由
結論として、併用を目指す場合でも第1段階はRAG単独から始めることを推奨します。理由は2つです。
1つめは、ファインチューニングで解くべき課題の量を、RAGを動かしてみるまで測れないためです。RAGを運用すると「出力の書式がどの程度揺れるのか」「揺れが業務上どれだけ問題になるのか」が実データで分かります。この測定値がないままファインチューニングを発注すると、必要のない範囲まで学習対象にしてしまいます。
2つめは、手法を切り替える際の手戻りコストが対称ではないためです。この非対称性が段階投資を選ぶ最大の根拠になるため、次の章で詳しく扱います。
コスト比較で見落としやすい3つの項目
提案書の金額を並べただけでは、RAGとファインチューニングのコスト比較はできません。両手法は費用が発生するタイミングと、利用量に対する増え方が違います。ここでは稟議で問われる「で、トータルいくらか」に答えるための整理方法を示します。
見落とし1 初期費用だけで比べると逆転する
比較は運用開始後12ヶ月の総額で行ってください。初期費用だけの比較では順位が入れ替わることがあります。
継続的に発生する費目を、両手法で分解すると次のようになります。
RAG側の継続費目
費目 | 内容 |
|---|---|
埋め込み生成 | 文書をベクトル化する処理の費用。追加・改定のたびに発生 |
ベクトルデータベースの維持 | インスタンス費用またはマネージドサービスの利用料。文書量とストレージに比例 |
再インデックス | 文書改定時の再取り込み。改定頻度に比例 |
プロンプトのトークン増 | 参照文書を毎回プロンプトに載せるため、1回あたりの入力トークンが増える |
検索精度の改善工数 | 「該当文書が出てこない」を改善するチューニング。運用初期に集中して発生 |
ベクトルデータベースの費用構造については、AWSの規範ガイダンスがRAGユースケース向けに考慮事項を整理しています。ベンダー提案の見積を検証する際の参照軸として使えます。
ファインチューニング側の継続費目
費目 | 内容 |
|---|---|
学習データの整備 | 入出力ペアの作成・クレンジング・品質確認。人手の工数が中心 |
再学習 | 業務内容や書式が変わった際の学習ジョブ費用と検証工数 |
基盤モデル更新への追従 | 元のモデルが新版に移行した際、ファインチューニングをやり直すかの判断と実施 |
推論単価 | ファインチューニング済みモデルの単価。前述のとおり基盤モデルより高く設定される場合がある |
モデルのホスティング費用 | デプロイしている間、利用の有無にかかわらず時間単位で発生する場合がある（提供形態によって異なるため要確認） |
稟議に載せるのは、この12ヶ月分の合計です。初期費用が安いほうが12ヶ月では高くなるケースは珍しくありません。
見落とし2 利用量が増えたときの伸び方が両者で違う
同じ12ヶ月でも、利用量の前提を変えると結果が変わります。想定利用回数を3水準（控えめ・想定・全社展開）で試算してください。
伸び方の違いは次のように整理できます。
- RAGは、1回の問い合わせごとに検索処理と参照文書分のトークンが発生します。利用回数にほぼ比例して増えます。文書量が増えるとストレージと検索処理も増えますが、こちらは緩やかです
- ファインチューニングは、学習費用が利用回数と無関係に先に発生し、以降は推論単価×利用回数で増えます。プロンプトが短いため1回あたりの単価は抑えられる一方、モデルの単価自体が高く設定されている場合があります。加えて、提供形態によってはモデルをデプロイしている間の時間課金が利用回数と無関係に発生するため、利用が少ないほど1回あたりの実質コストは高くなります
損益分岐点を計算する際は、次の2つの数字を出すだけで方向が見えます。
- RAGの1回あたりコスト：（参照文書込みの平均入力トークン数 × 基盤モデルの入力単価）＋ 検索処理の費用
- ファインチューニングの1回あたりコスト：（短縮後の平均入力トークン数 × ファインチューニング済みモデルの入力単価）
この2つの差額に年間利用回数を掛けた額が、学習費用・再学習費用・モデルのホスティング費用の合計を上回るかどうかが判断ラインです。ベンダーに「この2つの数字と、利用回数に依存しない固定費を出してください」と依頼すれば、提案の前提が数値で比較できるようになります。
見落とし3 手法を切り替えるときの手戻りコストは対称ではない
ここが本記事で最も強調したい論点です。手法選定を誤ったときの損失は、どちらから始めたかで大きく変わります。
ファインチューニングから始めてRAGに切り替える場合、失われる資産が多くなります。入出力ペアの作成、アノテーション、品質確認にかけた人手の工数は、RAGの構成では直接活かせません。学習ジョブに投じた費用も回収できません。元になった文書自体は検索対象として再利用できますが、学習データ形式に加工した分の工数は戻ってきません。
RAGから始めてファインチューニングを追加する場合、資産の多くが残ります。文書の電子化、テキスト抽出、チャンク分割の設計、メタデータの付与といった整備作業は、ファインチューニング用の学習データを作る際の土台としてそのまま使えます。検索基盤も、併用構成ではそのまま稼働し続けます。加えて、RAGを運用して蓄積された「質問と、現場が承認した回答」のログは、そのまま学習データの候補になります。
つまりRAG → ファインチューニングは資産が積み上がる方向、ファインチューニング → RAGは資産が失われる方向です。判断に迷ったときにRAGから着手すべき理由は、技術的な優劣ではなくこの非対称性にあります。
この論点は稟議でも効きます。「判断を誤った場合の損失が小さい順序で着手する」という説明は、技術的な議論に入らずに承認を得やすい論理です。
稟議用にコストを整理する3行の書き方
費用の説明は、次の3行に集約すると伝わります。
- 初年度総額：初期構築費＋12ヶ月の運用費（利用量は「想定」水準で記載し、前提の利用回数を明記する）
- 利用量が増えた場合の上限：「全社展開」水準で試算した12ヶ月の運用費（増加要因を1つだけ添える。例「参照文書をプロンプトに載せる分のトークン費用が利用回数に比例して増えるため」）
- 手法を切り替える場合の追加費用：第2段階でファインチューニングを追加する場合の概算と、その判断を行う時期
3行目まで書いてあると、「途中で方針が変わったらどうするのか」という質問を先回りできます。
判断を誤らないための進め方：プロンプト改善 → RAG → ファインチューニングの順に検証する
手法を選んだあとの進め方です。段階を分け、各段階に「次へ進む条件」と「ここで止める条件」を先に決めておきます。条件を先に決めることが重要で、後から決めると成果の評価が主観的になります。
第0段階：プロンプトエンジニアリングで足りないかを先に確認する
プロンプトエンジニアリング・RAG・ファインチューニングの違いは、投じるコストと変更できる範囲の違いとして整理できます。
手法 | 変更する対象 | 着手コスト | 効く課題 |
|---|---|---|---|
プロンプトエンジニアリング | 指示文とサンプルの与え方 | ほぼゼロ（工数のみ） | 出力の方向づけ、書式の大枠、判断基準の提示 |
RAG | 参照させる情報 | 中（検索基盤の構築） | 情報の正確さ・鮮度、出典提示 |
ファインチューニング | モデルの振る舞い | 大（学習データ整備＋学習） | 書式・語調の安定、専門語彙の一貫性 |
最初に確認すべきはプロンプトエンジニアリングです。OpenAIのモデル最適化のガイドでも、まず評価の仕組みを整えてプロンプトの改善を繰り返すことが推奨されており、そのうえで「プロンプトの改善だけで十分な結果が得られる場合もある」と述べられています。ファインチューニングは初手ではなく、プロンプトの改善で届かなかった課題に対する選択肢として位置づけられています。この「安い手段から順に試す」という優先順位の考え方は、先に触れたファインチューニングの提供形態の変動とは無関係に成り立つため、そのまま使えます。
第0段階で確認することは2つです。ひとつは、既存の汎用AIサービスに社内文書を数件貼り付けて質問した場合、どこまで満足できる回答が出るか。もうひとつは、書式の指定を丁寧に書いたプロンプトで、出力の揺れがどの程度収まるか。この2つを現場担当者と一緒に試すだけで、投資が必要な範囲が絞れます。
次へ進む条件：文書量が多すぎて貼り付けでは扱えない、または文書が頻繁に改定されて貼り付け運用が回らないことが確認できた場合。 ここで止める条件：プロンプトの工夫と既存ツールで現場の要望が満たせた場合。この結果も稟議では価値があります（「検証の結果、追加投資は不要と判断」という報告になります）。
第1段階：RAGを小さく検証し、次へ進む条件を決めておく
RAGの検証は、対象文書を絞って始めてください。全社の全文書ではなく、要望が最も強い部門の主要文書に限定します。目的は精度の証明ではなく、判断材料の取得です。
検証で取得すべき数字は3つです。
- 検索の当たり率：現場が用意した想定質問のうち、根拠となる正しい文書が検索されてきた割合
- 回答の許容率：現場担当者が「そのまま使える」と判断した回答の割合
- 出力の揺れ：同じ質問を複数回投げたとき、書式・語調がどの程度ばらつくか
3つめが第2段階の判断材料になります。揺れが業務上問題にならないなら、ファインチューニングは不要という結論になります。
合格ラインは検証前に決めてください。指標の定義や合格ラインの考え方についてはRAG評価指標でRAGASの4指標と合格ラインの決め方を整理しているので、ベンダーとの合意形成に使えます。本記事で強調したいのは、数字を取る前に「この数字を下回ったら止める」を決めておくという判断側の作法です。これがないと、PoCの結果が出た後に「もう少しチューニングすれば」という議論が延々と続きます。
次へ進む条件：検索の当たり率と回答の許容率が合格ラインを超え、かつ出力の揺れが業務上の問題として現場から指摘された場合。 ここで止める条件：検索の当たり率が合格ラインに届かない場合。この場合の課題は検索側にあり、ファインチューニングを追加しても改善しません。文書の整備・チャンク設計・検索方式の見直しに戻ります。
第2段階：ファインチューニングを追加する判断ライン
第2段階に進む条件は次の3つです。
- 第1段階で出力の揺れが定量的に測れている（「書式が揺れる」ではなく「想定質問100件のうち何件で書式が崩れたか」まで出ている）
- その揺れがプロンプトのテンプレート化では収まらないことを確認済み
- 学習に使える入出力ペアが、前述の目安件数以上そろっている（第1段階の運用ログから現場承認済みの回答が蓄積されていれば、それを充てられます）
3つめについては、第1段階を数ヶ月運用するとログが自然に貯まるという点が段階投資の副産物です。最初からファインチューニングを狙った場合、この学習データを人手で一から作る必要がありました。
ここで止める条件：揺れの件数が業務影響として小さい場合。ファインチューニングを追加せず、プロンプトのテンプレート整備で運用を続ける判断です。
ベンダーに確認する5つの質問
提案手法が自社要件に合っているのか、その会社の得意分野を勧めているだけなのかを見極めるための質問です。RAGを選んだ後のベンダー選定で聞くべき技術的な質問とは別に、手法選定そのものの妥当性を検証する質問に絞りました。
- 「この手法を選んだ判断根拠を、当社の業務条件で説明してください」 — 更新頻度・出力の型・出典提示の必要性のうち、どれを根拠に選んだのかを聞きます。一般論の説明しか返ってこない場合、自社要件の読み込みが浅い可能性があります
- 「もう一方の手法を選ばなかった理由を教えてください」 — 却下の理由が言えるかどうかで、両方を検討したのかが分かります。この回答はそのまま稟議の「検討した代替案」の材料になります
- 「当社の文書の更新頻度は◯回／年ですが、その前提でも提案手法は妥当ですか」 — 自社で確認した数字を提示して再確認します。提案の前提が仮定だった場合、ここで修正が入ります
- 「12ヶ月運用した場合の総額と、その内訳をいただけますか」 — 初期費用ではなく12ヶ月総額で出してもらいます。利用量の前提も明記してもらってください
- 「将来もう一方の手法を追加する場合、今回の構築物のどこが再利用できますか」 — 段階投資を前提にした質問です。回答があいまいな場合、拡張を想定した設計になっていない可能性があります
ファインチューニングを含む提案を受けている場合は、質問1に付随して「どのサービス・どの経路で学習を実施するのか」も確認してください。先に触れたとおり、提供形態は変動しています。契約期間中の提供継続性まで回答できるかどうかは、そのベンダーが提供元の動向を追えているかの判断材料になります。
この5問への回答を2社分並べると、どちらが自社要件を読み込んでいるかが明確になります。質問2と5の回答は、次の章で扱う稟議資料にそのまま転用できます。
社内稟議で「なぜこの手法か」を説明する型
判断結果を稟議資料の文面に落とします。役員が知りたいのは技術の仕組みではなく、「妥当な検討を経て決まったのか」「失敗したときにどうなるのか」の2点です。
稟議資料に書く4項目
次の4項目を書けば、手法選定の説明としては十分です。
項目 | 書く内容 | 分量の目安 |
|---|---|---|
業務要件 | どの業務の、どの困りごとを解決するか。更新頻度・出力の型・出典提示の必要性を数字と事実で記載 | 2〜3行 |
選定した手法とその理由 | 手法名と、業務要件のどの条件が決め手になったか | 3行 |
検討した代替案と却下理由 | もう一方の手法を挙げ、どの条件で合わなかったか | 2行 |
撤退・見直しの条件 | 何をもって成功・失敗と判断するか、いつ判断するか | 2行 |
4項目めを書いておくことが、承認を得るうえで効きます。「うまくいかなかったら止める条件が先に決まっている」提案は、承認側のリスクが小さくなります。
選定理由を3文で書く（RAG／ファインチューニング／併用の記述例）
RAGを選んだ場合の記述例
参照対象となる技術規程・作業標準は年間14回改定されており（文書管理台帳より）、改定内容を当日反映できることが業務要件である。また品質記録に関する回答は原典確認が必須であり、回答に根拠文書を併記できる構成が必要である。以上2点より、知識をモデル外部に保持し検索して参照するRAG構成を選定する。
ファインチューニングを選んだ場合の記述例
対象業務は検査記録の文章化であり、参照する判定基準は過去3年間改定されていない。求められているのは情報の検索ではなく、所定の書式・用語に統一された文章の生成である。承認済みの記録文書が1,200件蓄積されており学習データとして利用可能なため、モデル側に書式と用語を定着させるファインチューニングを選定する。
併用を選んだ場合の記述例
参照する部品仕様は月次で更新される一方、出力先の顧客向け回答文には所定の書式と社内用語の統一が求められる。第1段階として仕様情報をRAGで参照する構成を構築し、出力の書式のばらつきを想定質問100件で測定する。測定結果が許容範囲を超えた場合に限り、第2段階でファインチューニングを追加する。
いずれも共通しているのは、数字（改定回数・件数・測定対象数）が入っていることと、手法名より先に業務条件が来ていることです。この順序で書くと、技術の説明を求められにくくなります。
「なぜもう一方ではないのか」に一言で答える
役員会で想定される追加質問と、その一言回答の型です。
想定質問 | 一言回答の型 |
|---|---|
なぜファインチューニングではないのか | 「参照する規程が年◯回改定されるため、改定ごとに再学習の費用と期間が発生します。改定を当日反映できる構成を優先しました」 |
なぜRAGではないのか | 「今回必要なのは情報の検索ではなく出力書式の統一であり、参照する基準は◯年間改定されていません。検索基盤を持つ必要性が低いと判断しました」 |
なぜ両方やらないのか | 「両方の運用を同時に立ち上げると、期待どおりでなかったときの原因切り分けができません。まず片方で数値を取り、必要性が数値で確認できた段階で追加します」 |
もっと安い方法はないのか | 「既存ツールとプロンプトの工夫で足りるかを先に検証しました。文書量と改定頻度の点で運用に乗らないことを確認済みです」 |
失敗したらどうなるのか | 「第1段階で◯◯が基準を下回った時点で打ち切ります。その時点での投資額は◯◯万円で、整備した文書資産は他の用途にも使えます」 |
最後の質問への回答に、先ほど整理した手戻りコストの非対称性が効きます。「RAGから着手した場合、整備した文書とログは次の段階でも使える」と説明できると、失敗時の損失が限定されていることが伝わります。
まとめ：使い分けの判断は自社の条件に落とせば自力で決められる
RAGとファインチューニングの使い分けは、技術の優劣を評価する作業ではなく、自社の業務条件を確認する作業です。本記事の要点を再掲します。
5つの問いで判定する。 参照する知識が月単位で変わるか、求めているのは正しい情報か決まった型の出力か、出典を示す必要があるか、学習に使える入出力ペアが何件あるか、想定利用規模はどれくらいか。更新頻度が高い場合と出典提示が必要な場合は、RAGが土台になります。入出力ペアが数百件に届かない場合、ファインチューニングは時期尚早です。
費用は12ヶ月の総額と、利用量3水準で比較する。 初期費用だけの比較では順位が入れ替わります。ファインチューニング済みモデルの推論単価は基盤モデルより高く設定されることが多く、デプロイ中の時間課金が加わる場合もあるため、「規模が大きいほどファインチューニングが安い」とは限りません。1回あたりのトークン数と単価から損益分岐点を計算してください。あわせて、ファインチューニングを含む提案では、どのサービス経由で学習を実施するのか、その経路が契約期間中も提供され続けるのかをベンダーに確認してください。
着手はRAGから、段階的に進める。 プロンプトの改善で足りないかを確認し、次にRAGを小さく検証し、出力の揺れが数値で問題だと確認できた場合にファインチューニングを追加します。RAGからファインチューニングへは資産が積み上がる一方、逆方向では学習データ整備の工数が失われます。この非対称性が、迷ったときにRAGから着手すべき根拠です。
稟議には4項目を書く。 業務要件、選定した手法とその理由、検討した代替案と却下理由、撤退・見直しの条件。数字を入れ、手法名より先に業務条件を書くと、技術の説明を求められにくくなります。
この4つを埋めれば、ベンダーの提案が食い違っていても、自分の言葉で「なぜ自社ではこの手法なのか」を説明できる状態になります。次の一手は、社内の文書改定履歴と過去の成果物の件数を数えることです。判断に必要な数字は、すでに社内にあります。
関連情報
自社の業務がAI活用に適しているかを判断する問いを業種別にまとめた資料として、業種別 AI 活用チェックリストをご用意しています。製造・物流・医療・飲食・小売の業務別に、着手前に確認すべき項目を整理しています。
手法選定の段階で判断材料が足りないと感じている場合は、お問い合わせフォームからご相談いただけます。要件の整理やベンダー提案の比較軸の設計段階からご相談を承っています。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 5つの問いの答えが割れてしまった場合、どちらを優先して判断すればよいですか
出典提示の要否と更新頻度への回答を最優先してください。どちらか一方でもYESであれば、残り3問の結果に関わらずRAGが土台になるため、判断の手戻りを小さく抑えられ、稟議準備にも早く着手でき、後から判断が覆る心配もありません。
- 稟議までの時間が短く、5つの問い全部を検証する余裕がない場合はどうすればいいですか
出典提示の要否と更新頻度の2問だけを先に確認してください。この2問のどちらかでYESが出れば、残り3問の検証を待たずにRAGを土台とする判断を先に固定でき、限られた時間でも稟議準備を進められるうえ、後から判断が覆る心配もありません。
- ファインチューニングのセルフサーブ提供終了は、手法自体が使えなくなるという意味ですか
いいえ、手法自体が使えなくなるわけではありません。終了するのはOpenAIのセルフサーブ経路のみで、Azure OpenAIなどクラウド事業者経由の提供は残るため、提案書のベンダーがどの経路を使うかを確認してください。
- RAGとファインチューニングを併用する場合、両方を同時に発注してもよいですか
同時発注は避けてください。両方を並行させると出力が期待どおりでなかった際に検索精度とモデルの書式のどちらが原因か切り分けられなくなるため、まずRAG単独で出力の揺れを実測してから追加する順序が安全です。
- ベンダー2社の提案が食い違うとき、どちらを信頼すればよいですか
どちらか一方を信頼するのではなく、自社の更新頻度・出力の型・出典提示の要否を先に確定し、その条件を両社に伝えて再提案を求めてください。提案の食い違いの多くは技術力の差ではなく前提の仮定違いに起因します。
