公開2026.07.23更新2026.09.29 Azure

Azure Key Vaultとは：シークレット・キー・証明書の一元管理とRBAC既定化・Managed HSMの違いをCLIとPythonの実例で解説

Azure Key Vaultは、パスワード・接続文字列・APIキーといったシークレット、暗号鍵、TLS証明書を1か所に集約し、Microsoft Entra IDの認証と認可のもとで安全に受け渡すMicrosoft Azureのマネージドサービスです。実装で最初に押さえるべきは、管理対象がシークレット・キー・証明書の3種類に分かれること、操作面がコントロールプレーンとデータプレーンの2層に分かれること、そしてStandard・Premium・Managed HSMという選択肢で鍵の保護方式と専有性が変わることです。

2026年に入って仕様面の変化も続いています。API バージョン2026-02-01以降では新規に作るボールトの認可モデルがAzure RBACに既定化され、PremiumのHSMはFIPS 140-3レベル3で検証されたモジュールへ切り替わりました（いずれも2026年9月時点のMicrosoft Learnの概要ページの記載）。この記事では定義から、認可モデル、論理削除やパージ保護、Azure CLIとPythonでシークレットを作成・取得する手順、App ServiceとAKSからの取り出し方、スロットリング上限と課金単位、AWSのSecrets Manager／KMSとの対応関係、そして「どんなシステムで採用し、どこでは別サービスにするか」の判断基準までを、公式ドキュメントに基づいて整理します。

まとめ：Azure Key Vaultの要点と採用判断の分岐を先に確認する

Azure Key Vaultは、アプリのコードや構成ファイルに機密情報を直書きしないための「秘密の金庫」として、Azure上のシステムで第一候補になるマネージドサービスです。シークレット・キー・証明書を金庫（ボールト）に格納し、アプリはMicrosoft Entra IDのマネージドIDで認証したうえで、ボールト名.vault.azure.netというエンドポイントから必要な値だけを取得します。運用設計の中心は、誰が何を操作できるかを決める認可モデル（Azure RBAC推奨・新規作成では既定）と、削除事故から守る論理削除・パージ保護、そして到達経路を絞るネットワーク制御の3点になります。

採用が合理的なのは、Azure中心のシステムで資格情報をコードから排除し、鍵のローテーションや証明書の更新を集中管理したい場合です。逆に、鍵を扱うHSMに単一テナント専有とHSM単位で閉じた管理権限が要件化されているならManaged HSMを、AWS中心の構成ならSecrets ManagerやKMSを検討します。クラウドやオンプレミスをまたいでシークレットを一元管理したい場合は、自前運用型のHashiCorp Vaultによるシークレット管理も比較検討の対象になります。

実装の入口は、ボールトをRBACとパージ保護つきで作り、アプリのマネージドIDに「Key Vault Secrets User」だけを付け、App ServiceならKey Vault参照、AKSならSecrets Store CSIドライバー、それ以外はSDKで取得する、という流れです。この記事の手順章に、そのままコピーして動かせるCLIとPythonの例を載せています。自社システムでシークレット管理をどう設計するか迷う段階なら、クラウド全体の構成から相談できる開発会社に早めに当たると、後戻りの少ない設計にたどり着けます。

Azure Key Vaultの仕組みと3種類の管理対象データを理解する

Key Vaultは「ボールト」という論理的な金庫を単位に、機密データを暗号化して保管するサービスです。何を格納するかによって扱いが変わるため、まず3種類の管理対象を区別するところから設計が始まります。

シークレット・キー・証明書を一元管理するマネージドサービスという位置づけ

Key Vaultが扱う対象は3種類です。シークレットは、データベースの接続文字列やAPIキーのような任意の文字列を暗号化して保管する枠で、1件あたり最大25KBまで格納できます。キーは、RSAや楕円曲線などの暗号鍵そのもので、鍵を外部に出さずに署名・暗号化・復号といった演算をKey Vault内で実行できる点が特徴です。証明書は、TLS/SSL証明書のライフサイクル（発行・更新・失効）を管理する枠で、対応する公的認証局と連携すれば登録や更新の一部を自動化できます。

