用途と判断軸をユースケースで整理する｜FPT AI FACTORY
こんにちは。この記事は FPTスマートクラウドジャパン株式会社 の FPT AI FACTORY として、「結局、RAG（Retrieval-Augmented Generation）でいけるの？ それともファインチューニングが必要？」に答えるために書いています。
専門用語はなるべく避けて、用途と判断のしかたをユースケースで整理します。
✅ この記事でわかること（初心者向け）
- RAGとファインチューニングの違い（まずここ）
- ファインチューニングが刺さる用途（3つの型）
- 「いまの課題はRAG？ファインチューニング？」を迷わない判断表
- 実務でつまずくポイントと、その対処（PoC→本番の落とし穴）
- FPT AI FACTORY / FPT CLOUD がどう役立つか（自然に理解できる形で）
1. まず最初に：RAGとファインチューニングは“目的”が違う
LLM活用で出てくる改善手段はだいたいこの3つです。
- プロンプト改善：聞き方（指示文）を工夫する
- RAG：必要な情報（資料）を探してきて、答えの根拠にする
- ファインチューニング：モデルの“答え方のクセ”を整える（振る舞いを固定する）
初心者向けに超ざっくり言うと、以下の表現になります。
- RAG：資料を取りに行く（辞書引きに近い）
- ファインチューニング：答え方を鍛える（安定させる）
① RAG：辞書引きして根拠を渡す
② ファインチューニング：答え方（形式・観点・トーン）を整える
2. ファインチューニングって何を変えるの？（用途を先に押さえる）
ファインチューニングは「知識を覚えさせる魔法」ではありません。
実務で効くのは、主に “振る舞い”の安定化 です。
例えば次のような用途で強く効きます。
① 出力フォーマットを壊さない（業務で強い）
- JSONを厳格に出す（後段がAPI/ワークフロー）
- 帳票形式（稟議、監査レポート、事故報告）の構造を守る
PoCでは見逃せても、本番では「フォーマット崩れ」が致命傷になりがちです。
② 判断観点を標準化する（レビュー・監査・チェックリスト）
- セキュリティ観点のチェックを“漏れなく”揃える
- 契約レビューの指摘観点を統一する
- コードレビュー観点を標準化する
「人によってブレる」仕事ほど、ファインチューニング（または観点学習）が効きやすいです。
③ トーン／書きぶりを安定させる（対外文書・カスタマーサポート）
- サポート品質の均一化
- ブランド文体の統一
3. 逆に、ファインチューニングを“急がない方がいい”ケース
「社内規定やFAQを答えられるようにしたい」みたいな “情報不足” が原因なら、
まず疑うべきはRAGです。
- 社内文書を全部覚えさせたい → まずRAG（検索・引用・根拠提示）
- 規定が頻繁に変わる → RAG中心の方が更新追随が容易。バッチ処理化しやすい。
- 教師データを作れない／品質が担保できない → ファインチューニングは失敗しやすい
ファインチューニングは「データ品質が9割」です。ノイズが多いと、ノイズが強化されます。
4. 判断フレームワーク：いまの課題はRAG？ファインチューニング？（決定表）
「いま何が壊れているか」を切り分けるのが最短ルートです。
以下は現場で使っている 症状→原因→まずやること の表です。
| 症状 | 原因 | まずやること | ファインチューニング適性 |
|---|---|---|---|
| 最新情報・社内規定が答えられない | 知識不足 | RAG（検索/引用/根拠提示） | 低 |
| 回答が毎回ブレる | 出力傾向が不安定 | 評価→原因分解（どこが揺れる？） | 中〜高 |
| JSON/CSV/テンプレが崩れる | 形式制約が弱い | 形式ガード/構造化/関数呼び出し | 高 |
| “観点”が抜ける（監査/規約） | 思考パターンが弱い | 観点の明文化→評価→補強 | 高 |
| 丁寧語/ブランド文体が揺れる | スタイルが不安定 | スタイル制約→必要ならファインチューニング | 中〜高 |
| ハルシネーションが多い | 根拠不足/誘導 | RAG+引用強制+拒否設計 | 低〜中 |
5. 迷ったらこのフローで判断
6. ユースケース例：ファインチューニングが効きやすい現場パターン
ユースケース①：JSON出力が崩れて後段処理が止まる
- 課題：同じ入力でもJSONが崩れる／キーが抜ける／型が変わる
- 方針：構造化（関数呼び出し等）＋必要ならファインチューニングで「壊れない」方向に寄せる
- 狙い：賢さより、業務としての安定性
ユースケース②：監査・レビューの観点が抜ける／人でブレる
- 課題：チェック項目が漏れる、担当者ごとに基準が違う
- 方針：観点を明文化し、観点に沿った出力を評価→必要ならファインチューニング
- 狙い：品質の標準化
ユースケース③：カスタマーサポート文面の品質を一定にしたい
- 課題：丁寧さや表現が揺れる／ブランドトーンを外す
- 方針：トーンを固定するデータを用意し、必要ならファインチューニング
- 狙い：対外品質の安定
7. FPT Smart Cloudのファインチューニング事例：ドキュメント理解モデル × 300GB超データ（大容量学習の現場）
「ファインチューニングが効く場面」を、1つだけ具体例で紹介します。
ここでは ドキュメント理解モデル（Donut：Document Understanding Transformer） を対象に、300GB超のデータセットでファインチューニングしたケースを扱います。
事例の背景
- 顧客の状況：グローバルに開発チームを持つ企業（本社は日本）
- やりたいこと：帳票や文書画像を、実務で使える精度で「読み取り・理解・抽出」したい
- 難しさ：学習データが 300GB超 と大きく、学習基盤の設計とコスト最適化が効いてくる
課題
ドキュメント理解は、単に文章の知識を増やす話というより、
「読み取り・抽出の振る舞いを最適化する」 話になりやすいです。
つまり、RAGで「根拠を引く（辞書引き）」だけでは埋めにくく、
モデルの出力のクセ（抽出の仕方、構造の守り方、誤りの傾向） を整えるためにファインチューニングが効きやすい領域です。
解決アプローチ（どう組んだ？）
大容量データを扱うために、構成は「置き場」と「学習実行」を分けます。
- オブジェクトストレージ：学習データ（300GB超）を置く
- GPU環境（コンテナ）：ファインチューニングを実行する
- これを組み合わせて、柔軟でコスト最適化しやすい形で学習を回します
この事例からの学び（要点）
- データ量が大きいほど、「学習そのもの」より データ置き場・転送・実行環境の設計が効きます
- ドキュメント理解は 振る舞い最適化の比重が高く、ファインチューニングの価値が出やすいです
- 「賢さ」より “壊れない抽出” が業務価値になりやすいです
8. 実務の落とし穴：ファインチューニングは“学習”より“設計と運用”が重い
ファインチューニングは「学習を回せば終わり」ではなく、実務ではだいたいここが重いです。
- 学習データ設計（正例/負例/境界、フォーマット統一、ノイズ除去）
- 評価設計（何をもって“良い”とするか、再現性のある評価）
- 反復改善（失敗ケース収集→データ更新→再学習→再評価）
- 運用設計（更新頻度、RAGとの併用、監視、コスト管理）
ここを押さえてないと、PoCは良くても本番で詰まりやすいです。
教師データ（QA形式）に更に模範解答として「こう答えて欲しい」を付け加えると効果が出やすい傾向もあります。
9. FPT AI FACTORYを使うと何が楽になる？
FPT AI FACTORYでは、ノーコードで以下の事ができます。
- 教師データの作成
- ファインチューニング
- モデルテスト
通常ファインチューニングを実行するには、PCやVMなどで開発環境を構築したうえでPythonなどでファインチューニング用のプログラムを組んで実行する必要性があります。
しかし、FPT AI FACTORYではプログラミング経験が無くとも、ファインチューニングをノーコードで実行し、チューニング後の簡易テストができる環境まで提供しています。
10. サービス紹介（FPT AI FACTORY / FPT CLOUD）
FPTスマートクラウドジャパン株式会社では、大きくは以下二つのクラウドサービスを提供しております。
IaaSのFPT CLOUD（FPTスマートクラウドジャパン株式会社へお問い合わせください。）
PaaSのFPT AI FACTORY（今すぐにGPUが使える環境です。）
FPT AI FACTORY
- 日本リージョン：https://ai.fptcloud.jp/
- ベトナムリージョン：https://ai.fptcloud.com/
無料バウチャー提供中！2026年2月13日時点
新規ユーザー向けに、FPT AI FACTORYを30日間お試しいただける100ドル分のクレジットを提供しております！是非この機会にお試しください！
まとめ
- RAGは「情報を取りに行く」ための強化策
- ファインチューニング は「答え方（振る舞い）を安定させる」ための強化策
- 迷ったら 症状→原因→手段 の順で切り分けるのが最短ルート