MENU

Azure SDKの_asset_utils.py性能問題とは？4117433更新の影響と確認ポイント

Azure

2026年5月5日に関連更新として確認された Azure SDK の「4117433: Update _asset_utils.py to fix Performance issue」 は、Azure SDK for Python の azure-ai-ml に含まれる _asset_utils.py の性能問題に関する変更です。結論から言うと、Azure Machine Learning のジョブ送信時などに、.amlignore や .gitignore で除外したはずの大きなフォルダーまで走査され、アップロード前処理が遅くなる問題を改善しようとする内容です。

ただし、このPRは正式にマージされたリリース済み修正ではなく、GitHub上ではクローズされた状態です。そのため、現時点で利用者が取るべき対応は「すぐにSDK更新で解決すると考える」ことではありません。まずは自分の環境で azure-ai-ml のバージョン、.amlignore の配置、アップロード対象ディレクトリの範囲を確認し、必要に応じてジョブ投入元のフォルダー構成を見直すことが重要です。PR #46572 は sdk/ml/azure-ai-ml/azure/ai/ml/_utils/_asset_utils.py の1ファイルに対する変更で、差分は31行追加・9行削除として記録されています。(GitHub)

目次

Azure SDKの4117433更新でまず押さえるべき結論

この更新の中心は、Azure SDK for Python のうち Azure Machine Learning向けパッケージ azure-ai-ml に関係する内部処理です。具体的には、ローカルフォルダー内のファイルをアップロード対象として列挙する get_upload_files_from_folder の処理で、無視対象ディレクトリを早い段階でスキップしようとしています。

従来の処理では、.amlignore で .venv/ や大容量フォルダーを除外していても、os.walk がフォルダー内部を再帰的にたどってから各ファイルを判定するため、ファイル数が多い環境ではジョブ送信前に長く待たされる可能性がありました。関連Issue #39235 でも、azure-ai-ml 1.22.4、Windows、Python 3.10 の環境で、.amlignore に大きなPython環境フォルダーを追加しても get_upload_files_from_folder が内部ファイルを走査してしまい、Azure MLジョブの起動が非常に遅くなる問題が報告されています。(GitHub)

実務上のポイントは次の3つです。

確認項目要点今すぐの対応
正式反映の有無PR #46572 はクローズ済みで、マージ済み修正とは断定できないSDK更新だけで解決すると判断しない
影響範囲主に azure-ai-ml でローカルコードやフォルダーをアップロードする処理Azure MLジョブ投入時の遅延を確認する
回避策アップロード対象フォルダーを小さくし、.amlignore を適切に配置する.venv、data、outputs などをソース外へ移す

何が変わる予定だったのか

PR #46572 の差分では、get_upload_files_from_folder 内の os.walk に対して topdown=True を使い、dirs[:] を書き換えることで、無視対象ディレクトリへ降りないようにする変更が提案されています。レビューコメントでも、無視対象ディレクトリを走査対象から取り除くことで、大きな .venv のようなフォルダーがある場合の走査コストを減らす意図が説明されています。(GitHub)

変更のイメージは次のようなものです。

観点従来の挙動提案された挙動
ディレクトリ走査os.walk が配下のディレクトリを広く再帰走査する上位階層で無視対象ディレクトリを除外する
.amlignore の効果ファイル単位の判定が中心になり、巨大フォルダーでは遅くなりやすいディレクトリ単位で早めに枝刈りできる
期待される改善ファイル数が多いほど待ち時間が増える.venv やキャッシュ配下の走査を避けやすい
利用者側のAPI変更なしなしの想定

ポイントは、外部APIの使い方が変わる修正ではなく、Azure MLのアセットアップロード前処理を軽くする内部改善であることです。利用者のPythonコードに新しい引数を追加するような移行作業は基本的に想定されません。

影響を受けやすい利用者

このAzure SDK更新の影響を受けやすいのは、Azure Machine Learningでローカルフォルダーをジョブやコード資産としてアップロードしている利用者です。特に、リポジトリ直下に .venv、venv、node_modules、大容量データ、実験結果フォルダーなどが存在する場合は注意が必要です。

