はじめに
「SaaSごとにIDとパスワードが分かれていて管理しきれない」「退職者のアカウントが残っていないか不安」——中小企業の情シスでよくある悩みです。
本記事では、Microsoft Entra ID（旧Azure AD）を使って社員IDを集約し、シングルサインオン（SSO）と多要素認証（MFA） を導入する実務手順を、つまずきどころ込みで整理します。自社で実際に導入・運用した経験をベースに、再現できる粒度で書きました。
対象は Microsoft 365 を使っている（またはこれから契約する）情シス・管理者 です。
先にライセンスの話（ここで「どこまでできるか」が決まる）
機能とライセンスの対応を最初に押さえておくと、手戻りがありません。
| ライセンス | できること |
|---|---|
| Entra ID Free（どのM365にも付属） | ユーザー集約・SSOの個別割り当て・セキュリティ既定値による全員MFA（STEP1〜4＋簡易MFA） |
| Entra ID P1（M365 Business Premium / E3 / E5 に同梱、または単体） | 条件付きアクセス・グループ単位のアプリ割り当て・認証方法の詳細制御（STEP5の本格運用） |
要点は「STEP1〜2と“ざっくり全員MFA”は無料枠でも可能。ただし“締め出さない”きめ細かいMFA制御（条件付きアクセス）はP1が必要」です。
いきなり全社一斉ではなく、現状把握 → 1つのSaaSをSSO化して型を作る → 横展開、が現実的です。
STEP1: 現状を棚卸しする
設定を触る前に、対象を洗い出します。
- 利用中のSaaSと既存アカウントを一覧化（誰がどのサービスを使っているか）
- 各SaaSが SAML / OIDC に対応しているか、SSO対応にプラン条件（上位プラン必須など）が無いか
チェック: サービス×利用者の一覧ができ、SSO化の優先順位が見えている。
STEP2: ユーザーをEntra IDに集約する
管理は entra.microsoft.com から行います（全体管理者権限が必要）。
ID → ユーザー → すべてのユーザー
- M365を使っているなら、その利用者はすでにEntra IDに存在します（M365契約にEntra IDが含まれるため）
- 未登録の社員は「＋新規ユーザー」で追加。オンプレADがある場合は Entra Connect で同期
- 退職者は無効化
チェック: 在籍社員のIDがEntra IDに揃い、退職者が無効化されている。
STEP3: SaaSをSSO化する（まず1つから）
エンタープライズ アプリケーションとして登録します。
アプリケーション → エンタープライズ アプリケーション → ＋新しいアプリケーション
ギャラリーに対象SaaSがあれば選択、無ければ汎用の「独自アプリ」を作成します。
次にSSOを設定します。
シングルサインオン → SAML を選択
SaaS側の情報に合わせて、以下の値を入力します。
- 識別子（Entity ID）
- 応答URL（ACS URL）
- サインオンURL
そして「ユーザーとグループ」で使わせる社員・グループを割り当て、SaaS側にもEntraのメタデータ（証明書・各種URL）を設定します。SAMLは両側に同じ値を設定して初めて繋がる点に注意してください。
チェック: 割り当てた社員が、Entra IDのログインだけで対象SaaSに入れる（個別パスワード不要）。
STEP4: 強い認証方法を有効化する
MFAを必須化する前に、まず「使わせる方式」を整えます。
保護 → 認証方法 → ポリシー
- パスキー（FIDO2） と Microsoft Authenticator を「有効・全員」に
- SMS・音声は無効（フィッシング・SIMスワップに弱いため）
ここで弱い方式を残したままMFA必須化すると、結局フィッシング耐性の無い方式に流れてしまうので、先に整理しておくのがポイントです。
チェック: 強い認証方法が全員に有効化され、弱い方式が無効になっている。
STEP5: MFAを必須化する（条件付きアクセス）
有効化した認証方法を実際に使わせるため、条件付きアクセスで全ユーザーにMFAを要求します。
保護 → 条件付きアクセス → ポリシー
対象: すべてのユーザー（緊急用アカウントは除外）
許可: アクセス権を付与 → 多要素認証を要求する
⚠️ 条件付きアクセスは Entra ID P1 が必要です。P1が無い場合は、無料の「セキュリティ既定値（Security Defaults）」で全員MFAを有効化する簡易策があります（ただし、きめ細かい制御や例外設定は不可）。
さらに管理者は パスキー（耐フィッシングMFA）必須 にすると堅牢です。
最重要の注意: ポリシーは必ず緊急用（break-glass）アカウントを除外してから有効化します。除外を忘れると、設定ミス時に管理者自身も含めて全員がサインインできなくなります。最初は「レポート専用モード」で影響を確認してから有効化すると安全です。
チェック: サインイン時にMFAが要求される。締め出しが無い（緊急用アカウントを除外済み）。
STEP6: 運用・棚卸しのルールを決める
導入して終わりではなく、回し続ける仕組みが必要です。
- 入社・退職に合わせた付与・無効化の手順化（できればグループ＋ライセンス自動付与）
- サインインログを定期確認し、不要な権限・休眠アカウントを棚卸し
- 残りのSaaSも順次SSO化
チェック: 入退社フローと定期棚卸しのルールが文書化され、回り始めている。
つまずきポイントと対処
実際に遭遇しやすいものを挙げます。
-
SaaSがSSOに対応していない／上位プラン必須
→ 当面は パスワードベースSSO（Entraが資格情報を安全に代理入力）で束ねる手があります。完全なSAML連携でなくても「ログインの入口を1つにする」効果は得られます。 -
SAML設定で繋がらない
→ 識別子（Entity ID）・応答URL（ACS）の 綴り・末尾スラッシュの不一致 が定番の原因。https://example.com/acsとhttps://example.com/acs/は別物として扱われます。SaaS側とEntra側で完全一致させてください。 -
同期で重複アカウント
→ オンプレADと既存クラウドIDが二重になることがあります。突合（マッチング）属性（UPN / メール / ImmutableID など）を確認します。 -
MFAで締め出し
→ 緊急用アカウントを条件付きアクセスから除外し、レポート専用モード→段階適用の順で進めます。
完了チェックリスト
- 利用サービス×利用者を棚卸しした
- 社員IDをEntra IDに集約した（退職者は無効化）
- 1つ目のSaaSをSSO化し、SSOログインを確認した
- 強い認証方法（パスキー／Authenticator）を全員有効化、弱い方式を無効化
- 条件付きアクセスでMFAを必須化した（緊急用アカウント除外）
- 入退社フローと定期棚卸しのルールを決めた
おわりに
ID集約は「全部いっぺん」ではなく、1サービスをSSO化して型を作り、横展開するのが結局いちばん早くて安全です。まずは棚卸しと、影響範囲の小さいSaaS1つから始めてみてください。
株式会社ブレインディレクションは、ITソリューション／生成AI／クラウド／セキュリティ支援を行っています（ISMS取得済み）。https://www.brain-d.jp