RAGとは？ファインチューニングとの違いと、業務に合う選び方

RAGとは、回答に必要な根拠をモデルに渡す仕組みです。必要な社内情報がモデルに届いていないならRAGを使い、情報はそろっているのに文体や判断ルールを繰り返し間違えるなら、ファインチューニングを検討します。両者の違いは、根拠を渡すか、振る舞いを学習させるかにあります。以下の3つの業務例で見ていくと、学習料金が安くても、システム全体が安くなるとは限らない理由がわかります。

ドキュメント、モデルの提供状況、定価は2026年10月16日に確認しています。 以下の処理量と計算は予算検討のための例であり、顧客環境での実測結果ではありません。

RAGとは？ファインチューニングとどう使い分けるか

検索で改善するのは知識へのアクセス、ファインチューニングで改善するのは繰り返し現れる振る舞いです。 この違いを押さえると、サービスを選ぶ前に、どこへ手を入れるべきかが見えてきます。

検索拡張生成、つまりRAGは、関連する資料を検索し、モデルが回答する前に、その内容をコンテキストへ渡します。ファインチューニングは、望ましい回答や判断の例を使って事前学習済みモデルを追加学習し、学習済みのパラメーターを変更する手法です。サポート担当者にたとえるなら、検索は最新の業務マニュアルを手渡すこと、ファインチューニングは修正済みの対応例で指導することに当たります。どちらを使う場合も、明確な指示は欠かせません。

これは使い分けの出発点であって、「学習では事実を教えられない」という絶対的な法則ではありません。ファインチューニングでも、事実同士の関連は学習できます。ただし、それによって最新の規定、文書のアクセス権限、出典を確実に管理できるデータベースが手に入るわけではありません。AWSの比較解説でも、知識の提供とモデルのカスタマイズは別の役割として整理されています。

まず、正しい根拠を渡して試します。 失敗した質問に、正しく最新の該当箇所を手動で添えてください。それで回答が合格になるなら、直すべきは検索です。それでも失敗するなら、指示、タスクの難しさ、回答時の振る舞いを調べます。このシンプルな基準構成を改善してから、初めてファインチューニングを候補にします。

開発者にとっては、文書を処理する仕組みと学習の仕組みを切り分ける基準になります。運用担当者にとっては、知識を管理する人と学習例を承認する人のどちらが問題を担当すべきかが明確になります。導入を判断する人には、実用的な受け入れテストになります。追加する構成要素がどの失敗を直すのか、ベンダーに示してもらいましょう。

RAG・ファインチューニング・プロンプトエンジニアリングの違い

タスクの合格基準を満たす、最小限の改善から始めます。 プロンプトエンジニアリングとは、リクエストに含める指示、例、コンテキストを改善することです。検索を使うシステムでも、ファインチューニングしたシステムでも、引き続き必要になります。

RAGとプロンプトエンジニアリングはどう使い分けるか

必要な資料がすでにリクエスト内にあるなら、プロンプトで対応します。社内の情報源から資料を探す必要があるなら、検索を加えます。指示を改善しても、モデルに渡っていない解約条項はわかりません。一方、検索インデックスを用意しても、その条項をどう適用するかについて指示が矛盾していれば解決できません。

プロンプトエンジニアリングからファインチューニングへ進むのはいつか

変更が続くブランドのルールや、たまにしか行わないタスクは、プロンプトで扱います。明確な指示と代表的な例を示しても、安定した反復業務で同じ振る舞いの失敗が続くなら、ファインチューニングを検討します。Googleのチューニングガイドも、まずプロンプトによる基準構成を確立するよう勧めています。

ファインチューニングと転移学習の関係

ファインチューニングは転移学習の一種です。先行する学習で得た能力を、自分のタスクへ適応させます。情報源を検索する別の手法ではありません。ここで考えるべきなのは、そもそも学習済みの振る舞いを変える必要があるかどうかです。

実装前に、対応モデルと利用条件を確認する

