RAGの限界を超えろ：SaaS企業がGeminiファインチューニングに踏み切った全記録【失敗談あり】

はじめに：RAGは「魔法の杖」ではなかった

「RAG（検索拡張生成）を導入すれば、独自のデータに基づいた完璧な回答が得られる」

昨今の生成AIブームの中で、この定説は半ば常識として語られている。確かに、AI開発においてRAGは強力な武器だ。ハルシネーション（幻覚）を抑制し、最新情報を反映させるためには欠かせないアーキテクチャである。

しかし、現場で泥臭くAI開発に向き合っているエンジニアや経営者なら、薄々気づいているはずだ。「RAGだけでは、どうしても超えられない壁がある」ということに。

長年の開発現場で培った知見から、今回は少し「逆張り」の話をしよう。

ここで取り上げるのは、金融系SaaS領域における実践的なケーススタディだ。多くのプロジェクトでRAGが導入され、一定の成果を上げている。しかし、そこからが本当の戦いとなる。専門用語の微妙なニュアンスが伝わらない、回答のトーン＆マナーが安定しない、そして膨れ上がるトークンコストとレイテンシ（応答遅延）。

「プロンプトエンジニアリングで何とかなる」という甘い期待を捨て、Vertex AIを用いたGeminiモデルのファインチューニング（Fine-tuning）という、より険しい道を選ぶケースが増えている。

適切に導入した場合、推論速度が2倍になり、コストが40%削減されるといった成功事例も報告されている。しかし、そこに至るプロセスは決して平坦ではない。過学習によるモデルの暴走、データクレンジングの苦行など、乗り越えるべき課題は多い。

本記事では、成功の輝かしい数字だけでなく、エンジニアが知りたい「失敗と試行錯誤のプロセス」を包み隠さず共有する。RAGの限界を感じ、次のステップを模索している開発チームにとって、この記録が確かな道標となることを願っている。

1. プロジェクト背景：専門用語が飛び交う金融SaaSの挑戦

組織とサービス特性における課題

FinTech領域、特に法人向けの経費精算・管理クラウドサービスのような環境では、カスタマーサポート（CS）において極めて高度な専門性が要求される。「インボイス制度の特例適用範囲」や「電子帳簿保存法の要件設定」といった問い合わせは、単なる操作説明を超え、法的な正確さと信頼性が問われるからだ。

多くの開発現場では、業務効率化の第一歩としてRAG（検索拡張生成）ベースのチャットボット導入が進められている。社内の膨大なマニュアルや法規制データベースをベクトル検索し、LLMに回答生成させるこの仕組みは、初期のPoC（概念実証）段階では一般的な質問に対して良好な結果を示し、導入への期待を高めることだろう。

RAG導入後に直面する「80点の壁」

しかし、本格運用を目指して検証を進めると、多くのプロジェクトが「80点の壁」に直面する。回答の事実関係は概ね正確であっても、ユーザー体験（UX）を損なう以下の3つの構造的な課題が浮き彫りになるのだ。

1. ドメイン固有の言い回しの不一致: 金融業界特有の「堅実だが、冷たくはない」という絶妙なトーン＆マナーの再現は容易ではない。ベースモデルの学習データに引きずられ、機械的な翻訳調になったり、逆に不自然に馴れ馴れしい回答が生成されたりすることがある。
2. 文脈理解の不足: 専門用語の多義性がハードルとなる。例えば「差し戻し」という言葉一つとっても、システム上のワークフロー操作を指すのか、法的な申請却下を指すのかは文脈次第だ。RAGで関連ドキュメントを取得できたとしても、LLMがその文脈を正しく解釈しきれないケースが発生する。
3. プロンプトエンジニアリングの限界とコスト: 上記の課題解決策として、システムプロンプトに理想的な回答例（Few-shot）を多数含める手法が標準的だ。しかし、複雑な業務ルールやスタイルガイドを網羅しようとすると、プロンプトが肥大化し、入力トークン数が激増する。最新のモデルではコンテキストウィンドウが拡大しているとはいえ、トークン増加はレスポンスの遅延とAPIコストの上昇に直結し、リアルタイム性が求められるCS対応では致命的になりかねない。

