Microsoft Entra ID（旧Azure AD）の条件付きアクセスで、PCはスマートカード（CBA）、モバイルはMicrosoft Authenticator（電話サインイン）と端末ごとに認証方式を分けたいのに、サインインが「前回の方式」を自動選択して失敗する――その原因と、現実的に取れる対処を整理します。
起きていること：端末ごとに分けたいのに、前回の認証方式が“勝手に選ばれる”
次のような要件は、ゼロトラスト設計や監査要件の都合でよく出てきます。
- モバイル（iOS/Android）：Microsoft Authenticator の電話サインイン（Passwordless）を強制したい
- PC（Windows）：スマートカード（証明書ベース認証 / CBA）を強制したい
ところが実運用では、ユーザーが一度どちらかの方式でサインインすると、次に別端末・別アプリでサインインする際に「前回の方式が既定として自動選択される」ことがあります。特に Teams モバイルでは、最初に「サインイン オプション」を出さずに進もうとして失敗→戻って手動で切り替えが必要になり、問い合わせが増えがちです。
| 場面 | 本来やりたいこと（理想） | 実際に起きがちな挙動 | ユーザー影響 |
|---|---|---|---|
| PCでCBA（スマートカード）でサインイン後、モバイルのTeamsを開く | モバイルは電話サインインへ誘導・強制 | モバイル側でもCBAを再利用しようとして失敗 | サインインオプションに戻って手動切替が必要 |
| モバイルでAuthenticator（電話サインイン）後、PCでサインイン | PCはスマートカードへ誘導・強制 | PC側でもAuthenticator側の流れが先に出たり、候補が自動選択される | 最初に選択画面を出せず、混乱しやすい |
なぜ「前回の認証方式」が出てくるのか：Entra IDのサインイン体験は“ユーザー単位”で最適化される
Microsoftのサインイン体験は、毎回ゼロから選ばせるよりも、ユーザーの入力・操作を減らす方向に最適化されています。結果として「直近に成功した方法」や「ユーザーに紐づく既定の方法」が、次のサインインの出発点になりやすくなります。
さらに、Teams モバイルのようなクライアントアプリは、Webブラウザのログインとは違い、認証ブローカー（Authenticator / Company Portal など）を使ってシームレスなSSOを実現します。ブローカーは認証ハンドシェイクやトークン維持を担い、ブラウザより“なめらかに”見える反面、ユーザーが「サインイン オプション」で毎回選ぶ導線は弱くなりがちです。
そして、Conditional Access の認証強度（Authentication strength）のドキュメント上も、ユーザー体験を左右する要素として「ユーザーが以前どの認証方法を使ったか」が明確に挙げられています。つまり“前回の方式”は偶然ではなく、仕組みとして影響します。
| 要素 | 何が起きるか | 管理者がコントロールできる範囲 |
|---|---|---|
| ユーザーが前回使った方式 | 次回サインインの“開始点”として優先されやすい | 直接OFFにするスイッチは用意されていない（後述） |
| 認証ブローカー（モバイルSSO） | アプリ間SSOが強く働き、ログイン画面の選択導線が短絡化しやすい | アプリのサインアウトや端末側の状態で間接的に影響 |
| System-preferred MFA | 登録済みの中で“より強い方法”を優先提示する | 有効/無効、対象グループの制御が可能 |
| 認証方法ポリシー（Authentication methods policy） | そもそも使える/使えない方法の母集団を決める | ユーザー/グループ単位で可 |
| 条件付きアクセス（CA） | リソースアクセス時の要求（MFA/認証強度/準拠デバイス等）を決める | かなり強いが「最初の方法選び」そのものは制御しにくい |
結論：端末間の「前回方式の自動再利用」を無効化する“公式なポリシー設定”はない
結論から言うと、「端末間で前回の認証方式が自動選択される挙動」を無効化したり、常に最初に「サインイン オプション」を表示させたりするための、サポートされたポリシー設定は用意されていません。
この挙動は、ユーザーの手間を減らす目的の設計（by design）として扱われており、特にパスワードレスを主認証（第1要素）として使うケース（例：CBA/スマートカード、Authenticator電話サインインなど）では、管理者が“自動選択そのもの”を止める手段がありません。
ここが重要なポイントですが、Conditional Access（認証強度を含む）は万能ではありません。Microsoft Learn の仕様として、条件付きアクセスの評価は「初回の認証」後に行われるため、認証強度は「ユーザーが最初に何で認証するか」を直接制限できません。結果として、主認証がパスワードレス方式に寄っている設計ほど、今回の“前回方式の自動選択”問題が表面化しやすくなります。
回避策として試す価値があるのは「認証強度 × 端末条件」だが、効くのは限定的
完全な解決は難しいものの、回避策として現場で試されるのが認証強度（Authentication strength）を端末条件ごとに分けてCAで要求する構成です。
ただし、ポイントはここです。
- 主認証が“パスワード”である認証強度どうし（例：パスワード＋SMS、パスワード＋Authenticatorプッシュ等）の切り替えは、端末条件ごとに誘導できるケースがある
- CBA や Authenticator電話サインインのような“パスワードレス主認証”どうしの切り替えは、このやり方がうまく機能しないことがある
認証強度の仕組み自体は、CAで「どの組み合わせの認証方法を許可するか」を絞り込む考え方で、組み込みの強度（MFA / Passwordless MFA / Phishing-resistant MFA）やカスタム強度が用意されています。組み込み強度の一覧には、FIDO2、Windows Hello、CBA（多要素）、Authenticator電話サインインなどが含まれます。
| アプローチ | 狙い | 期待できること | 限界・注意点 |
|---|---|---|---|
| 端末条件ごとに認証強度を分ける（パスワード主認証） | モバイルはA、WindowsはBのMFAへ誘導 | 「自動選択される方式」を“結果的に”望む方へ寄せられる場合がある | パスワードレス同士（CBA vs 電話サインイン）では効かないことがある |
| System-preferred MFA を見直す | 強い方式を優先提示する挙動をコントロール | 想定外の方式が前に出る頻度を下げられる可能性 | 「毎回サインインオプション」を強制できるわけではない |
| そもそも主認証方式を統一する | “前回方式の引きずり”を起こさない設計へ | ユーザー混乱を根本から減らせる | 要件（スマートカード必須等）により現実的でない場合がある |
「パスワードレス主認証」を端末で分けたい場合に現実的にできること
今回のように、CBA と電話サインインを“主認証”として使い分けたい場合、機能で止められない以上、次のような実務的対処が現実解になります。
Teams モバイルで迷子を減らす：ユーザー向けの“戻り方”を定型化する
問い合わせが増えるのは、ユーザーが「どこに戻れば方式を変えられるのか」が分からないからです。手順を1枚の社内手順に落として、ヘルプデスク対応を統一すると、体感の負荷が下がります。
| 状況 | ユーザーに案内する行動（例） | 狙い |
|---|---|---|
| Teams モバイルでCBAに寄って失敗する | エラー画面や進行不能画面で戻る→「サインイン オプション（または別の方法でサインイン）」→Authenticator（電話サインイン）を選ぶ | 最短で正しい方式に切り替える |
| 何度やっても同じ方式が出る | Teams からサインアウト→アプリ再起動（必要ならキャッシュ削除/再インストールを段階的に） | ブローカー/アプリの状態をリセットして選択導線を出しやすくする |
| 端末を交換した・Authenticatorを入れ直した | Authenticator 側で業務アカウントを正しく追加し直し、電話サインインを有効化（組織の手順に従う） | そもそも選択肢として成立させる |
ポイントは、「サインイン オプションへ戻る」動線を、ユーザーの頭の中で固定化することです。運用で止められない仕様ほど、現場は“操作の定型化”が効きます。
PC側の「うっかりAuthenticator選択」を減らす：想定外の候補を残さない
PCでスマートカード（CBA）を強制しているつもりでも、条件付きアクセスの設計次第では「別方式でも進める余地」が残ります。完全解決ではないものの、事故率を下げるチェックポイントを押さえてください。
| チェック項目 | 確認ポイント | よくある落とし穴 |
|---|---|---|
| CAポリシーの重なり | 同一サインインで複数ポリシーが当たり、要求が競合していないか | 「Windows向け」「全社向け」などが同時に当たってUXが読めなくなる |
| 対象クライアント | Browser / Mobile apps and desktop clients の設定が意図通りか | Teams/Office クライアントが別の枠で評価される |
| プラットフォーム条件 | Windows / iOS / Android が正しく分岐しているか | 「未指定（Any）」にしていて想定外の端末に適用される |
| 認証方法ポリシー | ユーザーが“登録済み”かつ“利用可能”な方式が何か | 登録だけ残っていて候補として出続ける |
認証方式の前提を整理：CBAと電話サインインはどちらも「パスワードレス」
今回の設計が難しくなる根っこは、どちらもパスワードレスとして強い方式である一方、“主認証”として機能する点にあります。
- CBA（証明書ベース認証）：X.509 証明書で Entra ID に直接認証でき、フィッシング耐性の高い方式として位置づけられています。
- Authenticator（電話サインイン）：デバイスに紐づく鍵ベースの資格情報を使い、PIN/生体情報で完結するパスワードレス方式です。
この2つを同一ユーザーが日常的に使い分けると、「前回の方式を起点にしたい」というプロダクト側の思想と、「端末ごとに別方式を必ず使わせたい」という運用思想が衝突します。ここをCAだけでねじ伏せようとすると、どうしても限界が出ます。
「毎回、必ずサインイン オプションを出したい」はなぜ難しいのか
管理者としては「モバイルは常に電話サインイン、PCは常にCBA」と、最初に選択画面を出してほしいものです。しかし、次の理由で難しくなります。
- ユーザー体験上、毎回の“選択”は摩擦なので、サービス側は既定の方法を先に提示しがち
- 認証強度を含む CA は、仕様として初回認証後の評価が中心で、初手の選択画面を制御しづらい
- Teams モバイルは認証ブローカー経由のSSOが働き、ブラウザのように毎回同じUIが出るとは限らない
管理者向け：切り分けと調査の進め方（サポートに頼る前にやること）
「仕様」と言われて終わりになりがちですが、現場で困るのは事実です。サポート問い合わせや再設計に進む前に、以下をやると判断が早くなります。
サインインログで“何が要求され、何が満たせなかったか”を見る
- 対象ユーザーのサインインログを開き、Authentication Details（認証の詳細）でどの方法が使われた/試されたかを確認
- 該当サインインに適用されたCAポリシーを確認し、どの条件で分岐したかを特定
- モバイルのTeamsと、ブラウザで同じリソースにアクセスした場合で、挙動が一致するか比較（アプリ/ブローカー固有かを切る）
再現手順を“最短”にする
フィードバックやサポートに出す場合、次の情報が揃うと伝わりやすくなります。
- 端末種別（iOS/Android、Windowsのバージョン）
- アプリ（Teamsのモバイル/デスクトップ/ブラウザ）
- 前回のサインイン方法（CBA→モバイルで失敗、などの順序）
- 時刻（タイムゾーン含む）
- サインインログの該当イベント（相関IDが分かればなお良い）
改善要望としてはフィードバック提出が現実的
現時点で“スイッチがない”以上、プロダクト側の改善を期待する場合は、Microsoft のフィードバック窓口に要望として挙げるのが現実的です。特に以下の観点を明確にすると、単なる不満ではなく「設計要件」として伝わります。
- 同一ユーザーが複数端末を使う前提で、端末ごとに主認証を分離する必要がある
- 自動選択が利便性よりも業務影響（サインイン不能/問い合わせ増）を上回っている
- 「サインイン オプションを常に表示」「端末ごとに既定方式を固定」「失敗時に自動で選択画面へ誘導」など、望むUXを具体化
まとめ：止められない仕様は、設計の割り切りと運用の定型化が効く
Microsoft Entra ID のサインインで「前回使った認証方式」が端末間でも既定として使われてしまう挙動は、現時点では管理者側で無効化できる公式設定がありません。特に CBA や Authenticator の電話サインインのようなパスワードレス主認証を併用する構成では、CA設計だけで「毎回サインイン オプション」を出すのは難しいのが現実です。
そのため、現場では次の2本立てが効果的です。
- 事故率を下げる設計：CAの重なりを減らし、想定外の候補を残さない
- 迷子を減らす運用：Teamsモバイルでの「サインイン オプションへ戻る」手順を周知し、問い合わせ対応を定型化する
もし「端末ごとの主認証分離」が絶対要件であれば、要望としてフィードバックを出しつつ、短期的には運用設計で痛点を潰す方が、導入の成功確率は上がります。
コメント