Skip to content
Published on

RAG vs ファインチューニング vs プロンプトエンジニアリング：何をいつ選ぶか

🇰🇷KO🇺🇸EN🇯🇵JA
Split View
Authors

AIプロダクトチームが必ず聞く質問

「サービスにAIを組み込みたいのですが、どのアプローチを使えばいいですか？」

この質問は何百回と耳にしてきた。スタートアップのCTO、大企業の開発リード、個人でサイドプロジェクトを作っているエンジニアまで — 全員が同じ判断ポイントに直面する。そしてほとんどの人が「とりあえずファインチューニングしてみよう」か「RAGパイプラインを構築しよう」と性急に動いてしまう。

正直な答えを先に言う：プロンプトエンジニアリングから始めよう。プライベートな知識や最新情報が必要になったらRAGを追加する。ファインチューニングは本当に最後の手段だ。 ファインチューニングが必要なケースは、多くの人が思うよりずっと少ない。

この記事では、3つのアプローチの特性を正直に比較し、実際の判断基準を提供する。

3つのアプローチとは何か

まず定義を整理しよう。

プロンプトエンジニアリングはLLMに渡す入力自体を最適化する手法だ。システムプロンプトの作成、few-shotサンプルの追加、Chain-of-Thoughtの誘導などが含まれる。モデルの重みは一切変更しない。

**RAG（Retrieval-Augmented Generation）**は外部の知識ベースから関連ドキュメントを検索し、LLMにコンテキストとして渡す手法だ。モデルが知らない情報を「リアルタイムで検索して」提供する方式だ。

ファインチューニングは事前学習済みのLLMをドメイン固有のデータで追加学習させる手法だ。モデルの重み自体を変更する。

3つのアプローチの特性比較

特性プロンプトエンジニアリングRAGファインチューニング
初期コスト最低中程度高い
構築速度即時（数時間）早い（数日）遅い（数週間）
知識の更新即時即時再学習が必要
専門知識の習得弱い中程度強い
必要データなしドキュメント群ラベル付きデータセット
ハルシネーションリスク高い低い中程度
運用複雑度低い中程度高い
スタイル・形式の制御中程度中程度強い

この表で最も重要なのは**「知識の更新」と「ハルシネーションリスク」**の列だ。RAGがファインチューニングよりハルシネーションリスクが低い理由は、モデルが「生成」するのではなく、取得したドキュメントから「引用」するよう誘導できるからだ。

意思決定フレームワーク

Q1: 最新情報または社内非公開ドキュメントが必要か？
    YES → RAGを検討
    NO  → 次の質問へ

Q2: 特定のスタイル・形式・ドメイン専用言語が必要か？
    YES → ファインチューニングを検討
    NO  → プロンプトエンジニアリングから始める

Q3: RAGを試したが検索品質が継続的に悪い？
         （ドメイン特化の用語をモデルが理解できないなど）
    YES → RAG + ファインチューニングの組み合わせ
    NO  → RAGのみで十分

Q4: プロンプトエンジニアリングだが一貫性が不足？
    YES → few-shotサンプルを追加するかファインチューニングを検討
    NO  → 現在のアプローチを継続

Q1の「社内ドキュメント」とはFAQ、製品マニュアル、Confluence、Notion、Slackのアーカイブなど、ベースLLMが学習データに持っていない全ての内部情報を指す。このような情報にはRAGが必要だ。

Q2の「ドメイン専用言語」とは医療記録の略語体系、法律文書の特定フォーマット、特定企業のコーディング規約などを指す。一般的な技術文書の作成や要約は、ファインチューニングなしでも十分機能する。

実戦ケーススタディ3選

1. 顧客サポートチャットボット → RAG

B2B SaaSの顧客サポート自動化を構築するとしよう。製品FAQ、リリースノート、ユーザーガイドが数百件ある。

RAGが正解だ。理由：

  • ドキュメントは頻繁に更新される（新機能追加のたびに）
  • 製品固有の正確な情報が必要（ハルシネーション許容不可）
  • モデルが新しい文体を学ぶ必要はない

ファインチューニングを選んだ場合、ドキュメントが更新されるたびに再学習が必要になり、コストと時間が爆発する。

2. 医療記録の要約 → ファインチューニング

病院のEMR（電子医療記録）システムで診療記録を自動要約するシステムを作るとしよう。

ここではファインチューニングが本当に必要だ。理由：

  • Hx of HTN, DM2, CKD3 のような医学略語を正確に解釈しなければならない
  • SOAPノート形式（Subjective-Objective-Assessment-Plan）を正確に遵守する必要がある
  • 汎用LLMは医学用語の微妙なニュアンスを見逃す可能性がある

ただし、RAGと組み合わせるケースも多い。医学ガイドラインのドキュメントを検索ベースとして、ファインチューニングされたモデルが生成するパターンだ。

3. コードレビューアシスタント → プロンプトエンジニアリング + Few-shot

チームのコードレビューを補助するAIを作るとしよう。

