2026年5月5日に更新が確認された「Azure SDK documentation update: Fix async AzureMLOnBehalfOfCredential AttributeError on _identity_config」は、Azure Machine Learningジョブ内でユーザーIDの代理認証、いわゆるOBO認証を非同期クライアント経由で使う場合に発生する不具合への修正です。
結論から言うと、確認すべきポイントは3つです。identity: user_identity を指定したAzure MLジョブで、非同期のAzure SDKクライアントや非同期資格情報パスを使っているか。ログに AsyncManagedIdentityClient と _identity_config の AttributeError が出ているか。そして、修正が自分の利用している azure-ai-ml パッケージに取り込まれたバージョンかどうかです。
同期版の AzureMLOnBehalfOfCredential だけを使っている場合や、ローカル開発で DefaultAzureCredential を使っている場合は、今回の変更による直接影響は限定的です。一方で、Azure MLのトレーニングジョブからKey Vault、Storage、Azure AI系サービスなどへユーザーIDでアクセスし、さらに非同期処理を組み合わせている環境では、早めにログと依存パッケージを確認すべき更新です。
Azure SDK documentation update: Fix async AzureMLOnBehalfOfCredential AttributeError on _identity_config の概要
今回の更新は、Azure SDK for Pythonの azure-ai-ml に含まれるAzure ML向け認証処理の修正です。対象になっているのは、AsyncManagedIdentityClient.request_token の内部実装です。GitHub PRでは、存在しない self._identity_config を参照していたため、非同期のOBO認証フローで AttributeError が発生すると説明されています。(GitHub)
修正内容は小さく見えますが、実務上の影響は大きくなり得ます。Azure MLジョブ内でユーザーIDを使って外部リソースへアクセスする処理は、データ取得、シークレット取得、特徴量ストア連携、ジョブ内からのSDK呼び出しなどで使われます。認証トークン取得の段階で例外が出ると、後続のAPI呼び出しはすべて失敗します。
| 確認項目 | 内容 |
|---|---|
| 対象パッケージ | 主に azure-ai-ml のAzure ML認証まわり |
| 対象処理 | 非同期の AzureMLOnBehalfOfCredential / OBO認証経路 |
| 発生し得る例外 | AttributeError: 'AsyncManagedIdentityClient' object has no attribute '_identity_config' |
| 影響しやすい環境 | Azure MLジョブ、identity: user_identity、非同期Azure SDKクライアントの組み合わせ |
| 直接影響が小さい環境 | 同期クライアントのみ、ローカル開発のみ、OBOを使わないサービスプリンシパル認証など |
Microsoft Learnでは、AzureMLOnBehalfOfCredential はユーザーの代理で認証する資格情報であり、Azure Machine Learning ComputeまたはAzure Machine Learning Serverless Spark Computeのジョブ実行中に、ユーザーIDでジョブを実行する場合に使うものと説明されています。(Microsoft Learn)
何が変わったのか
PRで示されている主な修正は、非同期のトークン要求処理で呼び出すリクエスト生成処理の引数を見直した点です。修正前は、存在しない _identity_config を渡していました。
# 修正前のイメージ
request = self._request_factory(resource, self._identity_config)修正後は、同期版の実装と同じく resource のみを渡す形に変更されています。PR上の差分でも、self._request_factory(resource, self._identity_config) から self._request_factory(resource) への変更が確認できます。(GitHub)
# 修正後のイメージ
request = self._request_factory(resource)さらに修正ブランチの実装では、claims、tenant_id、enable_cae といった非対応のキーワード引数をトークン要求前に取り除く処理も確認できます。これは同期版の ManagedIdentityClient 側にも存在する考え方で、非同期版の挙動を同期版へ近づける意図が読み取れます。(GitHub)
| 変更点 | 修正前 | 修正後 | 実務上の意味 |
|---|---|---|---|
| リクエスト生成 | 存在しない _identity_config を参照 | resource のみで生成 | AttributeError の原因を除去 |
| 同期版との整合性 | 非同期版だけ異なる呼び出し | 同期版に近い処理 | 同じOBO認証でも挙動差が小さくなる |
| 非対応引数の扱い | パイプラインへ渡る可能性 | 事前に取り除く | 余計な引数による失敗を避けやすい |
重要なのは、この修正が「Azure MLのOBO認証全体を新しくする変更」ではなく、「非同期実装の内部バグを直す変更」である点です。アプリ側の認証設計を全面的に変える必要はありませんが、該当する非同期処理を使っている場合は、依存パッケージの更新確認が必要です。
エラーの正体：RBACやネットワーク設定ではなくSDK内部の属性参照ミス
この不具合で典型的に出るエラーは、次のような内容です。
AttributeError: 'AsyncManagedIdentityClient' object has no attribute '_identity_config'GitHub Issueでは、Azure MLジョブで非同期Azureクライアントを使いたい場面で、await credential.get_token("https://ai.azure.com/.default") を実行した際にこの例外が出るスタックトレースが報告されています。(GitHub)
ここで注意したいのは、_identity_config の AttributeError は、Key Vaultのアクセスポリシー不足やStorageのRBAC不足とは性質が異なるという点です。アクセス権限が不足している場合は、通常はトークン取得後のリソースアクセス時に403や権限エラーが出ます。一方、今回の問題はトークン要求を組み立てる前後でSDK内部の存在しない属性を参照して失敗します。
過去の別Issueでも、_identity_config が親クラスや子クラスで定義されていないため、AIO、つまり非同期実装のOBO資格情報でトークン取得に失敗する問題が報告されています。報告時の環境例には azure-ai-ml 1.26.0、Ubuntu、Python 3.11が含まれていました。(GitHub)
まず見るべきログ
Azure MLジョブの失敗ログで、次の文字列を検索してください。
_identity_config
AsyncManagedIdentityClient
AzureMLOnBehalfOfCredential
get_token failedこれらが同じスタックトレース内に出ている場合、まずSDK側の既知不具合として切り分けるのが効率的です。最初からKey Vaultのロール、StorageのACL、仮想ネットワーク、プライベートエンドポイントを疑うと、調査時間を無駄にしやすくなります。
影響を受ける可能性が高いユーザー
今回のAzure SDK更新で最も影響を受けるのは、Azure MLのリモートジョブ内で、ユーザーIDを使ったOBO認証と非同期処理を組み合わせている開発者です。
Microsoftのサンプルでは、AzureML OBOを使うにはジョブ定義でOBOを使うことを指定し、トレーニングスクリプト側で AzureMLOnBehalfOfCredential を使う必要があると説明されています。ジョブ定義では identity: type: user_identity を追加する例が示されています。(Microsoft Learn)
| 影響度 | 該当するケース | 対応の優先度 |
|---|---|---|
| 高 | Azure MLジョブで identity: user_identity を指定し、非同期Azure SDKクライアントを使っている | すぐにログと依存バージョンを確認 |
| 高 | ジョブ内でOBO認証を使い、_identity_config の AttributeError が出ている | 修正取り込み済みバージョンの確認が必要 |
| 中 | 今は同期処理だが、今後aioクライアントへ移行予定 | 移行前の検証項目に追加 |
| 低 | 同期版 AzureMLOnBehalfOfCredential のみを利用 | 直接影響は限定的 |
| 低 | DefaultAzureCredential、サービスプリンシパル、マネージドIDのみを利用 | 今回の不具合とは別系統 |
具体的には、次のような処理をAzure MLジョブ内で実行している場合に注意が必要です。
# 同期版の代表的な利用例
from azure.ai.ml.identity import AzureMLOnBehalfOfCredential
from azure.keyvault.secrets import SecretClient
credential = AzureMLOnBehalfOfCredential()
secret_client = SecretClient(
vault_url="https://my-key-vault.vault.azure.net/",
credential=credential
)
secret = secret_client.get_secret("secret-name")上記はMicrosoft LearnのOBOサンプルと同じ考え方です。OBOを使うと、リモートジョブ内のトレーニングスクリプトからユーザーのMicrosoft Entra IDを利用でき、ローカルでアクセスできるリソースにリモートジョブからもアクセスできると説明されています。(Microsoft Learn)
ただし、今回の問題は主に非同期経路です。同期版のサンプルが動いているからといって、同じ認証情報を非同期クライアントへ渡した場合も必ず安全とは限りません。
影響範囲を判断するチェックリスト
自分の環境が対象かどうかは、次の順番で確認すると切り分けやすくなります。
Azure MLジョブでユーザーIDを使っているか確認する
ジョブ定義、コンポーネント定義、パイプライン定義に次の設定があるか確認します。
identity:
type: user_identityこの設定がない場合、今回のOBO認証経路を使っていない可能性があります。ただし、別の場所で同等の設定をしている場合もあるため、ジョブ送信コードやYAMLテンプレートも確認してください。
非同期クライアントを使っているか確認する
Pythonコード内で次のような要素を探します。
async def
await
asyncio.run
azure.*.aio
get_token(...)特に、Key Vault、Storage、Event Hubs、Azure AI系サービスなどのaioクライアントをAzure MLジョブ内で使っている場合は注意が必要です。Issueで報告された再現例でも、非同期処理の中で credential.get_token() を待機した際に _identity_config の例外が出ています。(GitHub)
azure-ai-ml のバージョンを確認する
Azure MLの実行環境内で、実際に使われている azure-ai-ml のバージョンを確認します。ローカル端末のバージョンではなく、ジョブのDockerイメージやConda環境内のバージョンを見ることが重要です。
python -m pip show azure-ai-ml
python -m pip freeze | grep azure-ai-mlAzure SDKのリリース一覧では、Azure SDK for Pythonの各パッケージについてPyPI、コード、ドキュメントへのリンクが整理されています。azure-ai-ml がどのバージョンで配布されているかは、リリース一覧やPyPIで確認できます。(Azure)
ここで注意すべき点は、GitHubのPRが存在することと、修正済みパッケージがPyPIに公開されていることは同じではないという点です。PRがOpenの段階では、利用中の配布パッケージに修正が含まれているとは限りません。対象PRは確認時点でOpenとして表示され、マージにはレビューが必要な状態でした。(GitHub)
移行・設定確認でやるべきこと
今回の更新に対する実務対応は、「すぐにコードを書き換える」よりも「該当条件を確認し、修正済みバージョンへ安全に移行する」ことが中心です。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | 失敗ログを確認 | _identity_config の AttributeError があるか |
| 2 | ジョブ定義を確認 | identity: user_identity を使っているか |
| 3 | 非同期処理を確認 | aioクライアントや await credential.get_token() があるか |
| 4 | パッケージ確認 | Azure ML実行環境内の azure-ai-ml バージョンを確認 |
| 5 | 修正取り込み状況を確認 | リリースノート、PR、PyPIを確認 |
| 6 | 検証環境で再実行 | トークン取得と実リソースアクセスを確認 |
| 7 | 本番反映 | イメージ再ビルド、Conda環境更新、ジョブ再実行 |
修正済みバージョンが出るまでの回避策
修正済みパッケージをすぐに利用できない場合は、次の回避策を検討します。
| 回避策 | 向いているケース | 注意点 |
|---|---|---|
| 同期クライアントへ一時的に戻す | Key Vaultから少数のシークレットを読む程度 | 並列I/O性能は落ちる可能性がある |
| 非同期OBO認証に依存する処理を分離する | 一部の処理だけが失敗している | パイプライン設計の見直しが必要 |
| 修正済みパッケージの公開を待ってアップグレード | 本番環境で安定性を重視する | 公開バージョンとリリースノートを必ず確認 |
| SDK内部ファイルを独自パッチする | 緊急対応で、環境を厳密に管理できる | 長期運用には不向き。将来のSDK更新で衝突しやすい |
最も安全なのは、修正が正式リリースされた azure-ai-ml に更新し、Azure MLの実行環境を再ビルドして検証する方法です。Azure MLではジョブ環境のキャッシュやDockerイメージに古いパッケージが残ることがあるため、pip install -U だけでなく、実行ログで実際のバージョンを出力するのが確実です。
import azure.ai.ml
import importlib.metadata
print("azure-ai-ml:", importlib.metadata.version("azure-ai-ml"))アップグレード時の注意点
CondaファイルやDockerfileの固定バージョンを確認する
Azure MLジョブでは、conda.yaml やDockerfileにパッケージバージョンが固定されていることがあります。
dependencies:
- python=3.10
- pip
- pip:
- azure-ai-ml==1.xx.x
- azure-identity
- azure-keyvault-secrets修正済みバージョンへ移行する場合は、単にローカルでアップグレードするのではなく、ジョブ実行環境の定義ファイルを更新する必要があります。
dependencies:
- python=3.10
- pip
- pip:
- azure-ai-ml==<修正を含むバージョン>
- azure-identity
- azure-keyvault-secretsバージョンを未指定にすると、その時点の最新版が入るため一見便利です。しかし本番環境では再現性が落ちます。検証環境で動作確認したバージョンを固定し、CIやジョブログでバージョンを出力する運用が安全です。
内部モジュールへの依存を見直す
今回の問題は _aio や _internal を含む内部実装で発生しています。Azure SDKでは、先頭にアンダースコアが付くモジュールやクラスは、一般に公開APIとして長期互換性が保証されにくい領域です。
既存コードが内部の非同期資格情報クラスを直接importしている場合は、次の観点で見直してください。
| 確認点 | 理由 |
|---|---|
| public APIで代替できるか | 内部APIは変更されやすい |
importパスに _internal や _aio._credentials が含まれるか | 破壊的変更の影響を受けやすい |
| SDKのリリースノートでサポート対象になっているか | 長期運用の判断材料になる |
| 失敗時に同期版へ戻せる設計か | 本番障害時の回避策になる |
非同期処理が必須でない場合は、OBO認証まわりだけ同期クライアントで扱い、重いI/O処理だけ別の方法で並列化する設計も現実的です。
スコープは1回に1つだけ指定する
AzureMLOnBehalfOfCredential.get_token は、アクセストークンを要求するメソッドです。Microsoft Learnでは、この資格情報は1回のリクエストにつき1つのスコープのみ許可すると説明されています。(Microsoft Learn)
そのため、複数サービスへアクセスする場合は、サービスごとに適切なスコープでトークン取得やクライアント初期化を行う必要があります。
# 例：Key Vault
"https://vault.azure.net/.default"
# 例：Azure Storage
"https://storage.azure.com/.default"複数のスコープを一度に渡して失敗した場合、今回の _identity_config 問題とは別の原因になります。ログの例外名とスタックトレースを分けて確認してください。
SDK不具合と設定ミスを切り分ける
Azure MLの認証エラーは、SDK不具合、ジョブ設定、権限不足、実行環境の違いが混ざりやすい領域です。次の表を使うと、最初の切り分けがしやすくなります。
| 症状 | 可能性が高い原因 | 最初に確認すること |
|---|---|---|
AsyncManagedIdentityClient に _identity_config がない | 今回の非同期OBO認証バグ | azure-ai-ml のバージョン、修正取り込み状況 |
CredentialUnavailableError | OBOを利用できる実行環境ではない | Azure ML Compute / Serverless Spark上のジョブか |
No token received | OBOエンドポイントやジョブID設定の問題 | identity: user_identity、実行場所、ジョブログ |
| リソースアクセス時の403 | トークン取得後の権限不足 | Key Vault、Storage、Azure RBACの割り当て |
| ローカルでは成功、Azure MLジョブで失敗 | ローカル認証とジョブ内OBO認証の違い | 実行環境内の資格情報とパッケージバージョン |
特に、_identity_config の AttributeError が出ている場合は、RBACを調整しても解消しない可能性が高いです。まずSDKの修正状況を確認し、その後に権限やネットワークを調査する順番にしてください。
実務で使える最小検証手順
本番ジョブをいきなり更新する前に、最小構成の検証ジョブを作ると安全です。
検証ジョブで確認する内容
| 検証項目 | 期待する結果 |
|---|---|
azure-ai-ml のバージョン出力 | 想定した修正済みバージョンが表示される |
| OBO資格情報の初期化 | 例外なく作成できる |
| トークン取得 | _identity_config の例外が出ない |
| 実リソースアクセス | Key VaultやStorageにアクセスできる |
| ログ | トークン文字列を出力していない |
ジョブ内でトークンそのものをprintするのは避けてください。検証では、トークンの取得成功、期限、対象リソースへの疎通結果だけを出力するのが安全です。
import importlib.metadata
print("azure-ai-ml:", importlib.metadata.version("azure-ai-ml"))
# 実際の検証では、トークン文字列をログに出さない
print("OBO credential test started")検証後に本番へ反映する流れ
- 検証用Azure ML環境で
azure-ai-mlの修正済みバージョンを固定する - 最小ジョブでOBO認証と対象リソースアクセスを確認する
- 既存パイプラインのうち、非同期Azure SDKクライアントを使う箇所だけを先に検証する
- 本番用DockerイメージまたはConda環境を再ビルドする
- 本番ジョブの最初にパッケージバージョンをログ出力する
_identity_config、CredentialUnavailableError、403を分けて監視する
この流れにすると、SDK修正の効果と環境設定の問題を混同しにくくなります。
今回の更新で対応すべき人・様子見でよい人
| 立場 | 対応方針 |
|---|---|
| Azure MLジョブで非同期クライアントを使って失敗中 | すぐにPR・リリース状況と依存バージョンを確認 |
| これからAzure MLでaioクライアントを使う予定 | 検証項目に _identity_config エラー確認を追加 |
| 同期版OBOでKey Vaultなどにアクセスしている | 既存動作を確認しつつ、急な変更は不要 |
| OBOを使わずサービスプリンシパル認証を使っている | 今回の修正による直接対応は不要 |
| SDK内部モジュールを直接importしている | 長期運用リスクとしてpublic APIへの移行を検討 |
今回のAzure SDK documentation updateは、変更行数だけを見ると小さな修正です。しかし、Azure MLジョブ内のOBO認証は、シークレット取得、データアクセス、外部Azureサービス連携の入口になります。非同期処理でここが失敗すると、アプリケーション側の処理は正常でもジョブ全体が止まります。
まずはAzure MLジョブのログで _identity_config を検索してください。該当するエラーがある場合は、権限設定を変更する前に、azure-ai-ml のバージョンと修正取り込み状況を確認します。そのうえで、修正済みバージョンへの更新、実行環境の再ビルド、最小ジョブでのトークン取得テストを行うのが最短の対応ルートです。
コメント