Microsoft Azure AD におけるエラー AADSTS50034 の対処方法：ユーザーが存在しません

By Mirko Peters · 2026-04-21

Microsoft Azure AD のエラー AADSTS50034 は、簡単に言えば「ユーザーが存在しません」という意味です。Microsoft 365、Azure、または関連するクラウド サービスへのサインイン時にこのコードが表示される場合、入力されたユーザー名に一致するアカウントを Azure Active Directory で見つけられなかったことを示します。このメッセージはよく見かけるもので、特にユーザーが退職または削除された後、サインインやアカウントの同期時に入力ミスや設定漏れがあった場合に発生します。

Automatically translated with AI from the original post. Read the English original

Microsoft Azure AD のエラー AADSTS50034 は、簡単に言えば「ユーザーが存在しません」という意味です。Microsoft 365、Azure、または関連するクラウド サービスへのサインイン時にこのコードが表示される場合、入力されたユーザー名に一致するアカウントを Azure Active Directory で見つけられなかったことを示します。このメッセージはよく見かけるもので、特にユーザーが退職または削除された後、サインインやアカウントの同期時に入力ミスや設定漏れがあった場合に発生します。

このエラーへの対処は、目障りなメッセージを消すためだけのものではありません。クラウドへのスムーズなアクセス、ユーザーの生産性、そして堅牢なセキュリティを確保するうえで重要です。AADSTS50034 は、正当なユーザーが業務を進めることを妨げるおそれがあり、アカウントのライフサイクル、ディレクトリの構成、テナントへのアクセスに関するより深刻な問題を示している場合もあります。本ガイドでは、このエラーが発生する理由、類似の問題との関係、そして Microsoft の環境で今後の AADSTS エラーを修正する、あるいはより望ましくは未然に防ぐための手順を詳しく解説します。

AADSTS50034 と関連する Azure AD 認証エラーの理解

AADSTS50034 は、Azure Active Directory のユーザー検索処理の中核に関わるエラーです。「ユーザーが存在しません」というメッセージが表示される場合、実際には Azure AD がユーザー名または資格情報をディレクトリと照合しようとしたものの、一致する情報が見つからなかったことを意味します。これは、そもそもユーザーが存在しなかった、削除された、あるいは最初から同期やプロビジョニングが行われていなかったことが原因である場合があります。

しかし、Microsoft のクラウドにおける認証は単純であることがほとんどなく、複数のエラー コードが重なって、状況の把握をかえって難しくすることがあります。AADSTS50034 のほかにも、管理者は AADSTS50020 や AADSTS50126 といったサインイン エラーによく遭遇します。これらはいずれもユーザーの存在と ID に関係していますが、それぞれ微妙に異なる意味を持っています。その結果、トラブルシューティングは犯人探しのようになり、テナントの不一致、パスワードの問題、ユーザー オブジェクトの欠落など、エラーごとに異なる原因を指し示すことになります。

Microsoft 365 や Azure のサポートを担当する人にとって、これらのコードを理解することは欠かせません。ユーザーの欠落、無効なパスワード、誤ったテナントの違いは紙一重ですが、その違いを理解しておくと、問題をより早く、より確実に解決できます。技術的な対処に入る前に、全体像を把握することが重要です。つまり、Azure AD が ID をどのように検証し、エラーをどのように解釈し、これらのコードが安全で信頼性の高いアクセスという全体の中でどのように関係しているかを理解する必要があります。それでは、AADSTS50034 の原因と、他の一般的なユーザー サインイン エラーとの違いを見ていきましょう。

AADSTS50034 エラーの原因と Microsoft Azure における AADSTS50034 の対処方法

エラー AADSTS50034 は、サインイン時に Azure AD が一致するユーザー オブジェクトを見つけられないときに表示されます。内容は名前のとおり単純で、ユーザーがディレクトリに存在しなければ、アクセスは拒否されます。ただし、その原因は、メール アドレスの入力ミスのような単純なものから、削除、同期の失敗、テナントの不一致といった見えにくい問題まで幅広くあります。

