Microsoft 365 管理センターで新規ユーザーを作るとき、以前は「サインイン情報をメール送信」で代替メールアドレス宛に案内できたのに、最近のUI変更で見当たらない――その結果、招待メールが“作ったばかりの社内メール”に送られて本人が受け取れず、オンボーディングが手作業化して困るケースが増えています。本記事では、変更点の整理と、現場で破綻しない回避策を具体例つきでまとめます。
起きている問題：新規ユーザー作成時に「サインイン情報／招待メール」を代替メールへ送れない
Microsoft 365 管理センターで新規ユーザーを追加する際、以前は作成フローの中で「サインイン情報をメール送信」のような項目があり、複数の宛先（代替メールアドレスなど）に案内を送れました。しかし最近のUI変更後、同等の導線が見当たらず、次のような運用トラブルが発生します。
- ユーザー作成直後に「サインイン情報を送る」操作ができず、作成 → 詳細画面 → 別メニュー…と手順が増える
- 招待（案内）メールの送信先が新規作成した社内アドレスになりがち
- 本人はまだサインインできず、社内メールボックスにアクセスできないため受信できない
- 結果として、HR/情シスがOutlookで案内文を作って代替メール宛に手動送信する運用に逆戻り
- 「代替メールへ招待送信」や「初回アクセスを管理者へ通知」などの自動化も、GUIだけでは実現しにくい
変更点の整理：以前と今で何が違うのか
スレ内の到達点（結論）としては、Microsoft 365 管理センター側の「サインイン情報をメール送信（代替メール指定）」相当の機能は、2024年10月頃から削除された扱いになっており、現状は「できない（仕様）」という整理です。
| 観点 | 以前（旧UIのイメージ） | 現在（UI変更後） | 現場への影響 |
|---|---|---|---|
| 作成時の案内送信 | 作成フロー内で「サインイン情報をメール送信」でき、代替メール等を指定しやすい | 同等の導線が見当たらず、作成後に別画面で実施する必要がある | 手順増・引継ぎミス増 |
| 送信先の柔軟性 | 最大複数宛先（代替メールなど）を指定できた運用が多い | 送信先が「作成したユーザー本人の社内アドレス」寄りになりやすい | 本人が受信できず詰まる |
| オンボーディングの自動化 | GUIだけでも“最低限”は回る | GUIだけで完結しにくく、PowerShell/Graph/監査ログ連携が必要になりがち | HR運用と相性が悪化 |
なぜ詰まるのか：作ったばかりの社内メールは「受信できる状態」とは限らない
「招待メールが新しい社内アドレスへ送られているのに、本人が受け取れない」状況は、次の要因が重なって起きます。
- 本人がまだサインインできない（初回パスワード未取得、MFA未登録など）
- ライセンス付与のタイミング次第で、Exchange Onlineのメールボックスが未作成、または作成途中
- デバイス配布前で、Outlookやブラウザから社内メールへ到達する導線がない
- 案内文が「Microsoft 365 にログイン」になっていて、入口の選択を誤る（後述）
つまり、“社内アドレスに送る＝本人が必ず受信できる”ではない点が、オンボーディングの落とし穴です。
結論：Microsoft 365 管理センター単体では「代替メール宛の招待送信」はできない前提で設計する
現実的には、Microsoft 365 管理センターの作成フローだけで完結させようとするほど、手戻りが増えます。そこで運用の軸を次のように切り替えるのが安全です。
- ユーザー作成はEntra ID側を主導（作成・初期認証・本人確認の設計がしやすい）
- Microsoft 365 管理センター側はライセンス付与・サービス管理に寄せる
- 案内は「代替メールで受け取れる」導線を別に持つ（手動または自動）
回避策の全体像：現場で選びやすい3パターン
“理想”と“現実”の間を埋めるために、まずは次の3パターンで整理すると決めやすくなります。
| パターン | 向いている組織 | メリット | 注意点 |
|---|---|---|---|
| 手動メール（HRが代替メールへ案内） | 人数が多い／HR主導／ツール導入が難しい | 今すぐ回る、例外対応に強い | 作業負荷・属人化、誤送信リスク |
| Entra IDで作成→ライセンス付与→案内 | 情シス主導で標準化したい | 作成～初回サインイン設計を統一しやすい | 画面や権限が増える、教育が必要 |
| PowerShell/Graphで自動化（案内・通知も） | 入社数が多い／自動化投資できる | ミス削減、初回アクセス通知など高度化が可能 | 開発・運用・監査の整備が必要 |
最も確実な回避策：HRが代替メール宛にオンボーディング案内を送る
スレ内の到達点としても、まず現実解はここです。ポイントは「本文に必要情報をまとめる」「一時パスワードは別経路に分離する」の2つ。
案内メール本文に入れるべき情報（チェックリスト）
| 項目 | 入れる理由 | 例 |
|---|---|---|
| 入口URL | 迷子を防ぐ | https://www.office.com/ |
| ユーザーID（UPN） | 新ドメインだと入力ミスが多い | [email protected] |
| 初回の手順 | サインイン→パスワード変更→MFA登録を固定化 | 手順を箇条書きで |
| サポート窓口 | 詰まった時のエスカレーションを一本化 | 情シスメール/電話/受付時間 |
| 注意事項 | 「Microsoft 365にログイン」誤解などを予防 | 「まずOffice.comから」など |
テンプレ：代替メール宛のオンボーディング案内（本文）
件名：【重要】Microsoft 365 利用開始のご案内（初回サインイン手順） 〇〇様 入社に伴い Microsoft 365 アカウントを発行しました。 初回サインインは、以下の手順で実施してください。 ■サインイン入口（まずはこちら） [https://www.office.com/](https://www.office.com/) ■ユーザーID（メールアドレス） [[email protected]](mailto:[email protected]) ■初回サインイン手順 ・上記URLを開く ・ユーザーIDを入力して次へ ・初回用の認証情報（別経路でお知らせします）でサインイン ・サインイン後、指示に従ってパスワード変更 ・続けて多要素認証（MFA）登録（Authenticator等） ■よくある注意 ・「Microsoft 365 にログイン」ではなく、まず Office.com から開始してください（入口の違いでエラーになることがあります） ・途中で止まった場合は、画面のエラー表示（スクリーンショット）を添えてご連絡ください ■お問い合わせ（情シス） メール：it-support@example 電話：00-0000-0000（平日 9:00-18:00） 以上、よろしくお願いいたします。
テンプレ：一時パスワード／初回コードは「別メール」または別経路に分離
「機能が消えた背景として“パスワードをメールで送らせたくない”意図があるのでは？」という声も出がちです。実際、メール本文にパスワードを同梱すると誤送信・転送・盗み見の事故が起きやすいので、最低限本文と分離してください。
メールで分離する場合の例（推奨は後述の“メール以外”）：
件名：【別送】Microsoft 365 初回認証情報（取扱注意） 〇〇様 先ほどご案内した Microsoft 365 初回サインイン用の認証情報です。 第三者に転送・共有しないでください。 ■初回認証情報 （ここに一時パスワード／初回コード） ※サインイン後、必ずパスワード変更とMFA登録を完了してください。
詰まりポイント対策：「まずOffice.com」案内が効く理由
新規ユーザーが「Microsoft 365 にログイン」で検索して、別の入口（製品ページや別導線）に入ってしまい、認証の流れや表示が変わって詰まるケースがあります。そこで、案内文を次のように固定化すると事故が減ります。
- 入口はOffice.comを明記する（URLを直貼り）
- 「ユーザーID（UPN）」をコピペできる形で書く
- 初回にやることを3〜5ステップに絞る（長文は読まれない）
- 止まったら「エラー画面のスクショ＋発生時刻」を送ってもらう
“パスワード配布を減らす”が本筋：Temporary Access Pass などを検討する
「パスワードをメールで送るのが嫌で機能が消えたのに、結局メールで送っている」状態になるのは、セキュリティ面でも運用面でも不毛です。可能であれば、初回サインインを“パスワード配布に依存しない”設計へ寄せるのが筋です。
| 方式 | 概要 | 安全性 | 運用負荷 | おすすめ度 |
|---|---|---|---|---|
| メールで一時パスワード送付 | 代替メールにパスワードを送る | 低〜中（誤送信・転送リスク） | 低 | 緊急時のみ |
| 別経路（電話・対面・セキュア送信） | 本文と分離し、より安全な経路で伝える | 中〜高 | 中 | 現実的 |
| 一時アクセスコード（例：TAP） | 短時間・回数制限のコードで初回サインイン→その場でMFA登録 | 高（設計次第） | 中 | 推奨 |
| 完全パスワードレス | 最初からパスワードを使わない運用 | 高 | 中〜高（設計・教育） | 中長期で推奨 |
「TAP（Temporary Access Pass）」のような一時的なアクセス手段を使うと、初回だけ安全に通して、その場で本人にMFA登録とパスワード変更（またはパスワードレス）を完了させる設計が取りやすくなります。これにより、メールでパスワードを配布する頻度を大きく下げられます。
「初回アクセスを管理者へ通知」したい場合の現実解：サインインログ監視で“初回”を検知する
GUIだけで「初回アクセスしたら管理者へ通知」を実装するのは難しいことが多く、現実的にはサインインログ（監査ログ）を監視して初回を検知する方向になります。
考え方（運用に落としやすい形）
- 新規作成ユーザーを「オンボーディング対象」としてリスト化（CSVやチケット）
- サインインログから該当ユーザーの最初の成功サインインを抽出
- 抽出結果をメールやTeamsへ通知（自動化するならSIEM/Logic Apps/Power Automate等）
通知を“やり過ぎない”コツ
通知を作ると、最初は気持ちよく動きますが、すぐにノイズが増えます。次の条件で絞ると運用が続きやすくなります。
- 「成功」だけに限定（失敗を全部通知するとアラート疲れになる）
- 対象は“入社予定日の前後”など期間で限定
- 通知先は個人ではなく共有窓口（Teamsチャネル/共有メールボックス）にする
Entra IDで作成→Microsoft 365でライセンス付与：手順を短くするコツ
「Entra ID 側でユーザー作成 → Microsoft 365 管理センターへ戻ってライセンス付与」という整理にする場合、ポイントは“作業者が迷わない導線”を作ることです。作業者がHR部門の場合は特に、画面が増えるだけで事故が増えます。
おすすめの最短フロー（例）
- HRは「入社者情報シート」に代替メール（私用メール等）を入力
- 情シス（または権限を持つ担当者）がEntra IDでユーザーを作成
- 必要に応じて初回認証情報（TAP等）を発行
- Microsoft 365 管理センターでライセンス付与（Exchange/Teams等）
- HRがテンプレ本文で代替メールへ案内（パスワード等は別経路）
作業分担の“線引き”を表で決める
| 作業 | 担当（例） | 理由 | ミスを減らす工夫 |
|---|---|---|---|
| ユーザー情報（氏名・部署・代替メール）収集 | HR | 情報の一次ソース | 入力フォーム化、必須項目チェック |
| ユーザー作成（Entra） | 情シス | 権限・設計・セキュリティが絡む | 命名規則、入力項目の最小化 |
| ライセンス付与（M365） | 情シス（または専任） | 課金・棚卸し対象 | ライセンスセットをテンプレ化 |
| 案内送信（代替メール） | HR | 入社コミュニケーションの流れに乗せやすい | テンプレ固定、差し込み項目だけ編集 |
一括作成や高度な自動化が必要なら：PowerShell/Graphで“案内メールも自前で送る”
GUI運用（HR部門など）には合いにくい前提はありますが、入社人数が多い場合は自動化しないと破綻します。方向性としては次のどちらかです。
- ユーザー作成・ライセンス付与・案内メール送信をPowerShell/Graphで一括実行する
- ユーザー作成イベントを起点に、Logic Apps / Power Automate / Azure Functions 等で代替メールへ自動送信する
自動化する場合の設計ポイント
- 案内文はMicrosoft 365の“標準招待”に寄せず、自社テンプレとして送る（入口URL・UPN・窓口を統一）
- パスワードを本文に入れない。入れるなら別経路、可能ならTAP等で置き換える
- 送信元は個人ではなく共有メールボックスにする（担当者異動に強い）
- 監査ログに残る形にして、作業証跡を確保する
PowerShell自動化のイメージ（やることの分解）
| ステップ | 目的 | 主な処理 |
|---|---|---|
| アカウント作成 | UPN発行 | ユーザー属性（表示名、部署、利用場所等）登録 |
| 初回認証情報の用意 | 本人が入れる状態にする | 一時パスワード発行、またはTAP等の発行 |
| ライセンス付与 | メール・Teams等を使えるように | 必要なSKUを割当（テンプレ化推奨） |
| 案内メール送信 | 代替メールへ確実に届く | 共有メールボックスからテンプレを送る |
| 初回サインイン監視 | オンボーディング完了確認 | サインインログの初回成功を検知し通知 |
自動化は“便利”ですが、やり始めると監査・権限・例外対応が必ず出ます。小さく始めるなら、まずは案内メールの自動送信だけでも効果が大きいです（テンプレ統一＋誤送信削減）。
トラブルシュート集：オンボーディングでよく起きる詰まり
| 症状 | よくある原因 | 対処 |
|---|---|---|
| 招待メールが届かない | 社内メール宛に送っている／本人が受信できる状態ではない | 代替メール宛に案内を送る運用に切替（テンプレ化） |
| ログインできない（資格情報が合っているはず） | 入口の選択ミス、MFA未登録、初回変更が必要 | 入口をOffice.comに固定、手順を短く明文化 |
| 社内メールが使えない | ライセンス未付与、メールボックス作成待ち | ライセンス付与の標準手順化、付与後の反映時間を考慮 |
| HRの作業が属人化してミスが出る | テンプレがない／差し込み項目が多い | 差し込み項目を「URL・UPN・窓口」程度に絞る |
まとめ：UI変更に依存しない“オンボーディングの型”を作る
Microsoft 365 管理センターのUI変更で「サインイン情報を代替メールへ送る」導線が消えた結果、招待メールが“本人がまだ見られない社内アドレス”へ送られて詰まる、という現場トラブルが起きやすくなりました。対策としては、次の順で整備すると失敗しにくいです。
- まずは代替メール宛の案内テンプレを作って、手動でも確実に回る状態にする
- パスワード配布は本文に入れず、可能なら別経路やTAP等で置き換える
- 「初回アクセス通知」はGUIに期待せず、サインインログ監視で実現する
- 人数が多いなら、PowerShell/Graph等で案内送信の自動化から着手する
UIは変わりますが、オンボーディングは“人が詰まらない導線”を持っているかどうかで決まります。管理センターの機能に寄せすぎず、代替メールで確実にスタートできる設計へ切り替えるのが、いま最も現実的な解です。
コメント