Microsoft Entra ID（旧Azure AD）でサインインしようとした瞬間に「AADSTS900144: The request body must contain the following parameter: ‘login_hint’.」と出て先に進めない――。このエラーはアプリ（ベンダー）側の認証リクエスト不備が原因のこともあれば、Teams/SharePoint でのアカウント競合やクッキーが引き金になることもあります。現場で迷わないための意味・原因・対処を整理します。
起きていること：どんな状況で表示されるエラーか
典型的には、請負業者（ベンダー）が提供する新しいプラットフォームへ追加したアカウントでログインしようとした際、ポップアップや別ウィンドウのサインイン画面で次のエラーが出ます。
表示例：AADSTS900144: The request body must contain the following parameter: 'login_hint'.
- ログイン処理が途中で止まり、アプリ内の「場所（ロケーション）」や特定メニューに入れない
- 同じプラットフォームを使う他ユーザーでも再現する（＝個人端末の問題に見えにくい）
- サインインがTeams/SharePoint連携（ファイル、権限、埋め込みページなど）と絡むと、症状が複雑化しやすい
AADSTS900144 と login_hint の基礎知識
AADSTS900144 の意味
AADSTS900144 は、Microsoft Entra ID（旧 Azure AD）に対して送られた認証要求（OpenID Connect / OAuth 2.0 のリクエスト）に、必須パラメーターが含まれていないときに返る代表的なエラーのひとつです。今回のメッセージでは login_hint が要求されています。
login_hint とは何か（何ではないか）
login_hint は、ざっくり言うと「このユーザーでログインしてほしい」というユーザー名のヒントです。多くの組織では UPN（ユーザープリンシパル名） が使われ、見た目はメールアドレスと同じ形式（例：[email protected]）が一般的です。
- login_hint は本人確認の情報ではありません（パスワードやトークンの代わりにならない）
- Entra ID が「どのアカウントのサインイン処理を進めるべきか」を判断する材料になる
- 特に「画面を出せない/出したくない」サインイン（サイレントSSO）では重要度が跳ね上がる
| 項目 | 役割 | よくある値 | 不足すると |
|---|---|---|---|
login_hint | サインイン対象ユーザーのヒント（ユーザー名） | [email protected]（UPN/メール形式） | AADSTS900144（今回）になりやすい |
prompt | UI表示の制御（例：同意画面、アカウント選択） | none, select_account, login | prompt=none だとユーザー特定が必要になり、login_hint がほぼ必須化 |
domain_hint | どの種類のアカウントかのヒント（組織/コンシューマー等） | organizations 等 | テナント/アカウント種類の誘導ができず、選択画面や誤誘導が増える |
なぜ「login_hint が必須」になりがちなのか（よくある背景）
本来、サインイン画面を出せる設計なら、ユーザーが自分でアカウントを選んだりメールアドレスを入力したりできます。しかし、次のような設計では「どのユーザーで処理すべきか」をサーバー側が判断できず、login_hint が事実上必須になります。
- サイレントサインイン（例：
prompt=none）を使っている：画面が出ないため、アカウントの選択や入力ができない - ログインポップアップ/埋め込みフレームでSSOを完結させたい：UI制約が多く、アカウント確定が必要
- 同一ブラウザ内に複数のMicrosoftアカウントが混在：個人アカウントと組織アカウント、ゲスト、複数テナントなど
- アプリ側が「このユーザーで入る前提」でURLを組み立てている：その前提を満たす情報を渡していないと破綻する
結論として、技術的な直接原因はシンプルで、ベンダー（アプリ）側が認証要求に login_hint を付けていないことが多いです。ただし、利用者側の環境要因（アカウント競合やクッキー）が結果的に同じエラーを誘発することもあるため、切り分けが重要です。
ベンダー/開発者側：認証リクエストに login_hint を含める
OpenID Connect / OAuth 2.0 の authorize リクエスト例
実装がOpenID Connect/OAuth 2.0 の標準フローであれば、認可エンドポイント（authorize）に login_hint を含めます。
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
?client_id={client_id}
&response_type=code
&redirect_uri={redirect_uri}
&scope=openid%20profile%20offline_access
&state={state}
&nonce={nonce}
&[email protected]ポイント
login_hintには UPN/メール形式のサインインID を入れる（例：[email protected]）- URLエンコードを忘れない（特に
@や+などの文字を含むケース） prompt=noneを使うなら、ユーザー特定の情報（login_hint など）をセットで渡す- アプリ登録やSSO方針が「ユーザー識別子前提」なのに、実際のリクエストで渡していないと今回のようなエラーになりやすい
MSAL を使っている場合の代表例
ベンダーが Microsoft Authentication Library（MSAL）を使っている場合、フレームワークごとに渡し方が決まっています。名前が似たオプションが多いので、実装レビュー時は「どのメソッドで、どこに渡しているか」を明示して確認すると早いです。
| 実装パターン | login_hint の渡し方（例） | 狙い |
|---|---|---|
| MSAL.js（ブラウザ）でサイレントSSO | ssoSilent({ loginHint: "[email protected]" }) | 画面を出さずにユーザーを特定してSSO |
| MSAL（.NET）で対話型サインイン | AcquireTokenInteractive(scopes).WithLoginHint("[email protected]") | アカウント入力を省略/誤選択を減らす |
| MSAL（各種）でアカウント選択を許す | prompt=select_account を使う | ユーザー側でアカウントを選べるUIを出す |
「login_hint が取れない」設計のときに考えるべき代替案
ログイン前にユーザー名（UPN）をアプリが把握できない設計もあります。その場合、無理に prompt=none で完結させると破綻しやすいので、次のどれかに寄せるのが現実的です。
- アカウント選択画面を出す：
prompt=select_accountを検討 - ユーザーにメール入力させるUIをアプリ側に用意し、入力値を
login_hintとして渡す - テナント固定の導線を作る：
/commonではなく組織のテナントに寄せ、誤ログインを減らす - SSO前提の仕様を見直す：ブラウザ制約（サードパーティCookie等）を踏まえた設計に変更
開発チェックリスト（ベンダーに確認したい項目）
| チェック項目 | 確認観点 | NGだと起きがちなこと |
|---|---|---|
login_hint を付与しているか | authorize リクエストの実URL/ログで確認 | AADSTS900144 が再現 |
prompt=none の有無 | サイレント完結が仕様か、例外時UIが出るか | ユーザーが選べず詰む |
| テナント/アカウント種別の想定 | 組織アカウントのみか、個人MSA混在か | 個人/組織の取り違え、権限エラー |
| ブラウザ環境の制約 | ポップアップ/iframe/サードパーティCookie制限 | SSOが不安定、環境差で再現 |
| リダイレクトURIの整合 | 登録済みURIと完全一致しているか | 別のエラー（リダイレクト不一致など） |
利用者側：まず試すべき即効性の高い対処
「ベンダー側の実装修正が必要」と言われると待ち時間が発生しがちですが、実際の現場ではアカウント競合やクッキー起因で同じ現象が増幅するケースもあります。利用者側でできる範囲で、切り分けを短時間で行う手順です。
最短の切り分け手順
- シークレット/プライベートウィンドウでログインを試す
既存のクッキーやセッションの影響を受けにくく、切り分けに最適です。 - 正しい「組織アカウント」でサインインできているか確認
Microsoft 365 を使う組織の場合、個人用 Microsoft アカウント（MSA）で入ってしまうと、Teams/SharePoint 連携で衝突しやすくなります。 - 同じブラウザプロファイルで複数アカウントを混在させない
仕事用と個人用を分けるだけで、再発率が大きく下がります。
Microsoft 関連クッキーの削除（効果が高い）
症状が「突然起きた」「アカウントを追加/切り替えた直後から」「他のMicrosoftサービスは使えるのに特定の場所だけ入れない」などの場合、クッキー削除が刺さることがあります。
- 削除対象の例：
microsoft.com/login.microsoftonline.com/teams.microsoft.com/sharepoint.comなど - 注意：削除するとサインイン状態がリセットされ、他のMicrosoftサービスからも再ログインが必要になります。
| やること | 期待できる効果 | 向いている状況 |
|---|---|---|
| シークレットウィンドウで再ログイン | クッキー/セッション競合を回避して再現性を確認 | 原因切り分けを急ぎたい |
| Microsoft関連サイトのクッキー削除 | アカウント衝突・誤ログイン状態を初期化 | アカウント切替後に発生、Teams/SharePoint絡み |
| 仕事用と個人用でブラウザプロファイルを分離 | 再発防止（長期的に効果大） | 個人MSAも日常的に使う |
実例：Teams / SharePoint の「アカウント競合」とクッキーが原因だったケース
同じ AADSTS900144 でも、根本が「Entra ID の設定」ではなく、Teams/SharePoint にアクセスする際のアカウント取り違えとブラウザクッキーの競合だった、というパターンがあります。
起きていた状況
- アカウントを切り替えた後、Microsoft Teams にサインインしようとして問題が発生
https://teams.microsoft.comをブラウザで開くと、ブラウザ経由ではTeamsのファイルにアクセスできる場面もあった- 使用しているアカウントが「個人用 Microsoft アカウント」扱いに寄っており、組織の SharePoint / Teams リソースへアクセスするタイミングで衝突
なぜ競合すると詰まりやすいのか
Teams/SharePoint はサインイン状態・トークン・テナント情報などをブラウザのセッションに強く依存します。そこへ、同一ブラウザ内で個人アカウント（MSA）と組織アカウント（Entra ID）が混在すると、アプリが「どのユーザーで認証を進めるか」を決めきれず、結果として login_hint を要求する流れになりやすくなります。
実際に効いた対処
- ブラウザのMicrosoft関連クッキー（サイトデータ）を削除
- サインインをやり直し、意図した組織アカウントで Teams / SharePoint にアクセス
- 以後は、仕事用と個人用でブラウザプロファイルを分ける運用に変更
症状から原因を絞る：現場向けの早見表
| 観測できる症状 | 可能性が高い原因 | まずやること |
|---|---|---|
| 複数ユーザーで同時期に再現する | ベンダー側の認証リクエスト不備（login_hint 未送信） | ベンダーに「authorize要求に login_hint を付与しているか」確認依頼 |
| 同じユーザーでも端末/ブラウザで挙動が変わる | クッキー・セッション・アカウント混在 | シークレットで再現確認 → Microsoft関連クッキー削除 |
| Teams/SharePoint連携（ファイル）に入るときだけ失敗 | 個人MSAと組織アカウントの衝突、テナント誤選択 | 仕事用プロファイルへ分離、ログインし直し |
| 以前は動いていたが、最近だけ失敗 | ベンダー側のSSO仕様変更（prompt=none 等）やブラウザ制約の影響 | ベンダーに変更点確認、ログイン方式の見直し |
| 特定ユーザーだけ失敗（同じ組織内） | アカウント属性差（ゲスト/メンバー、UPN違い）、端末側の混在 | UPN確認、シークレット検証、管理者へサインインログ確認依頼 |
情シス/管理者向け：ベンダー修正を待つ前に確認すると早いこと
利用者側の対処で改善しない場合、管理者が一度だけ確認すると「ベンダーに何を渡すべきか」が明確になります。
確認観点
- どのユーザーが失敗しているか：全員か、一部か、ゲストだけか
- 失敗のタイミング：最初のサインインか、リソースアクセス時か（Teams/SharePoint連携の瞬間など）
- サインインログのエラー詳細：
AADSTS900144以外の併発（条件付きアクセスや同意不足など）がないか - ユーザーのサインインID（UPN）：
login_hintに入れるべき文字列の確定
ベンダーへ渡すと有効な情報
- 発生しているエラーメッセージ全文（可能なら日時も）
- ログインを試したユーザーの UPN（例：
[email protected]） - 再現手順（どの画面のどのボタンで、どのポップアップが出るか）
- シークレットで試した結果（再現する/しない）
ベンダーへの依頼テンプレート（そのまま送れる文面）
自分でURLやリクエストを変更できない場合、ベンダー/システム担当者へは「何を直せばいいか」が伝わる文面が重要です。次を必要に応じて編集して送ってください。
ログイン時に以下のエラーが発生し、アプリ内のロケーションに入れません。
エラー：AADSTS900144: The request body must contain the following parameter: ‘login_hint’.
Microsoft Entra ID（Azure AD）の認証要求（OpenID Connect / OAuth2）に、必須となる
login_hint（ユーザーのUPN/メールアドレス）パラメーターが含まれていない可能性があります。
authorize リクエスト（/oauth2/v2.0/authorize等）にlogin_hint={ユーザーUPN}を付与する実装になっているかご確認いただけますでしょうか。参考：サイレントサインイン（
prompt=none等）を使用している場合は特にlogin_hintが必須になりやすいです。
よくある質問（現場で混乱しがちなポイント）
login_hint には「メールアドレス」を入れればいい？
多くの組織では「メール形式のUPN＝サインインID」なので一致します。ただし、メールとUPNが別の組織もあります。確実にするなら「そのユーザーが実際にサインインに使っているID（UPN）」を使うのが安全です。
login_hint を付けるのは危険では？
login_hint は認証情報ではなく「ヒント」なので、それ自体が認証を突破することはありません。ただし、ログやURLに残りやすい性質があるため、ベンダー側では不要なログ出力を避ける、扱いを最小限にする、といった配慮が望ましいです。
クッキー削除で直った場合、ベンダー修正は不要？
直ったとしても「環境依存で再発する」可能性があります。
利用者側のクッキー整理は応急処置として有効ですが、複数ユーザーで発生しているなら、ベンダー側の実装（prompt=none と login_hint の整合など）も併せて見直してもらうと再発防止につながります。
同じエラーでも原因が複数あるのはなぜ？
サインインは「アプリの実装」「ブラウザの状態」「既存のサインインセッション」「テナント/アカウント種別」が絡みます。
そのため、最終的に Entra ID が「ユーザー特定に必要な情報が足りない」と判断すると、結果として同じ AADSTS900144 が出ることがあります。まずはシークレットで再現するかどうかが、切り分けの近道です。
実務的なまとめ：誰が何をやると最短で解決するか
| 立場 | 優先してやること | 狙い |
|---|---|---|
| 利用者 | シークレットで試す Microsoft関連クッキーを削除して再ログイン 仕事用/個人用でブラウザプロファイルを分ける | アカウント競合・セッション起因の問題を即時に潰す |
| 情シス/管理者 | どの範囲で再現するか整理（全員/一部） ユーザーのUPNを確認 ベンダーへ渡す情報（再現手順・対象ユーザー）を整える | 原因を「端末」か「ベンダー実装」かに素早く寄せる |
| ベンダー/開発者 | authorize リクエストに login_hint を付与 prompt=none を使うならユーザー特定情報とセットで設計 アカウント選択UIの許可（必要に応じて） | 根本原因を解消し、ユーザー環境差による再発を防ぐ |
コメント