Fine-tuning・RAG・プロンプトのうち、何から始めるべきか

0. この記事をひらく前に

ここまで読み進めてこられた方は、F1〜F6 の基礎6編と B1、B2 の2編をくぐってきた方だと思います。LLM が「それらしさ」を作り出す機械だという感覚、Attention の Q・K・V、embedding が高次元空間の座標であるという感覚まで。その土台の上に、今回の編を乗せていきます。

今回の編は、質問ひとつで終わります。

「うちの会社に AI を組み込みたいのですが、fine-tuning をすべきでしょうか、RAG を作るべきでしょうか、それともプロンプトを上手く書けば十分でしょうか?」

実務の現場に立つと、10回中9回はこの質問を受けます。そして私が見てきた限りでは、この質問にすぐ答えられる方は思ったより少ないんです。なぜなら、この3つは全く別の階層にある道具なのに、マーケティング資料では「AI カスタマイズ」という似たような名前でまとめて売られているからですよね。

今回の編では、この3つを1行で定義して、いつ何を選ぶべきかを5つの質問で振り分けて、費用感覚まで掴んでいきます。読み終わるころには、社内会議で「うちは今の段階なら RAG からで十分です」と自信を持って言えるようになっているはずです。

---

1. 実務でいちばんよく受ける質問 — 「うちの会社データで AI を使いたいのですが、何から?」

先月、ある中小法人の代表の方とお話しする機会がありました。その会社は社内規程文書が数百ページあって、従業員50名ほど、エンジニアは2名という構成です。代表の方がこう聞いてこられました。

「うちの規程を全部学習させた AI を作りたいんです。Fine-tuning というらしいんですが、いくらかかりますか? 1,000万円あれば足りますか?」

私は3つを聞き返したかったんです。規程はよく変わりますか。回答の話し方は固定されている必要がありますか。エンジニア2名で GPU インフラを管理できますか。

返ってきた答えはこうでした。「規程は四半期ごとに少しずつ変わります。話し方は丁寧であれば十分です。GPU は何のことかわかりません」。

この回答なら fine-tuning は正解ではありません。RAG が正解で、現実的には RAG すらすぐには必要なく、プロンプトを上手く書くだけで70%は解決する 状況です。ところが代表の方は「AI を組み込む = fine-tuning する」と思われていたんですよね。

この誤解は本当に広く広がっています。なのでまず、3つの道具を1行で整理するところから始めます。

---

2. 3つの道具の1行定義 — 料理人にレシピを教える3つの方法

LLM を料理人1人だと考えてみましょう。この料理人はすでに世界の料理のほとんどを作れます。ところが今あなたが欲しいのは 「うちの家だけの特製キムチチゲ」 です。どうやって教えますか。方法はちょうど3つあります。

方法1: 料理している横で、毎回レシピを読み上げる。
注文が入るたびに、あなたがレシピを読み上げます。「豚肉150g、熟成キムチ1カップ、豆腐は3番目の順で」。料理人は聞いて作ります。次の注文が来たら? また読み上げなければなりません。毎回です。
→ これが プロンプト (Prompt) です。使うたびに情報を引っ張り込んで渡す方式。

方法2: キッチンにレシピ本を置いておく。
キッチンの片隅に 会社のレシピブック を常備します。料理人は必要なときに「特製キムチチゲ」の項目を開いて読み、そのまま作ります。あなたが毎回読み上げる必要はなく、レシピ本を更新すれば翌日から新しいレシピが反映されます。
→ これが RAG (Retrieval-Augmented Generation) です。必要なときに外部から取ってきてプロンプトに乗せる方式。

方法3: 料理人を韓国料理の専門家として再教育する。
半年間、韓国料理学校に送ります。数百のレシピを体に染み込ませます。戻ってきた料理人は、レシピブックを見なくても自動的に韓国風の味付けをして、韓国風の盛り付けをします。代わりに教育費がかかり、一度卒業させたあとで新しいレシピを追加したければ、また学校に送らなければなりません。
→ これが Fine-tuning です。モデル自身の重みを更新して、知識・話し方・フォーマットを体に染み込ませる方式。

