Azure AD で発生する AADSTS900144 Missing Parameter エラーの解決方法

By Mirko Peters · 2026-04-21

認証エラーで行き詰まるのは誰にとっても避けたいものですが、Azure AD の AADSTS900144 Missing Parameter エラーは、アプリ開発者からIT管理者まで全員を悩ませる典型的な障害です。

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

認証エラーで行き詰まるのは誰にとっても避けたいものですが、Azure AD の AADSTS900144 Missing Parameter エラーは、アプリ開発者からIT管理者まで全員を悩ませる典型的な障害です。この記事では、このエラーの原因、最初に確認すべきこと、そしてユーザーを作業に戻すための手順を具体的に説明します。よくあるパラメーターの記述ミスから、OAuth フローやクラウドアプリ連携の詳細まで、原因と対処法を順に見ていきます。

Microsoft 365、Azure、Power Platform、または Entra ID に接続するあらゆるソリューションを扱う場合でも、クライアント側とサーバー側の両方の対処法が見つかります。実際のトラブルシューティング、エンタープライズ向けのベストプラクティス、クラウドガバナンスに関する参考リンクも掲載しているので、次にこのエラーが発生したときに困らないための備えとしてお役立てください。

Azure AD 認証で「AADSTS900144」が表示されるのはなぜか？

「AADSTS900144: Request body must contain the following parameter」というエラーは、Azure Active Directory（Microsoft Entra ID）に送信された認証要求に重要な情報が欠けている場合に表示されます。簡単に言えば、Azure はトークン要求の中に grant_type や client_id といった情報を探していますが、見つからないということです。情報自体は存在しても、形式が誤っていたり、間違った場所に置かれていたりする場合もあります。

このエラーは、ユーザーやアプリがエンタープライズ向けのクラウドサービスでサインインする際の OAuth 2.0 フローで最もよく発生します。多くの場合、認可コードをトークンと交換するときに送信するリクエストボディのパラメーターに問題があります。必須パラメーターが省略されていたり、綴りを間違えていたり、想定された POST ボディの外に配置されていたりすると、Azure AD は処理を停止し、AADSTS900144 のコードを返します。

このエラーは、独自のビジネスアプリを連携させる場合、Azure に新しいアプリを登録する場合、あるいは Microsoft Teams などのデスクトップクライアントで認証の問題が起きた場合に見られることがあります。コピー＆ペーストのわずかなミスや、アプリ登録の小さな変更が原因でパラメーターが合わなくなることもあります。エラーメッセージは分かりにくいかもしれませんが、「要求を見直して、不足している部分を修正してください」という Azure からのメッセージだと考えてください。

マルチテナントのアプリケーションを扱う場合は、テナントのコンテキストやサービスエンドポイントの不一致によっても、同様の混乱が生じることがあります。その結果、パラメーターが不足しているように見えることもありますが、実際には送信先が誤っているだけの場合があります。こうした仕組みを理解しておくと、トラブルシューティングが速くなり、サポートチームの負担も軽減されます。

リクエストボディのパラメーターに関するよくある問題と簡単な対処法

AADSTS900144 エラーのほとんどは、トークン要求で何かが抜けている、または間違った場所に入っていることが原因です。特に client_id と grant_type が関係することが多いです。必須パラメーターが1つでも欠けていると、Azure AD のトークンエンドポイントは要求を拒否します。HTTP メソッドが POST になっているかも確認してください。GET などほかのメソッドでは通りません。

まず、アプリが application/x-www-form-urlencoded のコンテンツタイプで要求を送信しているかを確認します。誤ったコンテンツタイプが原因で、Azure AD が読み取れないパラメーターを探し続けるケースは意外に多くあります。次に、Postman、curl、Fiddler などの HTTP リクエストツールを開き、生のリクエストボディを確認します。client_id、grant_type、client_secret などが、クエリ文字列やヘッダーではなく、本当にペイロードに含まれているでしょうか。

アプリ登録を調整する場合は、付与フローによって必要なパラメーターが変わる可能性があることを覚えておいてください。たとえば、認可コード付与を使う場合は code も指定する必要があります。必ずしも分かりやすくはないため、対処が完了したと判断する前に、付与の種類を Azure のドキュメントと照合してください。

マルチテナントアプリでは、対象のテナントが特定の GUID や値を必要とする場合に、/common エンドポイントへ要求を送っていないか注意してください。そうでないと、「パラメーターが足りない」というエラーの原因が、単に要求の送信先の誤りである可能性があります。特にクロステナントのシナリオでは、誤った URL への要求送信で経験豊富な開発者でもつまずくことがあります。エンドポイントとパラメーターの両方を合わせて確認しましょう。これらを修正すれば、多くの場合、厄介な AADSTS900144 エラーは解消されます。

