Azure AD アプリで発生する AADSTS700054（Response Type Not Enabled）の問題を解決する

By Mirko Peters · 2026-04-21

AADSTS700054 のエラーに遭遇して、「今度は何を間違えたんだろう？」と思ったことはありませんか。このエラーは、Azure Active Directory を使ってアプリの認証を行おうとしたタイミングで表示されることで知られており、決してあなただけではありません。Microsoft 365、Dynamics 365、または独自のシングルページアプリを使う場合によく発生します。根本的な原因は、認可エンドポイントに対して要求された「応答の種類（response type）」、つまり ID トークンやアクセス トークンを受け取るように、アプリが設定されていないことです。

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

AADSTS700054 のエラーに遭遇して、「今度は何を間違えたんだろう？」と思ったことはありませんか。このエラーは、Azure Active Directory を使ってアプリの認証を行おうとしたタイミングで表示されることで知られており、決してあなただけではありません。特に Microsoft 365、Dynamics 365、または独自のシングルページアプリで発生しやすいエラーです。根本的な原因は、認可エンドポイントに要求された「応答の種類（response type）」、たとえば ID トークンやアクセス トークンを受け取れるようにアプリが設定されていないことにあります。

本ガイドでは、このエラーが発生する理由を整理し、従来の暗黙的付与（implicit grant）ベースのアプリと、MSAL.js と PKCE を使用する最新の構成の両方について解決方法を説明します。あわせて、構成を安全に保つためのベストプラクティスや、コミュニティのリソース、ブログ内で答えを素早く見つけるためのナビゲームのヒントも紹介します。レガシーアプリでも最新アプリでも、この一般的な認証のトラブルを解決し、再発を防ぐ方法がわかるようになるはずです。

AADSTS700054 が発生する原因の理解

AADSTS700054 エラーは、単なる分かりにくいコードではありません。簡単に言えば、Azure から「アプリに許可されていない要求が来ている」と伝えられている状態です。多くの場合、問題は応答の種類（response type）に関係しています。アプリが Azure AD にトークンを要求しても、その「フロー」（暗黙的付与など）が構成されていない場合、Azure は要求をブロックし、このエラーを返します。

なぜこのエラーが発生するのでしょうか。多くの場合、アプリの登録で、認可エンドポイントに対する ID トークンやアクセス トークン、あるいはその両方の設定が不足していることが原因です。たとえば、Azure AD で有効になっていない暗黙的フローを使ってトークンを取得しようとするシングルページアプリケーション（SPA）を想像してください。Azure は要求内容と許可された設定の不一致を検出し、AADSTS700054 を返します。

レガシーな認証方式から最新のベストプラクティスへ移行する際に、設定ミスが起きやすくなります。古いアプリ（今も暗黙的付与を使っている可能性があるもの）と、新しいアプリ（PKCE と認可コードフローを使うべきもの）の両方をサポートしている組織は、特にリスクが高くなります。クラウド認証の更新や新しい Microsoft サービスとの統合を行う場合も、このエラーに遭遇する可能性は高まります。

このエラーを理解すると、コードが要求している内容と Azure アプリの設定内容の対応関係が見えてきます。本ガイドの以降のセクションでは、アプリケーションのトークン要求を Microsoft Identity Platform の想定に合わせる方法を説明します。トラブルシューティングで一歩先を行けるようになるはずです。

暗黙的付与の応答の種類に関する問題の推奨解決策の有効化

AADSTS700054 によって統合がブロックされている場合、最も手早い対処法は、通常、アプリの登録で適切な応答の種類を構成することです。多くの場合、暗黙的付与の設定を有効にすることを意味します。つまり、認可エンドポイントから直接トークンを要求できるように、アプリに許可を与えることです。

Azure portal での手順は次のとおりです。まず「アプリの登録」に移動し、対象のアプリケーションを見つけて、「認証」セクションを開きます。「暗黙的な付与とハイブリッド フロー」の領域を探してください。そこに「アクセス トークン」と「ID トークン」のチェックボックスが表示されます。シナリオに応じて適切なものをオンにします。通常、SPA には少なくとも「ID トークン」が必要で、古いアプリでは両方が必要になる場合があります。