シークレットはURIで版（バージョン）まで指定して取り出せるため、ローテーションで新しい版を足しても、アプリ側は「最新版」を参照するか「特定の版」に固定するかを選べます。暗号鍵と暗号方式そのものの前提は、暗号化の仕組みと共通鍵・公開鍵の違いを解説した記事で確認しておくと、キー管理の話が読み解きやすくなります。

コントロールプレーンとデータプレーンという2つの操作面の分離

Key Vaultの操作は、性質の異なる2つの面に分かれます。コントロールプレーンは、ボールトそのものを作成・削除し、SKUやアクセス構成、タグを変更する管理面で、Azure Resource Manager（management.azure.com）を通じて操作します。データプレーンは、ボールトの中身であるシークレット・キー・証明書を実際に読み書きする面で、ボールト名.vault.azure.netの専用エンドポイントやSDK経由でアクセスする仕組みです。

この2面は認可も別々に効くため、「ボールトは作れるが中の値は読めない」「値は読めるがボールト設定は変えられない」といった分離した権限設計が可能になります。RBACガイドによると、コントロールプレーンの認可はAzure RBAC、データプレーンはAzure RBACまたは旧来のアクセスポリシーで行います。実装では、この境界を意識して運用担当と開発担当の権限を切り分けるのが定石です。

StandardとPremiumの2つのSKUとManaged HSMの位置づけを整理

ボールトのSKUは2種類で、鍵をどこで保護するかが変わります。StandardはFIPS 140レベル1で検証されたソフトウェアの暗号ライブラリで保護し、多くの用途にはこちらで十分です。Premiumは、HSMで生成・保護される鍵（RSA-HSM、EC-HSMなど）を扱え、2026年9月時点ではFIPS 140-3レベル3で検証されたMarvell LiquidSecurityのHSMが使われています。旧来の解説で見かける「PremiumはFIPS 140-2レベル2」という記述は、HSM群のファームウェア更新によって現行の記載と食い違っているので注意してください。

さらに要件が厳しい場合は、Key Vaultのボールトとは別リソースのManaged HSMがあります。Managed HSMの概要によると、こちらも検証レベルはFIPS 140-3レベル3で、Premiumとの違いは単一テナント専有のHSMクラスターである点と、サブスクリプション管理者でも上書きできないHSM単位のローカルRBACを持つ点です。次の表に位置づけを整理します。

種別	鍵の保護	主な用途
Standard	ソフトウェア（FIPS 140 L1）	一般的なシークレット・鍵管理
Premium	共有HSM（FIPS 140-3 L3）	HSM保護が要件の鍵
Managed HSM	専有HSM（FIPS 140-3 L3）	単一テナント要件・高規制

StandardとPremiumは同じボールトの延長で使える一方、Managed HSMは料金体系も運用も異なる別プロダクトです。まずはStandardで始め、HSM保護が要件化された段階でPremium、単一テナントの専有や鍵管理権限の完全な分離が求められた段階でManaged HSMへ引き上げる、という段階設計が現実的でしょう。

認可モデル：Azure RBACとアクセスポリシーモデルの違いと既定化

Key Vaultの設計で最もつまずきやすいのが、誰が何にアクセスできるかを決める認可の部分です。認証はMicrosoft Entra IDが担い、その先の認可に2つのモデルが用意されています。

Microsoft Entra IDによる認証とマネージドIDでの資格情報レス接続

Key Vaultへのアクセスは、まずMicrosoft Entra ID（旧Azure Active Directory）でIDを認証するところから始まります。アプリからの接続で推奨されるのは、マネージドIDを使う方法です。仮想マシンやApp Service、Functions、AKSなどに割り当てたマネージドIDでKey Vaultにアクセスすれば、接続用の資格情報をアプリ側に一切持たずに済みます。つまり「Key Vaultにアクセスするためのパスワードをどこに保管するか」という循環問題を、マネージドIDが断ち切る形です。

IDと認証の全体像は、認証・ID管理の仕組みとMFA・SSO・IDaaSの違いを整理した記事と合わせて見ると、Entra IDがKey Vaultの入口をどう守るかが立体的に見えてきます。同じマネージドIDの考え方は、TerraformからAzureへ認証しtfstateを扱う構成でも、CIに秘密を持たせないための前提になります。

