Microsoft Azure および M365 における AADSTS70000 Invalid Grant エラーの理解

By Mirko Peters · 2026-04-21

AADSTS70000 の「invalid grant」エラーは、Azure Active Directory や Microsoft 365 サービスを扱う管理者や開発者にとって、よくある悩みの種です。

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

AADSTS70000 の「invalid grant」エラーは、Azure Active Directory や Microsoft 365 サービスを扱う管理者や開発者にとって、よくある悩みの種です。Power Platform、Outlook アドイン、または Microsoft の ID フローに依存するアプリを通じてシステムや自動化を接続する際に、このエラーがよく表示されます。

簡単に言えば、AADSTS70000 エラーは認証中に何かが失敗したことを意味します。通常は、アプリやユーザーが OAuth を使ってトークンを取得しようとした際に、「grant」がもはや有効ではない場合に発生します。これにより Power Automate のワークフローが停止したり、Outlook との連携が壊れたり、Azure や Entra ID を認証に使用しているアプリへのサインインが妨げられたりする可能性があります。クラウド IT やアプリ開発に携わる方は、このエラーを真剣に受け止める価値があります。システムを完全に停止させかねない認証およびセキュリティの問題を示しているからです。

このエラーがどこでどのように現れるかを知っておくことは、迅速なトラブルシューティングに欠かせません。また、何の前触れもなく一夜にして動かなくなり、頭を抱えるような事態も防げます。

70000 Invalid Grant エラー メッセージの構成要素を分解する

AADSTS70000 invalid grant エラーに遭遇したとき、実際にはエラー メッセージの 2 つの重要な部分を見ていることになります。1 つ目は、エラー コードそのもの「AADSTS70000」です。このコードは、Microsoft の認証基盤における OAuth grant の問題を特定するものです。

2 つ目は理由で、通常は「invalid_grant」というラベルや、「grant is invalid or malformed」のようなメッセージで示されます。これは、サーバーがトークン要求を受け入れられなかったことを示しています。原因としては、通常、設定の誤り、セキュリティ ポリシー、または grant の構造に関する問題が考えられます。

Azure のサインイン ログでこのエラーを確認すると、「refresh token expired」や「redirect URI mismatch」といった追加情報が含まれる場合があります。こうしたパターンを認識できるようになると、ユーザーのミス、アプリ登録の問題、より深刻なサービス設定の誤りを素早く切り分けられます。その結果、診断にかかる時間を短縮でき、Microsoft の最も役立つドキュメントやサポート窓口へ直接たどり着けるようになります。

70000 Invalid Grant エラーの原因は何でしょうか？

AADSTS70000 invalid grant エラーが表示される最も一般的な原因を以下に示します。いずれも、OAuth と Azure AD がトークン、セキュリティ、アプリ登録の設定をどのように扱うかに関係しています。

• 不正な形式または期限切れの OAuth grant: 無効または期限切れのアクセス トークンや更新トークンが、主な原因の一つです。トークンが有効期限を過ぎて使用されたり、転送中に改ざんされたりすると、Azure AD はただちにそれを拒否します。
• リダイレクト URI の誤りまたはクライアント設定の不一致: 登録されたリダイレクト URI のわずかな違い（末尾のスラッシュが欠けているだけでも）が、フローを壊す原因になります。Azure AD の設定を更新せずにアプリの詳細を変更することは、よくある原因です。
• 更新トークンの問題: 取り消された更新トークンを再利用しようとしたり、期限切れのトークンや別のクライアント向けに発行されたトークンを使用したりすると、このエラーが発生します。管理者がシークレットをローテーションしたり、パスワードをリセットしたりした結果、意図せずこれらのトークンが無効になることもあります。
• 条件付きアクセスおよび多要素認証（MFA）ポリシーによる中断: フローの途中で MFA やデバイス コンプライアンスのルールが適用されると（特にバックグラウンドで動作するサービス アカウントの場合）、ほとんど説明がないまま grant が拒否されます。これは見落としやすい原因で、経験豊富な専門家でもつまずくことがよくあります。条件付きアクセス ポリシーと信頼に関する問題をさらに詳しく知りたい場合は、ポリシーの穴とベスト プラクティスについてのこちらの解説をご覧ください。
• 同意またはスコープの不一致: アクセス許可が取り消されたり、一部のみ同意されていたり、アプリのスコープが非推奨になったりすると、以前は動作していた連携が突然失敗することがあります。サードパーティ製アプリを統合する管理者や開発者は、必要なアクセス許可と管理者の同意が引き続き有効であるかを必ず再確認してください。Entra ID における OAuth 同意のリスクを詳しく知りたい場合は、こちらのページをご覧ください。

