AADSTS900561: エンドポイントは POST のみを受け付けるエラー

By Mirko Peters · 2026-04-22 · Updated 2026-07-28

AADSTS900561 のエラー「エンドポイントは POST のみを受け付けます」の意味、Microsoft Entra サインイン中に発生する理由、そして安全なトラブルシューティングの方法を解説します。

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

クイックアンサー: AADSTS900561「エンドポイントは POST のみを受け付けます」は、Microsoft Entra の認証エンドポイントが、サポートされていないメソッドを使ったリクエストを受け取ったことを意味します。テナント全体の ID 設定を何度も変更するのではなく、アプリケーションのサインインフロー、リダイレクトの処理、開いている URL を確認してください。

Microsoft Entra ID や Azure Active Directory で作業中に AADSTS900561 エラーに遭遇したことはありますか。「Endpoint only accepts POST requests」と表示されるエラーです。平たく言えば、アプリが GET リクエストで Microsoft の認証サービスに接続しようとしたものの、サーバーは POST を求めている、ということです。本来は正面玄関から入るべきところを、裏口をノックしてしまった状態に近いと言えます。

このエラーは、Microsoft 365、Azure、Power Platform 向けのアプリを開発または連携させる際によく発生します。通常はサインインフローの途中や、Microsoft の ID プラットフォームからトークンを取得しようとした際に現れます。AADSTS900561 の発生原因を理解することは重要です。認証呼び出しのどこが Microsoft の技術要件と合っていないのかを、直接示してくれるからです。次に、このエラーがなぜ発生するのかを詳しく見ていき、よく知られたエラーコード AADSTS90056 とのつながりを説明します。

AADSTS90056 と AADSTS900561 のエラーの概要と背景

AADSTS900561 の問題に取り組む前に、対象を正確に把握しておくと役立ちます。AADSTS90056 と AADSTS900561 はいずれも、アプリが認証エンドポイントとやり取りする際に問題がある場合に Microsoft Entra ID（旧 Azure AD）が返すエラーコードです。要点は次のとおりです。AADSTS90056 は通常、認証パラメーターの不備や欠落を示します。一方、AADSTS900561 は HTTP メソッドの問題に特化しており、具体的には POST が必要な場面で GET を使用した場合に発生します。

Microsoft Entra ID は、トークン交換や認証フローに対して厳格なプロトコルルールを適用しており、多くの場合 OAuth 2.0 に基づいています。アプリが /token エンドポイントにアクセスしてトークンを取得する際、Microsoft は POST リクエストの送信を求めます。これは単に規則にうるさいからではありません。POST では機密データを URL ではなくリクエストの本文に含めて安全に送信できるため、情報漏えいや誤ったログ記録のリスクを抑えられます。

一方、GET リクエストは内容が丸見えの状態です。詳細情報が URL に含まれるため、経路上のだれでも、あるいはどのプロキシでも閲覧できてしまいます。特に ID と機密データを管理するエンタープライズ向けサービスでは、これは重大なセキュリティ上の問題です。そのため Microsoft の ID プラットフォームは、シークレット、コード、ユーザー情報のやり取りを伴うあらゆる操作に対して POST を強制しています。GET を送信すると、プラットフォームがそれを検出し、AADSTS900561 エラーで処理を止めます。この技術的背景を理解しておくと、何が間違っていたのかだけでなく、なぜこの規則が存在し、Microsoft のクラウドサービス全体で例外なく適用されるのかが分かるようになります。

要するに、これらのコードのいずれかが認証中に表示された場合、アプリが規則に沿わないリクエストを送信しているということです。これらのエラーコードの背後にあるセキュリティと、信頼性の高いプロトコルフローの考え方を押さえておけば、何を修正すべきか、そしてそれがなぜ重要なのかを、業務用のアプリ環境の中でより明確に把握できるはずです。

AADSTS900561 認証の問題の主な原因と対処方法

AADSTS900561 が表示されている場合、アプリが Microsoft のトークンエンドポイントへ接続する方法に誤りがあると考えて、ほぼ間違いありません。代表的な原因の一つは、アプリケーション登録の設定ミスや、Azure AD 内のリダイレクト URI の誤りです。登録されたリダイレクト URI が実際にアプリで使用されているものと一致していない場合、または必要な情報が欠けている場合、意図せず期待される POST ではなく GET リクエストが発生してしまうことがあります。

もう一つのよくある取り違えは、認証フロー自体の実装です。特に、リクエストを手動で組み立てようとしている場合や、使用しているライブラリを誤って理解している場合に、/token エンドポイントを呼び出す際に GET を使ってしまう開発者がいます。Microsoft Entra を使った OAuth 2.0 では、最終的なトークン取得は必ず POST で送信し、GET は使用してはいけません。この段階でワークフローが GET を送信していると、AADSTS900561 エラーがすぐに表示されます。