まとめるとこんな感じです。

方式	情報はどこにあるか	いつ注入されるか	持続性
プロンプト	プロンプトの中(一時テキスト)	呼び出すたびに	1回使って蒸発
RAG	外部ベクトル DB	呼び出し時点で検索して貼り付け	検索結果の分だけ維持
Fine-tuning	モデル重み(永続)	学習時点で1回	次の学習まで永続

この表1枚を頭に入れるだけで、今日の記事の半分は終わっています。残り半分は「いつ何を使うか」です。

---

3. プロンプト — いちばん速くていちばん安い、代わりに揮発する

プロンプトは料理人の横で毎回レシピを読み上げる方式だとお話ししましたよね。これがいちばん単純です。実装もいちばん楽で、費用もいちばん少なくて済みます。

長所

• すぐ始められる。 今日の午後に始めて、今日の夜には MVP を作れます。エンジニア1人だけで足ります。
• コストが低い。 API 呼び出し1回分のトークン費用だけ払います。平均的に1回あたり $0.001〜0.05 くらい。1日1,000回呼び出しても月数万円レベル。
• 実験が自由。 プロンプトを変えながら A/B テストができます。「今回はこの話し方、次はあの話し方」。デプロイの必要もありません。
• 透明性がある。 モデルがなぜそう答えたのか、プロンプトを見ればだいたい見えてきます。

短所

• 揮発する。 会話が終わるときれいに消えます。次の呼び出しは白紙から始まります。社内規程300ページを毎回プロンプトに詰め込むわけにはいきません。
• コンテキストウィンドウの上限。 Claude 4.7 Sonnet や GPT-4 Turbo あたりで、数万〜20万トークンあたりが上限です。会社文書全体を入れきれない規模のケースが多いんです。
• トークン費用は呼び出し数に比例。 呼び出しが多くなるほど、「毎回同じ長い指示文を送る無駄」が積み上がります。prompt caching で緩和はできますが、根本解決ではありません。
• 機密データを毎回外部 API に送ることになる。 プロンプトの中に社内情報を貼り付けて呼ぶということは、その情報が毎回 OpenAI・Anthropic のサーバーを経由するということです。契約条項とデータ処理場所を必ず確認する必要があります。
• 一貫性がない。 同じプロンプトを使っても、モデルは毎回少しずつ違う答えを出します。Temperature を 0 に下げても完全に同じにはなりません。

現実の使いどころ

• MVP 段階のほとんど。 チャットボット、要約ツール、分類器の初期版。
• 規模の小さい知識参照。 規程が A4 で10〜20枚程度で収まるケース。
• 1日の呼び出し数が数百以下。 費用が意味のあるボトルネックになる前。
• プロトタイピング。 「AI を乗せれば動くのか?」を確認する段階。

私が毎回差し上げるアドバイスはこれです。「まずプロンプトで試してみてください。だめだったら次の段階へ」。誰もこのアドバイスを好みませんが、実際に正しいんです。

---

4. RAG — 会社の文書数千枚を AI に「いつでも取り出せる状態」に

B2 で embedding を扱いましたよね。文を1,536次元くらいのベクトルに変換して「似た意味どうしがまとまるように」する技術。この embedding が RAG の心臓です。

RAG の流れを一度なぞってみます。

1. インデックス作成(事前作業)。会社文書数千枚をそれぞれ小さなチャンク(通常500〜1,000文字)に切ります。各チャンクを embedding に変換して、ベクトル DB(Pinecone、Weaviate、pgvector など)に保存します。これは1回やっておけば大丈夫です。
2. クエリ(毎回の呼び出し)。ユーザーが「先月の広告費の規程はどうなってる?」と聞いたら、この質問も embedding に変換します。
3. 検索。 質問の embedding といちばん近いチャンク上位5〜10個をベクトル DB から取り出します。コサイン類似度基準。
4. プロンプト組み立て。 取り出したチャンクをプロンプトの一番上に貼り付け、その下に元の質問を乗せます。「次の文書を参考に答えてください。[チャンク1] [チャンク2]… 質問: 先月の広告費の規程はどうなってる?」
5. LLM 呼び出し。 こう組み立てたプロンプトを LLM に送ります。モデルはチャンクを参考にして答えます。

