Azure OpenAI Studioでファインチューニングを送信した瞬間に「Standard TrainingType is not supported」と出て止まる、しかもトレーニングタイプの切替欄が見当たらない――この現象は多くの場合、選んだモデル×リージョン（またはサブスクリプション）が標準（教師あり）方式に非対応なだけです。原因の切り分けと、確実に前へ進める回避策をまとめます。
「Standard TrainingType is not supported」が意味すること
結論から言うと、このエラーは学習データの形式ミスというより、その環境で「Standard（標準＝教師あり/SFT）」のファインチューニングが使えないことを示しているケースがほとんどです。特に、ベースモデルとして gpt-4o-2024-08-06 のような新しめのモデルを選んだときに出やすく、テナント／リージョン／サブスクリプションの組み合わせによりStandardが提供されていないと発生します。
重要なのは、これは「あなたの操作ミス」ではなく提供形態の差で起きる点です。Azure側では、同じ“モデル名”でも、利用できるファインチューニング方式が環境によって変わることがあります（例：リージョン差、プレビュー提供差、制限付き機能の有効化差など）。
トレーニングタイプの変更項目が見つからない理由（UIの仕様）
「トレーニングタイプをStandard以外に変えれば良さそうなのに、切替欄がない」という点が混乱の元ですが、ここも仕様です。
- ポータル（Studio/Foundry）はモデルの対応状況を見て自動的に方式を判定します。
- その結果、手動で切り替える余地がない場合はUIに選択肢が出ません。
- Standardが選ばれてしまって非対応なら、送信時に弾かれてこのエラーになります。
「出てこない＝バグ」ではなく、「出てこない＝その場で選ばせる設計になっていない（または選択肢がない）」と捉えると切り分けが楽になります。
まず最短で直す：対応ベースモデルに切り替える
最短ルートはこれです。Standard（教師あり/SFT）をやりたいなら、SFTに対応しているモデルをベースに選び直します。Microsoft Foundryのドキュメント上、SFTは幅広いモデルでサポートされており、GPT-4o/4o-miniやGPT-4.1系が代表です。
ただし、ネット記事や過去の回答でよく挙がる gpt-35-turbo 系のバージョンは、時期によっては退役（Retirement）に到達している可能性があります。実際、ドキュメント上は gpt-35-turbo の特定バージョンに退役日が設定されています。古い手順をそのまま踏むと「そもそも候補に出ない」「作れない」につながるため、いま使える候補は必ずモデル一覧で確認してください。
対処の早見表（症状→原因→打ち手）
| 症状 | 一番ありがちな原因 | 推奨アクション |
|---|---|---|
| Standard TrainingType is not supported | 選択モデル×リージョン（またはサブスク）がStandard/SFT非対応 | SFT対応モデルに変更／対応リージョンへ切替／Global Trainingを検討 |
| トレーニングタイプの選択欄がない | UIが自動判定（選択肢がない） | モデル/リージョン/方式いずれかを変える |
| jsonlValidationFailed など別系統のエラー | データ形式不備（messages配列/role/content等） | データ構造を修正（今回の主因とは別） |
| quotaExceeded / forbidden / unauthorized | クォータ不足、権限不足、機能制限 | ロール付与／クォータ調整／管理者と確認 |
「Standard」「SFT」「DPO」「RFT」…用語を揃えて理解する
ポータルやドキュメントで、似た言葉が混在します。この記事では次の対応で捉えます。
- Standard（標準）：多くの場面で「教師あり（入力→望ましい出力）」の文脈で使われる
- SFT（Supervised Fine-Tuning）：教師ありファインチューニング（入力と正解出力のペアで学習）
- DPO（Direct Preference Optimization）：「良い/悪い」の比較を使って好みへ寄せる（報酬モデル不要）
- RFT（Reinforcement Fine-Tuning）：報酬信号を使う強化学習ベース（正誤が比較的明確な領域に向く）
どの技術が選べるかはモデルによって違い、SFT/DPO/RFTそれぞれ対応モデルが定義されています。
方式選びの実務的な判断基準
| やりたいこと | 向く方式 | 判断のコツ（現場の目線） |
|---|---|---|
| 文章の型・口調・定型フォーマットを安定させたい | SFT | 「入力→理想出力」が用意でき、例示で揺れが減りきらないならSFTが効きやすい |
| “どちらが好ましいか”の比較データがある（安全/丁寧/社内流儀など） | DPO | 正解が1つではないが、好みの方向は明確なときに強い |
| 数学・検証可能な推論など、正誤判定ができる・採点できる | RFT | 評価関数（グレーダー）を設計できるなら伸び幅が出る |
| そもそも学習まで要るか迷う（少量の例で足りそう） | まずはプロンプト/テンプレ | “例を数個入れたら安定する”レベルなら学習コストより運用が軽い |
Global（プレビュー）/ Global Training が使えるなら、選択肢になる
Standard（リージョン固定）の学習が非対応でも、テナントやポータルの状態によってはGlobal Training（パブリックプレビュー）が提供されている場合があります。Global Trainingは、提供リージョンが広く、コスト面のメリットが提示されることもあります（ポータル上の表示や選択可否で判断されます）。
一方で、Global系のオプションはデータの扱い（保存場所や一時保管の考え方）が標準のリージョントレーニングと同一とは限りません。社内規定でデータ所在地に厳しい場合は、プレビューの注意事項・データ取り扱い方針を踏まえて判断してください。
RFT（強化学習ベース）に切り替えるべきケース
Standard（SFT）が使えない環境で、かつ「出力の正誤を採点できる」タイプのタスクなら、RFTが選択肢になります。ただしRFTは、SFTよりも設計・評価の難易度が上がり、データ形式や要件も増える傾向があります。
目安としては次の通りです。
- 採点者（グレーダー）設計ができる（自動採点 or 人手採点の運用が組める）
- タスクの正解が比較的明確（数学、物理、ルールベースで検証できる領域など）
- 「口調」より「達成率（正答率）」を上げたい
実務で詰まりやすいポイントのチェックリスト
同じエラーでも、周辺条件の見落としで「対処したのに直らない」ことがあります。現場での確認順を、上から潰すのが効率的です。
モデル・リージョン・ライフサイクル
- 選んだベースモデルが、そのリソースでfine-tune可能か（後述のModels List APIで即確認できます）
- リージョンが対応しているか（同じモデルでもリージョンで差が出ます）
- 退役済みモデルを参照していないか（古い記事の指定モデル名に要注意）
権限・クォータ・同時実行制限
- ファインチューニングに必要なロール/権限が付与されているか（環境によって要件が変わる）
- クォータ不足や同時実行上限に引っかかっていないか（「実行中ジョブは同時に1つ」などの制約は運用に効きます）
データ形式（今回の主因ではないが、次に当たりやすい）
- JSONLの各行が壊れていないか（改行、エスケープ、文字コード）
messages配列、role、contentの構造が推論時と整合しているか- 学習用と検証用を分けるべき方式（RFTなど）で、必要ファイルを満たしているか
具体的な回避手順（ポータル操作の例）
ポータル画面は更新されるため文言が微妙に違うことがありますが、流れはほぼ共通です。
- ポータル（Azure OpenAI Studio / Microsoft Foundry）で Fine-tuning を開き、新規ジョブ（Fine-tune model）を選びます。
- ベースモデルを変更します。ポイントは「SFT（教師あり）で学習できるモデル」を選ぶことです。候補が少ない場合は、まず後述のAPIで
capabilities.fine_tuneを確認すると無駄が減ります。 - 学習データ（JSONL）をアップロードして送信します。
- もし同じエラーが続く場合は、次の順で切り替えます。
- 対応リージョンのリソース（またはプロジェクト）で作り直す
- Global（Preview）/ Global Training が選べるなら、そちらで作成する
- SFTではなく、DPO/RFTに適したユースケースなら方式から見直す
APIで「対応可否」を事前確認する（Models List API）
UIで試行錯誤する前に、そのAzure OpenAIリソースが“fine-tune可能なモデル”を持っているかをAPIで確認すると早いです。Models List APIは、利用可能なモデル一覧と、capabilities.fine_tune（学習可否）を返します。
確認用リクエスト例（curl）
curl -sS "https://{your-resource-name}.openai.azure.com/openai/models?api-version=2024-10-21" \
-H "api-key: {YOUR_API_KEY}"レスポンス内で見るべきポイントは次の通りです。
capabilities.fine_tuneがtrue：そのモデルはファインチューニング候補になり得るdeprecation.fine_tune：学習サポート終了時刻（UNIX time）が入る場合があるlifecycle_status：preview/generally-availableなど
ここで「fine_tuneがtrueのモデルがほぼ出ない」なら、リージョンや提供形態の問題で、そのリソースでは学習自体が難しい可能性があります。逆に、fine_tuneがtrueのモデルを選んでいるのにStandard不可なら、Standard（SFT）ではなく別の方式だけが許可されているなど、方式側の差異が疑わしくなります。
「それでも直らない」場合の追加の見立て
モデルはfine-tune可能なのにStandardだけ不可
- そのモデルはDPO/SFTのどちらか、あるいはGlobal Training専用の提供になっている可能性
- ポータルのプレビュー機能がテナントで有効化されておらず、UIがStandardへ寄ってしまっている可能性
モデル名は合っているのに候補に出ない
- モデルの退役に到達している（古い手順を踏んでいる）
- リソースのリージョンで、そのモデルがまだ提供されていない／既に提供が絞られている
ジョブが作れたが運用で困る（地味に多い）
- 「同時に走る学習ジョブは1つ」等の上限で、CI/CD的な回し方が詰まる
- ファイル総量上限（例：合計サイズ）で、データ更新のたびに入れ替えが必要になる
この辺りは、設計時点で「学習を頻繁に回すのか」「評価だけ回すのか」を分けておくと、手戻りを減らせます。
よくある質問（FAQ）
学習データ（JSONL）のせいで、このエラーが出ることはありますか？
今回の「Standard TrainingType is not supported」という文言に限っては、データ形式の不備よりも方式の非対応が主因であることが多いです。データ不備なら jsonlValidationFailed など別のエラーになりやすい、という切り分けができます。
「Standard」がだめなら、必ずGlobal（プレビュー）で解決しますか？
必ずではありません。Globalはテナント側の提供状況や、ポータル上での選択可否に依存します。また、データ所在地制約がある組織では採用できないこともあるため、運用要件とセットで判断してください。
教師あり（SFT）とDPO、どちらを選ぶべきですか？
「理想の出力」が明確な入力→出力ペアで作れるならSFTが基本です。一方、正解が1つではなく「好ましい/好ましくない」の比較で品質・安全・文体を寄せたいならDPOが向きます。
“UIが自動判定”なら、ユーザーができることは少ない？
できることは明確で、モデルを変える、リージョン（リソース）を変える、方式（SFT/DPO/RFT/Global）を変えるの3点です。逆に言えば、UIのどこかに隠しスイッチがあるタイプの問題ではありません。
まとめ（現場向けの結論）
- 「Standard TrainingType is not supported」は、モデル×リージョン／サブスク条件でStandard（教師あり/SFT）が使えないことが原因になりやすい。
- トレーニングタイプの切替欄が出ないのは、UIが自動判定する仕様であり不具合ではない。
- 最短の解決は、SFT対応モデルへの変更と、必要なら対応リージョンへの切替。
- Global TrainingやDPO/RFTなど、方式の選び直しがハマる場合もある。
- 「今のリソースで何ができるか」は、Models List APIでcapabilitiesを確認すると調査が爆速になる。
コメント