利用状況影響度理由
Azure MLジョブの code にリポジトリルートを指定している高不要ファイルまで走査対象になりやすい
.amlignore で .venv/ を除外しているがジョブ送信が遅い高今回の性能問題と症状が一致しやすい
小さな src/ フォルダーだけをアップロードしている低走査対象が少なく、遅延が出にくい
Azure Storageや登録済みデータ資産のみを使っている低ローカルフォルダー列挙の影響を受けにくい
azure-ai-ml 以外のAzure SDKを使っている低今回の対象ファイルはAzure ML SDK側の内部ユーティリティ

azure-ai-ml は Azure Machine Learning SDK v2 のPythonクライアントライブラリで、ジョブ実行、パイプライン、モデル、データ、環境などを扱うパッケージです。PyPI上の最新情報では azure-ai-ml 1.32.0 が2026年3月16日に公開されており、PR #46572 の作成時期より前のリリースです。(PyPI)

現時点で注意すべきこと：PRはクローズ済みで、正式修正とは限らない

この件で最も誤解しやすい点は、「GitHubにPRがある」ことと「pipで入る正式版に修正が入っている」ことは別だという点です。

PR #46572 は2026年4月28日に作成され、2コミットを含む変更として扱われていますが、GitHub上ではクローズされています。また、5月4日にヘッドリポジトリ削除によってクローズされた履歴が確認できます。さらに5月5日には別の azure-ai-ml: Support async clients #46496 から言及されていますが、これはこの性能修正が正式リリースに入ったことを意味するものではありません。(GitHub)

レビュー上の懸念もあります。PR内では、存在しない可能性のあるRESTクライアントモジュールへのimport、_get_latest の型判定が実質的に不要または誤っている可能性、PR説明がテンプレートのままで関連Issueへのリンクが不足している点などが指摘されています。つまり、このPRをそのまま本番環境の根拠として扱うのは避けるべきです。(GitHub)

自分の環境で確認すべきポイント

Azure SDKのこの性能問題に該当するかどうかは、次の順番で確認すると切り分けやすくなります。

azure-ai-ml のバージョンを確認する

まず、利用中の azure-ai-ml のバージョンを確認します。

pip show azure-ai-ml

Python側から確認する場合は、次のコマンドも使えます。

python - <<'PY'
from importlib.metadata import version
print(version("azure-ai-ml"))
PY

ここで確認したバージョンが古い場合でも、今回のPRが正式に取り込まれていない限り、単純なアップデートでこの性能問題が解消されるとは限りません。Azure SDKの公式一覧でも、Machine Learning向けの azure-ai-ml はPyPI 1.32.0として掲載されています。(Azure)

get_upload_files_from_folder の実装を確認する

診断目的で、インストール済みSDK内の実装を確認できます。これは内部モジュールなので、アプリケーションコードから常用するのではなく、調査用として扱ってください。

python - <<'PY'
import inspect
from azure.ai.ml._utils import _asset_utils

print(inspect.getsource(_asset_utils.get_upload_files_from_folder))
PY

出力に次のような特徴がある場合、無視対象ディレクトリの枝刈りが入っていない可能性があります。

for root, _, files in os.walk(path, followlinks=True):

一方、提案された改善に近い実装では、次のような要素が見えるはずです。

for root, dirs, files in os.walk(path, followlinks=True, topdown=True):
    dirs[:] = [
        d for d in dirs
        if not ignore_file.is_file_excluded(Path(root).joinpath(d).as_posix())
    ]

このような差分が入っていない場合は、.amlignore で除外していても、SDK内部で不要なディレクトリ走査が残っている可能性があります。

.amlignore の場所を確認する

Azure MLのアップロード対象フォルダーに対して、.amlignore が正しい場所にあるか確認します。一般的には、Azure MLジョブで code やソースディレクトリとして指定するフォルダーの直下に置くのが分かりやすいです。