Azure RBACとレガシーなアクセスポリシーモデルの2系統

認可にはAzure RBACとアクセスポリシーの2系統があります。Azure RBACは、Azure全体で統一されたロールベースのアクセス制御で、コントロールプレーンとデータプレーンの両方に適用でき、権限を管理グループ・サブスクリプション・リソースグループ・ボールト単位で継承・一元管理できるのが利点です。もう一方のアクセスポリシーモデルは、データプレーン専用の旧来方式で、ボールトごとに「このプリンシパルにシークレットのget/listを許可」といった許可を個別に列挙します。

注意したいのは、アクセスポリシーモデルのボールトでは、コントロールプレーンの共同作成者（Contributor）ロールを持つ人が自分にアクセスポリシーを追加し、中身を読めてしまう点です。RBACガイドもこの点を明記し、Contributorの付与を厳しく絞るよう求めています。現在はセキュリティと運用の一貫性の観点からAzure RBACの利用が推奨されており、新規に構築するなら原則RBACを選ぶのが妥当な判断です。

API 2026-02-01以降は新規ボールトでRBACが既定になった変更点

RBAC既定化の移行ガイドによると、API バージョン2026-02-01以降でボールトを新規作成すると、enableRbacAuthorizationを指定しない場合の既定値がtrue（Azure RBAC）になります。既存のボールトは、明示的に値を変えない限り現在の認可モデルのまま動き、旧APIで作られて値がnullのボールトはアクセスポリシーで動き続けます。アクセスポリシーを使い続けたい新規ボールトでは、作成時にfalseを明示することが必要です。

あわせて、2026-02-01より前の管理プレーンAPIバージョンは2027年2月27日に廃止予定で、Azure CLIは2.90.0以上、Azure PowerShellは16.3.0以上へ上げるよう案内されています（2026年9月時点）。ARMテンプレートやBicep、Terraformで古いAPIバージョンを固定している場合は、認可モデルの移行とは別に棚卸しが必要です。手元のボールトがどちらのモデルかは、次のコマンドで一覧できます。

# サブスクリプション内の全ボールトの認可モデルを一覧する
# rbacEnabled が true ならAzure RBAC、false または空ならアクセスポリシー
az keyvault list \
  --query "[].{name:name, rbacEnabled:properties.enableRbacAuthorization}" \
  --output table

Key Vault管理者・シークレットユーザーなど組み込みロールの粒度

Azure RBACには、Key Vault専用の組み込みロールが用意されています。代表的なものは、データプレーンのすべてを操作できるKey Vault Administrator（管理者）、シークレットの読み書きを担うKey Vault Secrets Officer、読み取りに絞ったKey Vault Secrets User、証明書を扱うKey Vault Certificates Officer、鍵の管理を担うKey Vault Crypto Officer、暗号演算だけを行うKey Vault Crypto Userなどです。ボールトそのものを管理するKey Vault Contributorはコントロールプレーン専用で、中身にはアクセスできません。

運用では、アプリのマネージドIDには「Secrets User」のように最小権限のロールだけを割り当て、鍵の作成や削除は管理者ロールを持つ限られた担当だけが行う、という最小権限の原則で設計します。RBACガイドは「アプリごと・環境（開発・検証・本番）ごとに1ボールト」を分け、ロールはボールト単位で付与する形を推奨しており、シークレット単位の個別付与は例外扱いです。次の表に主なロールと想定付与先を整理します。

ロール	できること	想定付与先
Key Vault管理者	全データ操作	運用管理者
Secrets Officer	シークレットの読み書き	デプロイ担当・CI
Secrets User	シークレットの読み取り	アプリのマネージドID
Certificates Officer	証明書の管理	基盤担当
Crypto User	鍵による暗号演算	暗号化処理を行うアプリ
Key Vault閲覧者	メタデータの参照	監査・確認用途
Purge Operator	削除済みボールトの消去	限られた管理者

保護機能：論理削除とパージ保護・ネットワークによるアクセス制御

金庫である以上、誤削除や不正な到達からの防御が設計の要になります。Key Vaultは、削除事故に備える論理削除・パージ保護と、到達経路を絞るネットワーク制御を備えています。

既定で有効な論理削除（ソフトデリート）と7〜90日の保持期間

