Microsoft Entraドキュメント更新：Azure SDK for Python認証サンプルの影響と対応ポイント

「Microsoft Entra documentation update: [Automation] Collect examples from azure-sdk-for-python#azure-mgmt-iotcentral_9.0.1」は、Microsoft Entraのテナント設定や認証ポリシーを直接変更する更新ではありません。結論から言うと、2026年5月19日にAzure公式GitHubリポジトリへマージされた、Azure SDK for PythonのIoT Central管理クライアント向けサンプル追加です。影響を受けやすいのは、PythonでAzure IoT Centralを自動管理している開発者、CI/CDでサービスプリンシパルを使っている管理者、Microsoft Entraのアプリ登録・RBAC・シークレットを運用しているチームです。(GitHub)

今回すぐ確認すべきことは、サンプルコードをそのまま本番に流用しないこと、DefaultAzureCredentialがどのMicrosoft Entra ID資格情報を使うかを把握すること、サービスプリンシパルのRBAC範囲とクライアントシークレットの期限を棚卸しすることです。

今回のMicrosoft Entraドキュメント更新で何が変わったのか

今回の更新は、Azure REST API仕様に対応するSDKサンプルを管理する Azure/azure-rest-api-specs-examples リポジトリのPR #7405です。このリポジトリのサンプルはAzure REST APIドキュメントページへ統合される位置づけで、リポジトリ自体も自動パイプラインで管理されています。(GitHub)

観点	内容	実務で見るべきポイント
更新日	PRは2026年5月19日にmainへマージ	新しいサンプルを参照するチームは、社内手順書や検証コードとの差分を確認する
対象SDK	`azure-mgmt-iotcentral` 9.0.1	IoT Central管理のPython自動化で利用しているか確認する
対象API	`Microsoft.IoTCentral/IoTCentral/stable/2021-06-01` 配下のPythonサンプル	APIバージョンや既存コードの想定と合っているか確認する
認証方式	`azure.identity.DefaultAzureCredential` と `IotCentralClient` を使用	Microsoft Entraのアプリ登録、サービスプリンシパル、マネージドID、環境変数の設定を確認する
追加された例	アプリ作成・更新・削除・取得・一覧・テンプレート一覧・操作一覧など	読み取り系と変更系の操作を分けて、検証環境で実行する

PRでは、Apps_CheckNameAvailability、Apps_CheckSubdomainAvailability、Apps_CreateOrUpdate、Apps_Delete、Apps_Get、Apps_ListByResourceGroup、Apps_ListBySubscription、Apps_Templates、Apps_Update、Operations_List に対応するPythonファイルとメタデータJSONが追加されています。ファイル一覧上では .json が10件、.py が10件です。(GitHub)

なぜIoT Centralの更新がMicrosoft Entra管理者に関係するのか

一見するとIoT Central SDKのサンプル追加ですが、実行時の認証はMicrosoft Entra IDに依存します。Azure IdentityライブラリはAzure SDK全体でMicrosoft Entra IDベースのトークン認証を提供し、DefaultAzureCredentialはローカル開発環境とAzure上のホスティング環境で使う資格情報をまとめて扱うための仕組みです。(Microsoft Learn)

つまり、今回の更新を「サンプルコードが増えた」で終わらせると、次のような運用リスクを見落としやすくなります。

リスク	起きやすい場面	対応の方向性
想定外のIDで実行される	ローカルPCやCI環境に複数のAzure認証情報がある	実行前にテナントID、クライアントID、サブスクリプションIDを明示的に確認する
権限が強すぎる	サンプル検証用のサービスプリンシパルにOwnerや広いContributorを付与する	操作対象のリソースグループまたはリソース単位で最小権限を検証する
シークレット期限切れで停止する	CI/CD、バッチ、監視スクリプトでクライアントシークレットを使う	期限、保管場所、ローテーション手順を棚卸しする
本番リソースを変更・削除する	`begin_create_or_update` や `begin_delete` をサンプルのまま実行する	まず検証用リソースグループで読み取り系から実行する
古い認証実装と混在する	旧来のAzure SDKコードから一部だけサンプルを取り込む	`azure-identity` ベースに統一するか、移行範囲を明確にする

Microsoft Entraのセキュリティ更新として確認すべき影響範囲

今回のPR自体は、脆弱性修正やMicrosoft Entraテナントの強制変更ではありません。ただし、Microsoft Entraのアプリ登録、サービスプリンシパル、RBAC、シークレット管理に関係するため、管理者は「認証情報を使う自動化コードの更新」として扱うのが現実的です。

影響範囲は、次の基準で切り分けると判断しやすくなります。

