三層分離の次へ───2030年を見据えた自治体ネットワークのゼロトラスト設計を考える

1.国はゼロトラストを本番運用している ─ GSS(ガバメントソリューションサービス)の現在地

「ゼロトラストはバズワード」と言われた時期もありましたが、少なくとも霞が関では、すでに実装段階に入っています。

デジタル庁が整備・提供するガバメントソリューションサービス（GSS）は、各府省庁が個別に整備してきたLAN・業務端末環境を、政府共通の環境に統合していく取り組みです。その設計思想の中核に置かれているのがゼロトラストアーキテクチャでした。境界の内側だからといって信頼しない。ユーザーと端末を都度検証し、アクセス制御を「ネットワークの場所」ではなく「アイデンティティ」起点で行う。この前提によって、庁舎の中でも外でも同じセキュリティレベルで業務ができる環境が動いています。

個人的に大事だと思うのは、これが構想や実証ではなく「政府の標準業務環境」として本番運用されている、という点です。デジタル庁の活動報告によれば、GSSの導入府省庁は14機関、接続ユーザーは4.5万人(2025年7月時点)。その後も各府省庁の移行は順次進められています。日本の行政機関のゼロトラストは、検討の段階を越えて、拡大の段階に入っています。

参照：デジタル庁「ガバメントソリューションサービス(GSS)について」(政策評価・行政事業レビュー有識者会議資料、2024年5月)、デジタル庁「2025年デジタル庁活動報告」

2.自治体へのゼロトラスト展開が始まった ─ 検証事業の最終報告書とガイドライン改定

国の環境が整えば、次は地方です。

デジタル庁は「国・地方ネットワークの将来像」の検討を進めており、令和7年度には自治体が参加する検証事業が実施されました。方式は2つ。デジタル庁のGSSを自治体が利用する「GSS利用方式」と、各自治体が独自に提案する「自治体提案方式」です。検証されたのは、ゼロトラスト導入時の運用負荷やコスト、自治体の規模に応じた課題、国・都道府県・市区町村の役割分担といった、かなり実務寄りの論点でした。

そして2026年3月31日、この検証事業の最終報告書が公表されました。報告書に添えられた自治体側の意見をみると、境界型対策への追加投資はできるだけ抑えたい、設備更新のタイミングに合わせてゼロトラスト構成を取り入れていきたい、といった率直な声が寄せられています。少なくとも検証に参加した自治体では、議論が「やるかやらないか」から「いつ・どうやるか」に移りつつあることがうかがえます。

同じ2026年3月には、総務省の自治体向けセキュリティガイドラインも改定されました。改定内容の詳細は、解説記事【2026年3月改定】3つの観点で整理！自治体向け総務省セキュリティガイドラインの改定ポイントにまとまっているので、あわせてご覧ください。

つまり、検証事業の報告書とガイドライン改定という大きな材料が、この春に出揃ったわけです。

参照：デジタル庁「国・地方ネットワーク」(検証事業の採択案件・経過報告・最終報告書を掲載)、デジタル庁「令和7年度 国・地方ネットワークの将来像の実現に向けた検証事業の採択案件について」(2025年4月30日)、総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」(2026年3月改定)

3.三層分離（三層の対策）は「失敗」だったのか ─ 役割と限界を整理する

念のため補足しておくと、三層の対策（マイナンバー利用事務系・LGWAN接続系・インターネット接続系の分離）は、失敗だったとは考えていません。2015年の年金機構の情報流出を受けて、限られた時間で全国の自治体のセキュリティ水準を一斉に引き上げた施策として、その役割を十分に果たしたと思っています。

ただ、10年が経ち、副作用も見えてきました。

• 業務効率との衝突：クラウドやテレワークが前提の時代に、ネットワーク分離は職員の業務動線とぶつかりがちです。ファイルの受け渡し、無害化処理、画面転送など、「分離を守るための仕事」が増えていきます。
• 境界モデルの構造的な限界：分離は「境界の内側は安全」という前提に立ちます。一方で攻撃の主流は、正規アカウントの認証情報の窃取やサプライチェーン経由の侵入に移りました。境界を越えられた後の内部移動(ラテラルムーブメント)に、分離モデルはどうしても弱くなります。
• 運用負荷の偏り：分離環境の維持や例外管理は、情報システム担当が数名（ときには1名）の市区町村に重くのしかかります。セキュリティ専任者を置ける自治体は、ごく一部です。

ゼロトラストへの移行は、この3つへの構造的な回答になり得ます。ただ、ここに新しい落とし穴もあると感じています。

4.自治体のゼロトラスト導入でつまずく2つの落とし穴

ゼロトラストの解説の多くは、ID管理（IDaaS）、端末防御（EDR）、クラウドアクセス制御（SASE）を中心に語られます。それ自体は正しいのですが、自治体の現場でこのレシピをそのまま実装しようとすると、2つの問題にぶつかるはずです。

