2026年5月20日に公開・更新された「Microsoft Azure documentation update: Add M365 Local Medium-Scale reference architecture (v0.21.14)」は、Microsoft 365 LocalをAzure Local上で展開する際の参照アーキテクチャに、中規模向けの「Medium-Scale」を追加する更新です。結論から言うと、Small-Scaleでは集約されすぎ、Large-Scaleでは過剰になりやすいM365 Local構成を、3クラスター・5サーバー構成として検討できるようになりました。既存環境が自動的に変更される更新ではありませんが、設計資料、PowerPoint出力、ラック配置、運用分担、移行計画を見直す価値があります。(GitHub)
今回のMicrosoft Azureドキュメント更新で何が変わったのか
今回の更新は、Azure Local向けの設計支援リポジトリである「ODIN for Azure Local」において、Microsoft Sovereign Private CloudsページのKnowledgeタブへ「Microsoft 365 Local — Medium-Scale」参照アーキテクチャを追加するものです。PRは2026年5月20日にマージされ、バージョンは0.21.13から0.21.14へ更新されています。(GitHub)
重要なのは、この更新が「新しいAzureサービスの一般的な機能追加」ではなく、Microsoft 365 LocalをAzure Local上でどう配置するかを判断するための参照アーキテクチャ追加である点です。管理者は、すぐに本番環境の構成変更を行うのではなく、まず既存の設計資料や提案資料がSmallまたはLargeに偏っていないかを確認する必要があります。
| 項目 | 更新内容 | 実務上の意味 |
|---|---|---|
| 対象 | Microsoft Sovereign Private CloudsページのKnowledgeタブ | 設計・提案・レビュー時に参照する構成パターンが増える |
| 追加された選択肢 | Microsoft 365 Local — Medium-Scale | SmallとLargeの中間規模を検討しやすくなる |
| 構成規模 | 3つのAzure Localクラスター、合計5サーバー | 中規模のM365 Local配置を具体的に比較できる |
| 反映範囲 | 画面上のSVG図、PowerPoint出力、スケール表示 | 提案資料や社内レビュー資料を更新しやすい |
| 変更されない点 | データ、スキーマ、PPTテンプレート、新規外部通信 | 既存データ構造やテンプレートを大きく作り替える更新ではない |
前提として押さえたいAzure LocalとMicrosoft 365 Localの位置づけ
Azure Localは、Microsoftが提供する分散インフラストラクチャで、Azureの機能を顧客が所有・管理する環境へ拡張するための基盤です。オンプレミスやエッジ、主権要件のある場所で仮想マシンやコンテナ化ワークロードを動かし、Azure Arcを統合管理のコントロールプレーンとして利用できます。(Microsoft Learn)
Microsoft Sovereign Private Cloudは、規制産業、重要インフラ、国防・公共系など、データ所在地や運用権限の管理が重視される環境でクラウドサービスを動かすためのポートフォリオです。Azure Localはそのインフラ基盤となり、Microsoft 365 LocalやFoundry Localなどのワークロードを同じ主権境界内で運用する考え方が示されています。(Microsoft Learn)
Microsoft 365 Localは、Microsoft 365のクラウド版をそのままローカルに複製するものではありません。公式情報では、Exchange Server、SharePoint Server、Skype for Business Serverを、顧客が所有・管理するAzure Localインフラ上で実行する生産性ワークロードとして説明されています。(Microsoft Learn)
つまり今回の「M365 Local Medium-Scale」は、メール、ポータル、コラボレーション、関連するSQL Serverなどを、主権性や非接続運用を意識した環境でどう分離・配置するかを考えるための設計パターンです。
Medium-Scaleのクラスター構成
M365 Local Medium-Scaleの中心となる変更は、2つの単一ノードAzure Localクラスターと、1つの3ノードAzure Localクラスターを組み合わせる点です。合計では3クラスター・5サーバー構成になります。(GitHub)
| 役割 | クラスター構成 | 主なワークロード | サーバー |
|---|---|---|---|
| Exchange Mailbox | 単一ノードAzure Localクラスター | Exchange mailbox server | Server 1 |
| Exchange Mailbox | 単一ノードAzure Localクラスター | Exchange mailbox server | Server 2 |
| 共通アプリケーション基盤 | 3ノードAzure Localクラスター | Exchange Edge Transport、SharePoint Server、Skype for Business、SQL Server | Server 3、4、5 |
ここで誤解しやすいのは、「5台のサーバーで1つのクラスターを作る」わけではない点です。Medium-Scaleは、3つのAzure Localクラスターを5台のサーバー上に配置する参照モデルです。特にExchange mailbox serverを載せるServer 1とServer 2は、それぞれ独立した単一ノードクラスターとして扱われます。
また、Active Directory、Firewall、Load Balancer、内部管理ネットワークルーターは、管理ネットワークやコンピュートネットワーク上のインフラコンポーネントとして扱われます。これらは別個のAzure Localクラスターとして数えない点も、設計レビューで確認すべきポイントです。(GitHub)
Small・Medium・Largeの違いと選び方
今回の更新によって、M365 Localの参照アーキテクチャはSmallとLargeの二択ではなくなりました。これまで中規模環境では、3ノードに集約されたSmall-Scaleを選んで過密に見積もるか、7クラスター・9サーバーのLarge-Scaleを選んで過剰に見積もるかになりやすい状況がありました。Medium-Scaleはその間を埋める選択肢です。(GitHub)
| スケール | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| Small-Scale | 1つの折りたたまれた3ノードクラスター | 検証、小規模、最小構成に近い設計検討 | 役割が集約されるため、本番想定では分離要件を確認する |
| Medium-Scale | 3クラスター・5サーバー | Smallでは集約されすぎ、Largeでは大きすぎる中規模導入 | 単一ノードクラスターの運用・監視・障害時対応を明確にする |
| Large-Scale | 7クラスター・9サーバー | より大きな分離、拡張性、役割分担を重視する導入 | コスト、ラック、電源、運用体制が重くなりやすい |
Medium-Scaleを選ぶ判断基準は、単に「中規模だから」ではありません。Exchange mailbox serverを分離しつつ、SharePoint Server、Skype for Business、SQL Serverなどを3ノードクラスター側にまとめたい場合に検討しやすい構成です。
一方で、すべての役割に対してより厳密な冗長化や分離を求める場合、Medium-Scaleだけで要件を満たせるとは限りません。参照アーキテクチャは設計の出発点であり、最終的な可用性、バックアップ、災害対策、サポート条件は、自社要件とMicrosoft・パートナー・ハードウェアベンダーの最新情報で確認する必要があります。
管理者への影響範囲
今回の更新は、Azureの一般的なIaaS利用者全員に影響するものではありません。影響が大きいのは、Azure Local、Microsoft 365 Local、Sovereign Private Cloud、非接続または規制対応環境の設計・運用に関わるチームです。
| 対象者 | 確認すべき影響 |
|---|---|
| Azure Local管理者 | クラスター数、単一ノードクラスター、S2D固定、ライフサイクル管理 |
| Microsoft 365 Local担当者 | Exchange、SharePoint、Skype for Business、SQL Serverの配置 |
| ネットワーク管理者 | 管理ネットワーク、コンピュートネットワーク、ロードバランサー、ファイアウォール、ルーティング |
| ID・セキュリティ担当者 | Active Directory、アクセス制御、監査、非接続時の運用ルール |
| インフラ設計者 | ラック、電源、冷却、障害ドメイン、保守手順 |
| 開発者・自動化担当者 | 参照アーキテクチャ名、スケール識別子、PowerPoint出力、既存スクリプトの前提 |
特に、ODINの出力をそのまま社内標準の設計資料や顧客向け提案資料に使っている場合は、最新版で再出力する価値があります。0.21.14では、画面上のSVG図とPowerPoint出力がMedium-Scaleに対応し、概要スライドやスケール表示にも反映されるためです。(GitHub)
展開前に確認すべき設定ポイント
クラスター境界をラック表示と混同しない
0.21.14では、同じラックに配置される単一ノードクラスターを共有ラックカードとして視覚的にまとめる改善も含まれています。Large-Scaleでは、4つのExchange mailbox単一ノードクラスターや2つのEdge Transport単一ノードクラスターが、それぞれ共有ラックカードとして描画されるようになりました。ただし、これらは見た目上まとめられているだけで、クラスターとして統合されたわけではありません。(GitHub)
運用上は、各単一ノードクラスターが独自のクォーラム、S2Dプール、ライフサイクルを持つ前提で扱う必要があります。監視、パッチ適用、バックアップ、障害切り分けの単位をラックカード単位でまとめてしまうと、実際の管理境界とずれます。
ストレージはS2Dローカル固定として設計する
今回の更新では、M365 LocalのMedium-ScaleでもSmall・Largeと同様に、ストレージはS2D localに固定されています。PRのNotesでも、ストレージはS2D local固定であり、新しいデータ、スキーマ、PPTテンプレート、新規外部ネットワーク呼び出しはないとされています。(GitHub)
そのため、外部SANや別のストレージ構成を前提に見積もっている場合は、Medium-Scaleの参照アーキテクチャをそのまま適用できるかを慎重に確認してください。特にメールボックス、検索インデックス、SharePointコンテンツ、SQL Serverデータベースの容量見積もりは、S2D上の実効容量、冗長性、成長率を含めて再計算する必要があります。
Active Directoryやファイアウォールを「追加クラスター」として数えない
Medium-Scaleの3クラスター・5サーバーという数字には、Active Directory、Firewall、Load Balancer、内部管理ネットワークルーターは含まれません。これらは管理・コンピュートネットワーク側のインフラコンポーネントとして扱われます。(GitHub)
設計書では、次のように分けて記載するとレビューが通りやすくなります。
| 分類 | 記載すべき内容 |
|---|---|
| Azure Localクラスター | クラスター名、ノード数、ホストするM365 Localワークロード |
| 共通インフラ | Active Directory、DNS、NTP、管理ネットワーク、監視基盤 |
| セキュリティ境界 | Firewall、Load Balancer、管理アクセス、管理者ロール |
| 物理設計 | ラック、電源系統、ToRスイッチ、ケーブル、保守動線 |
この分離が曖昧なまま見積もると、クラスター数、ノード数、ライセンス、運用担当、障害対応の責任範囲がずれます。
移行・設計見直しで失敗しやすいポイント
既存のSmall-ScaleまたはLarge-Scale前提の資料がある場合、Medium-Scaleを追加して再検討するだけで十分とは限りません。構成規模が変わると、物理設計、運用手順、監視設計、保守手順も変わります。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 5サーバーを1クラスターと誤解する | 障害設計や監視単位を誤る | 3クラスター・5サーバーとして図と一覧を分ける |
| 共有ラックカードを統合クラスターと見なす | パッチ適用や障害切り分けの単位がずれる | 各単一ノードクラスターのライフサイクルを個別に管理する |
| SmallからMediumへ単純拡張できると考える | 役割分離、IP設計、証明書、バックアップが不足する | 現行構成との差分表を作り、ワークロード単位で移行順序を決める |
| LargeからMediumへ縮小してコストだけ下げる | 可用性や分離要件を満たせなくなる | 要件定義に戻り、RTO/RPO、障害ドメイン、保守時間を確認する |
| S2D固定を見落とす | ストレージ設計や調達計画が合わない | 容量、IO、冗長性、成長率をS2D前提で再計算する |
| 非接続環境の運用を軽視する | 更新、監査、証明書、ログ収集が滞る | 接続時・非接続時それぞれの運用手順を文書化する |
特に注意したいのは、Medium-Scaleが「ちょうどよい規模」に見えやすい点です。中規模のラベルだけで選ぶのではなく、メールボックス数、SharePointの利用規模、SQL Serverの負荷、Skype for Businessの利用範囲、保守時間、障害時の業務継続要件を合わせて判断してください。
開発者・自動化担当者が確認すべきこと
今回の更新では、docs/reference-architectures/script.jsにm365-mediumのエントリが追加され、既存のscaleVariantsなどのコードパスを通じて画面表示やPowerPoint出力に反映されるようになっています。(GitHub)
ODINの参照アーキテクチャページを社内ポータルや設計自動化に組み込んでいる場合、次の点を確認してください。
| 確認項目 | 内容 |
|---|---|
| スケール名の取り扱い | m365-mediumやM365 Mediumのような新しいラベルを既存処理が無視しないか |
| PowerPoint出力 | スケール表示、目的別Scaleパネル、図のスライドが想定通り出るか |
| JSONやURL共有 | スケール選択値を保存・共有する処理でMediumが保持されるか |
| テスト | 既存のSmall/Large前提のテストがMedium追加で失敗しないか |
| ドキュメント生成 | 社内テンプレートにSmall/Largeのみの説明が残っていないか |
一方で、PRではデータ、スキーマ、PPTテンプレート、新しい外部通信の変更はないと説明されています。そのため、多くの環境では大規模な実装修正よりも、選択肢追加に伴う表示、分岐、テストケースの更新が中心になります。(GitHub)
Medium-Scaleを採用する前のチェックリスト
実際にMedium-Scaleを設計候補に入れる場合は、次の順序で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 成果物 |
|---|---|---|
| 現行要件の整理 | 利用人数、メールボックス容量、SharePoint容量、SQL Server負荷、可用性要件 | 要件一覧 |
| スケール比較 | Small、Medium、Largeのどれが過不足ないか | 比較表 |
| 物理設計 | 5サーバー、ラック、電源、ネットワーク、ToRスイッチ | ラック図・配線図 |
| クラスター設計 | 単一ノード2クラスター、3ノード1クラスターの役割分担 | クラスター構成図 |
| 運用設計 | 監視、バックアップ、パッチ、証明書、障害対応 | 運用手順書 |
| 非接続時の手順 | 更新、監査ログ、管理者アクセス、ポリシー適用 | 非接続運用手順 |
| 資料更新 | ODINの最新図、PowerPoint、社内レビュー資料 | 最新版の設計資料 |
ODINリポジトリのREADMEでは、バージョン0.21.14の互換性としてAzure Local 2506+が記載されています。検証環境や本番計画で異なるバージョンを使う場合は、参照アーキテクチャの図だけで判断せず、実際の採用バージョン、ハードウェア、サポート条件を必ず確認してください。(GitHub)
既存の設計資料をどう見直すべきか
すでにMicrosoft 365 LocalやSovereign Private Cloudの提案・設計を進めている場合は、次の観点で資料を更新すると実務に落とし込みやすくなります。
Small-Scaleを前提にしていた場合
Small-Scaleを選んだ理由が「最小構成で十分」ではなく、「中間構成がなかったから」だった場合、Medium-Scaleで再評価すべきです。特に、Exchange mailbox serverを独立した単一ノードクラスターとして扱いたい場合や、SharePoint Server、Skype for Business、SQL Serverを別の3ノードクラスターに寄せたい場合は、Medium-Scaleの方が設計意図を説明しやすくなります。
Large-Scaleを前提にしていた場合
Large-Scaleを選んだ理由が「Smallでは小さすぎるから」だけだった場合、Medium-Scaleへの見直しで、サーバー数、ラック数、電源、運用負荷を抑えられる可能性があります。ただし、Large-Scaleで確保していた分離性や障害ドメインをMedium-Scaleで維持できるとは限りません。削減ありきではなく、要件との差分を明示して判断してください。
提案資料やレビュー資料を作っている場合
0.21.14では、オンスクリーンのSVG図とPowerPoint出力がMedium-Scaleに対応しています。既存のスクリーンショットや旧バージョンのPowerPointを使い回していると、最新の選択肢が抜けた資料になります。顧客説明や社内承認に使う資料は、最新版で再出力し、Small・Medium・Largeの比較ができる形に整えるのがおすすめです。(GitHub)
今回の更新で次に取るべき行動
今回のMicrosoft Azure documentation updateは、M365 Localを中規模で検討する組織にとって、設計判断をしやすくする実用的な更新です。特に、Small-Scaleでは役割が集約されすぎる、Large-Scaleではサーバー数や運用負荷が大きすぎるという課題があった環境では、Medium-Scaleを比較対象に入れる価値があります。
まず行うべきことは、ODIN for Azure Localの最新版でMicrosoft 365 LocalのMedium-Scale図を確認し、自社の現在の設計資料と並べて差分を見ることです。そのうえで、3クラスター・5サーバー構成、S2D local固定、単一ノードクラスターの扱い、Active DirectoryやFirewallなどを別クラスターとして数えない点を、設計レビューのチェック項目に追加してください。
最終的には、参照アーキテクチャをそのまま採用するのではなく、自社の可用性要件、規制要件、運用体制、ハードウェア調達条件に合わせて、Small・Medium・Largeのどれが最も説明しやすく、運用しやすいかを判断することが重要です。
コメント