1. はじめに
この記事を作成する背景は、Fine Tuning の方式やモデルを選んでも、学習データの形式、件数、品質、パラメータ、評価方法が曖昧なままでは、改善を再現できないことです。トレーニングジョブが成功しても、ベースモデルより実用上の品質が上がったとは限りません。
本記事の目的は、Microsoft Foundry で Fine Tuning を実行するためのデータ設計、ジョブ設定、評価、デプロイの手順を整理することです。方式、対応モデル、料金、デプロイ方式の選び方は Part 1 で扱っています。
2. Fine Tuning のワークフロー
実装は、次の順序で進めます。
[1] 目的と評価指標を決める
↓
[2] ベースモデルの評価結果を保存する
↓
[3] トレーニング用・検証用 JSONL を準備する
↓
[4] Foundry Portal／SDK／REST API でジョブを作成する
↓
[5] 学習メトリクスとチェックポイントを確認する
↓
[6] 同じ評価セットでベースモデルと比較する
↓
[7] デプロイして Playground／API で受け入れテストする
↓
[8] 失敗例をデータへ戻し、必要な場合だけ再学習する
最初に「何を改善するか」と「合格条件」を固定します。たとえば、構造化出力なら JSON Schema 準拠率、分類なら正解率や F1、文体なら人手またはモデル評価器のルーブリック、RFT なら Grader の妥当性を評価します。
Fine Tuning 前のベースモデルに同じ評価セットを実行し、品質、トークン数、レイテンシ、コストを記録します。この比較対象がなければ、学習後の変化を効果として説明できません。
3. JSONL データを設計する
Microsoft Foundry の Fine Tuning では、JSON Lines（JSONL）形式のデータを使います。確認基準日時点のファイル要件や各手法のスキーマは、公式手順を正としてください。[^fine-tuning-guide]
3.1 共通要件
- 1 行に 1 サンプルを置く JSONL
- 文字コードは UTF-8（確認基準日時点の手順では BOM 付きが案内されていた）
- 1 ファイル 512 MB 以下
- トレーニングデータと検証データを別ファイルにする
- 学習データへ個人情報、機密情報、不要な識別子を含めない
- 本番で使う system message、出力形式、表記ルールをデータ全体でそろえる
最低件数を満たすことよりも、対象タスクを正しく代表し、誤りのない例をそろえることが重要です。重複や矛盾した例は、モデルへ望ましくないパターンを学習させます。
3.2 手法ごとのフィールド
| 手法 | 主なフィールド | データの考え方 |
|---|---|---|
| SFT | messages、各要素の role と content | 入力と、実際に出してほしい模範回答をそろえる |
| DPO | input.messages、preferred_output、non_preferred_output | 同じ入力に対する良い応答と悪い応答の差を明確にする |
| RFT | messages、solution など Grader が読むフィールド | 最終メッセージを user とし、採点に必要な正解情報を持たせる |
| Vision | messages[].content 内の text と image_url | 画像と指示に対する期待出力をテキストで用意する |
SFT のマルチターンデータでは、assistant メッセージの weight を使い、学習対象にする応答を選べる場合があります。DPO と RFT のスキーマ、対応モデル、制限はそれぞれの公式手順を確認してください。[^fine-tuning-dpo][^fine-tuning-rft]
3.3 SFT の JSONL 例
1 行が 1 サンプルです。
{"messages":[{"role":"system","content":"あなたは Xbox サポート担当です。簡潔に答えてください。"},{"role":"user","content":"Wi-Fi に接続できません"},{"role":"assistant","content":"設定 > ネットワーク > 詳細設定から接続テストを実行し、失敗する場合はルーターを再起動してください。"}]}
system message と回答方針を例ごとに変えないことが重要です。回答を簡潔にしたいなら、学習データの全回答も同じ粒度にそろえます。
3.4 DPO の JSONL 例
{"input":{"messages":[{"role":"system","content":"あなたは丁寧なカスタマーサポートです。"},{"role":"user","content":"返品方法を教えてください"}]},"preferred_output":[{"role":"assistant","content":"マイページの注文履歴から返品申請を選択してください。ご不明点があればお問い合わせください。"}],"non_preferred_output":[{"role":"assistant","content":"マイページから自分で手続きしてください。"}]}
好ましくない応答は、単に不自然な文章にするのではなく、実運用で避けたい振る舞いを含めます。良否の差が曖昧なペアを増やすと、何を学習すべきかが不明確になります。
3.5 RFT の JSONL 例
{"messages":[{"role":"system","content":"あなたは数学の問題を段階的に解く家庭教師です。"},{"role":"user","content":"x^2 - 5x + 6 = 0 の解は?"}],"solution":"x = 2, x = 3"}
RFT では、Grader が solution とモデル応答を比較して報酬を計算します。文字列一致、コード実行、モデルベースなど、Grader の種類によって必要なフィールドとリスクが変わります。[^fine-tuning-rft]
3.6 Vision データの要点
Vision Fine-Tuning では messages[].content を配列にし、text と image_url を同じ入力へ含め、assistant の期待出力を付けます。画像 URL または Base64 データを使えるかは、対象モデルの手順で確認してください。画像のライセンス、個人情報、解像度、クラス間の件数差も検査します。
4. データセットの規模と品質
4.1 件数の目安
確認基準日時点の Microsoft Learn では、少数例からジョブを開始できる一方、まず高品質な例を集め、評価しながら増やす方針が案内されていました。[^fine-tuning-considerations] 次の件数は計画用の目安であり、品質を保証する基準ではありません。
| 規模 | 主な用途 | 判断 |
|---|---|---|
| 10〜49 件 | スキーマ、権限、ジョブの動作確認 | 品質改善の結論には使わない |
| 50〜数百件 | PoC、初期比較 | 失敗分類ごとの不足を確認する |
| 500〜数千件 | 本番候補の評価 | 検証データとエッジケースを厚くする |
| 数千件以上 | 高難度、複数パターン | 重複、偏り、データ来歴を継続管理する |
データを増やす前に、現在の失敗が「例不足」「ラベル誤り」「指示の矛盾」「モデル能力の限界」のどれかを切り分けます。原因がモデル能力や外部知識の不足なら、データ追加だけでは解決しません。
FAQ なら問い合わせと承認済み回答、DPO なら良い／悪い応答ペア、構造化出力なら入力と厳密な JSON／SQL、RFT なら問題・正解・採点ルールを中心に集めます。件数はタスクの多様性、出力長、クラス数で変わるため、固定目標ではなく評価セットの失敗を減らせるかで追加量を決めます。
4.2 品質チェックリスト
- system message、出力形式、表記が全例で一貫している
- 模範回答を業務責任者または専門家が確認している
- 完全重複と近似重複を除いている
- 個人情報、秘密情報、認証情報、不適切表現をレビューしている
- エッジケースと、分類タスクのクラス間バランスを確認している
- 検証データが本番分布を代表し、学習データと重複していない
- データの作成元、承認者、版、利用許諾を追跡し、JSONL を機械検証している
5. ジョブとハイパーパラメータ
最初のジョブでは自動設定を使い、結果をベースラインとして保存します。手動調整は、評価結果から原因を説明できる場合に限ります。確認基準日時点の主な設定は次のとおりです。[^fine-tuning-guide]
5.1 ジョブ全体の設定
| 設定 | 内容 | 確認点 |
|---|---|---|
model | Fine Tuning 対象の基本モデル | 対応手法、バージョン、リージョン |
method／customization_method | supervised、dpo、reinforcement | モデルが手法に対応しているか |
training_type | Standard、Global、Developer | データ所在地、料金、SLA |
training_file | トレーニング JSONL のファイル ID | 対象版を固定したか |
validation_file | 検証 JSONL のファイル ID | 学習データと重複していないか |
suffix／seed | モデル名の識別子／再現性を補助する整数 | 実験名と条件を対応付けたか |
auto_deploy | 学習後の自動デプロイ | 対応モデルと必要権限 |
継続 Fine Tuning を行う場合は、Fine Tuning 済みモデルを model に指定できるかを確認します。前回データと今回データの違い、評価結果、モデル ID を実験記録へ残します。
5.2 SFT の主なハイパーパラメータ
| パラメータ | 役割 | 調整を検討する状況 |
|---|---|---|
batch_size | 1 ステップで使う例数 | データ規模に対して学習が不安定 |
learning_rate_multiplier | 基本学習率へ掛ける係数 | 損失が下がらない、または振動する |
n_epochs | データセットを反復する回数 | 過学習、または学習不足が見られる |
最初は auto を使います。train_loss が下がっても検証損失が上がる場合は過学習を疑い、エポック数や学習率、データの重複を見直します。一度に複数の値を変えず、実験ごとの差分を追跡します。
5.3 DPO と RFT の追加設定
DPO の beta は、参照モデルからの乖離と嗜好データへの適合のバランスに関わります。値だけを調整する前に、preferred／non-preferred の差が一貫しているかを確認します。[^fine-tuning-dpo]
RFT では、次の設定と Grader を一体で設計します。[^fine-tuning-rft]
| 設定 | 役割 |
|---|---|
eval_interval | 検証セットを採点する間隔 |
eval_samples | 1 回の検証で使うサンプル数 |
compute_multiplier | 1 ステップ当たりの探索量 |
reasoning_effort | Rollout 生成時の推論量 |
| Grader | 文字列一致、コード、モデルなどによる採点ロジック |
RFT では train_reward_mean だけでなく、検証側の報酬、タスク正答率、Grader が誤って高得点を付ける例を確認します。学習報酬だけが上がる場合は、報酬ハッキングを疑います。
5.4 調整の進め方
- 全パラメータを
autoにしてベースラインジョブを実行する - 学習損失、検証損失、正確性、RFT の報酬を確認する
- 同じ評価セットでベースモデルと Fine Tuning 後モデルを比較する
- 過学習ならエポック数、学習率、データ重複を見直す
- 学習不足ならデータ品質を確認してから学習率やバッチサイズを検討する
- 各エポックのチェックポイントも評価する
- 改善した失敗と悪化した失敗を分類し、次のデータ追加へつなげる
6. Foundry Portal で実行する
確認基準日時点の Foundry Portal では、Fine-tune 画面から OpenAI モデルのジョブを作成できました。画面名、ロール、対応モデルは変更される可能性があるため、実行時は公式手順を確認してください。[^fine-tuning-guide]
- Foundry Portal で対象プロジェクトを開き、Fine-tune 画面からジョブを作成する
- Base model、SFT／DPO／RFT、Standard／Global／Developer を要件に合わせて選ぶ
- トレーニング用と検証用の JSONL を登録する
- 初回は Hyperparameters を自動設定にする
- ジョブ名、データ版、評価セット版を記録して送信する
- 完了後にメトリクスとチェックポイントをベースモデルと比較する
- 合格したモデルだけをデプロイし、Playground と API で受け入れテストする
7. 評価、デプロイ、継続運用
7.1 評価する指標
| 観点 | 指標例 | 注意点 |
|---|---|---|
| 学習・検証 | loss、token accuracy | 検証データを学習データと分ける |
| タスク | 正解率、F1、Schema 準拠率、専門家評価 | 導入目的に直結する指標を使う |
| RFT | train／validation reward、Grader 誤判定 | 報酬ハッキングを確認する |
| 運用・安全性 | トークン、遅延、コスト、有害出力、拒否 | ベースモデルと同条件で比較する |
最も損失が低いチェックポイントが、必ずしも業務指標で最良とは限りません。各チェックポイントを同じ評価セットで比較し、改善量と悪化したケースを残します。
7.2 デプロイ前の確認
- データ所在地、SLA、容量要件を満たし、推論とホスティングを含む月額を再計算した
- 本番と評価で同じ system message を使い、ガードレールを含めてテストした
- ロールバック先のモデルとデプロイ設定を記録した
- 未使用デプロイの削除など、サービス固有のライフサイクルを運用へ組み込んだ
デプロイ方式の比較と制約は Part 1 を参照してください。デプロイの作成方法と利用可能な方式は公式手順で確認します。[^fine-tuning-deploy]
7.3 反復改善
本番や受け入れテストで失敗した入力を、そのまま学習データへ追加してはいけません。
- 失敗を分類し、期待結果と重大度をレビューする
- プロンプト、RAG、アプリロジックで直すべき失敗を除く
- 残った例の重複、個人情報、ラベル品質を確認し、検証用の未見例も追加する
- データ版、モデル版、パラメータ、評価結果を関連付ける
再学習のたびに評価セットを都合よく変えると比較できません。固定した regression セットと、新しい失敗を含む追加セットを分けて管理します。
8. まとめ
Fine Tuning では、評価可能な目的、整合した JSONL、独立した検証データ、再現できる実験記録が重要です。初回は自動パラメータでベースラインを作り、ベースモデルと同じ条件で品質、コスト、安全性を比較します。改善したモデルだけをデプロイし、本番の失敗を次のデータ版へつなげます。
9. 参考情報
- Microsoft Foundry の Fine Tuning 完全ガイド — 方式・モデル・コスト（Part 1／全 2 回） — 方式、モデル、料金、デプロイの選定
- Customize a model with fine-tuning — データ要件、ジョブ作成、Portal の手順
- Direct preference optimization — DPO のデータと設定
- Reinforcement fine-tuning — RFT と Grader
- Deploy a fine-tuned model — デプロイ方式と手順
- AIFoundry-Customization-Datasets — SFT、DPO、RFT の公式サンプルデータ
- azure-ai-foundry/fine-tuning — MedMCQ、ClauseMatching などのサンプル
- Fine-tuning considerations — データ量と Fine Tuning の判断
[^fine-tuning-guide]: Customize a model with fine-tuning — Microsoft Learn（確認日: 2026-05-11）
[^fine-tuning-dpo]: Direct preference optimization — Microsoft Learn（確認日: 2026-05-11）
[^fine-tuning-rft]: Reinforcement fine-tuning — Microsoft Learn（確認日: 2026-05-11）
[^fine-tuning-considerations]: Fine-tuning considerations — Microsoft Learn（確認日: 2026-05-11）
[^fine-tuning-deploy]: Deploy a fine-tuned model — Microsoft Learn（確認日: 2026-05-11）