マネージドサービスでファインチューニングを始める前に、モデルの対応状況とアカウントの利用資格を両方確認します。 古いチュートリアルにモデル名が載っているだけでは不十分です。

OpenAIのセルフサービス型ファインチューニング基盤は、2026年5月7日に、それまで利用実績のなかった組織への提供を終了しました。2026年7月2日からは、直前の60日間にファインチューニング済みモデルを実行していなかった組織も、ジョブを作成できなくなりました。現在の告知では、継続利用中の既存顧客も2027年1月6日に新規ジョブを作成できなくなり、既存のファインチューニング済みモデルによる推論は、基盤モデルの廃止までに限られます。新しい社内プロジェクトで標準的に選ぶ経路ではありません。OpenAIの廃止予定に関する告知。

Google Gemini 3.1 Flash-Liteは候補のひとつです。現在のGoogle Cloudドキュメントで、ラベル付きの例を使う教師ありファインチューニングへの対応が明記されています。Googleの現行ドキュメントでは、この基盤をGemini Enterprise Agent Platformと呼んでおり、以前のVertex AIのチューニングドキュメントはそちらへ転送されます。以下ではこのモデルで具体的な予算を示しますが、あなたのタスクで最も優れていると主張するものではありません。チューニング対応モデル。

デプロイ先の制約も重要です。このモデルのチューニングはus-central1またはeurope-west4で実行し、チューニング済みモデルの提供にはusまたはeuのマルチリージョンエンドポイントを使います。安価なグローバルエンドポイントのベースモデル料金を流用せず、実際に使うエンドポイントの料金で予算を組んでください。また、Googleは教師ありファインチューニングをサービスレベル保証の対象から外しています。チューニングの制限事項。

以下の例で使う料金： グローバル以外のエンドポイントでの標準的なテキスト推論は、100万トークン当たり入力$0.275、キャッシュ済み入力$0.0275、出力$1.65です。チューニングは、エポックの繰り返し分を含めて学習トークン100万当たり$3です。チューニング済みモデルの推論料金はベースモデルの1.5倍で、入力$0.4125、出力$2.475となります。いずれもGoogle Cloudの定価であり、Geminiアプリのサブスクリプション料金ではありません。Googleの料金表。

エポックとは、学習データ全体をひととおり処理する単位です。すべての例で、処理対象ごとにモデルを1回呼び出し、課金対象の出力トークン総数には推論トークンも含めると仮定しています。税金、開発、ラベル付け、評価用の呼び出し、再試行、元文書の保存、文書のスキャン、追加の検索サービスは含みません。これらには別途予算が必要です。学習の請求額は、システム導入の見積もりではありません。

3つの業務例で見る構成と費用

社内文書に基づくサポート回答：まずRAGから始める

ソフトウェア企業のサポートアシスタントに先に必要なのは、学習よりも最新の根拠です。 顧客から「解約はすぐに有効になりますか」と聞かれたら、現在の規定と、その契約に適用される例外に沿って答える必要があります。

承認済み文書を読み込み、使いやすい長さに分割し、出典URL、適用日、製品、アクセス権限を保持する取り込み処理を構築します。リクエスト時には顧客が閲覧できる資料だけを検索対象にし、該当箇所を取得して、その根拠を引用しながら答えるようモデルに指示します。変更された箇所は置き換え、削除された箇所は取り除きます。情報源が変更されても、インデックスが即座に更新されるわけではありません。

OpenAI text-embedding-3-smallは、類似検索に使う数値表現へテキストを変換します。料金は入力トークン100万当たり$0.02で、デフォルトの次元数は1,536です。文書を埋め込みベクトルに変換すると検索できるようになりますが、回答を生成するモデルを学習させるわけではありません。モデル料金、埋め込みの次元数。

この例では、ベクトルデータベースにCloudflare Vectorizeを使い、数値表現を保存して、似たものを探します。限界になるのは根拠の質です。類似度が高い箇所でも、古かったり、質問に関係なかったりする場合があります。アクセス制御を徹底し、選ばれた文章が回答の根拠になるかを確かめる責任は、アプリケーション側にあります。