この流れをキッチンの比喩に戻すと、料理人が「特製キムチチゲ」の注文を受けたら、レシピ本の目次から「キムチチゲ」を探して該当ページを開き、そのページを見ながら料理する、という動きです。あなたはレシピ本だけ管理すればよくて、料理人は本を見て調理します。

長所

• 鮮度。 レシピ本(文書)を今日更新すれば、明日から反映されます。Fine-tuning のように再学習する必要はありません。
• 大量文書の処理。 数万ページもベクトル DB に入ります。プロンプトのように1回の呼び出しに全部詰める必要がないので。
• 根拠の追跡。 どのチャンクが回答に使われたかをログに残せます。「この回答は規程集17ページ参照」のような引用が可能です。
• 機密データの管理ができる。 ベクトル DB をオンプレミスや VPC 内に置けます。原本文書が外部に流出するリスクを減らせます(ただし LLM にチャンクを送る瞬間には外に出るので、ここも社内 LLM を使うか BAA 契約を確認する必要があります)。

短所

• 検索品質がすべて。 チャンクの切り方、embedding モデルの選択、検索件数の設定次第で、回答品質が極端に割れます。エンジニアリング工数が結構かかります。
• インフラが必要。 ベクトル DB、インデックス作成パイプライン、文書更新トリガー、評価ループ。1人で回すにはきついスタックです。
• 初期セットアップコスト。 文書500枚をベクトル化するのは安いですが、運用中の RAG システムを安定的に維持するのは別の話です。最低 $500 からスタートして、本格運用は数千〜数万ドル規模。
• 遅延(latency)。 検索がもう1回入るので、プロンプトだけ送るより一拍遅くなります。通常 0.3〜1秒の追加。

現実の使いどころ

• 社内ナレッジチャットボット。 FAQ、社内 Wiki、規程集、マニュアル。
• カスタマーサポートの自動応答。 製品マニュアル・約款ベースの回答。
• リサーチアシスタント。 論文、法律文書、ニュースアーカイブ。
• コード検索型 IDE アシスタント。 Cursor のようなツールがコードベースをインデックスして RAG で答える構造。

ポイントはこれです。「情報がよく変わり、原本の追跡が必要なら RAG」。この条件に当てはまれば fine-tuning ではなく RAG です。

---

5. Fine-tuning — モデルの話し方・ドメイン・フォーマットを「体に染み込ませる」

Fine-tuning はいちばん重くて、いちばん誤解されている道具です。F6 で扱った gradient descent を思い出してください。モデルは大量のパラメータ(重み)を持っていて、この数字たちが入力を出力に変換する回路を作っています。Fine-tuning はこの重みを あなたが用意したデータでもう一度更新する 作業です。

技術的には2種類あります。

• Full fine-tuning: 全パラメータを更新。効果はいちばん強いけれど、コストと時間が大きく、モデルサイズ分のストレージが必要。
• PEFT/LoRA など: 元の重みは凍結して、小さな adapter 層だけを学習。ずっと安くて速くて、ストレージも数十 MB レベル。2026年基準で実務で回している fine-tuning のほとんどはこの系統です。

料理人の比喩では、これは料理人を学校に送ることです。学校で数千の例を繰り返し見た結果、料理人の手癖が変わります。卒業して戻ってきた料理人は、特別な指示がなくても自然に「うちの家のスタイル」で料理します。

長所