最も一般的な原因は、ユーザー名の入力ミス、最近削除されたもののまだサインインしようとしているユーザー、またはオンプレミスの Active Directory から一度も同期されていないアカウントです。また、ユーザーが誤ったテナントにアクセスしようとしているケースもあります。複数の組織にアクセス権を持っている場合や、ゲストの招待によるプロビジョニングが完了していない場合がこれにあたります。さらに分かりにくいのが、B2B ユーザーの作成に遅延がある場合や、フェデレーション時にメールアドレスと UPN が一致していない場合です。これらのケースでも AADSTS50034 が表示されます。

このエラーを解決するには、まずユーザー名に入力ミスがないかを再確認してください。Azure ポータルで、対象テナントの「ユーザー」の下にそのユーザーが存在するかを確認します。ユーザーが削除されていた場合は、復元するか、ゲストアクセスであれば再招待が必要になる場合があります。ハイブリッド環境では、オンプレミスのアカウントが有効であり、Azure AD に正常に同期されているかを確認してください。最後に、サインインが正しいテナントに対して行われていること、そしてユーザーの種類（「メンバー」または「ゲスト」）がアカウントの役割と一致していることを必ず確認してください。これらの根本的な問題に対処すれば、AADSTS50034 は解消され、環境全体の ID の信頼性も向上します。

Azure AD のユーザー エラーの比較：AADSTS50020 と AADSTS50126

AADSTS50020 と AADSTS50126 は AADSTS50034 と混同されがちですが、示しているサインインの問題は少しずつ異なります。AADSTS50020 は、ユーザーが Azure AD のどこかには存在するものの、アクセスしようとしているテナントには存在しないことを意味します。適切な資格情報で誤った組織またはテナントにサインインした場合に、よく発生します。

一方、AADSTS50126 は資格情報が誤っていることを示します。たとえば、ユーザー名は正しいものの、パスワードが違う場合です。AADSTS50034 が「あなたは誰ですか?」と問いかけているのに対し、これらのコードは「ここにはいません」(50020) や「そのパスワードではありません」(50126) と伝えています。こうした違いを素早く判断できれば、管理者は、問題がログイン情報、テナント、ディレクトリ設定のどれにあるのかを絞り込みやすくなります。

Azure AD アクセスの問題を解決するためのテナントおよびディレクトリの問題のトラブルシューティング

Azure AD のアクセスに関する問題の多くは、テナントの選択、ディレクトリの構成、またはポリシーの適用に起因します。特に複数の Azure テナントやビジネス間 (B2B) の構成を持つエンタープライズ環境では、ユーザーが単に誤った場所に、誤ったタイミングでいるためにエラーに遭遇するケースが少なくありません。ユーザーが誤って別のテナントにサインインしてしまったり、有効なサインインがポリシーによってブロックされたりすることも珍しくありません。

Azure AD のテナントとディレクトリの構造は、セキュリティの境界として機能します。ユーザーのアクセス、アプリの登録、リソースのアクセス許可は、すべて現在のテナントのコンテキストに紐付けられています。ユーザーまたはゲストが誤った経路からサインインしようとすると、システムは単に扱いにくいのではなく、そのユーザーを見つけることも認可することもできず、AADSTS50034、AADSTS50105、AADSTS53003 などのエラーが発生します。

こうしたケースのトラブルシューティングでは、ユーザーがテナント間でどのように振り分けられているか、メンバーかゲストか、ディレクトリの不一致があるかどうかに十分注意を払う必要があります。複雑な条件付きアクセスや厳格にロックダウンされたテナントを持つ組織では、構成がすべて正しく見えても、管理者のポリシーによってアクセスが拒否されることもあります。ガバナンスとポリシーがアクセスにどのような影響を与えるかについては、Azure エンタープライズ ガバナンスに関するこちらの資料をご覧ください。「なぜこのユーザーが見つからないのか」というエラーが増え続ける前に、ディレクトリとテナントの境界を正しく理解しておくことが重要です。

