日々の仕事やプライベートでMicrosoftアカウントを活用していると、急にサインイン時にエラーが出て困ってしまうことがあります。とくに「AADSTS900561: The endpoint only accepts POST requests. Received a GET request.」というエラーは初めて見ると戸惑いますが、正しい対処をすれば解決可能です。ここでは、原因や対処策を包括的にご紹介します。
AADSTS900561エラーの概要
「AADSTS900561: The endpoint only accepts POST requests. Received a GET request.」というエラーは、Azure Active Directory（Azure AD）の認証エンドポイントへアクセスする際に、本来POSTで送られるべきリクエストがGETとして送信されているときに表示されます。具体的には下記のような状況で発生することが多いとされています。
- ブラウザー（Safari、Microsoft Edgeなど）でMicrosoftアカウントにサインインしようとした
- Xbox One CloudなどのアプリケーションでMicrosoftアカウント認証を試みた
- 企業や学校のオンプレミス環境とAzureのハイブリッド構成を組んでいる
- リダイレクト設定やリンクの不備によってリクエストが正常に送信されていない
以上のように環境依存要素が多いエラーですが、原因をしっかり把握すれば解決が可能です。
発生しうる主な原因
このエラーが発生する要因は複数考えられます。ブラウザー側の問題から環境設定の問題まで、幅広く見ていくことが重要です。
1. ブラウザーやアプリケーション側のリクエスト不備
POSTリクエストを送信すべきところで、なぜかGETリクエストが発生しているケースです。次のような状況が考えられます。
- リダイレクトURLが間違っている
- JavaScriptやブラウザー拡張機能の影響でリクエスト方法が書き換わっている
- Cookieやキャッシュに古い情報が残っており、正しいリクエストが送信されていない
これらが原因の場合、ブラウザーのCookieやキャッシュクリア、拡張機能の無効化などが有効策となります。
2. 認証ポリシー・Azure AD設定の問題
企業アカウント（Microsoft 365 Business/Enterprise）や学校アカウントを利用している場合、IT管理者が設定している認証ポリシーやAzure AD側のリダイレクトURIの設定に食い違いがあると、正しい認証フローが実行されません。さらに、オンプレミスExchangeやハイブリッド構成を組んでいる場合には、リクエスト形式の整合性が保たれずにエラーが起こることがあります。
3. 信頼済みサイトやプライバシー例外リストの未設定
会社や自宅のネットワーク環境で、ブラウザーやWindows OSのインターネットオプションにて「信頼済みサイト」リストを適切に設定していない場合、通信がブロックされてPOSTリクエストがGETとして認識される、あるいは認証フローそのものが停止される可能性もあります。
エラー解消への具体的な手順
ここからは、実際にエラーを解消するための代表的な対処方法をより詳しく解説します。単なる一般論に留まらず、一歩踏み込んだ内容を含めてご紹介しますので、ぜひ参考にしてみてください。
1. ブラウザーのキャッシュ・Cookie・拡張機能のクリア
まずはもっとも基本的な対処法として、ブラウザーのキャッシュやCookie、拡張機能を一旦無効にしてみましょう。下記の手順を例に示します。
| ステップ | 操作内容 | ポイント |
|---|---|---|
| 1 | ブラウザーの設定画面を開く | Edgeなら「…」→「設定」、Chromeなら「⋮」→「設定」 |
| 2 | 「プライバシーとセキュリティ」または「セキュリティ」関連の項目を選択 | ブラウザーごとに名称が異なる |
| 3 | 「閲覧履歴データを削除」「Cookieと他のサイトデータを削除」などを実行 | 期間設定は「すべて」もしくは十分に古い期間を指定 |
| 4 | 再度Microsoftアカウントにログインを試みる | 拡張機能は全て無効にして再度試行 |
これでエラーが解消することが少なくありません。また、プライベートブラウズモード（シークレットモード）で同じ操作を行うのもおすすめです。
2. 信頼済みサイト・プライバシー例外リストへの追加
特定のドメインがブロックされていると、正しいリクエストが遮断されるケースがあります。Windowsのインターネットオプションやブラウザー設定から、以下の手順で「信頼済みサイト」にMicrosoftのログインURLを追加してみましょう。
- Windowsの「ファイル名を指定して実行」から
inetcpl.cplを実行し、インターネットオプションを開く - 「セキュリティ」タブ→「信頼済みサイト」→「サイト(S)」をクリック
https://login.microsoftonline.comやhttps://login.live.comなどを追加- ブラウザーを再起動して再度ログインを試す
EdgeやChromeなどでは、同様に「Cookieとサイトの権限」や「プライバシーとセキュリティ」の項目から該当ドメインを許可リストに追加すると効果がある場合があります。
3. Azure AD・Exchange環境の再確認
もし組織のアカウントを利用していて、オンプレミス環境とクラウド環境をハイブリッド構成している場合は、管理者やIT部門に問い合わせて以下の点を確認しましょう。
- Azure ADのリダイレクトURIやエンドポイントの設定
- Exchangeハイブリッド構成の認証方式（OAuth設定など）の整合性
- アプリ登録（App Registration）の設定が最新かどうか
設定の小さなずれによってPOST/GETの混乱が起こるケースがあります。特にアプリやサービスが複数連携している場合、どこか1つの構成ミスが原因で全体的に認証エラーが発生します。
エラーの根本メカニズムを理解する
ここでは少し踏み込んで、「なぜPOSTリクエストでなければならないのか」について解説します。
REST APIの原則
多くのWebサービスではRESTfulなAPI設計に従っています。認証系のエンドポイントは安全な通信と明確な状態変更を伴うため、POSTメソッドを使用して機密情報を保護しながらリクエストすることが一般的です。一方GETはURLにパラメータを付与して情報を取得する仕組みであるため、機密情報がURL上で露出してしまう危険性があります。
Azure AD認証フロー
Azure ADが用意しているOAuth 2.0やOpenID Connectのフローでは、アクセストークンやリフレッシュトークンなどの機密情報をやり取りするため、POSTメソッドが前提になっているケースがほとんどです。もしGETメソッドが混じると、以下のような問題が発生します。
- URL上にトークンなどの情報が漏れる危険
- セキュリティポリシーでGETをブロックしている場合に弾かれる
- リダイレクト経路が正しく設定されていない場合に想定外のフローになる
サンプルコード：リクエストメソッドの確認
もし自作のアプリケーションでAzure AD認証を実装している場合は、以下のようにメソッドを明示的にPOSTに指定しているか確認しましょう（JavaScript例）。
// Azure AD認証用のエンドポイントにPOSTでリクエストする
fetch('https://login.microsoftonline.com/xxxxx/oauth2/v2.0/token', {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
body: new URLSearchParams({
client_id: 'YOUR_CLIENT_ID',
scope: 'openid profile offline_access',
client_secret: 'YOUR_CLIENT_SECRET',
grant_type: 'client_credentials'
})
})
.then(response => response.json())
.then(data => {
console.log('Access Token:', data.access_token);
})
.catch(error => console.error(error));
上記のように、必ずmethod: 'POST'とbodyを正しく指定することで、GETリクエストの誤送を防ぎます。
ネットワーク観点での追加対策
1. プロキシやVPNの影響確認
企業のネットワークを使用しているとき、プロキシサーバーやVPNを介してアクセスしている可能性があります。これらが誤ってリクエストを再書き換えしている、あるいは一部のドメインをブロックしていることがあり得ます。ネットワーク管理者に「指定したURLに対してPOST通信が許可されているか」を確認しましょう。
2. ネットワークログの採取
問題が長引く場合は、Fiddlerやブラウザーの開発者ツール（DevTools）を使って実際のHTTPリクエストをキャプチャすると、GETとPOSTのどちらが送られているかが明確に分かります。下記はEdgeでの例です。
- Edgeを開き、「…」→「その他ツール」→「開発者ツール」を選択
- 「Network」タブを開き、Microsoftアカウントサインインページにアクセス
- リクエストのMethod欄がPOSTかGETかを確認
もし実際の通信がGETになっている場合、アプリやブラウザーの設定などを重点的に確認します。
トラブルシューティングのまとめ
- まずはブラウザーのキャッシュ・Cookie・拡張機能を疑う
- 信頼済みサイト・プライバシー例外リストにMicrosoft関連ドメインを追加
- Azure ADやオンプレミスとのハイブリッド構成を確認（管理者に問い合わせ）
- ネットワーク環境（プロキシ・VPN）やセキュリティ製品の設定をチェック
- 開発者ツール等で実際のリクエスト方式を検証
ケーススタディ：具体例を用いた解決アプローチ
ケース1：SafariとMac環境でエラーが出る
- Safariの「プライベートリレー」機能をオフにしてみる。
- Safariの環境設定→「プライバシー」からCookieやWebサイトデータを削除。
- それでも解決しない場合は別のブラウザー（Chromeなど）で試し、問題が再現するかを確認。
多くの場合、プライベートリレーや特定の拡張機能がリクエストを変換している可能性があります。
ケース2：Xbox One Cloudでログイン時にエラーが出る
- Xboxのネットワーク設定を確認し、DNSやプロキシが正常に機能しているかチェック。
- システムアップデートを最新にし、キャッシュをクリアして再起動。
- Microsoftアカウント情報の再入力を試みる。
コンソール機器の場合、システムやゲームが自動的に認証情報を管理していることが多いため、アップデートや再設定によって解消できるケースがあります。
ケース3：企業環境（Hybrid Exchange + Azure AD）で発生
- IT管理者がAzure ADおよびオンプレExchangeのハイブリッド設定を見直す。
- Enterprise Applications（旧Azure ADアプリケーション登録）やリダイレクトURI設定をチェック。
- 認証ポリシーやConditional Accessのルールを再確認。
エンタープライズ環境では様々なセキュリティルールが絡むため、管理者を通じた設定確認が必須です。
さらに深堀りするための補足
Microsoft 365管理センターやAzure Portalの活用
もし管理者権限を持っている場合は、Microsoft 365管理センターやAzure Portalから「診断とトラブルシューティング」の機能を試してみましょう。最近ではポータル上で問題の種類を選択すると、自動的に考えられる原因と対策を提示してくれる仕組みがあります。
ログとエラーIDの活用
エラーが発生した際のRequest IdやCorrelation Id、発生時刻を控えておくことで、MicrosoftサポートやIT管理者に問い合わせる際に迅速な対応が可能となります。特に企業アカウントの場合、サポートに依頼する際はこれらのIDと共に、問題再現手順を詳細に伝えるとスムーズです。
外部連携アプリの確認
SharePointやTeams、その他のSaaSアプリと認証連携している場合、アプリ登録情報（特にリダイレクトURL）が古い状態のまま残っていると、誤ったGETリクエストを誘発することがあります。定期的にアプリ登録や権限の棚卸しを行うことで、安全かつ正しい認証フローを保つことができます。
まとめ
「AADSTS900561: The endpoint only accepts POST requests. Received a GET request.」というエラーは、ブラウザーやアプリケーションからAzure ADに対して送られる認証リクエストがPOSTではなくGETになっていることが原因です。
最初はややこしく感じるかもしれませんが、キャッシュやCookieのクリア、信頼済みサイトの追加、VPNやプロキシの影響排除など、基本的な対処で解決できるケースが多々あります。もし企業や学校の組織アカウントを利用しているのであれば、ハイブリッド構成やAzure ADアプリ登録設定、セキュリティポリシーなどをIT管理者に確認してもらいましょう。
日頃からエラーが発生しても慌てず、エラーメッセージやリクエストの内容を正しく確認し、適切な対処をすることでMicrosoftアカウントとのスムーズな連携が期待できます。あなたの作業効率やゲームライフを維持するためにも、今回の解決策を参考にエラーを撃退してみてください。
コメント