「毎回辞書を引いて（検索して）答えるのではなく、そもそも専門用語や振る舞いを知識として内包していてほしい」。こうした現場のニーズに応えるためには、RAGのプロンプトチューニングだけに固執するのではなく、モデル自体をドメインに特化させる「ファインチューニング」への転換を検討すべき段階に来ていると言える。

2. なぜファインチューニングが必要だったのか？技術的・経営的判断

ファインチューニング（以下FT）は、RAG（検索拡張生成）に比べてハードルが高いとされている。データの準備が煩雑で、コストもかかり、モデルの更新運用も重い――これが一般的な見解だろう。しかし、プロジェクトの状況を冷静に分析すると、FTこそが合理的であるという結論に至るケースは少なくない。

プロンプトエンジニアリングの限界

多くのSaaS開発現場では当初、プロンプトエンジニアリングに多大なリソースを費やす傾向がある。「あなたはベテランの経理担当者です」というペルソナ設定から始まり、NGワードリスト、回答例（Few-shot）を5つ、10つと増やしていくアプローチだ。

結果、システムプロンプトだけで2,000トークン近くを消費する事態となる。ユーザーの質問とRAGの検索結果（チャンク）を合わせると、1回のリクエストで簡単に5,000〜8,000トークンに達する。これでは、どんなに高速なモデルを使ってもレイテンシは悪化する一方だ。さらに、プロンプトで指示できる「回答のスタイル」や「業務特有の暗黙知」には限界がある。

Gemini Flashモデル選定の理由

そこで解決策として注目されているのが、Google CloudのVertex AI上で利用可能なGeminiのFlashモデル（軽量版）だ。選定理由は明確である。

• 圧倒的なコストパフォーマンス: FlashモデルはProモデル（高性能版）に比べて非常に安価だ。FTを行うことで、Proモデル並み（あるいは特定のタスクではそれ以上）の精度を、Flashの低コストで実現できる可能性がある。
• 高速な推論速度: ユーザー体験（UX）において、チャットボットの応答速度は致命的だ。Flashモデルの低レイテンシは、実用アプリケーションにおいて大きな強みとなる。
• Vertex AIの統合環境: データセットの管理から学習ジョブの実行、デプロイ、評価（AutoSxS）までが一つのプラットフォームで完結するため、運用負荷を最小限に抑えられる。

最新トレンド：モデルの世代交代について（2026年1月時点）
Geminiモデルは、現在Geminiの最新モデルやGeminiの最新モデルなどの後継モデルへ移行が進んでいる。

• Geminiの最新モデル: 高速・低コストを維持しつつ基本性能が向上。
• Geminiの最新モデル: マルチモーダル対応や処理速度がさらに強化され、無料版Geminiの既定モデルとしても採用されている。

これから導入を検討する場合は、公式ドキュメントで最新のFlashモデルを確認し、Geminiの最新モデル以降のモデルを選択することを強く推奨する。

コストと精度のトレードオフ分析

導入の意思決定において、経営層への説得材料としてROI（投資対効果）試算が行われることが多い。

• 現状（RAG + Proモデル）: 精度は高いが、トークン単価が高く、プロンプト肥大化により毎回コストがかさむ。
• 提案（FT + Flashモデル）: 初期投資（学習コストとデータ作成工数）はかかるが、運用時のトークン単価は劇的に下がる。プロンプトも短縮できるため、二重のコスト削減になる。

一般的な試算では、月間5万回のクエリがある場合、開発コストを含めても半年程度で損益分岐点を超えるという結果が示される。これが、技術的にも経営的にもFTへ踏み切る決定打となるケースは少なくない。