Azure AD で正しいテナントにアクセスしていることを確認する方法

• テナントのコンテキストを確認する: Azure ポータルや Microsoft 365 ポータルで表示されているテナントを必ず確認してください。右上に表示される表示名が、現在アクティブな組織を示しています。
• ディレクトリを切り替える: 複数のテナントに所属している場合は、ポータルのディレクトリ切り替え機能を使って組織を切り替えてから、サインインを再試行してください。
• メンバー/ゲストの状態を検証する: アクセス先の組織で、自分がメンバーとして登録されているか、ゲストとして登録されているかを確認してください。ロールが誤っていると、アクセスがブロックされることがよくあります。
• 招待を確認する: ゲストユーザーの場合は、招待が承諾されており、ゲストアカウントが正しい Azure AD ディレクトリにプロビジョニングされていることを確認してください。

AADSTS50105 と AADSTS53003 のエラーを解決する: ディレクトリへのアクセスがブロックまたは拒否される場合

1. ポリシーまたはアクセスによるブロック (AADSTS50105): 管理者がアクセスポリシー、グループ、または制限を設定しており、特定のユーザーがリソースにアクセスできない場合があります。管理センターで、グループの割り当てとロールの対象かどうかを確認してください。
2. 条件付きアクセスまたは外部ユーザーの制限 (AADSTS53003): デバイスのコンプライアンス、場所、またはリスクに関するポリシーが適用されている場合、サインインがブロックされることがあります。Microsoft Entra ID のすべての条件付きアクセスポリシーを確認し、デバイスの登録とセキュリティ要件が満たされていることを確認してください。
3. ゲストの有効期限またはアクセスレビュー: アクセスレビューや自動有効期限の後に、ゲストまたは外部ユーザーのアクセス権が失われることがあります。予期しない拒否を管理し、最小限に抑えるために、ゲストアカウントの定期的な監査とライフサイクルの見直しを実施してください。
4. 管理者による対応: より広範囲のブロックが疑われる場合は、管理者に連絡して制限の解除またはアクセスの再プロビジョニングを依頼してください。その際は、ゲストのライフサイクル ガバナンス ガイドに記載されたベストプラクティスに従ってください。

オンプレミス AD の同期とアカウントの種類の確認による AADSTS50034 の防止

ハイブリッド ID を構成している組織では、同期とアカウントの分類に関する問題が原因で AADSTS50034 のトラブルに陥ることがよくあります。オンプレミスの Active Directory が Azure AD と連携している場合、ユーザー アカウントの同期に不具合があると、ローカルにはアカウントが存在しているように見えても、ユーザーがサインインできなくなることがあります。

主な原因の 1 つは、オンプレミスの AD と Azure AD の間でユーザーが正しく同期されないことです。同期処理が失敗した、ユーザー オブジェクトが無効になっている、変更がまだクラウドに反映されていない、といったことが考えられます。こうした問題は、ユーザーがサインインを試みて「user does not exist」と表示されるまで気付かれないことが多いです。

ユーザーの分類を誤っている場合は、さらに厄介です。たとえば、本来「Member」であるべきユーザーが「Guest」になっている、またはその逆になっているケースです。Microsoft Entra ID (旧 Azure AD) は認証時にこの状態を確認します。外部ゲストの設定に誤りがあったり、同期された Member ユーザーが Guest としてマークされていたりすると、Azure AD はどこを参照すべきか判断できず、AADSTS50034 が発生します。ハイブリッド、マルチクラウド、またはゲストの多い環境を管理する管理者にとって、こうした点の理解は欠かせません。次に、Microsoft のクラウド ディレクトリで正しい同期と適切なアカウントの種類を確保するための実践的な方法を見ていきましょう。

オンプレミスの AD と Azure AD を同期し、ディレクトリ同期の問題を回避する

