2026年10月8日に、OpenAIのModel optimizationとSupervised fine-tuningを再読しました。先に代表的な評価と基準結果を用意し、プロンプト・例・必要な情報を改善してから、残る失敗が追加学習で変わるかを比較します。教師ありファインチューニングは例示データを使う手段で、データ品質、未使用評価、回帰確認、提供条件を含む反復が必要です。最新情報や権限の問題を学習だけで解決しません。
プロンプトを直すか、モデルを追加学習するか。選択の出発点は、同じテストで「何が失敗しているか」を見分けることです。指示が曖昧なのか、必要な最新情報がないのか、書式や分類が安定しないのかで、先に直す場所は変わります。
30秒で要点
- 指示・例・文脈を改善した基準結果を作り、学習後も同じ未使用テストで比較する。
- 最新情報の不足は検索やツール、応答の傾向の調整は追加学習の検討対象。組み合わせることもできる。
- 学習件数・精度・総費用に一律の順位はない。データ整備、人の確認、再評価まで含めて判断する。
スーツの比喩から、変える場所を分ける
プロンプトは既製のスーツの着こなし、ファインチューニングは仕立て直し、と考えると違いをつかめます。ただし、仕立て直せば必ず良くなるわけではありません。合わない採寸に相当する誤った教師データなら、望ましくない癖も学びます。
プロンプトエンジニアリングは、推論時に渡す指示や例、文脈を設計することです。ファインチューニングは、事前学習済みモデルを追加データで学習し、学習可能なパラメータを調整することです。両者は排他的な選択ではありません。
表が収まらない場合は、横にスクロールできます
| 手段 | 主に変える場所 | 残る仕事 |
|---|---|---|
| プロンプト | 指示・具体例・出力形式・役割 | 代表的なテストでの評価、版管理、長さの管理 |
| RAG・ツール | 検索資料や計算結果などの入力 | 権限、情報鮮度、引用元、誤取得の確認 |
| ファインチューニング | 学習可能なパラメータ | 教師データ、学習と評価の分離、劣化の監視 |
RAGは、検索した資料を生成時の文脈に加える方法です。知識を更新するたびに必ず学習し直す必要がある、という意味ではありません。モデル変更だけでなく、資料取得や人への引き継ぎを含む工程も比較します。
最初に評価を作る
OpenAIの最適化ガイドも、評価で基準を作り、指示と文脈を調整し、必要な用途で追加学習を検討して、代表的な入力で再評価する流れを説明しています。これはOpenAI固有の案内であり、すべてのモデルで同じ改善率を約束するものではありません。業務と許容できない誤りを定義
→ 学習に使わない評価用データを確保
→ 現行モデル＋指示の基準結果
→ 指示・検索・学習の候補を比較
→ 採用または保留、更新後も同じ基準で再確認評価データを見ながら何度も調整したら、そのデータも開発に使ったことになります。最後に別の未使用データで確認します。正解率だけでなく、少数クラスの見逃し、形式違反、危険な回答、人が直す時間を分けて測ります。
まずプロンプトで確かめる5項目
表が収まらない場合は、横にスクロールできます
| 操作 | 具体的な変更 | 確認すること |
|---|---|---|
| 明確な指示 | 作業と禁止事項を分ける | 指示の矛盾が減ったか |
| 文脈の提供 | 対象文書と適用日を渡す | 必要な情報を参照できたか |
| 例の提供 | 正例と境界例を示す | 例以外の入力でも使えるか |
| 出力形式 | 項目名と欠損時の扱いを決める | 後続処理で読めるか |
| 役割の指定 | 文体・対象読者を決める | 専門家の資格や事実確認と混同していないか |
作業：提示した問い合わせを「請求」「操作」「要確認」に分類する。
根拠：本文にある情報だけを使う。
不明時：「要確認」とし、不足項目を1つ挙げる。
出力：分類 / 本文中の根拠 / 不足項目。
評価：未使用の問い合わせで分類と不明時の振る舞いを別に確認する。これは架空の指示教材です。実顧客データやAPI送信は含めていません。「プロンプトはデータも専門知識も不要」という旧説明は不適切です。少なくとも評価用の例と、業務上の正しさを判断できる人が必要です。
学習方法にも違いがある
表が収まらない場合は、横にスクロールできます
| 方法 | 調整するもの | 選ぶ際の注意 |
|---|---|---|
| 全パラメータの追加学習 | モデル全体の重み | 計算・保存・運用負担。常に最高精度とは限らない |
| LoRA | 凍結した元の重みに低ランクの学習行列を加える | 対象モデル・層・データに依存する |
| プロンプトチューニング | 学習する連続値のプロンプト | 人が文章で指示を編集する方法とは別 |
事前学習済みモデル
→ 権利と品質を確認した学習用の入出力例
→ 追加学習（方式と対象を固定）
→ 未使用テストで基準モデルと比較
→ 品質・費用・運用条件を満たす場合だけ採用必要なのは「数千件」という合言葉ではない
OpenAIのSFT資料には、最小10例、良く作った50例から評価して始めるという製品固有の説明があります。一律に数千件が必要とは言えません。ただし少数で十分とも限らず、代表性・正確さ・難しい境界例の質が重要です。確認日2026年10月6日のOpenAI最適化ガイドは、ファインチューニング基盤の縮小と新規利用者が利用できない旨も案内しています。上の件数は資料の適用範囲を説明するもので、今からそのサービスを契約できるという案内ではありません。実際に選ぶサービスの利用資格・対応モデル・終了予定を確認してください。一般的な学習技法と、特定サービスの提供状況は別です。
精度と費用を同じ条件で比べる
次は架空の分類テストです。両方式を同じ未使用100件で比べたという設定で、実モデルの測定結果ではありません。
表が収まらない場合は、横にスクロールできます
| 指標 | 指示を改善した基準 | 学習した候補 |
|---|---|---|
| 正しく分類できた件数 | 82/100 | 88/100 |
| 正解率 | 82% | 88% |
| 誤分類件数 | 18 | 12 |
正解率の差は6ポイント、誤分類の相対減少は(18−12)÷18＝約33.3%です。同じ数を「精度が33.3%上がった」とは書けません。この小さな架空計算だけで統計的な有意差も分かりません。同じ入力でどの誤りが入れ替わったか、重大な誤りが増えていないかも見ます。
表が収まらない場合は、横にスクロールできます
| 費用の内訳 | プロンプト側にも必要 | 追加学習で加わりうるもの |
|---|---|---|
| 初期 | 要件、例、評価、人件費 | データ整備、学習、比較実験 |
| 運用 | 入出力トークン、検索、人の確認 | 推論単価、モデル保管・提供条件 |
| 改善 | 指示更新、再評価 | 再学習、回帰確認、移行 |
仮に追加の初期費用が12万円、1件当たりの総運用費が0.6円減るなら、単純な回収件数は120,000÷0.6＝200,000件です。あくまで架空の損益計算で、実価格ではありません。再学習費や人の修正時間が増えれば結果は変わります。差が0円以下なら、この式で費用回収はできません。
3つの想定場面で判断する
旧稿の業務例は成果が確認された事例ではありません。次の比較計画として扱います。
表が収まらない場合は、横にスクロールできます
| 想定場面 | 先に試すもの | 追加学習の判断材料 |
|---|---|---|
| ブログ下書き | 構成・例・出典確認の工程 | 文体の一貫性が不足し、評価と良質な例が揃うか |
| 専門的な医療文書の分類 | 専門家が定義した分類と評価、権利・安全条件 | 特定方式が最高精度とは断定せず、重大な見逃しと運用条件を比較 |
| 顧客対応 | 検索資料、回答範囲、不明時の人への引き継ぎ | 最新情報の取得と応答傾向の調整を分け、両方が必要か |
用途が決まらないまま学習を発注すると、使い道のないモデルが残るかもしれません。一方、場当たり的な長い指示を増やし続けると、変更時の影響を追えなくなります。この2つの失敗像は、導入の実績談ではなく点検項目です。
基準結果で不足する点は何か？
指示の曖昧さ → 指示・例を改善
最新情報の不足 → 検索・ツールを改善
安定した応答傾向 → データと体制を確認して追加学習を比較
評価不能・責任不明 → 運用を設計してから再検討
各経路 → 同じ評価基準へ戻る。十分なら継続、不十分なら修正・保留。まず「誰のどの業務で、どの誤りを許容しないか」を1文にし、代表的な入力と正解を集めます。AIの費用の内訳と導入時の責任分界を合わせて確認すると、技術の優劣だけで決めずに済みます。
参考資料
- OpenAI Model optimization、Supervised fine-tuning：評価手順・例数・現行提供条件の必要範囲。
- Huほか、LoRA、Lesterほか、Prompt Tuning：2021年の一次研究の要旨、技法の定義。全文再現実験ではありません。
- プロンプト入門、LLMの基礎：用語の補足。