• 一貫した出力。 話し方・フォーマット・長さ・トーンが学習データに追従します。「常に3文以内で、敬語で、技術用語は噛み砕いて説明する」のようなルールが、プロンプトに書かなくても自動的に出てきます。
• トークン費用の削減。 長いシステムプロンプトが不要になるので、呼び出しあたりの入力トークンが減ります。呼び出し数が多いほど、この節約が効いてきます。
• ドメイン知識の内在化。 法律・医療・金融のような用語がシビアなドメインで、ドメイン話法を体に染み込ませられます。正確な用語選び、文体、構造まで。
• 遅延の短縮。 プロンプトが短くなるので応答が速くなります。同じモデルなら fine-tuned 版のほうがわずかに速いです。

短所

• 高コスト。 OpenAI の GPT-4 系の fine-tuning は学習費用だけで $100〜数千ドル。本格的な規模は数十万ドルに届くこともあります。自社ホスティングのオープンソースモデルだと、GPU 時間・ストレージ・エンジニア人件費まで含みます。
• 更新が大変。 新しい知識を追加するには再学習が必要です。RAG のように文書だけ更新すれば終わる話ではありません。これが決定的なんです。
• データ品質への依存。 ゴミを入れればゴミが出ます。数百〜数千組の高品質な学習ペア(入力・出力)を作ること自体が、大きなプロジェクトです。
• 機密データの管理。 学習データはモデル重みに「染み込みます」。理論的には抽出攻撃で原本が出てくる可能性があります。機密データで学習させるときは、モデルアクセス権と出力フィルタリングを別途設計する必要があります。
• ハルシネーションはそのまま。 後でまた扱いますが、fine-tuning がハルシネーションを消してくれるわけではありません。

現実の使いどころ

• 話し方・フォーマットの固定。 カスタマーサポート回答を会社ブランドのトーンに統一。
• 構造化出力。 JSON・XML・特定マークアップで正確に出力。
• 専門ドメインの分類器・要約器。 医療記録分類、法律文書要約のような固定タスク。
• 呼び出し数が非常に多いとき。 毎日数十万回呼び出すサービスなら、fine-tuning でプロンプトを短くすることで費用削減効果が積み上がります。

1行まとめ。「話し方・フォーマット・一貫性を得たくて、知識があまり変わらず、呼び出し数が十分に多いとき」 fine-tuning が正解です。それ以外はほぼ別の答えがあります。

---

6. 意思決定ツリー — 何を選ぶかを決める5つの質問

さて、ここから実際の判断です。5つの質問を順番に投げてみてください。それぞれの答えを書き出していくと、自然と方向が見えてきます。

Q1. 情報はよく変わるか?

• 毎日/毎週変わる → RAG 優先。 再学習なしに文書だけ差し替えられるので。
• 四半期/半期に一度変わる → RAG が楽だけれど、他の要件次第で fine-tuning もあり。
• ほぼ変わらない(固定カリキュラム、固定マニュアル) → Fine-tuning の候補になり得る。

会社の規程、商品価格、ニュース記事、リアルタイム在庫などは RAG が正解です。会社のブランドガイド、古い法律集のように年単位でしか更新されないものは fine-tuning もありえます。

Q2. 同じ話し方・フォーマットを繰り返し欲しいか?

• はい、トーン/構造/長さが固定されるべき → Fine-tuning 候補。
• いいえ、毎回柔軟に違う形で → プロンプトや RAG で十分。

例えば「すべての回答は『こんにちは、[会社名] カスタマーサポートです』で始まり、3段構造で、最後に問い合わせ番号」のような厳格なフォーマットが必要なら、fine-tuning でコードがずっときれいになります。プロンプトに毎回長く書くよりも。

ただし同じ目的を prompt caching + システムプロンプト で解決することもできます。規模が小さければこちらのほうが安いです。

Q3. 予算とエンジニアリングチームの規模は?

• エンジニア1〜2名、月予算数十万円 → プロンプト優先。 RAG は無理。
• エンジニア3〜5名、月予算数百万円 → RAG が可能。 ベクトル DB 運用能力があれば。
• エンジニア5名以上 + ML エンジニア、年予算数千万円〜億単位 → Fine-tuning も選択肢。

