ファインチューニングとRAGの選び方：コスト・精度・用途で比較する実践ガイド

生成AI（Generative AI）を業務に活用する際、「社内データをどう組み込むか」という問いに対して、ファインチューニングとRAG（Retrieval-Augmented Generation）は代表的な2つのアプローチです。前者はLLM（大規模言語モデル）の重みを直接更新して知識を埋め込み、後者は外部ドキュメントをリアルタイムに検索して回答を生成します。

この記事は、AI導入を検討するエンジニア・プロダクトマネージャー・情報システム担当者を対象としています。コスト・精度・更新頻度・セキュリティの4軸で両手法を整理し、自社のユースケースに合った選択ができるよう解説します。

読み終えると、「なぜ組み合わせが有効なのか」「どの条件でどちらを優先すべきか」が具体的に判断できるようになります。

LLMをビジネスで活用する際、「社内知識をどう持たせるか」は避けられない問いです。その答えとして代表的な2つの手法が、ファインチューニングとRAG（Retrieval-Augmented Generation）です。

両者はアプローチが根本的に異なります。ファインチューニングはモデルの重みそのものを更新し、RAGは外部ドキュメントを検索して回答に組み込みます。それぞれに強みと制約があり、用途を誤ると想定外のコストや精度の低下につながるケースが報告されています。

まずは各手法の基本的な仕組みを整理し、選択の土台を作りましょう。

ファインチューニングとは、事前学習済みのベースモデル（Foundation Model）の重みパラメータを、追加データで再学習させることで特定タスクへ適応させる手法です。モデル自体が「知識を内在化」するため、推論時に外部データを参照する必要がありません。

学習の流れ

• 教師データ（入力・出力ペア）を用意する
• 損失関数を最小化しながらパラメータを更新する
• 更新後のモデルをデプロイして推論に使用する

モデルへの影響は大きく2点に現れます。まず出力スタイルの固定化です。法律文書の定型表現や医療カルテの記述形式など、特定の文体・フォーマットを一貫して再現できるようになります。次にドメイン語彙の強化です。業界固有の専門用語やBPEトークナイザー（Byte-Pair Encoding Tokenizer）の語彙にない表現も、学習を通じてモデルが扱いやすくなる傾向があります。

一方で注意すべき制約もあります。

• 学習コストが高い：フルファインチューニングはGPU（Graphics Processing Unit）リソースを大量に消費する
• 知識の鮮度が落ちやすい：学習後に発生した情報はモデルに反映されない
• ハルシネーション（Hallucination）のリスク：学習データに存在しない事実を補完しようとする場合がある

コストを抑える手法としてPEFT（Parameter-Efficient Fine-Tuning）やLoRAが普及しており、全パラメータではなく一部の低ランク行列のみを更新することで、学習コストを大幅に削減できます。ただし、モデルの重みを変更する以上、更新のたびに再学習・再デプロイが必要になる点は変わりません。次のセクションで扱うRAGとの最大の違いは、この「知識がモデル内部に固定される」という特性にあります。

RAG（Retrieval-Augmented Generation）は、LLMが回答を生成する前に外部の知識ソースから関連情報を検索・取得し、その内容をコンテキストとしてプロンプトに組み込む手法です。モデルのパラメータ自体は変更しないため、知識の更新がデータベース側の操作だけで完結します。

処理の基本的な流れ

1. ユーザーの質問をエンベディングに変換する
2. ベクトルデータベースに対して類似度検索を実行し、関連チャンクを取得する
3. 取得した文書をシステムプロンプトまたはコンテキストウィンドウに挿入する
4. LLMが補完された文脈をもとに回答を生成する

この仕組みにより、モデルが学習時点で知らなかった情報でも、ドキュメントさえ登録されていれば回答に反映できます。たとえば、毎月改訂される社内規定や製品マニュアルを対象にする場合、文書を更新するだけでモデルの再学習なしに最新情報を反映できます。

検索精度を高める主な工夫

• ハイブリッド検索：ベクトル検索とBM25（キーワード検索）をRRFで組み合わせ、再現率と精度を両立する
• チャンクサイズの調整：文書の粒度が粗すぎると不要情報が混入し、細かすぎると文脈が失われる
• Agentic RAG：マルチステップ推論で複数回の検索を繰り返し、複雑な質問にも対応する