3. 実装プロセス詳細：泥臭いデータ準備と学習パイプライン

ここからは、エンジニア向けに、実際の「泥臭い」作業工程を解説しよう。ファインチューニング（FT）の成否は、アルゴリズムの優劣ではなくデータの質で9割決まる。これは決して誇張ではない。

学習データセットの構築：量より質の確保

「過去のログが10万件あるから、全部投入すれば賢くなりますよね？」

プロジェクトの初期段階で、このような疑問が生じることは珍しくない。しかし、その答えは明確に「No」だ。精査されていないデータを大量に学習させれば、モデルは自信満々に誤った情報を出力するようになるだけである（Garbage In, Garbage Out）。

高品質なモデルを構築するためには、一般的に以下の手順が推奨される。

1. 良質データの選別: 過去のカスタマーサポート（CS）ログから、顧客満足度が高かった回答や、ベテランオペレーターが作成した模範解答を抽出する。まずは1,000件程度を目安にすると良いだろう。
2. 人手によるクリーニング: ここが最も労力を要する工程だ。個人情報の削除はもちろん、「お世話になっております」といった過度な定型句の削除、誤字脱字の修正、そして回答内容が現在の規定に合致しているかの確認を行う。多くの場合、本当に「教科書」として使えるデータは抽出元の半数程度（約500件）まで絞り込まれる。
3. フォーマット変換: Vertex AIでのGeminiチューニングに必要なJSONL形式に整形する。

以下は、チャット形式のデータセット構造の例だ。

{"messages": [
  {"role": "system", "content": "あなたは経費精算システムのサポートAIです。質問に対して簡潔かつ正確に、親しみやすいトーンで回答してください。"},
  {"role": "user", "content": "領収書の画像アップロードがエラーになります。"},
  {"role": "model", "content": "ご不便をおかけして申し訳ありません。画像ファイルの形式はJPEGまたはPNGでしょうか？また、サイズが10MBを超えていないかご確認ください。もし条件を満たしているのにエラーが出る場合は、一度アプリのキャッシュをクリアして再試行していただけますか？"}
]}

この精選された500件程度の「黄金のデータセット」こそが、実用的なAIモデル構築の命綱となる。

Vertex AIでのチューニングジョブ実行手順

データセットの準備が整えば、Vertex AI上での操作自体は非常にシンプルだ。

1. データのアップロード: 作成したJSONLファイルをCloud Storageバケットにアップロードする。
2. モデルの選択: Vertex AI Studio（旧Model Garden）からベースモデルを選択する。
   • モデル選定の注意点: 以前はGeminiモデルが主流だったが、現在はより高性能かつ低遅延なGeminiの最新モデルやその軽量版など、新しい世代のモデルが登場している。Google Cloud公式ドキュメント（2025年以降）では、最新のFlashモデルへの移行が推奨されている。プロジェクトの要件に合わせて、常に最新の安定版モデル（例：gemini-2.5-flashなど）を選択してほしい。
3. ジョブの作成: 「Create Tuned Model」を選択し、データセットを指定してチューニングジョブを開始する。

ハイパーパラメータ調整の勘所

デフォルト設定でも動作はするが、より良い結果を得るためには、以下のパラメータ調整を検討することをお勧めする。

• Epochs（エポック数）: デフォルト値よりも少なめの設定から検証を始めるのが定石だ。特にデータ数が少ない場合、回しすぎると学習データの内容を丸暗記してしまい、未知の質問に対応できなくなる「過学習（Overfitting）」のリスクが高まる。多くのケースでは、3〜4エポック程度が最適解となる傾向がある。
• Learning Rate Multiplier（学習率）: モデルが重みを更新する際のステップ幅だ。標準設定で挙動が不安定な場合（Lossが下がらない、または乱高下する場合）は、値を少し下げて（0.1倍〜0.5倍程度）、じっくりと学習させる方針に切り替えると安定することがある。