論理削除（ソフトデリート）は、削除したボールトやシークレット・キー・証明書を即座には消さず、一定期間は復元可能な状態で保持する仕組みです。論理削除の概要ページによると、新規ボールトでは既定で有効になり、一度有効にすると無効化できません。保持期間は7〜90日の範囲で設定でき、指定しない場合の既定値は90日です。

見落としやすいのは、保持期間を設定できるのはボールト作成時だけで、後から変更できない点です。また、論理削除中のボールト名は保持期間が終わるまで再利用できず、ボールトを復元してもRBACのロール割り当てやEvent Gridのサブスクリプションは戻らないため、再作成が必要になります。うっかり消したことがそのまま本番障害に直結しないための最初の安全網ですが、「消しても戻せるから大丈夫」と考えず、復元後の手作業まで手順書に含めておくのが安全です。

# 削除済み（論理削除中）のシークレットを確認して復元する
az keyvault secret list-deleted --vault-name "$VAULT_NAME" --output table
az keyvault secret recover --vault-name "$VAULT_NAME" --name "DbConnectionString"

# 削除済みのボールト自体を一覧・復元する
az keyvault list-deleted --resource-type vault --output table
az keyvault recover --name "$VAULT_NAME"

任意設定のパージ保護と本番環境で有効化を推奨する理由と使い分け

パージ保護は、論理削除された状態のリソースを、保持期間が満了するまで完全削除（パージ）できないよう強制する追加の防御です。論理削除と違ってパージ保護は既定では無効で、有効化するかは運用者の判断に委ねられます。有効にすると、組織内の管理者はもちろんMicrosoft側であっても、保持期間中はパージを実行できなくなり、しかも一度有効にしたパージ保護は誰も無効化できません。これは内部からの悪意ある削除や、権限を奪われた際の即時消去に対する備えです。

加えて、Azure StorageのカスタマーマネージドキーのようにKey Vaultの鍵で他サービスのデータを暗号化する構成では、多くのサービスがパージ保護の有効化を前提条件にしています。本番環境では、保持期間を長め（最大90日）に取ったうえでパージ保護を有効化する構成が堅実です。一方で、検証環境では作り直しの都合上あえて無効のままにする、といった使い分けも実務では行われます。ただし無効のまま作ったボールトを後から本番に昇格させると、同名での作り直しが保持期間中はできないため、環境ごとにボールトを分けておくことが結局は近道です。

プライベートエンドポイント・ファイアウォールによるネットワーク分離

既定のKey Vaultはパブリックなエンドポイントを持ち、認証と認可を通れば理屈上はどこからでも到達できます。到達経路そのものを絞りたい場合は、ボールトのファイアウォールで許可する仮想ネットワークやIP範囲を限定し、さらにプライベートエンドポイントを使えば、Key Vaultへの通信を自社の仮想ネットワーク内の閉じた経路に閉じ込められます。

App Serviceからネットワーク制限つきのボールトを参照する場合、アプリの送信元パブリックIPを許可リストに入れる方式は、送信元IPが変わりうるため推奨されていません。アプリ側でVNet統合を設定し、そのサブネットからの通信を受け付ける構成にします。認証・認可・ネットワークの3層で守る考え方は、クラウド全体の守り方と共通です。責任共有モデルを含む土台は、クラウドセキュリティのリスクと責任共有モデルを解説した記事で押さえておくと、Key Vaultをどこまで自社で守るべきかの線引きがはっきりします。生成AIの社内審査でKey Vaultがどこに組み込まれるかは、Azure OpenAIのセキュリティ設計で問われる遮断・認証・フィルタの設定で具体例を扱っています。

Azure CLIでKey Vaultを作成しシークレットを登録・取得する手順

ここからは手を動かす章です。Azure CLIでボールトを作り、自分にロールを付け、シークレットを登録してPythonから取り出すまでを、Microsoft LearnのPythonクイックスタートの手順に沿って、本番を意識した設定に寄せて示します。前提はAzure CLI 2.90.0以上でaz loginが済んでいることです。

RBACとパージ保護を有効にしてボールトを作成しロールを付与する

