Microsoft EntraのSMS-based user sign-inを2026年4月時点で見直すなら、結論は「全社標準の認証方式として広げる」のではなく、フロントラインワーカー向けに限定し、対応アプリ・ライセンス・代替認証への移行計画を確認してから有効化することです。SMSベースのサインインは、ユーザー名やパスワードを入力せず、登録済み電話番号とSMSで届くワンタイムパスコードでMicrosoft Entra IDにサインインできる方式です。一方で、Microsoftはパスキー、Windows Hello for Business、証明書ベース認証など、フィッシングに強い認証方式への移行も推奨しています。(Microsoft Learn)
特にsecurity admins、identity teams、compliance teamsが見るべきポイントは、SMSサインインを「便利なパスワードレス」とだけ捉えないことです。Microsoft LearnのSMSサインイン設定ページは、SMSベース認証を主に現場担当者向けのサインイン簡素化手段として位置付け、インフォメーションワーカーには推奨しないと説明しています。2026年4月23日に更新された関連公式ページでは、SMSベース認証をサポートするアプリとサポート外アプリの整理も確認できます。(Microsoft Learn)
Microsoft EntraのSMS-based user sign-inとは
Microsoft Entra IDのSMS-based user sign-inは、ユーザーが電話番号を入力し、SMSで届いた6桁コードを使ってサインインする認証方法です。通常のSMS MFAのように「ユーザー名とパスワードを入力した後にSMSを追加要素として使う」方式とは異なり、SMSを第1要素として利用できる点が特徴です。(Microsoft Learn)
たとえば、小売店舗、倉庫、工場、医療・介護現場などで、従業員が共有端末からTeamsや業務アプリへ短時間でアクセスするケースでは、長いUPNや複雑なパスワードを入力させるより、電話番号とSMSコードのほうが運用しやすい場合があります。
ただし、SMSサインインは「強力な認証方式」ではなく、「特定の現場業務でサインイン体験を簡素化する方式」として評価すべきです。SMSコードはフィッシングやソーシャルエンジニアリングの対象になり得るため、管理者権限を持つユーザー、機密データを扱うユーザー、どこからでもアクセスする情報系ユーザーには、パスキーやFIDO2セキュリティキーなどのフィッシング耐性のある認証方式を優先するのが現実的です。(Microsoft Learn)
2026年4月更新で押さえるべきポイント
2026年4月時点のMicrosoft Entra SMSサインイン関連ドキュメントで重要なのは、単に設定手順を確認することではありません。実務上は、次の3点を先に判断する必要があります。
| 確認ポイント | 実務での意味 | 管理者が取るべき対応 |
|---|---|---|
| 対象ユーザー | SMSサインインは主にフロントラインワーカー向け | 全社展開ではなく、店舗・現場・共有端末利用者などに限定する |
| 対応アプリ | すべてのMicrosoft 365アプリで使えるわけではない | 対象業務アプリがSMSサインインに対応しているか事前検証する |
| セキュリティ方針 | Microsoftはフィッシング耐性のある認証への移行を推奨 | SMSは暫定・限定用途とし、QRコード認証やパスキーへの移行余地を残す |
関連するアプリサポートページでは、SMSベース認証はMicrosoft identity platformと統合されたMicrosoftアプリで利用できると説明されています。一方、Microsoft 365デスクトップアプリや、直接アクセスする一部のMicrosoft 365 WebアプリではSMSサインインをサポートしないことも明記されています。(Microsoft Learn)
SMSサインインとSMS MFAの違い
SMSサインインを検討する際に最も多い誤解は、「SMS MFAを有効にしているからSMSサインインも使える」というものです。両者は似ていますが、用途も設定も異なります。
| 項目 | SMS-based user sign-in | SMS MFA |
|---|---|---|
| 使い方 | 電話番号とSMSコードでサインイン | パスワード入力後の追加確認としてSMSを使う |
| 主な対象 | フロントラインワーカー、共有端末利用者 | 一般的な多要素認証の一方式 |
| ユーザー名・パスワード | 不要 | 通常は必要 |
| 導入目的 | サインイン操作の簡素化 | パスワード認証への追加保護 |
| 注意点 | Microsoft Entra MFAとは互換性がない既知の制約がある | SMS自体はフィッシング耐性が高い方式ではない |
Microsoft Learnでは、SMSベース認証はMicrosoft Entra SMS多要素認証とは異なる方式であり、通常のSMS MFAではユーザー名、パスワード、SMSが必要になると説明されています。また、既知の問題として、SMSベース認証はMicrosoft Entra多要素認証と互換性がないことも示されています。(Microsoft Learn)
この違いを理解せずに展開すると、条件付きアクセス、MFA登録、セルフサービスパスワードリセット、ユーザー教育の設計がちぐはぐになります。導入前に「このユーザーはSMSを第1要素として使うのか、それともMFAの一手段として使うのか」を明確に分けてください。
SMSサインインが向いているケース、避けるべきケース
SMSサインインは、使いどころを絞れば現場業務の摩擦を減らせます。しかし、認証強度だけを見ると最優先の方式ではありません。導入判断は、ユーザー属性と利用アプリで分けるのが安全です。
向いているケース
SMSサインインが向いているのは、次のようなケースです。
- 店舗、倉庫、工場などのフロントラインワーカーが共有端末を使う
- 業務アプリへのアクセス頻度が高く、パスワード入力が現場負荷になっている
- 利用アプリがSMSサインインに対応している
- 管理者がユーザーの電話番号を正しく管理できる
- 将来的にQRコード認証やパスキーへ移行する計画がある
Microsoftは、フロントラインワーカーの保護に関するベストプラクティスとして、MDM、共有デバイスモード、アプリ保護ポリシー、条件付きアクセス、デバイス準拠などのセキュリティ制御を組み合わせることを推奨しています。SMSサインインを使う場合も、認証方式だけで安全性を担保しようとせず、デバイスとアクセス制御をセットで設計する必要があります。(Microsoft Learn)
避けるべきケース
次のようなユーザーには、SMSサインインを安易に割り当てないほうがよいでしょう。
- 管理者、特権ロール保持者、セキュリティ担当者
- 財務、人事、法務など機密性の高いデータを扱うユーザー
- 社外・自宅・出張先など場所を問わず広範囲にアクセスする情報系ユーザー
- B2Bアカウント
- テナント間同期の対象ユーザー
- ネイティブOfficeアプリ中心で業務を行うユーザー
Microsoft Learnでは、SMSベース認証はB2Bアカウントをサポートしないこと、テナント間同期ではSMSサインインが有効なユーザーをサポートしないこと、Teamsを除きネイティブOfficeアプリケーションとの互換性がないことが既知の問題として挙げられています。(Microsoft Learn)
対応アプリの確認は必須
SMSサインインの導入で失敗しやすいのは、「Microsoft 365なら全部使えるだろう」と判断してしまうことです。実際には、アプリのサインイン経路によって対応可否が変わります。
2026年4月23日に更新されたMicrosoft Learnのアプリサポートページでは、Office 365 – Microsoft Online Services、Microsoft OneNote、Microsoft Teams、Company Portal、My Apps portal、Microsoft Forms、Microsoft Edge、Power BI、Stream、Power Apps、Microsoft Azure、Azure Virtual Desktopなどのサポート状況が整理されています。サポートされる理由として、これらのアプリがユーザーに電話番号とSMSコードを入力させられるMicrosoft Identityのログインを使う点が説明されています。(Microsoft Learn)
一方で、Microsoft 365デスクトップアプリや、Word、Excel、PowerPoint、Outlookなどに直接Webアクセスするケースでは注意が必要です。公式ページでは、Microsoft 365デスクトップアプリや一部の直接アクセス型Microsoft 365 WebアプリはSMSサインインをサポートしないと説明されています。(Microsoft Learn)
導入前の検証では、次のように「アプリ名」ではなく「実際のアクセス経路」で確認してください。
| 検証項目 | 確認例 |
|---|---|
| Webブラウザー経由か | office.com、My Apps、Teams Webなど実際のURLで確認する |
| ネイティブアプリか | Teams、Officeデスクトップ、モバイルアプリで挙動が異なるか確認する |
| 認証画面の種類 | Microsoft Identityログインに遷移するか確認する |
| 業務アプリ連携 | SAML、OIDC、Microsoft Entraアプリケーションプロキシ経由の認証を確認する |
| 代替手段 | SMS不可時にパスキー、Authenticator、QRコード認証へ切り替えられるか確認する |
有効化前の前提条件
SMSベース認証を有効化するには、Microsoft Entraテナント、適切な管理者ロール、対象ユーザーのライセンスが必要です。公式手順では、SMSベース認証を有効にするには少なくともAuthentication Policy Administratorロールが必要であり、SMS認証方法ポリシーで有効化された各ユーザーには、利用しない場合でも対象ライセンスが必要とされています。(Microsoft Learn)
特に大規模展開で見落としやすいのがライセンスです。グループ単位で一気に対象化すると、実際には使っていないユーザーまでライセンス要件の対象になります。まずは検証用グループを作り、対象者、利用アプリ、端末、サポート窓口を限定して進めるのが安全です。
導入前チェックリスト
| チェック項目 | 確認内容 |
|---|---|
| 対象ユーザー | フロントラインワーカーに限定しているか |
| 対象グループ | テスト用のMicrosoft Entraグループを用意しているか |
| ライセンス | Microsoft 365 F1/F3、Microsoft Entra ID P1/P2など対象ライセンスを確認したか |
| 管理ロール | Authentication Policy AdministratorまたはAuthentication Administratorの役割分担を決めたか |
| 電話番号 | 国番号付きで登録し、テナント内で重複していないか |
| 対応アプリ | 実際に利用するアプリでSMSサインインを検証したか |
| 代替認証 | SMSが届かない場合の回復手順を用意したか |
| 監査 | 変更作業とユーザー割り当てを記録する運用にしているか |
基本的な設定手順
SMSサインインの有効化は、大きく分けて3段階です。認証方法ポリシーを有効化し、対象ユーザーまたはグループを選び、各ユーザーに電話番号を割り当てます。Microsoft Learnでも、この3つが主要手順として整理されています。(Microsoft Learn)
認証方法ポリシーを有効化する
Microsoft Entra管理センターで、少なくともAuthentication Policy Administratorとしてサインインします。次に、Entra IDの「Authentication methods」から「Policies」に移動し、SMSを選択します。
ここで重要なのは、SMSを単に有効化するだけではなく、Use for sign-inに相当する「サインインに使用」の設定を確認することです。公式手順では、このチェックを入れることでSMSベース認証を第1要素のサインイン方法として構成でき、オフのままだとMFAやセルフサービスパスワードリセット用途になると説明されています。(Microsoft Learn)
対象ユーザーまたはグループを選ぶ
最初から「All users」を選ぶのは避けてください。Microsoft Learn上はすべてのユーザーまたはグループを選択できると説明されていますが、実務では検証グループから始めるべきです。理由は、ライセンス、対応アプリ、電話番号の重複、サポート問い合わせを同時に確認する必要があるためです。(Microsoft Learn)
おすすめは、次のような段階的展開です。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | IT部門、店舗代表者、現場管理者 | 設定、アプリ対応、サポート手順を確認 |
| パイロット | 1拠点または1部門 | 実運用でのSMS到達性、端末利用、問い合わせ傾向を確認 |
| 限定展開 | フロントラインワーカーの対象グループ | 業務影響を抑えながら利用範囲を広げる |
| 見直し | 利用ログと問い合わせを確認 | QRコード認証やパスキーへの移行判断を行う |
電話番号をユーザーに登録する
ユーザーがSMSサインインを利用するには、Microsoft Entra IDのユーザープロファイルに電話番号を関連付ける必要があります。電話番号はMy Accountでユーザー自身が設定することも、Microsoft Entra管理センターで管理者が設定することもできます。管理者が設定する場合は、少なくともAuthentication Administratorロールが必要です。(Microsoft Learn)
電話番号は国コードを含めて登録し、テナント内で一意でなければなりません。同じ電話番号を複数ユーザーに使おうとするとエラーになります。共有スマートフォンや店舗共用携帯を使っている組織では、この点が導入時の大きな制約になります。(Microsoft Learn)
Microsoft Graphでの管理も検討できる
大規模テナントでは、管理センターだけで個別に操作するより、Microsoft Graph APIやPowerShellを使って有効化・無効化を自動化したほうが現実的です。Microsoft Graphには、既存のmobile電話番号に対してSMSサインインを有効化するenableSmsSignIn、無効化するdisableSmsSignInが用意されています。(Microsoft Learn)
ただし、Graph APIで有効化するには、電話番号のphoneTypeがmobileであること、SMSサインインシステム内で電話番号が一意であること、ユーザーが認証方法ポリシーでSMSサインインの対象になっていることが必要です。(Microsoft Learn)
グローバル企業ではクラウド環境の違いにも注意してください。Microsoft GraphのSMSサインイン有効化・無効化APIはGlobal service、US Government L4、US Government L5では利用可能とされていますが、China operated by 21Vianetには対応していないとされています。(Microsoft Learn)
トラブルシューティングで見落としやすい点
SMSサインインで問題が起きた場合、まず見るべきなのは「SMSが届くか」ではありません。多くの原因は、ポリシー対象、電話番号形式、電話番号の重複、既存の認証方法との関係にあります。
| 症状 | よくある原因 | 確認すること |
|---|---|---|
| 電話番号を設定できない | 対象ユーザーがSMS認証方法ポリシーに含まれていない | 対象グループ、ポリシー保存状態、管理ロールを確認 |
| SMSサインインが有効にならない | 電話番号形式が不正 | 国番号を含む形式で登録しているか確認 |
| エラーが出る | 同じ電話番号が別ユーザーで使われている | テナント内の電話番号重複を確認 |
| 既存の電話番号が使えない | MFAやSSPRで登録済みの番号が自動的にSMSサインイン用にならない | SMSサインイン用として明示的に設定する |
| Officeアプリで使えない | アプリがSMSサインイン非対応 | 対応アプリ一覧と実際のサインイン経路を確認 |
Microsoft Learnでは、既にMFAやSSPRで電話番号が関連付けられていても、その番号がSMSベースサインインで自動的に利用可能になるわけではないと説明されています。また、エラー時の確認点として、SMSサインインの有効化、対象ユーザーのポリシー適用、電話番号の形式、重複、音声番号の設定確認が挙げられています。(Microsoft Learn)
QRコード認証やパスキーとの使い分け
2026年4月時点での実務判断として、SMSサインインを単独の最終形にしないことが重要です。Microsoft Entraには、フロントラインワーカー向けの代替アプローチとしてQRコード認証もあります。QRコード認証は、認証方法ポリシーで有効化し、ユーザーがQRコードとPINでサインインできる方式として説明されています。(Microsoft Learn)
共有デバイス中心の現場では、SMSよりQRコード認証のほうが運用に合う場合があります。たとえば、従業員が個人スマートフォンを持ち込めない工場、電話番号の管理が難しい短期スタッフ、端末を複数人で使う店舗では、QRコードとPINのほうが管理しやすいことがあります。
一方、情報系ユーザーや特権ユーザーには、パスキーやFIDO2セキュリティキーを優先すべきです。Microsoftのパスキー解説では、パスキーはSMSやメールコードのようなフィッシング可能な方式を置き換えるものとして説明され、公開鍵暗号に基づく仕組みによって認証情報の再利用や共有を防ぐ設計が示されています。(Microsoft Learn)
| 認証方式 | 向いている対象 | 主なメリット | 注意点 |
|---|---|---|---|
| SMSサインイン | フロントラインワーカー、限定的な現場利用 | 電話番号とコードでサインインしやすい | SMSはフィッシング耐性が高い方式ではない |
| QRコード認証 | 共有デバイス、店舗・現場端末 | 電話番号に依存しにくい | QRコードとPINの配布・失効管理が必要 |
| パスキー/FIDO2 | 情報系ユーザー、特権ユーザー、高リスク業務 | フィッシング耐性が高い | デバイス・登録・回復手順の設計が必要 |
| Windows Hello for Business | 会社管理Windows端末のユーザー | 端末とユーザーを結び付けやすい | Windows端末管理が前提になりやすい |
| 証明書ベース認証 | 規制産業、厳格な本人確認が必要な環境 | 強固な認証設計に向く | 証明書ライフサイクル管理が必要 |
コンプライアンス部門が確認すべき観点
compliance teamsがSMSサインインを評価する場合は、「SMSを使っているか」だけでなく、誰に、どの業務で、どの期間、どの代替策と併用しているかを確認する必要があります。
特に確認したいのは次の点です。
- SMSサインインの対象ユーザーが職務上必要な範囲に限定されているか
- 特権ユーザーや機密データ取扱者が対象外になっているか
- 電話番号の登録・変更・削除の承認フローがあるか
- 退職・異動・端末紛失時にSMSサインインを無効化する手順があるか
- 対応アプリと非対応アプリを利用部門へ説明しているか
- 将来的なフィッシング耐性認証への移行方針があるか
SMSサインインは、現場の利便性を上げる一方で、電話番号という個人情報に近い属性を認証に使います。個人所有端末の利用、電話番号の管理主体、退職後の番号再利用、国や地域ごとの通信事情も、グローバル展開では確認が必要です。
導入時のおすすめ運用設計
実務では、次の順序で進めると失敗しにくくなります。
| 手順 | やること | 成功条件 |
|---|---|---|
| 現状整理 | 対象ユーザー、端末、アプリ、勤務形態を分類 | SMSが必要な現場業務が明確になる |
| リスク評価 | 管理者、機密データ利用者、B2B、同期対象を除外 | 高リスクユーザーにSMSを割り当てない |
| 小規模検証 | テストグループでSMSサインインを有効化 | サインイン、アプリ対応、問い合わせ対応を確認 |
| 運用設計 | 電話番号登録、変更、無効化、紛失時対応を定義 | ヘルプデスクが手順通りに対応できる |
| 展開 | 拠点または部門単位で段階展開 | 業務影響と失敗パターンを抑えられる |
| 見直し | 利用状況とセキュリティ要件を定期確認 | QRコード認証やパスキーへの移行判断ができる |
ここで大切なのは、SMSサインインを「設定して終わり」にしないことです。Microsoft Entraの認証方式は、脅威動向、アプリ対応、ライセンス、端末管理方針によって最適解が変わります。SMSは現場の入口を簡単にする手段として使い、組織全体の認証基盤はフィッシング耐性のある方式へ寄せていくのが、2026年4月時点での現実的な運用方針です。
まとめ：SMSサインインは限定利用し、移行計画とセットで管理する
Microsoft EntraのSMS-based user sign-inは、フロントラインワーカーのサインイン体験を簡素化するうえで有効な選択肢です。ただし、すべてのユーザーやすべてのMicrosoft 365アプリに向くわけではありません。Microsoft公式ドキュメントでも、フィッシングに強い認証方式への移行、対象ユーザーの限定、対応アプリの確認、既知の制約が明確に示されています。(Microsoft Learn)
次に取るべき行動はシンプルです。まず、SMSサインインを必要とする現場ユーザーと利用アプリを洗い出してください。次に、テストグループでポリシー、電話番号、対応アプリ、トラブル対応を検証します。そのうえで、SMSを恒久的な標準認証にするのではなく、QRコード認証やパスキーなど、より強い認証方式への移行計画とセットで運用することが重要です。
コメント