ただし、すべてをオンにして様子を見るのは避けてください。セキュリティを最優先に考え、アプリが実際に必要とするオプションだけを有効にしてください。ほとんどのブラウザーベースのアプリのように、認可エンドポイント経由でトークンを要求している場合は、これらの設定が必要です。一方、PKCE などのより安全なフローへ移行しているアプリでは、暗黙的付与の設定に触れる必要がない場合もあります。

これらの変更を適用すると、ほとんどの AADSTS700054 の問題はすぐに解消されます。それでも解決しない場合は、アプリのアクセス許可のスコープ、リダイレクト URI を再確認し、変更がテナント全体に完全に反映されているかも確認してください。これがこのエラーに対処する基本であり、ユーザーと開発者が業務に戻れるようにするための土台です。

応答の種類の設定ミスを防ぐためのベストセキュリティプラクティス

暗黙的な付与の設定を変更するとエラーは解消できますが、長期的に見て最も安全な方法とは限りません。暗黙的フローを有効にすると、トークンがブラウザーの応答で直接返されるため、傍受されやすくなり、セキュリティリスクが高まります。そのため、Microsoft をはじめ、セキュリティを重視する管理者の多くは、特に新規または更新する SPA では、ほとんどのシナリオで PKCE を使用した認可コードフロー などの最新の代替手段を使用することを推奨しています。

では、暗黙的な付与をいつ有効にすべきでしょうか。結論として、レガシーアプリや、どうしても必要となる特殊なケースがある場合に限られます。それ以外のすべてのアプリでは、(PKCE を使用して)認可コードフローを使用するように設定してください。これにより、トークンがブラウザーのアドレスバーに露出しなくなり、攻撃対象領域を大幅に減らせます。

Power Platform、Microsoft 365、Dynamics 365 を組み合わせて利用している組織では、これらのベストプラクティスを軽視する余裕はありません。応答の種類を誤って構成すると、サインインが失敗するだけでなく、攻撃者に侵入経路を与えたり、後にコンプライアンス上の問題を引き起こしたりする可能性があります。Power Platform のセキュリティとガバナンスに関するこの概要では、特にシチズン開発者がカスタムアプリや統合を追加する場合に、厳格な制御と採用するフローの理解がなぜ重要なのかが説明されています。

要点は次のとおりです。必要なものだけを有効にし、可能な場合は PKCE を使用したコードフローを優先し、アプリの登録をガバナンス戦略全体の一部として厳格に管理してください。すべての設定が、適用したいセキュリティポリシーと整合していることを確認しましょう。将来の自分や監査担当者もきっと感謝するはずです。

MSAL.js を使用した最新アプリでの AADSTS700054 のトラブルシューティング

MSAL.js v2 以降や PKCE などの最新の認証ライブラリに移行すれば、AADSTS700054 のような「昔ながら」のエラーとは無縁になる、と思われるかもしれません。しかし、そう簡単ではありません。最新のシングルページアプリケーションであっても、アプリの登録やクライアント側の構成が現在のベストプラクティスと一致していないと、問題が発生することがあります。

最も多い原因は、古い前提です。開発者は MSAL.js を導入したものの、従来のリダイレクト URI をそのまま使用していたり、Azure AD で有効になっていない id_token などの応答の種類を誤って要求していたりすることがあります。特に、アプリのマニフェストを別のプロジェクトからコピーして貼り付けた場合に起こりがちです。その結果、アプリが認証フローを開始した際に、Azure AD からあの厄介なエラーが返されます。

デバッグはどのように行えばよいのでしょうか。ブラウザーの開発者ツールを開き、[ネットワーク] タブで認可要求を確認してください。response_type が、Azure アプリで実際に受け入れるように構成されているフローと一致しているかを二重に確認します。適切に有効化されていないトークンの要求が見つかった場合は、Azure portal に戻り、アプリの登録を調整してください。

覚えておいてください。MSAL.js v2 と PKCE を使用する場合、通常は暗黙的フローを有効にする必要はまったくありません。それでもアプリが失敗する場合は、ハードコードされた「implicit」設定、リダイレクト URI のタイプミス、誤った付与の種類がないかを確認してください。Azure 側とクライアント側の両方で構成を慎重に確認すれば、ほとんどの問題は解決します。地味な作業ではありますが、的確なトラブルシューティングは、推測に費やす何時間もの時間を節約してくれます。

