Microsoft Entra External ID（顧客向けCIAM）の外部テナント作成で「オーストラリア」が選べず、データ主権やIRAP要件で計画が止まる――この課題の最新状況と、後戻りできないテナント所在地の注意点、移行設計の現実解を整理します。
「オーストラリアを選べない」問題は今どうなっているのか
結論から言うと、「オーストラリアリージョンで External ID の外部テナントを作れない」状態は、公式に“前進”しています。これまでMicrosoft Q&Aなどでは「Australia location is not supported」「時期は未公表」「テナント作成後に場所は変えられない」といった回答が続き、オーストラリア国内ホスト必須の組織ほど意思決定ができず、代替CIAMへ移行したという声もありました。
しかし、Microsoft公式のリリース情報（Microsoft Entra の “releases and announcements / What’s new”）にて、Microsoft Entra External ID を Australia/Japan に拡張する一般提供（GA）が告知され、外部テナント作成時に選択できる「Go-Local add-on」として提供される位置付けが明確化されています。加えて、外部テナント作成手順のドキュメント側にも、Australia/Japan を選ぶと Go-Local の選択肢が表示される旨が明記されました。
まず押さえるべき重要ポイント
- 「テナントの場所（Country/Region）」は後から変更できない（これは今も変わりません）
- Australia 対応は “Go-Local add-on” とセットで説明されており、要件によっては費用・例外（グローバル基盤の一部機能）を含めた精査が必要
- 先に別リージョンで本番テナントを作り、後から“簡単に移す”前提は危険。移行は「新テナントを作って切り替える」設計になりやすい
そもそも「テナントの場所」とは何か：Azureリージョンと混同しない
External ID（外部テナント）を作成するときに選ぶ「場所（Country/Region）」は、Azureのリソース作成時に選ぶ「リージョン」と同じ概念ではありません。Microsoft Entra は、テナントを地理的な単位（geo-location）に割り当て、そこでディレクトリデータ（Core Store）などを保持・複製します。
| よく混同される用語 | 何を決めるものか | 外部テナント（External ID）での影響 | 注意点 |
|---|---|---|---|
| テナントの場所（Country/Region） | Microsoft Entra テナントのデータ保管・処理の地理的割り当て | データ主権・レイテンシ・規制対応の前提が決まる | 作成後に変更不可。後から「移す」は基本的に“新テナントでやり直し” |
| Azureリージョン（例：Australia East） | Azureリソース（VM/DB/Storage等）の配置場所 | アプリ本体・ログ基盤・周辺サービスの配置に影響 | External ID のテナント所在地と一致させても、外部サービスやMFA等の例外は別途確認が必要 |
| データレジデンシ（Data Residency） | データをどこに保管し、どこで処理するかの方針 | 契約・法令・監査で問われる | 「保管」だけでなく「処理」「転送」「運用者アクセス」まで定義が必要 |
このうち、今回の争点はテナント作成時に選ぶ Country/Region で Australia を選べるか、そして選んだ場合に“どの範囲のデータが国内に留まるか”です。
公式アップデート：Australia 対応は「Go-Local add-on」としてGA
Microsoft の “What’s new” では、External ID を Australia/Japan に拡張し、Go-Local add-on により External ID データを選択した場所に保存・処理できるようにする、という趣旨が説明されています。ここで重要なのは、同時に「一部の集中管理型プラットフォームサービスはグローバルに残る」という但し書きがある点です（例として MFA や RBAC の一部機能が挙げられています）。
Go-Local add-on で何が変わるのか（実務目線）
| 観点 | 期待できること | 追加で確認すべきこと |
|---|---|---|
| データ主権（保管場所） | 外部テナントのデータを Australia（またはJapan）に寄せられる | 「どのデータが対象か」「例外は何か（ログ、通知、MFA等）」を監査要件に照らして確認 |
| 導入手順 | 外部テナント作成時に選択肢として出る（Australia/Japan） | 後から変更できないため、本番テナントは初回から正しい選択で作成 |
| コスト | 必要な組織だけが追加オプションとして採用できる | Go-Local は有償アドオン。External ID のアドオンは無料枠の対象外（=最初のMAUから課金になり得る） |
| コンプライアンス（例：IRAP） | 「国内リージョン必須」の前提を満たしやすくなる | IRAPは“国内にあること”だけで完結しない。評価対象サービス範囲、運用、例外、統制まで含めてエビデンス化が必要 |
「オーストラリアで作れるのはいつ？」への答え方
過去のQ&Aでは時期未公表が続きましたが、公式のリリース情報としては2025年12月のアップデートで Australia/Japan への拡張（GA）が明記されました。したがって、今このテーマで計画を立てるなら、次のように整理すると社内説明が通りやすくなります。
- 2024年〜2025年10月頃まで：実質的に選べず、ロードマップも明確でない（コミュニティ上の不満が多い状態）
- 2025年12月：公式の “What’s new” で Australia/Japan の拡張が GA として言及され、Go-Local add-on の枠組みが提示
- 現在：外部テナント作成フロー上で Australia/Japan と Go-Local の説明がドキュメント化。実運用は「例外の扱い」「監査証跡」を含めて設計判断
「先に他リージョンで作った場合、後からオーストラリアへ移行できる？」
ここが最大の落とし穴です。Microsoft Entra の設計として、テナントの場所（Country/Region）は後から変更できません。つまり、「とりあえず別リージョンで本番テナントを立てて、後からオーストラリアに引っ越す」という計画は、原則として成立しません。
現実的な移行は、次のどちらかになります。
- 新しい外部テナント（Australia）を作成し、設定・ユーザー・アプリを移し替えて切り替える
- 既存環境の扱いについて Microsoft 担当者（サポート/アカウントチーム）に相談し、提供される手段があるか確認する
“移行＝引っ越し”ではなく“新築して切替”になりやすい理由
External ID の外部テナントは、アプリ登録、ユーザーフロー、IDプロバイダー設定、ブランド設定、課金（サブスクリプション紐付け）など、複数の要素が組み合わさって成立します。テナント所在地が変えられない以上、所在地を変えるにはテナントそのものを作り直す必要が出やすく、既存テナントから完全自動で移せるとは限りません。
移行時に“やり直し”になりやすい項目チェックリスト
| 領域 | 具体例 | 移行の難易度（目安） | 実務のコツ |
|---|---|---|---|
| アプリ統合 | アプリ登録、リダイレクトURI、証明書/シークレット、APIスコープ | 中 | 設定値を棚卸しし、環境差分（テナントID/issuer/authority）を外部化して切替しやすくする |
| サインイン体験 | ユーザーフロー、属性収集、ブランド（ロゴ/色/文言） | 中 | 画面差分が出やすい。プロダクト/法務（同意文面）も巻き込んで再レビュー |
| IDプロバイダー | Google/Apple 等のソーシャル、OIDC/SAML フェデレーション | 中〜高 | 各IdP側に登録しているリダイレクトURIの変更が発生しやすい。切替期間は並行稼働を前提に |
| ユーザー移行 | ユーザー属性、パスワード移行、同意情報 | 高 | Microsoft Graph API を使った移行が基本。パスワードが平文で取れない場合は、SSPRや段階移行を設計 |
| 監査・ログ | サインインログ、監査ログ、SIEM連携 | 中 | 「どこに保管されるか」も含めて監査要件に合わせて設計。ログ基盤（Azure Monitor等）はアプリ側リージョンとも連動 |
| 権限・運用 | 管理者ロール、運用手順、緊急時対応 | 中 | テナントを分けると運用も分かれる。運用者のアクセス統制と監査証跡を最初からテンプレ化 |
移行を前提にした“安全な進め方”（おすすめ構成）
オーストラリア要件が厳格な場合は、次のような二段階構成が現実的です。
- 検証：別リージョン（またはGo-Local未適用）でもよいので、機能検証・アプリ統合・運用設計のたたき台を作る
- 本番：要件を満たす Australia の外部テナントを“最初から正しく”作成し、検証で固めた設計を横展開する
このやり方だと「本番のテナント所在地を誤って作ってしまい、後から取り返しがつかない」リスクを最小化できます。検証は“捨ててもよい環境”として割り切り、設定は手順化・コード化（パラメータ化）して本番に移す、という思想が重要です。
Azure AD B2C を継続利用するべきか、External ID に投資すべきか
意思決定を難しくしているのは、「B2Cがすぐ止まるわけではないが、新規には制約が増えている」「External IDが“次世代”だが、B2Cの完全上位互換ではない」という二重構造です。ここでは、公式情報をベースに整理します。
Azure AD B2C の現状（重要な公式ポイント）
- 2025年5月1日以降：Azure AD B2C は新規顧客向けに購入不可（End of sale）
- 既存顧客：継続利用は可能で、体験（テナント作成やユーザーフロー等）は基本的に維持される
- サポート期間：少なくとも2030年5月まではサポート継続が明記されている
- ライセンス面：B2C P2 は2026年3月15日に廃止予定で、テナント作成は P1 が前提になる整理が示されている
External ID の現状（投資判断に効くポイント）
- 次世代CIAMとして位置づけられ、外部ユーザー（顧客/市民/パートナー）を別テナント（外部テナント）で管理できる
- 料金は MAU ベースで、一定の無料枠がある一方、アドオン（Go-Local等）は無料枠の対象外
- 機能差分：B2Cの「カスタムポリシー（IEF）」のような複雑なオーケストレーションは、External IDでは“不要化する方向”で説明されており、現実にはユーザーフロー＋拡張（API連携等）で代替していく思想
- 地域要件：Australia は Go-Local add-on として GA の位置づけになり、国内データ主権要件に寄せやすくなった（ただし例外は精査必須）
機能・運用・規制の観点での比較（実務向け早見表）
| 観点 | Azure AD B2C | Microsoft Entra External ID（外部テナント） | 判断の勘所 |
|---|---|---|---|
| 新規採用のしやすさ | 新規顧客は購入不可（2025/5/1以降） | 次世代として推進 | “今から新規でMicrosoft系CIAM”なら External ID 寄りになりやすい |
| 高度なカスタマイズ | カスタムポリシー（IEF）で自由度が高い | ユーザーフロー中心。複雑ロジックは拡張で代替する設計思想 | 既存のIEF資産が大きいほど、短期での完全移行は慎重に |
| UI/画面の自由度 | テンプレ/HTML/CSS含めた柔軟な制御が可能なケースが多い | ブランディング中心（“完全に自由”ではない範囲が出やすい） | デザイン要件が厳しい場合は PoC で先に限界値を確認 |
| オーストラリアのデータ主権 | 既存顧客なら運用継続しやすい | Go-Local add-on により Australia 対応が公式化 | 「国内に置く」だけでなく、MFA/通知/ログ等の“例外”を監査目線で整理 |
| 移行のしやすさ | 現行維持は容易 | ユーザー移行は Graph 等で設計・実装が必要 | 移行は“魔法のワンクリック”ではない前提で計画する |
| 中長期リスク | サポートは少なくとも2030年まで継続と明記 | 戦略製品として機能追加が継続 | 5年以上の寿命を想定するなら External ID への投資比率を上げる価値は高い |
おすすめの意思決定フレーム：期限×規制×機能差分で決める
「B2C継続か External ID か」の議論は、機能比較だけで決めると失敗しがちです。実務では“いつまでに本番が必要か”と“規制の厳密さ”で打ち手が変わります。
パターン別の現実解
| 状況 | 推奨アクション | 理由 |
|---|---|---|
| 新規案件で、オーストラリア国内データ主権が必須 | External ID（Australia＋Go-Local）を前提に設計 | B2Cは新規購入不可。External IDで公式に Australia 対応が整理され、要件を満たしやすい |
| 既存で B2C を大規模運用、IEF（カスタムポリシー）資産が重い | 当面はB2Cを維持しつつ、段階移行の計画を作る | サポート期限の余裕を使って、External ID 側の成熟や移行パスの整備を待ちながら安全に移行 |
| 期限が近いが、External IDの機能差分が致命的 | 短期はB2C（既存顧客の場合）または他社CIAMを含めて比較 | 「Microsoftに寄せたい」だけで無理に選ぶと、UXや運用で破綻する。要件が満たせる選択肢を優先 |
| コンプライアンスで“処理”まで国内限定、例外が許されない | Go-Localでも例外が残り得る前提で、監査設計→是非判断 | 一部機能がグローバル基盤に残る説明があるため、厳格要件では法務・監査と合意形成が必須 |
IRAP/データ主権で揉めないための実務チェックリスト
「Australia を選べるようになったか」だけで終わらせず、監査に耐える形に落とすには、要件定義を次の粒度まで落とすのが効果的です。
要件の言語化（これが曖昧だと詰みやすい）
- 国内に置く対象は何か：ユーザー属性、認証ログ、監査ログ、MFA関連データ、通知（メール/SMS）に含まれる個人情報など
- 「保存」だけで良いのか：認証処理・リスク判定・ロール評価など、処理も国内限定か
- 許容できる例外はあるか：プッシュ通知基盤（Apple/Google）、グローバルな集中サービス、障害時のフェイルオーバーなど
- エビデンスの形：どのドキュメントを根拠にし、どの運用ログで実証するか
確認先（Microsoft公式で押さえる場所）
- Microsoft Entra のリリース情報（What’s new / releases and announcements）
- Microsoft Entra のデータレジデンシ（Microsoft Entra ID and data residency）
- Microsoft Entra External ID の作成手順（外部テナント作成、Go-Local表示条件）
- Microsoft Entra External ID のFAQ（アドオン課金・無料枠の扱い）
- IRAPについては、Microsoftのコンプライアンス情報および Service Trust Portal（対象サービス範囲の確認）
よくある失敗と回避策
「とりあえず別リージョンで本番開始」
回避策：本番テナントは必ず要件を満たす所在地で新規作成する。検証は別環境で割り切り、設定を再現可能（手順化/自動化）にしておく。
「B2CとExternal IDは同じ感覚で移行できるはず」
回避策：External ID は“ユーザーフロー中心・拡張で代替”の設計思想。IEFカスタムポリシー前提の設計は、そのまま持ち込めない前提でギャップ分析を行う。
「データ主権＝テナント所在地だけで解決」
回避策：通知・MFA・ログ・連携先（SIEM/メール配信/通信経路）まで含めたデータフロー図を作り、例外が要件に抵触しないかを監査・法務と合意する。
まとめ
- 過去は「External ID 外部テナントで Australia を選べない」「時期未公表」が続いたが、公式のリリース情報で Australia/Japan 拡張（GA）が明記され、Go-Local add-onとして整理された。
- テナントの場所（Country/Region）は作成後に変更できないため、「先に別リージョンで本番→後で移行」は高リスク。基本は新テナントを作って切替の設計になる。
- Go-Local は強力だが、有償アドオンであり、一部の集中サービスがグローバルに残る旨の説明もある。厳格なデータ主権・IRAP要件では“例外の扱い”まで含めて判断する。
- Azure AD B2C は新規顧客の購入停止など制約が進む一方、既存顧客向けには少なくとも2030年までのサポート継続が明記されている。既存資産（特にカスタムポリシー）と期限で段階移行を設計するのが現実的。
参考情報（公式ドキュメント名）
- Microsoft Entra releases and announcements（What’s new）
- Microsoft Entra ID and data residency（Go-Local add-on の説明を含む）
- Create an external tenant（外部テナント作成手順、Australia/Japan を選ぶ場合のGo-Local表示）
- Microsoft Entra External ID frequently asked questions（アドオン課金・無料枠の扱い）
- Azure AD B2C: Frequently asked questions（End of sale、サポート期限、P2廃止予定など）
- Azure compliance / Microsoft compliance の IRAP 関連ページ（IRAPの概要と確認導線）
コメント