1つめは「ツールが増えること」

IDaaS、EDR、VPN代替、NAC、資産管理───　個別最適のツールを足していくと、管理コンソールが5つ6つと増えていきます。増えるのは画面の数だけではありません。ポリシーの設定箇所が分かれるので、職員の異動や退職のたびに複数のシステムで権限を直し、消し漏れがないかを突き合わせる作業が発生します。製品ごとにバージョンアップとライセンス更新の管理が要り、何かあったときは「どのツールのログを、どの順で見るか」から考えることになる。情報システム担当が数名、ときには1名という体制で、これを回し続けられるでしょうか。ゼロトラスト移行の一番の壁は予算ではなく、「導入した後、誰がそれを回すのか」ではないかと思います。国の検証事業で運用負荷や役割分担が主要な検証項目になったのも、同じ問題意識の表れだと受け止めています。

2つめは「ネットワークが置き去りになること」

ゼロトラストはID起点の考え方ですが、庁内にはユーザー認証や証明書認証に対応しにくい機器（複合機、ネットワークカメラ、施設管理系のIoTなど）が大量にあります。リモートアクセスだけをZTNA化しても、庁内LANにつながる未管理デバイスが残れば、内部移動のリスクは残ります。

しかも、庁内ネットワークの認証は「余裕があればやる」話ではなくなっています。総務省のガイドラインは、LGWAN接続系やマイナンバー利用事務系の端末で無線LANを利用する場合、認証サーバを用いたIEEE802.1X認証、具体的にはクライアント証明書による機器認証（EAP-TLS等）を求めています。つまり「正規の端末かどうかをネットワークの入口で確かめる」ことは、少なくとも該当する無線LAN利用環境では、すでにガイドライン上の要求事項として位置づけられています。ところが、これを自前でやろうとすると、認証サーバ（RADIUS）の構築・冗長化・保守に加えて、端末への証明書の配布と失効の管理という、継続的な運用がセットで付いてきます。1つめの「誰が回すのか」問題が、ここでも顔を出すわけです。

アクセス制御は、アプリケーションの入口だけでなく、有線・無線のポートレベルまで届いて初めて全体像になる───　これが私たちネットワーク側からの見方です。このあたりは「自治体・公共機関向けゼロトラストアクセスネットワークへの対応 ～スイッチ担当エンジニアの視点から～」でも掘り下げています。

5.自治体ゼロトラストにおける3つの設計要件

整理すると、自治体がゼロトラストを「自分の環境」で成立させるための要件は、次の3つに集約できそうです。それぞれ、「満たさないと何が起きるか」とセットで見ていきます。

要件1：ネットワークアクセスとアプリケーションアクセスのポリシーを、一貫して設計・運用できること。

庁内LANの認証とリモートアクセスの制御がばらばらのポリシーで運用されていると、何が起きるか。たとえば職員の退職時、庁内の認証からは外したのにリモートアクセス側の設定が残っていた───という消し漏れは、管理が分かれているほど起きやすくなります。「庁内では触れない情報に、外からはアクセスできてしまう」という不整合も同じ構造です。ポリシーの不整合は、手間の問題である以上に、穴の温床です。同一のポリシー基盤に統合できれば、設定不整合や運用負荷の低減につながります。もっとも、単一基盤でなければ成立しない、という話ではありません。別々の製品を組み合わせる場合でも、ID基盤との連携や運用ルールの統制によって一貫性を保つ設計はあり得ます。次期更改の仕様を考えるなら、「庁内の認証とリモートアクセスのポリシーを、一貫した形で設計・確認できるか」は確認項目に入れておきたいところです。

要件2：運用を複雑化させないこと。

前章で触れたとおり、証明書ベースの端末認証を自前で満たそうとすると、認証サーバの構築・冗長化・保守と、証明書の配布・失効管理が新たな仕事として乗ってきます。新しい基盤の導入が、新しいサーバの維持や専任者の確保を前提にするなら、多くの市区町村では現実的な運用モデルになりません。現実解の一つは、認証の仕組みそのものはクラウド型のサービスとして持ち、手元では対応する既存のスイッチや無線APを、認証ポリシーの適用ポイントとして活用する構成です。なお、ゼロトラスト移行で新しい運用が完全になくなることはありません。証明書、IdP、例外管理───増えるものは増えます。だからこそ、それ以外の負荷をどこまで抑えられるかが効いてきます。確認すべきは「庁内に管理対象のサーバを増やさずに、この認証を実現できるか」。ここが、机上のゼロトラストと運用できるゼロトラストの分かれ目だと考えています。

要件3：段階移行ができること。

