RAGとファインチューニングの違いと使い分け｜判断基準とコストで選ぶ2026年の実装方針

社内文書をLLMに答えさせたいとき、RAGとファインチューニングのどちらを選ぶかで迷う場面は多いはずです。ただし2026年8月現在、この問いの前提が変わりました。OpenAIは2026年5月7日に自社のセルフサービス型ファインチューニングの新規受付を停止しており、これから検討する組織はOpenAI APIでファインチューニングを選べません。ここでは両者が解く問題の違い、いま実際に選べる基盤、価格表から算出したコストの実額、そして動くコードまでを整理します。

まとめ：RAGとファインチューニングの使い分け結論

結論から言えば、社内文書やFAQのように「モデルが知らない事実」を答えさせたいならRAG、出力の書式や語調を安定させたいならファインチューニングです。両者は競合する選択肢ではなく、解いている問題そのものが違います。

単価は1Mトークンあたりのドル建てで、OpenAIの料金ページ（2026年8月14日時点）の実値です。ただし請求総額を決めるのは単価ではなく投入トークン量で、RAGが上回る場合があります。実額の試算は後述します。

用途で言えば、就業規則や製品カタログのように内容が更新される情報を答えさせるならRAG、決まったJSONスキーマで返させたい、あるいは社内の言い回しに寄せたいならファインチューニングです。以下では、この使い分けをどの数値で判断するかを順に見ていきます。

RAGとファインチューニングが解く問題の違い

RAGが埋めるのは「モデルが知らない事実」

RAGという語の出典は、Patrick Lewisらが2020年5月22日に投稿した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」（arXiv:2005.11401）です。この論文はモデルの重みに畳み込まれた知識をパラメトリック記憶、外部に置いた密ベクトル索引を非パラメトリック記憶と呼び、両者を組み合わせる構成を提案しました。論文では検索した文章を生成全体で共有するRAG-Sequenceと、トークンごとに別の文章を参照できるRAG-Tokenの2つの定式化が示されています。

実務上の意味は単純です。就業規則が改定されたら、索引を作り直せば翌日から新しい回答になります。モデルには一切手を触れません。知らない事実を推測で埋めるハルシネーションも、検索して当てた文書を根拠として示させることで抑えられます。

ファインチューニングが固定するのは「出力の型」

ファインチューニングは、追加の学習データでモデルの重みを更新する手法です。OpenAIの精度最適化ガイドはこの違いを、教科書を持ち込んで調べながら答えるのがRAG、半年間の授業で解き方の型を身につけるのがファインチューニングだと説明しています。したがって「先月の売上はいくらか」という事実質問にファインチューニングで答えさせようとすると、数字が変わるたびに再学習が要ります。

一方で、決まった書式で返させたい、社内の言い回しに寄せたいといった要求は、プロンプトに例を並べるよりも重みに焼き付けたほうが安定します。

ナレッジベース検索とRAGの違い

ナレッジベース検索は、キーワードやベクトルで該当する文書そのものを返す仕組みです。利用者は返ってきた文書を自分で読みます。RAGはその検索結果をLLMのコンテキストに詰めて、回答文を生成させるところまで含みます。

つまりRAGはナレッジベース検索を部品として内包する上位の構成であり、対立する技術ではありません。ElasticsearchのようなQAで使える全文検索基盤がすでにあるなら、その検索結果を messages のシステムメッセージへ渡す層を1枚足すだけでRAGになります。検索の質がそのまま回答の質を決めるため、索引の作り方は精度に直結します。索引構築の工程についてはRAGのIndexingとは？索引構築の工程とNaive・Advanced・Modular RAGの違いで扱っています。

プロンプト設計・RAG・ファインチューニングの適用順序

OpenAIの精度最適化ガイドは、RAGやファインチューニングのような複雑な手法に手を伸ばす前に、基本的な手法から絞り出せる精度を絞り切るよう推奨しています。まずプロンプトエンジニアリングで指示と実例を詰め、それでも事実が足りないならRAG、出力の型が揺れるならファインチューニングという順序になります。

同ガイドは、記憶の問題を「学習で身につける記憶」と「その場で参照する記憶」の2軸に分けたうえで、この2つの最適化手法について「additive, not exclusive—they stack」（加算的であって排他的ではない、積み重ねられる）と述べています。つまり併用は可能です。ただし機械的に全部盛りにするのではなく、仕事に合った道具を選べと釘を刺しています。プロンプト側の設計論はPrompt Engineeringとの違いで理解するContext Engineeringの本質と全体像にまとめています。