ボールト名はAzure全体で一意（英数字とハイフンの3〜24文字）にする必要があります。保持期間は作成時にしか決められないため、この時点で本番の値を指定しておきます。ロール割り当ては反映まで数分かかることがあるので、直後のシークレット登録が403で失敗したら少し待って再実行してください。

# 変数（ボールト名はAzure全体で一意にする）
RG="rg-app-prod"
LOCATION="japaneast"
VAULT_NAME="kv-myapp-prod-001"

az group create --name "$RG" --location "$LOCATION"

# RBAC・パージ保護・保持期間90日でボールトを作成する
az keyvault create \
  --name "$VAULT_NAME" \
  --resource-group "$RG" \
  --location "$LOCATION" \
  --enable-rbac-authorization true \
  --enable-purge-protection true \
  --retention-days 90

# 自分にシークレットの読み書き権限（Key Vault Secrets Officer）を付ける
VAULT_ID=$(az keyvault show --name "$VAULT_NAME" --query id -o tsv)
MY_ID=$(az ad signed-in-user show --query id -o tsv)
az role assignment create \
  --assignee-object-id "$MY_ID" \
  --assignee-principal-type User \
  --role "Key Vault Secrets Officer" \
  --scope "$VAULT_ID"

# シークレットを登録して確認する
az keyvault secret set --vault-name "$VAULT_NAME" \
  --name "DbConnectionString" \
  --value "Server=tcp:example.database.windows.net;Database=app;"
az keyvault secret show --vault-name "$VAULT_NAME" \
  --name "DbConnectionString" --query value -o tsv

スクリプトに組み込む場合は、ロール名ではなくロールID（Key Vault Secrets Officerなら b86a8fe4-44ce-4948-aee5-eccb2c155cd7）で指定しておくと、将来ロール名が変わっても壊れません。これはRBACガイドでも推奨されている書き方です。

PythonのSDKとDefaultAzureCredentialでのシークレット取得例

アプリのコードから取り出す場合は、azure-identityとazure-keyvault-secretsの2パッケージを使います。DefaultAzureCredentialは、手元ではaz loginの資格情報、Azure上ではマネージドIDを自動で選ぶため、同じコードのまま開発機と本番を行き来できます。

# インストール
# pip install azure-identity azure-keyvault-secrets

import os
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

vault_name = os.environ["KEY_VAULT_NAME"]
vault_url = f"https://{vault_name}.vault.azure.net"

credential = DefaultAzureCredential()
client = SecretClient(vault_url=vault_url, credential=credential)

# 最新版を取得する（版を固定したいときは version= を渡す）
secret = client.get_secret("DbConnectionString")
print(secret.name, secret.properties.version)
conn_str = secret.value  # 値はログに出さない

本番のアプリでは、取得した値をプロセス内でキャッシュし、リクエストごとにKey Vaultへ取りに行かない作りにします。後述するスロットリング上限に当たらないためと、Key Vaultの一時的な不調がそのままアプリ障害に波及しないためです。

App ServiceのKey Vault参照でコードを書かずに機密を注入する

App ServiceやFunctionsでは、アプリケーション設定の値に@Microsoft.KeyVault(…)形式の参照を書くだけで、実行時にKey Vaultから値が解決されます。App ServiceのKey Vault参照のドキュメントによると、書式はSecretUri=で完全なURIを指定する形と、VaultName=とSecretName=を並べる形の2通りで、アプリのマネージドIDにKey Vault Secrets Userを付与しておく必要があります。

# アプリにシステム割り当てマネージドIDを付け、読み取りロールだけを与える
APP_NAME="app-myapp-prod"
PRINCIPAL_ID=$(az webapp identity assign --name "$APP_NAME" \
  --resource-group "$RG" --query principalId -o tsv)
az role assignment create \
  --assignee-object-id "$PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope "$VAULT_ID"

# アプリ設定にKey Vault参照を書く（版を省くと最新版を使う）
az webapp config appsettings set --name "$APP_NAME" --resource-group "$RG" \
  --settings "[email protected](VaultName=kv-myapp-prod-001;SecretName=DbConnectionString)"