悪い例は、次のような構成です。

project/
├── .amlignore
├── .venv/
├── data/
├── outputs/
├── notebooks/
└── src/

この状態で project/ 全体をアップロード対象にすると、.venv や data を無視対象にしていても、SDKの実装次第では走査コストが残る可能性があります。

より安全な構成は、アップロード対象を最初から小さくすることです。

project/
├── .venv/
├── data/
├── outputs/
└── azureml-code/
    ├── .amlignore
    ├── train.py
    ├── component.yml
    └── src/

ジョブには project/ ではなく project/azureml-code/ を指定します。これだけで、SDK側の最適化に依存せず、走査対象を大きく減らせます。

推奨される .amlignore の書き方

.amlignore は「アップロードしたくないもの」を書くファイルですが、性能対策としては「巨大になりやすいもの」を明示的に除外することが重要です。

# Python仮想環境
.venv/
venv/
env/

# Pythonキャッシュ
__pycache__/
.pytest_cache/
.mypy_cache/
.ruff_cache/

# Git・IDE関連
.git/
.vscode/
.idea/

# 実験結果・一時出力
outputs/
runs/
logs/
tmp/
temp/

# 大容量データ
data/
datasets/
*.parquet
*.zip
*.tar
*.tar.gz

ただし、data/ や datasets/ を除外するかどうかは運用次第です。ジョブ実行に必要な小さなサンプルデータまで除外すると、実行時にファイルが見つからなくなります。本番データはローカルフォルダーとして同梱するのではなく、Azure MLのデータ資産、データストア、外部ストレージから参照する設計にしたほうが安定します。

移行や設定確認で見るべき観点

今回の Update _asset_utils.py to fix Performance issue は、APIの破壊的変更というより、内部処理の性能改善に近い内容です。そのため、正式に修正がリリースされた場合でも、多くの利用者はコードを書き換える必要はないと考えられます。

ただし、SDKを更新する前後では次の確認を行ってください。

確認項目確認方法判断基準
ジョブ送信時間同じジョブを更新前後で実行送信前の待ち時間が短くなるか
アップロード対象ファイル数SDKログ、ストレージ上の成果物、手元のファイル数で確認不要ファイルが含まれていないか
.amlignore の効き方意図的に除外したファイルを置いてテストアップロードされないか
シンボリックリンクリンク先が大容量フォルダーでないか確認followlinks=True により想定外に走査されないか
CI/CD環境ビルドエージェント上の作業ディレクトリを確認キャッシュや仮想環境を同梱していないか

特にCI/CDでは、ワークスペース内に依存関係キャッシュ、ビルド成果物、テスト結果、モデル出力などが残っていることがあります。Azure MLジョブのソースとしてリポジトリルートを指定している場合、ローカルPCでは問題なくても、CI上では突然遅くなることがあります。

すぐにできる実務的な回避策

正式なSDK修正を待たずにできる対策はあります。効果が大きい順に実施してください。

アップロード対象をリポジトリルートにしない

最も効果が高いのは、Azure MLに渡す code やソースディレクトリを小さくすることです。

避けたい指定例です。

# リポジトリ全体をアップロード対象にしてしまう例
code="./"

推奨例です。

# ジョブに必要なコードだけを含むフォルダーを指定
code="./azureml-code"

.amlignore に頼るより、最初から対象外のファイルをアップロード元の外に置くほうが確実です。

仮想環境をプロジェクト外に置く

.venv/ をプロジェクト直下に置く運用は便利ですが、Azure MLのアップロード対象と重なると性能問題の原因になります。可能であれば、仮想環境はリポジトリ外に作成します。

python -m venv ../.venvs/my-azureml-project

ローカル開発の利便性を優先してリポジトリ直下に置く場合は、.amlignore と .gitignore の両方に必ず追加してください。

大容量データをコードフォルダーに置かない

学習データ、検証データ、モデル出力、ログ、ノートブックの実行結果などは、コードと分離します。