2026年8月時点でファインチューニングを選べる基盤・選べない基盤

OpenAI APIのセルフサービス型は新規受付を終了

本記事の執筆時点で確認した範囲では、日本語の主要な比較記事はこの点に追随できていません。OpenAIは料金ページ上で、セルフサービス型ファインチューニング基盤を縮小中であり、新規ユーザーには開放していないと明記しています。廃止情報ページには2026年5月7日の通知として、次のスケジュールが載っています。

推論自体は、ベースモデルが廃止されるまで継続して利用できます。とはいえ、これから検討を始める組織にとっては選択肢がすでに閉じているということです。「RAGとファインチューニングを比較して決めましょう」と書かれた記事を読んで検討を始めても、OpenAI APIでは後者の入口がありません。まずここを確認してください。

付け加えると、OpenAIでファインチューニング可能なモデルはgpt-4.1系とgpt-4o系、そしてo4-miniで、ほかにgpt-3.5-turboとdavinci-002、babbage-002がlegacy扱いで残るのみです。gpt-5系は対象外でした。ファインチューニングを選ぶことは、1世代前のモデルに固定されることも意味していたわけです。

Microsoft Foundryとオープンウェイトという代替

ファインチューニング自体が消えたわけではありません。Microsoft Foundry（旧Azure AI Foundry）の微調整ドキュメント（更新日2026年7月30日）は、gpt-4o-mini、gpt-4o、gpt-4.1、gpt-4.1-mini、gpt-4.1-nanoの教師ありファインチューニングをGAとして提供しており、gpt-4o以降はDPOにも対応しています。o4-miniとgpt-5は強化ファインチューニング枠で、gpt-5へのアクセスは招待制のゲートがかかっています。

さらに同ドキュメントには、Llama-3.3-70B-Instruct、Qwen-32B、Ministral-3B、gpt-oss-20bといったオープンウェイトモデルの教師ありファインチューニングがパブリックプレビューとして並んでいます。自前でLoRAを回す道も当然残っています。手法の選択についてはPEFTとLoRAの違いとは？仕組み・使い方・QLoRA/DoRAとの比較を実装例つきで解説を参照してください。

コストと応答時間で比較するRAGとファインチューニングの実額

本記事の執筆時点で確認した日本語の比較記事は「RAGは安い」で終わっていますが、実際に計算すると条件次第で逆転します。OpenAIの公開価格（1Mトークンあたり、2026年8月14日時点）を使って試算しましょう。

社内文書3万件、1件あたり平均800トークンを索引化する場合、埋め込みは2,400万トークンで初回0.48ドルです。索引化コストは実質無視できます。効いてくるのは推論側です。

月1万件の問い合わせを処理し、RAGでは上位5チャンク（各400トークン）と質問・指示200トークンを毎回投げるとします。入力2,200トークン、出力400トークンで、月額は入力44.00ドルと出力32.00ドルの計76.00ドルになります。質問文をベクトル化する費用は月0.04ドルで、こちらも無視して差し支えありません。一方ファインチューニング済みモデルで検索文脈を渡さず入力200トークンに抑えると、単価は1.5倍でも入力6.00ドルと出力48.00ドルの計54.00ドルです。学習は50件×1,000トークンなら1.25ドルで済みます。

RAGのほうが高くつきました。理由は明快で、RAGは毎リクエストで検索結果ぶんの入力トークンを払い続けるからです。呼び出し回数が多く、渡す文脈が長いほど不利になります。ただしこの試算はファインチューニングで事実まで答えられる前提であり、実際には事実質問の精度が担保できません。コスト差22ドルは、知識更新のたびに再学習を回す運用コストで簡単に消えます。

応答時間にも同じ構図が出ます。RAGは検索の往復が1回増えるうえ、投入する入力トークンが200対2,200で11倍です。入力が長いほど最初のトークンが返るまでの時間は延びるため、対話用途でレイテンシを詰めたい場合はチャンク数の削減が最初の打ち手になります。

RAGの構成要素と最小実装

RAGの構成要素は、文書を分割するチャンク処理、テキストをベクトル化する埋め込みモデル、近傍を引く検索、そして生成モデルの4つです。埋め込みはtext-embedding-3-smallが1536次元、text-embedding-3-largeが3072次元で、いずれも最大入力は8192トークン。dimensions パラメータで次元を短縮でき、保存コストを削れます。