版を省いた参照は、ローテーションで新しい版が作られると24時間以内に自動で切り替わります。App Serviceが参照値をキャッシュし、24時間ごとに取り直す仕様のためです。すぐに反映させたい場合は、アプリ設定の変更による再起動か、公式に用意された更新用のAPIを呼びます。App Serviceそのものの価格レベルやデプロイスロットの設計は、Azure App Serviceの仕組みとデプロイスロットの実装手順で扱っており、環境ごとにボールトを分けるならKey Vault参照の設定はスロット固定の設定にしておきます。

AKSのSecrets Store CSIドライバーでPodにシークレットをマウントする

AKS（Kubernetes）では、Secrets Store CSIドライバーのAzure Key Vaultプロバイダーを使い、ボールト内のシークレットをPodのボリュームとしてマウントする方式が一般的です。AKSのCSIドライバーのドキュメントによると、アドオンazure-keyvault-secrets-providerを有効にするとノードリソースグループにマネージドIDが作られ、このIDかワークロードIDでボールトへ認証します。自動ローテーションは既定では無効で、有効にした場合のポーリング間隔の既定値は2分です（2026年9月時点）。

# 既存クラスターでアドオンを有効にする
az aks enable-addons --addons azure-keyvault-secrets-provider \
  --name "$CLUSTER_NAME" --resource-group "$RG"

# SecretProviderClass（アドオンのマネージドIDで読む例）
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kv-myapp
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"
    userAssignedIdentityID: "00001111-aaaa-2222-bbbb-3333cccc4444"
    keyvaultName: "kv-myapp-prod-001"
    tenantId: "aaaabbbb-0000-cccc-1111-dddd2222eeee"
    objects: |
      array:
        - |
          objectName: DbConnectionString
          objectType: secret

userAssignedIdentityIDにはアドオンが作ったマネージドIDのクライアントIDを入れ、そのIDにKey Vault Secrets Userを付与します。subPathでマウントしたファイルはローテーションが反映されないというKubernetes側の制約があるため、値の更新を拾わせたいアプリはファイル変更を監視するか、Podを再起動する運用を組み合わせます。

AWSの機密管理サービスとの対応関係とアプリからのシークレット取得

マルチクラウドや移行を検討するなら、AWSの機密管理サービスとの対応関係を押さえておくと設計を横展開できます。また、実装者が最も知りたいのはアプリからどう値を取り出すかでしょう。取り出し方は前章の手順で示したので、ここでは用途ごとの選び方を整理します。

AWS Secrets Manager・KMS・ACMとの対応関係を比較して整理

Key Vaultの機能は、AWSでは複数のサービスに分かれています。シークレット管理はAWS Secrets Manager、暗号鍵の管理と演算はAWS KMS、証明書の管理はAWS Certificate Managerが担い、Key Vaultはこれらをおおむね1つのサービスに束ねた位置づけです。Secrets Manager側のローテーション設定や料金はAWS Secrets Managerの料金・ローテーション設定と採用判断で、KMS側のキー種別・キーポリシー・料金体系はAWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説で整理しています。

認可の考え方も対応しており、AzureのRBACはAWSのIAMポリシーに相当します。クラウド認可の設計思想を対比したい場合は、AWS IAMの仕組みとユーザー・ロール・ポリシーの権限設計を解説した記事と読み比べると、Entra ID＋RBACとIAMの粒度の違いが見えてきます。

管理対象	Azure	AWS
シークレット	Key Vault	Secrets Manager
暗号鍵と演算	Key Vault・Managed HSM	KMS・CloudHSM
TLS証明書	Key Vault	Certificate Manager
認可	Entra ID＋Azure RBAC	IAMポリシー

Key Vault参照・CSIドライバー・SDKをアプリ／AKSで使い分ける

アプリからの取り出し方は用途で選びます。App ServiceやFunctionsでは、Key Vault参照を書くだけでコードを変えずに機密を注入できます。AKSでは、Secrets Store CSIドライバーでシークレットをPodのボリュームとしてマウントする方式が一般的です。コードから直接扱う場合や、暗号演算・証明書操作まで行う場合は、各言語のAzure SDKとマネージドIDを組み合わせれば、接続情報を持たずにシークレットを取得できます。