• 同期状態を確認する: Azure AD Connect のダッシュボードで、最後の同期時刻とエラー レポートを確認します。失敗が表示されている場合は、先に進む前に解決してください。
• クラウドでユーザーを確認する: Azure AD ポータルを使用して、ユーザーが存在し、オンプレミスのディレクトリ情報と一致していることを確認します。
• 同期エラーを解決する: 重複したプロキシ アドレス、ユーザー オブジェクトの競合、ディレクトリ同期をブロックする属性の設定ミスなど、よくある問題に対処します。
• 手動同期を実行する: ユーザーを作成または変更したばかりの場合は、手動同期を実行して、オンプレミスとクラウドのディレクトリの間で強制的に更新します。

アカウントの種類を確認し、Member と Guest の AADSTS50034 を修正する

• ユーザーの種類を確認する: Microsoft Entra ID で、ユーザーが「Member」または「Guest」のどちらとしてラベル付けされているかを確認します。種類が誤っていると、テナントのリソースへのサインインがブロックされます。
• 誤った分類を修正する: Azure AD のユーザー管理ツールを使用して、誤って登録されたゲストをメンバーに変換する(またはその逆を行う)。
• UPN とメールを検証する: ユーザー プリンシパル名(UPN)が目的のアカウントと一致していること、メール エイリアスの不一致による競合がないことを確認します。
• 外部 ID を監査する: B2B ユーザーおよびハイブリッド ユーザーについて、招待と組織間の関係が正しく設定され、有効になっているかを確認します。

Microsoft 365 でサービスやアプリの認証が AADSTS エラーを引き起こす場合

AADSTS エラーは、通常のユーザー サインインだけで発生するわけではありません。アプリやサービスが Microsoft 365 に接続する際にも表示されます。サービス自体に問題がある場合もあります。アプリの登録に不具合がある、クライアント シークレットの有効期限が切れている、登録が削除されている、といったケースです。Exchange Online、SharePoint、そして数百に及びサードパーティの統合は、Azure AD の正しい構成に依存しているため、わずかな変更でもすべてが停止する可能性があります。

アプリケーションの登録は、クライアントの認証設定と一致している必要があります。シークレットの欠落や取り消し、誤ったアプリ ID、無効になったアプリ、リダイレクト URI の不一致など、わずかなずれでも、AADSTS700016(「app not found」)や AADSTS7000218(「invalid client secret」)のようなエラーが発生する可能性があります。こうした問題は、テナント移行、PowerShell による自動化、新しいアプリを急いで作成したときなどに、IT 管理者を悩ませがちです。

さらに、条件付きアクセス ポリシーや厳格なテナント制限が厳しい場合、認証情報が正しく見えても、アプリがブロックされることがあります。エラーを正しく読み解き、問題がアプリの設定、同意の付与、OAuth の抜け穴のいずれにあるのかを追跡する方法を知っておくことは、業務の中断を防ぐうえで極めて重要です。OAuth の同意やアプリベースのセキュリティ上の隙が気になる場合は、Entra ID OAuth consent への同意攻撃を防ぐ方法をご覧ください。

AADSTS700016 と AADSTS7000218 の修正: アプリケーションが見つからない、またはクライアントが無効

• アプリの登録を確認する: アプリケーションが Azure AD テナントに登録されていることを確認します。認証要求内のクライアント ID / アプリ ID を、登録されている値と照合します。
• クライアント シークレットまたは証明書を確認する: 機密クライアントの場合、シークレットまたは証明書が有効で、アクティブであり、アプリの登録設定と一致していることを確認します。
• リダイレクト URI を検証する: 応答は、アプリの登録に記載されているリダイレクト URI を使用する必要があります。不一致があると、サインインは失敗します。
• テナントとアクセス許可の確認: アプリは正しいテナントで有効にし、ユースケースに合ったdelegated（委任）またはapp-only（アプリのみ）のアクセス許可を設定してください。

Microsoft 365サービスでのAADSTS90002およびAADSTS900144の解決