構築時の費用： 分割後の文書が10,000件、平均500トークンと仮定します。初回の埋め込み作成は500万トークン × $0.02 = $0.10です。文書の解析や、前述の開発作業は含みません。

インデックスには1,536万次元が保存され、Vectorizeの無料枠である500万次元を超えます。有料プランには保存1,000万次元と月間クエリ5,000万次元が含まれ、超過料金は保存1億次元当たり$0.05、クエリ100万次元当たり$0.01です。Cloudflareが公開する計算式では、このインデックスに対する月10,000回のクエリは3,072万クエリ次元となり、含まれる枠内に収まります。保存容量の超過分は月額$0.00268です。アカウント内の別用途で、これらの枠を消費していないと仮定しています。Vectorizeの料金。

月間の構成要素別予算： 1,000件の文書断片を置き換え、平均100トークンの質問10,000件を埋め込みに変換する費用は**$0.03です。入力合計2,500トークン、出力400トークンの回答を10,000件生成すると、費用は$13.475です。これにWorkers Paidのアカウント最低料金$5と保存容量の超過分を加えると、約月額$18.51**となり、別途、初回の埋め込み作成費用がかかります。Workerの実行は、含まれる利用枠内に収まると仮定しています。Workersの料金。

運用テストでは、回答が適用時点の正しい規定を使っているか、引用箇所が回答を裏付けているか、存在しない例外を作っていないかを確認します。削除済みの文書や、顧客が別の顧客の契約へアクセスしようとするケースもテストしてください。ファインチューニングは、正しい根拠を渡しても同じ振る舞いの失敗が繰り返される場合に、後から検討します。

自社らしい文体：学習の前に、作例とキャッシュを試す

文体の基準が固まっていれば、ファインチューニングを選ぶ理由になります。まだ社内で方向性を議論している段階なら、早すぎます。 たとえば、率直に伝え、誇張を避け、具体的な次の行動で締めくくる製品案内メールを作る企業を考えます。

まずはスタイルガイドと承認済みの作例をプロンプトに入れます。それでも細かな編集上の判断を繰り返し外すなら、学習用のペアを作ります。入力は元の制作指示と事実情報、出力は編集者が承認した原稿です。完成したメールのアーカイブだけでは、どの入力に対してどの回答を返すべきかがわかりません。

土曜日のサポート開始を告知する制作指示なら、承認済みの目標文は、たとえば「土曜日もサポートにお問い合わせいただけるようになりました。お困りの際はチャットをご利用ください。」となります。目標文が文体を示し、制作指示が事実を伝えます。

文体と事実情報は分けて扱います。書き出しを短くする傾向は学習させ、今週の製品情報はリクエスト時に渡します。学習に使っていない制作指示を評価用に残し、根拠のない主張、トーン、必須情報、必要な書き直しの量を編集者に判断してもらいます。文章の類似度スコアだけで、ブランドに合う良い文章だと判断してはいけません。

構築時の費用： 平均合計1,600トークンのペア1,000件 × 3エポック = 480万学習トークンで、ジョブ1回の費用は**$14.40**です。これは予算上の仮定であり、このデータ件数やエポック数なら評価に合格するという推奨ではありません。

月間のモデル利用料： 入力1,200トークン、出力400トークンの原稿を10,000件作成すると、チューニング済みモデルでは**$14.85です。同じベースモデルを使い、各リクエストに文体の指示と作例を4,800トークン分追加する場合、キャッシュがヒットしなければ$23.10かかります。定常状態で、繰り返すプレフィックスがすべて暗黙的キャッシュにヒットする極限では、プロンプトによる基準構成の費用は$11.22**に下がります。ただし、キャッシュミスとウォームアップの費用は別途かかります。計算には前述のGoogleの料金を使っています。