この区分は思ったよりよく忘れられます。多くの中小企業が「AI 導入」をしたいと言いながら、実際にはエンジニア1名がパートタイムで張り付いているんです。その状況で RAG システムを安定運用するのは大変です。プロンプトで最大限引っ張って、限界を感じたときに RAG に上がるのが正解です。

Q4. データは機密か?

• 個人情報・契約・医療記録 → プロンプトで毎回外部 API に送るのは危険。RAG でオンプレミスのベクトル DB に保存しても、チャンクが LLM に送られる瞬間に流出経路が残る。社内 LLM または Enterprise 契約(BAA など) が前提。
• Fine-tuning も機密データなら注意。 学習された重みから原本が出てくる抽出攻撃が現実的。

このカテゴリは「何を使うか」より「どこで回すか」のほうが重要です。クラウド API は入出力ロギングポリシーを必ず確認して、可能なら該当 LLM ベンダーの zero data retention オプションを使ってください。

Q5. 遅延(latency)は重要か?

• リアルタイム会話・音声応答など < 500ms が必要 → Fine-tuning + 短いプロンプトが有利。 RAG は検索時間が一拍追加される。
• チャットボット・要約など 1〜3秒許容 → RAG も問題なし。
• バッチ処理(夜間に回す) → 何でも構わない。

意思決定まとめ表です。

条件	優先推奨
情報がよく変わる	RAG
話し方・フォーマット固定が必要	Fine-tuning(呼び出し数が多いとき)
予算・チームが小さい	プロンプト
機密データ	オンプレミス/VPC + RAG もしくは社内 LLM
遅延が重要	Fine-tuning + 短いプロンプト
大量文書の参照	RAG
MVP・実験段階	プロンプト

---

7. 3つを「混ぜて使う」現実のパターン

ここまで読まれると「ああ、3つのうち1つを選ばないといけないんだな」と思われるかもしれません。でもプロダクション現実はそうじゃないんです。まじめな AI プロダクトのほとんどは、3つを組み合わせて 使っています。

いちばんよく見る組み合わせをいくつか紹介します。

パターン A: プロンプト + RAG

いちばんよく見る組み合わせです。システムプロンプトでトーン・役割・フォーマットを決め、RAG で会社文書を引っ張ってきて、最後にユーザー質問をくっつけます。

[システムプロンプト: カスタマーサポート役、3段構造、敬語]
[RAG で検索した規程チャンク3個]
[ユーザー質問]

長所は、fine-tuning なしでも話し方と知識の両方を押さえられることです。中小・中堅企業の70%はこの組み合わせで十分です。

パターン B: Fine-tuning + プロンプト

呼び出し数が多くて費用がボトルネックになった場合、長いシステムプロンプトを fine-tuning でモデルに埋め込んでしまいます。その後は呼び出すたびに短いユーザーメッセージだけを送ります。トーンとフォーマットはモデルが勝手に処理します。

パターン C: Fine-tuning + RAG + プロンプト(フルスタック)

本格的な規模のサービスは3つ全部使います。

• Fine-tuning: ドメイン話法・フォーマット・安全ガードレールを体に染み込ませる。
• RAG: 最新の文書・商品・価格・在庫をリアルタイムで注入する。
• プロンプト: 今回の呼び出しだけで必要な具体的指示(「今回の回答は英語で」など)。

Cursor、Perplexity、Harvey AI、Jasper のような AI プロダクトの背後には、ほぼこの構造が敷かれています。

組み合わせを選ぶときの順序

経験的にこの順序がおすすめです。

1. プロンプトだけでスタート。 どこまで通用するかを見る。
2. 文書量・鮮度が壁になったら プロンプト + RAG に拡張。
3. 呼び出し数・費用・一貫性が壁になったら Fine-tuning を追加。