一方で、RAGはコンテキストウィンドウに収まる情報量に制約があり、検索でヒットしなかった知識は回答に使われません。また、グラウンディングの品質は検索エンジンの設計に大きく依存するため、インデックス設計や前処理の精度が全体の出力品質を左右します。

ファインチューニングとRAGの議論では、「どちらか一方を選ぶ」という二項対立の思い込みが広がりやすい。しかし実際の現場では、両手法を組み合わせるアーキテクチャが有効なケースも多い。

この誤解が生まれる背景には、次のような要因がある。

• 「ファインチューニング＝モデルに知識を焼き込む」という説明が一人歩きし、RAGが不要に見える
• 「RAGで検索すれば何でも答えられる」という期待から、モデル自体のカスタマイズを軽視する
• 導入コストの比較だけで判断し、精度や運用負荷の違いを見落とす

実態はどうか。ファインチューニングは出力スタイルや応答形式の一貫性を高めるのに優れる一方、最新ドキュメントへの追従は苦手だ。RAGはリアルタイムな知識参照に強いが、モデル自体の語彙や文体が業務ドメインに合っていないと、検索結果をうまく活用できないケースがある。

つまり、両者は競合ではなく補完関係にある。

具体的な例として、法律分野のチャットボットを考えてみよう。法律文書特有の文体や出力形式をファインチューニングで習得させつつ、最新の判例や規制改正はRAGで参照する構成が、精度と鮮度を両立しやすい。

次のセクションでは、どちらを優先すべきかを判断するための評価軸を整理する。「何を重視するか」を明確にすることが、最適な手法選択の出発点になる。

ファインチューニングとRAGを公平に比べるには、「どちらが優れているか」という問いを立てるのではなく、評価軸を先に定義することが重要です。

比較に使う軸は主に4つ——コスト・精度・更新頻度・セキュリティです。さらに、ユースケースを「知識注入型」と「スタイル適応型」に分類することで、どちらの手法が本質的に適しているかが見えてきます。

以降のH3では、各軸の定義と具体的な判断基準を順に解説します。

ファインチューニングとRAGを比較する際、「どちらが賢いか」という問いは本質を外している。正しい問いは「自社の制約条件に対してどちらが合理的か」だ。判断を整理するために、以下の4軸で評価することを推奨する。

① コスト

• ファインチューニングは初期学習にGPUリソースが必要で、モデル更新のたびに再学習コストが発生する
• RAGはベクトルデータベースの構築・運用コストが主体で、モデル本体の再学習は不要
• 小規模な適応にはLoRAやQLoRAなどPEFTを使うことで学習コストを大幅に抑えられる傾向がある

② 精度

• ファインチューニングは特定ドメインの文体・語彙・推論パターンを「モデルに焼き込む」ため、出力の一貫性が高い
• RAGは最新ドキュメントを参照できる一方、検索精度が低いとハルシネーションのリスクが残る
• 回答根拠の引用が求められる業務では、RAGのグラウンディング機能が精度担保に有効に働く

③ 更新頻度

• 社内規定や製品マニュアルのように週次・月次で内容が変わるドキュメントは、RAGが圧倒的に扱いやすい
• ファインチューニングは再学習サイクルが長いため、情報鮮度が求められる用途には不向きな傾向がある

④ セキュリティ

• 機密データをクラウドAPIに送信したくない場合、ローカルLLMとオンプレミスのベクトルデータベースを組み合わせるRAG構成が有効
• ファインチューニング済みモデルをオフライン環境に閉じ込める構成も選択肢になるが、モデル更新の運用負荷が増す

この4軸は独立していない。たとえば更新頻度が高いほどファインチューニングのコストは膨らみ、セキュリティ要件が厳しいほど選択肢は絞られる。次のセクションでは、これらの軸をユースケースの類型に当てはめて整理する。

LLMのカスタマイズ手法を選ぶ前に、まず「何を解決したいのか」をユースケースの性質で分類しておくことが重要です。大きく分けると、知識注入型とスタイル適応型の2種類に整理できます。