キャッシュを考慮すると、費用面の結論が逆転します。編集者の手直しを減らせるならファインチューニングには価値がありますが、長い文体プロンプトの料金を繰り返し払わずに済むからといって、自動的に安くなるわけではありません。学習の仕組みを整える前に、キャッシュの利用状況と、編集者が原稿を採用する割合を測ってください。

問い合わせの分類：安定した判断を学習させ、変わるルールは検索する

分類ラベルが安定していて、繰り返す誤りを測定できるなら、問い合わせの分類はファインチューニングの有力な用途です。 使用できるラベルがbilling、access、bug、reviewだとします。

「請求書を開けません」というメッセージに、難しさが表れています。請求に関する言葉は含まれていますが、担当するのはアクセス関連の窓口かもしれません。サポート責任者と分類の境界を合意し、曖昧なケースも含めて代表的なメッセージにラベルを付けます。学習用と評価用にデータを分ける際は、同じ会話に属する関連メッセージを同じ側にまとめ、時期の新しい問い合わせも含めて、表現や製品の変化を把握します。

出力は許可されたラベルでなければなりませんが、形式が正しいだけでは成功とはいえません。緊急案件の見落とし、誤った窓口への振り分け、不要な確認依頼、その後の担当変更の負担を、それぞれ測定します。モデル自身が「自信がある」と述べても、それは振り分けに使える、校正されたしきい値ではありません。

構築時の費用： 平均合計300トークンのラベル付き事例5,000件 × 3エポック = 450万学習トークンで、ジョブ1回の費用は**$13.50です。月間のモデル利用料： 100,000件の問い合わせを、1件当たり入力250トークン、課金対象の出力20トークンで処理すると、チューニング済みモデルでは約$15.26です。同じ短いプロンプトをベースモデルに渡す場合は$10.18**です。チューニング済みモデルには、この差額に見合う判断の改善が求められます。Googleの料金表。

アプリケーションのコードで不正なラベルを拒否し、曖昧なケースは確認に回します。Googleのチューニングドキュメントでは、出力をスキーマに制限する制御付き生成を推論時に加えると、学習時との不一致が生じる可能性があると注意しています。実際にデプロイする組み合わせそのもので評価してください。チューニングの既知の問題。

窓口の担当範囲が頻繁に変わるなら、現在の振り分けルールはモデルの重みの外で管理し、検索するかプロンプトに含めます。ラベルの境界自体が変わり続けるなら、学習させられる程度に運用が安定するまでファインチューニングを待ちます。

2026年、長いコンテキストとプロンプトキャッシュで何が変わるか

文書群が小さく安定しているなら、検索サービスを構築する前に、そのままモデルへ渡す方法を試す価値があります。 長いコンテキストもキャッシュも2026年に発明されたわけではありません。ただし、現在比較すべき基準構成を変える要素になっています。

コンテキストウィンドウとは、モデルが1回のリクエストで扱える情報量です。2026年5月7日にリリースされたGemini 3.1 Flash-Liteには、1,048,576トークンのコンテキストウィンドウが用意されています。これは容量であって、大きなハンドブック内のすべての例外を正しく適用できる保証ではありません。指示、質問、生成のための余裕を確保したうえで、難しい箇所をテストします。モデルの仕様。

RAGとCAGの違いは何か

キャッシュ拡張生成、つまりCAGは、質問のたびに文書を検索する代わりに、知識を先に読み込み、キャッシュしたコンテキストを再利用する考え方です。関連文書がコンテキスト内に収まり、更新頻度が低く、その情報を受け取る全員のアクセス権限が同じ場合に役立ちます。プロンプトキャッシュが再利用するのは、繰り返される入力の処理です。事実をモデルの重みに組み込むわけでも、最新の回答を保証するわけでもありません。

80,000トークンのハンドブックを10,000回のリクエストで再利用すると仮定した場合、ハンドブックの入力部分だけで、キャッシュなしなら**$220**、すべてキャッシュにヒットする料金なら**$22かかります。新しい質問、出力、キャッシュミス、キャッシュ作成には、引き続き費用が発生します。このハンドブックを明示的キャッシュとして720時間保持すると、公表されている100万トークン時間当たり$1**の料金で、保存費用$57.60が加わります。Googleのキャッシュ料金。