逆に行かないでください。「最初から fine-tuning」は90%のケースで無駄です。

---

8. 実務でよくある錯覚 — 「fine-tuning するとハルシネーションが消える」という誤解

これは私が現場でいちばんよく打ち砕いている誤解です。代表の方、役員の方、エンジニアの方、みなさんこう信じておられる方が多いです。

「会社データで fine-tuning したら、もうこのモデルは嘘をつかなくなりますよね?」

いいえ。絶対に違います。

F1 で扱いましたよね。LLM は「それらしさ生成器」です。次のトークンが何かを確率的に予測して文をつないでいきます。事実検証の回路のようなものはありません。Fine-tuning をしてもこの基本構造は変わりません。

むしろ fine-tuning は、ときにハルシネーションを もっと自信たっぷりに してしまいます。なぜなら、学習データの話し方が「自信ある断定形」であれば、モデルは事実かどうかに関係なくその話し方で答えるからです。「当社の規程によると XXX」と堂々と答えるけれど、実際の規程にはそんな条項がない、という回答。これが fine-tuning がいちばんよく作る失敗です。

ハルシネーションを減らすのは別の階層の作業です。

• RAG: 回答に参照根拠をつけて「この根拠がないなら知らないと答えろ」という指示が効くようにします。これがいちばん効果の強い反ハルシネーション装置です。
• Retrieval ベース評価: 回答を生成したあとで、根拠チャンクと照合して一致するかをもう一度 LLM で検証する。
• 出力の構造化: JSON スキーマの強制、空フィールド許容で「わからない」を明示的に受けられるように。
• 人の検収ループ: 最終的に意思決定を人が確認する。

Fine-tuning がハルシネーション対策に寄与する部分は「断定形の話し方を減らすよう調整する」くらいです。知識検証は RAG と連鎖ループに任せるべきです。

1行で。「わからないときにわからないと言わせたいなら、fine-tuning ではなく RAG + プロンプトルール + 評価ループが必要」。

---

9. 費用を数字で見る感覚 — だいたいのレンジ

数字なしで「安い/高い」と言っても意味がないですよね。2025〜2026年基準でのざっくりしたレンジをお渡しします。実際の数字はベンダー・モデル・規模で大きく変わりますので、「感覚」として受け取ってください。

プロンプトベースのシステム

• 呼び出しあたり: $0.001〜$0.05(モデルと長さによる)
• 月5,000回、中程度の長さ基準: 月 $5〜$50
• 月50,000回基準: 月 $50〜$500
• エンジニアリングのセットアップ: エンジニア1名・数日程度
• 初期投資: ほぼ0円〜数十万円

RAG システム

• インデックス作成: 文書10,000ページ基準で一回性 $100〜$500(embedding 費用)
• ベクトル DB 運用費: Pinecone・Weaviate・pgvector 基準で 月 $50〜$500(規模による)
• LLM 呼び出し費: プロンプトシステムと同程度、もしくは少し多め(チャンクが追加されるので)
• エンジニアリングのセットアップ: エンジニア1〜2名・2〜4週
• 初期投資: $500〜数万ドル(本格システムは数万ドル規模)

Fine-tuning システム

• OpenAI 系 fine-tuning 学習費用(LoRA 級): $100〜$5,000(データ量による)
• Full fine-tuning の商用規模: $10,000〜$500,000+
• 自社ホスティングオープンソース(Llama・Qwen・Mistral など): GPU レンタル費 $500〜数万ドル + エンジニア人件費のほうが大きい
• データ準備: 通常、エンジニアリング費用の最大部分を占める。数百万円〜数千万円
• エンジニアリングチーム: ML エンジニア1名以上が必須
• 初期投資: 最低 $1,000〜数億円

運用中の継続費用の感覚

1日1,000回呼び出し基準、ざっくりした感覚:

• プロンプト中心: 月数万円
• RAG 中心: 月数十万円〜数百万円
• Fine-tuning 中心 + 自社ホスティング: 月数百万円〜数千万円