クライアント側のトラブルシューティング：キャッシュされた資格情報の削除とアプリのリセット

ときには、問題がコードではなく、ローカルマシン上で認証フローが狂っていることがあります。キャッシュされた資格情報や古いCookieが古いトークンを保持していたり、パラメーターのデータを壊していたりする場合があり、特にMicrosoft TeamsやOutlookのようなデスクトップアプリで起こりやすくなります。この状態になると、バックエンドの問題を解消した後でも、ユーザーにAADSTS900144のメッセージが表示され続けます。

最初に行うべき最も簡単な手順は、保存されている資格情報をすべて削除することです。Windowsでは、資格情報マネージャーを使ってアカウントに紐づくキャッシュされたトークンを削除します。Webアプリの場合は、ブラウザーのCookieとサイトデータを削除すると、クリーンな再認証プロセスを開始できます。解決しない場合は、特にMicrosoft Teamsでローカルリセットを試してください。すべてのデバイスからサインアウトし、アプリを閉じて、キャッシュフォルダーを削除してから再起動します。ユーザーによっては、デバイスの設定からTeamsのアカウントプロファイルを強制的に削除し、痕跡をすべて消してから、Teamsを最初から再インストールする必要がある場合もあります。

他のユーザーをサポートする場合は、「資格情報を削除する、アプリを終了する、キャッシュを消去する、再度サインインする」という簡潔なチェックリストを用意しておくとよいでしょう。業務ユーザーはアプリをすぐに使えるようにすることを求めているため、この方法であればダウンタイムと混乱を最小限に抑えられます。ITサポートチームは、より深く調査する前に、古い認証データがすべて削除されていることを必ず確認すべきです。残存する不要なデータが、AADSTS900144エラーが解消しない主な原因となることが多いためです。

Microsoft Teamsのガバナンスや、繰り返し発生する認証の問題に取り組んでいる方は、技術的な修正だけでは「ガバナンス」を解決できないことを理解しておくとよいでしょう。ガバナンスに終わりがない理由と、実務でそれを機能させる方法について詳しく知りたい場合は、Teamsのガバナンスと管理の錯覚に関するこちらのガイドをご覧ください。または、実践的な戦略については、こちらのTeamsのライフサイクル自動化プレイブックをご覧ください。

エンタープライズアプリでAADSTS900144を防ぐためのベストプラクティス

AADSTS900144エラーを防ぐことは、結局のところOAuthリクエストとアプリの構成を徹底して管理できるかどうにかかっています。Azure ADのトークンエンドポイントにリクエストを送信する前に、必須パラメーターをすべて検証する習慣をつけましょう。特にclient_idとgrant_typeは重要です。デプロイパイプラインで自動チェックを行えば、パラメーターの欠落や不正な形式を本番環境に到達する前に検出でき、後々の多くの問い合わせを減らせます。

Microsoft Entraの開発者向けツールを使って認証リクエストをシミュレーションし、Azure ADがどのように見ているかを確認しましょう。これにより、パラメーターの欠落だけでなく、特定のテナントで有効なリクエストをブロックしかねないエンドポイントの不一致やポリシーも洗い出せます。モックのEntraエンドポイントを使った単体テストを設定すると、パラメーターの問題をリリース時ではなく開発段階で明らかにでき、予期せぬ事態をさらに減らせます。

ガバナンスが厳格な組織や、複数の開発チームを抱える組織では、検証をInfrastructure as Codeの実践に組み込みましょう。ARMやBicepのデプロイテンプレートでスキーマチェックを使い、アプリの登録時に必要なOAuthパラメーターがすべて含まれるよう強制します。これにより、特にアプリが進化していく中で、構成のドリフトや設定ミスのリスクを抑えられます。

セキュリティを重視するアプローチとしては、OAuthの同意付与とポリシーの適用に常に注意を払うことが大切です。攻撃者は緩い同意設定を悪用する傾向があるため、ユーザーの同意を厳しく制限し、承認済みの発行元を必須にし、管理者による承認ワークフローを適用しましょう。これらの脅威と対策について詳しく知りたい場合は、Entra IDのOAuth同意攻撃の解説をお読みください。ガバナンスのプロセスを見直しているなら、自動化、RBAC、Azure Policyを活用することも有効です。設計の考え方と実践的な統制策については、Azureエンタープライズガバナンス戦略のガイドをご覧ください。