4. 直面した「過学習」と「破滅的忘却」の壁

順調に進んでいるように見えても、最初のモデルが出来上がった段階で予期せぬ課題に直面することがある。

特定の言い回しへの過剰適合

例えば、完成したモデルをテストすると、どんな質問をしても「承知いたしました。直ちに確認し、担当部署へ申し送ります。」というフレーズを文末に付け加えるようになってしまうケースがある。

これは学習データの中に、解決困難なケースに対する「エスカレーション（担当者への引き継ぎ）」のログが多く含まれていることが原因として挙げられる。モデルは「困ったらこれを言っておけば正解らしい」と誤った学習をしてしまうのだ。

これを防ぐためには、データセットを見直し、エスカレーションする回答の比率を意図的に下げ、自己解決を促す回答バリエーションを増やす（データバランシング）必要がある。

一般的知識の喪失への対策

もう一つの問題は「破滅的忘却（Catastrophic Forgetting）」だ。特定の業務知識を詰め込みすぎた結果、Geminiが元々持っていた一般的な知識や、論理的な推論能力が低下してしまう現象である。例えば、簡単な日付計算を間違えたり、一般的な挨拶が不自然になったりする。

対策として、学習データに汎用的なタスク（一般的な会話や論理パズルなど）を少量混ぜる手法（Replay Buffer的なアプローチ）を採用することが有効だ。これにより、専門性を高めつつも、LLMとしての基礎体力を維持させることができる。

評価セットによる継続的なモニタリング

これらの問題を早期に発見するために役立つのが、Vertex AIのAutoSxS（Automatic Side-by-Side）評価だ。これは、評価用のモデル（審査員モデル）が、チューニング前と後のモデルの回答を比較し、どちらが優れているかを判定する仕組みである。

学習データとは別に用意した「評価用データセット（50件程度）」を用いて、毎回チューニング後にスコアを計測することで、「肌感覚」ではなく「数値」でモデルの良し悪しを判断できるようになる。

5. 導入成果：速度2倍・コスト40%減のインパクト

適切なデータセット構築とハイパーパラメータ調整を経て、ファインチューニング済みモデルを本番環境へデプロイした際、期待できる成果は非常に大きなものだ。ここでは、Geminiの軽量モデル（Flashシリーズ）を活用した一般的な成功事例におけるインパクトを分析する。

定量的成果：レイテンシとトークン削減

ファインチューニングの最大の恩恵は、プロンプトに依存しないパフォーマンスの最適化である。

• 応答速度（レイテンシ）の改善: 多くのケースで応答速度が劇的に向上する。例えば、平均4.5秒かかっていた回答生成が2秒台前半まで短縮されるケースも珍しくない。これは、Few-shotプロンプト（例示）を削除できることによる入力処理の軽量化が大きく寄与している。
  • Update: 最新のGeminiの最新モデルやGeminiの最新モデルを採用した場合、旧世代（1.5 Flash）と比較してさらなる処理速度の向上（最大3倍程度）が見込まれる。
• コスト削減: 入力トークン数が平均で約60%削減される傾向にある。GeminiのFlashモデルが持つ低価格設定と相まって、月間のAPI利用コストは約40%ダウンという試算も現実的だ。特に最新モデルではコストパフォーマンスがさらに最適化されている。

定性的成果：ユーザー満足度の向上

数値には表れにくい「回答の質感」の変化も、ビジネスにおいては極めて重要だ。

• 「人間らしい」応答: カスタマーサポート（CS）の現場では、「まるで新人のオペレーターではなく、熟練したスタッフが答えているようだ」という評価が得られることが多々ある。
• ドメイン知識の定着: 専門用語の使用が適切になり、顧客からの「回答がわかりにくい」「的外れだ」というフィードバックが激減することは、ファインチューニングの明確な成功指標と言える。

運用チームの負荷軽減