知識注入型とは、モデルが本来持っていない情報を扱えるようにしたいケースです。

• 社内規定・製品仕様書・法改正情報など、外部から持ち込む必要がある知識
• 学習データのカットオフ以降に発生した最新情報
• 特定企業・業界固有のデータ（例：独自の商品コード体系、社内用語集）

このタイプには、RAGが適している傾向があります。ドキュメントをベクトルデータベースに格納し、クエリに応じて動的に検索・参照するため、情報の追加・更新が即時に反映されます。ファインチューニングで知識を「焼き込む」アプローチは、情報が陳腐化するたびに再学習が必要になるため、更新コストが高くなりがちです。

スタイル適応型とは、モデルの出力形式・文体・応答パターンを特定の基準に揃えたいケースです。

• 医療レポートや法律文書など、定型フォーマットで出力させたい
• ブランドのトーン・オブ・ボイスに沿った文章生成
• 特定言語（タイ語・日本語など）での自然な表現精度を高めたい

このタイプにはファインチューニングが向いています。モデルの重みに直接「振る舞いのパターン」を学習させるため、プロンプトで毎回細かく指示しなくても安定した出力が得られます。

実務では、この2分類が混在するケースも多くあります。「社内用語を正確に使いながら、特定フォーマットで回答させたい」といった要件は、組み合わせアプローチが有効です。次のセクションでは、コスト・精度・更新頻度の観点から3つの選択肢を比較します。

前節で定義した評価軸をもとに、ファインチューニング・RAG・組み合わせアプローチの3択を横断比較します。

比較ポイントは大きく3つです。

• コスト：学習費・推論費・運用費の総合負担
• 精度とハルシネーション：回答品質と誤情報リスクの傾向
• データ更新のしやすさ：情報の鮮度を保つための運用コスト

各軸の詳細は以降のH3で掘り下げます。まず全体像を把握したうえで、自社のユースケースに照らし合わせてください。

ファインチューニングとRAGでは、コスト構造が根本的に異なる。3つのフェーズに分けて整理すると判断しやすい。

学習費（初期投資）

• ファインチューニング：GPU時間が主なコスト。フルファインチューニングは高額になる傾向があるが、LoRAやQLoRAなどPEFT手法を使うと学習パラメータを絞れるため、コストを大幅に抑えられるケースが報告されている
• RAG：モデル自体の学習は不要。ただし、ドキュメントのエンベディング生成とベクトルデータベースの初期構築にコストが発生する

推論費（実行時コスト）

• ファインチューニング済みモデル：コンテキストウィンドウに大量のドキュメントを詰め込む必要がないため、1リクエストあたりのトークン消費が少なくなる傾向がある
• RAG：検索クエリの発行＋取得チャンクのコンテキスト挿入が加わるため、1回の推論でトークン数が増えやすい。特に複数ドキュメントを参照する場合は注意が必要

運用費（継続コスト）

• ファインチューニング：知識が古くなるたびに再学習が必要。更新頻度が高いデータを扱う場合、再学習コストが積み重なりやすい
• RAG：ベクトルデータベースの更新とストレージ費が主な継続コスト。ドキュメントを差し替えるだけで知識を更新できるため、運用コストは比較的予測しやすい

コスト面での大まかな傾向まとめ

初期投資を抑えてすぐに試したい場合はRAGが有利。一方、推論回数が非常に多いプロダクション環境では、ファインチューニングの推論コスト優位性が効いてくる。なお、価格は執筆時点の参考傾向であり、最新の料金は各クラウドプロバイダーの公式ページで確認することを推奨する。

精度とハルシネーション率は、手法の選択に直結する重要な評価軸だ。ファインチューニングとRAGでは、それぞれ異なるメカニズムで誤りが生じる傾向がある。

ファインチューニングの精度特性

• 学習データが高品質かつ十分な量であれば、特定タスクの出力形式や専門用語への適応精度は高まる傾向がある
• 一方で、学習データに含まれない最新情報や未知のトピックに対しては、自信を持って誤った回答を生成するハルシネーションが起きやすい
• 学習データのバイアスや誤りがそのままモデルに刷り込まれるリスクもある