一桁の差が出ます。なので 「必要になる前には上に行かない」 が正解です。

---

10. 小さな会社の現実的な始め方 — 3段階の順序

代表の方、開発リードの方、ひとりでやる創業者の方から、いちばんよく聞かれるのが「じゃあ、どこから始めればいいですか?」です。私がおすすめする3段階はこれです。

ステージ1. プロンプトだけで MVP(1〜4週)

• いちばん使いやすい LLM API を1つ選んでください。OpenAI、Anthropic、Google Gemini のどれか。
• 目標のユースケースを 1つだけ 決めてください。例: 「社内規程チャットボット」「カスタマーサポート下書き生成器」「会議議事録の要約」。
• システムプロンプトに役割・トーン・フォーマット・禁止事項を書き込んでください。
• フロントエンドは最もシンプルなもので。Slack Bot、社内 Web ツール、さらには Google スプレッドシート関数でも大丈夫です。
• 1週間使ってみて「使えそうか?」を正直に評価してください。使えそうなら次のステージへ。

このステージで90%は「RAG や fine-tuning は要らないな」と気づきます。残り10%だけ進みます。

ステージ2. データが溜まったら RAG を追加(4〜12週)

• 会社文書を1か所に集めてください(Notion、Confluence、Google Drive など)。
• チャンク戦略を決めてください。500文字、1,000文字、2,000文字のどれで切るか。通常700〜1,000文字が無難です。
• embedding モデルを1つ選んでください。OpenAI text-embedding-3-small がコスパ良好、Cohere、Voyage も選択肢。
• ベクトル DB を選んでください。小規模なら PostgreSQL + pgvector がいちばんシンプル。中規模以上なら Pinecone・Weaviate。
• 文書更新パイプラインを作ってください。原本が変わったら再インデックスする自動化。
• 検索品質の評価ループを回してください。「質問50個 + 正解チャンク50個」のデータセットを作って、システムが正解チャンクを上位に載せるかを定期的に確認。
• プロンプトエンジニアリングを新しくやり直してください。チャンクをどんなフォーマットで貼り付けるか、「根拠がなければ知らないと答えろ」をどう強制するか。

ステージ3. 規模が大きくなったら fine-tuning を検討(6か月〜1年以上)

• 本当に必要なのかをもう一度確認。プロンプト + RAG で解決できない具体的なボトルネックがあるか。
• ボトルネック候補: 一貫したフォーマットが出ない、呼び出し費用がプロンプト長のせいで高い、ドメイン話法がめちゃくちゃ。
• LoRA・QLoRA のような軽量 fine-tuning から始める。Full fine-tuning は最後。
• 学習データをまじめに作ります。最低1,000〜5,000組の高品質な入出力。これがいちばん高くつきます(エンジニアリング時間)。
• 評価データセットを別途準備して、fine-tuned モデルが元モデルより 測定可能に 優れているか確認。
• デプロイ後もプロンプトと RAG は並行。Fine-tuning がすべてを代替するのではなく、「話し方・フォーマット・安全ガード」層を担当すると考えてください。

この順番が正解というわけではありません。ただ、この順序で行くと お金・時間・労力の無駄がいちばん少ない んです。逆順で行ったチームを何組か見ましたが、だいたい fine-tuning に大金を使ったあとで結局 RAG をくっつけることになっていました。

---

---

11. 実務者向けチェックリスト

今日の記事を閉じる前に、5つの bullet で整理します。社内会議に持っていけます。

