Azure にサインインしようとしたときに AADSTS5000225「This tenant has been blocked due to inactivity（このテナントは非アクティブのためブロックされています）」が出る場合、昔使っていた“古いテナント”にログイン先が固定されていることがよくあります。古いデータが不要なら、ブロック解除にこだわらず新しいテナントへ確実に切り替えて、Text-to-Speech（音声合成）を使い始めるのが最短です。
症状：AADSTS5000225 が出て Azure ポータルに入れない
典型的には、Azure ポータルや Microsoft サインイン画面で次のような状態になります。
- エラーコード：AADSTS5000225
- メッセージ：This tenant has been blocked due to inactivity
- 心当たり：1年以上前に試用した Azure（Microsoft Entra ID / Azure AD）テナントがある
- 今の目的：過去のリソースは不要。新しく Azure を使って Text-to-Speech（Speech サービス）だけ使いたい
まず整理：テナント（ディレクトリ）とサブスクリプションは別物
この手のトラブルが長引く最大の原因は、「どこにログインできないのか」を混同することです。Azure ではざっくり次の階層で管理されます。
| 用語 | 役割 | 今回のポイント |
|---|---|---|
| テナント（ディレクトリ） Microsoft Entra ID | ユーザー・ログイン・権限の“入れ物” | ブロックされると、そのテナント宛てのサインインが失敗しやすい |
| サブスクリプション | 課金・リソース作成の契約単位 | Text-to-Speech のリソース作成にはサブスクリプションが必須 |
| リソースグループ | リソースの整理用フォルダ | Speech リソースをまとめる場所 |
AADSTS5000225 の意味：非アクティブ判定でテナントが「アクセス不可」になっている
AADSTS5000225 は、長期間使われていないテナントが非アクティブ（inaccessible due to inactivity）として扱われ、ログインがブロックされている状況で出ます。Microsoft のテナント ライフサイクルの考え方として、不要なコストや放置テナントを減らす目的で、一定条件下でアクセス不可にされます。
また、管理者であっても「ブロック状態のテナントにサインインして解除する」ことができず、復活が必要な場合はサポート経由の手続きになります（復活できる期間にも制限があります）。
結論：古いテナントは“触らない”でOK。新しいテナントで作業する
今回の前提は「古いテナントのデータは不要」「新しく Text-to-Speech を使いたいだけ」です。ならば、やることはシンプルです。
- 古い（ブロックされた）テナントのブロック解除を追わない
- 新しいテナントに対して Azure ポータルへサインインし直す
- 新しいテナント配下のサブスクリプションで Speech（Text-to-Speech）リソースを作る
最短ルート：テナントを明示した URL で Azure ポータルを開く
「なぜか古いテナントへ飛ばされる」「サインインした瞬間に AADSTS5000225 になる」という場合、まず効くのがテナントを URL で指定して Azure ポータルを開く方法です。
Azure ポータルは、次の形式で特定テナントをターゲットにして開けるケースがあります。
- テナント名（例：xxxxx.onmicrosoft.com や独自ドメイン）を使う：
https://portal.azure.com/<テナント名> - テナント ID（GUID）を使う：
https://portal.azure.com/<テナントID>
これにより、ブラウザが「新しいテナント宛てのサインイン」を優先し、古いテナントのブロックに引っ張られにくくなります。
うまくいく確率を上げるコツ（必須に近い）
- シークレット（プライベート）ウィンドウで開く（古いクッキーやセッションを排除）
- 複数の Microsoft アカウントがあるなら、目的のアカウントだけでサインインする
- 普段と別ブラウザ（Edge/Chrome/Firefox など）も試す
王道ルート：Azure ポータルの「ディレクトリ + サブスクリプション」で新テナントへ切り替える
Azure ポータルに入れる状態になったら、次は「いまどのテナント（ディレクトリ）で作業しているか」を目視で固定します。Azure ポータルにはディレクトリ（テナント）を切り替える機能があります。
手順のイメージ：
- Azure ポータル右上の設定（歯車アイコン）を開く
- Directories + subscriptions（ディレクトリ + サブスクリプション）へ
- 目的のディレクトリ（新しいテナント）を探してSwitch（切り替え）
- 必要なら、表示対象のサブスクリプション フィルターも見直す
| よくある勘違い | 実際に起きていること | 対処 |
|---|---|---|
| 「ログインできた＝目的のテナントに入れた」 | ログインはできていても、古いテナントがカレントになっている | ディレクトリ + サブスクリプションで新テナントへ Switch |
| 「サブスクリプションが表示されない＝契約していない」 | サブスクが見えていないだけ（フィルター／別テナント） | サブスク一覧で「表示されない場合はディレクトリ切替」が必要 |
| 「自分が管理者なら解除できるはず」 | テナント自体がアクセス不可状態で、管理者でも入れない | 復活が要るならサポート案件。不要なら新テナントで前進 |
新しいテナント ID の確認方法（迷ったらここ）
テナント指定 URL を使うには、テナント ID（GUID）か、テナント名（onmicrosoft.com など）が必要です。Azure ポータルで確認するなら次が確実です。
- Azure ポータルで Microsoft Entra ID を開く
- 概要（Overview）の「基本情報（Basic information）」付近で Tenant ID を確認する
「ブラウザが不安定でポータルに入れたり入れなかったり」なら、CLI で確認してしまうのも手です。
az login
az account show --query tenantId -o tsv古いテナントを解除したい場合の現実的な話（今回は不要でも知っておく）
「やっぱり昔のリソースが必要だった」「請求やドメインの都合で復活が必要」という場合は別ルートになります。Microsoft の案内としては、非アクティブでアクセス不可になったテナントは、管理者が一定期間内に再アクティブ化を依頼でき、期間を過ぎると削除される扱いです。
- 復活が必要：テナント管理者が Microsoft サポートへ連絡
- 復活が不要：放置でよい（一定期間後に削除・復旧不可）
ここからが本題：新しいテナントで Text-to-Speech（音声合成）を使う手順
新テナントに入れたら、次は Speech（Text-to-Speech）を最短で動かします。ポイントは「サブスクリプションがあること」と「Speech リソースを作ってキーとエンドポイントを取る」の2つです。
最短チェックリスト
| チェック項目 | OK の目安 | NG のときに起きること |
|---|---|---|
| 新テナントに切り替わっている | ディレクトリが新テナント | 古いテナントに誘導され AADSTS5000225 が再発 |
| サブスクリプションが見える | 「サブスクリプション」一覧に表示 | リソース作成ができない（作成ボタンが進まない） |
| Speech リソース作成 | Speech のキー・エンドポイントが見える | SDK/REST が認証エラーになる |
Speech（Text-to-Speech）開始の手順
- 新しいテナントで Azure ポータルに入る（ディレクトリも確認）
- リソースグループを作成（例：rg-speech-jp）
- Speech（AI Services resource for Speech）を作成
- 作成後にリソースへ移動し、キーとエンドポイント（またはリージョン）を確認
Text-to-Speech のクイックスタートでも、前提として「Azure サブスクリプション」「Speech リソース作成」「キーとエンドポイント取得」が明示されています。
API を叩くときの基本：エンドポイントとヘッダーを間違えない
Text-to-Speech を「とにかく動かす」だけなら、Speech SDK を使うのが一番トラブルが少ないです。REST API も使えますが、用途によっては SDK が推奨されます。
REST で“声一覧”を取る（動作確認に便利）
リージョンに紐づく音声一覧は、次のような形式のエンドポイントで取得できます（リージョンを合わせるのが重要です）。
https://<リージョン>.tts.speech.microsoft.com/cognitiveservices/voices/list
認証は、最小だと Ocp-Apim-Subscription-Key ヘッダー（Speech リソースキー）で通せます。
REST で音声合成する（SSML を送る）
Text-to-Speech の合成は、概ね次のようなエンドポイントに SSML を POST します。
https://<リージョン>.tts.speech.microsoft.com/cognitiveservices/v1
最低限押さえるヘッダー例：
Content-Type: application/ssml+xmlX-Microsoft-OutputFormat: ...（出力音声フォーマット）Ocp-Apim-Subscription-Key: ...もしくはAuthorization: Bearer ...
「新しいテナントを作ったのにまたブロックに当たる」時の追加チェック
テナント指定 URL を使っても AADSTS5000225 が出る場合、次のどれかが原因になりがちです。
| 原因 | 見え方 | 対処 |
|---|---|---|
| ブラウザが古いテナントを“起点”として記憶している | 何度やっても同じエラー画面に戻る | シークレット、別ブラウザ、いったんサインアウトを徹底 |
| ディレクトリ切替はできていない | 入れたがサブスクリプションが出ない | 設定 → ディレクトリ + サブスクリプションで Switch |
| Speech リソースのリージョンと API のリージョンが不一致 | 401/403 や Endpoint 関連でつまずく | Speech リソースのリージョンに合わせたエンドポイントを使う |
運用の小ワザ：テナントを増やすほど“迷子”が増える
今回のように「古いテナントが残っていて、新しいテナントで始めたい」ケースは今後も起きやすいので、最初に少しだけ整備しておくと事故が減ります。
- 新テナントの表示名を分かりやすくする（例：Personal-Azure-2025）
- リソースグループ名に用途とリージョンを入れる（例：rg-speech-japaneast）
- サブスクリプション フィルターを使う場合は「隠れて見えない」を疑う
まとめ：AADSTS5000225 は“古いテナント問題”。新テナントに切り替えれば前に進める
- AADSTS5000225 は、非アクティブでブロックされたテナントにサインインしようとしているサイン
- 古いデータが不要なら、ブロック解除に時間を使わず新しいテナントを正しく狙ってログインする
- 確実化の手段は、テナント指定 URL＋ディレクトリ + サブスクリプションでの切替＋シークレット/別ブラウザ
- Text-to-Speech は、新テナント配下でSpeech リソースを作り、キーとエンドポイント（リージョン）を取ればすぐ始められる
コメント