RAGの精度特性

• 検索で取得したドキュメントを根拠として回答を生成するため、情報の出どころが明確になりやすい
• ただし、検索精度が低い場合（関連性の低いチャンクを取得した場合）は、誤った文脈に基づいた回答が生成される「グラウンディング失敗」が発生しやすい
• BM25やベクトルデータベースを組み合わせたハイブリッド検索を用いることで、検索精度を改善できるケースが報告されている

ハルシネーション率の傾向まとめ

どちらの手法もハルシネーションをゼロにはできない。重要なのは、誤りが発生する原因を把握し、ガードレールや人間によるHITL（Human-in-the-Loop）レビューを組み合わせて対策することだ。

データ更新のしやすさは、ファインチューニングとRAGの間で最も差が出る評価軸のひとつです。

ファインチューニング：更新コストが高く、即時性に難あり

ファインチューニングは、新しい知識を反映するたびに再学習が必要です。主な課題を整理します。

• 再学習には追加のGPUリソースと時間が必要
• 学習データの整備・検証・デプロイまでのリードタイムが長い
• 更新頻度が高いほど運用コストが累積しやすい

たとえば、週次で改訂される社内規定や製品価格表をファインチューニングで管理しようとすると、更新のたびに学習パイプラインを回す必要が生じます。この運用負担は、情報の鮮度を保つうえで現実的な障壁になりやすい傾向があります。

RAG：ドキュメント差し替えだけで即時反映

RAGはベクトルデータベースに格納したドキュメントを検索して回答を生成するため、情報の更新はインデックスの再構築で完結します。

• 新ドキュメントを追加・上書きするだけで最新情報が反映される
• モデル本体の再学習は不要
• 更新から回答反映までのリードタイムを大幅に短縮できる

社内マニュアルの改訂や法令変更への対応など、「今日更新して明日から使いたい」という要件にはRAGが適しています。

組み合わせる場合の考え方

ファインチューニングで出力スタイルや業界用語の理解を固め、頻繁に変わる情報はRAGで補完するアーキテクチャが、更新コストと精度のバランスを取りやすい設計です。次のセクションでは、ファインチューニング単体が特に効果を発揮するユースケースを掘り下げます。

ファインチューニングが真価を発揮するのは、「モデルの振る舞い自体を変えたい」場面です。知識を外部から注入するRAGとは異なり、モデルの重みを直接更新するため、出力スタイルや応答形式の一貫性が求められる用途に適しています。特に専門用語が多い業界や、特定のトーンを維持したい業務での活用が報告されています。以下のH3では、具体的なユースケースと実装手法を掘り下げます。

ファインチューニングが最も力を発揮するのは、出力のスタイルや形式を固定したい場面です。RAGは「何を答えるか」の精度を高めますが、「どう答えるか」を統一する力は限定的です。

たとえば以下のようなケースで、ファインチューニングの優位性が報告されています。

• 医療・製薬: カルテ要約や治験報告書など、特定の章立て・用語規則に沿った出力が必要
• 法務: 契約書レビューで「リスク項目→根拠条文→対応案」という固定フォーマットを要求される
• 金融: 投資レポートでの断定表現の回避や免責文言の自動付与
• 製造業: 障害報告書の「現象・原因・対策」三段構成の徹底

これらは、システムプロンプトで指示するだけでは安定しない傾向があります。プロンプトが長くなるほどコンテキストウィンドウを消費し、推論コストも増加するためです。

ファインチューニングによってモデルの重みに「業界の書き方のルール」を焼き込むと、短いプロンプトでも一貫したフォーマットが維持されやすくなります。出力のばらつきが減ることで、後工程の品質チェックやRPAとの連携も安定する傾向があります。

ただし注意点もあります。

• 学習データの品質が低いと、誤った文体パターンが固定されるリスクがある
• 出力形式の仕様が変わるたびに再学習コストが発生する
• 知識の最新性はRAGほど担保できない

「形式の一貫性」を最優先とする業務では、ファインチューニングを選択肢の筆頭に置くことが合理的です。

