RAG・ファインチューニング・プロンプト — 自社LLM構築の3つの方式を比較

三つの選択肢を会議のテーブルに置いて

前回の記事で、自社データLLMの三つの選択肢について軽く触れました。今回はその三つを、決裁会議のテーブルに置く気持ちで一つずつ丁寧に見ていきます。

先日、ある製造業のDX担当部長と2時間ほど話す機会がありました。その方が最後におっしゃった一言が印象に残っています。「どれも良いと言われるのですが、うちの会社では何から手をつければいいのか判断がつきません」。正直に申し上げると、私もこの質問を前にすると毎回少し迷います。正解が一つではないからです。ただ、決裁の直前で悩まれている方のために、私たちが最近のプロジェクトで実際に何をどう選んだのか、率直にお話ししたいと思います。

三つの方式はそれぞれ何に手を入れるのか

まずは原理から短く整理します。三つの方式は名前が並んで語られますが、実は手を入れる場所がそれぞれ違います。

プロンプトエンジニアリングは、モデル自体はそのままにして、投げかける質問(プロンプト)だけを緻密に磨き上げ、望む答えを引き出す方式です。モデルは市販のGPTやClaudeをそのまま使い、「どう問いかけるか」だけを設計します。初期実験やPoC段階で、真っ先に手をつける場所です。

RAG(Retrieval-Augmented Generation)は、自社の文書・マニュアル・商品DBをあらかじめベクトルで索引化しておき、質問が来ると関連する文書のいくつかを取ってきてLLMに参考資料として一緒に渡す方式です。分かりやすく言えば、「モデルに試験を受けさせるとき、自社の資料集を持たせてあげる」ようなイメージに近いです。回答の下にどの文書から出てきたか根拠を付けられる点が、決裁者の立場から見ると特に強力です。

ファインチューニング(Fine-tuning)は、事前学習済みモデルの重み自体を自社データで追加学習させる方式です。モデルが自社の話し方、ドメイン用語、判断パターンを身につけていきます。ただしGPUも必要ですし、学習データも丁寧に整える必要があります。

コストと保守の感覚

決裁会議で最もよく出る質問は、結局のところ二つです。いくらかかるのか、後々どれくらい手がかかるのか。三つの方式を一枚に整理すると、こんな絵になります。

数値はプロジェクト規模によって幅があります。ただ感覚的に見ると、初期のハードルはプロンプト → RAG → ファインチューニングの順で上がっていくとご理解いただければと思います。逆に「自社ならではの資産」が残る度合いは、その逆順で大きくなります。

なぜ多くの中小企業はRAGから検討するのか

結論から申し上げると、私たちがこの1年ほどの間に進めてきた韓国・日本の中小企業向けプロジェクトの多くは、RAGから始めています。自慢ではなく、他の選択肢がそのつどより悪かったからです。

理由はいくつか重なります。第一に、初期コストが低いこと。自社文書を整理してベクトルDBに入れ、検索パイプラインを載せる作業は、ファインチューニングほどGPUを要求しません。第二に、文書を差し替えれば回答が即座に更新されること。規定や商品カタログが頻繁に変わる会社であれば、この保守のシンプルさは実務チームの立場から見て決定的です。第三に、回答に根拠文書を付けられること。ハルシネーション(hallucination)のリスクを完全に消せるわけではありませんが、「この回答はどのマニュアルの3ページから来ています」と表示できるという事実だけで、社内決裁のハードルが目に見えて下がります。

こうした話は、前回の概念・ロードマップ総まとめで軽く触れた部分ともつながります。ロードマップの図で「1段階PoC」に該当する場所は、実際のプロジェクトではほとんどRAGで埋まります。

ではファインチューニングはいつやるのか

もちろん、ファインチューニングが必要な瞬間もはっきりあります。私たちが実際にファインチューニングを提案するケースは、おおむね次のようなものです。

ラベル付けされた学習データが5,000件以上蓄積されており、業界特有の話し方や文体の一貫性がサービス品質を左右する状況。例えば法務文書の要約、特定ブランドの顧客対応スクリプト、医療・バイオのように用語の正確さが事業の根幹となるドメイン。もう一つは大規模な反復トラフィックです。1日に数十万件の単純反復作業をAPIで回すとトークン費用が重くのしかかります。この場合は小さなモデルをファインチューニングして自社ホスティングする方が、長期的にはるかに安くなります。ケースによってはAPI比で運用費を80〜90%節約できたという報告も珍しくありません。

本当によく見かける典型的なパターンはハイブリッドです。最初はRAGで素早くサービスを立ち上げ、6ヶ月〜1年ほど運用データが溜まりトーンへの要求が明確になってから、LoRAのような部分ファインチューニングを載せていく流れです。最初からハイブリッドを描こうとせず、運用の中で自然に必要性が浮かび上がる順序で進める方が失敗確率が低くなります。

ではプロンプトエンジニアリングはどこに位置するのか

たまに誤解があるので触れておきます。プロンプトエンジニアリングは、RAGやファインチューニングの「下の段階」ではありません。三つとも並行するレイヤーです。RAGをやろうがファインチューニングをやろうが、結局モデルにどう問いかけるかは毎回設計する必要があります。あるチームはプロンプトだけをよく磨いても半年は問題なく回っています。順序で見ればプロンプト → RAG →(必要に応じて)ファインチューニングという検討順が自然です。逆にファインチューニングから始める会社は、たいてい数ヶ月後に後悔します。

決裁会議で投げかけてみたい質問

三つの方式について社内で議論される際、次の質問を先に整理しておかれると、決断がずっと楽になります。答えが用意されないままベンダーの見積書だけを比較すると、たいてい方向がぶれます。

• 自社がLLMに参照させたい知識はどれくらいの頻度で変わるか
• 回答に「どの文書から出てきたか」の根拠を表示する必要があるか
• ラベル付けされた学習データが実際にどれくらい蓄積されているか(希望ではなく実測で)
• 1日の利用量はどれくらいか — 少量精密型か、大量反復型か

この4つの質問に答えられれば、三つの方式のうちどれを優先すべきかは、たいてい自然に絞り込まれてきます。

おわりに — 方式を選んだそのあとに

方式を選んだからといってプロジェクトが始まるわけではありません。むしろ本当に難しい問題はその後にあります。「これで何がどれだけ良くなったのか」を3ヶ月後、経営陣にどのような言葉でお見せするのか。次回は自社LLM導入効果を測るROI・KPI設計を取り上げる予定です。実際に私たちがクライアントと一緒に組んできた指標フレームをいくつか共有します。

もし今、社内で方式をめぐる議論が交わされている最中であれば、文書の種類・業務の性格・トラフィックの感覚だけ教えていただければ、どちらが有利かおおまかな方向性を一緒に整理させていただけます。無料相談はこちらまでお気軽にご利用ください。私たちがこれまで進めてきた関連事例が気になる方は、前回のロードマップまとめもあわせてご覧いただければと思います。