利用状況	影響度	確認すべきこと
Azure portalだけでIoT Centralを管理している	低	直接のコード変更は不要。今後自動化する予定がある場合のみ確認
PythonでIoT Centralアプリを作成・更新・削除している	高	SDKバージョン、認証方式、RBAC、検証環境を確認
GitHub ActionsやAzure DevOpsでサービスプリンシパルを使っている	高	シークレット期限、権限範囲、環境変数、ログ出力を確認
Azure Functions、VM、Container AppsなどAzure上で実行している	中〜高	マネージドIDへ置き換えられるか確認
IoT Centralを使っていないがAzure SDK for Pythonを運用している	中	`DefaultAzureCredential`の考え方は他SDKにも共通するため、認証設計を再確認

Microsoftのドキュメントでは、Microsoft Entra IDにアプリを登録するとサービスプリンシパルが作成され、リソースへのアクセスは割り当てられたロールで制御されると説明されています。また、自動化ツールではユーザーIDではなくサービスプリンシパルを使うことが推奨されています。(Microsoft Learn)

管理者が最初に確認すべき設定

アプリ登録とサービスプリンシパルを棚卸しする

まず、IoT Central管理に使っているMicrosoft Entraアプリ登録を特定します。社内のコードリポジトリ、CI/CD変数、Key Vault、運用手順書から、次の文字列を検索すると見つけやすくなります。

azure.mgmt.iotcentral
IotCentralClient
DefaultAzureCredential
AZURE_CLIENT_ID
AZURE_TENANT_ID
AZURE_CLIENT_SECRET
AZURE_SUBSCRIPTION_ID

確認する項目は、アプリ名だけでは不十分です。アプリ登録とエンタープライズアプリケーション、サービスプリンシパルのオブジェクトID、所有者、RBAC割り当て、シークレットや証明書の期限まで見ます。

確認項目	見る理由
アプリケーションID、テナントID	サンプル実行時に別テナントへ向いていないか確認する
サービスプリンシパルの所有者	退職者や個人アカウントだけが所有者になっていないか確認する
RBACのスコープ	サブスクリプション全体に不要な権限を与えていないか確認する
クライアントシークレットや証明書の期限	期限切れによる自動化停止を防ぐ
サインインログや監査ログ	いつ、どのIDで、どの環境から実行されているか確認する

RBACは「サンプルが動く」ではなく「必要な操作だけ動く」で決める

サンプルコードを動かすためだけに、サービスプリンシパルへ広い権限を付けるのは避けるべきです。たとえば、一覧取得だけなら読み取り系の権限で足りる可能性があります。一方、IoT Centralアプリの作成・更新・削除を行う場合は、対象リソースグループに対する変更権限が必要になります。

実務では、次の順序で権限を検証します。

段階	実行する操作	権限確認の考え方
初期確認	`list_by_subscription`、`list_by_resource_group`	読み取りだけで通るか確認する
個別確認	`get`、名前やサブドメインの可用性確認	対象リソースを限定して確認する
変更検証	`create_or_update`、`update`	検証用リソースグループだけで実行する
削除検証	`delete`	本番環境では実行経路に承認や保護を入れる

「権限不足で失敗したからOwnerを付ける」は、短期的には楽ですが、長期的には監査・事故対応・委任管理を難しくします。サンプルの目的は動作確認であり、本番権限設計の完成形ではありません。

クライアントシークレットの期限切れに備える

サービスプリンシパルの資格情報には、クライアントシークレットや証明書があります。Microsoft Entraの推奨事項では、サービスプリンシパルの資格情報が期限切れになると認証できず、業務シナリオの停止につながる可能性があると説明されています。期限が近い資格情報はMicrosoft Entra管理センターやMicrosoft Graph APIで確認できます。(Microsoft Learn)

特に注意したいのは、サンプルコードのコメントにある AZURE_CLIENT_SECRET を、CI/CDの変数やローカル .env に入れたまま放置するケースです。Microsoft Entraのドキュメントでも、クライアントシークレットの値は作成後に一度しか表示されないため、適切な場所に保存する必要があると説明されています。(Microsoft Learn)

運用では、次のルールを決めておくと事故を減らせます。

ルール	具体例
シークレットをコードに書かない	Pythonファイル、README、Terraform変数ファイルへ直書きしない
保管先を統一する	Azure Key Vault、CI/CDのシークレットストアなどに集約する
期限を可視化する	期限30日前、14日前、7日前で通知する
ローテーション手順を作る	新旧シークレットを一時的に併存させ、切り替え後に旧シークレットを削除する
不要な資格情報を削除する	使っていないシークレットや証明書を残さない

可能ならマネージドIDかワークロードIDフェデレーションを検討する

Azure上で実行するワークロードなら、サービスプリンシパルのシークレットを持たせるより、マネージドIDを使う方が運用しやすい場合があります。Microsoftのドキュメントでも、マネージドIDをサポートするサービス上でコードが動き、Microsoft Entra認証に対応するリソースへアクセスする場合は、サービスプリンシパルの代わりにマネージドIDを検討するよう案内されています。(Microsoft Learn)

