個人の Microsoft アカウントで作成した Azure 無料アカウントが、Grafana 連携などの設定後に突然サインインできなくなり、AADSTS16000（Microsoft Services テナント）で止まることがあります。これは「正しいテナント」と「正しいサインイン名（UPN）」がズレた状態で起きやすく、原因を切り分けて手順どおりに進めれば復旧できるケースが多いです。
現象：AADSTS16000 で Azure ポータルにサインインできない
次のような状況に当てはまる場合、本記事の手順がそのまま役に立ちます。
- 個人の Microsoft アカウント（例：
[email protected]/[email protected]）で Azure 無料アカウント を作成し、しばらくは普通に使えていた - プロジェクト要件で Grafana を使うため、Azure 側で「アプリの登録」や認証周りの設定を触った
- その途中から、ログインしているアカウントが
@tenantname.onmicrosoft.com形式や、組織内アカウントのような表示に切り替わった - 元の個人メールで Azure ポータルに入れなくなり、AADSTS16000（tenant が Microsoft Services など）と出る
- サブスクリプションやリソースに一切アクセスできず、新規で無料アカウントを作り直そうとしても「対象外」になる
AADSTS16000 のエラーを「何が起きているか」に翻訳する
AADSTS16000 は、ざっくり言うと「今サインインしようとしているユーザーは、認証先として選ばれたテナント（ディレクトリ）に存在しない／招待されていない」状態で出やすいエラーです。実際、Azure ポータルで発生する AADSTS16000 には、次のような文言が含まれることがよくあります。
interaction_required: AADSTS16000:
User account '（あなたの個人メール）' from identity provider 'live.com' does not exist in tenant 'Microsoft Services'
...
The account needs to be added as an external user in the tenant first.
Sign out and sign in again with a different Azure Active Directory user account.ここで重要なのは、エラーの「原因」よりも、どこに向かってログインしようとして失敗しているかです。
| エラーメッセージの要素 | 読み解き | 復旧の方向性 |
|---|---|---|
identity provider 'live.com' | 個人 Microsoft アカウント（MSA）で入ろうとしている | MSA のまま入るなら「ゲストとして招待されている」必要がある |
tenant 'Microsoft Services' | 目的の Azure テナントではなく、別テナント側に接続されている可能性が高い | テナントを固定してログインし直す（tenant-specific URL など） |
does not exist in tenant | そのテナントにユーザーがいない／外部ユーザーとして追加されていない | 正しい UPN で入る、または外部ユーザーとして再追加する |
Microsoft のコミュニティ回答でも、AADSTS16000 は「認証に使われたテナントにユーザーが見つからない」ことが根本で、個人アカウントで入っていると Microsoft Services テナントに接続されてしまうケースがある、と説明されています。
なぜ「Microsoft Services」に飛ばされるのか（ここがハマりポイント）
Azure ポータルはブラウザのセッション（クッキー、SSO 状態、直前に使ったアカウント）に影響されます。たとえば、次のような状況が重なると「本来入るべきテナント」ではなく、別のテナント文脈でトークン取得を試みて AADSTS16000 で止まります。
- 同じブラウザで複数の Microsoft アカウント（個人／職場・学校）を切り替えて使っている
- 直前に Microsoft 365、Teams、別テナントの Entra 管理センターへログインしていた
- Grafana 連携の検証中に、ログイン先のテナントを切り替えた／切り替わった
この状態では、いくら「正しいメールアドレスとパスワード」を入れても、認証先テナントがズレている限り同じエラーを引きやすいのが厄介な点です。
原因の核心：外部ユーザーを内部ユーザーに変換すると「入口」が変わる
あなたの状況は、よくある “無料アカウント＋個人メール” の構成に、Entra（旧 Azure AD）側のユーザー変換操作が加わったときに起きるパターンです。
まず、アカウントの種類を整理する（用語で迷子にならないため）
| 用語 | 意味 | 例 |
|---|---|---|
| Microsoft アカウント（MSA） | Outlook.com / Hotmail / Gmail 等で作る「個人」アカウント | [email protected] |
| Microsoft Entra ID（旧 Azure AD）アカウント | テナント（ディレクトリ）内で管理される「職場/学校」系のアカウント | [email protected] / [email protected] |
| テナント（ディレクトリ） | ユーザーやアプリ、サブスクリプションの「所属先」 | tenantname.onmicrosoft.com |
| UPN（サインイン名） | テナント内でのログイン名。見た目がメールに近いが「メール＝UPN」とは限らない | [email protected] |
| 外部ユーザー（External） | ホスト組織の外で認証されるユーザー（MSA など） | user_domain.com#EXT#@tenantname.onmicrosoft.com のような表記 |
| 内部ユーザー（Internal） | ホスト組織のテナントで認証されるユーザー | [email protected] |
「外部 → 内部」変換で何が起きる？
Microsoft Entra には、外部ユーザーを内部ユーザーに変換するための機能が用意されています。管理センターで外部ユーザーを選び、Convert to internal user を実行する流れが公式に案内されています。
そして公式ドキュメントは、この変換について「利用できなくなると困るアカウントでテストしないほうがよい」趣旨の注意も明記しています。つまり、変換はユーザーの “入口” を変え得る操作であり、うっかり自分のメインアカウントで実施すると、今回のようにログイン不能が起きやすい、ということです。
さらにややこしいのが、UserType（Member/Guest） も関係し得る点です。UserType は「組織との関係性」を表す属性で、Member ↔ Guest を相互変換できる一方、軽々に変えるべきではないとされています。
結論として、今回のハマり方はこう整理できます。
- 最初：個人 MSA で Azure にサインアップ → テナントには “外部ユーザー” として紐づく形が多い
- 途中：何らかの操作（変換/UPN 変更/ユーザー属性変更）で、内部ユーザーとして扱われる入口に切り替わった
- 結果：元の MSA（live.com）で入ろうとすると、そのテナント側に “存在しない” 扱いになり AADSTS16000
復旧の最短ルート：テナントを固定して、テナント内アカウントで入る
復旧で一番大事なのは、次の2つを “固定” することです。
- どのテナントに入るか（ディレクトリ）
- どの UPN（サインイン名）で入るか
最初にやる：セッションをリセットして「別アカウントの残骸」を消す
まずは、余計な SSO 状態を避けます。
- ブラウザの InPrivate / シークレット で新しいウィンドウを開く
- Azure ポータル、Microsoft 365、Entra 管理センター等を開いているタブがあれば全部閉じる
- 可能なら「別ブラウザ」で試す（Edge と Chrome を分けるなど）
Microsoft Learn のサインアップ／トラブルシューティングでも、問題がある場合に InPrivate を試すことが示されています。
テナントを固定して Azure ポータルを開く（重要）
AADSTS16000 でループする場合、tenant-specific URL で Azure ポータルに入るのが効果的なことがあります。Microsoft の回答でも、テナント固有 URL でのサインインが案内されています。
例（コードとして扱うため、実際はあなたのテナントに置き換えてください）：
https://portal.azure.com/<TenantID>
[https://portal.azure.com/<tenantname.onmicrosoft.com](https://portal.azure.com/<tenantname.onmicrosoft.com)>ポイントは「ポータルに入ってからディレクトリを探す」ではなく、入口の時点で入るテナントを指定してしまうことです。
次にやる：個人メールではなく「テナント内のサインイン名（UPN）」でログインする
あなたのケースでは、次のような形式のアカウントでサインインする必要が出ている可能性が高いです。
ユーザー名@tenantname.onmicrosoft.comユーザー名@xxxx.com（カスタムドメインを設定している場合）- Grafana 用に作成した “テナント内ユーザー” の UPN
パスワードについては状況により異なりますが、典型的には次のどちらかです。
- 変換前から継続して使われているパスワード
- 内部ユーザー化や新規ユーザー作成時に設定したパスワード（自分で設定した／自動生成を控えた）
MFA（多要素認証）のセットアップが出たら、必ず完了させる
復旧直後に MFA の登録を求められることがあります。ここで未設定のまま中断すると、次回以降また入口で詰まりやすくなります。スマホアプリ（Authenticator）や SMS など、環境に合わせて登録を済ませます。
ログインできたらやること：サブスクリプションとリソースを取り戻す手順
ポータルに入れた時点で半分は解決ですが、次は「サブスクリプションが見える状態」を取り戻します。
ディレクトリとサブスクリプションを正しく選ぶ
Azure は「ログインできた＝サブスクリプションが見える」とは限りません。ディレクトリ（テナント）がズレていると、リソースが “消えたように見える” ことがあります。
- 画面上部のディレクトリ表示が想定どおりか確認する
- 「ディレクトリ + サブスクリプション」フィルターで、対象のサブスクリプションにチェックが入っているか確認する
- もしサブスクリプションが空なら、別ディレクトリに切り替えて再確認する
権限（RBAC）不足を疑う：Owner/Contributor が付いているか
ログインはできても、サブスクリプションに対して権限が付いていないとリソースは操作できません。特に “自分自身を変換してしまった” ケースでは、権限の割り当てが意図せず変わることがあります。
| 症状 | よくある原因 | やること |
|---|---|---|
| サブスクリプションが一覧に出ない | ディレクトリ/フィルターのズレ、または権限なし | ディレクトリ切替 → フィルター確認 → 既存の管理者に RBAC 付与を依頼 |
| 見えるが作成/変更ができない | Reader 相当の権限、または条件付きアクセス/MFA未完了 | 自分のロール確認、MFA完了、必要なら Contributor 以上を付与 |
| Entra（ユーザー/アプリ登録）が開けない | テナント側の管理権限がない | グローバル管理者/ユーザー管理者に操作を依頼 |
元の個人メール（MSA）でも入りたい場合の現実的な対処
「以前の [email protected] でまた Azure に入りたい」というニーズは多いのですが、ここは少し割り切りが必要です。理由は、内部ユーザー化によって “入口” が変わると、同じ人物でも別ユーザーとして扱われる状態になりやすいからです。
実務的に一番安全な方法は、次のどちらかです。
方法：元の個人メールを “ゲスト” として再追加し、サブスクリプションに権限を付ける
- テナント内アカウントでポータルに入る
- Microsoft Entra の「ユーザー」から、元の個人メールアドレスを外部ユーザーとして追加（招待）する
- サブスクリプション（またはリソースグループ）の「アクセス制御（IAM）」で、そのゲストに Owner もしくは Contributor を付与する
これにより、個人メール（MSA）でサインインしても “そのテナントに存在する外部ユーザー” として扱われ、アクセスできる形に戻せる可能性があります（ただし、組織のポリシーや設定次第で制限がある点は注意）。
補足：UserType の変換は慎重に
Member/Guest の変換自体は可能ですが、UserType は「関係性」を表す属性であり、軽々に変えるべきではないと公式ドキュメントでも注意されています。復旧目的であっても、最後の管理者を失うような操作にならないよう、必ず代替の管理者を確保してから進めてください。
「Azure 無料アカウントの対象外」と出て作り直せない理由
今回のトラブルで多くの人がやりがちなのが、「入れないなら作り直そう」として無料アカウントを再作成しようとすることです。しかし、ここで “対象外” になるのは珍しくありません。
Azure 無料アカウントは 新規 Azure 顧客のみに提供される、と明記されています。
また、Microsoft Learn のガイドでも、無料試用（free trial）は Azure の利用歴がある場合に有効化できず、必要であれば 従量課金（pay-as-you-go） を検討するよう案内されています。
そのため、今回のように「無料枠をすでに使っている／同一人物判定に引っかかる」状態では、作り直しで解決しないケースが多く、基本戦略は “元のテナントとサブスクリプションを取り戻す” になります。
それでも新規サインアップが必要な場合のチェックポイント
どうしても別環境が必要で、従量課金での新規作成などを検討する場合は、入力情報の不一致や過去利用情報が原因で弾かれることがあるため、公式のチェック項目（住所・電話・カード・同一情報の Microsoft アカウント有無など）に沿って見直すのが安全です。
Grafana 連携を進めるときの再発防止（やりがちな落とし穴を潰す）
Grafana を Azure と連携させるとき、認証（OIDC/SAML）や API アクセスの都合で Entra 側の設定に踏み込むことが多く、そこで “自分の入口” を触ってしまうと事故が起きます。復旧後は、次の運用に切り替えると同じ事故を避けやすくなります。
管理アカウントを分ける
- 管理用（テナント管理者）：日常利用しない。MFA 必須。パスワードはパスワードマネージャで保管。
- 作業用（普段の操作）：リソース作成や確認に使う。
- アプリ用（Grafana 連携）：アプリ登録（クライアント ID / シークレット / 証明書）やサービスプリンシパルに寄せ、人のアカウントを極力使わない。
「外部→内部」変換を行う前に、必ず代替管理者を確保する
外部ユーザー変換は影響が大きい操作です。公式にも、変換テストは “利用できなくなると困るアカウント” で行わないほうがよい、と明示されています。まずはテスト用ユーザーで検証し、問題ないことを確認してから本番に適用するのが安全です。
必ずメモしておくべき情報（復旧速度が段違い）
| 項目 | 理由 | 例 |
|---|---|---|
| Tenant ID / テナントのドメイン | tenant-specific URL で入口を固定できる | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / tenantname.onmicrosoft.com |
| 管理者の UPN | 「どのアカウントで入るか」がブレない | [email protected] |
| 復旧用の追加管理者 | 自分がロックアウトしても戻せる | 別ユーザーにグローバル管理者を付与 |
| MFA の登録状況 | 入口で詰まらない | Authenticator / SMS |
それでも入れない場合の考え方（詰まりどころ別）
最後に、復旧の分岐を簡単にまとめます。
| 状況 | 優先する打ち手 | 次の手 |
|---|---|---|
| テナント内 UPN とパスワードが分かる | tenant-specific URL で入り、UPN でログイン | MFA 設定 → サブスクリプション確認 → 権限回復 |
| テナントは分かるが UPN/パスワードが不明 | 同テナントの別管理者にパスワードリセットを依頼 | 管理者不在ならサポート窓口へ（契約形態により手順が異なる） |
| どのテナントかも分からない／ディレクトリが見つからない | サインアップ時のメール等からテナント情報を辿る | 復旧が難しい場合は従量課金や別の検証環境を検討 |
AADSTS16000 は一見 “認証のエラー” に見えますが、実態は「入口（テナント/UPN）の取り違え」であることが多いです。まず入口を固定し、テナント内アカウントで入って状況を把握できれば、サブスクリプションとリソースへのアクセスは取り戻せる可能性が高まります。
コメント