暗黙的キャッシュには保存料金がかかりませんが、ヒットは保証されません。共通の資料を先頭に置き、プレフィックスを統一し、レスポンスのcachedContentTokenCountを確認します。このモデルでは、対象となるコンテキストが最低4,096トークン必要です。そのため、短い問い合わせ分類用プロンプトを、キャッシュが効く前提で予算化してはいけません。キャッシュのドキュメント。

使い分けは実務上の条件で決まります。範囲が限定され、全体をまとめて更新・権限管理できるハンドブックなら、長いコンテキストに直接渡します。社内文書がもっと多い、一部ずつ更新される、文書ごとに権限が異なる場合は、検索を使います。効果があるなら、RAGシステム内で共通の指示プレフィックスをキャッシュしても構いません。これらは併用できます。

ベースモデルのキャッシュ機能がすべて、チューニング済みモデルでも使えるとは限りません。Googleの現行のチューニング済みモデル向けキャッシュのドキュメントでは、ファインチューニング済みモデルは明示的キャッシュに非対応で、暗黙的キャッシュへの対応はモデルのバージョンによるとされています。

事実が変わり、振る舞いの問題も残るなら併用する

検索とファインチューニングは、それぞれが別々に確認できた失敗を直す場合に組み合わせます。 サポートアシスタントなら、最新の解約条項を検索しつつ、チューニング済みモデルに「回答、根拠、許可された次の行動、またはエスカレーション」という自社の回答構成を守らせる形が考えられます。

学習には、本番でモデルへ渡される根拠に近い例を使います。必要な箇所が欠けている例、無関係な箇所を含む例、内容が矛盾する例も入れ、追加の確認を求めたり、答えを作り上げずに回答を控えたりする振る舞いを学習対象にします。実行時には引き続き、制限された資料がモデルへ届く前にアクセス権限を確認します。

検索と回答時の振る舞いは、別々に評価します。正確な引用、権限の境界、情報源の更新は、引き続きアプリケーション側の責任です。ファインチューニングが代わりに保証してくれるわけではありません。

根拠を見つけるために追加の検索が必要なら、エージェント型RAGのガイドで、制約を設けた検索ループが複雑さに見合うのはどのような場合かを解説しています。安定した振る舞いの問題が確認でき、学習する理由が明確になったら、LLMのファインチューニング手順で、データセットの準備、チェックポイント、評価を確認できます。

どこが過大評価されているのか

「いつでもRAGが最善」「ファインチューニングをすれば自社を理解するモデルになる」のどちらも、妥当な開発要件ではありません。 検索は、情報源の古さ、該当箇所の選び方、コンテキストの不足によって失敗します。チューニングは、矛盾した例を学び、古いルールを以前より一貫して再現してしまうことがあります。

学習の計算料金が安いことも、過大評価されがちです。その請求額には、良い回答の定義を決める作業、ラベル付けの意見の食い違いを解消する作業、テストセットを有用な状態に保つ作業は含まれません。コンテキストウィンドウが大きくなれば容量の制約は緩みますが、渡したすべての事実について正しく推論できると証明されたわけではありません。

求めるべき主張は、もっと具体的です。学習に使っていない実務の評価例で、その構成要素が特定の失敗を直し、ほかの要件も維持できるかどうかです。既存のプロンプトで合格しているなら、システムを変える必要はありません。

RAGとファインチューニングを選ぶタイミング

根拠の不足には今すぐ対処し、学習は振る舞いの問題を特定して測れるようになるまで待ちます。 規定が変わる現場の運用担当者は、情報源の管理責任と更新を整えます。作例の基準が固まっていて書き直しが繰り返し発生する編集部は、プロンプトとチューニングを比較します。分類ラベルが変わり続けるなら、学習は待つべきです。別の最適化手法が使えるようになったからといって、うまく動いているプロンプトベースの業務を変える必要はありません。