1. テナントが見つからない (AADSTS90002): 多くの場合、対象のテナントが存在しないか、削除されています。サインインやアプリの接続文字列に指定したドメイン名を再確認し、テナントがアクティブであることを確認してください。
2. ポリシーまたはディレクトリの違反 (AADSTS900144): 条件付きアクセスやテナント全体のポリシーにより、より厳格な制御が適用されている可能性があります。ポリシーを確認して調整してください。その際は、信頼性を高めるために広く適用範囲を確保し、場当たり的な例外の追加を最小限にすることを優先します。最適なポリシー設計の詳細は、この条件付きアクセスのベストプラクティスガイドをご覧ください。
3. 委任アクセスの問題: 有効期限が切れたOAuthの同意や、アプリの登録で不足しているアクセス許可があると、サインインのフローが止まることがあります。同意の付与内容とその有効期限を定期的に確認してください。
4. サービスまたはユーザーの削除: 必要なサービスプリンシパルとユーザーが、正しいテナントに存在することを確認してください。最近削除された場合は、必要に応じて復元するか、再登録してください。

多要素認証の要件と条件付きアクセス ポリシー

ユーザーが正しいアカウントと資格情報を持っていても、セキュリティ ポリシーが満たされていなければ、Azure ADはアクセスをブロックすることがあります。この点では、多要素認証（MFA）とデバイスのコンプライアンス要件が大きな役割を果たします。組織はこれらを使ってリスクを低減しており、サインインを完了する前に、追加の確認やデバイスの状態チェックを求めています。

AADSTS50076やAADSTS50079といったエラーは、ユーザーがMFAを省略した場合や、管理されていないデバイスまたはコンプライアンスに準拠していないデバイスからサインインしようとした場合に発生します。特にポリシーが最近変更された場合や、新しいデバイスを初めて使う場合、ユーザーは驚くかもしれません。新しい条件が適用されていることは、Azure ADが接続を完全に拒否するまで、事前にはわかりにくいことが多いのです。

管理者にとって、条件付きアクセスの構成と維持は、設定したら終わりという作業ではなく、継続的なサイクルです。ユーザーが回避策を見つけたり、ポリシーが変更されたり、デバイスが交換されたりするなど、設定と実態のずれは必ず生じます。拡張可能で強制力のあるID セキュリティを詳しく知りたい場合は、この条件付きアクセスのガバナンスに関するポッドキャストが、利便性を損なわずに統制を強化する方法を解説しています。次に、一般的なMFAやコンプライアンスが原因で発生するサインインのブロックを解決するための、実践的なトラブルシューティング手順を説明します。

AADSTS50076およびAADSTS50079の解決: MFAとデバイスのコンプライアンスが必要

• MFAの設定: 求められた場合は、MFAが有効になっており、構成されていることを確認してください。組織の設定に応じて、モバイルアプリ、電話の呼び出し、またはSMSを使用します。
• デバイスの登録: デバイスのコンプライアンスについては、Intuneや Endpoint Manager など、組織のデバイス管理ソリューションにデバイスが登録されていることを確認してください。
• ポリシーの確認: 条件付きアクセス ポリシーの割り当てと適用範囲を確認してください。正当なユーザーが制限が厳しすぎるルールによってブロックされている場合は、調整してください。
• 管理者への連絡: 設定が正しいにもかかわらずエラーが続く場合は、管理者にデバイスまたはセッションのコンプライアンスを確認してもらい、最近の変更がないかポリシーのログを確認してもらってください。

エキスパートのヒント: Microsoft Entra B2Bシナリオで「User Does Not Exist」エラーを防ぐ

「user does not exist」を解決するのは一つの課題ですが、そもそも発生させないようにすることは、また別の難しさがあります。特にMicrosoft Entra B2Bやクロステナントのシナリオでは困難です。企業間のコラボレーションが増えるにつれて、ユーザープロビジョニングの遅延、使われていないゲストアカウント、ユーザー属性の不整合などにより、AADSTS50034に遭遇する可能性が高まります。ゲストユーザーの作成、アカウントの削除、ハイブリッドIDの同期のプロセスは、必ずしも即時に、また完全に信頼できるものではありません。