では、どう修正すればよいのでしょうか。まず、Azure ポータルのアプリ登録と、アプリのローカル構成の両方でリダイレクト URI を再確認してください。プロトコル（http または https）やパスまで含めて、完全に一致していることを確認します。MSAL や ADAL ライブラリを使用している場合は、古いバージョンを使っていないか、既定の POST の動作を上書きするコードを書いていないかを確認してください。独自の認証コードを使っている場合は、HTTP 呼び出しを調べ、トークン エンドポイントに対して必ず POST リクエストが送られていることを確かめてください。

コードでお困りですか。簡単なヒントをお伝えします。fetch や axios を使う JavaScript では、/token への呼び出しが method: 'POST' のような形になっているか確認してください。ログやブラウザに「endpoint only accepts post」と表示される場合は、認可から トークン交換 までの間にコードが行う各処理を見直すタイミングです。特に、アプリがフロントエンドとバックエンドの処理を切り替えている場合は注意が必要です。ID に起因するリスクと実際のガバナンス上の対策について詳しく知りたい場合は、Azure セキュリティにおけるコントロール プレーンとしての ID を扱ったこのエピソードをご覧ください。

AADSTS900561 エラーのデバッグとベスト プラクティス

このエラーを突き止め、再発させないための方法を見ていきましょう。React、Vue、Angular で単一ページ アプリケーション (SPA) を動かしている場合は、ブラウザの開発者ツールを開いてください。[ネットワーク] タブを選択してログイン フローを実行し、/token エンドポイントに対する GET リクエストがないか注意深く確認します。それが見つかれば、原因を特定できています。

この問題は、認証ライブラリの設定が正しくないことが原因の場合もあります。たとえば MSAL.js では、acquireTokenSilent を使うべき場面で loginRedirect を使っていたり、ライブラリの構成を誤っていたりすると、POST ではなく GET が送信されることがあります。MSAL.js を最新バージョンに更新し、初期化設定を再確認するだけで、多くの手間を省けます。フレームワークには細かい要件がありますが、トークン リクエストには POST が必要であることは、Microsoft のドキュメントに明記されています。

Azure のログも見逃さないでください。詳細なリクエスト トレースについては、Azure AD のサインイン ログを確認しましょう。呼び出されたエンドポイント、使用されたメソッド、プロトコルの不一致を示すフラグなどを確認できます。詳細な診断が必要な場合、Fiddler を使えば HTTP トラフィックを 1 行ずつ分析できますし、Application Insights を使えば呼び出しスタックを問題の箇所まで対応付けられます。

事前の対策は、問題が起きてから後始末をするよりも効果的です。認証フローは、本番環境に展開する前に、必ず開発環境とステージング環境でテストしてください。認可コードをトークンと交換するコードは、OAuth 2.0 の仕様どおり、必ずサーバー側で POST を使って実行されるようにしてください。ブラウザー内でコードを交換するのは、AADSTS900561 を招き、セキュリティ上の穴を開けてしまう典型的な方法です。

Microsoft 365 や Azure の大規模な環境で作業している場合は、ガバナンスの進め方を見直してください。Entra ID は重要なアクセスの多くを支えているため、ポリシーを厳格に保ち、コードが Microsoft のベスト プラクティスに従っていれば、運用はずっと楽になります。見落としが生じないガバナンスの設計については、Azure エンタープライズ ガバナンス戦略のエピソードがおすすめです。

アプリが Power Platform の一部である場合、またはコネクタを使っているだけの場合でも、ID とコネクタを慎重に管理し、アーキテクチャのずれや予期しないアクセス許可エラーを防いでください。実践的なガイダンスは、こちらのリソースで確認できます。Power Platform のセキュリティとガバナンスのベスト プラクティス

要点をまとめると、認証フローを把握し、すべてのリクエストを検証し、ツールを最新の状態に保つことです。万一エラーが発生しても、どこを確認すべきか、どう根本から解消すればよいかが分かるはずです。

実践チェックリスト

• 実際のユーザーへの影響と影響範囲を確認します。
• 安全性を確保できる最も限定的な構成やコミュニケーションの方法を選びます。
• 広く展開する前に、ユーザー エクスペリエンスをテストします。
• 担当者、後続の対応事項、確認のポイントを文書化します。

よくある質問

最初に行うべき最善の手順は何ですか。

ユーザーのシナリオと必要な具体的な結果を明確にします。これにより、不要な変更を防ぎ、より分かりやすく信頼性の高い実装につながります。

🎧 あわせて聴きたいエピソード

• Identity Governance in Entraは、ID管理を取り巻くガバナンスの全体像を把握するための資料です。
• Microsoft Entra Private Access – Simply Explainedでは、最新のID・アクセスアーキテクチャについて解説しています。
• Privileged Identity Management (PIM) – Simply Explainedでは、Entra管理者向けに特権アクセスの観点を補足しています。

最終レビュー日：2026年7月。