用途と判断軸をユースケースで整理する｜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は「情報を取りに行く」ための強化策
ファインチューニング は「答え方（振る舞い）を安定させる」ための強化策
迷ったら 症状→原因→手段 の順で切り分けるのが最短ルート