たとえばストレージの接続文字列を安全に渡す場面では、Azure Blob Storageの仕組みと採用判断を解説した記事で扱うストレージアカウントのキーをKey Vaultに預け、アプリはKey Vault参照で受け取る、という組み合わせが定番の設計になります。さらに踏み込むなら、ストレージ自体をマネージドIDとRBACで直接認可し、キーそのものを使わない構成に寄せるのが、漏えいする秘密を減らす方向の設計です。

Key Vaultの料金単位とスロットリング上限を設計前に確認する

Key Vaultは作るだけでは課金されにくい一方、呼び出し回数とHSM鍵の数で費用と性能の上限が決まります。設計段階で押さえておくべき数字を整理します。

操作1万件単位の従量とHSM保護キーの月額という課金の考え方

Key Vaultの料金ページでは、StandardとPremiumの操作は1万トランザクション単位の従量、HSM保護キーはキーごとの月額、証明書の更新は更新要求ごとの課金という単位で示されています。実額は通貨や契約、時期で変わるため、見積もりでは料金ページと料金計算ツールで取り直してください。論理削除中のオブジェクトは操作できないため原則として課金は発生しませんが、復元やパージの操作自体は通常の操作として数えられます。

費用で効いてくるのは、アプリがリクエストのたびにシークレットを取得する作りです。取得回数がそのまま操作件数になるため、キャッシュの有無で桁が変わります。Managed HSMは使用量でなくHSMプールの時間単位で課金される別体系なので、Premiumとの比較は月額の固定費として見積もります。

10秒あたり4,000件のスロットリング上限と429エラーへの備え

サービス上限のページによると、シークレットの取得などの操作は、ボールトかつリージョンごとに10秒あたり4,000件が上限で、シークレットの作成・証明書のインポート・鍵のインポートは合計で10秒あたり300件に絞られています。サブスクリプション全体の上限はボールト単位の5倍です。上限を超えると429（Too Many Requests）が返るため、SDKの再試行設定に任せるだけでなく、取得値のキャッシュと、起動時に大量のPodやインスタンスが一斉に取りに行かない工夫が必要です。

操作の種類	10秒あたりの上限
シークレット作成・インポート	合計300件
その他のシークレット操作	4,000件
HSMキー（RSA 2048）の演算	2,000件
HSMキー（RSA 4096）の演算	250件

ボールト内のシークレット数そのものに上限はありませんが、1つのオブジェクトに版が500を超えて溜まるとバックアップが失敗します。頻繁にローテーションする値は、古い版の扱いも含めて運用設計に入れておきましょう。

Azure Key Vaultを採用すべき場面と見送るべき場面の判断基準

ここからは判断です。Key Vaultは万能ではなく、真価を発揮する場面と、別サービスに委ねるべき場面がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。

Azure Key Vaultの採用が合理的になる実務上の条件を見極める

次のいずれかに該当するなら、Key Vaultが第一候補になります。

Azure上のシステムで、接続文字列やAPIキーをコードや構成ファイルから排除したい
マネージドIDと組み合わせ、アプリに資格情報を一切持たせずに機密へアクセスさせたい
TLS証明書の発行・更新を集中管理し、更新漏れによる失効を防ぎたい
暗号鍵を外部に出さず、署名・暗号化・復号をサービス内で完結させたい
Azure StorageやAzure SQLのデータを、自社管理の鍵（カスタマーマネージドキー）で暗号化したい

いずれもクラウド上で機密を扱う際の定番要件で、マネージドIDとの組み合わせが効くほど運用負荷が下がります。特に、鍵や証明書のローテーションを人手の運用から自動化へ寄せられる点が、長期的な事故防止につながります。

Azure Key Vaultを選ぶべきでない場面と適切な代替サービス

一方で、次の要件にはKey Vaultをそのまま当てはめません。第一に、鍵を扱うHSMの単一テナント専有や、サブスクリプション管理者からも切り離した鍵管理権限が要件化されているなら、共有型のPremiumではなく別プロダクトのManaged HSMを選びます。第二に、AWSやGoogle Cloud中心の構成なら、Secrets ManagerやSecret Managerなど各クラウドの機密サービスに寄せた方が、認可とネットワークの一貫性を保ちやすいでしょう。