チャンク分割と上位k件の取得

チャンク分割は固定長で切るより、見出しなど文書構造の境界を優先したほうが検索精度が安定します。以下は境界優先で分割し、L2正規化済みベクトルの内積で上位k件を返す最小実装です。

import numpy as np

def split_by_heading(doc, max_chars=400):
    """見出し行(#始まり)を境界にし、超過分だけ max_chars で追加分割する"""
    chunks, buf = [], ""
    for line in doc.splitlines():
        if line.startswith("#") and buf:
            chunks.append(buf.strip())
            buf = ""
        buf += line + "\n"
        if len(buf) >= max_chars:
            chunks.append(buf.strip())
            buf = ""
    if buf.strip():
        chunks.append(buf.strip())
    return chunks

def top_k(query_vec, doc_vecs, k=3):
    """L2正規化済みベクトル前提。内積をコサイン類似度として上位k件の添字を返す"""
    return np.argsort(-(doc_vecs @ query_vec))[:k].tolist()

doc = "# 返品規定\n未開封の商品は到着後14日以内に限り返品できます。\n# 送料\n5,000円以上の注文は送料無料です。\n# 保証\n保証期間は購入日から1年間です。\n"
print(len(split_by_heading(doc)))

この例は3を出力します。見出しごとに1チャンクへ切れているという意味です。max_chars は分割を発火させるしきい値で、行の途中では切らないため実際のチャンクはこれをやや上回ります。1行120文字の行が5本続く節では、最初のチャンクが488文字になります。一方、見出し行が来れば必ず切れるので、短い節が無理に結合されることはありません。

埋め込みの取得と生成への引き渡し

埋め込みAPIの呼び出しはモデル名と入力テキストを渡すだけです。レスポンスは data 配列で返り、各要素の embedding がベクトル本体になります。以下は前節の続きで、question は利用者の質問文です。

from openai import OpenAI

client = OpenAI()
question = "返品はいつまでできますか"
chunks = split_by_heading(doc)

def embed(texts):
    res = client.embeddings.create(input=texts, model="text-embedding-3-small")
    vecs = np.array([d.embedding for d in res.data])
    return vecs / np.linalg.norm(vecs, axis=1, keepdims=True)

hits = top_k(embed([question])[0], embed(chunks), k=3)
context = "\n\n".join(chunks[i] for i in hits)

あとは context をシステムメッセージに埋め込み、「与えた文脈のみを根拠に答え、無ければ不明と答える」と指示します。この一文が無いと、モデルは検索結果を無視して自分の記憶で答えます。検索の順位付けを複数クエリで改善する手法はRRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説で、検索と生成のどちらが劣化しているかを分けて測る方法はRAGCheckerとは｜RAGを検索と生成に分けて診断するAmazonの評価フレームワークで扱っています。

ファインチューニングの学習データ形式と必要件数

教師ありファインチューニングの学習ファイルはJSONL形式で、1行が1件の会話です。role と content を持つ messages 配列を並べ、ツール呼び出しを学習させる場合は tool_calls と tools を併記します。

件数について、OpenAIのドキュメントは最小10件と定めたうえで、50件の丁寧に作られた実例から始めることを推奨しています。効果については「50〜100件のファインチューニングで改善が見られるが、適切な件数は事例ごとに大きく異なる」と明記されています。数千件を用意しなければ始められないという理解は誤りです。

逆に言えば、50件のデータで変えられるのは出力の型までです。50件の質疑応答で社内知識を覚えさせようとしても、モデルは口調だけを真似て中身を作ります。

RAGを選んで失敗する典型パターン

RAGは万能ではありません。OpenAIの精度最適化ガイドは、アイスランド語の事例でRAGを追加したところBleuスコアが4ポイント下がり83になったと報告しています。同ガイドはこれを、追加の文脈が必ずしもモデルを助けない「振る舞いの最適化」の問題だったと説明しています。RAGが解くのはコンテキスト内の学習課題だけであり、それ以外の問題には効きません。報告や構成上の制約から、失敗は次の4つの型に整理できます。

検索を測らず生成プロンプトだけを直す型

RAGの精度問題の大半は検索側で起きます。生成モデルを上位版に替えても、そもそも当たっていない文書を渡している限り改善しません。検索と生成を分けて測ってから、どちらを直すか決めてください。

