「RAGとファインチューニング、どちらを選ぶべきか」で迷う情シス・DX推進室は多い。結論から言えば、9割の事業会社はRAGから始めるべきだ。ファインチューニングが効くのは、専門用語や出力形式が固定された限定領域に絞られる。判断軸は、鮮度、ドメイン特化度、運用体制、ガバナンスの4つで見る。
RAG と FT の本当の違い (用途・コスト構造・更新サイクル)
RAG(=検索拡張生成)は、社内規程、FAQ、提案書、マニュアルなどを検索し、その結果を生成AIに渡して回答させる設計だ。モデルそのものは変えず、参照する知識を外側から差し込む。一方、FT(=ファインチューニング)は、既存モデルに追加学習を行い、特定の表現、分類、判定傾向を身につけさせる。
コスト構造も違う。RAGは初期の文書整備、権限設計、検索精度の調整に費用が寄る。月次で文書を更新すれば、最新情報を比較的反映しやすい。FTは学習データ作成、検証、再学習のたびにコストが発生する。社内規程が毎月変わる会社でFTを先に選ぶと、更新のたびにモデル評価が必要になり、情シスの運用負荷が膨らむ。コアネストは、知識を覚えさせる前に「どの文書を、誰に、どの粒度で参照させるか」を設計する方が、事業会社では成果につながりやすいと見ている。
事業会社が見落としがちな4つの判断軸 (鮮度、ドメイン特化度、運用体制、ガバナンス)
第一の軸は鮮度だ。価格表、就業規則、顧客別の運用ルールのように月1回以上変わる情報はRAG向きである。第二にドメイン特化度。業界固有の略語を正規化する、問い合わせを20カテゴリへ分類する、といった繰り返しタスクはFTを検討する価値がある。
第三は運用体制だ。RAGは文書オーナー、承認フロー、検索ログの確認担当を決めれば、小さく回せる。FTは学習データの品質管理、誤判定時の再学習判断、モデルの世代管理まで必要になる。専任のMLエンジニアがいない100〜300名規模の事業会社では、FT運用が属人化しやすい。
第四はガバナンスである。RAGはアクセス権限を文書単位で制御しやすく、監査ログも設計しやすい。ただし規制業種で社内データの外部送信が禁じられているケースは別の設計が必要だ。オンプレミス、閉域網、匿名化、ローカルLLMの組み合わせを検討し、RAGかFTかの前にデータ持ち出し条件を整理するべきである。
RAG が向く業務 / FT が向く業務 (それぞれ仮想ケース1社ずつ — 業種・規模を分ける)
RAGが向くのは、根拠文書があり、回答時に出典確認が必要な業務だ。たとえば従業員210名の法人向けSaaS企業A社では、カスタマーサクセスと情シスに毎月約320件の社内問い合わせが来ていた。契約プラン、障害対応手順、権限設定がNotionとGoogle Driveに分散し、新人は回答に平均12分かかっていた。RAGでFAQ、運用手順、過去チケットを横断検索し、回答に参照元リンクを付ける設計にすると、一次回答の工数を3〜4割下げやすい。
FTが向くのは、知識の検索よりも「判断の型」を揃える業務だ。年商280億円の医療機器専門商社B社では、海外メーカーから届く仕様書に独特の略語が多く、営業事務が見積カテゴリへ分類する作業にばらつきがあった。過去3万件の分類済みデータがあり、更新頻度も四半期単位なら、FTで用語解釈とカテゴリ判定を寄せられる。逆にデータが数百件しかない、分類基準がまだ揺れている段階では、FTよりプロンプトとRAGで業務ルールを固める方が先だ。
事業会社向け実装ステップ (初期PoC→評価→本番)
最初のPoCは、全社展開ではなく1部門・1業務に絞る。期間は4〜6週間、対象文書は50〜200本程度で十分だ。まず業務棚卸しを行い、「回答時間を月80時間削減」「一次回答の正答率80%」のように評価指標を決める。次に文書の最新版、重複、閲覧権限を整理する。
評価では、正答率だけでなく、根拠提示率、回答不能時に止まれる率、権限外情報を出さない率を見る。FTを検討する場合も、まずRAGやプロンプトで失敗パターンを集める。100〜300件の評価データを作り、同じ誤りが繰り返されると確認できてからFTへ進む。本番化では、文書更新の責任者、月次レビュー、ログ監査、改善チケットの流れを決める。コアネストのコンサルでは、この判断フローを部門横断で設計する。
RAGとFTは対立概念ではない。事業会社では、まずRAGで社内データの所在、権限、更新サイクルを整え、そのうえで限定領域だけFTを重ねる設計が現実的だ。技術名から選ばず、業務、データ、運用責任から逆算することが重要だ。自社の社内データ活用にRAG/FTどちらが効くかを見積もるなら、30分の無料診断で確認してほしい。
