自治体ネットワークの次期モデルはどう選ぶか｜α′・β・β′の判断軸と段階移行

「三層分離を見直したい」という相談が急速に増えています。基幹業務システムのガバメントクラウド移行が視野に入り、クラウドサービスを前提とした働き方に切り替える必要が出てきたためです。

一方で、実際に検討を始めると最初に詰まるのが「どのモデルを目指すのか」という論点です。総務省のガイドラインが示すα′・β・β′は、単なるセキュリティ強度の段階ではありません。業務システムと業務端末をどこに置くかという設計思想の違いです。ここを取り違えたまま調達仕様書を書くと、後工程で全体を組み直すことになります。

本記事では、複数の自治体でネットワーク移行とグループウェア刷新の支援に入ってきた立場から、モデル選定の判断軸を整理します。

4つのモデルの構造的な違い

前提として、従来型の三層分離がαモデルです。マイナンバー利用事務系・LGWAN接続系・インターネット接続系を分離し、職員はLGWAN接続系の端末で業務を行い、インターネットは画面転送方式で利用します。三層分離そのものの仕組みは自治体の三層分離とLGWANで解説しています。

そこからの発展形が3つあります。

表で並べると分かりやすいのですが、α′とβは「端末の置き場所が逆転している」という点が本質です。α′はローカルブレイクアウトによって画面転送を経由せずSaaSを使えるようにする考え方であり、端末そのものは内側に残ります。技術的な詳細はLGWANローカルブレイクアウトとはで扱っています。

β′はβをさらに進め、LGWAN接続系にあった業務システムもインターネット接続系に配置します。境界での分離に依存せず、情報資産単位のアクセス制御と継続的なモニタリングで守る設計に移るということです。

採用状況には規模による偏りがある

移行の進み方には、団体規模による明確な偏りがあります。β′モデルは都道府県で3割強、政令指定都市で4割程度が採用している一方、中核市・特別区では8割以上、その他の市町村では9割以上が依然としてαモデルにとどまっています。

この数字が示しているのは、技術的な難易度ではなくコストと運用負荷が移行の壁になっているという事実です。β′に必要な対策は、導入すれば終わりではなく、継続的に運用して初めて機能します。人口規模が小さいほど、その継続を担う体制を確保しにくい。ここが本質的な制約です。

選定を左右する3つの判断軸

1. 情報システム部門の体制

これが実質的に最も重い制約です。β′は情報資産単位でのアクセス制御、継続的なモニタリング、エンドポイント対策の運用が前提になります。専任職員が1〜2名、しかも数年で人事異動がある体制で、この運用を内製で回すのは現実的ではありません。

支援に入ったある自治体（人口規模2万人前後、想定アカウント数500〜600）では、この点を最初に確認しました。結論として、目指す姿はβ′に置きつつ、初期段階ではα′で立ち上げ、運用が定着してから段階移行する構成を提案しています。α′はβ′への「途中段階」として用意された選択肢であり、体制が整わないうちに一足飛びに進む必要はありません。

逆に言えば、運用を外部委託する前提を置けるなら、体制の制約は緩みます。ただしその場合は、委託先に何をどこまで任せるかを調達段階で具体化しておく必要があります。「監視を委託する」だけでは、インシデント発生時に誰が判断するのかが決まりません。

2. 既存資産の更新タイミング

ネットワーク機器、サーバー、グループウェアの更新時期がバラバラだと、モデル移行のタイミングを取りにくくなります。逆に言えば、複数の更新が重なる年度は移行の好機です。

数千名規模のある市の案件では、グループウェア更改とネットワーク更改を同一プロジェクトとして扱い、切替時期を揃える設計にしました。別々に走らせると、移行期間中に「旧ネットワーク×新グループウェア」という検証負荷の高い組み合わせが発生してしまうためです。

更新時期が揃わない場合は、先に動かせる部分から順に着手し、あとで合流させる計画を立てることになります。この場合、中間状態がどれだけ続くかを明示しておかないと、暫定構成がそのまま定着します。

3. 都道府県セキュリティクラウドとの調整余地

見落とされやすい論点です。α′でローカルブレイクアウトを行う場合も、β／β′で通信経路を変える場合も、都道府県セキュリティクラウド側との通信要件の調整が発生します。

