Azureを触り始めたときに混乱しやすいのが「テナント（Microsoft Entra ID / 旧Azure AD）」と「サブスクリプション」の関係です。どちらも“入れ物”に見えますが役割は別物で、ここを誤解すると課金・権限・運用設計が遠回りになります。この記事では、テナントとサブスクリプションの違い、1:1/1:Nの紐付けルール、本番と開発を別テナントにする場合の最小構成、そしてサブスクリプション作成上限で詰まったときの現実的な切り分け手順をまとめます。
まず結論：テナントとサブスクリプションは同じではない
最初に、混乱しやすいポイントを“結論”として押さえます。
- テナント（ディレクトリ）は、サブスクリプション無しでも存在できます。Azureリソースを作らない（ID基盤だけ使う）なら、テナントだけでも成立します。
- サブスクリプションが信頼できるテナント（ディレクトリ）は同時に1つだけです。「1つのサブスクリプションを複数テナントにまとめて紐付け」はできません。
- 1つのテナントに複数サブスクリプション（1:N）は可能です。本番用・開発用・検証用をサブスクリプションで分ける運用は定番です。
- Cost/Billingで見える範囲は、スコープ（どこを見ているか）と、選択中テナント（ディレクトリ）に依存します。別テナントのサブスクリプションを扱うには、基本的にディレクトリ切り替えや委任管理が必要です。
用語を整理：テナント／ディレクトリ／サブスクリプション／課金アカウント
Azureの画面や資料では、似た言葉が混ざって登場します。ここを一度整理すると、以降の判断が一気に楽になります。
| 用語 | ひとことで | 主な役割 | 代表的に“ここで決まる”もの | よくある誤解 |
|---|---|---|---|---|
| テナント（Microsoft Entra ID テナント） | ID/認証の入れ物 | ユーザー、グループ、アプリ登録、SSO、条件付きアクセスなど | サインイン、IDガバナンス、ゲスト招待、監査ログ | 「テナント＝課金先」だと思ってしまう |
| ディレクトリ | ポータル上の“今見ているテナント” | Azure portalの表示・操作の対象テナントを切り替える概念 | サブスクリプション一覧に何が出るか、権限付与の対象 | 「ディレクトリ切替＝別アカウントでログイン」と混同する |
| サブスクリプション | リソース/課金の入れ物 | Azureリソースを作る単位、請求や予算（Budget）やクォータの境界 | 請求、リソース作成、クォータ、RBAC、ポリシー適用単位 | 「サブスクリプション＝契約書そのもの」だと思ってしまう |
| 課金アカウント（契約/オファー） | 請求をまとめる箱 | 支払い方法、請求書、請求先情報、契約形態（MCA/EA/CSP等） | 請求書、課金プロファイル、支払い方法、サブスクリプション作成権限 | 「サブスクリプションが作れない＝テナントの問題」と決めつける |
ポイントは、テナント（ID）とサブスクリプション（リソース/課金）は責務が違うということです。テナントは“人・アプリ・認証”を扱い、サブスクリプションは“Azureのモノ・お金・上限”を扱います。
テナント数＝サブスクリプション数？という誤解が起きる理由
Azure portalで操作していると、サブスクリプションが見えないときに「このテナントにはサブスクリプションが無い＝テナントが間違い？」となりがちです。よくある原因は次の2つです。
- そもそもそのテナントにサブスクリプションが紐付いていない（別テナントにある）
- 紐付いてはいるが、自分のアカウントに閲覧権限が無い（RBAC、課金ロール、ゲスト招待の設定など）
見えない＝存在しない、ではありません。まずは「どのディレクトリを見ているか」「そのディレクトリ内でどの権限を持つか」を切り分けるのが近道です。
サブスクリプションとテナントの紐付けルールを図で理解する
関係性の核心は、次の2つだけです。
- サブスクリプション → テナント：同時に1つだけ
- テナント → サブスクリプション：複数持てる
| 関係 | 可否 | 具体例 | 運用上の意味 |
|---|---|---|---|
| 1テナントに1サブスクリプション | 可能 | 小規模な検証環境 | 単純で分かりやすいが、権限・課金・制限が全部同居する |
| 1テナントに複数サブスクリプション（1:N） | 可能 | 同一テナント内で本番/開発を分ける | IDは共通のまま、課金・権限境界・クォータを分けられる |
| 1サブスクリプションを複数テナントへ同時に紐付け（N:1） | 不可 | 「複数テナントを1つの契約でまとめたい」 | 同時紐付けはできない。必要なら運用/課金の整理を別軸で考える |
さらに実務で重要なのが、“紐付けは変えられるが、同時に複数にはできない”という点です。サブスクリプションのディレクトリ（テナント）を変更できるケースもありますが、変更後は新しいテナントに属するものとして扱われ、元のテナントから同時に見える状態にはなりません。
「複数テナントを1つのサブスクリプションにまとめたい」への現実解
「組織や顧客ごとにテナントを分けたい。でも課金や契約はまとめたい」という相談はよくあります。ただし“サブスクリプションの同時紐付け”はできないため、目的を分解して別の解決策を選ぶ必要があります。
| やりたいこと | よくある誤った発想 | 現実的な解決策 | 注意点 |
|---|---|---|---|
| 複数テナントの運用を一元化したい | 1サブスクリプションに全部紐付ける | ゲスト（B2B）や委任管理（Azure Lighthouse等）で運用者の入口を一本化 | 管理対象が増えるほど、監査・権限設計・招待運用が重要 |
| コストをまとめて可視化したい | Cost/Billingで全テナントが自動的に見えるはず | タグ/命名規則＋予算（Budget）＋（可能なら）契約スコープで集計 | 契約形態や権限ロールで見え方が変わる |
| セキュリティ境界を強くしたい | サブスクリプションだけ分ければ十分 | 境界要件により「別テナント」を選ぶ（ID基盤ごと分離） | 運用負荷が上がるため、境界要件を明確にする |
ここでのコツは、「まとめたいのは何か（運用？課金？ID？）」を最初に決めることです。テナント分離は“ID基盤の分離”という強い手段なので、目的がコスト可視化や環境分離（本番/開発）程度なら、まずは同一テナント内での分割から検討すると失敗しにくいです。
Cost/Billingで「別テナントのサブスクリプションが見えない」問題の整理
Azure portalの「Cost Management + Billing」や「サブスクリプション一覧」で、別テナントのサブスクリプションが見えないのは珍しくありません。多くの場合、原因は“表示スコープ”と“選択中ディレクトリ”の不一致です。
まず確認するチェックポイント
- Azure portal右上のアカウントメニューで、どのディレクトリ（テナント）を選択中か
- 「ディレクトリ + サブスクリプション」のフィルターで、対象のサブスクリプションが選択可能か
- 自分のアカウントがそのサブスクリプションで閲覧以上のRBAC権限を持つか（少なくともReader）
- コストを見たい場合、サブスクリプション権限だけでなく課金ロール（Billing系ロール）が必要な契約形態もある
「全部を一画面で見たい」場合の考え方
“全テナントのサブスクリプションを常に一画面で”は、契約形態と権限設計次第で難易度が変わります。運用設計としては、次の順で検討すると現実的です。
- 短期：ディレクトリ切り替えで確認できる状態を作る（まず見える化）
- 中期：タグ設計（例：Env=Prod/Dev、System=xxx、Owner=yyy）でサブスクリプションを横断集計しやすくする
- 長期：委任管理（例：Azure Lighthouse）や運用基盤で、複数テナントの運用者体験を揃える
コスト集計を本気でやるなら、テナントやサブスクリプションの分け方以上に、タグ・命名規則・予算（Budget）・アラートの整備が効いてきます。逆にここが無いと、どんな構成でも「結局どれが何の費用？」になりやすいです。
すぐ使える：テナントID／サブスクリプションIDの確認とディレクトリ切り替え
サポート問い合わせや権限付与の議論では、名前（表示名）よりもIDが確実です。特に「どのテナントの話か」「どのサブスクリプションの話か」が食い違うと、議論が前に進みません。ここでは、現場でよく使う“確認の型”をまとめます。
Azure portalで確認する
| 確認したいもの | ポータル上の場所（例） | メモしておくと役立つ場面 |
|---|---|---|
| サブスクリプションID | 「サブスクリプション」→ 対象サブスクリプション → 「概要」 | RBAC付与、サポート起票、ARMテンプレ/スクリプト |
| テナントID（ディレクトリID） | 「Microsoft Entra ID」→ 「概要」 | ゲスト招待、アプリ登録、条件付きアクセス、サポート起票 |
| 今どのディレクトリを見ているか | 右上のアカウントメニュー → 「ディレクトリの切り替え」 | サブスクリプションが見えない/見えるの差分確認 |
CLIで確認する（画面に出ないときに強い）
ポータルの表示が混乱しているときは、Azure CLIで“事実”を拾うと早いです。以下は代表例です。
# ログイン（必要に応じて）
az login
# 自分が見えているサブスクリプション一覧（tenantIdも表示される）
az account list --output table
# 現在選択中のサブスクリプション情報（subscriptionId / tenantId）
az account show --output json
# 操作対象サブスクリプションを切り替え
az account set --subscription ポイントは、subscriptionIdとtenantIdの組が一致しているかです。ここがズレていると、ポータルで「見えない」「別テナントに誘導される」などの現象が起きやすくなります。
本番（Tenant1）と開発（Tenant2）を別テナントにしたい：最小で必要なサブスクリプション数
本番をTenant1、開発をTenant2のようにテナントを分けてAzureリソースを作るなら、原則として各テナントに最低1つずつサブスクリプションが必要です。理由は単純で、サブスクリプションは同時に1つのテナントにしか所属できないからです。
| 構成 | テナント数 | 必要サブスクリプション数（最小） | 向いているケース |
|---|---|---|---|
| 本番/開発を同一テナントで分ける | 1 | 2（本番用＋開発用） | ID基盤は共通で良い、運用を簡素にしたい |
| 本番/開発を別テナントで分ける | 2 | 2（Tenant1用＋Tenant2用） | ID境界を分けたい、管理者やポリシーを分離したい |
ここでの落とし穴は、テナントを増やすと「管理するID基盤が増える」ことです。ゲスト招待、管理者アカウント、MFA/条件付きアクセス、監査ログ、アプリ登録の棚卸しなどが、テナント数に比例して増えます。本番/開発を分けたいだけなら、まずは同一テナント内でサブスクリプション分割＋厳格なRBACで目的を達成できないか検討するのが堅実です。
テナント分離が“必要”になりやすい判断基準
「なんとなく安全そうだから」でテナントを分けると運用が重くなりがちです。逆に、次の要件があるなら別テナントの価値が出ます。
| 要件/背景 | 同一テナント内の分離で足りる？ | 別テナントが向く？ | 理由 |
|---|---|---|---|
| 別会社・別組織として完全にID運用を分けたい | 難しい | 向く | 管理者、監査、招待、ポリシーを独立できる |
| 外部顧客向けのID基盤（B2C/B2B）を明確に分けたい | ケースによる | 向く | 社内IDと顧客IDの境界を明確にできる |
| 本番/開発で課金を分けたい、権限を分けたい | 足りることが多い | 必須ではない | サブスクリプション分割＋RBAC＋ポリシーで実現しやすい |
| 事故時の影響範囲を“IDレベル”で分離したい | 難しい | 向く | テナント分離は認証基盤ごと分けるため影響範囲を限定しやすい |
同一テナントで本番/開発を分ける実務的な設計例
「分けたい理由」が環境差（本番/開発）であれば、次のような設計が現場で扱いやすいです。
- サブスクリプションを分ける：Prod-Sub / Dev-Sub
- 管理グループを使う：Prod配下とDev配下でポリシーと権限を階層化（管理グループは同一テナント内で有効）
- RBACを“役割ごと”に固定化：開発者はDevのみContributor、本番はReader＋変更はパイプライン経由など
- ポリシーで守る：本番はSKU制限、リージョン制限、タグ必須、パブリックIP制限など
- コスト運用を組み込む：サブスクリプションごとにBudgetとアラート、タグ集計
| 項目 | 本番（Prod-Sub） | 開発（Dev-Sub） | 狙い |
|---|---|---|---|
| RBAC | 運用者のみContributor、開発者は原則Reader | 開発者にContributor | 本番の変更を統制し、開発のスピードを落とさない |
| Azure Policy | 厳しめ（必須タグ、SKU/リージョン制限、ネットワーク制限） | 緩め（最低限のガード） | 事故・コスト暴走の予防線を張る |
| Budget/アラート | 低めの閾値で早めに検知 | 月次上限や停止運用を設計 | 想定外の増加を“翌月の請求”になる前に潰す |
Tenant2でサブスクリプションを作ろうとするとTenant1に誘導されるときの切り分け
「開発用にTenant2を作ったのに、サブスクリプション作成の途中でTenant1に切り替えるよう誘導される」という現象は、課金アカウント（契約）や権限がTenant1側に寄っているケースで起きやすいです。代表的な切り分けを整理します。
| 症状 | ありがちな原因 | 確認ポイント | 対処の方向性 |
|---|---|---|---|
| Tenant2で「サブスクリプションの追加」が進まない | サブスクリプション作成に必要な課金権限がない | 課金アカウント/契約の管理画面で自分のロールを確認 | 課金ロール付与、または課金担当に作成してもらう |
| なぜかTenant1が“作成先”として提示される | 課金アカウント（支払い方法/契約）がTenant1側に存在 | どのテナントに課金アカウントが属しているか | Tenant2側での課金準備（契約/支払い設定）を整える、もしくは運用方針を見直す |
| Tenant2がB2C等の特殊なディレクトリである | B2Cディレクトリは用途が特殊で、通常のリソース管理用テナントと扱いが異なる | Tenant2の種類（B2Cかどうか）、作成経路 | B2Cは“顧客ID用”として使い、Azureリソース/課金は別テナントで管理する構成を検討 |
| 作成メニューは出るがエラーになる | 契約上限、支払い方法の検証、内部クォータ、ポリシー制限 | エラー文言、契約種別、最近の変更（支払い方法など） | Billingサポートで原因特定、必要なら上限緩和や契約見直し |
実務的には、「Tenant2に課金アカウントを用意して権限も整える」か、「テナント分離ではなく同一テナント内のサブスクリプション分割に戻す」の二択になりやすいです。後者は“設計の負債”を減らせることが多く、特に小規模〜中規模の運用では効果が大きいです。
「サブスクリプションをこれ以上作れない」問題：上限が分からないときの実務解
サブスクリプション作成が止まったとき、原因は“Azureの仕様”というより契約・課金・権限・内部制限のどれかであることがほとんどです。順番に潰せるよう、チェック項目を並べます。
チェックリスト：まず見るべき順番
- 契約形態（オファー）：個人（Pay-As-You-Go/Free/Trial）か、組織契約（MCA/EA/CSP）か
- 課金アカウント側のロール：サブスクリプション作成に必要なロールを持っているか
- 既定の作成上限や内部制限：契約ごとに“作れる数”や“作成できる条件”がある
- 支払い方法/本人確認：検証が終わっていない、支払い方法が無効、請求先情報の不整合など
- 組織の運用ルール：CSPならパートナーが作成、EAなら特定の管理者経由など
| 観点 | なぜ詰まりやすい？ | 自分でできる確認 | 次の一手 |
|---|---|---|---|
| 契約形態（MCA/EA/CSP/個人） | 作成フローと必要ロールが契約で異なる | 請求画面で契約名や課金アカウントの種類を確認 | 契約に合ったロール設計に修正 |
| 権限（RBAC/課金ロール） | サブスクリプション作成は“課金側”の権限が必要なことがある | 自分が課金アカウントの所有者/管理者か確認 | 課金管理者に付与を依頼 |
| 上限/内部制限 | 既定上限に達しても、画面では分かりにくい | エラー文言、作成履歴、最近作ったサブ数を整理 | Billingサポートで上限や緩和可否を確認 |
| 支払い方法 | 検証・承認が必要な場合がある | 支払い方法の有効性、請求先情報の不備を確認 | 支払い情報を更新、必要なら別契約に切替 |
サポートに連絡するときに添えると早い情報
サポート（特にBilling系）に投げる場合、次の情報を揃えておくと“たらい回し”を減らせます。
- 対象テナントのテナントID
- サブスクリプション作成を試した日時と、ポータル上のエラー文言
- 契約形態（MCA/EA/CSP/個人）と、課金アカウント/請求書のスコープが分かる情報
- 作成したいサブスクリプションの用途（本番/開発/検証など）と想定数
- 作成権限を持つべき担当者（課金管理者）の情報
設計で後悔しないための“現場のコツ”
最後に、検索では出てきにくいが効くポイントをまとめます。テナント/サブスクリプション設計は“正解”というより“運用コストとのトレードオフ”なので、先に運用の形をイメージしておくのが重要です。
| 悩み | ありがちな選択 | おすすめの考え方 | 理由 |
|---|---|---|---|
| 本番と開発を分けたい | すぐ別テナントにする | まず同一テナント＋サブスクリプション分割＋ポリシーでガード | テナント増はID運用が増える。多くはサブスクリプション分割で目的達成できる |
| コストを明確にしたい | テナント/サブスクリプションを細かく切る | タグとBudgetを先に設計し、必要に応じて分割 | 分割だけでは可視化できない。タグがないと集計できない |
| 権限事故が怖い | 全部を最小権限にして運用停止 | 「人の権限」ではなく「仕組み」で守る（ポリシー、PIM、承認フロー） | 運用の現実と両立しやすく、監査にも強い |
| テナントを増やしたら管理が大変 | 場当たりでゲスト招待 | 管理者アカウントの標準、ゲスト運用、監査の型を先に決める | テナント数が増えるほど“IDの作法”が効いてくる |
よくある質問
テナントだけ作って、サブスクリプション無しで使い続けられますか？
可能です。Microsoft Entra IDのテナントはID管理の基盤として存在でき、Azureリソース（VMやStorageなど）を作らないならサブスクリプションが無くても運用できます。ただし、Azureリソースを作成・課金したい場合はサブスクリプションが必要になります。
1つのサブスクリプションを、複数テナントのユーザーで共同運用できますか？
サブスクリプション自体が同時に属せるテナントは1つだけですが、他テナントのユーザーをゲストとして招待し、RBACで権限を与えることで共同運用は可能です。ポイントは“サブスクリプションの所属は1つ、運用者の参加は複数”という分け方です。
別テナントのサブスクリプションを見たいのに、ポータルに出てきません
まずディレクトリ（テナント）切り替えと、「ディレクトリ + サブスクリプション」フィルターを確認してください。それでも出ない場合は、対象サブスクリプションでのRBAC権限、もしくは課金ロールが不足している可能性があります。
本番/開発を別テナントにする最大のメリットは何ですか？
最大のメリットは、ID基盤（管理者、ポリシー、監査、アプリ登録）を含めた境界を作れることです。一方で、運用は確実に重くなります。本番/開発分離だけが目的なら、同一テナントでサブスクリプション分割する設計のほうが“管理が回る”ケースが多いです。
まとめ
テナントはIDの入れ物、サブスクリプションはAzureリソースと課金の入れ物です。テナントはサブスクリプション無しでも存在でき、サブスクリプションは同時に1つのテナントにしか紐付きません。本番/開発を分けたいだけなら同一テナント内のサブスクリプション分割が運用しやすく、テナント分離はID境界が必要な場合に選ぶのが基本です。サブスクリプションが作れないときは、テナントよりも課金アカウント・契約形態・権限・上限の切り分けが近道になります。
コメント