AADSTS70000 Invalid Grant エラーの解決策

1. キャッシュされたトークンを消去して再認証する: トークンやセッションの問題を最も早く解決するには、影響を受けているアカウントやサービスの接続を切断して再接続します。Power Automate、Outlook などのアプリでは、手動でサインアウトしてサインインし直すと、新しい OAuth フローが実行され、無効な付与 (invalid grant) エラーが解消されることがあります。
2. リダイレクト URI を確認して修正する: Azure ポータルに移動し、アプリ登録のリダイレクト URI が、アプリやコネクタが送信している値と完全に一致しているか確認してください。Azure が要求を検証する際、1 文字の違いでも認証全体が失敗する原因になります。
3. アプリの登録とクライアント シークレットを検証する: 最近行ったアプリ登録の変更、シークレットの更新、アクセス許可の変更がすべて最新の状態になっているか確認してください。期限切れや不一致のクライアント シークレットは、継続的な統合を静かに停止させる原因になります。
4. 条件付きアクセス ポリシーと同意を確認する: 条件付きアクセス ポリシーに、過度に広い除外設定やデバイス準拠の不備がないか監査してください。これらは、明確なエラー メッセージが表示されないままフローを停止させることがあります。ユーザーの同意フローを見直し、必要な箇所で管理者の同意が引き続き適用されていることを確認してください。ガバナンス戦略については、こちらの詳しいセキュリティのベスト プラクティス ガイドを参照してください。
5. アクセス許可のスコープを更新する: アプリや自動化処理が要求しているアクセス許可のスコープを再確認してください。スコープは名称が変更されたり、非推奨になったりすることがあり、特に Microsoft Graph で起こりがちです。アプリのコード、ポータルでの登録内容、同意の履歴がすべて一致しているか確認してください。
6. セキュリティ変更後にトークンを強制的に消去する: トークンが漏えいした可能性がある場合や、パスワード ポリシーを更新した直後であれば、Intune または Azure ポータルを使用してすべてのアクティブなセッションを取り消し、全ユーザーと自動化処理に対して再サインインを求めてください。同意ベースの持続的なアクセス攻撃への対策について詳しくは、Entra ID の同意攻撃のリスクと軽減策に関するこちらのガイドをご覧ください。

Power Automate の問題: 無効な付与による認証エラーのトラブルシューティング

