RAGか、ファインチューニングか。それともハイブリッドか。
企業がLLMを導入しようとすると、かなり早い段階でぶつかる問いがあります。
「うちはRAGでいいのか？」
「ファインチューニングまでやるべきなのか？」
「結局、どちらが安くて、どちらが精度が出るのか？」
この問いは、一見すると技術選定の話に見えます。
しかし実際には、もっと経営寄りの問いです。
企業の知識を、どこに持たせるのか。
業務ルールを、どこで管理するのか。
AIの振る舞いを、どこまで固定化するのか。
そして、運用コストと品質責任を誰が持つのか。
つまり、RAGとファインチューニングの選択は、単なるAI機能の実装方式ではなく、企業の知識管理と業務設計そのものに関わる判断です。
2026年時点では、「RAGかファインチューニングか」という二択で考える段階は、すでに少し古くなっています。実務的には、まずRAGで始め、必要に応じてファインチューニングや小型モデル最適化を組み合わせるハイブリッド構成が現実的な選択肢になっています。
まず押さえるべき基本原則
LLM導入を考えるとき、最初に分けるべきなのは「知識」と「振る舞い」です。
変わる知識はRAGで扱う
社内規程、商品マニュアル、価格表、契約条件、FAQ、過去の問い合わせ履歴、技術資料、法務文書などは、頻繁に更新されます。
こうした情報をモデル自体に覚え込ませてしまうと、更新のたびに再学習や再評価が必要になります。これは運用上かなり重い。
そのため、変化する情報は外部データベースやドキュメントストアに置き、必要なときに検索してLLMに渡す。これがRAGの基本的な考え方です。Google CloudもRAGについて、検索システムやデータベースとLLMを組み合わせることで、より正確で最新性のある回答を実現する枠組みとして説明しています。
安定させたい振る舞いはファインチューニングで扱う
一方で、毎回同じように守ってほしい応答スタイル、文章の型、専門用語の使い方、分類ルール、出力フォーマットなどは、RAGだけでは安定しにくいことがあります。
たとえば、次のようなものです。
- 問い合わせ回答のブランドトーン
- 営業メールの文体
- 業界特有の用語変換
- 問い合わせ種別の分類
- JSON形式での安定出力
- 社内文書の要約ルール
- コンプライアンス上、避けるべき表現
こうした「振る舞いの癖」をモデルに覚えさせたい場合、ファインチューニングが有効になります。OpenAIの公式ドキュメントでも、教師ありファインチューニングは、特定ユースケースに対して望ましいスタイルや内容をより安定して出すための方法として説明されています。
AIおじさん的に言えば、RAGは「資料室」、ファインチューニングは「社員教育」に近いです。
資料室を整備すれば、最新の情報を参照できる。
社員教育をすれば、同じ資料を読んだときの受け答えが安定する。
この2つは競合するものではありません。役割が違うのです。
RAGだけでは足りない理由
数年前までは、「社内文書をベクトルDBに入れれば、社内AIができる」という期待がかなりありました。
もちろん、RAGは強力です。
特に、社内FAQ、規程検索、マニュアル検索、営業資料検索のような用途では、最初に検討すべき構成です。
しかし、実務で使うとすぐに問題が出ます。
検索された文書の一部だけでは文脈が足りない。
似たような資料が複数あり、どれを優先すべきかわからない。
古い規程と新しい規程が混在する。
検索は当たっているのに、回答のまとめ方が業務に合わない。
根拠は出ているが、現場で使える文章になっていない。
RAGの難しさは、単に「検索できるか」ではありません。
本当に難しいのは、検索された情報を、業務上正しい文脈で使えるかどうかです。
この弱点に対して、2024年にAnthropicが発表した「Contextual Retrieval」は重要な示唆を与えました。Anthropicは、RAGで文書を小さなチャンクに分けると文脈が失われやすいという課題に対し、各チャンクに文書全体の中での位置づけを付与してから検索に使う方法を紹介しています。
これは、企業RAGにとってかなり実務的な話です。
たとえば、ある就業規則の一文だけを取り出しても、それが「正社員向け」なのか「契約社員向け」なのか、「国内拠点向け」なのか「海外拠点向け」なのかがわからなければ、誤回答につながります。
つまり、RAGの品質は、ベクトルDBを入れるだけでは決まりません。
- 文書の分割方法
- メタデータ設計
- バージョン管理
- 権限管理
- 検索順位
- 回答時の引用ルール
- 古い情報の除外
- チャンクに文脈を持たせる工夫
ここまで含めて、初めて企業向けRAGになります。
ファインチューニングだけでも足りない理由
では、ファインチューニングすれば全部解決するのか。
これも違います。
ファインチューニングは、モデルの振る舞いを安定させるには有効です。
ただし、最新の社内情報を常に反映する用途には向いていません。
たとえば、料金プラン、契約条件、在庫状況、法改正、社内規程、製品仕様などをモデルに覚えさせようとすると、更新のたびに再学習や検証が必要になります。
これは非常に危険です。
なぜなら、モデルが「古い情報を自信満々に答える」可能性があるからです。
企業利用で怖いのは、AIがわからないと言うことではありません。
むしろ怖いのは、間違ったことを自然な日本語で断言することです。
したがって、ファインチューニングは「知識の保管庫」として使うよりも、「出力の型」「判断の癖」「業務上の応答パターン」を安定させるために使うべきです。
Google CloudのVertex AIのドキュメントでも、教師ありファインチューニングは、分類、感情分析、エンティティ抽出、比較的複雑でない要約、ドメイン固有クエリの作成など、出力が定義しやすい用途に向いていると説明されています。
ここが重要です。
ファインチューニングは、何でも知っている社員を作る技術ではありません。
むしろ、決まった業務を安定してこなす専門スタッフを育てる技術に近い。
企業向けLLM導入の判断フロー
ここからは、実際に企業がLLM導入を検討するときの判断フローを整理します。
Step 1：扱う情報は頻繁に更新されるか？
まず見るべきは、情報の更新頻度です。
社内規程、製品マニュアル、価格表、FAQ、契約条件、過去事例、ナレッジベースのように頻繁に更新される情報を扱うなら、RAGはほぼ必須です。
この場合、モデルに知識を覚えさせるのではなく、最新の情報を取りに行かせる設計にします。
該当するユースケースは次のようなものです。
- 社内FAQ
- 規程検索
- 営業資料検索
- 製品マニュアル検索
- カスタマーサポートの回答支援
- 技術文書検索
- 法務・契約書レビュー支援
- 過去問い合わせの参照
ここで重要なのは、「RAGを入れれば正確になる」ではなく、「正しい情報源を管理できる状態にする」ということです。
RAG導入の成否は、AIモデルよりも、社内文書の整理状態に左右されることが多いです。
PDFが散らばっている。
最新版がどれかわからない。
部署ごとに違う資料を使っている。
ファイル名に日付が入っていない。
権限管理が曖昧。
この状態でRAGを組んでも、AIは混乱します。
AI導入プロジェクトのつもりが、実際にはナレッジ整理プロジェクトになる。
これは企業LLM導入で非常によく起きることです。
Step 2：応答スタイルや業務ルールを安定させたいか？
次に見るべきは、AIに「どう答えてほしいか」です。
同じ質問に対して、毎回トーンが違う。
出力フォーマットが崩れる。
専門用語の使い方が揺れる。
回答が丁寧すぎたり、逆にカジュアルすぎたりする。
社内ルール上、避けるべき表現を使ってしまう。
こうした問題がある場合、プロンプトだけで粘るよりも、ファインチューニングやFew-shot設計、あるいは小型モデルの最適化を検討すべきです。
特にカスタマーサポートや営業支援では、単に正しい情報を出すだけでは不十分です。
企業としての言い回し、謝罪のトーン、断り方、提案の仕方、エスカレーションの基準が重要になります。
ここはRAGだけでは弱い。
RAGは資料を持ってくるのは得意ですが、その会社らしい言い方を毎回安定して再現するのは別問題です。
Step 3：月間クエリ数はどの程度か？
次に、コストとスケールの問題です。
PoC段階では、高性能な大規模モデルを使ってもコストは大きな問題にならないことが多いです。
しかし、本番運用で月間数十万件、数百万件のリクエストが発生する場合、話は変わります。
RAGは、検索処理、埋め込み、再ランキング、長いコンテキスト投入などが必要になるため、構成によっては推論コストが膨らみます。
一方で、特定の業務に絞ったファインチューニング済み小型モデルを使えば、1件あたりのコストやレイテンシを抑えられる場合があります。OpenAIのモデル最適化ドキュメントでも、ユースケースによってはファインチューニングが望ましい場合があり、学習や利用料金は別途課金設計されることが示されています。
ただし、ここで注意したいのは、コスト比較は単純なAPI単価だけでは決まらないということです。
見るべきなのは、次のような総コストです。
- 推論コスト
- 検索基盤のコスト
- ベクトルDBの運用コスト
- データ整備コスト
- 評価データ作成コスト
- 再学習コスト
- 監査・ログ管理コスト
- 人間によるレビューコスト
- 誤回答時の業務リスク
AIおじさん的に言うと、AIのコストは「API料金」ではなく「業務フロー全体の摩擦」で見た方がいいです。
安いモデルを使っても、人間の確認作業が増えるなら高くつきます。
高いモデルを使っても、業務時間を大きく削減できるなら安い場合があります。
Step 4：説明責任や根拠提示が必要か？
企業利用では、回答の正しさだけでなく、「なぜその回答になったのか」が重要です。
特に、法務、医療、金融、製造、公共、インフラ、採用、人事評価などでは、AIが出した答えに根拠が求められます。
この場合、RAGは強力です。
なぜなら、回答に参照元文書を紐づけられるからです。
「この回答は、どの規程のどの箇所に基づいているのか」
「どのマニュアルのどの版を参照したのか」
「古い資料ではなく最新版を見ているのか」
これを追跡できることは、企業にとって非常に大きな意味があります。
一方、ファインチューニングだけで回答させると、根拠の追跡が難しくなります。
モデルの中に学習された知識は、明示的な引用元として取り出しにくいからです。
したがって、説明責任が重要な用途では、RAGを中心に置き、必要に応じてファインチューニングで出力形式や判断パターンを整える構成が現実的です。
Step 5：PoC用のデータはすでにあるか？
最後に、PoCをすぐに始められるかを確認します。
LLM導入でよくある失敗は、最初から大きな構想を描きすぎることです。
全社ナレッジ基盤を作る。
全部署の問い合わせをAI化する。
社内文書を全部読ませる。
AIエージェントで業務を自動化する。
方向性としては悪くありません。
しかし、最初から広げすぎると、ほぼ確実に失敗します。
最初にやるべきなのは、業務範囲を絞った小さなPoCです。
たとえば、以下のような単位です。
- 特定部署のFAQ 100件
- 製品マニュアル10本
- 過去問い合わせ500件
- 営業メールの成功パターン100件
- 契約レビューのチェックリスト50項目
- 社内規程のうち人事関連だけ
このくらいの範囲で、まず評価できる状態を作る。
PoCでは、単に「動いた」では不十分です。
事前に成功基準を決める必要があります。
- 正答率
- 引用の正確性
- 回答スピード
- 人間の修正時間
- エスカレーション率
- ユーザー満足度
- 誤回答率
- 運用コスト
- セキュリティ要件
- 現場担当者の受容度
AI導入のPoCは、技術デモではありません。
本番運用に進むべきかを判断するための実験です。
ユースケース別のおすすめ構成
社内FAQ・規程検索
基本はRAGです。
情報が更新されるため、ファインチューニングで覚えさせるべきではありません。
最新版の規程やFAQを検索し、回答には必ず参照元を付ける構成が望ましいです。
ただし、回答フォーマットを統一したい場合は、プロンプトテンプレートや軽いファインチューニングを組み合わせる価値があります。
おすすめ構成は、RAG中心です。
カスタマーサポート
カスタマーサポートは、RAGとファインチューニングのハイブリッドが向いています。
製品情報、FAQ、規約、トラブルシューティング手順はRAGで参照する。
一方で、謝罪の仕方、ブランドトーン、問い合わせ分類、エスカレーション基準はファインチューニングやルール設計で安定させる。
この領域では、単に正しい回答を出すだけでなく、「顧客にどう伝えるか」が重要です。
おすすめ構成は、RAG＋ファインチューニングです。
営業支援・提案書作成
営業支援では、RAGがかなり有効です。
過去提案書、導入事例、業界別資料、価格表、競合比較、顧客情報などを参照できるからです。
ただし、提案書の構成、言い回し、会社としてのトーン、訴求ポイントの出し方を安定させたい場合は、ファインチューニングやテンプレート設計も有効です。
おすすめ構成は、RAG＋テンプレート＋必要に応じたファインチューニングです。
文書分類・問い合わせ分類
分類タスクは、ファインチューニングと相性が良い領域です。
問い合わせ内容をカテゴリ分けする。
優先度を判定する。
担当部署を振り分ける。
リスクレベルを判定する。
こうしたタスクは、出力が比較的明確で、正解データを作りやすい。
Google Cloudも、教師ありファインチューニングが分類やエンティティ抽出などに向いていると説明しています。
おすすめ構成は、ファインチューニング中心です。
法務・契約書レビュー
法務領域では、RAGが中心になります。
根拠文書や条項、過去の契約例を参照できることが重要だからです。
ファインチューニングだけで回答させると、根拠の追跡が難しくなります。
ただし、レビュー観点やリスク分類、コメントの書き方を安定させるために、ファインチューニングや評価用プロンプトを組み合わせる価値はあります。
おすすめ構成は、RAG＋厳格な引用＋人間レビューです。
製造業・技術サポート
製造業では、RAGだけではなく、かなり丁寧なデータ設計が必要になります。
図面、仕様書、部品表、トラブル履歴、保守記録、マニュアル、過去QAなど、情報の粒度も形式もバラバラだからです。
この場合、単純なRAGではなく、メタデータ設計、文書構造化、権限管理、検索順位調整が重要になります。
また、専門用語や回答パターンを安定させるために、ファインチューニングやドメイン適応を組み合わせる余地があります。
おすすめ構成は、高度なRAG＋必要に応じたファインチューニングです。
AIおじさんの視点：RAGかFTかではなく、会社の知識をどう設計するか
ここで、AIおじさんとして一番言いたいことがあります。
多くの企業は、LLM導入を「AIツール導入」として考えます。
しかし、本質的には「会社の知識の置き場所を再設計するプロジェクト」です。
社内文書が整理されていない。
業務ルールが暗黙知になっている。
ベテラン社員の頭の中にしか判断基準がない。
部署ごとに回答が違う。
過去事例が検索できない。
最新版の資料がわからない。
この状態でAIを入れると、AIが賢くなるというより、会社の情報管理の弱さが可視化されます。
これは悪いことではありません。
むしろ、AI導入の大きな価値の一つです。
LLMを導入しようとすると、企業は嫌でも自社のナレッジ構造を見直すことになります。
どの情報が正なのか。
誰が更新責任を持つのか。
どの文書をAIに読ませてよいのか。
どの情報は部門限定なのか。
どの回答は人間の承認が必要なのか。
ここを整理しないまま、RAGやファインチューニングの議論だけをしても、あまり意味がありません。
RAGは、散らかった社内情報を魔法のように正しくしてくれる仕組みではありません。
ファインチューニングは、曖昧な業務ルールを勝手に標準化してくれる仕組みではありません。
AIは、会社の知識管理の成熟度を映す鏡です。
2026年の実務的な結論
2026年の企業LLM導入では、次の考え方が現実的です。
まず、RAGで始める。
なぜなら、企業が扱う情報の多くは変化するからです。
次に、評価データを作る。
AIの回答が良いか悪いかを、人間の感覚だけで判断しないためです。
そのうえで、回答スタイルや分類精度、出力形式に課題があるなら、ファインチューニングを検討する。
さらに、利用量が増えてきたら、小型モデル化、キャッシュ、ルーティング、モデル選択、プロンプト最適化を考える。
つまり、最初から「RAGかFTか」を決め打ちするのではなく、段階的に設計するべきです。
初期PoC
- 高性能な汎用LLM
- 小規模RAG
- 手動評価
- 対象業務を限定
初期本番
- RAG基盤の整備
- 引用・ログ・権限管理
- 回答テンプレート
- 人間レビュー導線
拡張フェーズ
- ファインチューニング
- 小型モデル活用
- コスト最適化
- 自動評価
- エージェント化
- 部門横断展開
この順番で進めるのが、もっとも失敗しにくいです。
上司に説明するなら、こう言えばいい
社内で説明するときは、難しい技術用語を並べるよりも、次のように言うのがわかりやすいです。
RAGは、AIに最新の社内資料を参照させる仕組みです。
ファインチューニングは、AIの答え方や業務上の振る舞いを安定させる仕組みです。
したがって、どちらか一方を選ぶ話ではなく、変わる知識はRAGで、安定させたい振る舞いはファインチューニングで管理するのが基本方針です。
この説明が一番通りやすいと思います。
技術選定の話を、経営判断の言葉に翻訳することが大切です。
まとめ：LLM導入の勝ち筋は、技術よりも設計にある
RAGとファインチューニングは、どちらが優れているかを競うものではありません。
RAGは、変化する知識を扱うための仕組み。
ファインチューニングは、安定した振る舞いを作るための仕組み。
ハイブリッド構成は、その両方を業務に合わせて組み合わせる考え方です。
企業がLLM導入で失敗する理由は、モデル選びを間違えるからだけではありません。
むしろ多いのは、業務要件、知識管理、評価基準、運用責任を曖昧にしたまま導入してしまうことです。
AI導入で最初に問うべきなのは、
「どのモデルを使うか」ではありません。
本当に問うべきなのは、
「この会社の知識は、どこにあり、誰が管理し、AIはそれをどう使うべきか」です。
そこまで考えられた企業から、LLM活用は実験ではなく、業務インフラになっていきます。