三層分離環境を一気に捨てられる自治体はありません。予算は単年度で、基幹業務を止めるリスクは取れない。だから「全面刷新が前提」の提案は、正しくても通りません。現実的な道筋は、まず、ガイドライン対応にもつながる無線LAN認証の強化や、有線を含むネットワーク入口の認証見直しから入り、次にリモートアクセスのZTNA化、その先でセグメント設計の見直しへ、と既存環境と共存しながら一歩ずつ進む形です。大事なのは、各段階がそれ単独でも意味を持つこと。最初の一歩（認証強化）は、その後の計画が多少遅れても、ガイドライン対応・監査対応として無駄になりません。「途中で止まっても投資が無駄にならない順序になっているか」も、計画を評価する物差しになります。

この3つをどこまで一貫した設計・運用モデルで実現できるか───。これが、製品やサービスを比較する際の重要な確認ポイントになります。

6.実装例：NACとZTNAを統合する「Extreme Platform ONE Security」

この3要件を1つのサービスとして実装している例として、Extreme NetworksのExtreme Platform ONE™ Security（旧称：ExtremeCloud Universal ZTNA）を紹介します。特徴は、NAC（ネットワークアクセス制御）とZTNAの統合です。クラウド上の単一のポリシーエンジンが、2つのアクセス経路をまとめて制御します。

ネットワークアクセス（Cloud NAC）

• どんな機能か：クラウドからRADIUS機能をサービスとして提供（RADIUS as a Service）し、対応する有線スイッチ・無線APを認証ポリシーの適用ポイントとして活用します。Extremeの無線AP/スイッチはRADIUS連携による802.1X認証に対応しており、ガイドラインが求めるEAP-TLS（クライアント証明書）による機器認証を利用できます。802.1Xに加えてMAC認証にも対応し、ユーザー認証や証明書認証に対応しにくい複合機やIoTなどの機器も制御下に置けます。通信はTLSトンネル（RadSec）で保護されます。
• 自治体にとっての価値：Extreme Platform ONE SecurityのCloud NACを利用することで、オンプレミスのRADIUSサーバや、新たなExtremeControl環境を個別に構築・運用する負担を抑えられます。4章で見た「誰が回すのか」問題に対する、負担軽減の選択肢になり得ます。有線・無線の入口認証を一貫した設計で扱える点も利点です。
• それでも残る運用：証明書の発行・配布・失効といった証明書自体のライフサイクル管理は、どの製品を選んでも別途の設計が必要です。ここは製品では消えない仕事として、移行計画に織り込んでおくべき部分です。

アプリケーションアクセス（ZTNA）

庁内・データセンター・IaaS上のアプリケーションへのリモートアクセスを、ユーザーとアプリケーション単位の最小権限で制御します。エージェント方式に加えてブラウザだけで使えるエージェントレス方式もあり、委託事業者や会計年度任用職員のような「端末を管理しきれない利用者」へのアクセス提供にも向いています。IdPはMicrosoft Entra ID、Google Workspace、Okta、HENNGE Oneなどと連携できます。

本製品の海外における初期導入のお客様は、主に地方自治体や教育機関でした。ネットワーク担当者がセキュリティを兼務しているケースが多く、専任者を配置しにくい一方で、守るべき情報や分散した拠点を抱えているという点で、海外の自治体・教育機関の状況は日本の市区町村と共通する部分が多くあります。

もちろん、Extreme Platform ONE Securityだけでゼロトラストが完成するわけではありません。ID基盤との連携設計、端末防御との組み合わせ、庁内のセグメント設計の見直しまで含めて、ようやく全体像です。それでも、「ネットワークの入口からアプリケーションの入口まで、1つのポリシーで貫く」骨格を、専任者なしで運用できる形にしている点は、自治体ゼロトラストの現実解の1つとして検討する価値があると思っています。

参照：Extreme Networks「Extreme Platform ONE Security」

© 2026 Extreme Networks, Inc. All rights reserved. Extreme Networks, the Extreme logo, and Extreme Platform ONE are registered trademarks or trademarks of Extreme Networks, Inc. and its subsidiaries in the United States and/or other jurisdictions.

Microsoft、Microsoft Entra ID、Microsoft Entra Intuneは、マイクロソフトグループの企業の商標です。
その他記載されている会社名・製品名は、各社の商標または登録商標です。

7.まとめ：次のネットワーク更改までに考えておきたいこと

検証事業の最終報告書とガイドラインの改定で、参考にできる材料はこの春、だいぶ増えました。とはいえ、自治体ごとに予算も体制も事情も違いますから、今すぐゼロトラストに舵を切ることだけが正解だとは思っていません。これまでの三層の対策を丁寧に運用してきたからこそ、いま守られているものも確かにあるはずです。三層の対策を否定するのではなく、その先にどのような環境を目指すのか。「三層分離の次」を見据え、今後5年、10年先の自治体ネットワークについて議論を始めるタイミングは、まさに今なのかもしれません。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
組織・製品等の名称は執筆時点のものです。