1. 影響を受けるデータ接続を再接続または更新する: フローで 70000 エラーが発生している場合は、Power Automate でフローを開き、警告が表示されている接続を見つけて、再接続してください。これにより、サービスは最新の資格情報を使用して新しいトークンを取得します。
2. ユーザーのアクセス許可と資格情報の有効性を確認する: フローに割り当てられているユーザーが、データ ソースに対する適切なアクセス権を持っているか確認してください。フローで使用しているアカウントが無効になっている、パスワードの有効期限が切れている、または MFA の要件が変更されている場合、認証エラーが繰り返し発生します。
3. 必要なアクセス許可のスコープを検証する: 付与されたスコープが、メールの読み取りや送信、ファイルの作成、SharePoint への項目の追加など、フローに必要な内容と一致しているかを再確認してください。Outlook と Teams のコネクタでは特に重要です。
4. DLP ポリシーとコネクタの制限を確認する: コネクタがブロックされていない状態からブロックされた状態に変わったり、管理者によって分類が変更されたりすると、データ損失防止 (DLP) ポリシーによってフローが気付かれないまま停止することがあります。適切な DLP の境界で安定した自動化を構築する方法については、Power Platform 開発者向けのこの DLP ポリシー ガイドをご覧ください。
5. 一時的な障害と持続的な障害を見分ける: 70000 エラーは、短時間の停止やサービスの一時的な不具合が原因の場合もあります。1 回だけエラーが発生し、その後復旧した場合は通常それほど心配する必要はありません。エラーが継続する場合は、テナント全体で接続のアクセス許可と同意のスコープを追跡してください。
6. ガバナンス構成を確認する: 環境や ID のガバナンスに不備があると、認証に関するリスクが時間とともに入り込むことがあります。Power Platform のガバナンスに関するヒントについては、こちらのベスト プラクティスの概要を参照してください。

Azure サインイン 70000: Azure AD ログと監査を使用した診断

1. Azure AD サインイン ログから確認を始める: Azure ポータルのサインイン ログを開き、コード「AADSTS70000」の失敗でフィルターをかけます。失敗の理由、クライアント アプリ、送信元 IP を確認してください。これにより、問題がユーザー、アプリ、構成のいずれに起因するのかを切り分けられます。
2. トークンとクライアントの動作パターンを分析する: 同じユーザー、サービス プリンシパル、またはアプリに関連する繰り返しのエラーを探してください。シークレットのローテーションなど、定期的なイベントの後に「invalid grant」エラーが一貫して発生する場合は、トークン ポリシーの不整合や、期限切れの更新トークンが原因であることが多いです。
3. Azure AD 監査ログで全体像を把握する: サインインの失敗と Azure AD 監査ログを組み合わせて確認してください。これにより、アプリ登録の変更、条件付きアクセス ポリシーの更新、一括トークン取り消しの可能性が明らかになります。エラーが発生し始める直前の変更を特定できれば、根本原因にたどり着けることがあります。
4. 高度な監査ツールを活用する: Microsoft 365 全体を対象とする広範な調査には、Microsoft Purview Audit のようなツールが役立ちます。長期間の保持と詳細な分析シグナルを提供するため、フォレンジック分析に有効です。これらのツールの設定と使用方法については、こちらの Purview Audit の概要をご覧ください。
5. 長期的な安定性のためにガバナンスを強化する: 適切なガバナンスは、時間の経過とともに発生するサイレントな障害やポリシーの累積的なずれを防ぐのに役立ちます。Azure Policy でガードレールを適用し、例外を監視してください。包括的な戦略については、Azure エンタープライズ ガバナンス ガイドを参照してください。

時刻同期とクロック スキュー: OAuth の invalid grant エラーの隠れた原因

AADSTS70000 の invalid grant エラーの原因として見落とされがちなのが、システム時刻のずれ、いわゆるクロック スキューです。クライアント マシンと Microsoft のサーバーの時刻が一致しないと、OAuth トークンや認可コードが、他がすべて正しくても、期限切れまたはまだ有効ではないと判断されることがあります。

この問題は、システムごとにクロックがわずかにずれている仮想化環境やクラウド環境で特に厄介です。ネットワークの遅延やデバイスのスリープ モードによって問題が悪化し、有効な認証要求が原因不明のまま失敗することがあります。

対策は、信頼性の高い NTP サーバーとすべてのデバイスを定期的に同期することです。ドメイン コントローラー、仮想マシン、エンドユーザーのデバイスで自動的な時刻補正を設定してください。「実際の時刻」との差を 1 分か 2 分以内に保つことは、原因不明の付与失敗を防ぐうえで非常に有効です。適応型制御を含め、Microsoft 365 と Dynamics のセキュリティに対する先回りのアプローチ全般については、こちらの Zero Trust by Design のポッドキャストをご覧ください。