フルファインチューニングはモデル全パラメータを更新するため、GPU費用と学習時間が大きな障壁になりやすい。そこで注目されるのが**PEFT（Parameter-Efficient Fine-Tuning）と、その代表的手法であるLoRA（Low-Rank Adaptation）**だ。

LoRAの仕組みと利点

LoRAは、元のモデルパラメータを凍結したまま、低ランクの行列を追加して差分だけを学習する手法。更新対象が全体の1〜5%程度に絞られるため、以下のメリットが生まれる。

• 学習に必要なGPUメモリを大幅に削減できる
• 学習時間が短縮され、クラウドコストを抑えやすい
• 元のベースモデルを保持したまま、複数のLoRAアダプタを差し替え可能

QLoRAによるさらなる軽量化

QLoRAはLoRAに量子化（Quantization）を組み合わせた手法で、4ビット精度でモデルをロードしながら学習できる。コンシューマー向けGPU1枚でも数十億パラメータ規模のモデルを適応できるケースが報告されており、オンプレミス環境やローカルLLMへの適用にも有効な選択肢となっている。

実践上の注意点

• データ量の目安：数百〜数千件の高品質な学習サンプルから効果が出る傾向がある
• ランク数（r）の設定：rが小さいほど軽量だが表現力が下がるため、タスク複雑度に応じて調整が必要
• 過学習リスク：データ量が少ない場合は検証セットでの評価を欠かさないこと

PEFTやLoRAは「フルファインチューニングは費用的に難しい」という組織でも、スタイル適応や専門用語の定着を実現できる現実的な入口となる。まずPoC規模で試し、精度と費用のバランスを確認してから本番展開を検討する進め方が堅実だ。

RAGが真価を発揮するのは、「情報の鮮度」と「根拠の透明性」が求められる場面です。ファインチューニングがモデルの振る舞いそのものを変えるのに対し、RAGは外部ドキュメントをリアルタイムで参照するため、データが頻繁に変わる業務や、回答の出典を明示しなければならない業務に適しています。次の2つのユースケースを中心に、RAGを選ぶ判断基準を整理します。

社内規定や製品マニュアルのように更新頻度が高いドキュメントを扱う場合、RAGは特に強みを発揮します。ファインチューニングでは再学習のたびにGPU費用と時間が発生しますが、RAGはベクトルデータベースのインデックスを差し替えるだけで最新情報を即時反映できます。

RAGが適している主な理由

• 規定改訂・価格改定・製品仕様変更など、月次・週次レベルで内容が変わるドキュメントに対応しやすい
• 回答生成時に参照チャンクを明示できるため、「どの文書の何ページに基づく回答か」をユーザーが確認しやすい
• ベースモデル（Foundation Model）はそのまま使いまわせるため、複数部門のドキュメントを追加しても追加学習コストが生じない

具体的な活用パターン

たとえば製造業の現場では、製品マニュアルのバージョンが頻繁に更新される傾向があります。新バージョンのPDFをチャンク分割してベクトルデータベースに登録し直すだけで、AIチャットボットが最新手順を案内できる状態になります。人事部門の社内規定運用でも、就業規則の改訂内容をインデックスに追加すれば、従業員の問い合わせ対応を即座に最新化できます。

注意点

ただし、検索精度はチャンクサイズやエンベディングモデルの品質に左右されます。ドキュメントの構造が複雑な場合は、ハイブリッド検索（BM25＋Dense Model）を組み合わせると精度が向上するケースが報告されています。次のセクションで扱う法務・コンプライアンス用途では、この出典明示の特性がさらに重要な役割を果たします。

法務・医療・コンプライアンス領域では、「なぜその回答が正しいのか」を示す根拠の透明性が不可欠です。RAGはこの要件に対して構造的な強みを持ちます。

RAGが引用・出典管理に優れる理由

• 回答生成時に参照した原文ドキュメントをそのままユーザーへ提示できる
• 「どの規定の第何条に基づくか」を明示しやすく、監査対応にも活用しやすい
• ドキュメントが更新されれば、ベクトルデータベースの差し替えだけで回答内容も追従する

法務部門を例にとると、契約審査や社内規程の照会では、AIが生成した文章の根拠条文をその場で確認できないと実務での採用が難しくなります。RAGであれば検索結果のチャンクをそのまま引用として付与できるため、担当者が原文に戻って確認する手間を大幅に減らせる傾向があります。

