2026年5月20日の公式リポジトリ更新で、Azure AI Foundryに関連するFoundry Localモデル資産は、新しいストレージアカウント名foundrylocalassetdataを使う形に変更され、リリースパイプライン上でモデルをisArchived: trueとして扱う更新が入りました。結論から言うと、利用者側のAzure Storageをすぐ作り替える変更ではありません。ただし、Foundry Localモデルの取得、モデル一覧の取得、自社CI/CDでの資産同期、ネットワーク許可リスト、モデル名・バージョンの固定運用には影響が出る可能性があります。特に「モデル一覧から最新を選ぶ」実装や、foundrylocalmodelsなど旧ストレージ名をハードコードしている運用は確認が必要です。(GitHub)
今回のAzure AI Foundry更新で変わったこと
今回の更新は、Azure AI Foundryの画面に新ボタンが増えるような表面的な機能追加ではなく、Foundry Localモデル資産の公開・管理に関わるメタデータ更新です。公式PRでは、すべてのFoundry Localモデルを新しいストレージアカウントfoundrylocalassetdataに更新し、リリースパイプライン中にモデルをアーカイブするためにisArchiveを使う趣旨が説明されています。実際のYAML差分では、モデル定義のstorage_nameがfoundrylocalassetdataへ変更され、spec.yamlにはisArchived: trueが追加されています。(GitHub)
| 変更点 | 変更前の例 | 変更後 | 実務上の意味 |
|---|---|---|---|
| ストレージアカウント名 | foundrylocalmodels、一部でautomlcesdkdataresources | foundrylocalassetdata | モデル資産の参照先メタデータが変わる。自社スクリプトや許可リストで旧名を使っている場合は見直しが必要 |
| アーカイブ指定 | 記載なし | isArchived: true | モデルが削除されたわけではないが、通常の一覧取得で見え方が変わる可能性がある |
| 対象 | Foundry Localモデル資産 | Foundry Localモデル資産全体として更新 | CPU/GPU/NPU向けの複数バリアントを扱う運用では、モデルごとに確認が必要 |
| 実際の差分 | model.yaml、spec.yaml | .yamlファイル群 | 自社でazureml-assetsをミラー・解析している場合、YAMLパーサーや検証ルールの更新が必要 |
注意したいのは、PR説明ではisArchiveという表記が使われていますが、実際のファイル差分に追加されているキーはisArchived: trueです。自社のYAML、JSONスキーマ、CI検証、検索スクリプトに反映する場合は、isArchiveではなくisArchivedを確認してください。DeepSeek-R1-Distill-QwenやMistral、Phi系のFoundry Localモデルでも、storage_name変更とisArchived: true追加のパターンが確認できます。(GitHub)
これは「モデル削除」ではなく「公開・一覧表示の整理」と考えるべき
Azure Machine Learningのモデル管理では、アーカイブされたモデルは既定でaz ml model listのようなリストクエリから非表示になります。一方で、アーカイブされたモデルをワークフローから参照・使用し続けることは可能です。つまり今回のisArchived: trueは、モデル資産を消す変更というより、リリースパイプラインやカタログ上の見せ方を整理するためのライフサイクル管理と捉えるのが適切です。(Microsoft Learn)
実務で問題になりやすいのは、次のような実装です。
- モデル一覧を取得し、最初に見つかったモデルを使う
latest相当のモデルを一覧結果から独自判定している- 旧ストレージアカウント名を文字列で判定している
spec.yamlに未知のプロパティがあるとCIを落とす- アーカイブ済みモデルを「利用不可」と誤判定する
既存アプリが特定のモデル名とバージョンを明示して参照している場合、直ちに壊れるとは限りません。ただし、初回ダウンロード、モデルカタログ同期、社内ミラー作成、ネットワーク制御、監査ログ連携をしている環境では、リリース前に冷スタート検証を行うべきです。
Foundry Local利用者にとって何が重要か
Foundry Localは、ユーザーのデバイス上でAIモデルを実行するためのローカルAIソリューションです。Microsoft Learnでは、C#、JavaScript、Rust、Python向けSDK、オンデバイス向けに最適化されたモデルカタログ、自動ハードウェアアクセラレーション、モデルの初回ダウンロードとローカルキャッシュなどが説明されています。モデル取得やモデル管理がアプリの起動体験に関わるため、今回のようなモデル資産メタデータの変更は、アプリ開発者にも無関係ではありません。(Microsoft Learn)
特に確認すべきなのは、次の3点です。
| 確認対象 | 確認すべきこと | 失敗しやすいポイント |
|---|---|---|
| 初回起動 | 新規端末でモデルをダウンロードできるか | 開発端末ではキャッシュ済みで問題に気づかない |
| モデル選択 | CPU/GPU/NPUなど想定バリアントが選ばれるか | 一覧取得ロジックがアーカイブ済みモデルを除外してしまう |
| ネットワーク | モデル取得時の通信がブロックされないか | 旧ストレージ名だけを許可しているプロキシ・EDR・FWで失敗する |
| CI/CD | YAMLのisArchivedを正しく扱えるか | 未知フィールド扱いで検証ジョブが落ちる |
| 監査 | 「アーカイブ済み」を「削除済み」と誤記録しないか | 運用レポートでモデル消失と誤認する |
管理者がまず確認すべき設定
管理者は、Azureポータル上の通常リソースだけを見るのではなく、モデル資産の取得経路と運用ルールを確認してください。今回の変更はユーザーのサブスクリプション内にあるストレージアカウントを直接変更するものではありませんが、組織側でモデル取得先やアセット定義を厳密に制御している場合は影響します。
ネットワーク許可リストを確認する
プロキシ、ファイアウォール、CASB、EDR、DLP、閉域網ゲートウェイなどで、モデル取得先のストレージ名やURLパターンを許可リスト化している場合は、foundrylocalassetdataが想定に入っているか確認します。
すぐに旧名を削除するのではなく、次の順で進めるのが安全です。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | 通信ログでfoundrylocalmodels、automlcesdkdataresources、foundrylocalassetdataを検索 | 旧名参照が残っているか把握する |
| 2 | 検証端末でFoundry Localモデルをキャッシュなしで取得 | 新規端末でも成功するか確認する |
| 3 | 必要に応じてfoundrylocalassetdataを許可 | ブロックログが出ている場合に対応する |
| 4 | 旧名の削除は段階的に実施 | 既存リリースやロールバックで旧参照が残らないことを確認してから行う |
モデル一覧の取得コマンドを見直す
Azure ML CLIのaz ml model listには、アーカイブ済みモデルを含める--include-archived、アーカイブ済みのみを対象にする--archived-onlyがあります。リスト結果を使ってモデル存在確認や最新バージョン判定をしている場合は、通常の一覧だけで判断しないようにします。(Microsoft Learn)
# アーカイブ済みも含めてモデルを確認
az ml model list \
--registry-name <registry-name> \
--name <model-name> \
--include-archived
# アーカイブ済みモデルだけを確認
az ml model list \
--registry-name <registry-name> \
--name <model-name> \
--archived-only
# 特定バージョンの詳細を確認
az ml model show \
--registry-name <registry-name> \
--name <model-name> \
--version <version>社内の運用手順書で「az ml model listに出ないので存在しない」と判断している場合は、今回の変更後に誤判定する可能性があります。アーカイブ済みでも参照・使用できるという前提を、運用ルールに明記しておくと混乱を防げます。
開発者が確認すべき実装ポイント
開発者が最も注意すべきなのは、「モデルカタログやモデル一覧は常にアクティブなモデルだけを返す」という前提でコードを書いていないかです。Foundry Localはモデルの取得、キャッシュ、ハードウェアに応じたモデル選択を行うため、アプリ側のモデル選定ロジックが過度に自前実装されていると、今回のようなメタデータ変更で影響を受けやすくなります。
旧ストレージ名のハードコードを探す
azureml-assetsをミラーしている、モデル定義を社内で解析している、独自カタログを生成している場合は、リポジトリ内を検索します。
grep -R "foundrylocalmodels" .
grep -R "automlcesdkdataresources" .
grep -R "foundrylocalassetdata" .
grep -R "isArchived" .見つかった場合は、単純に文字列を置き換える前に、そのコードが何のために使われているかを確認してください。たとえば、監査レポート用の表示名なのか、実際のダウンロード許可判定なのかで対応が変わります。
YAMLバリデーションを更新する
自社CIでmodel.yamlやspec.yamlを検証している場合、isArchivedを未知のキーとして落とさないようにします。特に、次のような独自ルールは見直し対象です。
| ルール | リスク | 修正方針 |
|---|---|---|
| 許可キーを固定列挙している | isArchived追加でCI失敗 | スキーマ更新、または許可キーに追加 |
storage_nameを旧名だけ許可 | 新モデル定義を拒否する | foundrylocalassetdataを許可 |
isArchived: trueを利用不可扱い | 参照可能なモデルまで除外する | 「一覧非表示」と「使用不可」を分けて判定 |
| 大文字小文字を無視している | isArchiveとisArchivedを混同 | 実フィールド名isArchivedで統一 |
モデル選定は「名前＋バージョン」で固定する
本番アプリでは、一覧取得結果から曖昧にモデルを選ぶより、利用するモデルID、バージョン、想定ハードウェア、フォールバックモデルを明示する運用が安全です。
悪い例は、一覧の先頭や最新らしきものを自動選択する実装です。アーカイブ指定やカタログ整理が入ると、候補が変わる可能性があります。
避けたい例:
- 一覧の先頭を使う
- 名前に "mistral" を含む最初のモデルを使う
- アーカイブ済みを常に除外する
- バージョンを指定しない推奨は、アプリのリリースごとに検証済みモデルを固定し、必要な場合だけ更新する方法です。
推奨:
- モデル名を明示する
- バージョンを明示する
- CPU/GPU/NPUなど検証済み環境を記録する
- 起動時にモデル取得失敗時の代替モデルを用意する
- キャッシュなし端末で回帰テストする展開前に行うべきテスト
Foundry Localモデルは、開発者のPCではキャッシュ済みで問題なく動いても、新規端末や制限ネットワークでは失敗することがあります。今回のAzure AI Foundry更新を受けて、展開前には「キャッシュなし」「制限ネットワーク」「複数ハードウェア」の3条件で検証してください。
| テスト | 内容 | 合格基準 |
|---|---|---|
| コールドスタート | モデル未取得の端末でアプリを起動 | モデル取得、ロード、初回応答まで成功する |
| キャッシュ利用 | 2回目以降の起動を確認 | 再ダウンロードせず、想定時間内に起動する |
| ネットワーク制限 | 社内プロキシ・VPN・EDR配下で起動 | ストレージ変更後もブロックされない |
| ハードウェア差分 | CPU、GPU、NPU端末で確認 | 想定バリアントまたはフォールバックで動作する |
| モデル一覧 | --include-archivedあり/なしで確認 | アーカイブ状態を正しく解釈できる |
| ロールバック | 旧アプリ版や旧設定で起動 | 旧参照が必要な場合に失敗しない |
特に業務アプリに組み込む場合、ネットワークが安定した開発環境だけで確認しても不十分です。営業端末、工場端末、店舗端末、VDI、プロキシ配下の端末など、実際の利用場所に近い条件でテストする必要があります。
管理者・開発者別の対応チェックリスト
| 立場 | すぐ確認すること | 優先度 |
|---|---|---|
| Azure管理者 | foundrylocalassetdataが通信・監査・許可リストで問題にならないか | 高 |
| セキュリティ担当 | 旧ストレージ名だけを許可していないか | 高 |
| 開発者 | モデル一覧取得でアーカイブ済みを誤除外していないか | 高 |
| MLOps担当 | spec.yamlのisArchivedをCIが許容できるか | 高 |
| QA担当 | キャッシュなし端末でモデル取得テストを実施したか | 高 |
| 運用担当 | 「一覧にない＝削除」と誤判定しない手順になっているか | 中 |
| 情シス | 端末配布後の初回モデル取得に時間・通信量の問題がないか | 中 |
よくある誤解と正しい見方
foundrylocalassetdataというAzure Storageを自社で作る必要がある？
通常の利用者が、自分のサブスクリプション内に同名のストレージアカウントを作る必要はありません。今回の変更は、Foundry Localモデル資産の公開元・参照メタデータに関する更新です。自社で問題になるのは、旧ストレージ名を使って通信制御、監査、ミラーリング、YAML検証をしている場合です。
isArchived: trueならモデルは使えない？
使えないと決めつけるのは誤りです。Azure MLのドキュメントでは、アーカイブされたモデルは既定のリストクエリから非表示になりますが、ワークフロー内で参照・使用し続けることができると説明されています。必要に応じてaz ml model list --include-archivedやaz ml model showで確認します。(Microsoft Learn)
既存のFoundry Localアプリは必ず修正が必要？
必ず修正が必要とは限りません。モデルをSDK経由で標準的に取得し、旧ストレージ名を自前で扱っていないアプリでは、影響が見えない場合もあります。ただし、モデル一覧を自前で解析している、社内ネットワークで通信先を厳しく制限している、モデルファイルを社内配布している、リリースパイプラインでazureml-assetsを検証している場合は確認が必要です。
isArchiveとisArchivedはどちらを使う？
実装上はisArchivedを確認してください。PR説明の文脈ではisArchiveという表現が出ていますが、実際のYAML差分ではisArchived: trueが追加されています。大文字小文字や末尾のdを誤ると、独自スクリプトやバリデーションで検出漏れが起きます。(GitHub)
今回の更新後に取るべき次の行動
今回のAzure AI Foundry documentation updateは、Foundry Localモデルの配布・管理メタデータを整理する更新です。重要なのは、storage_nameがfoundrylocalassetdataへ変わったこと、そしてisArchived: trueによりモデル一覧の見え方が変わり得ることです。
まずは、自社コードと運用で旧ストレージ名を使っていないかを検索してください。次に、Azure ML CLIやSDKでモデル一覧を取得している処理が、アーカイブ済みモデルを正しく扱えるか確認します。最後に、キャッシュなし端末でFoundry Localモデルの初回取得テストを行い、ネットワーク、モデル選択、フォールバックまで確認してから本番展開するのが安全です。
この更新は、単なるドキュメント差分として流すよりも、AIアプリを安定配布するためのモデル資産管理ルール変更として扱うべきです。モデル名・バージョンの固定、通信許可リストの見直し、isArchivedを考慮した一覧取得の3点を押さえれば、管理者と開発者の双方が余計な障害を避けやすくなります。
コメント