自治体や官公庁関連のシステム案件に関わっていると、「三層分離」という言葉を当たり前のように使われて戸惑った経験はありませんか。三層分離とは、自治体の情報システムを3つのネットワークに分割して運用する情報セキュリティ対策のことで、マイナンバー制度の開始とセットで語られることが多い用語です。この記事では、三層分離とは何か、なぜ導入されたのか、αモデル・βモデルといった種類の違い、そして現在進んでいる見直しの動きまでまとめました。
三層分離とは？（定義・基礎知識）
三層分離の定義
三層分離とは、地方自治体の情報システムを3つのネットワークに分割して運用するセキュリティモデルです。具体的には「マイナンバー利用事務系」「LGWAN接続系」「インターネット接続系」に分け、相互の通信を制限することで情報漏えいリスクを下げます。総務省の資料によると、2015年の日本年金機構の情報漏えい事案を受けて2015年12月に「自治体情報セキュリティ対策の抜本的強化」の方針が示されました。これを具体化する形で、2016年3月に「自治体情報システム強靭性向上モデル」が策定されています。三層分離とはこの強靭性向上モデルの中核をなす考え方で、全国の自治体に導入が求められました。
なぜこの用語が使われるようになったか
年金機構の事案では、インターネットに接続された職員の業務端末が標的型攻撃を受け、個人情報が外部に流出しました。この教訓から生まれたのが、機微な情報を扱う系統とインターネット接続系を物理的に切り離すという発想です。マイナンバーを扱う系統と、メールやWebブラウジングを行う系統を分けたことで、「三層分離」という呼び方が定着しました。以降、全国のほぼすべての地方自治体がこのモデルに沿ったネットワーク再構築を実施しています。
三層の内訳
- マイナンバー利用事務系: 税・福祉などマイナンバーを直接扱う業務システム。最も厳格に分離される
- LGWAN接続系: 総合行政ネットワーク(LGWAN)に接続し、自治体間連携や庁内の主要業務を行う系統
- インターネット接続系: メール送受信やWeb閲覧など、外部との接続が必要な業務を行う系統
三層分離の具体例
三層分離とは具体的にどのような運用になるのか、代表的なパターンを見てみましょう。
- 端末を系統ごとに物理的に分ける: 系統専用の端末を別々に用意し、職員は業務内容に応じて端末を使い分ける
- 仮想デスクトップ(VDI)で分離する: 物理端末は1台のまま、インターネット接続系の画面だけを仮想デスクトップ上に表示する。通信自体は分離されたサーバー側で行う
- 無害化処理を挟んでファイルをやり取りする: 受信したファイルはマルウェア検査や形式変換(無害化)を経てから、他の系統に取り込む
初めて「三層分離環境なので」と言われたとき、正直ピンと来ませんでした。
αモデル・βモデルの違い
従来の三層分離モデル（αモデル）
三層分離とは、導入された当初の構成が現在「αモデル」と呼ばれているものを指します。3系統を厳格に分離するのが基本方針で、特にインターネット接続系は職員の端末とは別のVDI環境を経由してのみアクセスできる構成でした。
αモデルの課題
αモデルは情報漏えいリスクを大きく下げた一方で、クラウドサービスの普及に対応しづらいというデメリットが指摘されるようになりました。SaaSやテレワーク環境の利用が進む中、インターネット接続系を経由しないと使えないクラウドサービスが増えたためです。業務効率の低下や、VDIサーバーの負荷集中によるコスト増も問題視されるようになりました。
βモデル・βダッシュモデルへの移行
こうした課題を受けて、総務省は2020年、「βモデル」「β’（ベータダッシュ）モデル」という発展形を示しました。βモデルは、業務端末をインターネット接続系に統合しつつ、業務システム自体はLGWAN接続系に残し、端末から画面転送方式でアクセスする構成です。端末側はインターネットに直結しながら、実際の業務システムはLGWAN接続系側にとどめる構成です。これにより、クラウドサービスの利用しやすさと一定のセキュリティレベルの両立を図っています。β’モデルはさらに踏み込み、業務端末だけでなく業務システムそのものもインターネット接続系へ移行し、LGWAN接続系との分離をほぼ解消する構成です。なお、マイナンバー利用事務系についてはαモデル・βモデル・β’モデルのいずれを採用しても厳格な分離が維持され、緩和の対象にはなりません。自治体の実情に応じて、αモデル・βモデル・β’モデルのいずれかを選択できる形になっています。
なお2024年には、既存構成を大きく変えずに導入できる新モデルも示されました。LGWAN接続系から特定のクラウドサービスへ「ローカルブレイクアウト」という仕組みで直接アクセスする「α’（アルファダッシュ）モデル」です。実務ではこちらも選択肢に加わっています。
各モデルの比較
三層分離とはいえ、モデルによって構成の違いは小さくありません。各モデルの違いを整理すると、次のようになります。
| 項目 | αモデル | βモデル | β’モデル |
|---|---|---|---|
| 業務端末の配置 | LGWAN接続系 | インターネット接続系（画面転送で業務システムにアクセス） | インターネット接続系 |
| 業務システムの配置 | LGWAN接続系 | LGWAN接続系のまま | インターネット接続系に移行 |
| マイナンバー利用事務系の分離 | 厳格に分離（他モデルと共通） | 厳格に分離（他モデルと共通） | 厳格に分離（他モデルと共通） |
| クラウド活用のしやすさ | 低い | 中程度 | 比較的高い |
| 移行のハードル | 導入済み自治体が多い | 既存構成からの再設計が必要 | βモデルからさらに大規模な再設計が必要 |
三層分離とはどのモデルを選ぶかによって負担が変わる仕組みで、自治体の人口規模・既存システムの構成・予算によって最適解は異なります。人口規模の小さい自治体では、共同利用型クラウドサービスを活用してβモデルへの移行コストを抑える動きも見られます。
三層分離の課題と今後の方向性
ネットワーク分離による業務効率の低下
三層分離とは実務上の負担も無視できない仕組みです。系統をまたぐ作業のたびに端末やVDI環境を切り替える必要があり、単純な資料作成やメール対応にも余計な手間がかかるという声は根強くあります。ファイルの無害化処理にも時間がかかり、急ぎの対応が求められる場面で足かせになることもあります。三層分離とはこうしたトレードオフを常に伴う仕組みです。
クラウド活用が制限される
インターネット接続系を経由しないとクラウドサービスにアクセスできない構成のままだと、SaaSの活用が進みにくいという課題があります。民間企業では当たり前になっている使い方だけに、ギャップは大きくなりがちです。βモデルへの移行はこの点を緩和するものですが、既存システムの再設計や予算確保が必要で、対応が済んでいない自治体も少なくありません。三層分離とはこの点で、民間企業のクラウド活用の発想とは前提が大きく異なる仕組みだといえます。
ゼロトラストへの移行という方向性
デジタル庁は中長期的な方向性として、ネットワークの物理的な分離ではなく、通信のたびに認証・検証を行う「ゼロトラスト」の考え方への移行を打ち出しています。三層分離とはあくまで現時点でのモデルであり、今後は段階的に見直されていく前提だといえます。三層分離とはネットワークの物理的な分離を前提とする仕組みです。今後はエンドポイントセキュリティの強化やアクセス制御の高度化によって、分離に頼らずに安全性を担保する構成へ移行していく流れです。ただし、全国の自治体で一斉に移行が完了する段階には至っておらず、当面はαモデル・βモデル・ゼロトラストが混在する期間が続くとみられます。
要件定義の段階で、どのモデルが前提かは必ず確認しておきたいところです。
三層分離運用で実際に困りやすいこと
実際に三層分離環境で3ヶ月ほど運用してみると、資料には出てこない細かな困りごとに直面することがあります。承認フローの存在に気づかずに作業を進めてしまい、後から差し戻しになる失敗も起こりがちです。
- 系統をまたぐデータ連携に承認フローが必要: ちょっとした集計作業でも、系統間でファイルを移すには申請・承認のプロセスを経る必要がある。即日対応が難しいケースもある
- VDI環境の動作が重く、開発・検証作業がしづらい: VDI環境上での開発・テストはローカル環境に比べて動作が重い。大量データを扱う検証には向かないことがある
- 系統ごとにアカウント管理が分かれ、運用負荷が増える: 職員一人あたり複数系統のアカウントを管理する必要がある。異動・退職時の棚卸し作業も煩雑になりやすい
三層分離に関わる主な法令・ガイドライン
三層分離とはいっても、この言葉自体が特定の法律の条文に登場するわけではありません。以下の法令・ガイドラインが根拠として関係します。
- マイナンバー法（正式名称: 行政手続における特定の個人を識別するための番号の利用等に関する法律）: マイナンバー事務の情報保護の枠組みを定める法律
- 個人情報の保護に関する法律（個人情報保護法）: 自治体が保有する個人情報全般の取り扱いを規律する
- 総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」: 三層分離を含む具体的な対策要件を示す、実務上もっとも参照される文書
システム調達や設計の際は、これらの一次情報を発注元の自治体情報システム部門とあわせて確認しておくと、要件の解釈違いによる手戻りを防ぎやすくなります。特にマイナンバー法と個人情報保護法は、条文自体が改正されることもあるため、最新版を確認する習慣をつけておくと安心です。
三層分離とマイクロセグメンテーションの違い
三層分離とはどのようなものか、民間企業のインフラエンジニアが自治体案件に初めて携わると「これはマイクロセグメンテーションと同じでは」と感じることがあります。両者は「ネットワークを分割してリスクを局所化する」という発想は共通していますが、前提が異なります。
マイクロセグメンテーションは、ワークロード単位・アプリケーション単位で通信を制御する技術的な手法です。必要に応じて柔軟に境界を引き直せる点が特徴です。一方、三層分離とは業務の性質に基づいた3分類が前提になっている概念です。ガイドラインに沿った運用ルール(申請・承認フロー、無害化処理など)とセットで語られる点が大きく異なります。技術要素だけでなく、組織的な運用ルールまで含めて理解する必要があるのが三層分離の特徴だといえます。
よくある質問（FAQ）
三層分離は法律で義務付けられているのですか？
三層分離とは、法律で直接義務付けられているものではありません。総務省が策定した「自治体情報セキュリティ対策の抜本的強化」の方針に基づき、多くの自治体が導入しています。マイナンバー法や個人情報保護に関する各種ガイドラインとあわせて、事実上の標準的な対策として運用されています。民間企業でも三層分離という言葉は使いますか？
三層分離という呼び方自体は自治体・官公庁の文脈で使われることがほとんどです。民間企業では、同様の発想を「ネットワークセグメンテーション」等の別の用語で表現することが多く、意味合いは近くても呼び方は異なります。三層分離とゼロトラストは両立しますか？
両立可能です。デジタル庁の資料によると、今後は物理的な分離を段階的に緩和する方向性が示されています。かわりに、ゼロトラストの考え方(通信のたびに認証・検証を行う)を組み合わせていく想定です。移行期には両方の要素が混在した構成になります。αモデルからβモデルへの移行にはどのくらい費用がかかりますか？
三層分離とは規模の大きい構成変更をともなうため、自治体の規模やシステム構成によって費用は大きく異なり、一概には言えません。三層分離とは既存のVDI環境の再設計やネットワーク機器の追加をともなうことが多く、数百万円から数千万円規模の予算が組まれることが一般的です。移行を検討する場合は、複数のベンダーから見積もりを取って比較することをおすすめします。三層分離の対象はどの自治体ですか？
三層分離とは、都道府県・市区町村を問わず、マイナンバーを扱う情報システムを運用するすべての地方自治体が対象となる対策です。人口規模の小さい自治体でも同様の対策が求められるため、共同利用型のクラウドサービスを活用して負担を軽減する動きも広がっています。三層分離の見直しで、セキュリティレベルは下がりませんか？
三層分離とはあくまで手段の一つであり、目的は情報漏えいリスクの低減です。βモデルやゼロトラストへの移行は、分離を緩和する代わりにエンドポイントセキュリティの強化やアクセス制御の高度化を組み合わせる設計になっています。単純に分離をなくすのではなく、別の手段でリスクを補う考え方のため、設計・運用が適切であればセキュリティレベルを維持できるとされています。三層分離環境ではリモートワーク（テレワーク）はできますか？
三層分離とは、αモデルのままだとVDI環境へのリモートアクセスに制限が多く、テレワークとの相性はあまり良くありません。βモデルへの移行によって、LGWAN接続系から直接利用できるクラウドサービスが増えれば、テレワークの選択肢も広がりやすくなります。実際にどこまで対応できるかは自治体ごとのシステム構成次第です。三層分離の設計・保守を担当するにはどんなスキルが必要ですか？
三層分離とはネットワーク設計やファイアウォール・VDI基盤の知識に加えて、総務省ガイドラインなど自治体特有の要件を読み解く力が求められる分野です。民間企業向けのインフラ構築経験だけでは前提条件が異なる部分も多くあります。自治体案件特有の制約（申請フローや無害化処理の仕様など）を早い段階で把握しておくことが重要です。まとめ
三層分離とは、自治体の情報システムを3つの系統に分割して運用するセキュリティ対策で、年金機構の情報漏えい事案をきっかけに導入されました。従来のαモデルはセキュリティを重視する一方で業務効率やクラウド活用の面で課題があります。そのため、βモデル・β’モデルへの移行や、将来的なゼロトラストへの転換が進められています。
自治体システムの案件に関わる際は、対象システムがどのモデルを前提にしているかを早い段階で確認しておくと、後工程での手戻りを防げます。特に見積もり・要件定義の段階で「αモデルのまま」なのか「βモデルへの移行を含む」のかを取り違えると、設計方針が根本から変わってしまいます。発注元の情報システム部門とのすり合わせを丁寧に行うことをおすすめします。
関連して、ネットワークの冗長化について知りたい方はこちらもご覧ください。