こんにちは、Hitomiです。
Azure サブスクリプションを運用していると、「サブスクリプションの Owner はいるのに、支払い方法や請求所有権の操作ができない」という場面があります。
リソースを作れる。リソースを消せる。Azure RBAC の Owner も複数人いる。だから大丈夫だと思っていたら、請求まわりの所有者が退職済みのユーザーのままで、支払い方法変更や請求所有権の移譲で詰まる。これは、Azure の権限管理を「リソース管理」だけで見ていると見落としやすい問題です。
結論から言うと、Azure RBAC の Owner と、請求管理側の所有者は別物です。サブスクリプション作成者のアカウントを退職者対応で削除する前に、Azure RBAC だけでなく、請求アカウント、請求プロファイル、請求書セクション、Account Administrator も棚卸しする必要があります。
Owner がいるのに支払い方法を変えられない
たとえば、ある Azure サブスクリプションでクレジットカードや請求先を変更したいとします。Azure Portal 上ではサブスクリプションの Owner が残っていて、リソース管理はできる。ところが Cost Management + Billing に入ると、請求まわりの操作ができない。
このとき起きているのは、リソース権限の不足ではなく、請求管理権限の不足かもしれません。
Azure のサブスクリプションには、少なくとも次の2つの観点があります。
| 観点 | 主に扱うもの | 代表的なロール |
|---|---|---|
| リソース管理 | VM、Storage、Network、Key Vault などの Azure リソース | Azure RBAC の Owner / Contributor / Reader |
| 請求管理 | 請求書、支払い方法、請求所有権、請求プロファイル、請求書セクション | Account Administrator、Billing account owner、Billing profile owner、Invoice section owner など |
名前に「Owner」が入っているので紛らわしいのですが、Azure RBAC の Owner は、あくまで Azure リソースへのアクセスを管理するためのロールです。Microsoft Learn の Add or change Azure subscription administrators でも、subscription scope に Owner を割り当てる話と、billing administrator の話は分けて説明されています。
つまり、リソースを操作できることは、支払い方法を変更できることの十分条件ではありません。
Azure RBAC の Owner と請求所有者は別物
ここでいう「請求所有者」は、契約種別によって名前が変わります。
Microsoft Online Services Program、いわゆる pay-as-you-go の MOSP（Azure Portal の billing account type 表示では Microsoft Online Subscription Program）では、Manage access to billing information for Azure にあるように、Account Administrator が請求アカウント側の重要な管理者として扱われます。MOSP サブスクリプションを作成したユーザーは、Account Administrator と Azure RBAC Owner の両方を得ます。
ここが落とし穴です。作成時には同じ人が両方の権限を持つため、後から見ると「Owner と請求管理者は同じようなもの」に見えます。しかし、実際には権限のレイヤーが違います。
Microsoft Customer Agreement、つまり MCA や Azure Plan の文脈では、Understand Microsoft Customer Agreement administrative roles in Azure にあるように、billing account、billing profile、invoice section という単位で role が分かれます。たとえば Billing profile owner / contributor は支払い方法の管理に関わり、Invoice section owner / contributor はサブスクリプション作成や invoice section の変更、請求所有権リクエストに関わります。
この違いを雑にまとめると、次のようになります。
| 契約・課金モデル | 見るべき主な場所 | 注意点 |
|---|---|---|
| MOSP / pay-as-you-go | Account Administrator、Billing properties | 作成者が Account Administrator と Azure RBAC Owner の両方を持ちやすい |
| Microsoft Customer Agreement / Azure Plan | Billing account、Billing profile、Invoice section の IAM | Account Administrator という表示ではなく、MCA の billing roles を確認する |
| Enterprise Agreement / Microsoft Partner Agreement | EA / MPA 側の管理者、パートナー管理 | 本稿では詳細手順まで扱わない。契約管理者やサポートへの確認が必要 |
重要なのは、契約種別によって UI やロール名が変わることです。「Account Administrator が誰か」だけを探しても、MCA ではその表示が見えないことがあります。その場合は、Cost Management + Billing で billing account type を確認し、MCA の billing roles を見に行く必要があります。なお、同じ Azure Plan でも、CSP（クラウドソリューションプロバイダー）経由で契約している場合は、請求管理がパートナーの Microsoft Partner Agreement 側に寄ります。このときは自社の billing IAM だけでは完結せず、パートナーへの確認が必要になります。
作成者のアカウントが消えると何が困るか
問題が顕在化しやすいのは、サブスクリプション作成者が退職し、Entra ID 上のユーザー ID が削除された後です。
Microsoft Learn の Transfer Azure product billing ownership to a Microsoft Customer Agreement には、元の billing account owner が組織を離れ、その user identity が組織の Microsoft Entra ID からなくなると、Azure subscription に有効な billing owner がいない状態になり得る、と説明されています。その状態では、請求書の表示や支払いを含む billing operations ができなくなり、未払い、サブスクリプションの無効化、最終的な削除につながる可能性があります。
これは怖い話ですが、脅しではなく、管理対象を取り違えると起きる運用リスクです。
ただし、必ず即詰みになるわけではありません。同じ Microsoft Learn の説明では、有効な billing account owner がいなくなったサブスクリプションについて、Azure が他の billing account owner や subscription owner にメールを送り、請求所有権を引き取るためのリンクを案内する、Azure Portal の該当サブスクリプションにバナーを表示する、ともあります。つまり、他に有効な billing account owner や subscription owner が残っていれば、その人がリンクから billing ownership を引き取れる場合があります。裏を返せば、その受け皿が誰も残っていなければ、この導線も使えません。だからこそ、請求側の所有者を最後の1人に依存させないことが効いてきます。
Azure RBAC の Owner が残っていれば、VM の停止やリソースグループの操作はできるかもしれません。しかし、請求所有者が無効なユーザーのままなら、次のような操作で詰まる可能性があります。
| 操作 | Azure RBAC Owner だけで足りるか | 詰まりやすい理由 |
|---|---|---|
| リソースの作成・削除 | 多くの場合は可能 | リソース管理の権限だから |
| 請求書の確認 | 契約種別や設定に依存 | Billing Reader や請求ロールが必要になる場合がある |
| 支払い方法の変更 | 足りないことがある | Billing profile や Account Administrator 側の権限が必要になる |
| 請求所有権の移譲 | 足りないことがある | 移譲元・移譲先の billing role が必要になる |
| 支払い不能時の整理 | 足りないことがある | 契約、請求、サポートの確認が絡む |
「Owner なのにできない」は、Azure が壊れているというより、見ている権限の面が違うと考えた方が整理しやすいです。
実務で詰まりやすいポイント
実務でよく困るのは、支払い方法を変えたいだけなのに、話が請求所有権の問題になっていくところです。
たとえば、Account Administrator が退職済みユーザーのまま残っている。Azure Portal の通常画面から新しい担当者へ変更できない。支払い方法を更新したいだけなのに、請求所有権の移譲、billing profile の権限、invoice section の権限を確認する必要がある。
MOSP の請求所有権移譲について、Microsoft Learn の Transfer billing ownership of an MOSP Azure subscription to another account では、subscription を持つ account の Account Administrator が移譲できると説明されています。一方で、すべての subscription type が移譲に対応しているわけではなく、transfer option が利用できない場合もあります。Azure Plan subscription の移譲では、invoice section owner / contributor の権限が必要になる場合もあります。
ここから分かるのは、「サポートに問い合わせれば必ず一発で直る」と考えない方がよい、ということです。もちろん、詰まったときは Microsoft サポートへの問い合わせが必要になる場合があります。ただし、サポート側が契約や支払いの責任分界を飛び越えて何でも直す、というより、新しい課金先、移譲先の請求権限、支払い方法、対象サブスクリプションの契約種別を確認しながら進めることになります。
復旧は、事前に整えていた権限と連絡先の品質に左右されます。ここがこの記事で一番言いたいところです。
復旧時にまず確認すること
すでに詰まっている場合、いきなり「誰に Owner を付けるか」から入るより、次の順に確認した方が整理しやすいです。
1つ目は、billing account type です。Cost Management + Billing の Billing scopes や Properties で、Microsoft Online Subscription Program、Microsoft Customer Agreement、Enterprise Agreement、Microsoft Partner Agreement のどれに近いのかを確認します。
2つ目は、サブスクリプションの Billing properties です。MOSP の場合は Account Admin が表示されることがあります。表示されない場合は、MCA の billing roles を見る必要があるかもしれません。
3つ目は、Billing account、Billing profile、Invoice section の IAM です。MCA では、どの scope に誰が owner / contributor として付いているかを見ます。支払い方法変更なら billing profile、サブスクリプションの invoice section 変更や請求所有権リクエストなら invoice section も関係します。
4つ目は、退職者アカウントの状態です。ユーザーが無効化されているだけなのか、削除済みなのか、復元可能なのかで選択肢が変わります。ただし、この記事では個別の復旧手順は断定しません。実環境では、組織の Entra ID 運用、保持期間、サポート判断が絡むためです。
5つ目は、移譲先の準備です。請求所有権を移す場合、移譲先が有効な有償アカウントや支払い方法を持っている必要があります。MCA へ移すなら、移譲リクエストを作れる billing role が必要です。
この確認をすると、「Azure RBAC の Owner を増やせば解決する問題」なのか、「請求所有権を移す問題」なのか、「契約管理者や Microsoft サポートに確認すべき問題」なのかを分けやすくなります。
実際に対応したこと（退職者発生時の対応例）
実際に、退職者対応で請求まわりが詰まったサブスクリプションを扱ったことがあります。ここでは、そのとき自分が何を確認し、どう動いたかを順を追って残しておきます。
このときの契約形態は、サポートから Microsoft Partner Network (MPN) プランという呼称で案内されました。最初に分かったのは、MPN プランの仕組み上、アカウント管理者の変更や支払い方法の変更を Microsoft サポート側で直接やってもらうことはできない、という制約です。つまり「サポートに頼めば管理者を付け替えてもらえる」のではなく、こちら側で新しい支払い情報の受け皿を用意したうえで、サポートに請求情報を紐づけ直してもらう、という前提に立つ必要がありました。
最初に引っかかったのが、なぜダミーのサブスクリプションをわざわざ作るのか、という点でした。サポートとのやり取りの中で確認したところ、理由は、従量課金の支払いデータ、つまりクレジットカードなどの支払い方法を新しく登録するための受け皿が必要だからでした。
退職者が作成した既存のサブスクリプションには、もう有効な支払い方法や請求管理者を素直に紐づけられません。そこで、新しいアカウントで支払い方法を登録できる従量課金制のサブスクリプションを別に作り、その課金情報を既存のサブスクリプションへ引き継ぐ、という方針を立てました。
具体的に動いたのは、次の順序です。
- Microsoft サポートにチケットを起票した。
まず現状（Owner はいるが請求側の操作ができない、作成者は退職済み）と契約が MPN であることを伝え、対応方針をすり合わせました。ここで前述の「サポートでは直接変更できない／ダミー経由で紐づけ直す」という流れを確認しています。 - ダミーの Azure 従量課金制サブスクリプションを作成した。
支払い方法を新しく登録するための受け皿として、Azure のアカウント作成ページ から新規に作成しました。作成後、サブスクリプション ID をサポート窓口へ連絡しています。 - 譲渡先に請求書セクションの所有者権限を付与した。
譲渡作業を円滑に進めるため、先に IAM 側を整えました。請求先アカウントの所有者かつグローバル管理者の権限を持つアカウントで Azure Portal にサインインし、Cost Management + Billing から該当の課金スコープ、課金プロファイル、請求セクションとたどり、アクセス制御 (IAM) の「追加」で譲渡先に請求書セクションの所有者権限を付けています。 - 同意文を提出した。
サポート窓口での代理譲渡にあたって、アクティブなグローバル管理者からの本人確認のための同意文の提出を求められました（要否はサポート側で確認）。ここで一つ確認になったのが後述のグローバル管理者権限の持ち方です。 - サポート側で課金情報を既存サブスクリプションへ紐づけてもらった。
ダミー側に登録した課金情報を、操作できなくなっていた既存のサブスクリプションへ紐づけ、プラン変更と譲渡をサポート窓口に代理対応してもらいました。 - 役目を終えたダミーのサブスクリプションを削除した。
既存サブスクリプションへの請求情報の紐づけが完了したことを確認したうえで、受け皿として作ったダミーは削除しています。
この件のはまりどころ
はまり①：同意文＝アクティブなグローバル管理者が必要
まず最初に引っかかったのがグローバル管理者権限の「持ち方」でした。同意文の提出にあたって、PIM で昇格可能なグローバル管理者権限だけでは要件を満たさず、アクティブなグローバル管理者である必要がありました。Microsoft Learn の Privileged Identity Management で Microsoft Entra ロールを割り当てる を見ると、ロールの割り当てには「対象（有資格）」と「アクティブ」の二種類があり、有資格の割り当てはロールを使うたびにアクティブ化の操作が必要になると説明されています。
今回のように譲渡や代理作業の同意が絡む手続きでは、必要なときだけ昇格する有資格の状態ではなく、常にロールを保持しているアクティブな割り当てが求められる、という整理になります。実際、この点を取り違えると、同意文の段階で作業が止まってしまいます。
はまり②：IAMの付与を先回りしすぎると譲渡NGになることがある
また、先回りでやってしまうと逆効果になる落とし穴がありました。
良かれと思って、Microsoft の手続き前に、作成者以外のアカウントへ請求書セクションの所有者権限を付けてしまうと、譲渡が NG になり、サブスクリプションを作り直すことになります。IAM を整えるのは譲渡作業を円滑にするためですが、付与のタイミングを誤ると、かえって譲渡の前提を崩してしまう、ということです。実際、権限付与は手順の中で行うものの、窓口とのすり合わせの順序を外さないことが大事でした。
はまり③：作り方によっては技術的に譲渡対象にできない
そもそも「作成したサブスクリプションに対して技術的に譲渡できない」ケースがあった点です。私は最初、Azure テナントからそのまま新しいサブスクリプションを作成すればよいと考えていました。ところが、作り方によっては譲渡対象にできませんでした。
サポートからの回答として案内されたのは、次の整理です。Azure サブスクリプションの譲渡は、Azure 課金アカウント間での移行を前提とした仕組みになっている。一方で、作成したサブスクリプションが Microsoft 365 の課金アカウントに紐づいていると、その配下のサブスクリプションは Azure 課金アカウントへ譲渡できない。結果として、そのサブスクリプションはそのまま譲渡対象にできず、作り直しになりました。
予防策は作成時と退職者対応に入れる
この問題は、起きてから頑張るより、サブスクリプション作成時と退職者対応時に潰しておく方がずっと楽です。
まず、サービス用途のサブスクリプションを個人任せで作らないことです。個人ユーザーが作成すること自体が常に悪いわけではありません。ただ、作成したあとも請求所有者、支払い方法、請求書送付先、連絡先が個人に閉じたままになると、退職や異動のときに運用リスクになります。
次に、請求管理ロールを複数名または適切な管理主体で持つことです。MCA では billing account / billing profile / invoice section の scope ごとに、必要な owner / contributor / reader を整理します。強すぎる権限を広く配る必要はありませんが、最後の1人に依存しない状態を作るべきです。
退職者対応では、Entra ID のユーザー削除や Azure RBAC の棚卸しだけで終わらせないことが重要です。サブスクリプション、Cost Management + Billing、billing profiles、invoice sections、支払い方法、請求書送付先、サポート連絡先まで確認します。
新規サブスクリプション作成手順にも、次の項目を入れておくとよいです。
| タイミング | 確認すること | 理由 |
|---|---|---|
| 作成前 | 誰の契約・請求単位で作るか | 後から請求所有権を移すより、最初に正しい billing scope で作る方が安全 |
| 作成直後 | Azure RBAC Owner と billing role の両方を確認する | リソース管理と請求管理を混同しないため |
| 運用開始前 | 支払い方法、請求書送付先、請求連絡先を確認する | 未払い・期限切れ・連絡不能を防ぐため |
| 退職者対応 | Azure RBAC、billing roles、support contact を棚卸しする | アカウント削除後の請求所有者不在を防ぐため |
| 定期点検 | 少なくとも四半期ごとに owner と請求先を確認する | 組織変更やカード期限切れに気づくため |
ここで大事なのは、完璧な手順書を作ることではありません。誰が、どのサブスクリプションを、どの billing scope で、どの支払い方法に紐づけて運用しているのかを、説明できる状態にすることです。
退職者対応チェックリスト
退職者対応に Azure を含めるなら、私は少なくとも次を確認します。
- 退職者が Azure RBAC Owner / Contributor / Reader を持っている subscription、resource group、management group はないか。
- 退職者が Account Administrator として表示される MOSP subscription はないか。
- 退職者が MCA の billing account、billing profile、invoice section の owner / contributor / reader になっていないか。
- 退職者が subscription creator として作成した subscription の請求先は、現在も有効な管理主体に紐づいているか。
- 支払い方法、請求書送付先、請求通知先が退職者の個人アドレスや個人カードに依存していないか。
- サポートリクエストを出せるユーザー、契約管理者、経理側の連絡先が残っているか。
- サービスプリンシパル、managed identity、secret、証明書、Automation account など、退職者が作成した運用資産の所有者が引き継がれているか。
このチェックリストは、Azure に限らずクラウドや SaaS の管理プレーン全般に効きます。退職者対応は「ログインできないようにする」だけでは足りません。契約、支払い、請求、サポート、監査ログ、運用自動化まで含めて、業務が継続できる状態にする必要があります。
この話は管理プレーンの権限管理である
Azure の請求所有者不在問題は、経理だけの話でも、Azure Portal の操作だけの話でもありません。クラウドを業務基盤として使うなら、管理プレーンの権限管理です。
誰がリソースを作れるのか。誰が支払い方法を変えられるのか。誰が請求書を見られるのか。誰が所有権を移譲できるのか。誰がサポートへ問い合わせられるのか。
これらは全部、サービス継続に関わる権限です。
リソース Owner の棚卸しは、もちろん必要です。ただ、それだけでは「Azure を動かし続ける責任」を説明できません。サブスクリプションをサービス用途で使うなら、作成者個人の善意や在籍状況に依存しないように、請求所有者と管理主体を組織の運用に乗せるべきです。
FAQ
Azure RBAC の Owner がいれば支払い方法を変更できますか
常にできるとは限りません。Azure RBAC の Owner はリソース管理のロールです。支払い方法変更には、MOSP の Account Administrator や、MCA の billing profile owner / contributor、billing account owner / contributor など、請求側の権限が必要になる場合があります。
また、契約形態やサポート手続きによっては、本人確認や同意文の提出などで Microsoft Entra の（アクティブな）グローバル管理者の対応が必要になる場合があります。
Account Administrator と Billing owner は同じですか
同じものとして扱わない方が安全です。MOSP では Account Administrator が重要な請求管理者として出てきます。一方、MCA では billing account、billing profile、invoice section の owner / contributor / reader といったロールで考えます。契約種別によって名称と操作場所が変わります。
退職者アカウントを削除した後でも復旧できますか
可能性はありますが、断定はできません。契約種別、移譲先の権限、支払い方法、アカウント状態、Microsoft サポートの判断に依存します。少なくとも、退職者アカウントを削除する前に請求ロールを棚卸ししておく方が安全です。
サービス用途のサブスクリプションを個人が作ってはいけませんか
個人が作成すること自体を一律に禁止する話ではありません。問題は、作成後も請求所有者、支払い方法、請求連絡先、管理者権限が個人に閉じたままになることです。サービス用途に使うなら、作成後すぐに組織の管理手順へ乗せる必要があります。
まとめ
Azure サブスクリプションの運用で、「Owner がいるから大丈夫」と考えるのは危険です。
Azure RBAC の Owner は、リソースを管理するための権限です。請求所有者、支払い方法、請求書、請求所有権移譲は、契約種別に応じた請求管理ロールで扱われます。MOSP なら Account Administrator、MCA なら billing account / billing profile / invoice section の role を見る必要があります。
退職者対応では、ユーザーを無効化・削除する前に、Azure RBAC だけでなく請求管理ロールも棚卸ししてください。サブスクリプション作成時には、請求所有者、支払い方法、請求書送付先、サポート連絡先を、個人ではなく組織の運用として管理してください。
クラウドは簡単に作れるからこそ、作った後の所有者設計が重要です。個人のアカウントで始まったサブスクリプションを、いつまでも個人の責任に閉じ込めない。これが、Azure をサービス基盤として安全に使い続けるための現実的な予防策だと思います。
