Azure SDK KeyVaultのsetup.pyからpyproject.toml移行とは？影響範囲と確認手順

Azure SDKのKeyVault関連で「setup.pyからpyproject.tomlへ移行」と聞くと、アプリの認証コードやKey VaultのAPI呼び出しを直す必要があるのか不安になるかもしれません。結論から言うと、通常の利用者がpip install azure-keyvault-administrationでパッケージを使っているだけなら、まず確認すべきなのはアプリコードではなく、CI/CDや社内ビルド環境、パッケージ管理の設定です。

2026年5月5日に公開・更新された情報として確認すべきポイントは、Azure SDK for PythonのKeyVault data-planeパッケージのうち、azure-keyvault-administrationがsetup.py中心の構成から、PEP 621形式の[project]テーブルを持つpyproject.tomlへ移行される点です。GitHub上のPRでは、対象パッケージはsdk/keyvault/azure-keyvault-administrationで、setup.pyは削除対象、pyproject.toml側にビルド設定・依存関係・ライセンス・Python対応バージョンなどが移されています。(GitHub)

Azure SDK KeyVaultの今回の更新で何が変わるのか

今回の「Azure SDK documentation update: [KeyVault] Migrate packages from setup.py to pyproject.toml」は、Azure Key Vaultの機能仕様変更ではなく、Pythonパッケージのビルド・配布設定の近代化です。

具体的には、azure-keyvault-administrationのパッケージメタデータが、従来のsetup.pyではなくpyproject.tomlの[project]テーブルに整理されます。PEP 621は、Pythonパッケージのコアメタデータをpyproject.tomlに記述するための仕様で、メタデータを静的かつツール非依存に扱いやすくすることを目的としています。(Python Enhancement Proposals (PEPs))

変更の読み方を間違えないために、まず次のように整理してください。

観点	今回の変更内容	実務上の意味
対象パッケージ	azure-keyvault-administration	Key Vaultの管理系クライアントを使うPythonプロジェクトが確認対象
変更の種類	setup.pyからpyproject.tomlへの移行	API仕様変更ではなく、ビルド・配布設定の変更
ビルドバックエンド	setuptools.build_meta	PEP 517/PEP 621前提のビルド方式に寄る
ビルド要件	setuptools>=77.0.3とwheel	古いCI環境ではビルドツール更新が必要になる可能性
Python要件	requires-python = ">=3.9"	Python 3.8以下の環境は利用方針の見直しが必要
ライセンス表記	license = "MIT"	旧来のライセンスclassifierではなく、SPDX表現の確認が重要

PR上では、pyproject.tomlにname = "azure-keyvault-administration"、version = "4.7.0"、依存関係としてisodate>=0.6.1、azure-core>=1.38.0、typing-extensions>=4.6.0などが記載されています。また、readmeはREADME.mdとCHANGELOG.mdを使う動的設定として扱われています。(GitHub)

影響を受けやすいのはアプリ利用者よりビルド担当者

今回の変更で最も注意すべきなのは、Key Vaultのシークレット取得やアクセス制御のコードを書いているアプリ開発者そのものではなく、Azure SDK for Pythonをソースからビルド・検証・再配布している担当者です。

たとえば、次のような環境では影響が出やすくなります。

利用パターン	影響度	確認すべきこと
PyPIから通常インストールしている	低	アプリコードの変更は基本不要。依存関係とPythonバージョンを確認
GitHubのソースからインストールしている	中	pyproject.toml前提のビルドが通るか確認
CIでpython setup.pyコマンドを使っている	高	python -m buildやpython -m pip install .へ置き換える
社内ミラー・SBOM・ライセンススキャンを使っている	中	メタデータ取得元がpyproject.tomlに対応しているか確認
Linuxディストリビューションや社内パッケージへ再パッケージしている	高	specファイルやビルドスクリプトがsetup.py依存になっていないか確認

PyPAのガイドでも、python setup.py install、python setup.py develop、python setup.py sdistのようなコマンドではなく、python -m pip install .、python -m pip install --editable .、python -m buildの利用が推奨されています。(Python Packaging)

setup.pyからpyproject.tomlへの移行で確認すべき変更点

今回の更新は一見小さく見えますが、現場では「どのファイルから何を読んでいるか」が変わるため、ビルド自動化や監査ツールに影響することがあります。

ビルド設定は[build-system]を見る