医療分野では、診療ガイドラインや添付文書を参照させることで、ハルシネーションのリスクを抑えながら根拠付きの情報提供が可能です。ただし医療行為の判断への直接適用は別途専門的な検討が必要であり、AIはあくまで情報参照の補助に留める設計が推奨されます。

コンプライアンス用途では、EU AI ActやPDPAなどの規制文書を定期的にインデックス更新することで、法改正への対応コストを抑えられるケースが報告されています。

ファインチューニングとの役割分担

ファインチューニングは文体や出力形式の統一には有効ですが、「この回答の根拠はどこか」という問いには答えにくい構造です。引用・出典の透明性が求められる業務では、RAGを軸に設計することが適切な選択といえます。

ファインチューニングとRAGは「どちらか一方」ではなく、組み合わせることで互いの弱点を補える設計が可能です。ファインチューニングでモデルに専門的な文体や推論パターンを習得させつつ、RAGで最新情報を動的に供給する構成は、精度と鮮度を両立する有力な選択肢です。以下の各H3では、具体的なアーキテクチャ設計とAgentic RAGとの組み合わせ方を解説します。

ファインチューニング済みモデルとRAGを組み合わせる設計は、両者の弱点を相互補完できる点で注目されています。基本的な考え方は「モデルの振る舞いをファインチューニングで固め、知識の鮮度はRAGで担保する」という役割分担です。

アーキテクチャの基本構成

• ファインチューニング層：業界特有のトーン・出力フォーマット・専門用語の扱いをモデルに学習させる
• RAG層：最新の社内規定や製品情報をベクトルデータベースから動的に取得し、コンテキストウィンドウへ注入する
• システムプロンプト層：両者をつなぐ役割として、検索結果をどう使うかの指示を記述する

この構成では、ファインチューニングが「どう答えるか」を担い、RAGが「何を答えるか」を担うため、責務が明確に分離されます。

設計上の注意点

ファインチューニング済みモデルにRAGを乗せる際、検索結果とモデルの学習知識が矛盾するケースが発生することがあります。この場合、システムプロンプトで「検索結果を優先する」と明示することで、ハルシネーションのリスクを抑えられる傾向があります。

また、チャンクサイズの設計も重要です。ファインチューニングで長文出力に慣らしたモデルに対して、短すぎるチャンクを渡すと文脈が途切れ、精度が低下するケースが報告されています。チャンクサイズはモデルの出力スタイルに合わせて調整することが推奨されます。

PoC段階では、まずベースモデル＋RAGで精度を確認し、それでも出力品質が不十分な場合にPEFTやLoRAによるファインチューニングを追加する順序が、コスト管理の観点から合理的です。

Agentic RAGは、RAGの検索ステップをAIエージェントが自律的に制御するアーキテクチャです。従来の静的RAGが「1回の検索→回答生成」という固定フローだったのに対し、Agentic RAGでは複数回の検索・判断・再検索をエージェントが動的に繰り返します。

ファインチューニング済みモデルとAgentic RAGを組み合わせると、次のような役割分担が生まれます。

• ファインチューニング済みモデル：業界特有の文体・出力フォーマット・専門用語を担当
• エージェント層：クエリの分解、検索ツールの呼び出し順序の決定、結果の評価を担当
• ベクトルデータベース：最新ドキュメントの格納と類似検索を担当

たとえば法務レビュー業務では、契約書の条項ごとにクエリを分解し、社内規定データベースと判例データベースを順番に検索したうえで、ファインチューニング済みモデルが法務部門の定型フォーマットで回答を生成する、というフローが構築できます。

この設計の主なメリットは以下の通りです。

• マルチステップ推論に対応できるため、複雑な質問への回答精度が向上する傾向がある
• 検索結果が不十分な場合に再検索を自動実行するため、ハルシネーションを抑制しやすい
• ドキュメントが更新されてもエージェント層の再設計は不要で、ベクトルデータベースの更新だけで対応できる

一方で、エージェントオーケストレーションの設計・テストコストが増加する点には注意が必要です。PoC段階では静的RAGから始め、複雑なクエリへの対応が必要になった時点でAgentic RAGへ移行するステップアップが現実的です。

