LGWAN環境からMicrosoft 365へ安全接続できるのか。結論は、可能だが、全機能を同じやり方でつなぐ発想は危険です。自治体実務では、Officeアプリの認証・更新だけなのか、Teams会議まで使いたいのか、外部とファイル送受信まで行うのかで、必要な構成も運用負荷も大きく変わります。総務省のガイドラインは2024年10月改定で、LGWAN接続系端末から特定クラウドサービスを安全利用するためのα’モデルを整理し、2025年3月改定では「一人一台端末」の考え方を踏まえた画面転送方式も別紙で示しました。 (パブリックコメント)
つまり今の論点は、「LGWANからMicrosoft 365へつなぐか、つながないか」ではありません。どの通信を、どの端末で、どの認証条件で、どこまで許可するかを切り分けられるかです。ここを整理すると、ローカルブレイクアウトを選ぶべき場面と、LGWAN-ASPや画面転送、AVD、インターネット側端末併用に振り分けるべき場面が見えてきます。 (パブリックコメント)
LGWAN環境からMicrosoft 365へ安全接続するときの前提
総務省ガイドラインが想定しているのは、LGWAN接続系からインターネットへ何でも自由に出す運用ではありません。α’モデルは、従来のαモデルよりインターネット由来のリスクが増える前提で、事前の外部確認と定期的な外部監査を求めたうえで、利用範囲の違う3つの基本ケースを示しています。要するに、「一部のクラウドサービスを、必要な対策込みで使う」という整理です。 (パブリックコメント)
この3ケースはあくまで基本形であり、ガイドライン自体も、自治体ごとのサービス利用範囲を踏まえて個別に検討する必要があるとしています。正解を一つ探すより、まず自団体の業務で何をしたいのかを明文化する方が先です。 (パブリックコメント)
Microsoft 365は“インターネット前提”のSaaSとして見る
Microsoft 365はインターネット接続が必要で、DNSやCRL、CDNなどの標準インターネットサービスにも依存します。つまり、LGWAN側の思想だけで閉じ切ったネットワークに後付けで押し込む製品ではなく、インターネットに出る前提をどう安全化するかが設計の本丸です。 (Microsoft Learn)
ネットワーク面では、MicrosoftはローカルDNSと利用者に近いインターネット出口、プロキシや過度なTLS検査のバイパス、VPN利用時のスプリットトンネルを主要な最適化として案内しています。「全部を一箇所のプロキシで細かく検査すれば安全」という発想は、Microsoft 365では性能や安定性をむしろ落としやすい点に注意が必要です。 (Microsoft Learn)
さらに、Microsoft 365のエンドポイントは月次を基本に必要に応じて更新され、新規URL/IPは事前公開されます。Microsoft自身も最新データをWebサービスから取得する前提を示しており、サービス領域の大分類だけでアクセス制限することは有効ではないとしています。実務では、固定のFQDNやIPを人手で長期保守するより、更新取得の仕組みまで含めて設計した方が壊れにくいです。 (Microsoft Learn)
まずは「何を使いたいか」で方式を切り分ける
| 使いたい範囲 | 合いやすい考え方 | 実務で押さえる点 |
|---|---|---|
| 認証・更新だけ | α’(ア) | ライセンス認証や定義更新など、最小範囲から始めやすい |
| Teams会議・コミュニケーション中心 | α’(イ) | 自テナント中心、LGWAN端末へのダウンロード禁止が前提 |
| 外部とのファイル送受信・メール受信 | α’(ウ) | 無害化、権限管理、監査まで含めて運用負荷が上がる |
| 外部テナント参加や共同編集が多い | 画面転送・AVD・インターネット側端末併用 | LGWAN端末で無理に完結させない方が整合的 |
上表は、総務省ガイドラインのα’(ア)〜(ウ)と、2025年改定で示された画面転送の考え方、公開事例を実務向けに読み替えたものです。 (パブリックコメント)
- α’(ア)は、認証・ウイルス定義体取得のみを想定する最小構成です。各団体専用のテナントを保有せず、Web会議やメールなどのアプリケーション利用も前提にしていません。 (パブリックコメント)
- α’(イ)は、コミュニケーションツールを使うが、LGWAN接続系にファイルを取り込まないケースです。自テナントでの会議や共有はできても、外部団体のテナントに入って会議参加やファイル交換をする場合は、インターネット接続系端末からのアクセスが前提になります。 (パブリックコメント)
- α’(ウ)は、外部とのファイル送受信やメール受信まで行うケースです。できることは増えますが、無害化や権限管理まで含めて対策が一段重くなります。 (パブリックコメント)
- 画面転送やAVDは、ガイドラインのα’区分そのものではありませんが、一人一台端末の方向性や環境切替の現実解として有力です。2025年3月改定で画面転送方式が別紙として示され、町田市の公開事例でもAVDでLGWAN接続系・マイナンバー利用事務系・インターネット系を切り替える運用が紹介されています。 (パブリックコメント)
判断を誤りにくくする3つの基準
外部テナントに入るか
自テナントだけを使う業務と、外部団体のテナントに入って会議やファイル交換をする業務は、同じ「Teamsを使う」でも別物です。総務省ガイドラインは、外部団体のテナントにアクセスして会議参加やファイル交換を行う場合、インターネット接続系端末からのアクセスを前提にしています。ここを曖昧にしたまま設計すると、ルールも例外運用も破綻しやすくなります。 (パブリックコメント)
ファイルをLGWANへ取り込むか
次に大きい分岐が、クラウド上のファイルをLGWAN接続系へ入れるかどうかです。ファイルを内部に取り込まないα’(イ)と、外部とファイル送受信を行うα’(ウ)では、求められる対策の重さがかなり違います。「会議はしたいが、LGWAN端末へは落とさない」のか、「受け取ったファイルを業務に使う」のかを、最初に決めておくべきです。 (パブリックコメント)
ネットワークだけで守ろうとしていないか
見落としやすいのが、Microsoft 365のセキュリティ境界はネットワークの外まで広がっている点です。Microsoft Entra の条件付きアクセスは、ユーザー、IP、デバイス状態、アプリ、リスクなどのシグナルで判定し、Defender for Cloud Appsはリアルタイムのアクセスとセッション制御を補強できます。ネットワーク出口の制限だけで守ろうとすると、LGWAN側の設計は重くなるのに、実際の制御は甘いままになりがちです。 (Microsoft Learn)
安全接続で外せない設計ポイント
接続先制限は「更新方法」まで設計する
総務省ガイドラインでは、α’(イ)/(ウ)でLGWAN接続系から外部へ出られる宛先を、LGWAN-ASPと利用が許可されたクラウドサービスに限定し、自団体テナントのみに制限することを求めています。一方でMicrosoft 365側は、エンドポイント情報をWebサービスで最新化する前提を示しています。したがって、ファイアウォールやプロキシの許可設定は、静的な一覧表を作って終わりではなく、変更通知の取得方法と反映手順まで設計して初めて実運用になります。 (パブリックコメント)
自テナント制御はMicrosoft 365側でも担保する
LGWAN側の出口制御だけでは、「Microsoft 365には出られるが、別組織のテナントにも入れてしまう」という穴が残ります。そこで有効なのが Microsoft Entra のテナント制限で、許可したテナントだけにアクセスを絞れます。実装では、プロキシ要件やヘッダー挿入に加え、device.login.microsoftonline.com や enterpriseregistration.windows.net をTLS検査やヘッダー挿入から除外しないと、デバイス登録やデバイスベースの条件付きアクセスを壊す点に注意が必要です。より細かい運用を目指すなら、テナント制限 v2 も検討対象です。 (パブリックコメント)
認証と端末条件でゼロトラスト化する
条件付きアクセスでは、MFA、準拠デバイス、Microsoft Entra ハイブリッド参加デバイス、承認済みクライアントアプリなどを要求できます。特定のアプリに対して、組織の管理端末からのアクセスだけを許可する設計も可能です。逆に、レガシー認証はMFAやデバイス状態を扱えず、こうした制御でブロックされるため、例外運用を増やさないなら早めに整理しておく方が安全です。 (Microsoft Learn)
ファイル制御はTeams単体で考えない
LGWAN環境からMicrosoft 365を安全接続する設計で、特に事故が起きやすいのはファイルの持込・持出です。Defender for Cloud Apps では、アンマネージド端末からOneDrive上の機密ファイルをダウンロードさせない、SharePoint Onlineへのマルウェアアップロードを止める、といったセッション制御ができます。さらにTeamsのドキュメント保護はSharePointとOneDriveを含めて設計しないと成立しません。秘密度ラベルもTeamsのFilesタブ経由で扱えるため、「Teamsは会議」「SharePointは別件」と切り離して考えない方が安全です。 (Microsoft Learn)
監査と調達を後回しにしない
α’モデルは、導入前の外部確認と導入後の定期的な外部監査まで含めて成立します。加えて、Microsoft 365側では統合監査ログでExchange Online、SharePoint、OneDrive、Microsoft Entra ID、Teamsなどのイベントを横断的に追えます。「入れたら終わり」ではなく、誰が何をしたかを後から追える体制を前提にしてください。 (パブリックコメント)
| 確認項目 | 最低限見るもの |
|---|---|
| 客観的な安全性 | ISMAP/ISMAP-LIUの有無、ISO/IEC 27017、SOC報告書 |
| 可用性 | 稼働率、目標復旧時間、バックアップ方法 |
| 契約終了時 | 事前告知期限、データ移行方法 |
| 事故対応 | インシデント報告義務、連絡体制、SLA |
総務省ガイドラインは、ISMAPやISMAP-LIUに載っていても言明対象範囲や統制目標の管理策まで確認すべきとし、終了時のデータ移行やインシデント報告義務も調達条件に含めるよう求めています。 (パブリックコメント)
接続方式ごとの向き・不向き
| 方式 | 向く場面 | 強み | 注意点 |
|---|---|---|---|
| α’ローカルブレイクアウト | LGWAN端末から必要最小限のMicrosoft 365を使いたい | 既存の三層分離を活かしやすい | 接続先制限、テナント制御、監査が必須 |
| LGWAN-ASP / 外部閉域利用 | 事業者提供サービスとして閉域経由で使いたい | LGWAN経由の提供形態に乗せやすい | 提供機能はサービスリストと個別仕様の確認が必要 |
| 画面転送・AVD/VDI | 一台端末運用や環境切替を重視したい | データ境界を分けやすい | コスト、UX、運用設計が必要 |
| インターネット側端末併用 | 外部テナント参加や外部ファイル交換が多い | ルールが明快で例外が減る | 端末使い分けの教育が必要 |
LGWAN-ASPはJ-LISが「非常にセキュアなネットワーク」を介して行政事務サービスを提供する仕組みとして整理しており、外部閉域利用サービスや、ISMAPクラウド上のLGWAN-ASPホスティングも広がっています。一方で、外部テナント参加やファイル交換の多い業務は、総務省ガイドライン上もインターネット接続系端末の利用と相性がよく、2025年改定の画面転送方式や町田市のAVD事例は、その現実的な落としどころを示しています。 (J-LIS)
公開事例から見える現実的な落としどころ
- 北杜市の公開事例では、LGWAN接続系とインターネット接続系の間に出口を設け、特定クラウドサービスだけを使えるローカルブレイクアウトで Microsoft 365 Apps for Enterprise を活用しています。まずは認証・更新や最小限のクラウド利用から始めたい自治体に近い発想です。 (Microsoft)
- 町田市では、一台の端末でAVDを切り替えながらLGWAN接続系、マイナンバー利用事務系、インターネット系を使う形を公開しています。窓口業務のように切替頻度が高い部署では、直結よりこちらの方が現実的な場合があります。 (Microsoft)
- 山口県の公開事例では、α’モデルと Microsoft 365 E3 / E5 Security を組み合わせ、2030年頃の新たなネットワーク像も視野にゼロトラストを進めています。今すぐ全部を変えず、将来像と足元の運用を分けて考える例として参考になります。 (Microsoft)
どの事例にも共通するのは、「Microsoft 365を全部つなぐ」のではなく、使う範囲を切っていることです。ここを真似るだけでも、設計の難易度はかなり下がります。
失敗しやすいポイント
- 最初からフル機能前提で設計する：α’(ア)〜(ウ)は要求水準が違うため、会議中心なのか、外部ファイル交換まで必要なのかを先に分けないと、過剰設計か対策漏れになりやすくなります。 (パブリックコメント)
- 自テナントと外部テナントを同じ扱いにする：外部団体テナントでの会議参加やファイル交換は、LGWAN接続系端末で無理に完結させない方がガイドラインと整合しやすいです。 (パブリックコメント)
- Teamsだけ見てファイル制御を後回しにする：Teamsのファイル共有はSharePointとOneDriveまで含めて設計しないと、DLPやラベル付けが片手落ちになります。 (Microsoft Learn)
- 固定の許可リストを手運用する：Microsoft 365のエンドポイントは変わるため、一覧表を手で更新し続ける前提は壊れやすく、運用事故の温床になりやすいです。 (Microsoft Learn)
- ISMAP登録だけで選定を終える：言明対象範囲、統制目標、SLA、終了時データ移行、インシデント報告義務まで確認して初めて比較になります。 (パブリックコメント)
- 監査と例外運用を設計しない：α’は事前外部確認と定期監査が前提なので、導入後の監査計画や例外申請フローを後回しにすると運用で詰まります。 (パブリックコメント)
導入前に作ると迷わない1枚
判断を早くするには、会議室で大きな構想図を描く前に、次の1枚を作る方が効果的です。
| 項目 | まず決めること |
|---|---|
| 使う機能 | Apps認証・更新 / Teams会議 / チャット / ファイル共有 / 外部メール |
| アクセス先 | 自テナントのみ / 外部テナントあり |
| LGWANへの取り込み | なし / メール添付のみ / ファイルあり |
| 端末 | LGWAN端末 / インターネット端末 / 画面転送 / AVD |
| 候補方式 | α’(ア) / α’(イ) / α’(ウ) / LGWAN-ASP / 画面転送 |
この表が埋まると、「本当に必要な通信だけを許可する」議論に変わります。逆にこれがないと、ネットワーク、端末、認証、業務部門がそれぞれ違う前提で話し始め、要件が膨らみやすくなります。なお、候補方式の切り分けは、総務省ガイドラインのα’(ア)〜(ウ)と2025年の画面転送検討をベースにしています。 (パブリックコメント)
まとめ
LGWAN環境からMicrosoft 365へ安全接続する考え方で重要なのは、接続の可否よりも、利用目的を小さく切り、外部テナント参加の有無とファイルの出入りで方式を選ぶことです。認証・更新だけならα’(ア)、会議中心で内部取り込みなしならα’(イ)、外部とのファイル送受信まで行うならα’(ウ)が基準になります。外部テナント参加や一台端末運用を重視するなら、LGWAN-ASP、画面転送、AVD、インターネット側端末併用まで含めて考える方が安全で現実的です。 (パブリックコメント)
次にやるべきことは一つです。自団体で使いたいMicrosoft 365の機能を「認証・更新」「会議・コミュニケーション」「外部ファイル交換あり」の3段階に分け、外部テナント参加の有無とLGWANへの取り込み有無を表にしてください。その1枚ができれば、必要最小限の接続方式と対策が見え始めます。
コメント