GitHub ActionsやAzure DevOpsなど、Azure外またはCI/CD基盤から実行する場合は、ワークロードIDフェデレーションも選択肢です。Microsoft EntraのワークロードIDフェデレーションは、外部IDプロバイダーとの信頼関係を構成し、対応シナリオではシークレットを管理せずにMicrosoft Entraで保護されたリソースへアクセスできる仕組みです。(Microsoft Learn)

実行環境	推奨しやすい認証方式	判断基準
Azure Functions、App Service、VM、Container Apps	マネージドID	Azure上で完結し、リソースへRBACを直接割り当てられる
GitHub Actions、Azure DevOps	ワークロードIDフェデレーション	長期シークレットをCI/CDに保存したくない
ローカル開発	開発者アカウントまたは検証用サービスプリンシパル	本番権限を持つ資格情報をローカルへ置かない
一時検証	期限を短くしたサービスプリンシパル	検証後に削除する前提で使う

開発者がサンプルコードを使う前に直すべき箇所

今回追加されたPythonサンプルは、pip install azure-identity と pip install azure-mgmt-iotcentral を前提に、DefaultAzureCredential() と IotCentralClient を使う構成です。サンプル内では AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET の設定が案内されています。(GitHub)

ただし、サンプルはあくまで例です。本番運用に近いコードへ落とし込むなら、最低限次の修正を行います。

サンプルで見かける点	そのまま使うリスク	修正例
`subscription_id="00000000-0000-0000-0000-000000000000"`	誤ったサブスクリプションで失敗、またはコードにIDを直書きする	`AZURE_SUBSCRIPTION_ID` から読み込む
`resource_group_name="resRg"`	実在しない、または本番リソースグループへ誤指定する	環境ごとの設定ファイルや変数で分ける
`resource_name="myIoTCentralApp"`	既存アプリを更新・削除する可能性がある	検証用の命名規則を使う
`"str"` のような仮値	APIエラーや意図しない設定になる	SKU、location、template、subdomainを実値に置き換える
`begin_delete(...).result()`	実行すると削除処理が完了するまで進む	削除系は検証環境だけで実行し、確認フローを入れる
環境変数の資格情報	別プロジェクトのサービスプリンシパルを拾う	実行前にテナントIDとクライアントIDをログで確認する

安全に書き直すなら、まずはサブスクリプションIDも環境変数から取得する形にします。

import os

from azure.identity import DefaultAzureCredential
from azure.mgmt.iotcentral import IotCentralClient

subscription_id = os.environ["AZURE_SUBSCRIPTION_ID"]

client = IotCentralClient(
    credential=DefaultAzureCredential(),
    subscription_id=subscription_id,
)

このコードだけでは、どの資格情報が使われたかまでは分かりません。ローカルPC、CI/CD、Azure上の実行環境では、DefaultAzureCredentialが使う候補が変わります。検証時は、実行環境、テナントID、サブスクリプションID、対象リソースグループをログや実行前チェックで明示してください。

azure-mgmt-iotcentral 9.0.1を使う時の注意点

PyPI上の azure-mgmt-iotcentral 9.0.1 は2026年5月18日に公開され、リリース履歴では「最新のコード生成ツールで再生成」とされています。また、同ページでは azure-identity のインストール、AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET、AZURE_SUBSCRIPTION_ID を使った認証例が示されています。(PyPI)

開発チームで特に見ておきたいのは、バージョン固定と既存コードの互換性です。

確認項目	対応
パッケージの固定	`azure-mgmt-iotcentral==9.0.1` のように検証済みバージョンを固定する
`azure-identity` の導入	既存コードが別の認証ライブラリに依存していないか確認する
Python実行環境	CI、ローカル、本番で同じPython系統を使う
LRO操作	`begin_create_or_update`、`begin_update`、`begin_delete` の完了待ちを設計する
例外処理	認証エラー、権限不足、リソース未検出、長時間操作の失敗を分けて扱う

古いAzure SDK実装では、azure.common.credentials や msrestazure.azure_active_directory を使った認証コードが残っていることがあります。azure-mgmt-iotcentral の過去のリリース履歴では、認証システムが刷新され、azure-identity クラスを使う方向に変更されたことが説明されています。古いコードへ今回のサンプルだけを継ぎ足すのではなく、認証処理をまとめて見直す方が安全です。(PyPI)

移行・展開時のおすすめ手順

今回の更新を受けて既存のPython自動化へ反映する場合は、いきなり本番パイプラインへ入れず、次の順序で進めます。