Few-shotを使ったプロンプトエンジニアリングで十分だ。理由：

  • LLMはすでにコードを深く理解している
  • プロンプトに3〜5つのレビュー例を入れるだけでチームのスタイルにすぐ適応する
  • 高価なファインチューニングや複雑なRAGインフラは不要
SYSTEM_PROMPT = """You are a senior engineer doing code review.
Review style: direct, constructive, with specific line references.

Example reviews:
---
[EXAMPLE 1]
Code: for i in range(len(items)): process(items[i])
Review: Use enumerate() instead — cleaner and more Pythonic:
  for i, item in enumerate(items): process(item)
---
[EXAMPLE 2]
Code: try: result = api_call() except: pass
Review: Never use bare except. Catch specific exceptions and log them:
  try: result = api_call()
  except RequestException as e: logger.error(f"API call failed: {e}"); raise
---
Now review the following code:"""

実際のコスト計算

1日10,000件のクエリを処理するサービスを想定しよう。GPT-4o料金を基準に概算すると：

プロンプトエンジニアリングのみ

  • クエリあたり平均1,000トークン（入力800 + 出力200）
  • 月300万件 × 0.005ドル/1Kトークン ≈ 月 約150ドル
  • 追加インフラコスト：ほぼゼロ

RAG追加

  • トークン増加：取得コンテキストで約2,000トークン追加
  • トークンコスト：月 約450ドル（3倍増）
  • ベクターDB（Pineconeなど）：月 約70ドル
  • 月間総運営費：約520ドル

ファインチューニング

  • 学習コスト（GPT-4oファインチューニング）：100万トークンのデータで約25ドル（1回限り）
  • 推論コスト：ファインチューニングモデルは基本モデルより20〜50%高い
  • 月間総運営費：約180〜225ドル + 再学習コスト

結論：RAGはトークンコストが上がるが、社内ドキュメントが必要なら選択の余地がない。ファインチューニングは推論コストだけ見れば悪くないが、定期的な再学習とラベリング人件費を合算すると実際にははるかに高コストになる。

3つを組み合わせる場合

エンタープライズレベルのAIプロダクトでは、3つを組み合わせるパターンが効果的だ：

[System Prompt]               <- プロンプトエンジニアリング
"あなたはABC社の専門サポートエージェントです。
 常に丁寧に、ユーザーの言語で回答してください。"

[Retrieved Context]           <- RAG
"関連ドキュメント：[FAQ #127] 返品ポリシーは30日以内..."

[User Query]
"注文した商品を返品したいのですが。"

[Fine-tuned Model]            <- ファインチューニング
ドメイン用語の理解 + 会社のトーン＆マナーを内在化

この組み合わせが最良の結果を生む理由：

  • システムプロンプト：役割と制約の定義
  • RAG：最新の正確な情報の提供
  • ファインチューニング：ドメイン語彙の理解と一貫したスタイル

ただし、この組み合わせは構築と運用が複雑だ。MVP段階では過剰なエンジニアリングになる。

シンプルな意思決定ヘルパーのコード

def choose_approach(
    has_private_docs: bool,
    needs_latest_info: bool,
    has_training_data: bool,
    budget: str  # 'low', 'medium', 'high'
) -> str:
    """
    プロジェクトの特性に基づいて推奨アプローチを返す。
    """
    if has_private_docs or needs_latest_info:
        if has_training_data and budget == 'high':
            return "RAG + Fine-tuning (ハイブリッドアプローチ)"
        return "RAG"

    if has_training_data and budget in ['medium', 'high']:
        return "Fine-tuning (まずプロンプトエンジニアリングを試すこと)"

    return "Prompt Engineering (ここから始めて高速イテレーション)"


# 使用例
print(choose_approach(
    has_private_docs=True,
    needs_latest_info=True,
    has_training_data=False,
    budget='medium'
))
# 出力: "RAG"

よくある失敗

失敗1：ファインチューニングを最初の選択肢にする ファインチューニングは最後の手段だ。GPT-4oに良いシステムプロンプトを与えるだけで、ファインチューニングの効果のほとんどが得られる。

失敗2：RAGを万能の解決策だと思う RAGは検索品質に完全に依存している。関連ドキュメントをうまく取得できなければ、どんなに優れたLLMでも意味がない。チャンキング戦略と埋め込み品質が鍵だ。

失敗3：評価なしでデプロイする どのアプローチを選んでも、定量的な評価なしに「感覚」でデプロイしてはいけない。RAGASのようなツールで測定しながら改善すること。

結論：段階的アプローチ

  1. プロンプトエンジニアリングから始める → 1日で最初のバージョンを完成させる
  2. 社内ドキュメントが必要になったらRAGを追加 → 数日で構築可能
  3. ドメイン特化が本当に必要な時だけファインチューニングを検討 → 数週間の投資価値があるか判断する

「最初から完璧なシステムを作ろうとして何もデプロイできない」罠にはまらないようにしよう。プロンプトエンジニアリングから始め、実際のユーザーフィードバックを見ながら段階的に複雑さを上げていくのが、現実的に最も速い道だ。

Discuss on Twitter • View on GitHub