ここまでの比較を踏まえ、自社の状況に合った手法を素早く絞り込むための判断軸を整理します。

選択に迷う主な原因は、予算・データ量・更新頻度という3つの変数が同時に絡み合うことです。以降の H3 では、この3ステップを順に確認するフローと、多言語環境での追加考慮点を解説します。

手法選択に迷ったとき、以下の3ステップで判断すると整理しやすい。

ステップ1：予算を確認する

GPUクラウド費用やAPI課金など、初期投資と運用費を分けて見積もる。

• ファインチューニングは学習時に一定のGPU費用が発生するが、推論は通常のLLMと同等
• RAGはベクトルデータベースの維持費と検索API費用が主なランニングコストになる
• 予算が限られる場合は、LoRAやQLoRAを用いたPEFTで学習コストを抑える選択肢も検討できる

ステップ2：利用可能なデータ量を確認する

手元にあるデータの「量」と「質」の両面を評価する。

• 高品質な教師ありデータが数百〜数千件以上確保できる場合は、ファインチューニングの効果が出やすい傾向がある
• 既存ドキュメントが主体で構造化が難しい場合は、RAGのほうが早期に導入できるケースが多い
• データ量が少ない段階では、まずRAGでPoC（概念実証）を行い、効果を確認してからファインチューニングを検討する順序が合理的

ステップ3：更新頻度を確認する

情報の鮮度要件が手法選択に直結する。

• 週次・月次でドキュメントが更新される業務（社内規定・製品仕様など）はRAGが適している。インデックス再構築だけで対応できるためだ
• 一方、出力スタイルや業界固有の表現パターンは更新頻度が低いため、ファインチューニングで一度定着させると安定した品質を維持しやすい
• 更新頻度が「高い」かつ「根拠の引用が必要」な場合は、組み合わせアプローチが現実的な選択肢となる

3ステップを経ても判断が難しい場合は、次セクションで解説する多言語環境の追加考慮点も合わせて確認してほしい。

タイ語と日本語を同時に扱う環境では、単純なファインチューニング vs RAGの選択に加えて、言語固有の技術的ハードルを考慮する必要がある。

トークナイザーの問題

BPEトークナイザーは英語を前提に設計されたものが多く、タイ語・日本語では1文字あたりのトークン消費量が英語の数倍になる傾向がある。これはコスト試算に直接影響するため、事前に各言語のトークン数を実測しておくことが重要だ。

ファインチューニング時の注意点

• 学習データは各言語で均等なサンプル数を確保しないと、片方の言語の品質が極端に低下しやすい
• タイ語は単語間にスペースがないため、チャンク分割の境界設定が難しく、RAGのチャンクサイズ設計に専用ロジックが必要になるケースがある
• 日本語は敬語・文体の揺れが大きく、スタイル統一を目的とするならファインチューニングの効果が出やすい

RAG設計時の注意点

• エンベディングモデルの多言語対応品質はモデルによって大きく異なる。タイ語の意味検索精度を担保するには、マルチリンガルNLPに対応したモデルを選定し、実測で精度を確認することが望ましい
• ハイブリッド検索（BM25＋ベクトル検索）を採用する場合、BM25の形態素解析器がタイ語・日本語に対応しているかを必ず確認する

実務上の判断基準

タイ語・日本語の両方を高品質に処理したい場合、ベースモデルの多言語能力が高いモデルを選んだうえでRAGを構築するアプローチが、ファインチューニングの言語バランス調整コストを回避できる点で現実的な選択肢になりやすい。

ファインチューニングとRAGの導入を検討する際、現場からは共通した疑問が繰り返し上がります。このセクションでは、特に問い合わせの多い「必要データ量」と「ローカルLLMとの組み合わせ可否」の2点を取り上げます。選定判断の最終確認として、自社の状況と照らし合わせながら読んでみてください。

「データが少ないからファインチューニングは無理」と諦めているケースは多いが、実際には手法とモデル規模によって必要量は大きく異なる。

フルファインチューニングの場合