ライフサイクル管理をしっかり行うことが重要です。招待の遅延、外部との同期の失敗、メールエイリアスの不一致により、オンボーディングが完了したように見えても、ゲストユーザーがAADSTS50034を引き起こすことがあります。非アクティブ、コンプライアンス、または管理者による手動のクリーンアップを理由に削除されたアカウントが論理削除の状態のまま残ると、サインインやテナント移行時に不可解な問題を引き起こすことがあります。こうした落とし穴を避けたい場合は、この詳細なゲスト管理ガイドで紹介されているように、定期的なアクセスレビューと体系的なライフサイクルルールが非常に役立ちます。

サービス プリンシパル認証でアプリやサービスを移行する管理者には、別の問題が生じます。ユーザー コンテキストの欠落やアクセス許可の設定ミスによって AADSTS50034 が表示されることがありますが、根本原因はユーザーが欠落していることであるケースはほとんどありません。B2B プロビジョニング、メールと UPN の照合、アプリ移行の設定を事前に整えておくことで、クロステナント プロジェクトや複雑な自動化フローに必要な安定性をディレクトリに確保できます。ここでは、この AADSTS50034 が繰り返し発生するシナリオを監視、診断、予防する方法を具体的に見ていきます。

ゲスト ユーザーのプロビジョニング、アカウントの削除、UPN の不一致による AADSTS50034

• プロビジョニングの遅延：ゲストが招待を承諾した後、アカウントが Azure AD に完全に表示されるまでに時間がかかる場合があります。トラブルシューティングを進める前に、サインイン ログを監視して、アカウントの作成タイミングを確認してください。
• 自動削除または手動削除：ゲストや外部ユーザーは、非アクティブ状態が続くと自動的に削除されることがあり、管理者が手動で削除することもあります。論理削除されたアカウントは認証できず、AADSTS50034 が発生します。このライフサイクル管理ガイドに記載されているとおり、ライフサイクル ポリシーを頻繁に見直してください。
• メール/UPN の不一致：メール エイリアスや、一致しない UPN（ユーザー プリンシパル名）を使用してサインインするユーザーは、Azure AD で見つからない場合があります。解決するには、UPN とプライマリ メールが、ディレクトリに登録されている内容と一致していることを確認してください。
• SMTP の照合競合：テナント間で同じメール アドレスが重複していると、ID の解決に失敗します。明示的な招待を使用し、各テナント内でメール アドレスが一意であることを確認して、検索エラーを防いでください。

サービス プリンシパルとアプリのみの認証：移行時に誤解を招く AADSTS50034 エラーを回避する

1. アプリのみの認証コンテキスト: サービス プリンシパルを使用する移行ツールや自動化スクリプトは、ユーザーが認証に関与していないにもかかわらず、アプリのアクセス許可が誤って構成されている場合や、スクリプトが存在しないユーザー オブジェクトを参照している場合に AADSTS50034 を受け取ることがあります。移行を実行する前に、必ずポータルでロールとアプリのスコープを検証してください。
2. 委任スコープと期限切れの同意: 委任されたアクセス許可が必要なのに、同意が期限切れになっているか、そもそも与えられていない場合、ツールが AADSTS50034 を誤って報告することがあります。特にテナント移行やアプリの再承認のサイクルの後は、同意を再度付与するか、内容を確認してください。
3. UPN とオブジェクト ID の正確性: スクリプトを作成する際は、参照エラーを避けるため、テナント内の有効なユーザーまたはサービス プリンシパルに一致する、正しく最新の UPN とオブジェクト ID を使用してください。
4. エラーの診断: 欠落しているユーザーを探すだけでなく、Graph API や PowerShell のログでアクセス許可やオブジェクト参照のエラーを確認し、認証失敗の真の原因を特定してください。