開発・運用チームにとっても、長期的なメリットがある。

• プロンプト管理からの解放: 以前は回答精度を維持するために複雑なプロンプト修正を繰り返す「モグラ叩き」状態に陥りがちだった。しかし、モデル自体がスタイルやルールを学習しているため、推論時のプロンプトは「質問に答えてください」といったシンプルな指示で済む。
• 本質的な改善へのシフト: 運用チームは、プロンプトの微調整という対症療法から解放され、より本質的な「学習データの質の向上」や「最新モデル（Geminiの最新モデル/3系）への移行検証」にリソースを集中できるようになる。

---

※本セクションで言及した数値は一般的なモデルケースに基づく目安であり、実際のデータセットや利用環境により異なる。最新のGeminiモデル（2.5 Flash / 3 Flash等）の仕様については、Google Cloud公式ドキュメントを参照してほしい。

6. これから取り組む方へ：RAGとFTの使い分けチェックリスト

ここまでの解説から言えることは、「RAGかFTか」という二者択一ではないということだ。実際、実務の現場ではRAGを併用するケースが多い。最新の法改正情報などはRAGで検索し、その情報を元にFTモデルが「自社らしいトーン」で回答を生成する、というハイブリッド構成が有効だ。

最後に、FTに踏み切るべきか判断するためのチェックリストをまとめた。

ファインチューニングすべきケース、すべきでないケース

項目	RAGで十分なケース	FTを検討すべきケース	具体的な事例	判断の目安
知識の更新頻度	毎日・毎週変わる（ニュース、在庫情報）	あまり変わらない（社内規定、業界用語、基本法規）	法改正は年単位だが、規定は不変	FT向き（最新情報はRAGで補完）
課題の種類	「知らないこと」によるハルシネーション	「話し方」「形式」「思考プロセス」の不一致	トーン＆マナーの不統一	FT向き
データ量	社内文書が大量にある	良質なQ&Aペアが数百件以上用意できる	過去のCSログが豊富	FT向き
コスト制約	初期コストを抑えたい	ランニングコストを下げたい	取引量増大によるコスト増が課題	FT向き

導入前に準備すべき3つのリソース

もしFTに挑戦するなら、以下の3つを確保してほしい。

1. ドメインエキスパート: データの良し悪しを判断できる人材（エンジニアだけでは困難だ）。
2. クリーンなデータセット: 最低でも100件、できれば500件の「理想的なQ&A」。
3. 評価パイプライン: モデルが劣化したことにすぐ気づけるテスト環境。

今後の展望：継続的なモデル更新

AIモデルは一度作って終わりではない。実運用においては、月次でデータを追加し、モデルを再学習させるMLOpsのサイクルを構築することが求められる。Geminiのモデル自体も進化し続けている。

RAGの限界を感じているなら、まずはプロトタイプとしてファインチューニングの世界へ一歩踏み出してみてほしい。そこには、プロンプト調整だけでは決して到達できない、自社だけの「理想のAI」が待っているはずだ。

まとめ

RAGの「80点の壁」を突破するためのGeminiファインチューニングという選択肢。それは決して楽な道のりではないが、得られる果実は非常に大きい。

• スタイルとニュアンスの統一: 独自のブランドボイスを獲得。
• コストと速度の劇的改善: ビジネスに直結するKPIを達成。
• 運用のシンプル化: 複雑怪奇なプロンプトからの脱却。

もちろん、すべてのプロジェクトでFTが必要なわけではない。しかし、特定のドメイン知識やスタイルが強く求められるB2B SaaSにおいて、これは強力な差別化要因になり得る。

もし終わりのないプロンプト調整に疲弊しているなら、一度立ち止まって考えてみてほしい。「モデルそのものを鍛える時が来たのではないか？」と。データという原石を磨き上げ、自社に最適化されたAIエージェントを作り上げる挑戦は、ビジネスの最短距離を描く強力な武器となるだろう。