Microsoft 365 / Azure（現 Microsoft Entra ID）のテナントを作成すると、必ず @tenant.onmicrosoft.com という初期ドメインが付き、ユーザーにも onmicrosoft のメールアドレスが自動でぶら下がります。管理者としては残しておきたい一方で、学生などの利用者には見せたくない……という教育機関は非常に多いです。本記事では、この onmicrosoft アドレスを「消さずに、使わせず、ほぼ見えなくする」ための考え方と具体設定をまとめます。
onmicrosoft メールアドレスとは何か？まずは正体を整理する
最初に、そもそも @tenant.onmicrosoft.com とは何者なのかを整理しておきます。ここを曖昧なままにすると、不要な削除や危険な変更につながりがちです。
テナント作成時に必ず付いてくる「初期ドメイン」
Microsoft 365 / Entra ID テナントを新規作成すると、必ず xxxxx.onmicrosoft.com という初期ドメインが付与されます。このドメインはテナントを一意に識別するための「裏の名前」であり、テナント削除まで原則として存在し続けます。
ユーザーを作成すると、多くのケースで次のような状態になります。
- サインイン名（UPN）：
[email protected] - メールアドレス：
[email protected]が自動付与 - 後から自校ドメイン（例：
@schooldistrict.edu）を追加し、そこに切り替えることが多い
ここでポイントになるのが、「サインイン名（UPN）」と「メールアドレス（SMTP / エイリアス）」は別物だという点です。
| 項目 | 意味 | 代表的な属性名 | ユーザーからの見え方 |
|---|---|---|---|
| UPN（サインイン名） | Microsoft Entra ID にログインするときの ID | UserPrincipalName | サインイン画面の「ユーザー名」欄など |
| 既定メールアドレス | メールの送受信で名乗るアドレス | ProxyAddresses の SMTP: | Outlook の「差出人」、GAL、連絡先など |
| 副メールアドレス（エイリアス） | 同じメールボックスに届く追加アドレス | ProxyAddresses の smtp: | 通常はユーザーにはほぼ意識されない |
onmicrosoft アドレスは、この「副メールアドレス（エイリアス）」として保持しておくのがベストプラクティスです。メールの送信元としては自校ドメインを既定にし、onmicrosoft は裏方専用にします。
なぜ消さない方が良いのか（むしろ残したい理由）
「学生に見せたくないなら消してしまえばいいのでは？」と考えたくなりますが、実務では次のような理由で消さない方が安全です。
- テナント内部で一意な ID として扱いやすい
- 将来のドメイン変更（学校統合・名称変更など）時に、古いドメインと切り分ける軸として便利
- 移行作業・トラブルシュート時に、「最初から存在するアドレス」として参照しやすい
- サインイン名や既定アドレスを自ドメインに切り替えておけば、通常運用では onmicrosoft が露出しない
特に教育委員会や大学など、組織改編やドメイン変更が将来発生しうる環境では、onmicrosoft を「テナントの背番号」のように大切に温存しておくと、後々自分を助けることが多いです。
「onmicrosoft を保ちつつ学生にはほぼ見せない」設計の全体像
目指したいゴールはシンプルです。
- 学生が使うのは 自校ドメインだけ
- onmicrosoft はあくまで バックエンド用の隠しアドレス
- そのうえで セキュリティ（MFA / 条件付きアクセス） もきちんと担保
これを実現するための主要なアクションを、一覧で整理すると次のようになります。
| やりたいこと | 具体的な設定 | 主な設定場所 | 備考 |
|---|---|---|---|
| 対外的なメールアドレスを自ドメインに統一 | Primary SMTP を @schooldistrict.edu に設定 | Exchange Online 管理センター / PowerShell | onmicrosoft はエイリアスとして残す |
| サインイン名も自ドメインに統一 | UPN を @schooldistrict.edu に変更 | Entra 管理センター / Graph PowerShell | 学生が onmicrosoft を目にする機会をさらに減らす |
| アドレス帳に余計なアカウントを出さない | HiddenFromAddressListsEnabled で GAL 非表示 | Exchange Online 管理センター / PowerShell | サービスアカウント・共有メールボックス向け |
| エイリアスでのサインインを抑制 | 「メールアドレスでのサインイン（Email as alternate login ID）」の運用方針を決める | Entra 管理センター / Graph PowerShell | ProxyAddresses をログイン ID に使う機能。慎重に設計する必要あり |
| 全体の防御力を底上げ | MFA と条件付きアクセスで保護 | Entra 管理センター | 特に管理者・特権アカウントから必須化 |
以下では、これらを順番に深掘りしていきます。
既定メールアドレスを自ドメインにする（onmicrosoft は副アドレスのまま）
まず最優先でやるべきは、Primary SMTP（既定の送受信アドレス）を自ドメインにしておくことです。これを変えずに onmicrosoft を消そうとするより、はるかに安全で効果的です。
Primary / Secondary の考え方
Exchange Online では、メールアドレスは ProxyAddresses 属性に次のように格納されます。
SMTP:[email protected]… 既定の送受信アドレス（大文字）smtp:[email protected]… 副アドレス（小文字）
このように設定しておけば、
- ユーザーがメールを送るときの差出人アドレスは常に
@schooldistrict.edu - 受信は
@schooldistrict.eduでも@tenant.onmicrosoft.comでも同じメールボックスに届く - ユーザーが onmicrosoft の存在を意識する必要はほぼない
PowerShell での設定例
Exchange Online 管理 PowerShell に接続し、対象ユーザーの既定アドレスを切り替えます。
Connect-ExchangeOnline
# 例：既定を自ドメインにし、onmicrosoft を副アドレスにする
Set-Mailbox -Identity [email protected] `
-EmailAddresses 'SMTP:[email protected]','smtp:[email protected]'
大量のユーザーに一括適用する場合は、CSV などと組み合わせます。
# targets.csv に UserPrincipalName 列を用意しておく
Import-Csv .\targets.csv | ForEach-Object {
$upn = $_.UserPrincipalName
# ここでは例としてローカル部をそのまま使う
$local = $upn.Split('@')[0]
$primary = "[email protected]"
$onmicrosoft = "[email protected]"
Set-Mailbox -Identity $upn `
-EmailAddresses "SMTP:$primary","smtp:$onmicrosoft"
}
メールフローが落ち着いたタイミングで実行し、テストユーザーで送信・受信テストをしてから全体展開すると安心です。
サインイン名（UPN）も自ドメインに統一する
次に、サインイン名（UPN）を自ドメインにそろえることで、学生が onmicrosoft を目にする機会を大幅に減らせます。
UPN を変えると何が起きるか
UPN を [email protected] から [email protected] に変更すると、以下が変わります。
- ブラウザー / Office クライアントのサインイン画面で入力する ID が自ドメインになる
- Teams や OneDrive などで表示されるアカウント名も、自校ドメインのメールアドレスと一致させやすくなる
- 運用マニュアル・学生向け案内は「メールアドレスでサインインしてください」で統一できる
一方で、既存の端末やアプリに一時的な再サインインが必要になるケースもあるため、学期の切り替え前など、計画されたタイミングで実施するのがおすすめです。UPN 変更時の一般的な注意点として、テストユーザーでの事前検証やユーザーへの周知が重要であることは、ハイブリッド環境向けのベストプラクティスでも繰り返し言及されています。
Graph PowerShell による UPN 変更例
クラウド専用ユーザーであれば、Microsoft Graph PowerShell から次のように変更できます。
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes User.ReadWrite.All
# 例： [email protected] → [email protected]
Update-MgUser -UserId '[email protected]' `
-UserPrincipalName '[email protected]'
オンプレ AD と同期している環境では、基本的には オンプレ側の UPN を変更し、Entra Connect で同期するのが正攻法です。その場合は、AD 側の変更手順・影響範囲の検証・ロールバックプランも合わせて設計してください。
UPN とメールアドレスをそろえるかどうか
「サインイン名＝メールアドレス」の構成は、ユーザーにとって非常にわかりやすい一方で、組織によっては
- ログイン ID は学籍番号、メールアドレスは氏名ベース
- 職員と学生でドメインや命名規則を変えたい
など、完全一致させない方が都合が良いパターンもあります。この場合でも、
- UPN は
[email protected] - メールアドレスは
[email protected]
のように、ドメイン部分だけは共通にしておくと、学生側から onmicrosoft を意識させずに運用できます。
メールボックス単位で GAL から隠す：サービスアカウントなどへの適用
「onmicrosoft のアドレスだけをアドレス帳から消したい」という相談をよく受けますが、Exchange Online の仕様上、エイリアス単位で GAL から隠すことはできません。隠せるのはあくまで「受信者（メールボックス）単位」です。
HiddenFromAddressListsEnabled の使いどころ
次のようなアカウントに対しては、GAL から非表示にする運用が一般的です。
- アプリケーションから利用するサービスアカウント
- 共有メールボックスのうち、ユーザーが直接宛先に指定しないもの
- システム用途のダミーユーザー
PowerShell からの設定例は次の通りです。
# 個別設定
Set-Mailbox -Identity '[email protected]' `
-HiddenFromAddressListsEnabled $true
# CSV で一括設定
Import-Csv .\hidden-mailboxes.csv | ForEach-Object {
Set-Mailbox -Identity $_.UserPrincipalName `
-HiddenFromAddressListsEnabled $true
}
この設定を有効にすると、Outlook / OWA のアドレス帳検索や GAL からは完全に見えなくなります。代わりに、送信側が明示的にアドレス文字列を入力すれば送信自体は可能です。
学生ユーザー全員に対してこの設定を行うと、教員側のアドレス帳からも学生が消えてしまうため、実務上はあまり現実的ではありません。どちらかというと、「見せたくない特定のアカウントにだけ限定」して使うのがポイントです。
「メールアドレスでのサインイン」機能の扱いを決める
Microsoft Entra ID には、ProxyAddresses（メールアドレス）でもサインインできるようにする「Email as an alternate login ID（メールアドレスでのサインイン）」という機能があります。
メールアドレスでのサインイン機能の概要
この機能を有効にすると、次のような動きになります。
- 通常の UPN に加え、ProxyAddresses に登録されているメールアドレス（特定条件を満たすもの）でもサインイン可能
- ユーザー側から見ると「UPN かメールアドレスか、どちらでもサインインできる」ように見える
- ハイブリッド環境では、オンプレのメールアドレスをそのままサインイン ID として使えるようにする用途で活用される
管理センターからは、
- Entra 管理センター > Entra ID > Entra Connect > Connect Sync > Email as alternate login ID
と辿ることで設定できます。
教育機関でのおすすめ方針
教育機関の学生テナントでは、次のような理由から、
- サインイン ID を UPN に限定しておく
- メールアドレスによるサインイン機能は 無効のまま運用する
というポリシーが比較的扱いやすいことが多いです。
- 「どの画面でも UPN（= 学校が配布した ID）だけを使えば良い」と案内できる
- 後からエイリアスを増やした際に「どのアドレスでログインできるのか」がブレにくい
- トラブル対応時に、「UPN のみ」を前提にした切り分けがしやすい
特別な要件がない限り、あえてメールアドレスサインイン機能を有効化せず、UPN に一本化しておく方が、学生・教職員ともに運用負荷が下がります。
onmicrosoft を完全に隠したい場合の上級テクニック：アドレス帳ポリシー（ABP）
大規模な学校・大学・教育委員会では、さらに踏み込んで学生用のアドレス帳を分離する「アドレス帳ポリシー（Address Book Policy, ABP）」を導入するケースもあります。
ABP でできることのイメージ
ABP を使うと、たとえば次のような構成が可能です。
- 教職員：全職員＋全学生が見える GAL
- 学生 ：学生だけが見える GAL（教員は一部だけ）
- システム用アカウント：一般ユーザーからは一切見えない
ABP 自体は onmicrosoft 専用の仕組みではありませんが、「学生が目にしてよいアドレスを絞り込む」ための強力な手段です。導入には次のような要素が絡むため、ある程度の Exchange Online 設計スキルが必要になります。
- アドレスリスト（Address List）の設計（フィルター条件の定義）
- GAL / OAB / ルームリストなどの分離設計
- ABP の割り当て方法（メールボックス単位）
onmicrosoft を直接消すのではなく、「学生から見える世界」を ABP で制御するという発想は、大規模テナントでは特に有効です。
Exchange ライセンスが無い学生はどう見えるか
「全学生に Microsoft 365 を配布したいが、メールは使わせない」というパターンもよくあります。この場合、
- Entra ID のユーザーとしては存在する
- しかし Exchange Online ライセンスを付与していない
という状態になります。このようなユーザーは、メールボックス自体が無いため、Exchange Online の GAL にはそもそも登場しません。したがって、「onmicrosoft を見せたくない」という観点で言えば、
- メールライセンスを付与しない学生については、onmicrosoft が GAL に表示される問題は発生しない
- Teams や OneDrive などのサービス利用では、UPN や表示名の方が主にユーザーの目に触れる
という整理になります。メール機能を配布する学生だけに、ここまで解説してきた設定を適用していくイメージです。
onmicrosoft を消してしまった場合のリスクと戻し方の考え方
実務の現場では、すでに onmicrosoft のエイリアスを削除してしまっているケースも少なくありません。その場合、すぐに大惨事になるとは限りませんが、次のようなリスクがあります。
- 今後のドメイン変更やテナント統合時に、識別子として使えるアドレスが減ってしまう
- 移行用スクリプトや一部のツールで、「初期ドメインのアドレスがある前提」のサンプルが使えない
- onmicrosoft ベースで作られた古いアカウント情報（外部システムなど）とのマッピングが難しくなる
もし削除済みであれば、
- 可能な範囲で、同じローカル部で onmicrosoft アドレスを再追加しておく
- 追加前に「同じアドレスを使っている別のオブジェクトがないか」を確認する
といったリカバリーも検討できます。ただし、「過去に onmicrosoft で運用していたメールフロー」が存在する場合は、思わぬところからメールが飛んでくることもあり得るため、ログや現場ヒアリングを行いつつ慎重に進めてください。
セキュリティ観点で必ずやっておきたいこと：MFA＋条件付きアクセス
ここまで onmicrosoft を「見せない・意識させない」ための話をしてきましたが、最終的なアカウント防御力を決めるのは認証強度です。
優先順位の高い順に導入する
- 管理者・特権アカウントに対する MFA 完全必須化
- 教職員全体への MFA 展開
- 学生アカウントに対する段階的 MFA 導入
特に管理者アカウントは、侵害されると「全ユーザーのパスワードリセット」「ドメイン追加」「アプリ登録」など、甚大な影響が出ます。onmicrosoft の露出を隠しても、パスワードが弱ければ防御にはなりません。
条件付きアクセスを組み合わせれば、
- 学外からのアクセスは MFA 必須
- 危険度の高いサインインはブロックまたは追加検証
- 管理者アカウントではレガシー認証を全面禁止
といったポリシーが実現できます。Microsoft は Entra ID の条件付きアクセスと MFA を組み合わせたハイブリッド認証構成を、公式ドキュメントでも強く推奨しています。
具体シナリオ別：どう設計するかの例
シナリオ 1：全学生にメールを配布する大学
- UPN：
学籍番号@univ.ac.jp - Primary SMTP：
氏名ローマ字@univ.ac.jp - onmicrosoft：
学籍番号@tenant.onmicrosoft.comを副アドレスで付与
この場合の設計指針は次の通りです。
- 学生向けには「学籍番号@univ.ac.jp をサインイン ID として使用」と案内
- メールは氏名ベースのアドレスを既定にし、学生は氏名アドレスを名刺・履歴書等で利用
- onmicrosoft はエイリアスとして保持するが、マニュアルや画面上には一切登場させない
シナリオ 2：学生にはメールを配らず、Teams と OneDrive のみ使わせたい高校
- 学生には Exchange Online ライセンスを付けない
- UPN のドメインだけ自校ドメインに変更
- onmicrosoft の扱いは、UPN 初期値としてのみ存在
この場合、GAL に学生は登場しないため、教員から見ても onmicrosoft のメールアドレス問題はそもそも発生しません。サインイン ID を自校ドメインで統一しておけば、学生は Teams / OneDrive / Classroom 系サービスを違和感なく利用できます。
実務での「最短アクション」まとめ
最後に、「今すぐ何をやれば良いのか」をシンプルにまとめます。
| 優先度 | アクション | ゴール |
|---|---|---|
| 高 | Primary SMTP を必ず自ドメインに切り替える | 送受信で onmicrosoft が見えることを防ぐ |
| 高 | 管理者・特権アカウントに MFA＋条件付きアクセスを適用 | アカウント乗っ取りリスクの大幅低減 |
| 中 | UPN を自ドメインに統一する | 学生に onmicrosoft を意識させないサインイン体験 |
| 中 | サービスアカウント・共有メールボックスを GAL 非表示 | アドレス帳をすっきりさせ、誤送信リスクを減らす |
| 低〜上級 | 必要に応じてアドレス帳ポリシー（ABP）を導入 | 学生・教職員・システム間で見えるアドレスをコントロール |
キーワードは、
- onmicrosoft は「消す」のではなく「裏方に引っ込める」
- ユーザーに見せるのは自ドメインのアドレスだけ
- サインイン ID、アドレス帳、MFA をセットで設計する
この方針さえ守っておけば、onmicrosoft アドレスは教育現場での運用の邪魔をせず、むしろ将来の変更やトラブルシュートの味方になってくれます。「消さずに見せない」設計で、学生にとっても教職員にとっても分かりやすい Microsoft 365 環境を構築していきましょう。
コメント