• 「AI を組み込もう」という話が出たら、まず「情報がどれくらい変わるか」と「一貫した話し方・フォーマットが必要か」の2つの質問を投げる。 ここですでに80%は方向が分かれる。
• 基本はプロンプトから始める。 MVP で通用しない部分がはっきりするまで、RAG と fine-tuning は保留。「必要になって上がる」と「見栄えで上がる」は別物。
• 情報が多くてよく変わるなら RAG。 話し方・フォーマットが固定されて呼び出し数が多ければ Fine-tuning。この区分さえ明確なら、ベンダー・ツール選びは後からついてくる。
• ハルシネーション問題は Fine-tuning では解決しない。 RAG + 根拠引用 + 評価ループ + 人の検収で進むべき。「学習させれば嘘をつかなくなる」は間違った前提。
• プロダクション規模に行けば3つ全部混ぜて使う。 「1つを選ばないといけない」ではなく「段階的に積み上げる」と考えよう。今日プロンプト、6か月後 RAG、1年後 Fine-tuning は健全な経路。

---

閉じのひとこと

LLM はすでに世界中の料理を全部知っている料理人だ。あなたの仕事は「うちの家のキムチチゲのレシピ」をどう伝えるかを選ぶことだけ。毎回読み上げるか、キッチンに置くか、学校に送るか。焦らず、いちばん楽な方法から使おう。

次回は M1 — Retrieval Layer: 会社の文書を AI が取りに行く層 です。今回 RAG の流れをなぞったなら、次の編はその流れの中で「検索」の部分だけをじっくり掘っていきます。チャンク戦略、hybrid search(vector + keyword)、reranking、評価指標(MRR・Recall@K)のようなものを1つずつ見ていく予定です。RAG システムを実際に回してみたい方は、ぜひ読んでください。

---

FAQ

Q1. Fine-tuning と RAG のどちらか1つを選ぶとしたら?

ほぼほとんどのケースで RAG です。Fine-tuning が輝くのは「話し方・フォーマットがとても厳格で、呼び出し数が1日数万件以上のサービス」に絞られます。それ以外は RAG + 良いプロンプトのほうが、費用・時間対効果で答えになります。

Q2. OpenAI API だけで RAG を作れますか?

embedding(text-embedding-3-small)と Chat Completions は OpenAI が提供しますが、ベクトル DB は別途くっつけないといけません。いちばんシンプルな組み合わせは OpenAI embedding + PostgreSQL + pgvector です。エンジニア1名が週末で POC を作れる規模です。本格運用は Pinecone や Weaviate のような専用 DB に移るのが楽です。

Q3. Claude でも Fine-tuning はできますか?

2026年4月時点で、Anthropic はエンタープライズ顧客向けに Claude fine-tuning を限定的に提供しています(AWS Bedrock・Google Vertex 経由が代表的)。個人開発者がすぐ使えるオプションは OpenAI のほうがずっと開かれていて、オープンソースモデル(Llama 3、Qwen 2.5、Mistral など)を自社ホスティングする方法もよく使われています。

---

ソースリスト (Sources)

• OpenAI, “Fine-tuning” (platform.openai.com/docs) — fine-tuning API・費用・LoRA 対応範囲
• Anthropic, “Prompt Engineering” (docs.anthropic.com) — システムプロンプト・prompt caching
• Anthropic, “Contextual Retrieval” (anthropic.com/research) — RAG の retrieval 品質を高める技法
• OpenAI, “Embeddings” (platform.openai.com/docs/guides/embeddings) — text-embedding-3 系スペック
• Pinecone, “Vector Database Concepts” (pinecone.io/learn) — ベクトル DB アーキテクチャ・費用構造
• Meta AI, “LLaMA 3 Technical Report” — オープンソースモデル fine-tuning 実務リファレンス
• Microsoft, “LoRA: Low-Rank Adaptation of Large Language Models” (arxiv.org/abs/2106.09685) — PEFT/LoRA の原理
• mathbullet YouTube チャンネル — gradient descent の視覚化解説 (F6 連携)

---

ニュースレターのご案内

こうしてひとつひとつの概念を最後まで解きほぐしていく記事を、毎週月曜日の朝にメールでお届けしています。受け取ってみたい方は ニュースレター登録(無料・30秒) からどうぞ。

---

著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)

ソースリスト

• テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
• AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 公式ドキュメント
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス

---

著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。