レガシーアプリケーションを暗黙的な付与から PKCE へ移行する

暗黙的フローを完全に卒業する準備はできていますか。それは賢明な判断です。PKCE (Proof Key for Code Exchange) への移行は、現在の標準であり、Microsoft も強く推奨しています。ただし、正直に言えば、利用者がいる稼働中のアプリの移行は、単に設定を切り替えるだけでは済みません。ダウンタイムを避け、サインインの妨げを最小限に抑え、関係者全員に情報を共有する計画が必要です。

最初のステップは、暗黙的な付与を使用しているすべてのアプリの登録を評価し、一覧化することです。次に、ステージング環境で新しい PKCE ベースのフローをテストします。具体的には、アプリを認可コードフローを使用するように設定し、リダイレクト URI を更新し、クライアント側の構成ファイル (MSAL.js や ADAL.js の置き換えなど) を調整します。サインイン、サインアウト、トークンの更新の一連の流れを最後まで確認してください。すべてのユーザー種別で動作することも確かめましょう。

本番環境で切り替える前に、ロールバック計画を用意してください。移行がうまくいかない場合に備えて、一時的に両方のフローを有効にしておく必要があるかもしれません。また、利用者には明確に伝えてください。利用者は予告のない変更を好みません。特に、サインインの方法が予告なく変わったために業務が止まってしまう場合は、なおさらです。

最後に、移行後にトークン更新の失敗やアクティブなセッションの中断が起きていないか確認してください。可能であれば、アップグレードは利用者が少ない時間帯に計画しましょう。こうした移行の運用についてさらに知りたい場合は、直接的な資料ではありませんが、最新の Microsoft 365 Copilot やアーキテクチャのポッドキャストで、企業の変更管理に関するヒントが得られることがあります（最近のディスカッションはこちら）。

信頼性の高い解決策を得るために、Nishant Weblog Rana’s のような信頼できるブログを見つける

• Nishant Rana’s Weblog： Azure AD の統合の問題を解決するための定番の情報源です。詳細な解説、手順に沿った修正方法、Dynamics 365 や Power Platform の特殊なケースまで扱っています。わかりやすい解説により、厄介な認証エラーへの対応も、ずっと取り組みやすくなります。
• KingswaySoft MVP Blog： CRM データ統合に関する実践的なアドバイスで知られる、MVP が執筆するブログです。認証の特殊なケースを定期的に取り上げており、Azure AD と Microsoft 365 のエコシステムを扱う方にとって欠かせない情報源です。
• Top 100 CRM Blogs： このようなキュレーションされたリストは、Microsoft の ID、セキュリティ、トラブルシューティングについて定期的に執筆している、より広い技術コミュニティの書き手を見つける助けになります。読むブログの範囲を広げるほど、自分の特殊なケースに合った解決策に出会える可能性が高まります。

クイック検索とアーカイブを使って、Azure AD の問題に関する最新の投稿を探す

• クイック検索機能を使う： 信頼できる技術ブログのほとんどには検索バーがあります。ぜひ使ってください。「AADSTS700054」「Azure AD error」「implicit grant」などと入力すると、問題に直接関係する投稿やガイドがすぐに表示されます。手作業で探すよりずっと速く見つかります。
• アーカイブと最新情報を確認する： 検索で問題が見つからない場合は、サイトのアーカイブや「最新の投稿」の絞り込みリストを確認してください。実績のあるトラブルシューティングガイドは古い投稿に埋もれていることが多く、最近の投稿が、Microsoft のプラットフォームにおける新しい認証の変更に対する正確な対処法を示している場合もあります。
• 上級者向けに絞り込みを組み合わせる： さらに使いこなしたい場合は、検索とタグやカテゴリを組み合わせてください。「Azure AD」の投稿だけに絞り込んだり、「app registration」で範囲を狭めたりすると、トラブルシューティングの時間を大幅に短縮でき、見落としていた問題や解決策にも出会えます。