2026年5月20日に更新された「Microsoft Azure documentation update: Update model version and update azure.yml」は、Azure OpenAIを使うサンプル／テンプレート環境で、古いgpt-35-turboモデルバージョンの廃止に備えるための更新です。結論から言うと、確認すべきポイントは「モデルバージョン」「利用リージョン」「azure.yamlのフック設定」「PowerShell Core前提の実行環境」の4つです。既存環境にそのまま影響するAzure全体の仕様変更ではありませんが、該当テンプレートを使っている管理者・開発者は、デプロイ失敗やモデル廃止後の停止を避けるために、設定の棚卸しを早めに行うべきです。(GitHub)
Microsoft Azureの「Update model version and update azure.yml」は何が変わったのか
今回の更新は、Azureのenterprise-azureaiリポジトリに対するPull Requestとしてマージされた変更です。PRには、古いgpt-35-turboモデルの廃止に対応するためモデルバージョンを更新し、azure.yml、実際の変更ファイルとしてはazure.yaml、および.shスクリプトを整理したことが記載されています。あわせて、READMEの要件も更新されています。(GitHub)
重要なのは、この更新を「Azure OpenAI全利用者に自動適用される仕様変更」と誤解しないことです。今回の変更は、特定のテンプレート／サンプル構成に含まれるBicep、Azure Developer CLI設定、スクリプト、READMEの更新です。ただし、そこに含まれる論点は実運用でも重要です。古いモデルバージョンの廃止、リージョンごとのモデル提供状況、azdフックの実行方式は、本番環境のデプロイや移行計画にも直結します。
| 変更領域 | 主な変更内容 | 確認すべき人 |
|---|---|---|
| Azure OpenAIモデル | gpt-35-turboの古いバージョン廃止を踏まえたモデルバージョン更新 | Azure OpenAI利用者、AIアプリ開発者 |
| Bicepテンプレート | 利用可能リージョン、モデルバージョン判定、APIM SKUの条件分岐を更新 | IaC管理者、クラウド管理者 |
azure.yaml | OS別のsh実行から、pwsh中心のフック実行へ整理 | azd利用者、DevOps担当者 |
| シェルスクリプト | 複数の.shファイルを削除し、PowerShell Core前提に寄せる | Mac/Linux/Windows混在チーム |
| README | MacでPowerShellが必要である旨を追加 | ローカル環境を構築する開発者 |
変更点の中心はAzure OpenAIのモデルバージョン更新
PRの説明では、古いモデルの廃止によりgpt-35-turboのモデルバージョンを更新したとされています。変更差分では、Bicep内のモデルバージョン判定が、従来の0301／0613系から、1106／0125系を使う形に変更されています。(GitHub)
これは、Azure OpenAIを使うアプリケーションでよくある「モデル名だけ見て安心してしまう」問題への対策です。Azure OpenAIでは、gpt-35-turboのようなモデル名だけでなく、デプロイされているモデルバージョンも確認する必要があります。モデル名が同じでも、バージョンによって提供リージョン、API互換性、廃止時期、応答傾向が変わる可能性があります。
Microsoftのモデルライフサイクル説明では、モデルはプレビュー、一般提供、廃止へと進み、利用者は代替モデルを評価して移行する必要があります。モデルの提供終了日はモデルごとに異なるため、運用中のデプロイがどのバージョンを使っているかを把握しておくことが重要です。(Microsoft Learn)
管理者が最初に確認すべきモデル設定
Azure OpenAIを運用している場合、まず確認すべきなのは「アプリが呼び出しているデプロイ名」と「そのデプロイの中身」です。アプリケーションコードにはgpt-35-turboではなく、独自に作成したデプロイ名が設定されているケースが多いためです。
確認すべき項目は次の通りです。
| 確認項目 | 見るべき内容 | 判断基準 |
|---|---|---|
| デプロイ名 | アプリが参照しているAzure OpenAIのデプロイ名 | コード、環境変数、Key Vault、App Service設定を確認 |
| モデル名 | gpt-35-turboなど | 想定したモデルファミリーか |
| モデルバージョン | 0301、0613、1106、0125など | 廃止済み、廃止予定、利用可能な代替か |
| リージョン | japaneast、eastusなど | 対象モデルバージョンがそのリージョンで利用可能か |
| アップグレード設定 | 自動更新、廃止時更新、手動固定など | 本番環境の変更管理方針と合っているか |
Microsoftのドキュメントでは、Azure OpenAIの一部デプロイでは自動モデル更新がサポートされ、OnceNewDefaultVersionAvailable、OnceCurrentVersionExpired、NoAutoUpgradeといった更新オプションがあると説明されています。NoAutoUpgradeの場合、廃止日を過ぎるとデプロイが動作しなくなるため、検証環境ならともかく本番環境では慎重な管理が必要です。(Microsoft Learn)
Bicepテンプレートではリージョンとモデルバージョンの判定が更新された
今回のPRでは、infra/main.bicepも更新されています。差分では、Azure OpenAI Service向けに許可されるリージョンのリストが変更され、説明文もgpt-35-turbo向けであることが分かる形に更新されています。また、セカンダリリージョンの説明も「空欄の場合は無効」という意図が明確になっています。(GitHub)
ここで注意すべきなのは、リージョンは単なるデプロイ先ではなく、利用できるモデルとバージョンを左右する条件だという点です。たとえば、日本の利用者であればjapaneastを優先したくなりますが、利用したいモデルバージョンやSKUがそのリージョンで使えるとは限りません。逆に、米国や欧州のリージョンを使うとモデル選択肢が広がる場合がありますが、データ所在地、社内規程、レイテンシ、コストの確認が必要になります。
リージョン選定で失敗しやすいポイント
Azure OpenAIの移行では、モデルバージョンだけを見てリージョンを後回しにすると失敗しやすくなります。特に次のようなケースは要注意です。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 既存リージョンのまま新モデルへ変更しようとする | 対象バージョンが選択できない | 先にモデル提供リージョンを確認する |
| プライマリとセカンダリで異なるモデルを使う | フェイルオーバー時に応答品質や制限が変わる | 両リージョンのモデル名・バージョンをそろえる |
| APIMやネットワーク構成を見直さない | ルーティングや認証でデプロイ後に失敗する | IaC、APIM、Private Endpointをまとめて確認する |
| 日本リージョン前提で検証を省略する | 本番切り替え時にモデル非対応が判明する | 検証環境でも本番候補リージョンを使う |
今回の差分では、APIM V2 Tierの利用可能リージョン配列を追加し、場所に応じてAPIM SKUの既定値をStandardV2またはDeveloperに切り替えるような変更も含まれています。これは、同じテンプレートでもリージョンによって利用できるSKUや構成が変わることを前提にした調整と見てよいでしょう。(GitHub)
azure.yamlの更新でクロスプラットフォーム対応が整理された
今回の更新では、azure.yamlのフック設定も大きく整理されています。従来はposixではsh、windowsではpwshを実行するようOS別に分けていましたが、差分ではpwshでPowerShellスクリプトを実行する形に整理されています。(GitHub)
Azure Developer CLIのazure.yamlは、azdプロジェクトの構成ファイルです。サービス、Azureリソース、インフラストラクチャ、フック、CI/CDパイプラインなどを定義し、azd up、azd provision、azd deployなどの実行時にCLIから読み取られます。(Microsoft Learn)
今回の変更を実務目線で見ると、「OSごとに別スクリプトを管理するより、PowerShell Coreを共通ランタイムとして使う」方向への整理です。Windows、macOS、Linuxの混在チームでは、Bash版とPowerShell版の処理差分がバグになりやすいため、スクリプトを一本化できるメリットがあります。
azure.ymlではなくazure.yamlを確認する
PRタイトルにはazure.ymlとありますが、変更されたファイル一覧ではazure.yamlが対象になっています。実務ではこの違いが意外と重要です。リポジトリ内にazure.ymlとazure.yamlの両方がある、またはCI/CD側が別名ファイルを参照している場合、修正したつもりでもazd実行時に読まれていないことがあります。
確認時は、プロジェクトルートで次の点を見てください。
ls -la見るべきポイントは、azure.yamlがプロジェクトルートにあるか、CI/CDパイプラインがどのファイルを参照しているか、古いazure.ymlが残っていないかの3点です。ファイル名の揺れを放置すると、ローカルでは成功するのにGitHub ActionsやAzure DevOpsでは失敗する、という切り分けしづらいトラブルにつながります。
.shスクリプト削除の影響はMac/Linux利用者ほど大きい
PRでは、scripts/appreg.sh、scripts/cleanup.sh、scripts/deploy-azurechat.sh、scripts/set-az-currentsubscription.sh、scripts/set-env.shの削除が含まれています。これは、Posix環境でもPowerShell Coreのpwshを使う前提に寄せた変更と読み取れます。(GitHub)
Windows利用者はもともとPowerShellに慣れているため影響を感じにくいかもしれません。しかし、MacやLinuxでBash中心に作業していた開発者は、pwshがインストールされていない、実行ポリシーや改行コードでエラーになる、スクリプトの相対パスが解決できない、といった問題が起きる可能性があります。
READMEの変更では、MacでPowerShellが必要であることが要件に追加されています。ローカル環境構築時には、Azure CLI、Azure Developer CLI、Docker Desktop、Node.js、jqだけでなく、PowerShell Coreも確認対象に入れる必要があります。(GitHub)
ローカル環境で確認するコマンド
Mac/Linux/Windowsのどれで作業していても、まず次のコマンドで基本ツールを確認します。
az version
azd version
pwsh --version
node --version
jq --versionpwsh --versionでエラーになる場合、azure.yamlのフック実行時に失敗する可能性があります。特にazd upやazd provisionの途中で止まる場合は、Azure側の権限やBicepの問題だけでなく、ローカルのPowerShell Core未導入も疑うべきです。
既存環境への影響範囲
今回の更新で影響を受けやすいのは、Azure/enterprise-azureaiのテンプレートや派生構成を使っている環境です。ただし、同じような構成を自社テンプレートに取り込んでいる場合も、実質的な影響があります。
影響を受ける可能性が高いケース
次のいずれかに当てはまる場合は、設定確認を優先してください。
| 対象 | 影響内容 | 優先度 |
|---|---|---|
gpt-35-turboの古いバージョンを固定している | モデル廃止後に停止、または意図しない更新が起きる可能性 | 高 |
| Azure OpenAIのリージョンを固定している | 新しいモデルバージョンが選べない可能性 | 高 |
azdでテンプレートをデプロイしている | azure.yamlフック変更の影響を受ける | 高 |
Mac/Linuxで.sh前提の運用をしている | 削除されたスクリプトに依存していると失敗する | 中〜高 |
| CI/CDで独自にスクリプトを呼び出している | ファイル削除やパス変更でパイプラインが失敗する | 中 |
| APIMを組み合わせている | SKUやリージョン条件の確認が必要 | 中 |
反対に、Azure OpenAIをAzure Portalから手動作成しており、このリポジトリやテンプレートを使っていない場合、今回のPR自体が直接設定を書き換えることはありません。ただし、古いモデルバージョンの廃止という背景は共通しているため、モデルバージョンの確認は行うべきです。
開発者が確認すべき移行手順
今回の更新を受けて、開発者は「テンプレートを更新して終わり」ではなく、アプリケーションの挙動まで確認する必要があります。モデルバージョンが変わると、同じプロンプトでも応答の形式、長さ、ツール呼び出しの安定性が変わることがあるためです。
まず現在のデプロイ状態を棚卸しする
最初に、Azure OpenAIのデプロイ一覧を確認します。Azure PortalのFoundryまたはAzure OpenAIリソース画面から確認してもよいですが、複数環境がある場合はCLIやREST APIで一覧化した方が安全です。
確認対象は次の通りです。
| 項目 | 例 | メモ |
|---|---|---|
| 環境 | dev、stg、prod | 環境ごとの差分を洗い出す |
| リソースグループ | rg-ai-prodなど | IaC管理対象か手動作成かを確認 |
| Azure OpenAIリソース名 | aoai-prod-001など | アプリの接続先と一致するか |
| デプロイ名 | chat、gpt35など | コードが参照している値 |
| モデル名 | gpt-35-turboなど | モデルファミリー |
| バージョン | 0613、1106、0125など | 廃止予定と照合 |
| SKU/容量 | Standard、Provisionedなど | 移行時のクォータ確認に必要 |
Microsoftのドキュメントでは、デプロイのモデルバージョンや更新ポリシーはAzure PowerShellやREST APIで確認・更新できると説明されています。特に本番環境では、モデルを自動更新するのか、廃止時のみ更新するのか、手動で固定するのかを運用ルールとして決めておく必要があります。(Microsoft Learn)
新しいモデルバージョンで回帰テストを行う
モデル移行では、HTTPレスポンスが返るかどうかだけでは不十分です。特に社内FAQ、RAG、チャットボット、要約、分類、JSON生成などでは、品質と形式をテストする必要があります。
おすすめは、実際の問い合わせログから20〜50件程度の代表プロンプトを選び、旧バージョンと新バージョンで比較する方法です。
| テスト観点 | 確認内容 | 失敗時の対応 |
|---|---|---|
| 応答形式 | JSON、箇条書き、敬体などが崩れないか | システムプロンプトを明確化 |
| 精度 | FAQや社内文書に沿った回答か | RAGの検索条件やプロンプトを調整 |
| 安定性 | 同じ入力で大きくブレないか | temperatureやtop_pを見直す |
| 長文処理 | 要約漏れや途中切れがないか | max tokensや分割処理を調整 |
| 速度 | 応答時間が許容範囲か | リージョン、SKU、並列数を見直す |
| コスト | トークン使用量が増えていないか | プロンプト短縮、キャッシュ活用を検討 |
モデル移行でよくある失敗は、「新しいモデルだから精度は上がるはず」と考えてテストを省略することです。新しいバージョンで性能が改善する可能性はありますが、自社のプロンプトや業務データに対して必ず同じ結果になるとは限りません。公開前に最低限の回帰テストを行うべきです。
管理者が確認すべきデプロイ・運用上の注意点
管理者にとって重要なのは、モデル更新だけでなく、デプロイの再現性と失敗時の戻し方です。今回の変更ではBicep、azure.yaml、スクリプトが同時に変わっているため、単体では成功しても、全体のデプロイフローで問題が出る可能性があります。
IaCの差分をそのまま本番に流さない
Bicepのリージョン配列やAPIM SKUの条件分岐が変わると、同じパラメータでも作成されるリソース構成が変わる場合があります。特にAPIMはSKUによって機能、価格、利用可能リージョンが異なるため、what-ifや検証環境での確認が必要です。
実務では、次の順序で進めると安全です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | 変更前のBicep、azure.yaml、環境変数をバックアップ | 戻しやすくする |
| 2 | dev環境でazd provisionまたはBicepデプロイを実行 | IaC差分を確認 |
| 3 | Azure OpenAIのデプロイ名・モデルバージョンを確認 | アプリ接続先との不一致を防ぐ |
| 4 | APIM、Key Vault、Managed Identity、Role Assignmentを確認 | 権限・経路の問題を防ぐ |
| 5 | アプリの回帰テストを実施 | モデル変更の影響を確認 |
| 6 | stg、本番の順に展開 | 影響範囲を段階的に広げる |
CI/CDパイプラインの.sh依存を確認する
今回削除された.shファイルを、GitHub Actions、Azure DevOps、社内のデプロイスクリプトから直接呼んでいる場合、テンプレート更新後にパイプラインが失敗します。azure.yaml上ではPowerShellに移行していても、CI/CD側に古い呼び出しが残っているケースは珍しくありません。
たとえば、次のような参照がないか確認します。
grep -R "scripts/.*\.sh" .
grep -R "set-env.sh\|cleanup.sh\|deploy-azurechat.sh" .見つかった場合は、対応する.ps1スクリプトへ置き換えるか、CI/CD上でpwshを使うよう修正します。LinuxランナーでもPowerShell Coreが利用できる前提にすると、OSごとの差分を減らせます。
よくある疑問と判断基準
これはAzure OpenAIの強制移行なのか
今回のPRそのものは、Azure全体の強制移行ではありません。特定リポジトリのテンプレート更新です。ただし、背景にある古いモデルバージョンの廃止はAzure OpenAI利用者に関係します。テンプレートを使っていない環境でも、古いgpt-35-turboバージョンを固定している場合は確認が必要です。(GitHub)
gpt-35-turboから別モデルへ移行すべきか
今回の差分ではgpt-35-turbo内のバージョン更新が中心です。ただし、長期運用を考えるなら、単に1106や0125へ置き換えるだけでなく、現在利用可能な新しいモデルファミリーへの移行も検討対象になります。判断基準は、コスト、応答品質、コンテキスト長、API互換性、社内の検証工数です。
すぐに全面移行できない場合は、まず本番影響の小さい機能から新モデルを試し、評価結果をもとに段階移行するのが現実的です。
NoAutoUpgradeを設定している場合はどうするべきか
NoAutoUpgradeは、モデルが勝手に変わらないため検証済みの挙動を維持しやすい一方、廃止日を過ぎるとデプロイが動作しなくなるリスクがあります。Microsoftの説明でも、NoAutoUpgradeでは廃止後に動作しなくなり、期限切れでないモデルデプロイを参照するよう更新が必要とされています。(Microsoft Learn)
本番環境では、NoAutoUpgradeを使うなら廃止日監視、移行期限、検証担当、切り戻し手順までセットで管理してください。設定だけ固定して廃止情報を追わない運用は危険です。
今回の更新後にやるべきチェックリスト
最後に、今回のMicrosoft Azure documentation updateを受けて実施すべき作業を整理します。すべてを一度に対応できない場合でも、モデル廃止に関わる項目から優先してください。
| 優先度 | チェック項目 | 完了の目安 |
|---|---|---|
| 高 | Azure OpenAIのデプロイ名、モデル名、バージョンを一覧化する | dev/stg/prodで把握済み |
| 高 | 古いgpt-35-turboバージョンを使っていないか確認する | 廃止対象の有無を判断済み |
| 高 | 対象リージョンで移行先モデルが利用できるか確認する | プライマリ／セカンダリとも確認済み |
| 高 | azure.yamlのフックがpwsh前提になっているか確認する | ローカルとCI/CDで実行確認済み |
| 中 | Mac/Linux環境にPowerShell Coreを導入する | pwsh --versionが通る |
| 中 | .shスクリプトへの直接参照を検索する | 参照がない、または.ps1へ移行済み |
| 中 | Bicepのリージョン、APIM SKU、モデルバージョン条件を確認する | 検証環境でデプロイ済み |
| 中 | 新モデルバージョンで回帰テストを行う | 代表プロンプトで品質確認済み |
| 低 | READMEや社内手順書を更新する | 新規メンバーが同じ手順で構築可能 |
今回の更新は、単なるドキュメント修正ではなく、Azure OpenAIのモデルライフサイクル、Azure Developer CLIのクロスプラットフォーム運用、Bicepによるリージョン制御が交差する実務的な変更です。まずは自社環境で使っているモデルバージョンとazure.yamlのフック設定を確認し、次に検証環境でモデル更新とデプロイフローを通してください。古いモデルの廃止対応は、期限直前に行うほどテスト不足になりやすいため、棚卸し、検証、段階展開の順で進めることが安全です。
コメント