LLMカスタマイズ、結局どれを選べばいい？
ミドリ(confused)： タツヤさん、うちの会社でもLLMを使いたいって話が出てるんですけど、「RAG」とか「ファインチューニング」とか、手法がいろいろあって混乱してます。
タツヤ： それ、今一番よく受ける相談だよ。結論から言うと、LLMカスタマイズには大きく3つの手法があって、選び方を間違えると数百万円を無駄にする。
ミドリ(surprised)： えっ、そんなに違うんですか。
タツヤ： 3つの手法を簡単に整理しよう。プロンプト工学、RAG（検索拡張生成）、ファインチューニング。この順番が大事で、検討する順序もこの通りにするのが鉄則なんだ。
まず3つの手法を30秒で理解する
ミドリ： それぞれ一言で言うとどういうものですか？
タツヤ： こう覚えて。
- プロンプト工学 — モデルへの「指示の出し方」を工夫する。モデル自体には一切手を加えない
- RAG — 質問に関連する社内データを検索して、プロンプトに添付してからモデルに渡す。モデルに「カンペ」を持たせるイメージ
- ファインチューニング — モデル自体を自社データで追加学習させる。モデルの「脳」を書き換える
ミドリ(nodding)： なるほど。外から情報を渡すか、モデル自体を変えるかの違いですね。
タツヤ： そういうこと。で、この3つはコスト・精度・実装難易度が全然違うから、ユースケースに応じた選択が重要なんだよ。
3大手法の徹底比較表
ミドリ(thinking)： 具体的にどう違うんですか？数字で見たいです。
タツヤ： OK、比較表を作ったよ。
| 比較軸 | プロンプト工学 | RAG | ファインチューニング |
|---|---|---|---|
| 初期コスト | ほぼゼロ | 50〜300万円 | 200〜1,000万円+ |
| 月間ランニングコスト | API利用料のみ | API利用料 + ベクトルDB | API利用料（推論コスト低減あり） |
| 実装期間 | 数時間〜数日 | 2〜8週間 | 4〜16週間 |
| 必要な専門知識 | 低（非エンジニアでもOK） | 中（エンジニア必要） | 高（ML専門家必要） |
| 情報の鮮度 | リアルタイム更新可能 | リアルタイム更新可能 | 再学習が必要（数日〜数週間） |
| 回答精度（自社データ） | △ 限定的 | ◎ 高い | ○ 高い（データ依存） |
| ハルシネーション制御 | △ 難しい | ◎ 出典付きで抑制 | △ 完全には防げない |
| レイテンシ | 低い | やや高い（検索分） | 低い |
| スケーラビリティ | ◎ | ○ | △ |
ミドリ： こうして見ると、RAGってバランスいいですね。
タツヤ： そう。だから実務の90%はRAGで解決できるって言われてるんだ。
判断フローチャート：どれを使うべきか
ミドリ(confused)： でも残りの10%はファインチューニングが必要ってことですよね。どう見分けるんですか？
タツヤ： 3つの質問で判断できる。
質問1：既存のモデルにプロンプトで指示するだけで解決するか？
タツヤ： たとえば「メールの文面をフォーマルに書き直して」とか「この議事録を要約して」みたいなタスク。これはプロンプト工学で十分。Few-shotの例を3〜5個添えるだけで精度は劇的に上がる。
ミドリ(nodding)： 確かに、わざわざRAGとかファインチューニングする必要ないですね。
タツヤ： プロンプトだけで解決するのに、RAGやファインチューニングに手を出す企業が意外と多い。まずプロンプト工学を徹底的に試すのが第一歩。
質問2：自社固有のデータを参照する必要があるか？
タツヤ： 「社内マニュアルに基づいて回答する」「製品カタログから情報を引いてくる」「過去の契約書を検索する」。こういうケースはRAG一択。
ミドリ： モデルが知らない情報を外から渡すわけですね。
タツヤ(nodding)： その通り。RAGのメリットは3つ。第一に、データを更新するだけで最新情報に対応できる。第二に、出典を提示できるからハルシネーションを抑制できる。第三に、モデル自体に手を加えないからリスクが低い。
質問3：モデルの「振る舞い」自体を変えたいか？
タツヤ： ここでようやくファインチューニングの出番。具体的には以下のケース。
- 特殊な文体や口調を再現したい（法律文書、医療レポート、ブランドのトーン）
- 専門用語の正確な使い方をモデルに覚えさせたい
- 独自の推論パターン（特定の分析フレームワークなど）を学ばせたい
- レイテンシを極限まで下げたい（RAGの検索時間を省きたい）
ミドリ(nodding)： なるほど、「情報」じゃなくて「振る舞い」を変えたいときだけファインチューニング、と。
タツヤ： 完璧な理解だね。
各手法の実装ポイント
プロンプト工学：意外と奥が深い
ミドリ(confused)： プロンプト工学ってただ指示を書くだけでしょ？ 簡単そうですけど。
タツヤ： 甘い甘い。プロンプト工学には確立されたテクニックがいくつもある。
- System Prompt設計 — モデルの役割、制約条件、出力フォーマットを定義する
- Few-shot Learning — 入出力の例を3〜5個提示して精度を上げる
- Chain-of-Thought（CoT） — 「ステップバイステップで考えて」と指示して推論精度を上げる
- Self-Consistency — 同じ質問を複数回投げて、多数決で最終回答を決める
タツヤ： 特にFew-shotは強力で、適切な例を5つ入れるだけで精度が20〜40%改善したケースもある。
ミドリ(surprised)： プロンプトだけでそんなに変わるんですか。
タツヤ： だから「まずプロンプト工学を極めろ」が鉄則なんだ。コストゼロで精度を大幅に上げられるのに、ここを飛ばすのはもったいなさすぎる。
RAG：構成要素と設計のコツ
ミドリ(thinking)： RAGの構成って具体的にどうなってるんですか？
タツヤ： RAGは4つのコンポーネントで構成される。
- ドキュメントの前処理 — PDF、Word、Slack履歴などを分割してチャンク化。チャンクサイズは256〜1024トークンが一般的
- ベクトルDB — チャンクをembeddingベクトルに変換して格納。Pinecone、Weaviate、pgvectorなどが代表的
- 検索（Retrieval） — ユーザーの質問をベクトル化して、類似度の高いチャンクを上位5〜10件取得
- 生成（Generation） — 取得したチャンクをプロンプトに添付してLLMに回答を生成させる
ミドリ(thinking)： チャンクサイズって何ですか？
タツヤ： ドキュメントを分割する単位のこと。小さすぎると文脈が欠ける、大きすぎるとノイズが増える。512トークン前後がバランスがいいとされている。ただしこれはドキュメントの種類によって調整が必要。
タツヤ(smiling)： もう一つ重要なのがHybrid Search。ベクトル検索だけだとキーワードの完全一致に弱いから、従来のキーワード検索（BM25）と組み合わせるのが最新のベストプラクティスだよ。
ファインチューニング：2026年の現実
ミドリ： ファインチューニングって、めちゃくちゃ高いイメージがあるんですけど。
タツヤ： 2026年時点では選択肢が増えてコストも下がってきている。
| 手法 | 必要データ量 | コスト感 | 精度 |
|---|---|---|---|
| Full Fine-tuning | 数万〜数十万件 | 高い（GPU数十時間〜） | 最高 |
| LoRA / QLoRA | 数千〜数万件 | 中程度（GPU数時間〜） | 高い |
| OpenAI Fine-tuning API | 数百〜数千件 | 低い（数万円〜） | 中〜高 |
タツヤ： 特にLoRA（Low-Rank Adaptation）は革命的で、フルのパラメータ更新の1/10以下のコストで、ほぼ同等の精度が出る。
ミドリ(confused)： それでも数千件のデータは必要なんですね。
タツヤ： そこがネック。質の高い教師データを数千件用意するのは、実は一番お金と時間がかかるフェーズ。だからファインチューニングは「最終手段」なんだよ。
組み合わせ戦略：最強はRAG + ファインチューニング
ミドリ： ちなみに、これらを組み合わせるのはアリですか？
タツヤ： むしろ上級者は組み合わせてる。最強パターンを紹介しよう。
パターン1：プロンプト工学 + RAG（推奨度：★★★★★）
タツヤ： 最もコスパがいい組み合わせ。RAGで取得したドキュメントを、精密に設計されたプロンプトでLLMに渡す。企業導入の80%はこのパターンで十分。
パターン2：RAG + ファインチューニング（推奨度：★★★★）
タツヤ： ファインチューニングでモデルの基本的な振る舞い（文体、専門用語の理解）を調整し、RAGで最新情報を補完する。医療・法律・金融など専門性が極めて高い領域で有効。
パターン3：3つ全部盛り（推奨度：★★★）
タツヤ： ファインチューニング済みモデル + RAG + 精緻なプロンプト。理論上は最高精度だけど、メンテナンスコストも最高になる。よほどの理由がない限り非推奨。
ミドリ： 全部盛りが最強じゃないんですね。
タツヤ(thinking)： 複雑さが増すと、どこで問題が起きてるか特定しにくくなる。シンプルに保つのも技術力の一つだよ。
実例：業種別の最適選択
ミドリ： 業種ごとの具体例も知りたいです。
タツヤ： よくある4パターンを紹介しよう。
社内ヘルプデスク（製造業・100名規模）
- 採用手法： プロンプト工学 + RAG
- データソース： 社内マニュアル200件、FAQ500件
- 結果： 問い合わせの70%を自動回答、対応時間を1件あたり15分→2分に短縮
- コスト： 初期150万円、月額5万円
契約書レビュー（法律事務所）
- 採用手法： RAG + ファインチューニング
- データソース： 過去の契約書3,000件、判例データベース
- 結果： レビュー時間を60%短縮、見落としリスクを85%低減
- コスト： 初期500万円、月額15万円
カスタマーサポート（ECサイト）
- 採用手法： プロンプト工学 + RAG
- データソース： 商品DB、過去の問い合わせ履歴1万件
- 結果： 一次回答の自動化率80%、顧客満足度スコア12%向上
- コスト： 初期100万円、月額8万円
医療レポート生成（病院）
- 採用手法： ファインチューニング + RAG
- データソース： 診療記録5,000件、医学論文DB
- 結果： レポート作成時間を70%短縮、医療用語の正確性99.2%
- コスト： 初期800万円、月額20万円
ミドリ： ファインチューニングまで必要なのは、やっぱり専門性が高い領域なんですね。
タツヤ(nodding)： その通り。一般的なビジネス用途なら、プロンプト工学 + RAGで十分すぎる精度が出る。
よくある失敗パターン
ミドリ： 逆に、やっちゃいけないことってありますか？
タツヤ： 3つのアンチパターンを覚えておこう。
失敗1：いきなりファインチューニングに飛びつく
タツヤ： 「自社専用AIを作りたい」→「じゃあファインチューニングだ！」って短絡する企業が多い。まずプロンプト工学で8割解決できないか検証すべき。検証コストはほぼゼロなんだから。
失敗2：RAGのチャンク設計を甘く見る
タツヤ： RAGの精度はチャンク設計で8割決まる。ドキュメントを雑に分割すると、検索精度がガタ落ちする。章・セクション単位での意味的な分割と、メタデータの付与が必須。
失敗3：評価指標を決めずに始める
タツヤ： 「なんとなく良くなった気がする」では投資判断ができない。正答率、ハルシネーション率、レイテンシ、ユーザー満足度の4指標は最低限、導入前に定義しておくこと。
ミドリ： 数字で効果を測れないと、上にも報告できないですもんね。
まとめ：迷ったらこの順番で考える
ミドリ： 今日の話をまとめるとどうなりますか？
タツヤ： シンプルに3ステップで考えればいい。
- まずプロンプト工学を極める — コストゼロで精度を最大化。Few-shot、CoT、System Promptの最適化。これだけで解決するケースが意外と多い
- 自社データが必要ならRAGを導入する — 情報の鮮度、出典提示、ハルシネーション抑制の3つが手に入る。企業導入の本命
- モデルの振る舞いを変えたい場合のみファインチューニング — 特殊な文体、専門用語、独自の推論パターンが必要な場合の最終手段
ミドリ： 「プロンプト→RAG→ファインチューニング」の順番、覚えました！
タツヤ： この順番を守るだけで、無駄な投資を防いで最短で成果を出せる。LLMカスタマイズで失敗する企業の大半は、この順番を無視してるんだよ。
次のアクション
自社でLLMを活用する際の最適な手法を選ぶために、以下を整理してみましょう。
- 解決したい業務課題を具体的にリストアップする
- 参照が必要な社内データの種類と量を棚卸しする
- まずはプロンプト工学だけで小さく検証してみる
- 手法選定や実装計画のご相談は、Shimanto AI SolutionsのLLM活用コンサルティングへ