Outlook.comにログインしようとした時に「AADSTS900561: The endpoint only accepts POST requests. Received a GET request.」が表示された場合は、通常のサインイン入口からやり直し、同じ操作で再現するかを確認します。この記事はOutlookなどを利用する側のブラウザー確認、変更の戻し方、問い合わせへ渡す情報を説明します。自作アプリの認証コードを調べる場合は、要求先とGET／POSTを確認する開発者向け手順を参照してください。
OutlookでAADSTS900561が出た時の確認順
- 途中の認証URLや戻る操作を繰り返さず、通常のサービス入口を開き直す。
- Outlook.comか、職場・学校のOutlookか、社内ポータル経由かを記録する。
- 同じアカウントと入口を別のブラウザー環境で試し、正常な場合との違いを記録する。
- 一つの環境だけなら対象サイトのCookieや拡張機能を個別に確認する。
- 改善しない場合は、エラー全文・日時・ID・試した結果をサービス担当者へ渡す。
Microsoftの公式エラー一覧では、AADSTS900561は要求先が受け付けるHTTPメソッドとの不一致を示し、開発者の誤りやブラウザーの「戻る」で不正な要求が起きる場合を挙げています。エラーだけからCookie、VPN、Azure側の設定を原因と確定することはできません。
AADSTS900561エラーとは
AADSTS900561はMicrosoft Entra ID（旧Azure AD）の認証・認可エラー一覧にあるコードです。「only accepts POST」「Received a GET」は、POSTを受け付けるアクセス先にGETが届いたことを示します。認証フローには正常にGETを使う区間もあるため、利用者がすべての通信をPOSTへ変える必要はありません。
Outlook.comを利用するだけの場合は、まず直前に戻る操作や途中のURLの再表示をしたかを確認します。通常の入口からやり直して成功すれば、その結果を記録します。毎回同じ場所で失敗する場合は、ブラウザーに依存するか、サービス側の調査が必要かを分けて確認してください。
エラー内容の背景
一つのエラー表示から、履歴や全Cookieの削除、保護機能の例外追加をまとめて実施しないでください。何を変えて結果が変わったか分からなくなるため、通常の入口の再試行と別環境との比較から始めます。
自作アプリや社内ポータルで同じ箇所の失敗が続く場合、利用者のOutlook設定だけでは直せない可能性があります。管理者へ入口と直前の操作を渡し、実際に失敗した要求を確認してもらいます。
社内ネットワークだけで発生する場合の比較
組織が許可する回線と端末で、同じサービス・アカウント・入口を使った結果を比較します。社内だけで発生しても、プロキシがPOSTをGETへ書き換えたとはエラー文だけで断定できません。管理者に回線、ブラウザー、時刻を伝えてログを確認してもらいます。
考えられる原因と対策
ここでは、原因を決めつけず再現条件を絞る確認方法を紹介します。変更前の状態と結果を記録し、一度に複数の設定を変えないでください。
ブラウザ拡張機能の影響をチェック
拡張機能が関係するかは、同じ入口で状態を一つずつ比較します。広告ブロックやトラッキング防止という分類だけで原因を断定せず、機能名・有効状態・結果を記録してください。
InPrivateで比較し、許可された拡張機能も確認する
Edgeでは［…］→［新しいInPrivateウィンドウ］から同じ入口を試せます。公式のInPrivate説明では、許可した拡張機能はInPrivateでも実行されます。したがって成功したことだけで拡張機能の原因は確定せず、通常側と有効状態を比較してください。CookieやサイトデータはすべてのInPrivateウィンドウを閉じた時に削除されます。組織で利用が制限されている場合は管理者に確認します。
ネットワーク環境を変えて試す
異なる回線で比較する場合は、組織が許可する環境を使ってください。特定の回線だけで失敗する場合は、その回線、発生日時、同じアカウントでの比較結果を管理者へ伝えます。結果が違っても、原因となる装置や設定は追加調査が必要です。
組織の接続方針を守って確認する
VPNの追加や社外経由への変更で組織の方針を回避しないでください。既存VPNを使う場合も、必要な接続条件を管理者に確認し、接続状態とエラーの結果を記録します。
Azure AD側の視点での考察
HTTPメソッドの不一致は表示文で分かりますが、どこで誤った要求が作られたかは別の調査です。利用者の操作、自作アプリ、戻り先の処理等を確認し、Azure側の設定だけが原因とは判断しないでください。
AzureサポートやMicrosoft Q&Aでの問い合わせ
問い合わせ先は利用サービスで選びます。個人のOutlook.comではMicrosoft公式のサインイン案内からアカウントのトラブルシューティングやサポートへ進みます。職場・学校のサービスや社内ポータルでは、組織の管理者・アプリ担当者へ情報を渡します。
具体的な問い合わせ内容のポイント
・発生するエラーのスクリーンショット
・発生した日時と回線情報（社内ネットワークか、自宅回線か）
・利用ブラウザとバージョン
・拡張機能の有無
・試した対策や設定変更の内容
これらをなるべく詳細に伝えると、原因特定が早まり解決しやすくなります。
独自アプリや認証フローが関係する場合
独自アプリや社内ポータルからのみ再現する場合は、その入口を管理者へ渡します。認証フローの区間と、実際に失敗したURL・メソッドを調べるのはアプリ担当者の作業です。利用者がOutlook設定から認証方式を一律に書き換える対策はありません。
社内ポータル経由と直接の入口を比較する
組織が許可する場合、普段の社内ポータルと正規のサービス入口からの結果を比較します。ポータル経由だけで失敗することを確認できれば、担当者へその結果を伝えます。POSTへ一律変更しただけで解決するという前提にはしません。
入口、直前の操作、エラー全文、発生時刻をそろえると担当者が同じ条件を調べやすくなります。変更した項目と結果は対にして記録してください。
具体的な確認項目
問題解決をスムーズに進めるために、押さえておきたい確認ポイントをまとめます。
必要な場合は対象サイトのCookieだけを削除する
別環境では成功し通常のブラウザーだけで失敗する場合、対象サイトのCookie・サイトデータの確認を検討します。履歴削除とCookie削除は同じではありません。削除後はそのサイトで再サインインが必要になるため、作業中の内容を保存してから行います。
Cookieの許可状態は対象サイトごとに確認する
Edge公式のCookie管理には、サイト別の許可・ブロックと対象サイトだけの削除があります。ブロック状態はページの動作に影響する場合がありますが、それだけでAADSTS900561の原因とは確定しません。必要な設定は利用サービスや組織の案内と照らして確認してください。
Edgeで特定サイトのCookieを削除する手順
Edgeの公式資料に従い、通常ウィンドウの設定から対象サイトだけを検索します。Internet Explorerの信頼済みサイトへの追加と、現在のEdgeのCookie管理は別の操作です。
1. Edgeの［…］→［設定］→［プライバシー、検索、サービス］を開く
2. ［Cookie］→［すべてのCookieとサイトデータを表示］を選ぶ
3. 削除する対象サイトを検索する
4. 対象サイトの右の矢印を開き、削除する
5. 正規のサービス入口から再サインインし、結果を記録する高度な対策とテクニカルな視点
上述の対策を試してもなお改善が見られない場合、さらに深い部分での検証が必要になるかもしれません。
FiddlerやWiresharkなどで通信を解析
通信解析は、必要性を判断した管理者・アプリ担当者が行います。利用者はログの取り方を担当者へ確認し、Cookie・認証コード・トークンを含む通信データを公開しないでください。要求先ごとのGET／POSTの確認は開発者向け手順で説明しています。
通信解析で確認したいポイント
– リダイレクトの順番やステータスコード
– リクエストヘッダの内容（POSTかGETか）
– クッキーが正しく送信・受信されているか
もし社内ネットワークで動作させている場合は、プロキシサーバー側のログも確認するとさらに詳細がわかるでしょう。
Azure ADのアプリ登録と構成を見直す
アプリ担当者はMicrosoft公式の認可コードフローを確認します。アプリへの戻り先はresponse_mode=queryならGET、form_postならPOSTです。登録値だけでなく、受け側が選択した方式を処理できるかを調べます。利用者のブラウザーでGETを見つけただけで設定ミスとは判断しません。
自作アプリの修正は担当者が行い、正規の入口からサインインが完了するかを確認します。戻り先のURLを推測して置き換える操作は行わないでください。
まとめと今後の対処
AADSTS900561「The endpoint only accepts POST requests. Received a GET request.」が出た場合は、通常の入口から再試行し、戻る操作の直後だけか毎回発生するかを分けます。利用者は同じアカウント・入口のブラウザー比較から始め、必要な場合に対象サイトデータや拡張機能を個別に確認します。
社内ポータルや独自アプリだけで続く場合は、入口と再現手順を管理者・開発者へ渡してください。エラー文だけで回線やAzure設定の原因を断定せず、確認結果に基づいて担当者が要求先とメソッドを調べます。
Outlook.comをスムーズに使うために、今回紹介した各種対策や検証方法を活用してみてください。
コメント