ファインチューニングとRAGのどちらを選ぶべきかという相談は、たいてい質問ではなく宣言の形でやってきます。自社のデータでモデルをファインチューニングしたい、という一文です。これは企業のAI導入において最も高くつく言葉のひとつであり、そして多くの場合は誤っています。常にではありませんが、たいていは誤りです。この依頼が実際に意味しているのは、ほぼ必ず二つのうちどちらかです。モデルが自社の業務を知らないか、あるいはモデルが望んだ形で答えてくれないか。ファインチューニングは前者に対しては筋の悪い解決策であり、後者に対しては高すぎる解決策です。
三つの手法のあいだの選択は、技術的な好みの問題ではありません。それぞれが別の種類の問題を解いており、選び方を間違えると、数か月分の作業を投じたあとで、そもそもの苦情には何ひとつ答えていないという結果になります。予算の観点から見れば、これは機能の失敗ではなく診断の失敗です。
最も費用を節約する原則: モデルが何かを知らないことが問題なら、検索を使ってください。モデルは知っているのに、文体や書式や長さが望んだものと違うことが問題なら、まずプロンプトを改善し、それで駄目だったときにだけファインチューニングを検討してください。ファインチューニングが教えるのは振る舞いであって事実ではありません。知識を注入する目的でこれを使ったチームが手にするのは、新しい社内文体で自信たっぷりに間違えるモデルです。
ファインチューニングとRAGとプロンプト:それぞれが何をするのか
区別そのものは、世間の議論が示唆するよりずっと単純です。
プロンプトは、リクエストのたびにモデルへ送る指示を変えます。トーン、書式、構造、推論の進め方を形づくり、あわせて控えめな量の文脈をその場で与えることもできます。効果は即座に現れ、費用はトークン代以外にかからず、本番環境でも数秒で書き換えられます。運用しながら方針を修正したいとき、これほど身軽な手段は他にありません。
**検索(リトリーバル)**は、リクエスト時に自社のコンテンツから関連する素材を取り出し、モデルが答える前にコンテキストへ差し込みます。これによりモデルは、学習時にはまったく見ていない情報にアクセスできます。今朝更新されたばかりの内容であっても構いません。モデル自体は何も変わっていません。変えているのは、モデルに渡す材料のほうです。仕組みの詳細は検索拡張生成(RAG)の解説 で扱っています。
ファインチューニングは、望む振る舞いの実例を使ってモデルの重みを調整します。言葉で説明するのは難しいが実例で示すのは容易な、一貫した書式やトーン、タスク固有のパターンを教える手段としては、実際によく効きます。一方で事実を教える手段としては不向きです。この方法で覚え込ませた事実は更新できず、監査もできず、出典を示すこともできません。しかも、その事実を誤った形で持ち出しているときに、モデルがそれを自己申告する術はありません。
混乱が生じるのは、三つとも出力を変えるからです。しかし、モデルが知っていることを変えるのは検索だけです。
それぞれの費用
以下の数字は、中規模の業務アプリケーションを英国で開発した場合の典型的な水準を反映しています。
プロンプト。 週ではなく日の単位で終わります。並行して用意すべき評価セットを含めて、おおむね1,000ポンドから5,000ポンドが目安です。運用費用はトークン代そのものです。システムプロンプトを長くすれば費用はわずかに上がりますが、プロンプトキャッシュがその大半を相殺してくれます。
検索。 四週間から十二週間、金額はおおむね15,000ポンドから60,000ポンドで、原典コンテンツがどれだけ荒れているかによって上下します。構築費用の大半は取り込み処理に集中します。文書をそれを抱えているシステムから取り出すこと、意味の単位で妥当にチャンク分割すること、利用者が見てよいものだけを検索できるように権限を扱うこと、そしてインデックスを最新に保つことです。運用費用にはベクトル保存の費用と、リクエストごとにやや大きくなるコンテキストの分が加わります。
ファインチューニング。 エンジニアリングに二週間から八週間、加えてデータセットの整備が必要で、金額はおおむね20,000ポンドから80,000ポンドです。学習にかかる計算費用は、たいてい最も小さな項目です。費用の本体は、品質の高い例を数百件から数千件つくることにあります。これは対象領域を理解している人間の手作業です。運用費用も高くなる場合があります。ファインチューニング済みモデルには割増料金がつくか、専用のホスティングが必要になることが多いためです。
重要なのはこの非対称性です。十分ではないだろうとかなり確信している場合でも、まずプロンプトから試すだけの安さがあります。どのみち評価の仕組みは必要になりますし、実際の失敗がどの種類のものなのかを、そこで初めて具体的に知ることができるからです。
試す順序
順番に進めるほうが、結論に飛びつくより安く済みます。最終的に同じ結論へたどり着く場合でも、です。
まず評価セットをつくってください。 正解が分かっている出力とセットになった、実際の入力を三十件から百件そろえます。これがないと、加えた変更が役に立ったのかどうかを判断できず、以降の意思決定はすべて当て推量になります。地味な作業ですが、ここから先に出てくるすべての選択肢の前提になります。これは OpenAI API 統合ガイド で説明したのと同じ仕組みです。
次にプロンプトを改善します。 書式について具体的に指定し、良い出力の例をいくつかプロンプト内に置き、答えが分からないときにどうすべきかを明示してください。モデルの性能が足りないという苦情のうち、驚くほど多くの割合がこの段階で解消します。とりわけ冗長さと構造に関する不満は、ここで消えることが多いのです。
次に、より大きなモデルや別のモデルを試します。 どんなカスタマイズ作業よりも安く済むことが多く、評価そのものは半日あれば終わります。この比較を正しく行う方法はOpenAIからの移行 で扱っています。
失敗の原因が知識にあるなら、そこで検索を足します。 自社の製品、ポリシー、社内文書について尋ねられたモデルが、誤った答えを返したり回答を拒んだりしているなら、それを直すのはこの段階です。事実の欠落は、どれだけプロンプトを磨いても埋まりません。
失敗の原因が振る舞いにあるなら、そこで初めてファインチューニングを検討します。 この時点で手元には、評価セットと調整済みのプロンプトがあり、必要であれば検索のパイプラインもあります。それでもなお出力の文体や構造が要求に届かず、しかも望む振る舞いを言葉で説明するより数百件の実例で示すほうが容易だというのであれば、そのときファインチューニングは正しい道具です。
多くのプロジェクトは三番目か四番目の段階で止まります。その差額こそが、節約できた金額です。
ファインチューニングが本当に効くとき
実際に効く場面はあります。最初に飛びついてしまうのが誤りであるのと同じくらい、頭から否定してしまうのも誤りです。
大量処理における一貫した構造化出力。 すべての応答が厳格な書式に従わなければならず、その書式をプロンプトで細かく指定するのが煩雑きわまりないとき、ファインチューニング済みモデルはより確実に、しかもはるかに少ない入力トークンでそれを生成します。物量が増えるほど、この差が投資を回収していきます。
専門的なトーンや業界特有の文体。 法務文書の起案、診療記録、規制下にある金融コミュニケーションのように、その道の実務者なら一目で判別できる強い慣習を持ちながら、指示文では捉えきれない文体がこれにあたります。
境界線が微妙で、言語化しにくい分類。 自社のチームは一貫してラベルを付けられるのに、その判断基準を言葉にできないという状況があります。実例から学習させるという手法は、まさにそのために存在します。
大量処理における費用削減。 狭い一つのタスクに限れば、小さなファインチューニング済みモデルが大きな汎用モデルと同等の品質に届くことがあり、その場合はリクエストあたりの費用を大幅に下げられます。ただしこれは、節約額が構築と保守の費用を上回る物量に達している場合にのみ意味を持ちます。
共通しているのは、知識ではなく振る舞いだという点です。欲しいものを一段落で説明できるなら、プロンプトで指示してください。見せることしかできないなら、学習させてください。
誰も見積書に書かない費用
ファインチューニングの稟議からは、継続的に発生する三つの負担が決まって抜け落ちます。
データセットは古びます。 ファインチューニング済みモデルは、学習時に見た例をそのまま映し出します。製品やポリシー、社内の文体基準が変われば、その例は過去のものになり、モデルは古い振る舞いを自信たっぷりに再生し続けます。定期的な再学習は一度きりの出費ではなく、恒常的な費用として予算に組み込んでください。
特定のベースモデルに縛られます。 ファインチューニングは特定のバージョンに紐づきます。そのベースが提供終了になったとき、あるいはより優れたモデルが登場したとき、移行するには再学習が必要です。これはプロンプトには存在しない、実在の乗り換え費用です。
評価は任意ではなく必須になります。 プロンプトであれば、退行が起きたときに目視でおおよその見当をつけられます。ファインチューニング済みモデルでは、振る舞いがなぜ変わったのかを内部から確認する手段がありません。評価の仕組みが、あなたに残された唯一の計測器になります。
検索にも規模の小さい同種の負担があります。インデックスは最新に保たなければならず、人の役割が変われば権限も正しく追随させなければならず、取り込み処理が静かに止まったことに誰かが気づかなければなりません。再学習より安いのは確かですが、無料ではありません。
構築の前に診断を
Mecanikは検索システム、評価の仕組み、ファインチューニングのパイプラインをAI統合サービス の一環として構築していますが、着手の前に必ず、三つの問題のうち実際にどれを抱えているのかを確かめます。
この診断はたいてい短期の案件で終わり、当初計画していたプロジェクトよりはるかに安く済む提案で結論を迎えることが少なくありません。ファインチューニングが本当に正解である場合には、そう申し上げたうえで、データセット整備の工数を正直に見積もります。成否を分けるのは、まさにその部分だからです。予算全体の見取り図については、AI統合コストのガイド で構築費用と運用費用を分けて整理しています。
モデルの何がうまくいっていないのかを、御社の利用者が使う言葉のままでお聞かせください。三つのうちどれなのかをお答えします。
関連記事: AIソフトウェア開発 - 2026年 英国ビジネスガイド 、Kimi K3 セルフホスティング:機材・費用・主権 、2026年のDrupal移行:費用・選択肢・期限 、OpenAI APIチャットボット構築:2026年ガイド 。
よくある質問
自社データでモデルをファインチューニングすべきですか。 たいていの場合は不要です。ファインチューニングが教えるのは事実ではなく振る舞いであり、その方法で覚えた知識は更新も引用も監査もできません。モデルが自社の製品、ポリシー、社内文書を知らないことが問題なのであれば、正しい手段は検索であり、構築も保守も検索のほうが安く済みます。
ファインチューニングとRAGの違いは何ですか。 検索はリクエスト時に自社のコンテンツから関連する素材を取り出し、コンテキストに置きます。そのためモデルは、学習時にまったく見ていない情報からでも答えられます。ファインチューニングは実例を使って重みを調整するもので、モデルが何を知っているかではなく、どう振る舞うかを変えます。
ファインチューニングの費用はどれくらいですか。 中規模の業務アプリケーションで、おおむね20,000ポンドから80,000ポンド、エンジニアリングに二週間から八週間が目安です。学習にかかる計算費用はたいてい最も小さな項目で、費用の大半は品質の高い例を数百件から数千件つくることに向かいます。これは対象領域を理解している人の手作業です。
RAGシステムの構築費用はどれくらいですか。 四週間から十二週間で、おおむね15,000ポンドから60,000ポンドが一般的です。金額を左右する主な要因は、原典コンテンツがどれだけ荒れているかです。工数の大半は取り込み、チャンク分割、利用者が見てよいものだけを検索できるようにする権限の扱い、そしてインデックスを最新に保つ作業に費やされます。
どの順序で試すべきですか。 まず評価セット、次にプロンプト、次により大きなモデルや別のモデル、失敗の原因が知識にあるならそこで検索、そして失敗の原因が振る舞いにある場合にのみ、最後にファインチューニングです。多くのプロジェクトは、この最終段階に至る前に解決します。
コメント