2026年5月5日に公開または更新された「Microsoft Purview documentation update: [Purview] Migrate packages from setup.py to pyproject.toml」でまず押さえるべき点は、Microsoft Purviewそのものの設定変更ではなく、Purview向けAzure SDK for Pythonパッケージのビルド定義変更だということです。
対象は azure-purview-administration、azure-purview-datamap、azure-purview-scanning、azure-purview-sharing、azure-purview-workflow の5パッケージです。これらのパッケージで、従来の setup.py から、PEP 621形式の [project] テーブルを持つ pyproject.toml へ移行する内容になっています。公式PRではこの変更が「active data-plane packages off setup.py」への継続的な取り組みの一部と説明されています。(GitHub)
Purviewのデータマップ、スキャン、共有、ワークフローをPythonから扱っている開発者は、アプリのAPI呼び出しよりも、CI/CD、パッケージビルド、社内ミラー、SBOMやライセンス監査、ロックファイル更新への影響を確認するのが実務上の優先事項です。
Microsoft Purviewのpyproject.toml移行で何が変わるのか
今回のMicrosoft Purview documentation updateの中心は、Azure SDK for Pythonリポジトリ内にあるPurview系データプレーンパッケージのパッケージング方式を整理する変更です。
公式PRでは、5つのPurview data-plane packageを setup.py から pyproject.toml のPEP 621 [project] テーブルへ移行すると説明されています。対象パッケージは、管理、データマップ、スキャン、共有、ワークフローに関するPurviewクライアントライブラリです。(GitHub)
| 確認項目 | 変更内容 | 利用者が見るべきポイント |
|---|---|---|
| 対象パッケージ | Purview系の5つのPython SDKパッケージ | 自社コードやCIで該当パッケージを使っているか確認する |
| ビルド定義 | setup.py から pyproject.toml へ移行 | python setup.py ... 前提の処理がないか確認する |
| メタデータ | [project] に名前、バージョン、依存関係などを記述 | パッケージ監査や社内管理ツールが参照する場所が変わる可能性がある |
| ライセンス表記 | license = "MIT" のSPDX表現へ | ライセンススキャナーがclassifierだけを見ていないか確認する |
| バージョン | 移行時点で _version.py から読み取った静的文字列 | 独自ビルドやソース取得時にバージョン検出方法を確認する |
| README | README.md と CHANGELOG.md を使う動的readme | ソースを加工・再配布する場合は関連ファイルを削らない |
重要なのは、これはPurviewポータルのUI変更やMicrosoft Purviewアカウントの設定移行ではないことです。Python SDKを通常どおり pip install して使っているだけなら、すぐにアプリコードを書き換える変更とは限りません。一方で、ソースからビルドしている環境や、Azure SDKリポジトリを直接参照しているCIでは影響が出やすくなります。
対象となるPurview系Python SDKパッケージ
今回のPRで移行対象として示されているパッケージは次の5つです。(GitHub)
| パッケージ名 | 主な用途の目安 | 確認すべき利用シーン |
|---|---|---|
azure-purview-administration | Purview管理系の操作 | Purviewアカウント管理や管理API連携 |
azure-purview-datamap | データマップ関連 | カタログ、エンティティ、分類、メタデータ連携 |
azure-purview-scanning | スキャン関連 | データソーススキャンの自動化や状態確認 |
azure-purview-sharing | データ共有関連 | 共有機能をPythonから操作する処理 |
azure-purview-workflow | ワークフロー関連 | 承認フローやガバナンス処理の自動化 |
まずは、自社環境でこれらのパッケージを使っているか確認します。
python -m pip freeze | grep -E "azure-purview-(administration|datamap|scanning|sharing|workflow)"Windows PowerShellなら、次のように確認できます。
python -m pip freeze | Select-String "azure-purview-(administration|datamap|scanning|sharing|workflow)"該当パッケージが表示された場合は、コード変更の有無より先に、インストール方法とビルド方法を確認してください。特に、GitHubのAzure SDKリポジトリから直接インストールしている場合や、社内でソース配布を再ビルドしている場合は注意が必要です。
pyproject.tomlへの移行はなぜ重要なのか
pyproject.toml は、Pythonパッケージングで使われる設定ファイルです。Python Packaging User Guideでは、[build-system] はビルドバックエンドとビルドに必要な依存関係を宣言する場所、[project] は依存関係や名前などの基本メタデータを記述する場所と説明されています。(Python Packaging User Guide)
今回のPurview系パッケージでは、[build-system] に setuptools>=77.0.3 と wheel を指定し、build-backend に setuptools.build_meta を使う構成が追加されています。たとえば azure-purview-administration の差分では、pyproject.toml に [build-system] と [project] が追加され、同時に setup.py が削除されています。(GitHub)
従来の setup.py はPythonコードとして実行できるため柔軟ですが、メタデータがツールから静的に読み取りにくいことがあります。pyproject.toml に移ると、名前、依存関係、対応Pythonバージョン、ライセンスなどを標準化された形式で扱いやすくなります。
一方で、setup.py 自体が完全に非推奨になったわけではありません。Python Packaging User Guideは、setup.py とSetuptoolsは非推奨ではない一方、python setup.py install や python setup.py sdist のように setup.py をコマンドとして直接実行する使い方は非推奨だと説明しています。(Python Packaging User Guide)
つまり今回の変更は、「Purview SDKが使えなくなる」という話ではなく、Pythonパッケージの作り方が現代的な標準形式に寄っていく変更と理解すると判断しやすくなります。
利用者への影響範囲
影響が出やすいのは、Purview SDKのAPIを呼び出すアプリ本体よりも、パッケージを取得・ビルド・検査する周辺プロセスです。
| 利用状況 | 影響度 | 対応の目安 |
|---|---|---|
| PyPIから通常のwheelをインストールしている | 低 | 次回アップデート時にテストを実行する |
pip install azure-purview-datamap など通常利用のみ | 低〜中 | lockファイル更新時に依存解決結果を確認する |
| Azure SDK for Pythonのソースからビルドしている | 中〜高 | pyproject.toml 前提のビルドに切り替える |
CIで python setup.py コマンドを実行している | 高 | python -m build や python -m pip install . に置き換える |
社内ツールが setup.py を解析してメタデータを取得している | 高 | pyproject.toml の [project] を読むよう修正する |
| ライセンス監査がclassifier前提 | 中 | SPDX形式の license = "MIT" を検出できるか確認する |
公式PRには、License :: OSI Approved :: MIT License classifierを落とし、license をSPDX表現の MIT にする注記があります。また、バージョンは移行時点で _version.py から読み取った静的文字列とし、READMEは README.md と CHANGELOG.md を使う動的設定のままとされています。(GitHub)
ライセンス監査ツールやSBOM生成ツールが古いclassifierだけを見ている場合、MITライセンスを見落とす可能性があります。実務では、ライセンス表記が変わったときに「ライセンスが消えた」と誤判定されるケースがあるため、監査ルールの確認が必要です。
まず確認すべきチェックリスト
この更新を見たら、次の順番で確認すると無駄がありません。
| 手順 | 確認内容 | コマンド・確認場所の例 |
|---|---|---|
| 1 | 対象パッケージを使っているか | pip freeze、requirements.txt、pyproject.toml、poetry.lock |
| 2 | ソースビルドしているか | CI/CDのインストール手順、Dockerfile |
| 3 | setup.py 直接実行がないか | grep -R "setup.py" . |
| 4 | 古いビルド環境ではないか | pip、setuptools、wheel、buildのバージョン |
| 5 | ライセンス監査が通るか | SBOM、SCA、社内OSS審査ツール |
| 6 | アプリの結合テストが通るか | Purview APIを呼ぶ定期ジョブ、スキャン自動化処理 |
LinuxやmacOSでは、CI定義やDockerfileに setup.py が残っていないか次のように確認できます。
grep -R "setup.py" . \
--exclude-dir=.git \
--exclude-dir=.venv \
--exclude-dir=node_modulesPowerShellでは次のように確認できます。
Get-ChildItem -Recurse -File |
Select-String "setup.py" |
Select-Object Path, LineNumber, Line特に次のようなコマンドが残っている場合は見直し対象です。
| 古い書き方 | 推奨される置き換え例 |
|---|---|
python setup.py install | python -m pip install . |
python setup.py develop | python -m pip install --editable . |
python setup.py sdist | python -m build |
python setup.py bdist_wheel | python -m build |
Python Packaging User Guideでも、python setup.py install は python -m pip install .、python setup.py sdist や bdist_wheel は python -m build へ置き換える流れが示されています。(Python Packaging User Guide)
CI/CDで見直すべきポイント
Purview系SDKを使うアプリのCI/CDでは、次の3点を優先して確認してください。
python setup.py 前提の処理をなくす
今回のPRでは、対象パッケージで setup.py が削除されています。ファイル差分にも、各パッケージの pyproject.toml 追加と setup.py 削除が表示されています。(GitHub)
そのため、ソースから対象パッケージをビルドするCIで次のような処理があると失敗する可能性があります。
python setup.py sdist
python setup.py bdist_wheel
python setup.py install代わりに、ビルドフロントエンドを使います。
python -m pip install --upgrade pip build setuptools wheel
python -m build
python -m pip install dist/*.whlビルド分離に対応した環境にする
pyproject.toml の [build-system] は、ビルドに必要なツールを宣言します。今回の差分では、setuptools>=77.0.3 と wheel が指定されています。(GitHub)
通常の新しいpip環境では、この指定に基づいてビルド分離が行われます。ただし、古いCIイメージや社内制限のあるビルド環境では、必要なビルド依存関係を取得できず失敗することがあります。
確認すべき典型例は次のとおりです。
python -m pip --version
python -m pip show setuptools wheel build社内ネットワークでPyPIへの直接アクセスを制限している場合は、社内ミラーに setuptools、wheel、build の必要バージョンがあるかも確認してください。
lockファイル更新時に依存関係を見直す
今回の変更はパッケージのメタデータ配置に関わるため、requirements.txt、requirements.lock、poetry.lock、uv.lock などを更新するタイミングで差分を確認するのが安全です。
特に見るべき点は次の3つです。
- 対象Purviewパッケージのバージョンが変わっていないか
azure-coreなど周辺依存関係のバージョン制約が変わっていないか- wheelではなくsdistからビルドされる流れになっていないか
通常運用では「インストールできたか」だけでなく、Purview APIを実際に呼ぶジョブを1本流して確認します。たとえば、Data Mapのエンティティ取得、Scanningのスキャン状態取得など、自社で最もよく使う処理を回すのが効率的です。
変更されないと考えてよい点
今回のPRを見る限り、主眼はパッケージング形式の移行です。Purviewサービスの認証方式、APIエンドポイント、Azure Portal上の設定、データカタログやスキャンの仕様変更を示す内容ではありません。
特に混同しやすいのは、次の点です。
| 誤解しやすい点 | 実際の見方 |
|---|---|
| Purviewアカウントの移行が必要になる | 今回の主題はPython SDKのパッケージング変更 |
| APIコードを全面的に書き換える必要がある | PR上はビルド定義・メタデータ移行が中心 |
setup.py がなくなるのでPython SDKが使えない | pyproject.toml 経由でビルドする形に変わる |
| MITライセンスではなくなる | SPDX表現の license = "MIT" に整理される |
PRのコミットメッセージには、[tool.setuptools.packages.find] のinclude/excludeリストを setup.py の find_packages() と一致させ、移行をbehavior-preservingにする意図も記載されています。(GitHub)
ただし、これは「絶対に影響がない」と断定するものではありません。ビルド・配布・監査・社内ミラーなど、アプリコード以外の工程では失敗する余地があります。
注意したい失敗パターン
setup.py を探す社内スクリプトが失敗する
社内のOSS管理ツールやビルドスクリプトが、次のように setup.py の存在を前提にしている場合があります。
python setup.py --name
python setup.py --version
python setup.py egg_infopyproject.toml 移行後は、この前提が崩れます。メタデータ取得は、pyproject.toml の [project] を読むか、ビルド済みwheelのメタデータを確認する流れに変える必要があります。
古いsetuptoolsでライセンス表記に失敗する
今回の差分では license = "MIT" というSPDX形式が使われています。Python Packaging User Guideでも、現在の license はSPDX license expressionとして記述する形式が説明されています。(Python Packaging User Guide)
古いビルドバックエンドや社内ツールでは、この形式に対応しておらず、license はテーブルであるべきだというエラーや、ライセンス未検出の誤判定が出ることがあります。CIでライセンスチェックをしている場合は、Purview SDK更新時に必ず監査結果を確認してください。
READMEやCHANGELOGを削ってソース配布を再ビルドする
今回のPRでは、READMEは README.md と CHANGELOG.md を使う動的設定のままとされています。(GitHub)
社内でソースを取り込み、不要ファイルを削ってから再ビルドする運用では、READMEやCHANGELOGを削除したことでビルドメタデータ生成に失敗する可能性があります。ソース再配布やミラー運用をしている場合は、パッケージルートのドキュメントファイルを不用意に削らないようにしましょう。
PR段階の情報をリリース済みと誤解する
確認時点で、該当PRはGitHub上でDraftとして表示されています。つまり、PRの内容がそのままマージ済み・リリース済みであるとは限りません。(GitHub)
実務では、次の順番で確認すると安全です。
- PRの状態を確認する
- マージ済みか確認する
- 対象パッケージのリリースノートやPyPI上のバージョンを確認する
- lockファイルを更新する
- CIと結合テストを実行する
「PRを見たからすぐ本番更新」ではなく、リリース反映後に検証環境で確認するのが安全です。
実務での対応手順
Purview SDKを使っている開発チームは、次の流れで対応すると整理しやすくなります。
現在の利用パッケージを棚卸しする
まず、対象の5パッケージが入っているか確認します。
python -m pip freeze | grep "azure-purview"表示されたパッケージが対象に含まれる場合は、次にどこからインストールしているかを確認します。
python -m pip show azure-purview-datamapLocation、Version、Requires を見て、通常のPyPIインストールなのか、社内ミラー経由なのか、ローカルソースなのかを切り分けます。
ビルド手順をpyproject.toml前提に更新する
自社プロジェクト側でPurview SDKをソースビルドしていなくても、CIテンプレートに古いPythonパッケージング手順が残っていることがあります。
見直し後の例は次のようになります。
python -m pip install --upgrade pip
python -m pip install --upgrade build setuptools wheel
python -m pip install -r requirements.txt
python -m pytestソースからパッケージをビルドする場合は、対象ディレクトリで次のように実行します。
python -m build
python -m pip install dist/*.whlPurview連携の最小テストを用意する
ビルドが通っても、実際のPurview連携が壊れていないかは別問題です。更新後は、普段使っている処理のうち最小限のテストを実行します。
| 利用機能 | 最小テスト例 |
|---|---|
| Data Map | 既存エンティティを1件取得する |
| Scanning | 登録済みスキャンの一覧または状態を取得する |
| Sharing | 共有リソースの取得処理を実行する |
| Workflow | 既存ワークフローの参照処理を実行する |
| Administration | 管理対象リソースの読み取り処理を実行する |
ポイントは、新規作成や削除を伴うテストではなく、まず読み取り系のテストで確認することです。本番データに影響を与えず、認証、依存関係、import、HTTP通信の問題を早めに検出できます。
管理者・開発者・セキュリティ担当ごとの確認ポイント
今回の更新は、担当者によって見るべき場所が変わります。
| 担当者 | 確認ポイント | 具体的な行動 |
|---|---|---|
| 開発者 | import、依存関係、テスト | 対象パッケージ更新後にユニットテストと結合テストを実行 |
| CI/CD担当 | ビルドコマンド、Dockerfile、runner環境 | python setup.py を検索し、python -m build へ置換 |
| セキュリティ担当 | ライセンス検出、SBOM、SCA | SPDX形式のMITライセンスを検出できるか確認 |
| データ基盤担当 | Purviewジョブの継続稼働 | スキャンやメタデータ同期ジョブを検証環境で確認 |
| 情シス・運用担当 | 社内ミラー、プロキシ、許可リスト | 必要なビルド依存関係を取得できるか確認 |
この変更で最も見落としやすいのは、アプリ担当者ではなく、社内のビルド・監査・配布基盤を管理するチームです。アプリは動くのに、SBOM生成や社内パッケージ登録で止まることがあります。
次に取るべき行動
今回のMicrosoft Purview documentation updateは、Purviewの業務機能変更ではなく、Purview系Azure SDK for Pythonパッケージの setup.py から pyproject.toml への移行です。通常のAPI利用者は慌ててコードを書き換える必要はありませんが、CI/CDや社内パッケージ管理に関わるチームは早めに確認しておくべき変更です。
まずは、対象5パッケージを使っているかを pip freeze やlockファイルで確認してください。該当する場合は、CIに python setup.py が残っていないか、古いsetuptools前提になっていないか、ライセンス監査がSPDX形式を読めるかを確認します。
最後に、Purview連携の読み取り系テストを1つ用意しておくと、今後のSDK更新でも影響を素早く判断できます。今回のようなパッケージング変更はアプリコード上では目立ちませんが、ビルドと監査の工程で差が出ます。更新前に「どのパッケージを、どこから、どうビルドしているか」を把握しておくことが、最も確実な対策です。
コメント