pyproject.tomlでは、ビルドに必要なツールを[build-system]テーブルに書きます。今回のPRでは、ビルド要件としてsetuptools>=77.0.3とwheel、ビルドバックエンドとしてsetuptools.build_metaが指定されています。(GitHub)

これは、CI/CDで次のような古い前提を置いている場合に問題になりやすいポイントです。

python setup.py sdist bdist_wheel

今後は、少なくとも次のような形で検証するのが安全です。

python -m pip install --upgrade pip build wheel setuptools
cd sdk/keyvault/azure-keyvault-administration
python -m build
python -m pip install dist/*.whl
python -m pip check

pyproject.tomlがあるプロジェクトでは、pipやbuildなどのビルドフロントエンドがbuild-system.requiresに基づいて一時的なビルド環境を作る場合があります。ビルド隔離では、指定されたビルド時依存関係だけが入った環境でビルドされるため、「CIマシンにたまたま入っていたパッケージに依存してビルドが通る」という状態を発見しやすくなります。(Python Packaging)

パッケージメタデータは[project]へ移る

[project]テーブルには、パッケージ名、作者、説明、Python要件、依存関係、分類子、ライセンスなどの基本情報が入ります。Python Packaging User Guideでも、[project]は依存関係や作者名などの基本メタデータを指定するために多くのビルドバックエンドが使うテーブルとして説明されています。(Python Packaging)

今回のPRでは、主に次の項目がpyproject.toml側で確認できます。(GitHub)

項目	設定例	確認ポイント
パッケージ名	azure-keyvault-administration	依存管理ファイルや社内ミラーの名前と一致しているか
Python要件	>=3.9	古いPython環境での利用計画が残っていないか
バージョン	4.7.0	自動取得スクリプトがsetup.pyではなくメタデータを読めるか
依存関係	azure-core>=1.38.0など	lockファイルや制約ファイルと矛盾しないか
ライセンス	MIT	SBOM・ライセンス監査ツールが新表記を読めるか
README	README.mdとCHANGELOG.mdを動的利用	sdist/wheel作成時にファイルが含まれるか

特に社内のセキュリティレビューやOSSライセンスチェックで、setup.pyを直接解析している場合は注意が必要です。setup.pyがなくなると、古いツールでは「メタデータが見つからない」「ライセンスが不明」といった誤検知が起きる可能性があります。

ライセンス表記はSPDXのMITを確認する

PRのNotesでは、ライセンスはSPDX expressionのMITとして設定され、従来のLicense :: OSI Approved :: MIT License classifierは落とされると説明されています。(GitHub)

実務では、ここを軽視しないでください。ライセンス自体がMITから別のものへ変わったという意味ではなく、メタデータの書き方が変わるという意味です。ただし、監査ツールが古いclassifierだけを見ていると、ライセンス判定が変わったように見えることがあります。

確認すべき例は次のとおりです。

確認対象	ありがちな失敗	対応
SBOM生成ツール	ライセンスが空欄になる	pyproject.tomlのlicenseを読めるバージョンへ更新
社内OSS台帳	classifierの消失をライセンス変更と誤認	MIT表記を正として再確認
CIのポリシーチェック	旧メタデータ前提で失敗	チェックルールをPEP 621対応にする

対応が必要かを判断するチェックリスト

まず、自分のプロジェクトがazure-keyvault-administrationを使っているか確認します。

python -m pip show azure-keyvault-administration
python -m pip freeze | grep azure-keyvault-administration

WindowsのPowerShellなら、次のように確認できます。

python -m pip show azure-keyvault-administration
python -m pip freeze | Select-String azure-keyvault-administration

使っていない場合、今回のKeyVaultパッケージ移行による直接対応は基本的に不要です。使っている場合は、次の順で確認すると手戻りが少なくなります。

| 手順 | 確認内容 | 判断基準 |
| -: | ———– | —————————————– |
| 1 | インストール方法 | PyPIのwheel利用だけなら影響は限定的 |
| 2 | Pythonバージョン | Python 3.9以上であることを確認 |
| 3 | CIコマンド | python setup.pyを直接呼んでいないか確認 |
| 4 | ビルドツール | pip、build、setuptools、wheelが古すぎないか確認 |
| 5 | メタデータ取得 | ライセンス・バージョン・依存関係をpyproject.tomlから読めるか確認 |
| 6 | 成果物検証 | wheel作成、インストール、pip check、基本importを確認 |

基本importの確認は、次のような軽いテストで十分です。

python - <<'PY'
import azure.keyvault.administration
print("azure-keyvault-administration import OK")
PY

この時点で失敗する場合は、アプリコードではなく、インストールされたパッケージ、Pythonバージョン、依存関係、名前空間パッケージの解決を先に確認してください。

CI/CDで直すべきコマンド例

今回のような移行で最も壊れやすいのは、古いsetup.pyコマンドを前提にしたCIです。PyPAのガイドでは、setup.pyを直接実行するコマンドは推奨コマンドへ置き換える流れが示されています。(Python Packaging)

旧コマンド	推奨される置き換え	用途
python setup.py install	python -m pip install .	ローカルソースから通常インストール
python setup.py develop	python -m pip install --editable .	editable install
python setup.py sdist	python -m build	sdist/wheel作成
python setup.py bdist_wheel	python -m build	wheel作成

CIの例としては、次のように組み直すとトラブルを切り分けやすくなります。

python -m pip install --upgrade pip
python -m pip install --upgrade build wheel setuptools

cd sdk/keyvault/azure-keyvault-administration

python -m build
python -m pip install dist/*.whl
python -m pip check

python - <<'PY'
import azure.keyvault.administration
print("import OK")
PY

editable installを使う開発環境では、次も確認します。

python -m pip install --editable .
python - <<'PY'
import azure.keyvault.administration
print("editable install OK")
PY

Setuptoolsのドキュメントでも、pyproject.tomlを使う構成では[build-system]と[project]を中心に設定し、setuptools.build_metaをビルドバックエンドとして指定する例が示されています。古いツール互換が必要な場合は最小限のsetup.pyを残す方法もありますが、今回のAzure SDK側のPRではsetup.py削除が変更内容に含まれています。(Setuptools)

移行で失敗しやすいポイント

古いpipやbuildツールでソースインストールしている

pyproject.toml前提のビルドでは、古いpipやsetuptoolsを使っている環境ほど失敗しやすくなります。とくに、社内の閉じたネットワークでパッケージをビルドしている場合、setuptools>=77.0.3を取得できるかを事前に確認してください。

失敗例としては、次のようなものがあります。

ERROR: Could not build wheels for azure-keyvault-administration
ERROR: Backend subprocess exited when trying to invoke build_wheel

この場合、すぐにアプリコードを疑うのではなく、次を確認します。

確認項目	見るべき場所
pipのバージョン	python -m pip --version
buildの有無	python -m build --version
setuptoolsの解決	CIログ、社内ミラー
Pythonバージョン	python --version
build isolationの挙動	--no-build-isolationを使っていないか

setup.pyからバージョンを取得する独自スクリプトがある

PRのNotesでは、バージョンは移行時点で_version.pyから読み取った静的文字列として書かれると説明されています。動的なattr解決は、uvのbuild isolation内でlegacyなpkgutil.extend_path名前空間に対して失敗するため、静的なバージョンが使われるとされています。(GitHub)

このため、社内で次のような処理をしている場合は見直しが必要です。

python setup.py --version
python setup.py --name

代替としては、インストール済みパッケージのメタデータを読む方法が実用的です。

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

ソースツリーの状態で読む必要がある場合は、pyproject.tomlを解析する処理に切り替えます。ただし、リリース前後でバージョンが変わる可能性があるため、CIでは「期待するバージョンを固定して比較する」よりも、「ビルドされたwheelのメタデータを検証する」ほうが安全です。

packages.findのexclude設定で成果物が変わる

PRのコミット履歴では、[tool.setuptools.packages.find]のinclude/exclude設定をsetup.pyのfind_packages()と揃え、移行が振る舞いを変えないように調整したことが示されています。(GitHub)

ここは、パッケージ移行で見落とされやすいポイントです。exclude設定が広すぎると必要なサブパッケージがwheelに入らず、狭すぎるとテストやサンプルが意図せず配布物に入ることがあります。

確認するなら、ビルド後にwheelの中身を見ます。

python -m build
python -m zipfile -l dist/*.whl | grep azure/keyvault

Windows PowerShellでは次のように確認できます。

python -m build
python -m zipfile -l (Get-ChildItem dist\*.whl | Select-Object -First 1)

確認のポイントは、azure/keyvault/administration配下の実行に必要なファイルが含まれ、tests、samples、docなどが意図せず混ざっていないことです。

利用者別の対応方針

アプリ開発者は依存関係とPythonバージョンを確認する

Key Vaultを使うアプリ開発者は、まず現在の依存関係を確認してください。

python -m pip freeze | grep azure

または、プロジェクトの依存管理ファイルを確認します。

管理方法	確認するファイル
pip	requirements.txt、constraints.txt
Poetry	pyproject.toml、poetry.lock
uv	pyproject.toml、uv.lock
pip-tools	requirements.in、requirements.txt
社内テンプレート	独自の依存定義ファイル

通常のKey Vault操作コード、たとえば認証情報の取得やクライアント生成の処理は、今回のsetup.py移行だけで書き換える必要はありません。対応が必要になるのは、ビルド時やインストール時に失敗した場合です。

CI/CD担当者はsetup.py直呼びをなくす

CI/CD担当者は、リポジトリ内を検索してsetup.pyを直接呼んでいる箇所を洗い出してください。

grep -R "setup.py" -n .

PowerShellなら次のように確認できます。

Select-String -Path .\* -Pattern "setup.py" -Recurse

見つかった場合は、目的に応じてpython -m pip install .、python -m pip install --editable .、python -m buildへ置き換えます。置き換え後は、ビルドだけでなくインストール後のimport確認まで入れると、成果物の欠落を早期に検出できます。

セキュリティ・監査担当者はメタデータ取得元を確認する

SBOM、ライセンススキャン、脆弱性管理の観点では、setup.pyがなくなること自体よりも、ツールがPEP 621形式を読めるかが重要です。

確認すべき項目は次の3つです。

確認項目	理由
license = "MIT"を正しく読めるか	classifier消失をライセンス不明と誤判定しないため
dependenciesを読めるか	azure-coreなどの依存関係を漏らさないため
requires-pythonを読めるか	サポート外Python環境を検出するため

監査ツールが古い場合は、ビルド後のwheelメタデータを読む方法に切り替えるのも有効です。

python -m build
python -m pip install dist/*.whl
python - <<'PY'
from importlib.metadata import metadata
m = metadata("azure-keyvault-administration")
print("Name:", m.get("Name"))
print("Version:", m.get("Version"))
print("License:", m.get("License"))
print("Requires-Python:", m.get("Requires-Python"))
PY

すぐに実行できる確認手順

今回のAzure SDK KeyVault更新に備えるなら、次の順で確認すると効率的です。

優先度	作業	コマンド例
高	利用有無の確認	python -m pip show azure-keyvault-administration
高	Pythonバージョン確認	python --version
高	古いsetup.py呼び出しの検索	grep -R "setup.py" -n .
中	ビルドツール更新	python -m pip install -U pip build wheel setuptools
中	ソースビルド検証	python -m build
中	wheelインストール検証	python -m pip install dist/*.whl
中	依存関係検証	python -m pip check
低	SBOM・ライセンス確認	利用中ツールでpyproject.toml対応を確認

特に、社内ミラーや閉域CIを使っている環境では、setuptools>=77.0.3を取得できないことが原因でビルドが止まる可能性があります。インターネット接続の有無ではなく、ビルド時依存関係を社内リポジトリに取り込んでいるかを確認してください。

今回の更新をどう受け止めるべきか

今回のAzure SDK KeyVaultのsetup.pyからpyproject.tomlへの移行は、Key Vaultの使い方を変える更新ではありません。むしろ、Pythonパッケージングの標準的な流れにAzure SDKが追随していると捉えるのが適切です。

ただし、実務では「APIは変わっていないから何もしなくてよい」と判断すると、CI/CD、社内パッケージング、ライセンス監査でつまずくことがあります。次に取るべき行動は明確です。

まず、azure-keyvault-administrationを使っているか確認します。使っている場合は、setup.pyを直接呼ぶ処理を検索し、python -m buildやpython -m pip install .へ置き換えます。あわせて、Python 3.9以上、ビルドツールの更新、SBOM・ライセンススキャンのPEP 621対応を確認してください。

GitHub上のPRはDraftとして表示されており、少なくとも確認時点ではマージ済みリリース情報と同一視せず、今後のAzure SDK for Pythonの変更として追跡する必要があります。PR画面でも、Draft状態であり、承認レビューが必要であることが示されています。(GitHub)

小さなパッケージング変更に見えても、ビルド自動化では影響が出やすい領域です。アプリコードより先に、CI、依存管理、監査ツールの3点を確認しておくことが、今回の更新への最も現実的な対応です。