週明けは、次の手順から始めてください。

1. 1

   システムを変える前に、失敗例を保存する

   代表的なサポートの質問、制作指示、問い合わせを選びます。承認済みの回答や判断を記録し、これらの評価例は学習データに含めずに残します。

2. 2

   足りない根拠を手動で渡す

   正しい該当箇所と明確な指示を添え、同じタスクを繰り返します。残った誤りを、知識の不足、ルールの曖昧さ、振る舞いの誤り、モデルがまだ処理できないタスクに分類します。

3. 3

   最小限の候補構成で費用を計算する

   現在のプロンプト、キャッシュや長いコンテキストを使うプロンプト、検索の順に比較し、それでも必要な場合に対応モデルでのファインチューニングを検討します。実際の課金対象トークン、キャッシュヒット、再試行、人による修正作業を数えます。

4. 4

   タスクの合格基準を満たしてから導入する

   合格する構成のうち、最もシンプルなものを選びます。文書の更新や学習例のレビューの担当者を決め、デプロイしたバージョンを記録し、元に戻す手段を確保します。

よくある質問

AIのファインチューニングとは何ですか？

ファインチューニングは、追加の学習例を使って事前学習済みモデルを用途に合わせる手法です。社内業務では通常、繰り返し求められる回答の文体やタスクの処理方法を学習させることが有効です。

モデルのファインチューニングには、どれくらい費用がかかりますか？

文章作成の例では、記載したトークン数とエポック数を前提に、Googleの学習ジョブ1回が$14.40です。ラベル付け、評価、モデルの提供、開発の費用は別です。実験がうまくいかなければ、追加のジョブも必要になります。

RAGより適した方法はありますか？

必要な根拠がすべて含まれているなら、プロンプトへ直接渡すほうがシンプルです。安定した振る舞いの問題には、ファインチューニングが役立つ場合があります。ただし、最新かつアクセス権限を満たす情報を探す必要がある場合、どちらも検索の代わりにはなりません。

ファインチューニングしたモデルとRAGの主な違いは何ですか？

ファインチューニングは、学習によって学習済みのパラメーターを変えます。RAGは、リクエスト時に渡す根拠を変えます。情報源のインデックスを更新すること、モデルを再学習すること、回答に妥当な引用があると確認することは、それぞれ別の作業です。

ファインチューニングは効果がないと証明されたのですか？

機械学習モデルを用途に適応させる手法のことなら、そうではありません。価値はタスクによって異なります。学習から除外した例を使い、プロンプトによる基準構成と比較して効果を示す必要があります。

ChatGPTはどのようにファインチューニングされたのですか？

2022年に公開されたOpenAIの最初のChatGPT発表では、教師ありの対話例を使い、その後に人間のフィードバックからの強化学習を行ったと説明されています。この過去の学習プロセスと、現在の企業向けAPIのチューニング利用資格は別の話です。

Stephen Hawkingはファインチューニングについて何と言ったのですか？

それは宇宙論における微調整についての質問であり、同じ言葉でも意味が異なります。言語モデルを用途に合わせる話ではありません。ここで扱っている業務上の判断は検索と学習に関するもので、宇宙についての主張ではありません。

ファインチューニングは今も使われていますか？

はい。Googleの現行ドキュメントには、この記事で使ったGeminiモデルを含む対応モデルが掲載されています。提供状況は変わるため、ジョブの準備前に、対象モデルとアカウントの利用資格を確認してください。

ファインチューニングには、どのモデルが最適ですか？

主要なタスクをすでに処理でき、デプロイの制約も満たす、対応済みのベースモデルを選びます。この記事のGemini 3.1 Flash-Liteは費用計算の例であり、あらゆる用途で最良だと実証したモデルではありません。学習に使っていない評価例で判断してください。

AIを使う開発の実務判断に役立つ情報は、ニュースレターに登録してお受け取りください。