集計・横断的な問いに検索で答えようとする型

「昨年度の全案件で最も多かった不具合は何か」といった質問は、上位5件のチャンクを見ても答えが出ません。この種の問いは検索ではなく集計であり、素のRAG構成では原理的に解けません。SQLや集計処理を別に用意します。実体間の関係をたどる問いであれば、グラフ構造を索引に持つGraphRAGをAzureで動かす方法｜Accelerator終了後の現行構成と実装手順【2026年版】の構成が選択肢になります。

チャンクを細かく切りすぎて文脈が壊れる型

200文字で機械的に切ると、条件を述べた文と結論を述べた文が別チャンクに分かれます。結果として、条件を落とした回答が生成されます。前掲のコードのように文書構造の境界を優先すれば、この破断はかなり防げます。

文書が整備されていない組織に導入する型

これは言い切っておきます。ドキュメントが整備されていない組織にRAGを入れても失敗します。RAGは検索対象の品質をそのまま増幅する仕組みであり、古い規程と新しい規程が両方置いてあるフォルダを索引化すれば、モデルは古いほうを堂々と引用するでしょう。導入前にやるべきは基盤の選定ではなく、文書の棚卸しです。

よくある質問

RAGとファインチューニングは併用できますか？

併用できます。OpenAIの精度最適化ガイドはこの2つの最適化手法について、加算的であって排他的ではない（additive, not exclusive）と明記しています。出力形式をファインチューニングで固め、事実はRAGで供給する構成が典型です。ただし同ガイドは、すでにファインチューニングでタスクを学習済みのモデルにRAGを足したところ、Bleuスコアが4ポイント下がって83になった事例も挙げています。併用は自動的に精度を上げる打ち手ではないため、片方ずつ効果を測ってから積み上げてください。

ナレッジベースとRAGは何が違いますか？

ナレッジベース検索は該当する文書を返して終わり、読むのは利用者です。RAGは検索結果をLLMのコンテキストに渡し、回答文の生成まで行います。RAGはナレッジベース検索を部品として内包する構成であり、置き換え関係にはありません。既存の全文検索やベクトル検索の基盤があるなら、その結果をプロンプトへ渡す層を追加するだけでRAGとして機能します。回答品質は検索の当たり方でほぼ決まるため、投資すべきは生成モデルより索引の設計です。

ファインチューニングはもう使えないのですか？

OpenAI APIのセルフサービス型については、2026年5月7日以降、過去に実行実績のない組織は新規のジョブを作成できません。2027年1月6日には既存の利用組織も作成できなくなります。ただし推論はベースモデルが廃止されるまで継続します。Microsoft Foundryではgpt-4.1系やgpt-4o系の教師ありファインチューニングがGAで提供されており、Llama-3.3-70B-InstructやQwen-32Bなどオープンウェイトモデルの教師ありファインチューニングもパブリックプレビューで利用できます。

ファインチューニングに必要な学習データは何件ですか？

OpenAIのドキュメントでは最小10件と規定され、まず50件の丁寧に作られた実例から始めることが推奨されています。効果の目安として50〜100件で改善が見られるとされていますが、適切な件数は用途によって大きく変わるとも書かれています。数千件を集めないと着手できないという理解は不要です。ただし50件規模で変えられるのは出力の書式や語調までで、社内知識そのものを覚えさせる用途には足りません。事実の供給はRAG側の役割です。

RAGのコストはどのくらいかかりますか？

索引化は安価です。3万件の文書を平均800トークンとして埋め込むと2,400万トークンで、text-embedding-3-smallの単価0.02ドル（1Mトークン）なら初回0.48ドルにしかなりません。負担は推論側に出ます。上位5チャンク（各400トークン）と質問200トークンを毎回渡し、月1万件処理するとgpt-4.1の標準単価で月76.00ドル。呼び出し回数と渡す文脈長にほぼ比例するため、チャンク数を5件から3件に減らすだけでも入力コストは目に見えて下がります。

関連記事

• RAGのIndexingとは？索引構築の工程とNaive・Advanced・Modular RAGの違い
• RRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説
• RAGCheckerとは｜RAGを検索と生成に分けて診断するAmazonの評価フレームワーク
• Agentic RAGのアーキテクチャと構成要素を詳しく解説
• PEFTとLoRAの違いとは？仕組み・使い方・QLoRA/DoRAとの比較を実装例つきで解説