この調整は市町村単独では完結せず、リードタイムも読みにくいものです。県側の更改スケジュールや、他団体との共通仕様の制約が絡むこともあります。構想段階で県側に一度当てておくだけで、後の手戻りがかなり減ります。

モデル名より先に決めるべきこと

実務上、最初にモデル名を決めてしまうのはお勧めしません。先に固めるべきは以下の3点です。

この3点が決まると、選べるモデルはほぼ自動的に絞られます。逆に、ここが曖昧なまま「β′を目指す」と宣言すると、調達仕様書に書けない項目が大量に残ります。

無害化の扱いも同じ構造です。モデルを変えても無害化をそのまま維持すれば、クラウド化の効果は大きく削がれます。この論点は無害化はどこまで残すべきかで個別に扱っています。

段階移行という現実解

「最終的にβ′を目指す」ことと「今回の更改でβ′に移る」ことは別の話です。両者を混同すると、体制が追いつかないまま運用が始まり、結局は例外運用だらけになります。

現実的な進め方は、次のような順序です。

1. クラウド化する業務範囲と庁外アクセス方針を確定する
2. その範囲で必要な対策を洗い出し、内製できるものと委託するものを分ける
3. 初期構成としてα′を選び、対象クラウドサービスを限定して立ち上げる
4. 運用が定着し、検知・対応の実績が積み上がった段階でβ／β′への移行を判断する

一度で理想形に到達しようとしないことが、結果的には最短経路になります。ガイドラインが複数のモデルを併記しているのは、団体ごとに到達点が違ってよいという前提があるからです。

よくある質問

α′・β・β′モデルの違いは何ですか？

セキュリティ強度の段階ではなく、業務システムと業務端末をどこに置くかという配置設計の違いです。α′は三層分離の構造を維持したまま特定のクラウドサービスへ直接接続を許容する方式、βは業務端末をインターネット接続系に移して業務システムはLGWAN接続系に残す方式、β′は業務システムもインターネット接続系に配置する方式です。

小規模な自治体がいきなりβ′を目指すのは無理がありますか？

運用体制の確保が最大の制約になります。β′は情報資産単位のアクセス制御、継続的なモニタリング、エンドポイント対策の運用が前提です。専任職員が1〜2名で人事異動もある体制では内製での運用は現実的ではありません。目指す姿をβ′に置きつつ、初期はα′で立ち上げて段階移行する構成が現実的です。

モデルを決める前に何を固めておくべきですか？

クラウドに載せる業務の範囲、庁外からのアクセスをどこまで認めるか、インシデントの検知と対応を誰が担うかの3点です。この3点が決まると選べるモデルはほぼ自動的に絞られます。逆にここが曖昧なままモデル名を先に決めると、調達仕様書に書けない項目が大量に残ります。

都道府県セキュリティクラウドとの調整はいつ始めるべきですか？

構想段階です。α′でローカルブレイクアウトを行う場合も、β・β′で通信経路を変える場合も、県側との通信要件の調整が発生します。この調整は市町村単独では完結せずリードタイムも読みにくいため、要件を固める前に一度当てておくと後の手戻りが減ります。

ネットワーク更改とグループウェア更改は分けたほうがよいですか？

更新時期が近いなら、同一プロジェクトとして扱い切替時期を揃えるほうが安全です。別々に走らせると、移行期間中に旧ネットワークと新グループウェアという検証負荷の高い組み合わせが発生します。時期が揃わない場合は、中間状態がどれだけ続くかを明示したうえで順に着手します。

まとめ

α′・β・β′は、セキュリティ強度の段階ではなく、業務システムと業務端末の配置設計の違いです。機能比較の表を眺めても選定は進みません。

実際に選定を左右するのは、情報システム部門の運用体制、既存資産の更新時期、都道府県セキュリティクラウドとの調整余地の3点です。とりわけ体制は、導入後に継続して運用できるかを決める最も重い制約になります。

そして、モデル名より先に「クラウド化する業務範囲」「庁外アクセスの方針」「検知と対応の担い手」を固めてください。ここが決まれば、選べるモデルは自然に絞られます。小規模な団体では、α′を経由した段階移行が現実的な解になりやすい構図です。