Outlook.comにログインしようとしたら突然「AADSTS900561: The endpoint only accepts POST requests. Received a GET request.」というエラーが表示されて戸惑った経験はありませんか。実は私も以前、同様のエラーに悩まされました。ブラウザ設定を見直しても改善せず、「なぜこのエラーが出るのか」「一体どうやって解決すればいいのか」と頭を抱えたものです。本記事では、その原因や考えられる対処法、実際に私が解決へたどり着くまでの体験談を交えながらわかりやすく解説していきます。エラーでお困りの方は、ぜひ最後まで読んでみてください。
AADSTS900561エラーとは
AADSTS900561エラーは、Microsoft Azureの認証システム（Azure Active Directory、通称Azure AD）を利用する際に表示されるエラーコードの一つです。具体的には「The endpoint only accepts POST requests. Received a GET request.」というメッセージが示す通り、認証に用いられるエンドポイントがPOSTリクエストしか受け付けないのにもかかわらず、GETリクエストでアクセスが行われていることを指摘しています。
ただ、Outlook.comを普通に利用している中で「GETリクエスト」を意図的に送信しているわけではないはずです。それにも関わらずこのエラーが発生する背景には、ブラウザや拡張機能、ネットワーク環境、そしてAzure AD側の認証設定など複合的な要因が絡んでいる可能性があります。
エラー内容の背景
このエラーが一度出現すると、利用者側で単純に「クッキーを消す」や「ブラウザ履歴を削除する」といった対策をしても解消しないことがあります。実際に私もブラウザのキャッシュ・履歴を削除したり、サードパーティCookieを許可したり、セキュリティソフトの例外設定を見直したりと色々試しました。しかし、なかなか状況が変わらずに手こずりました。
問題の核心はOutlook.comのUIからは直接制御できない部分、つまりAzure ADの認証フローやリダイレクトURLの挙動などにあることが多いのです。そこが利用者にとっては悩ましいポイントと言えるでしょう。
事例：社内ネットワークでの限定的な発生
会社のネットワークを利用してOutlook.comへアクセスしようとするとエラーが頻発し、自宅の回線だと問題なく使える、というケースを実際に耳にしたことがあります。これは社内ネットワークのセキュリティポリシーによって、特定のリクエストを検知し修正や遮断を行っている可能性が考えられます。プロキシサーバーやファイアウォールがリクエストを横取りして別の形で送信してしまい、結果としてGETリクエスト扱いになってしまうのです。
考えられる原因と対策
ここでは、私が調べたり試したりして有効だった、あるいは専門家の方から教わった対策をご紹介します。
ブラウザ拡張機能の影響をチェック
拡張機能が導入されているブラウザの場合、リダイレクト処理やクッキーの扱いを拡張機能が書き換えていることがあります。特に広告ブロック系やトラッキング防止系の拡張機能には、リクエスト内容を変更してしまうものがあるので注意してください。
拡張機能を一時的にすべて無効にする
まずは使用中の拡張機能を一旦すべて無効にし、Outlook.comにアクセスしてみます。もしエラーが解消した場合は、拡張機能が原因となっている可能性が高いです。その後、問題がない拡張機能だけを徐々に有効に戻していき、どの拡張機能でエラーが再発するかを突き止めるのが確実です。
ネットワーク環境を変えて試す
自宅Wi-Fiやモバイルデータ通信など、異なるネットワーク環境でログインを試すことで、原因の切り分けが可能です。ある特定のネットワークでのみエラーが発生するようであれば、前述したようにプロキシやファイアウォールが原因になっているかもしれません。
VPN接続を利用してみる
企業や大学などのネットワーク環境でエラーが起きる場合は、VPNを利用して外部経由でアクセスを試してみるのも有効です。VPN接続を行うと、通常とは異なる経路で通信が行われるため、ネットワーク環境由来の不具合を回避できることがあります。
Azure AD側の視点での考察
AADSTS900561エラーが指し示すとおり、リクエストメソッドの不一致が根本にある可能性が高いです。この設定をコントロールするのは基本的にAzure AD側です。もちろん利用者のブラウザやネットワークによる意図しないリクエスト変換も否定できませんが、最終的にはAzure ADのログインフローを管理する側の設定が大きく関わっています。
AzureサポートやMicrosoft Q&Aでの問い合わせ
自力で解決するのが難しい場合、Azureサポートへ問い合わせるのが最も確実です。トラブルシューティングの経験値が豊富なエンジニアが対応してくれるため、ユーザー側で行った設定変更や試行内容を正確に伝えるとスムーズです。
具体的な問い合わせ内容のポイント
・発生するエラーのスクリーンショット
・発生した日時と回線情報（社内ネットワークか、自宅回線か）
・利用ブラウザとバージョン
・拡張機能の有無
・試した対策や設定変更の内容
これらをなるべく詳細に伝えると、原因特定が早まり解決しやすくなります。
独自アプリや認証フローが関係する場合
企業が独自に開発したアプリやポータルサイトを利用してOutlook.comにログインしているケースでは、アプリケーション内部で用いている認証フローがエラーの原因となる場合があります。例えば、リダイレクトURLの指定やOAuth2.0などのフローでGETリクエストが意図せず送信されている可能性があるのです。
実際にあった改善例
社内ポータルからOutlook.comへシングルサインオン（SSO）する仕組みがあり、そこにAzure AD連携を加えた際にGETメソッドが走っていたという事例がありました。システム管理者がコードを修正してPOSTリクエストを正しく送るようにした結果、エラーが解消されたとのことです。
私の知り合いも、社内システムでSSOの実装を行ったときに同様の課題にぶつかりましたが、ソースコードのごく一部の設定を変えただけであっさり解決したそうです。改めて認証フローの仕組みを理解することって大切ですよね。
具体的な確認項目
問題解決をスムーズに進めるために、押さえておきたい確認ポイントをまとめます。
ブラウザのキャッシュ・Cookie・履歴は本当にクリアできているか
一度ブラウザのキャッシュや履歴を削除しても、Cookieが完全に消えていないこともあります。例えば複数のブラウザを切り替えながら使っている場合や、シークレットモード・プライベートブラウズを利用していない場合は注意してください。
ブラウザの設定でサードパーティCookieを許可しているか
Outlook.com（または関連ドメイン）を正しく許可リストに入れておかないと、ログインフローで必要なCookieがブロックされ、結果として認証失敗に繋がる可能性があります。実際にCookie関連の設定を見直してエラーが消えたという話も珍しくありません。
手順例: Internet ExplorerやEdgeでのサイト追加
Windows環境でInternet Explorerや旧版Edgeを使っている場合、Internetオプションからサイトを信用済みサイトに追加すると改善するケースがあります。
1. [Windowsキー] + [R] を押して inetcpl.cpl を起動
2. [セキュリティ] タブを選択し、[信頼済みサイト] をクリック
3. [サイト] ボタンを押して、対象のURL（outlook.com 等）を追加
4. ブラウザを再起動してログインを再試行高度な対策とテクニカルな視点
上述の対策を試してもなお改善が見られない場合、さらに深い部分での検証が必要になるかもしれません。
FiddlerやWiresharkなどで通信を解析
ブラウザを経由する通信をパケットキャプチャツールやプロキシツールを使って解析すると、どの段階でGETリクエストに切り替わっているのかが見えてきます。
通信解析で確認したいポイント
– リダイレクトの順番やステータスコード
– リクエストヘッダの内容（POSTかGETか）
– クッキーが正しく送信・受信されているか
もし社内ネットワークで動作させている場合は、プロキシサーバー側のログも確認するとさらに詳細がわかるでしょう。
Azure ADのアプリ登録と構成を見直す
Azureポータル上でアプリ登録を行っている場合、リダイレクトURLや許可されるリソース、権限の設定に不備があると意図しないリクエストメソッドが混ざる可能性があります。特にOAuth2.0のAuthorization Code Flowを利用している場合、POSTで戻ってくることが想定されているURLがGETになってしまうのは設定ミスが疑われます。
私は以前、Azureポータルのアプリ構成で間違ったリダイレクトURLを設定しており、なぜかログイン画面を繰り返すだけという状況に陥ったことがありました。正しいURLを入力しただけで嘘のように動くようになりましたよ。
まとめと今後の対処
AADSTS900561エラー「The endpoint only accepts POST requests. Received a GET request.」は、一見Outlook.com単体のトラブルに見えて、その背景にはAzure ADの認証フローやネットワーク環境が複雑に絡み合っています。ブラウザやCookieの設定を見直しても改善しない場合には、Azureサポートや専門家に相談することが解決への近道になることが多いです。
さらに、社内環境や独自アプリを組み合わせているケースでは、開発者やIT管理者と連携してシステム側の設定やコードをチェックすることが必要不可欠です。使っているブラウザ拡張やネットワーク機器の制限、Azure ADアプリ登録の細かな設定など、どこに落とし穴があるかは実際に調査しないとわかりません。
Outlook.comをスムーズに使うために、今回紹介した各種対策や検証方法を活用してみてください。
コメント