AIをカスタマイズしたい
ChatGPTやClaudeをそのまま使っても十分便利ですが、「もっと自分の用途に特化させたい」と思う場面は出てきます。
自社の製品知識で回答してほしい。特定のトーンで文章を書いてほしい。専門用語を正しく使ってほしい。最新の社内データを踏まえて回答してほしい。
こういうカスタマイズの方法は、大きく3つあります。それぞれ全く違うアプローチなので、正しく使い分けることが重要です。
3つのアプローチの概要
| プロンプトエンジニアリング | RAG | ファインチューニング | |
|---|---|---|---|
| 何をするか | AIへの指示を工夫する | 参考資料をAIに渡す | AIの脳を追加学習させる |
| 難易度 | 低い（誰でもできる） | 中程度（技術者向け） | 高い（専門知識必要） |
| コスト | ほぼゼロ | 中程度 | 高い |
| データ更新 | 即座（プロンプトを変えるだけ） | 簡単（文書を入れ替えるだけ） | 再学習が必要 |
| 効果の範囲 | その会話のみ | 接続されたデータの範囲 | モデル全体に恒久的に反映 |
プロンプトエンジニアリング — まずここから
AIへの指示（プロンプト）を工夫することで、出力を制御する方法。一番手軽で、一番最初に試すべきアプローチです。
できること
- トーンや文体の指定（「カジュアルに」「学術的に」「小学生にもわかるように」）
- 出力フォーマットの指定（「箇条書きで」「JSON形式で」「表で」）
- 役割の設定（「あなたは経験豊富なマーケターです」）
- 数発の例示（Few-shot）で特定のパターンを学習させる
- 制約の設定（「200文字以内で」「専門用語は使わないで」）
限界
- AIの学習データにない情報は引き出せない
- 毎回同じプロンプトを書く必要がある（システムプロンプトで一部解消可能）
- コンテキストウィンドウの制限がある（長すぎる指示は入らない）
- 複雑なカスタマイズには限界がある
いつ使うか
常に。他のアプローチと組み合わせても、プロンプトの質は常に重要。プロンプトで解決できるなら、それ以上複雑なことをする必要はないです。
RAG — データを渡す
RAG（Retrieval-Augmented Generation）は、AIに「参考資料」を渡して回答させる方法です。別記事で詳しく解説していますが、ここではカスタマイズ手段としての位置づけを整理します。
できること
- AIの学習データにない最新情報・社内情報をもとに回答させる
- 出典付きの回答を生成する
- データの追加・更新が簡単（文書を入れ替えるだけ）
- ハルシネーションを抑制する
限界
- 検索の精度がそのまま回答の質になる
- AIの「振る舞い」（文体、判断の仕方）は変えられない
- ベクトルデータベースのセットアップが必要（技術者向け）
- 大量のデータを扱うにはコストがかかる
いつ使うか
「AIが知らない情報をもとに回答してほしい」とき。社内文書Q&A、最新情報の反映、個人の知識ベースとの連携。事実ベースの質問に強い。
ファインチューニング — AIの脳を改造する
既存のLLMに追加のデータで学習させて、モデルそのものを変更する方法。3つの中で最も強力だけど、最もコストと手間がかかります。
できること
- 特定の文体やフォーマットを「AIの標準動作」にする
- 専門領域の知識や用語を深く理解させる
- 特定のタスクのパフォーマンスを大幅に向上させる
- プロンプトでは実現できない細かい行動パターンの調整
限界
- 学習データの準備が大変（質の高い事例が数百〜数千件必要）
- 学習にコストがかかる（数万円〜数十万円）
- データを更新したら再学習が必要
- やり方を間違えるとモデルの性能が劣化する（catastrophic forgetting）
- 最新のクラウドモデル（Claude、GPT-4o）のフルファインチューニングは一般には開放されていない場合がある
いつ使うか
プロンプトでもRAGでも実現できないケースに限る。具体的には：
- 非常に特殊な文体やフォーマットを常に維持したい
- 特定のタスク（分類、情報抽出など）の精度を極限まで上げたい
- 推論コストを下げたい（小さいモデルをファインチューニングして、大きいモデルと同等の性能を出す）
判断フローチャート
「自分のケースではどれを使うべきか」を判断するための流れです。
- プロンプトで解決できる？ → Yes → プロンプトエンジニアリングで終了
- AIが知らない情報が必要？ → Yes → RAGを検討
- AIの「振る舞い」自体を変えたい？ → Yes → ファインチューニングを検討
- プロンプト + RAGの組み合わせで十分？ → Yes → ファインチューニング不要
実際のところ、90%以上のユースケースはプロンプトエンジニアリングとRAGの組み合わせで対応できます。ファインチューニングが本当に必要なケースは少ない。
組み合わせて使う
これら3つは排他的ではなく、組み合わせて使えます。
プロンプト + RAG（最も一般的）
「この文書を参考にして」（RAG）＋「カジュアルなトーンで、300文字以内で」（プロンプト）。ほとんどの実用的なAIアプリはこの組み合わせで動いています。
ファインチューニング + RAG
ファインチューニングで文体や判断基準を調整したモデルに、RAGで最新データを渡す。企業向けのチャットボットなどで使われるパターンです。
全部組み合わせ
ファインチューニングしたモデルに、RAGでデータを渡し、プロンプトで細かい指示を出す。最も強力だけど、最も複雑。大規模なプロダクトでないと割に合わない。
コスト比較
| アプローチ | 初期コスト | 運用コスト | 必要スキル |
|---|---|---|---|
| プロンプト | ゼロ | API利用料のみ | 不要（誰でも） |
| RAG | 数万円（構築） | ベクトルDB＋API利用料 | プログラミング基礎 |
| ファインチューニング | 数万〜数十万円 | モデルホスティング費 | ML/AIの知識 |
結論 — シンプルなものから試す
AIのカスタマイズは「プロンプト → RAG → ファインチューニング」の順に複雑さとコストが上がります。
原則は「最もシンプルな方法で目的を達成する」こと。プロンプトで十分ならプロンプトで済ませる。RAGで解決できるならファインチューニングは不要。
技術の世界では「一番複雑な方法が一番良い」という思い込みがありがちですが、AIのカスタマイズに関しては逆です。シンプルな方法ほどメンテナンスしやすく、柔軟で、コストが低い。複雑な方法は「それでしか解決できない」ケースに取っておく。
まずはプロンプトを工夫するところから始めてみてください。それだけで驚くほど多くのことが実現できます。
]]>