• 一般的に数千〜数万件の高品質な学習サンプルが目安とされる
• データが少ないほど過学習のリスクが高まり、汎用性が損なわれる傾向がある
• 大規模モデルほど必要データ量が増えるため、GPU コストとのトレードオフを検討する必要がある

PEFT / LoRA を使う場合

• 数百〜数千件程度でも一定の効果が報告されているケースがある
• LoRA はモデルの重みの一部のみを更新するため、少ないデータでも過学習を抑えやすい
• QLoRA を使えばメモリ消費をさらに抑えられ、手元の GPU でも試しやすくなる

データ品質はデータ量より優先度が高い点も見落とせない。ノイズの多い 1 万件より、丁寧にラベリングされた 500 件のほうが成果につながるケースは珍しくない。

一方、データが 100 件未満の段階では RAG の検討を先行させるのが現実的な判断軸になる。ドキュメントをベクトルデータベースに格納するだけで即座に知識を参照できるため、データ収集コストを抑えながら早期に価値を出せる。

まず少量データで PoC を行い、精度が要件を満たさない場合にファインチューニングへ移行するという段階的アプローチが、リスクを最小化しやすい。

結論から言えば、ローカルLLMでもファインチューニングとRAGの組み合わせは十分に実現できます。クラウドAPIに依存しないため、機密データを外部送信したくない企業にとって特に有効な選択肢です。

ローカル環境で組み合わせる主な構成例

• ベースモデル: LlamaやMistralなどのオープンウェイトモデルをQLoRAでファインチューニング
• ベクトルデータベース: ChromaやWeaviateをオンプレミスで構築
• エンベディングモデル: BGEやE5などのローカル動作モデルで文書をベクトル化
• 推論サーバー: OllamaやvLLMでAPIエンドポイントを立てる

この構成により、社内ネットワーク内で完結したRAGパイプラインが実現します。

注意すべきポイント

• GPUメモリの制約が大きく、7Bパラメータ前後のモデルが現実的な選択になるケースが多い
• ファインチューニング後のモデルとエンベディングモデルの言語対応を揃えないと、日本語やタイ語での検索精度が落ちる傾向がある
• 量子化（Quantization）でモデルサイズを圧縮できるが、精度とのトレードオフを検証する必要がある

コスト面での現実

クラウドと比べてAPI費用はかかりませんが、GPU調達・電力・保守の固定費が発生します。利用頻度が高い業務であれば長期的にコストメリットが出やすく、逆に利用頻度が低い場合はクラウドの方が割安になるケースも報告されています。

ローカルLLMでの組み合わせ構成は技術的ハードルが高めですが、データ主権やセキュリティ要件が厳しい環境では有力な選択肢です。まずPoC規模で検証し、運用コストと精度のバランスを確認することをお勧めします。

ファインチューニングとRAGは、どちらが優れているという二項対立ではなく、「何を解決したいか」によって使い分ける補完関係にあります。記事全体を通じた比較を振り返り、判断の軸を整理しましょう。

ファインチューニングが適しているケース：

• 出力の文体・フォーマットを業界水準に揃えたい
• 推論時に外部検索が不要な、閉じた知識体系を扱う
• PEFTやLoRAで学習コストを抑えられる環境がある

RAGが適しているケース：

• 社内規定や製品マニュアルなど、ドキュメントが頻繁に更新される
• 法務・医療など、回答の出典・根拠を明示する必要がある
• 初期投資を最小化してPoC段階から始めたい

組み合わせが有効なケース：

• ドメイン特化の表現力とリアルタイム情報検索の両方が求められる
• Agentic RAGで動的な多段階推論が必要な業務フロー

意思決定の出発点は「データの更新頻度」と「予算規模」の2軸です。更新が月次以上の頻度で発生するならRAGが現実的な選択肢となり、文体や出力形式の一貫性が最優先ならファインチューニングに軍配が上がる傾向があります。

どちらの手法も、ハルシネーションのリスクをゼロにはできません。ガードレールやHITLの設計を並行して進めることが、本番運用の品質を左右します。まずは小規模なPoCで仮説を検証し、実測値をもとに拡張判断を行うアプローチが、リスクを抑えながら成果を積み上げる現実的な道筋です。