一言でいうと
この記事を読むと、プロンプト、RAG、ファインチューニングのどれを選ぶか決められます。毎回の指示で直るならプロンプト、更新資料を参照するならRAG、同じ書式・分類の崩れを繰り返し直したいならファインチューニングです。
ファインチューニングは、最新情報を覚えさせる第一選択ではありません。学習済みAIへ追加の練習問題を渡し、回答の書式、文体、分類などの「仕事の型」を調整する方法です。ゼロから新人を育てるのではなく、基礎研修を終えた人に店ごとの接客を練習してもらうイメージです。
まずは「料理人の仕上げ研修」で考える
大規模なAIモデルは、さまざまな文章や画像のパターンを事前に学んだ「基礎力のある料理人」のような存在です。そのままでも多くの注文に応えられますが、店ごとの盛り付け、言葉遣い、注文票の書式までは知りません。
そこで、店が望む完成例を何度も見せます。たとえば「お客さまの質問」「望ましい回答」を一組にした見本を用意し、AIがその傾向を学べるようにします。これがファインチューニングです。一般的には、元のモデルが持つ多数の調整値の一部または全部を、追加データに合わせて少し動かします(2026-07-24 時点)。
ここで重要なのは、社内資料を丸ごと暗記させる方法とは限らないことです。ファインチューニングが得意なのは、答えの「型」「調子」「判断パターン」を繰り返し身につけさせることです。毎日変わる価格表や在庫のような最新情報を参照させたいなら、外部資料を検索して回答に添えるRAGなど、別の仕組みが向いています(2026-07-24 時点)。
何が変わるのか
調整前のAIに「問い合わせへ答えて」と頼むと、説明が長すぎたり、会社で使わない言い回しを選んだりすることがあります。良い見本をそろえて調整すると、次のような傾向を持たせやすくなります。
- 回答を決められた順番や書式で出す
- 特定分野の分類を、社内の区分に合わせる
- 短く丁寧に答えるなど、文体をそろえる
- 入力文から必要な項目だけを抜き出す
- 望ましくない答え方を避ける傾向を学ぶ
ただし、「見本に一度入れた事実なら、いつでも正しく答える」とは考えないほうが安全です。AIの出力は、入力や設定によって変わります。重要な業務では、テスト用の質問集を別に用意し、調整に使わなかった例でも品質を測る必要があります。
同じ問い合わせで見る、調整前と調整後
架空の通販会社が、返品問い合わせを「区分・回答・次の確認」の3項目で処理する例を考えます。入力は調整前後で同じです。
入力
返品したいです。注文番号はA-1842です。箱は開けましたが、商品は使っていません。
調整前の出力例
返品をご希望とのこと、承知しました。一般的には未使用品であれば返品できる可能性がありますが、販売店の返品規約や購入日などによって条件が異なります。詳しい状況を確認させてください。
丁寧ですが、担当者が知りたい分類がなく、次に何を確認するかも曖昧です。人が文章を読み直し、社内の入力欄へ転記する必要があります。
調整後に目指す出力例
区分: 開封済み・未使用
回答: 返品条件を確認します。現時点では受付可否を確定できません。
次の確認: 購入日と返品理由を教えてください。
この例では、新しい返品規約をAIへ覚えさせたのではありません。「3項目で出す」「条件が足りないときは可否を断定しない」という回答パターンを、複数の合格例から学ばせることが狙いです(2026-07-24 時点)。返品期限や例外条件が頻繁に変わるなら、その情報はRAGや業務システムから取得し、ファインチューニングは出力形式の統一に絞るほうが役割を分けやすくなります。
評価するときは「自然に見えるか」だけでなく、たとえば次の3項目を、学習に使っていない同じ評価問題で調整前後に数えます。件数は用途の種類と失敗時の影響を見て決め、測っていない固定値を置きません。
- 区分が正解した件数
- 3項目の書式を守った件数
- 情報不足なのに受付可否を断定した件数
調整前後で同じ問題を比べれば、改善した部分と悪化した部分を確認できます。学習に使った質問をそのまま採点へ回すと、初めて見る問い合わせへの強さを測れないため、評価用の問題は学習用データから分けておきます。
プロンプト、RAG、ファインチューニングの違い
AIを目的に合わせる方法は一つではありません。服装にたとえると、プロンプトは「今日の指示書」、RAGは「必要な資料を入れるかばん」、ファインチューニングは「本人の仕事の癖を育てる研修」です。
| 方法 | 先に選ぶ場面 | 変更時の主な作業 | 注意点 |
|---|---|---|---|
| プロンプト | 指示を変えれば目的を達成できる | 指示文を直す | 長くなると管理しにくい |
| RAG | 更新される情報や根拠を回答に加えたい | 参照資料を差し替える | 検索や資料の整備が必要 |
| ファインチューニング | 同じ形式・分類を多数回繰り返す | データを直して再調整・再評価する | 良い学習例と評価が必要 |
| ゼロからの学習 | 基盤モデル自体を独自に作る | 大規模な学習をやり直す | 大量のデータと計算資源が要る |
まず短いプロンプトで目的を達成できるかを試します。最新資料が必要ならRAG、書式や分類が繰り返し崩れるならファインチューニング、という順で原因に合う手段を選びます。RAGとファインチューニングは二者択一ではなく、「RAGで最新規定を渡し、調整済みAIが決めた書式で返す」という併用もできます(2026-07-24 時点)。
主要サービスの追加学習を公式資料で照合
2026年8月24日に、各社の公式ドキュメントを開いて照合しました。「最低件数」はサービス全体で一つとは限らず、方式や基盤モデルで変わります。確認できない値を推測で補わず、推奨件数と受付上の最低件数も分けました。
| サービス名 | 対応している方式 | 必要な学習データの最低件数の公式記載 | 学習に出したデータの保存と再利用の扱い | 出典URL | 確認日 |
|---|---|---|---|---|---|
| OpenAI API | 教師ありファインチューニング。公式ページでは新規利用者への提供終了と段階的終了を案内 | 最低10例、開始時は良質な50例を推奨 | APIデータは明示的に共有へ同意しない限り基盤モデル改善に使わない。ファインチューニングのアプリ状態は削除まで保持、標準の不正利用監視ログは最大30日。ゼロデータ保持の対象外 | https://developers.openai.com/api/docs/guides/supervised-fine-tuning https://platform.openai.com/docs/models/default-usage-policies-by-endpoint | 2026-08-24 |
| Google Cloud Gemini Enterprise Agent Platform | 教師あり調整、選好調整。調整方法の説明にはパラメータ効率型と全パラメータ型がある | 受付上の単一最低件数は確認できず。効果が出やすい目安として100例以上を案内 | 顧客の許可・指示なしに顧客データを他のAI/MLモデルの学習や調整へ使わない。既定でプロジェクト分離のインメモリキャッシュに最大24時間。学習データと調整済みモデルの削除時期は当該ページで確認できず | https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/tuning https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention | 2026-08-24 |
| Amazon Bedrock | 基盤モデルごとの教師ありファインチューニング。対応形式と制限はモデル別 | 単一値ではない。公式表で5件、32件、100件、1,000件などモデル別の最低値を確認 | 学習・検証データは利用者のS3からサービスロールで読み取る。顧客入力・出力は基盤モデル学習に使わず、モデル提供者とも共有しない。S3側の保存期間は利用者の設定に従う | https://docs.aws.amazon.com/bedrock/latest/userguide/model-customization-prepare.html https://aws.amazon.com/bedrock/faqs/ | 2026-08-24 |
この照合から、件数だけでサービスを選ぶのは危険だと分かります。OpenAIは最低10例と書いていても、新規利用者は現在開始できません。Amazon Bedrockはモデルごとに最低値が違います。候補サービスが決まったら、使う基盤モデル名まで固定して、そのモデルのデータ形式・件数・削除手順をもう一度確認します。
実際にはどう進めるのか
導入は「とりあえずデータを集める」ことから始めません。何を良くしたいかを、採点できる形にすることが先です。
- 目的を一つに絞る
「回答品質を上げる」ではなく、「問い合わせを業務で使う区分へ分類し、調整前と同じ評価問題で正答した割合を上げる」のように決めます。区分数や評価件数は、手元のデータと業務の危険度を確かめてから設定します。 - 良い入出力例をそろえる
実際の質問と、担当者が合格と判断した回答を組にします。同じ質問へ担当者ごとに違う正解を付けず、個人情報や秘密情報は除きます。 - 学習用と評価用に分ける
すべてを練習に使わず、初めて見る問題として採点する分を残します。同じ問い合わせが両方へ入らないよう、重複を確認します。分割比率は固定せず、種類ごとの例が評価側にも残るようにします。 - 小さく調整する
少量の良質な例から始め、元のモデルより改善したかを比べます。 - 失敗例を分類する
書式違反、分類違い、根拠のない断定、余計な説明など、失敗の種類ごとに件数を数えます。 - 本番後も監視する
利用者の入力は評価用データより幅広いため、たとえば週次で誤りを抽出し、分類別の悪化や新しい問い合わせを確認します。監視頻度は利用量と誤答時の影響に合わせます。
学習データの量だけを増やしても、例同士が矛盾していればAIは迷います。「丁寧に長く答える例」と「必ず一文で答える例」が同じ目的で混ざると、望む傾向がぼやけます。料理人に異なる店の盛り付けを同時に教えるようなものです。
調整が裏目に出る四つの例
ファインチューニングは、データに含まれる良い傾向だけを都合よく取り出す工程ではありません。不適切な例、偏り、秘密情報まで学習データへ入れると、望ましくない出力が増えるおそれがあります(2026-07-24 時点)。
| 失敗 | 何が起きるか | 業務への影響 | 調整前に行う対策 |
|---|---|---|---|
| 過学習 | 練習例には合うが、言い換えや初見の質問で崩れる | 評価では高得点でも本番の分類ミスが増える | 学習に使わない評価問題を残し、言い換えでも測る |
| 機密データの混入 | 顧客情報、未公開情報、社内だけの文字列が学習工程へ入る | 情報管理上の事故や、削除・再調整の作業につながる | 収集時と投入直前の2段階で、個人情報・秘密情報を除く |
| 誤った見本の反復 | 古い規定や担当者の誤分類を正解として覚える | 同じ誤りを多数の入力で繰り返す | 見本の承認者と版を記録し、矛盾する例を除く |
| 狭い例への偏り | 一部の商品、言い回し、利用者だけに合う | 少数の表現や例外ケースで性能が落ちる | 種類別に件数を確認し、不足する区分を評価に含める |
特に機密データは、投入後に出力を数回試すだけでは混入の有無を十分に判定できません。学習前に除く工程を置き、利用するAIサービスのデータ保存、学習利用、削除方法、契約条件を確認します(2026-07-24 時点)。混入が判明した場合は、影響するデータと調整済みモデルの利用を止め、組織の情報管理手順に沿って調査します。
過学習を見つけるには、学習時と表現だけを変えた質問も使います。たとえば学習例が「返品したいです」だけなら、評価には「届いた品を返せますか」「未使用なので送り返したい」も入れます。意味が近い初見表現で分類が崩れるなら、練習問題への適合と実務での汎用性を分けて見直せます。
向いている場面、向いていない場面
ファインチューニングは、同じ種類の仕事を何度も行い、良い完成例を用意できる場面に向きます。たとえば、問い合わせの分類、決まったJSON形式での出力、商品説明の社内向け下書きなどです(2026-07-24 時点)。
一方で、次の場面では別の方法を先に検討します。
- 情報が毎日変わるなら、検索やデータベース参照
- 数件しか使わないなら、プロンプトの改善
- 正解例を人間も決められないなら、業務ルールの整理
- 一文字の誤りも許されない計算なら、通常のプログラム
- 法律、医療、契約など重大な判断なら、専門家による確認
また、調整済みAIにも、元のAIが持つ限界や誤りの可能性は残ります。ファインチューニングは「何でも正解する装置」を作る技術ではなく、特定の仕事で望ましい振る舞いを増やす技術です。
費用を見るときの落とし穴
費用は学習時だけではありません。データの整理、個人情報の除去、人による採点、モデル更新後の再評価、本番での監視にも手間がかかります。AIサービスによって、学習料金、利用料金、保存条件、使えるモデルは異なります(2026-07-24 時点)。
比較するときは、次の三つを一緒に見ます。
- 調整前より何点良くなったか
- 人の確認時間が何分減ったか
- 維持と再評価に何時間かかるか
利用回数が少なければ、長いプロンプトを整えるだけのほうが安い場合もあります。反対に、同じ書式の出力を大量に繰り返すなら、指示を短くできることが運用上の利点になる場合があります。
まとめ
ファインチューニングは、学習済みAIへ追加の見本を与え、仕事の型を目的に寄せる「仕上げ研修」です。最新資料を読ませるRAG、毎回の条件を伝えるプロンプトとは役割が違います。迷ったら、まずプロンプトで試し、情報の鮮度が課題ならRAG、反復する形式や分類が課題ならファインチューニング、と原因から選びます。
導入の出発点はモデル選びではありません。「どの仕事を、どんな合格例へ近づけたいか」を決めることです。良い例、別に残した評価問題、人による確認を用意し、正解率、書式違反、危険な断定の件数を調整前後で比べます。改善が一部だけなら、対象業務を狭めるか、プロンプトやRAGへ戻す判断も必要です。
次に読む記事
- 配置の全体判断はローカルAIとクラウドAIの比較
- 意味検索の部品は埋め込みベクトルの仕組み
- 外部資料を都度参照する方法はRAGの仕組み
- 複数形式の入力を扱う場合はマルチモーダルAIの仕組み
一次情報(確認日: 2026-08-24)
- Google「LLM tuning」: 追加学習によるモデル調整と代表的な方式を確認。https://developers.google.com/machine-learning/crash-course/llm/tuning
- OpenAI「Model optimization」: 評価、プロンプト、ファインチューニングを反復する改善手順を確認。https://developers.openai.com/api/docs/guides/model-optimization
- Google「Machine Learning Glossary」: fine-tuning、overfitting、validation setの定義を確認。https://developers.google.com/machine-learning/glossary
- OpenAI「Supervised fine-tuning」: 提供状況、教師あり方式、最低10例と推奨50例を確認。https://developers.openai.com/api/docs/guides/supervised-fine-tuning
- OpenAI「Data controls」: ファインチューニングデータの学習利用、監視ログ、保持期間を確認。https://platform.openai.com/docs/models/default-usage-policies-by-endpoint
- Google Cloud「Introduction to tuning」: 教師あり・選好調整、方式、100例以上の目安を確認。https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/tuning
- Google Cloud「Zero data retention」: 学習利用の制限とインメモリキャッシュを確認。https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention
- AWS「Prepare data for fine-tuning」: モデルごとに異なる最低レコード数とS3入力を確認。https://docs.aws.amazon.com/bedrock/latest/userguide/model-customization-prepare.html
- AWS「Amazon Bedrock FAQs」: 入出力を基盤モデル学習へ使わず、モデル提供者へ共有しない扱いを確認。https://aws.amazon.com/bedrock/faqs/
執筆: テック羅針盤編集部。方法: 3サービスの方式・最低件数・データ扱いを公式資料で横断し、用途選択と調整前後の評価手順へ再構成。最終確認日: 2026-08-24。広告・アフィリエイト: なし。