悪い例です。

azureml-code/
├── train.py
├── data/
│   ├── train.parquet
│   └── valid.parquet
└── outputs/

推奨例です。

project/
├── azureml-code/
│   └── train.py
└── local-data/
    ├── train.parquet
    └── valid.parquet

ジョブ内では、データ資産やデータストア、入力パラメーターとしてデータを渡します。これにより、コードアップロードとデータ管理を分離できます。

よくある失敗と対処法

.amlignore を書いたのに遅い

.amlignore が存在していても、アップロード対象フォルダーの外に置かれていると期待通りに効かないことがあります。まず、ジョブで指定している code の直下に .amlignore があるか確認してください。

また、今回の性能問題は「除外されるかどうか」だけでなく、「除外判定に到達するまでに巨大フォルダーを走査してしまう」点が問題です。そのため、.amlignore を正しく書いていても、SDK実装によっては遅延が残る可能性があります。

.gitignore があるから大丈夫だと思っている

Azure MLでは .amlignore を使う運用が分かりやすいです。SDK内部の説明では、.amlignore がある場合は .gitignore より優先される扱いになっています。両方を併用している場合は、どちらのファイルに何を書いているかを整理してください。(GitHub)

おすすめは、Azure MLへのアップロード除外は .amlignore に明示し、Git管理の除外は .gitignore に分けることです。

シンボリックリンク経由で大きなフォルダーに入っている

os.walk が followlinks=True で動作する場合、シンボリックリンクの扱いにも注意が必要です。リンク先が大容量ディレクトリだと、見た目のフォルダー構成より多くのファイルが走査される可能性があります。

調査時は、アップロード対象内のリンクを確認します。

find . -type l -ls

Windows環境では、ジャンクションやシンボリックリンクを含む作業ディレクトリにも注意してください。

SDK更新を待つべきか、運用で回避すべきか

現時点では、運用で回避できるなら先に回避するのが安全です。理由は、PR #46572 がクローズ済みであり、正式にどのバージョンへ取り込まれるかを断定できないためです。

状況推奨判断
ジョブ送信が数十秒以上遅いまずアップロード対象フォルダーを小さくする
.venv や data がリポジトリ直下にあるソース外へ移動する
本番CIでAzure MLジョブを頻繁に投入するCIの作業ディレクトリを整理し、ファイル数を監視する
SDKのmainブランチを直接使いたいレビュー指摘があるため本番利用は避ける
正式修正リリースを待てるAzure SDKのリリースノートとPyPI更新を確認してから検証する

特に本番環境では、GitHub上の未マージPRやクローズ済みPRを直接取り込むのは避けてください。importの不整合や型判定の問題がレビューで指摘されているため、性能改善のつもりで別の実行時エラーを持ち込むリスクがあります。

次に取るべき行動

Azure SDKの「4117433: Update _asset_utils.py to fix Performance issue」を見た開発者は、まず自分の環境がこの性能問題に該当するかを確認してください。特に、Azure Machine Learningで azure-ai-ml を使い、ローカルフォルダーをジョブのコードとしてアップロードしている場合は確認優先度が高いです。

最初に行うべきことは次の3つです。

  1. pip show azure-ai-ml で利用中バージョンを確認する
  2. Azure MLジョブの code がリポジトリ全体を指していないか確認する
  3. .venv/、data/、outputs/ などをアップロード対象外に移す、または .amlignore で明示的に除外する

このPRは、Azure SDKの内部処理として重要な性能改善の方向性を示しています。一方で、正式に取り込まれた修正とは限らないため、現時点では「SDK更新を待つ」だけでは不十分です。アップロード対象を小さく保つ、不要な大容量フォルダーをコードと分離する、CI/CD上の作業ディレクトリを整理する。この3点を実施すれば、SDK側の修正有無にかかわらず、Azure MLジョブ投入時の待ち時間を減らしやすくなります。

Azure
Azure Machine Learning Azure SDK Python SDK azure-ai-ml .amlignore

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次