第三に、Key Vaultはシークレットの保管には向く一方、アプリの一般設定値（機密でないフラグやパラメーター）まで全部入れる置き場ではなく、そちらはApp ConfigurationやKubernetesのConfigMapが適します。第四に、1秒間に大量のシークレット取得を繰り返す設計はスロットリング（要求制限）に当たりやすいため、取得結果をアプリ側で適切にキャッシュすることが前提です。第五に、有効期限の短い資格情報を都度発行する「動的シークレット」が欲しい場合は、Key Vaultの守備範囲の外で、HashiCorp Vaultのような仕組みが候補になります。

受託開発におけるシークレット管理の設計の勘所と外注先への相談

実際のシステムでは、Key Vault単体ではなく、マネージドID・RBAC・ネットワーク制御・アプリ側のキャッシュ戦略を一体で設計する必要があります。どの機密をどのボールトに置き、どのIDにどのロールを与え、どの経路からアクセスさせるかは、可用性・監査要件・運用体制のトレードオフで決まり、後からの権限再設計にはアプリ改修も必要です。とくに2026-02-01以降のAPIへの移行や、アクセスポリシーからRBACへの切り替えは、ロール割り当ての漏れがそのまま停止につながるため、切り替え前の棚卸しを必ず工程に組み込みます。

要件定義の段階でシークレット管理の方針まで固めておくほど、開発後半の作り直しを避けられます。Azureを含むクラウドインフラの構築・移行の相談では、Key Vaultを含む認証・認可・機密管理の設計から実装・運用までを一貫して支援できます。

よくある質問

Azure Key Vaultの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

Azure Key VaultとManaged HSMはどう違いますか？

Key Vault（Standard/Premium）は、多くのシステムで使う汎用的な機密管理サービスで、Premiumでも背後のHSMは複数テナントで共有されます。Managed HSMは、単一テナント専有のHSMクラスターを提供する別プロダクトで、HSM単位のローカルRBACによりサブスクリプション管理者からも鍵の管理権限を切り離せます。2026年9月時点ではPremiumもManaged HSMもFIPS 140-3レベル3検証のHSMを使っているため、選び分けの軸は検証レベルではなく専有性と権限分離です。

RBACとアクセスポリシーはどちらを使うべきですか？

新規構築では原則Azure RBACを選びます。RBACはAzure全体で統一された認可モデルで、権限の継承や一元管理ができ、API 2026-02-01以降は新規ボールトの既定にもなりました。アクセスポリシーはデータプレーン専用の旧来方式で、引き続きサポートはされますが、共同作成者ロールの人が自分に権限を足せてしまう点など管理上の弱さがあります。既存ボールトをRBACへ移す場合は、先に同等のロールを割り当ててから切り替えないと、アプリが読めなくなり障害になります。

削除したシークレットは元に戻せますか？

元に戻すことは可能です。論理削除（ソフトデリート）が既定で有効なため、削除したシークレットやボールトは保持期間（7〜90日・既定90日）の間はaz keyvault secret recoverなどで復元できます。さらにパージ保護を有効にしておくと、保持期間が満了するまで完全削除そのものを禁止でき、内部からの不正な即時消去にも備えられます。なお保持期間は作成時にしか設定できず、パージ保護は一度有効にすると無効化できません。

アプリからKey Vaultにアクセスするパスワードはどこに置きますか？

置きません。仮想マシンやApp Service、AKSに割り当てたマネージドIDでEntra ID認証を行えば、Key Vaultへの接続用資格情報をアプリに持たせずにアクセスできます。コードではDefaultAzureCredentialを使えば、開発機ではaz loginの資格情報、本番ではマネージドIDが自動で選ばれます。「機密を守る金庫を開けるための機密」を持たずに済むのがマネージドIDの利点で、これがKey Vault利用時の推奨構成です。

AWSのSecrets ManagerやKMSとは何が違いますか？

役割は対応しますが、Key Vaultはシークレット・キー・証明書を1サービスに束ねる点が異なります。AWSではシークレットがSecrets Manager、鍵がKMS、証明書がCertificate Managerと分かれます。認可もAzureのRBACがAWSのIAMに相当する形で対応するため、設計思想は横展開できますが、APIやエンドポイント、課金単位は別物です。シークレットの自動ローテーション機能はSecrets Managerの方が組み込みの範囲が広く、Key Vaultでは通知と関数を組み合わせて実装する場面が多くなります。