Microsoft 365 管理センターでユーザーを作成したものの、ライセンスを割り当てていない——この状態はライセンスコンプライアンス違反なのか？結論は「作成だけなら原則問題になりにくいが、利用させた瞬間に違反リスクが跳ね上がる」です。判断基準と安全運用を実務目線で整理します。
結論：未ライセンスのユーザー作成は「基本OK」、ただし利用はNG
Microsoft 365 のライセンスコンプライアンスで最重要なのは、「ユーザーオブジェクトが存在すること」ではなく「そのユーザーがオンラインサービスをアクセス／利用しているか」です。Microsoft のライセンス条項（Product Terms）でも、オンラインサービスについて「アクセスする各ユーザーは、原則としてユーザー単位のサブスクリプションライセンス（User SL）が必要」という考え方が明示されています。
したがって、ユーザーをディレクトリ（Microsoft Entra ID、旧 Azure AD）上に作って“置いておくだけ”で、Exchange Online / SharePoint / Teams などの有償サービスを利用していないのであれば、一般的には違反とは言いにくい整理になります。一方で、未ライセンスのまま有償サービスを使わせたり、ライセンスが前提の機能の恩恵をそのユーザーが受ける状態にすると、監査で説明が難しくなり、違反リスクが高まります。
実務での一言まとめ：「未ライセンスユーザー＝存在しても良い。ただし“使わせない仕組み”がないと危ない」
まず前提を整理：ユーザー、ライセンス、サービスプランは別物
混乱の原因は、Microsoft 365 管理センターでユーザーを作る操作が「Microsoft 365 の利用開始」と同じに見えてしまうことです。実際には、次の3つは役割が違います。
| 要素 | 何を表すか | 代表例 | コンプライアンス上のポイント |
|---|---|---|---|
| ユーザー（Entra ID） | 認証・IDの“入れ物” | 社員、派遣、テスト、緊急用管理者 | 作成だけでは直ちに課金・違反とは限らない。だがサインイン可能だと誤利用が起きやすい。 |
| ライセンス（サブスクリプション） | サービスを使う“利用権” | Microsoft 365、Office 365、Exchange Online など | オンラインサービスへアクセスするユーザーには原則ライセンスが必要。 |
| サービスプラン | ライセンス内の個別機能のON/OFF | Exchange、Teams、SharePoint などの有効化 | 「メールだけ切る」「Teamsだけ切る」など運用に使えるが、設計が甘いと“未割り当てなのに利用”が起きる。 |
Microsoft 365 管理センターでは、ユーザー作成時にライセンスを割り当てず、後から割り当てることもできます（運用としては一般的です）。
コンプライアンス上「適正」になりやすい状態
次のように、“有償サービスを利用していない”ことが明確で、かつ誤用の防止策があるなら、未ライセンスでユーザーを保持する運用は現実的です。
| 用途 | 未ライセンスで置くのが許容されやすい理由 | 最低限のガード |
|---|---|---|
| 将来利用予定の“待機アカウント” | 雇用開始前・配属前など、利用開始していない段階 | サインインをブロック／初回利用時に必ずライセンス付与 |
| 検証用・PoC用アカウント | 検証テナントや期間限定用途で、コストを抑えたい | 検証期間だけ試用版・検証用ライセンスを付け、終了後はサインインブロック＋棚卸し |
| 緊急用管理者（ブレークグラス） | Microsoft も“緊急時のみ使う高権限アカウント”の維持を推奨 | 普段は使わない／監視・アラート／保管ルールを徹底 |
| 外部サービスへのSSO専用（社内アプリなど） | Microsoft 365 の有償ワークロードを使わず、ID基盤としてのみ使う設計 | 利用する Entra 機能が無償範囲か／対象ユーザーが“有償機能の恩恵”を受けないかを確認 |
ポイントは、「未ライセンスのまま放置すること」ではなく、未ライセンスのまま“使われない”ことを証明できる状態にしておくことです。監査では、この“説明可能性”が強い武器になります。
不適正（違反）になり得る条件：見落としがちなNGパターン
未ライセンスユーザーが違反側に寄るのは、ほぼ次のどれかです。
- オンラインサービス（有償）を実際に利用している（サインインして利用、アクセス権を付与して利用、アプリで使用、など）
- そのユーザーが、ライセンスが前提の機能の恩恵を受けている（例：条件付きアクセス、Microsoft Purview の特定機能、など）
- 過去にライセンスが付いていたユーザーを“外しただけ”で、データや機能が残っている（運用ミスで実質利用が継続する）
- “うっかり利用”を誘発する構成（サインイン可能、パスワード共有、メールボックスが作られている、など）
とくに「恩恵を受ける」という観点は見落とされがちです。たとえば条件付きアクセスは、機能としてはテナントに有効化できますが、Microsoft の説明でも利用には Microsoft Entra ID P1 が必要で、対象ユーザーがその機能の恩恵を受けるならライセンスが必要という整理になります。
サービス別：未ライセンス運用で事故が起きやすいポイント
「どのサービスを“使った扱い”になるのか」を、よくある事故ベースで整理します。自社の運用に照らして、該当しそうな行を先に潰すのが効率的です。
| 対象 | ライセンスが必要になりやすい線引き | ありがちな事故 | 対策 |
|---|---|---|---|
| Exchange Online（メール） | サービスにアクセスするユーザーはサブスクリプションが必要。ユーザー単位のメールボックス運用が前提。 | 未ライセンスのはずがメールボックスが作られ、送受信していた／共有パスワードで運用していた | ユーザーにメールボックスを持たせない。共有用途は“共有メールボックス”など非ユーザー型を検討（容量要件に注意）。 |
| SharePoint / OneDrive | SharePoint/OneDrive の利用（閲覧だけでも“アクセス”）は基本的にライセンス前提 | 未ライセンスのユーザーにサイト閲覧権限だけ付けたつもりが、監査上は利用と判断される | 未ライセンスユーザーはサインインブロック。どうしても閲覧させるならライセンスを割り当てる。 |
| Teams | Teams を利用するには Teams を含むサブスクリプション／ライセンスが前提（アドオン含む）。 | 未ライセンスで Teams にログインできてしまい、社内的に“使えている”状態が続く | ライセンス未割り当てユーザーはサインインブロック＋定期棚卸し。Teams 利用開始日に必ず割り当て。 |
| Microsoft Purview（コンプライアンス機能） | Purview のポリシーや機能を SharePoint サイト・M365 グループ・Teams 等に適用する場合、所有者/メンバーには必要ライセンスが求められる、という整理が明示されている。 | 「テナント側でDLPや保持を入れたからOK」と思い、未ライセンスユーザーにまで機能が及んでいた | Purview を適用する範囲（サイト・チーム・ユーザー）と、対象ユーザーのライセンスをセットで管理する。 |
| Microsoft Entra 条件付きアクセス | 機能自体の利用に P1 が必要で、対象ユーザーが恩恵を受けるならユーザー単位のライセンスが必要という整理。 | 未ライセンスユーザーも「全ユーザー対象」の条件付きアクセスに含めていた | 未ライセンスユーザーを対象外にするか、対象に含めるなら必要ライセンスを割り当てる。 |
| Entra ロール（権限管理） | 組み込みロールは無償だが、カスタムロールは P1 が必要など、機能ごとに要件がある。 | “管理用アカウント”として未ライセンスで運用し、知らないうちに要件のある機能（カスタムロール等）を使っていた | 管理者の役割設計を見直し、必要な機能を使う管理者には適切なライセンスを付与する。 |
安全運用のコツ：未ライセンスユーザーは「誤って使えない」設計にする
未ライセンスアカウントを“置く”運用自体はあり得ますが、事故が起きるのはたいてい「使えてしまう状態」が残っているからです。ここでは、現場で効くガードを優先度順に紹介します。
サインインをブロックする
最も効果が高く、説明もしやすい対策がサインインブロックです。Microsoft 365 管理センターから対象ユーザーを選び「Block sign-in（サインインのブロック）」を設定できます。
- 未ライセンスユーザーは原則ブロック（“利用開始”時に解除）
- ブロック解除は申請制にする（人事異動・入社日・配属日などのトリガー）
- ブロック解除と同時にライセンスを割り当てる（「解除だけ」にならないよう運用手順に組み込む）
命名規則とグループ分離で“見える化”する
棚卸しで見落とさないために、未ライセンスユーザーは命名規則を揃えると効果的です。例として、接頭辞で用途を区別します。
| 例 | 用途 | 運用ルール |
|---|---|---|
| NL-PreHire-xxxx | 入社前の待機 | 入社日にライセンス付与＆サインイン許可 |
| NL-Lab-xxxx | 検証 | 期限を必ず設定（期限後は削除またはブロック維持） |
| BG-GlobalAdmin-01 | 緊急用管理者 | 緊急時のみ使用。監視・アラート必須。 |
さらに、未ライセンスユーザーを専用グループに集約し、棚卸し（フィルタ）で一発で出せる状態にしておくと、監査対応がラクになります。
ライセンス割り当ては“人”ではなく“グループ”で管理すると事故が減る
運用が大きくなるほど、人手での個別割り当てはミスが増えます。Microsoft 365 管理センターには「後から割り当て・後から解除」の導線があり、運用設計を作りやすいので、ルール化しておくのが得策です。
- 入社・異動で所属グループが変わる＝自動で必要ライセンスが付く（または付ける判断がしやすい）
- 退職・休職はグループから外す＝ライセンス解除（＋サインインブロック）
- 管理者アカウントは別グループで管理し、一般ユーザーと混ぜない
監査で強い「説明の型」：未ライセンスでも適正と言える根拠を残す
監査は「結局、未ライセンスで使っていないの？」という一点に収束します。そこで、次のような証跡（ログ・運用記録）を残しておくと説明が通りやすくなります。
| 証跡にしたいもの | 目的 | 例 | メモ |
|---|---|---|---|
| サインインブロック設定 | “使えない”状態の証明 | 対象ユーザーは Block sign-in が有効 | ブロック設定の手順自体が Microsoft Learn に明記されている点も説明材料になる。 |
| サインインログ | “使っていない”の証明 | 未ライセンスユーザーのサインインがゼロ | ブロック解除の例外があれば理由と期間を残す |
| ライセンス割り当て履歴 | 付与・解除の統制 | いつ誰が付与/解除したか | 運用フロー（申請→承認→実施）と紐づける |
| 利用実績レポート | 有償ワークロード未利用の確認 | Exchange/Teams/SharePoint の利用がない | 「未ライセンス＝未利用」を定期点検に落とし込む |
実務向けチェックリスト：未ライセンスユーザーを棚卸しするときの観点
未ライセンスユーザーが増えるほど、リスクは「違反」よりも「誤用（インシデント）」に寄ります。棚卸しは次の観点で行うと抜けにくいです。
| チェック観点 | OKの目安 | NGのサイン | すぐ打つ手 |
|---|---|---|---|
| サインイン可否 | ブロックされている | 許可になっている／解除理由が不明 | 即ブロック＋パスワードリセット |
| 権限（グループ・役割） | 用途に必要な最小権限 | 管理者権限が付いているのに運用手順がない | 権限剥奪＋緊急用なら手順整備 |
| 有償サービスの痕跡 | 利用ログがない | Teams/SharePoint/Exchange に利用痕跡 | 利用停止＋必要ライセンスの割り当てを検討 |
| Purview/条件付きアクセス等の対象 | 対象外、または適切にライセンス付与済み | “全ユーザー対象”に含まれている | 対象外にするかライセンス付与（要件確認） |
| 期限 | 用途に期限がある（例：入社日まで） | 用途不明で長期放置 | 削除／無効化／担当者確認 |
よくある質問
未ライセンスユーザーを作るだけで料金や契約違反になりますか？
ユーザーオブジェクトの作成だけで直ちに“利用”とは限りません。問題になるのは、オンラインサービスをアクセス／利用する状態（または有償機能の恩恵を受ける状態）にしているかどうかです。条項の考え方としても、オンラインサービスは「アクセスするユーザーにライセンスが必要」という枠組みです。
「使っていない」つもりでも違反になるのはどんなとき？
サインインが許可されていて、本人や第三者がログインできる状態だと“つもり”が崩れます。未ライセンスで運用するなら、まずサインインブロックを標準にして事故を物理的に防ぐのが安全です。
緊急用管理者（ブレークグラス）は未ライセンスでいいですか？
緊急用管理者は Microsoft 自身が推奨している運用の一つで、通常の業務利用を想定しない“最後の鍵”です。重要なのはライセンスの有無よりも、緊急時以外に使わない設計、監視、そして条件付きアクセスの設計（除外の扱いを含む）です。
共有メールボックスはライセンス不要と聞きました。未ライセンス運用の代替になりますか？
共有メールボックスや会議室などの“非ユーザー型メールボックス”は、一般にユーザー単位のサブスクリプションが不要とされ、ライセンス運用の選択肢になります。ただし容量が一定（例：50GB）を超える場合は追加ライセンスが必要になるなど、条件があります。
Microsoft Purview のポリシーをテナントに入れている場合、未ライセンスユーザーは気にしなくて良い？
Purview は“テナントに機能がある”だけではなく、「どの場所（サイト、チーム等）にポリシーを適用し、誰がそれを利用／恩恵を受けるか」でライセンス要件が絡みます。所有者/メンバーにライセンスが求められる、という考え方も明示されているため、対象範囲とユーザーライセンスをセットで管理してください。
まとめ：未ライセンスを“違反にしない”ための最短ルート
未ライセンスユーザーを作成して保持すること自体は、運用として珍しくありません。ですが、監査・セキュリティ・運用事故の観点からは、「使わせない設計」「使っていない証跡」「使うときに必ずライセンス付与」の3点セットがないと、すぐに危険側へ傾きます。
- 未ライセンスは原則サインインブロック（解除と同時にライセンス付与）
- “全ユーザー対象”の有償機能（条件付きアクセス、Purview 等）に含めていないか確認
- 用途・期限・責任者を残し、定期棚卸しで説明可能性を維持
自社の契約形態（MCA、EA など）や利用している機能により要件は変わり得ます。最終判断は Product Terms と Microsoft Learn のサービス説明を一次情報として確認し、必要に応じて販売パートナー／法務とすり合わせるのが確実です。
コメント