手順	作業内容	成功条件
現状調査	`IotCentralClient` とEntra関連の環境変数を検索する	対象コードと実行環境が一覧化されている
認証方式の決定	サービスプリンシパル、マネージドID、ワークロードIDフェデレーションから選ぶ	長期シークレットの要否が明確になっている
RBAC検証	検証用リソースグループで最小権限を割り当てる	読み取り・作成・更新・削除の必要範囲が分かる
SDK検証	`azure-mgmt-iotcentral` と `azure-identity` を固定して実行する	CIとローカルで同じ結果になる
変更系操作のテスト	作成、更新、削除を検証用アプリで試す	本番リソースに影響しないことを確認する
本番反映	承認フロー、ログ、ロールバック手順を整えて展開する	失敗時に停止・復旧できる
運用監視	シークレット期限、サインイン、操作ログを定期確認する	期限切れや想定外のID利用を検知できる

この手順で重要なのは、認証テストと操作テストを分けることです。認証が通ることと、本番で安全に変更操作を実行できることは別問題です。

よくある失敗と回避策

環境変数が別プロジェクトの資格情報を指している

DefaultAzureCredentialは便利ですが、環境変数が設定されていると、その資格情報を使って認証することがあります。複数のAzureプロジェクトを扱う開発PCや共用CIランナーでは、意図しないテナントやサブスクリプションへ向くことがあります。

回避策は、実行前に AZURE_TENANT_ID、AZURE_CLIENT_ID、AZURE_SUBSCRIPTION_ID を明示的に出力することです。ただし、AZURE_CLIENT_SECRET は絶対にログへ出してはいけません。

アプリ登録はあるがAzure RBACがない

Microsoft Entraにアプリ登録を作っただけでは、Azureリソースを操作できません。IoT Centralアプリを作成・更新・削除するには、対象スコープで適切なAzure RBACが必要です。Microsoftのドキュメントでも、サブスクリプション内のリソースへアクセスするにはアプリケーションにロールを割り当てる必要があると説明されています。(Microsoft Learn)

認証エラーと権限不足エラーを混同すると、無駄にシークレットを再発行したり、過剰な権限を付けたりしがちです。エラーメッセージを確認し、トークン取得に失敗しているのか、Azure Resource Manager側で権限不足なのかを分けて調査してください。

サンプルの削除処理を本番で実行してしまう

今回追加されたサンプルには Apps_Delete.py も含まれます。これは学習や検証には有用ですが、本番環境で誤実行するとIoT Centralアプリ削除につながります。削除系や更新系のサンプルは、リポジトリへ取り込む前に次の対策を入れてください。

対策	具体例
環境ガード	`ENVIRONMENT=production` の場合は削除処理を実行しない
名前ガード	`dev-` や `test-` で始まるリソースだけ操作する
承認ガード	CI/CDで手動承認後だけ変更系ジョブを実行する
ログ出力	対象サブスクリプション、リソースグループ、リソース名を実行前に表示する

シークレットローテーションが手順化されていない

シークレットを1つだけ使っている状態で期限当日に更新すると、反映漏れでパイプラインが止まりやすくなります。新しいシークレットを追加し、CI/CD側を切り替え、動作確認後に古いシークレットを削除する流れを手順化しておきます。

証明書やマネージドIDへ移行できる環境では、長期のクライアントシークレットを減らす方が運用負荷を下げやすくなります。

今回の更新で取るべき次のアクション

今回のMicrosoft Entra documentation updateは、Microsoft Entraの設定変更そのものではなく、Azure SDK for PythonのIoT Central管理サンプル追加です。ただし、サンプルの実行にはMicrosoft Entra IDの認証、サービスプリンシパル、RBAC、シークレット管理が深く関係します。

管理者と開発者は、次の順で対応すると実務に落とし込みやすくなります。

優先度	やること
高	`azure.mgmt.iotcentral`、`IotCentralClient`、`AZURE_CLIENT_SECRET` を含むコードとCI/CD設定を検索する
高	対象サービスプリンシパルのRBAC範囲、所有者、シークレット期限を確認する
高	`Apps_Delete` や `Apps_Update` など変更系サンプルを本番で誤実行しないガードを入れる
中	Azure上で実行する処理はマネージドIDへ置き換えられるか検討する
中	CI/CDはワークロードIDフェデレーションで長期シークレットを減らせるか検討する
中	`azure-mgmt-iotcentral==9.0.1` と `azure-identity` の組み合わせを検証環境で固定して試す

サンプル更新は、単なるコード例の追加に見えても、実行環境ではIDと権限の設計に直結します。まずは「どのIDが、どのスコープで、どの操作を実行できるのか」を一覧化し、検証環境で読み取り系から確認してください。そのうえで、作成・更新・削除の自動化を段階的に展開するのが安全です。

この記事を書いた人

佐藤健司

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