Viva Engage をハブ／スポークの複数テナントで使うときは、「MTO（Multi-Tenant Organization）」と「External Network（外部ネットワーク）」のどちらで組織境界を越えるかが最重要です。ライセンス、運用、Teams 連携、統制の観点で選び方を整理します。
Viva Engage を複数テナントで使う前提：ゴールを先に決める
複数テナントをまたいだ Viva Engage の設計は、技術よりも「誰を“同じ社員体験”で扱うのか」を先に定義すると迷いません。典型的には次の2パターンに分かれます。
- グループ企業（社内）：子会社・事業会社が別テナントでも、全社のお知らせやナレッジを一体で回したい
- 社外（パートナー）：取引先・委託先・共同プロジェクトだけ、限定的にコミュニティを作りたい
このゴールの違いが、そのまま「MTO で“組織として結ぶ”か」「External Network で“別ネットワークとして切る”か」の判断軸になります。
選択肢は大きく2つ：MTO と External Network
| 項目 | MTO（Multi-Tenant Organization） | External Network（外部ネットワーク） |
|---|---|---|
| 狙い | 複数テナントを“1つの組織体験”に寄せる（社内グループ向き） | 社外・他社と“別ネットワーク”で安全に協業する（外部コラボ向き） |
| ユーザー体験 | 横断コミュニティ／Storyline／Leadership Corner などを組織横断で展開しやすい | ネットワークが分かれるため、体験は分離しやすい（切り替え運用が前提） |
| 管理の思想 | ハブで全社発信、スポークは受信・参加（ハブ＆スポーク） | 外部コラボ用途の“専用ネットワーク”をテナント単位で管理 |
| 典型ユースケース | M&A / 持株会社 / 事業会社分割 / 地域別テナント統合運用 | 委託先との案件コミュニティ / 業界横断の連絡会 / 期間限定ワークスペース |
MTO（Multi-Tenant Organization）とは：ハブ／スポークを「1つの社内ネットワーク」に寄せる
MTO は Microsoft 365 のマルチテナント組織機能を利用し、信頼済みの複数テナントを「統合的な組織」として扱えるようにする考え方です。Viva Engage ではハブ＆スポーク構成を取り、ハブ側（本社・全社広報・人事などがいるテナント）から、スポーク側へ一斉に情報を届ける設計が基本になります。
注意点として、Viva Engage の MTO は常に誰でもすぐ有効化できる機能ではなく、提供は段階的（ロールアウト）で、設定にあたって Microsoft のアカウント担当またはサポートへの連絡が必要になる場合があります。プロジェクト計画では「技術検証はできたのに本番有効化の手続きが残る」ことがあるため、早めに確認しておくと手戻りを避けられます。
MTO の前提条件（技術要件）
Viva Engage で MTO を成立させるための前提条件は、ざっくり言うと「Entra で信頼関係を張り、Engage を Native Mode で運用し、ハブを中心に同期と配信を設計する」です。代表的な要件は次のとおりです。
- 全テナントで Microsoft Entra によるネットワーク管理（Entra 管理）
- Viva Engage ネットワークが Native Mode（M365 ネイティブ）であること
- テナント間で Full Trust（完全な信頼）が確立されていること
- 各テナントは Engage ネットワークを 1 つだけ持つ（one-to-many 状態ではない）
- MTO の構成・同期には Microsoft Graph API などの要件が関係する
また、Microsoft 365 のマルチテナント組織には上限や非対応事項があります。例えば、マルチテナント組織は最大 100 テナントまでのサポートが示されており、モバイルでは一部の切り替え・通知に制約があるなど、周辺サービスの制限も設計に影響します。グループ企業の数や、現場がモバイル中心かどうかは、早めに前提として織り込むのがおすすめです。
MTO のライセンス要件：よくある誤解を解く
複数テナント運用で一番つまずきやすいのがライセンスです。結論から言うと、Viva Engage の MTO は「Entra 側の前提」と「Engage 側の前提」が分かれます。
| 観点 | 要件のポイント | 実務での読み替え |
|---|---|---|
| Entra（ID / 信頼 / 同期） | 各テナントで Microsoft Entra P1 以上が必要。P2 は必須ではなく、P1 で要件を満たすケースが多い | 「全テナントに P1 がある」状態を作る。ユーザー単位での “二重購入” を避ける設計が前提 |
| Viva Engage（体験 / 機能） | ハブ／スポーク両テナントの 全ユーザーに Viva Suite もしくは Viva Employee Communications and Communities（C&C）相当のライセンスが求められる | 「一部だけ MTO で使う」よりも、「全社で一体化」向き。コストは“全員前提”で試算しやすい |
| 重複ライセンス | ハブのユーザーがスポーク側で、またはスポークのユーザーがハブ側で 重複してライセンスを持つ必要はない | ユーザーは“自テナント”でライセンスを持てばよい。跨り方が増えるほどこの差が効く |
つまり、質問にある「両テナントの全ユーザーに Entra ID P1/P2＋Viva Suite または C&C が必要か？」に対しては、方向性としては概ね Yesです。ただしポイントは次の2つです。
- Entra は「P1 または P2」。P2 が必須というより、P1 が前提（必要に応じて P2 を追加）
- ユーザーは他テナント分を“二重に買う”必要はなく、MTO 全体として P1 を満たせばよい
MTO で得られるメリット：全社発信と参加が“横串”になる
MTO の強みは、単に「跨って投稿できる」ではなく、ハブ側の発信を軸にして組織横断の参加が設計できる点です。Viva Engage では Storyline や Leadership Corner、キャンペーン、コミュニティなどがクロステナント対応し、ハブ起点でスポークまで一体運用しやすくなります。
運用面でのコツは、ハブに全社広報・人事・社内ITなど“発信の責任を持つ役割”を集め、スポークは「参加・現場の声・地域ローカルの補足」へ寄せることです。ハブを迷うとガバナンス（誰が全社に出して良いか）が崩れやすいので、最初にハブの責任者と発信ポリシーを決めておくと事故を減らせます。
External Network（外部ネットワーク）とは：外部コラボ用に“別テナント／別ネットワーク”を立てる
External Network は、社外や別会社との協業を想定して用意される「外部向けの Viva Engage ネットワーク」です。現行の External Network（モダン外部ネットワーク）は Microsoft Entra 認証を前提とし、外部ネットワークごとに 新しい Entra テナント（Workforce tenant）を用意して連携します。つまり「External Network なら新規テナントを作って招待する」という理解は、設計としてほぼその通りです。
モダン外部ネットワークの設計で見落としやすいのが、外部ネットワークは 1 つ作るごとに 1 つの Entra テナントが必要という点です。プロジェクトが増えるたびに外部ネットワークを増やす運用にすると、テナント数（＝運用対象）が雪だるま式に増えるため、基本は「外部ネットワークは用途の塊ごとに最小数で作る」方針が現実的です。
External Network の作り方：実務で押さえるべき 5 ステップ
- 外部ネットワーク用の Entra テナント（Workforce tenant）を作成する（国/地域は親テナントと合わせる）
- 外部テナントの管理者（通常は作成者）に、必要なライセンスとメール属性を整備する
- Viva Engage 管理画面で 関連付けトークン（association token）を発行し、親ネットワーク側で紐付ける
- 外部参加者（ユーザー）を CSV などで一括招待してゲストとして取り込む
- Native Mode の整合・データ移行（既存外部ネットワークがある場合）を行い、周知して切り替える
なお、外部ネットワークは “レガシー” から “モダン” への移行が進んでおり、外部ネットワークも Native Mode（Entra ベース）へ整合させる前提で案内されています。過去に Yammer 時代の外部ネットワークを使っていた場合は、ユーザーやデータの移行手順（CSV 取り込みなど）まで含めて計画しておくと安全です。
この方式のメリットは明確で、「外部は外部として切り分ける」ため、社内ネットワークのガバナンスを保ったまま協業空間を作れます。一方で、ネットワークが分離するぶん、統合体験は MTO より弱くなります（後述）。
External Network のライセンス要件：E5 推奨の“正体”
External Network の議論でよく出てくる「Microsoft 365 E5 推奨」は、参加者全員が E5 必須という意味ではなく、外部ネットワークをセットアップ／管理するための最低要件として E5 が絡む点が重要です。公式手順では、モダン外部ネットワークの要件として「グローバル管理者権限」と「少なくとも 1 ユーザーの Microsoft 365 E5 ライセンス」が挙げられています。
補足すると、Viva Engage 全体の一般論としては「管理者が管理画面に入るために必ずしもユーザーライセンスを割り当てる必要はない」とされています。一方で、モダン外部ネットワークのセットアップ手順では、新テナント側で管理者が Network Admin としてサインインできるよう、少なくとも 1 ユーザーに E5 を割り当て、Engage Core のサービスプランを有効化する流れが示されています。ここを読み違えると「管理は無償のはずなのに、なぜ E5 が要るのか？」となりやすいので、セットアップ要件として切り分けて理解すると整理しやすいです。
一方、一般の参加者がどのライセンスで“参加できるか”は、基本的には Viva Engage Core（コア機能）を利用できるかに寄ります。Microsoft 365 Business Premium 自体に Viva Engage が含まれるため、Business Premium ユーザーが External Network へアクセスして閲覧・投稿する、といった「参加」用途は現実的です（ただし利用できる機能範囲や統制要件は別途検討が必要です）。
さらに、Viva Engage の高度機能（分析、キャンペーン、Leadership Corner、AMA など）は、Viva Suite または Viva Employee Communications and Communities のライセンスで提供される整理になっています。External Network を “参加中心” に割り切るなら Business Premium でも十分なケースがありますが、高度な機能を外部コラボにも展開したい場合は、Viva Suite/C&C を含めて設計するのが安全です。
| ライセンス観点 | Business Premium | Microsoft 365 E5 | Viva Suite / C&C |
|---|---|---|---|
| Engage の基本参加（閲覧・投稿・リアクション） | ○（Engage を含む） | ○ | ○（前提としてコアも） |
| Engage のプレミアム体験（分析、キャンペーン等） | △（基本はコア中心） | △（単体ではプレミアム確約ではない） | ○（プレミアム機能の主戦場） |
| セットアップ要件（外部ネットワーク作成/管理の最小条件） | △（少なくとも 1 ユーザーは E5 が要件になり得る） | ○（少なくとも 1 ユーザー） | （別軸：Engage プレミアム機能の権利） |
| 統制・監査の拡張（Purview などを含む高度統制を前提にしやすい） | △ | ○ | （別軸：統制は製品群全体の組み合わせで設計） |
また、モダン外部ネットワークは「コミュニティ」を中心に提供され、将来的にキャンペーンやイベント、ナレッジ機能が拡張される想定が示されています。今すぐ“社内と同等の Engage 体験”を外部にも求める場合は、ロードマップも含めて期待値調整が必要です。
招待されたユーザーは“親テナントに切り替え”が必要か？
モダン外部ネットワークは Entra による B2B を前提にしており、外部参加者は自分の既存アカウント（所属組織の資格情報）でサインインする形が基本です。つまり「毎回、親（ハブ）テナントに切り替えてログインし直す」よりも、招待（ゲスト化）→自組織の認証でアクセスという流れになります。
ただし実務上は、Microsoft 365 の“ディレクトリ（テナント）切り替え”や、Viva Engage の“ネットワーク切り替え”が UI 上で発生することがあります。これは「認証が別アカウントになる」というより、「今どの組織コンテキスト（どのネットワーク）を見ているか」を切り替える操作です。ユーザー教育としては次の言い方が伝わりやすいです。
- ログインはいつもの会社アカウントで OK（招待メールのリンクから入る）
- 表示先のネットワーク（外部ネットワーク）を選ぶ画面が出たら、外部ネットワークを選択する
- ブックマークは “外部ネットワークの URL” を使う（迷子を減らす）
なお、外部ネットワークは Consumer Identities（コンシューマー ID）の利用もサポートされるため、外部参加者の属性（法人テナント／個人ID）が混在するケースも設計上は想定できます。
MTO と External Network の比較：制限・トレードオフまで含めて判断する
ここからは、実際に現場で揉めやすい論点（UX、コンプライアンス、Teams 連携、運用負荷）を比較していきます。
| 比較軸 | MTO（Multi-Tenant Organization） | External Network（外部ネットワーク） |
|---|---|---|
| 組織体験 | ハブ起点で“全社”を一体運用しやすい。ストーリーラインやリーダー発信が横串になりやすい | ネットワークが分かれるため、体験は分離。案件・目的単位に割り切るほど強い |
| 機能の広がり | Storyline / Leadership Corner / campaigns / communities を跨って設計しやすい | 現状はコミュニティ中心で、拡張は段階的（将来拡張の余地） |
| ライセンス設計 | Entra P1/P2 と Viva Suite/C&C が“全体設計”として前提になりやすい | セットアップに E5 が絡み得る一方、参加者はコア中心で成立するケースもある |
| コンプライアンス／監査 | 信頼済みテナント間で運用するため、統制モデルを揃えやすい（ただしテナント別の管理責任は残る） | 外部ネットワークが別テナントになるため、統制は“テナント境界”で切れる。運用ルール整備が重要 |
| Teams 連携 | 同一組織体験に寄せやすい（Teams 側の切り替え・制約も設計で吸収しやすい） | Teams 側でもテナント/ゲスト文脈が絡むため、体験は分離しがち。利用シーンを限定すると運用しやすい |
| 運用負荷 | 初期設計は重いが、運用が軌道に乗ると“全社統一”で回しやすい | 外部参加者の招待・棚卸・期限管理など、運用作業が継続的に発生しやすい |
External Network を選ぶ場合の主な制限と、実務での落としどころ
External Network は「外部協業のために分離する」設計なので、MTO と比べたときにトレードオフが出ます。ただし、制限を理解して設計すれば“むしろ安全に使える”場面も多いです。
ユーザー体験（UX）：一体感よりも“目的別”の使い分けが前提
- 社内のタイムライン/ストーリーラインと外部ネットワークの情報が混ざらない（良くも悪くも分離）
- 外部ネットワークはコミュニティ中心で、社内で当たり前の拡張機能を同等に期待するとギャップが出やすい
落としどころ：外部ネットワークは「案件」「パートナー種別」「期間（例：6か月）」でコミュニティ設計し、社内アナウンスはハブ側（社内）に寄せます。外部に出す情報は“目的と範囲”を先に決め、投稿テンプレ（目的、期限、担当、次アクション）を決めるだけで、情報の散らかり方が大きく変わります。
コンプライアンス：テナント境界で切れるからこそ、棚卸が重要
モダン外部ネットワークは Native Mode を前提にしており、Purview での eDiscovery など Microsoft 365 側の統制と接続しやすい整理になっています。一方で、外部ネットワークは別テナントなので「保持期間」「監査ログ」「外部共有の可否」などを外部テナント側でも揃える必要があります。
落としどころ：外部ネットワークは“利用期間が終わる”前提で運用します。具体的には、(1) コミュニティ単位のオーナー、(2) 四半期ごとの外部参加者棚卸、(3) 契約終了時のアーカイブ/削除手順、の3点を最初に決めておくと監査対応が楽になります。
管理運用：CSV 招待やゲスト管理が増えやすい
外部ネットワークは「ユーザーをゲストとして取り込む」設計のため、招待・承認・未登録ユーザー対応など、運用タスクが継続的に発生しやすいのが現実です。公式手順でも CSV による一括招待が前提のシーンが示されています。
| 運用タスク | よくある詰まりどころ | おすすめの運用ルール |
|---|---|---|
| 外部ユーザー招待 | 招待メール未着／承認待ちの放置／所属変更でメールが変わる | 招待は「月1回の定期バッチ」に寄せ、個別対応を減らす |
| コミュニティ参加承認 | 管理者が不在で承認が止まる | コミュニティごとにオーナーと代理承認者を2名以上置く |
| 棚卸・期限管理 | プロジェクト終了後に外部が残り続ける | 四半期棚卸＋案件終了チェックリストに“外部ネットワーク退出”を入れる |
| 分析・統制の横断 | 社内ネットワークと外部ネットワークで指標が分断される | 外部は「活動量」より「意思決定のログ」を残す目的に寄せる |
外部ユーザーが「ハブの一部ユーザーだけ」@メンションできないときの切り分け
External Network で「全員ではなく一部だけ @メンションできない」という症状は、再現性が低いことも多く、設定・同期・検索範囲の影響を受けるケースがあります。まずは“仕様制限”と“環境依存の不具合”を分けて考えるのが近道です。
@メンションが効く仕組みをざっくり押さえる
@メンションの候補表示は、Viva Engage の画面だけで完結しているのではなく、ユーザー情報（表示名・メール・所属など）の参照、コミュニティ参加状態、外部向け検索の許可など複数要素に依存します。したがって「候補に出ない＝存在しない」ではなく、「見つけられない条件がある」可能性を疑います。
| 確認ポイント | 起きがちな原因 | 切り分け方法（例） |
|---|---|---|
| 対象ユーザーはコミュニティに参加済みか | 招待状態のまま／参加承認待ち／グループ同期未反映 | ハブ側で当該ユーザーの参加状態を確認し、再招待または承認 |
| 外部ユーザー検索・表示が制限されていないか | アドレス帳非公開、外部向け検索制限、プロファイルの非表示設定 | “検索で出る/出ない” を別ブラウザ・別端末で比較 |
| ゲスト（B2B）作成が正常か | プロビジョニング遅延、属性未同期、メール未設定 | Entra 側でゲスト状態・UPN/メール属性を確認し、再同期を試す |
| クライアント依存か | ブラウザ拡張、キャッシュ、Teams 内蔵ブラウザ差 | シークレットウィンドウ／別ブラウザ／スマホで再現確認 |
上記を潰しても改善しない場合は、テナント構成やポリシー差分まで踏み込む必要があるため、Microsoft 365 管理センターからサポートチケットを起票し、ログや設定を含めて調査してもらうのが確実です。問い合わせ時は「影響を受ける外部ユーザー」「@メンションできない内部ユーザーの一覧」「発生時刻」「再現手順（どのコミュニティで、どの画面で）」を揃えると調査が早く進みます。
どちらを選ぶべきか：判断を早める “決め手”
MTO と External Network は、優劣ではなく「組織境界の扱い方」が違います。迷ったら次の質問に答えると、ほぼ自動的に結論が出ます。
| 質問 | Yes の場合に有力 | No の場合に有力 |
|---|---|---|
| グループ各社を“社員”として同じ全社発信・同じ文化施策で回したい？ | MTO | External Network |
| 外部参加者は案件単位で増減し、期限がある？ | External Network | MTO |
| 全社レベルの統制（リーダー発信、キャンペーン、分析）を重視する？ | MTO（＋Viva Suite/C&C 前提） | External Network（割り切り運用） |
| 運用を“ハブで集中管理”し、スポークは参加に寄せたい？ | MTO | External Network（外部テナント運用が発生） |
実務で多いのは「社内は MTO、社外は External Network」のハイブリッドです。社内の一体感を保ちつつ、社外はテナント境界で切って安全にコラボする──この住み分けが一番トラブルが少なく、説明責任（なぜその場に社外がいるのか）も果たしやすい設計になります。
導入前にやっておくと失敗しにくいチェックリスト
- 目的：全社発信を跨らせたいのか、案件コラボを作りたいのか
- 対象範囲：誰が投稿者で、誰が閲覧者か（社外が投稿するか）
- ライセンス：MTO は Entra P1/P2 と Viva Suite/C&C の前提、External Network はセットアップ要件（E5）を確認
- ガバナンス：投稿ルール、オーナー、コミュニティ作成ルール、棚卸頻度
- 運用設計：招待の手順（CSV/自動化）、退職・契約終了時の退出、権限の引継ぎ
- 利用者教育：ネットワーク切り替え、通知の受け方、社外投稿時の注意
最後に、どの方式でも共通して効くのは「コミュニティの寿命」を設計することです。作ったまま放置されるコミュニティが増えると、検索性も統制も一気に崩れます。作成時に“終了条件（いつ・誰が・どう閉じる）”を決めるだけで、複数テナント運用の難易度は大きく下がります。
コメント