🎄 WiseVine Advent Calendar 2025 – Day 6！ 🎄
この記事は、WiseVine Advent Calendar 2025の記事です。
はじめに
こんにちは。WiseVine で SRE を中心に、幅広く技術領域を担当している jkkitakita です。
もともと Web 系スタートアップで SRE をしていましたが、GovTech スタートアップに来て 2 年が経ちました。
その中で経験してきた「行政ならでは」の話を、いくつかご紹介できればと思います。
突然ですが、普段は Web や SaaS の世界で SRE / インフラエンジニアをやっている人にとって、行政におけるインフラ・ネットワークってどういう印象がありますでしょうか。また「LGWAN」「ガバメントクラウド」「公共SaaS」っていうキーワードを聞いた時どう感じますでしょうか。
- なんとなく“レガシーで閉じてる世界”っぽい
- 「ガバメントクラウド」だけはなんとなく聞いたことあるけど、正体もよく分からない。それ以外はよく知らない。
- ほとんど SIer 製のオンプレミスパッケージなのでは？
- 仕様書が PDF で 100 ページあって、そっと閉じたことがある
自分も最初はそんな感じでした。でも、ちゃんと前提を理解しておくと見え方が変わります。
今回は前編・後編と分けて、これまで行政に関わったことなかったエンジニアが
「行政における案件ってそもそもどう生まれて、どうやってサービスが提供されているのか？」
を、個人的な見解も踏まえて、特にインフラ・ネットワークの目線で、ご紹介できればと思います。
1. その案件どこから来た？ ~ 入札・調達仕様書と“市場の生まれ方” ~
突然ですが、まずは、行政の案件ってどうやって立ち上がるのかについて簡単に触れておきたいと思います。
まず民間の Web 企業だと、だいたいこんな感じでサービスが生まれますよね。
- 既存市場やユーザー課題のリサーチをして、どこにニーズやポテンシャルがあるかを探る
- 社長や PdM、事業側が「こういうサービスをやりたい」と言う
- 企画・要件定義を一緒にやる
- エンジニアも最初から入って技術的な実現方法を詰める
- 実装して、試して、直していく
- サービスがユーザーに受け入れられ（いわゆる PMF して）、そこに市場ができてくる
一方で、特に基幹系・インフラ系の行政システム案件では、この「市場の生まれ方」と「最初のボールの投げられ方」が、民間サービスとはかなり違って見えます。
- まず行政側（自治体や国）の中で、
- 「この業務はもうアナログでは限界だ」
- 「制度改正に対応しないといけない」
- 「既存システムの更新時期が来た（ハード保守やリース、サポート終了など）」
といった業務・制度起点の課題が出てくる
- その課題に対して、国の方針や標準仕様、予算メニューなどが整備されていく
- この段階で、業界団体やベンダーが意見を出したり、勉強会・ヒアリングを通じて要件形成に影響を与えようとする提言・要望のプロセスも入ってくる
- そうして「この領域にこういうシステムが必要です」という市場の枠組みが作られる
- そのうえで各自治体が、自分たちの状況に合わせて、**「調達仕様書（要求仕様書）」**という形に落とし込む
- 調達仕様書を作成する前に、RFI（情報提供依頼書）を各事業者に求めて、情報収集することもあります。
- RFI で情報提供しないとこの案件が取れないというわけではありませんが、この段階から関わっておくと、自治体の課題や前提への理解が深まり、その後の入札でよりフィットした提案をしやすくなると感じています（特にスタートアップにとっては重要な接点になりがちです）。
- その後、仕様書が公示され、そこで初めて事業者側から見ると「このテーマの市場が立ち上がった」「この条件で競争してください」という形で、入札・提案のステージに出てくる
つまり、スタートアップが「サービスを作りながら市場を育てていく」パターンとは対照的に、
行政の世界では 「政策・制度・予算 →（必要に応じて提言・要望を含む要件形成）→ 仕様書 → 入札を通じた市場」 という順番で
案件と市場が立ち上がってくる傾向が強い、というのが最初の大きな違いです。
そしてこの過程で作成される調達仕様書の中には、機能要件だけじゃなくて、非機能要件やネットワーク・セキュリティの前提も細かく書かれています。
こうした前提条件までを含めて「事前にまとめて決めてから入札にかける」という構造自体が、行政案件がウォーターフォール型の進め方になりやすい背景のひとつになっていると感じます。
そもそも「入札」って何？
Web 系の世界で普通に仕事をしていると、「入札」ってあまり馴染みがないですよね。
でも、行政の世界では システムを作る・買うときは、原則として入札やプロポーザルなどの“公募プロセス”を経る のが基本です（例外もありますが）。
入札を Web 系エンジニアに例えると
かなりざっくり言うと、入札は 「公開コンペ付きの発注」 のようなイメージです。
[民間企業の場合]
社長「この SaaS 作りたいから、A 社に発注しよう」
→ 社内稟議通れば OK、直接契約
[行政の場合]
自治体「このシステム作りたい。でも税金使うから…」
→ 特定の会社だけに声をかけると不公平と言われる
→ 公平性・透明性を担保するために、公募して事業者を選ぶ
→ その代表的な仕組みが「入札」や「プロポーザル」
※実務では、金額が小さいものや特殊な事情があるものは「随意契約」といって、入札を行わずに契約するケースもありますが、ここでは「競争があるパターン」に絞って話します。
入札・公募の主なパターン（ざっくり）
自治体や案件規模によって呼び方や細かいルールは違いますが、ざっくり Web エンジニア目線で整理するとこんな感じです。
-
一般競争入札（オープンな価格競争寄り）
-
事前に定められた 入札参加資格・条件 を満たす事業者であれば参加できる
- 例：自治体の入札参加資格者名簿に登録されていること
○○市内に本店または支店を有すること、など
- 例：自治体の入札参加資格者名簿に登録されていること
-
価格を軸に選定されることが多い（最低価格落札方式）
-
ただし、
- 異常に安い価格（ダンピング）を排除する仕組み（最低制限価格・調査基準価格）や、
- 技術点も含めて評価する 総合評価方式 を採用している場合もあり、「一番安ければ必ず勝つ」というわけではありません。
-
-
プロポーザル・企画競争（提案内容で勝負するコンペ方式）
- 価格だけでなく、提案内容・体制・実績などを総合評価して選ぶ方式
- 「こういう課題があるので、こういうコンセプト・アーキテクチャ・体制で解決します」といった提案書・プレゼンを行う
- Web 系で言えば、「RFP に対して、アーキテクチャや UX、体制をまとめて提案し、スコアで選ばれる」ような感覚です。
- 規模が大きい案件や、仕様を完全にガチガチに決めきるのが難しい案件では、この方式が採用されることが多いです。
-
指名競争入札
- 自治体が あらかじめ複数の事業者を指名 し、その中で見積もり・価格競争をしてもらう方式
- ある程度の実績がある会社や、地域の業者などに絞って競ってもらうケースが多い
- 小規模案件や、一定のスピード感が必要な案件で使われることがよくあります。
※実務上は、「公募型プロポーザル → その結果を踏まえて随意契約で締結」など、入札とプロポーザルを組み合わせたプロセスもあります。
入札・プロポーザルのざっくりフロー
細かい手続きは自治体ごとに違いますが、Web エンジニアが雰囲気を掴むにはこのくらいで十分です。
[1] 自治体が「仕様書・要求水準書」などを作成
└─ 「こういうシステムが欲しい」「最低限こういう要件を満たしてほしい」
└─ プロポーザルの場合は「達成すべき水準・目的」を中心に書かれることも多い
[2] 公示（公開募集）
└─ 「この案件をやりたい事業者は応募してください」と公開される
└─ 自治体の HP や入札情報サービスで閲覧可能
[3] 事業者が応募・提案書／入札書を提出
└─ 仕様書を読み込んで、「うちならこう作ります」「こういう体制でやります」をまとめる
└─ 見積金額も提示する（入札方式か、見積方式かで形式は変わる）
[4] 審査・評価
└─ 価格だけでなく、提案内容・体制・実績などを総合的に評価する場合が多い
└─ 一般競争入札（価格中心）なのか、総合評価方式なのか、プロポーザルなのかで評価軸は変わる
└─ 評価委員会がスコアリングして、最も評価の高い事業者を決定
[5] 落札（または最優先交渉権者の決定）・契約
└─ 選ばれた事業者と正式に契約
└─ ここからやっと「開発スタート」
Web 系エンジニアが押さえておきたいポイント
1. 案件は「公示」された段階で、要件の大枠が決まっている
-
民間の受託開発だと、
- 「まずは一緒に要件定義しましょう」から始まるケースが多いですが、
-
行政では、
-
公募をかける時点で、一定レベルの要件が仕様書として固まっている
のが前提です。
-
公募をかける時点で、一定レベルの要件が仕様書として固まっている
-
なので、
- 「この仕様書の前提条件・業務フローを正しく読み解く力」がめちゃくちゃ重要です。
とはいえ、ゼロから毎回その自治体専用の業務を設計しているわけではありません。
-
住民記録、税、福祉、子育て支援…といった大きな業務の枠組みは、
地方自治法や個別法令・政令・省令などで、ある程度の共通のフレームがあります。 -
一方で、
- 実際の業務フロー・画面帳票・呼び方・決裁ルートなどは、
各自治体の 条例・規則・要綱・内部ルール によってかなり違います。
- 実際の業務フロー・画面帳票・呼び方・決裁ルートなどは、
-
そのため、
- 既に導入実績のある自治体の仕様書はとても参考になりますが、
そのまま横展開すれば終わり とは考えない方が安全です。
- 既に導入実績のある自治体の仕様書はとても参考になりますが、
実務的には：
既存のお客様自治体のときに使われた仕様書・成果物を参考にしつつ、
新しい自治体の業務・ルールとどこが違うかを確認しながら
「どこまで共通化できるか」「どこから個別対応が必要か」を整理していく、
という感覚に近いです。
2. 仕様書はそのまま「契約の根拠」になる
-
Web 系の世界でありがちな
- 「とりあえず動くものを作って、あとで細かいところは調整しましょう」
-
行政の場合、これは通りにくいです。
理由はシンプルで、
-
仕様書や提案書が、そのまま契約の根拠になる からです。
- 仕様書に書いてあることをやらない → 契約不履行のリスク
- 仕様書に書いていない追加要件をやる → 追加費用交渉や契約変更の対象
もちろん、実際のプロジェクトでは
-
要件確定後に「仕様変更」「改善」も発生しますが、
- その度に「契約変更」「見積り変更」が必要だったり、
- 議会・監査の目線も意識する必要があったりします。
要は、「仕様書・契約書に落とす前のふんわりした合意」は
民間よりはるかに許容されにくい、くらいのイメージです。
3. 既存自治体の仕様書は「宝の山」だが、鵜呑みは危険
-
すでに導入実績があって、うまく回っている自治体がある場合、
- そのときの仕様書・提案書・成果物を参考にするのは、とても合理的です。
-
ただし、
- その仕様書には その自治体固有の業務・組織・条例 前提の要件が混ざっていることが多く、
- 別の自治体でそのまま使うとズレが出がちです。
「似ている部分は積極的に流用しつつ、
違いがある部分はちゃんと要件整理してカスタマイズする」
という、エンタープライズ案件っぽいアプローチが必要になります。
民間のエンタープライズ案件と近いところも多いですが、
- 行政の場合は 法令・条例・監査・議会 といった制約が一段階多いので、
*「後で運用で吸収しよう」「そのうち仕様を変えよう」が極めて通りにくいという前提を持っておかないと、リカバリー不能なプロジェクト炎上を招きます。- 場合によっては、仕様変更＝契約変更＝議会承認や補正予算が必要になるケースもあります。
4. 入札情報はかなりオープン
-
各自治体の HP や、入札情報サービス（NJSS など）で、
- 公告
- 仕様書（一部非公開の場合もあり）
- 質疑応答
- 結果（誰がいくらで落札したか）
などが公開されていることが多いです。
-
「どんな案件が出ているのか」を眺めるだけでも、
- 行政インフラの世界観
- どの分野にどれくらいお金が使われているか
がなんとなく掴めてきます。
2. 調達仕様書のどこに「SRE が読むべきこと」が書いてあるのか
調達仕様書の構成はバラバラですが、だいたいこんな要素はよく出てきます。
- システムの目的・背景
- 業務ごとの機能要件
- 非機能要件（環境・性能・可用性・セキュリティ・保守運用など）
- ネットワーク要件（LGWAN 接続・三層分離・端末配置など）
- 運用・監視・保守体制に関する要求
- 納期・体制・ドキュメント類
SRE / インフラエンジニア的には、特にこのあたりを「SLO っぽいもの」として読んでいきます。
-
環境
- 「本番環境、研修環境、検証環境を用意すること」
- 「研修環境は、本番と同等の環境を用意して、新人研修などでいつでも使えるようにしておくこと」 など
-
可用性
- 「業務時間内の停止は原則認めないこと」
- 「月次での停止許容時間は◯時間以内とする」 など
-
性能
- 「ピーク時同時接続◯ユーザでも◯秒以内に応答すること」
- 「日次バッチは業務開始までに完了すること」 など
-
セキュリティ / 監査
- 「操作ログを◯年保管すること」
- 「利用者の操作履歴を追跡できること」 など
-
運用
- 「24 時間 365 日の監視体制を敷くこと」
- 「重大障害発生時は◯分以内に一次報告を行うこと」 など
これは、実質的に “日本語で記述された SLO（および必達の SLA）” そのものです。
Web の世界だと、SRE チームが自分たちで SLO を定義して、プロダクトと相談しながら決めていくことが多いと思います。
行政インフラの場合は、
「先に SLO らしきものが仕様書側に書いてあって、それを達成するアーキテクチャを考える」
という、Web サービスとは逆順の世界になっている、くらいの感覚で読むと理解しやすいです。
SRE 目線では、「SLO 設計に参加する」というより「既に決まっている SLO をどう守るか」に比重が寄りがちな構造と言えます。
3. そもそもオンプレ？クラウド？
インフラエンジニア・SREとしてまず気になるのは、「行政システムはオンプレミスなのか、クラウドなのか」という点ではないでしょうか。
結論から言うと、かつてはオンプレミスが主流でしたが、現在は国の方針もあり「クラウド前提」へと急速にシフトしている過渡期にあります。
現状を見渡すと、チャットツールやグループウェアなど、比較的新しい業務ツールは導入時点からSaaSやクラウドを活用しているケースが増えています（LGTalk、LoGoチャット、Garoon、kintone など）。
一方で、長期間運用されている基幹システム系は、依然としてSIerが構築・運用するオンプレミス環境や、データセンター内のハウジング環境が残っていることが多いのが実情です。
これまでの自治体や政府の情報システムは、基本的にオンプレミスが前提でした。
- 庁舎内やデータセンターのサーバールームに物理サーバーを設置する
- 5〜7 年サイクルでハードウェア更新・OS 更新・基幹システムの更改を行う
- クラウドは「一部の周辺系システムで検討されるもの」程度の位置づけ
しかし、ここ数年でこの常識が大きく覆されました。
背景にあるのが、政府が打ち出している 「クラウド・バイ・デフォルト原則（クラウド第一原則）」 です。これは政府情報システムの方式を検討する際、クラウドサービスの採用を第一候補（デフォルト）とする方針です。
この方針により、従来の「自前で作る（Make）」文化から、「あるものを使う（Buy/Use）」文化への転換が求められています。
参考: 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル社会推進標準ガイドライン DS-310）
「ガバメントクラウド」と「パブリッククラウド」の違い
ここで、SREとして混同しやすい用語を整理しておきます。
-
クラウド・バイ・デフォルト（方針）
- 「システムを作るなら、まずはクラウド（SaaSやIaaS）の利用を検討しなさい」という国全体の方針です。
- この方針に基づき、一般的なWebサービスや周辺システムでは、AWSやAzureなどの民間のパブリッククラウド契約や、SaaS利用が進んでいます。
-
ガバメントクラウド（調達枠組み・環境）
- デジタル庁がセキュリティや要件を審査し、政府・自治体が共通して利用できるように調達・契約した特定のクラウドサービス利用枠組みのことです（AWS, Azure, Google Cloud, Oracle Cloudなどが選定されています）。
- 特に後述する「標準化対象20業務」などの基幹業務は、原則としてこのガバメントクラウド上に構築することが求められています。
つまり、「クラウド化」と言っても、「単にAWSを使う（パブリッククラウド）」場合と、「デジタル庁が用意した枠組み上のAWSを使う（ガバメントクラウド）」場合があり、これらは調達プロセスやネットワーク要件が異なります。
2025年度末の「標準化」期限
特に現在（2025年12月時点）、自治体の現場が最も逼迫しているのが、**「自治体情報システムの標準化・共通化」**への対応です。
これは、住民記録や税務などの主要な20業務（標準化対象20業務）について、2025年度末（2026年3月末）までに、国の定めた標準仕様に準拠したシステムへ移行し、かつその基盤として「ガバメントクラウド」を利用するという特大プロジェクトです。
まさに今、各自治体の担当者やベンダーは、この移行対応の佳境を迎えています。
標準化対象20業務の一覧
総務省「自治体情報システム標準化・共通化」で指定されている主な業務は以下の通りです。
（※これらは原則としてガバメントクラウドへの移行対象となります）
| 領域 | 業務名 | 業務概要 |
|---|---|---|
| 住民基本台帳関連 | 1. 住民基本台帳 2. 印鑑登録 3. 選挙人名簿管理 4. 戸籍 5. 戸籍の附票 |
全ての行政サービスの基礎となるデータ管理。転出入のワンストップ化等に必須。 |
| 税務関連 | 6. 固定資産税 7. 個人住民税 8. 法人住民税 9. 軽自動車税 |
税の賦課徴収管理。複雑な計算ロジックの統一化が狙い。 |
| 社会保障（年金・医療） | 10. 国民年金 11. 国民健康保険 12. 後期高齢者医療 13. 介護保険 |
マイナンバーカードの保険証利用（マイナ保険証）の基盤や、資格管理・給付。 |
| 社会保障（福祉・子育て） | 14. 障害者福祉 15. 生活保護 16. 児童手当 17. 児童扶養手当 18. 子ども・子育て支援 |
手当支給や給付管理。迅速な給付実現のためのデータ連携基盤。 |
| その他 | 19. 健康管理 20. 就学 |
検診データ管理や学齢簿管理など。 |
それでも残るオンプレミス
「クラウド・バイ・デフォルト」や「ガバメントクラウド移行」が進む一方で、すべてのシステムがクラウドになるわけではありません。仕様書に「オンプレミス前提」と明記されれば、それに従う必要があります。
具体的には以下のようなケースで、オンプレミスが継続して採用される場合があります。
- 極めて機微な情報を扱う場合: 特定秘密など、クラウドへのデータ保管が法令やポリシー上許容されない領域。
- 物理的な制約がある場合: 庁舎内の物理的なデバイス制御や、超低レイテンシが要求される現場装置に近いシステムなど。
- コスト対効果が合わない場合: 小規模かつ変更が少ないシステムで、クラウドのリフト＆シフトを行うとかえってコスト増になる場合。
とはいえ、世の中の流れはゼロトラストセキュリティやクラウドネイティブへと進んでいます。
自治体システムも、今回の「標準化」を大きなマイルストーンとして、2030 年頃に向けて段階的にクラウドへの移行が進んでいくと考えられます。
4. 三層分離と α / α' / β / β' モデルの変遷
突然ですが、仕様書を読んでいると
- 「三層分離」
- 「αモデル」「α'モデル」「βモデル」「β'モデル」
みたいな単語がちらほら出てきます。
三層分離 = 超ざっくり言うと「トラストゾーンを 3 つに分ける」
三層分離の説明に入る前に、まず LGWAN について簡単に触れておきます。
LGWANとは、総合行政ネットワーク（略称：LGWAN → Local Government Wide Area Network）のこと。
LGWANは、地方公共団体の組織内ネットワーク（庁内LAN）を相互に接続し、地方公共団体相互のコミュニケーションの円滑化や情報の共有による情報の高度利用を図ることを目的とした、高度なセキュリティを維持した行政専用の閉域ネットワーク（インターネット網に接続されていないネットワーク）のことをいいます。つまり、行政向けの WAN です。
https://www.j-lis.go.jp/file/lgwangaiyou_20201209.pdf
さて話を戻して、三層分離は、Web3層構造の「プレゼンテーション層」「アプリケーション層」「データ層」のことか？と連想してしまうかもしれませんが、全くの別物です。
マイナンバー制度導入直前となる2015年6月、日本年金機構が管理していた125万件もの個人情報が漏洩する事件をきっかけに、2016年に総務省の自治体セキュリティ強靭化ガイドラインで発表された「自治体情報システム強靭性向上モデル」におけるネットワーク分離モデルのことで 「マイナンバー利用事務系」「LGWAN接続系」「インターネット接続系」 の3層にネットワークを分離しましょう、という考え方です。
（逆にいうと、三層分離が導入される以前は、インターネット接続と基幹系システムが近いネットワーク構成になっていた自治体も多かった、ということでもあります。）
| レイヤー名 | 通称・役割 | ネットワーク特性 | エンジニアリング上の制約 |
|---|---|---|---|
| ① マイナンバー利用事務系 | 個人番号系住民基本台帳、税、社会保障など、マイナンバーを含む特定個人情報を扱う最重要領域。 | 完全閉域（エアギャップ）。原則として他ネットワークとの接続禁止。端末からの外部媒体持ち出しも厳禁。 | ・外部からのリモートアクセス不可。 ・データの持ち込みは、ウイルススキャン済みの専用媒体または一方向通信装置（データダイオード）のみ。 ・SREによるリモート監視は極めて困難。 |
| ② LGWAN接続系 | LGWAN系人事給与、財務会計、文書管理など、行政運営に必要な内部情報を扱う領域。 | 広域イントラネット。全国の自治体を専用線で結ぶ閉域VPN網。インターネットへの直接接続は行わない構成とするのが基本です。 | ・GitHub, Docker Hub等のパブリックリポジトリへのアクセス不可。 ・NTP、DNSは内部サーバを利用。 ・メールやWeb閲覧は「無害化」または「画面転送」を経由する必要がある。 |
| ③ インターネット接続系 | インターネット系Web閲覧、外部メール送受信、ホームページ公開など。 | インターネットアクセス可能。ただし、自治体情報セキュリティクラウドを経由した厳格なフィルタリングが適用される。 | ・一般的なWeb開発環境に最も近い。 ・ただし、ここからLGWAN系への通信（インバウンド）は原則遮断される。 |
基本的に、どの自治体の職員の方々もこの3層のどこかで業務をしています。その前提で「どの業務をどの層（どの接続系）でどの端末を使ってやるのか」に従って、自治体毎にいくつかのパターン（モデル）に分かれています。最初は、αモデルのみが定義されて（当時はαモデルという言葉はなく、三層分離そのものが定義された）その後、職員の利便性・生産性の向上やクラウド利用を目的としてガイドラインが改定され、いくつかのモデルが定義されていきました。
| モデル名 | 概要 |
|---|---|
| αモデル |
業務端末と業務システムをLGWAN接続系に配置し、インターネットと完全分離する従来型モデル。 |
| βモデル |
業務端末をインターネット接続系に移し、業務システムはLGWAN接続系に残すモデル。 |
| β'モデル |
業務端末と業務システムをインターネット接続系に移行し、フルクラウド化を実現するモデル。 |
| α'モデル |
業務端末と業務システムをLGWAN接続系に配置（αモデル基本）しつつ、特定の安全なクラウドサービスへの接続を許可するモデル。 |
αモデル：一番堅くて、今も広く使われている基本形
最初に定義された三層分離のモデルです。
- 職員の業務 PC は LGWAN 接続系にぶら下がる
- インターネットを見るときは、別端末やシンクライアントなどを経由する
- 各ネットワークは基本的に直接はつながない（USB 経由転送＋無害化など）
セキュリティ的には分かりやすくて堅い一方で
- 職員はインターネット系端末とLGWAN系端末の「2台持ち」を強いられ、
- データのやり取りにはUSBメモリを用いた「運び屋」業務が発生
など「利便性の欠如」と「効率性の低下」しました。
β / β' モデル：業務端末をインターネット側に出す「新三層分離」
そこで出てきたのが β / β' モデルです。
βモデル（既存システム温存型）
業務端末を「インターネット接続系」に配置し、利便性を高めたモデルです。しかし、重要な業務システム（財務会計や人事給与など）は、セキュリティの高い「LGWAN接続系」に残したままにします。
-
仕組み:
- 職員はインターネット側のPCを使用します。
- 業務システムを使うときは、**「画面転送（VDIなど）」**の技術を使って、LGWAN側にあるシステムを遠隔操作します。
-
メリット:
- 既存のシステム（オンプレミス）をそのまま使い続けられるため、システム改修コストを抑えられる場合があります。
-
デメリット:
- 画面転送のライセンス料やサーバー構築コストがかかる場合があります。
- 結局、業務のたびにVDI接続が必要なため、操作性が少し落ちる可能性があります。
β’モデル（クラウドシフト・ゼロトラスト型）
βモデルをさらに進化させ、業務システムそのものも「インターネット接続系（またはパブリッククラウド）」へ移動させたモデルです。LGWAN接続系には、LGWANでしか使えないごく一部のシステムのみが残ります。
-
仕組み:
- 職員はインターネット側のPCから、インターネット上（クラウド）にある業務システムへ直接アクセスします。
-
メリット:
- VDIなどの構成が不要になり、動作が軽快になります。
- 自宅や出張先からのテレワークや、SaaS利用が最もスムーズに行えます。
-
デメリット:
- 重要な情報資産がインターネット側に置かれるため、**極めて高度なセキュリティ対策（EDR、MDM、CASB、ゼロトラストアーキテクチャ等）**が求められます。
- 既存システムをクラウド対応（Web化）させるための改修・移行コストが非常に大きくなる傾向があります。
α'モデル：α の構造を残したまま、クラウドも使いたいという折衷案
β、β'モデルをやろう！とするも主に
- 導入・維持コストの増加
- 運用負荷増加
- セキュリティ脅威の増加
などの理由により、うまくα -> β,β' への移行が進まなかったため、その折衷案として、α'モデルというものが提唱され、これは最近出てきた「αモデルを完全には崩さずに、クラウドも使いたい」という考え方です。
2024年10月の地方公共団体における情報セキュリティポリシーに関するガイドライン(令和６年 10 月版)の中で規定されたモデルです。
- 業務端末は LGWAN 接続系側に残したまま、
- 特定のクラウドサービスに対してだけローカルブレイクアウト（直接インターネット接続）する
という構成が例としてよく出てきます。
つまり、**「三層分離の構成は維持しつつ、特定の通信のみをローカルブレイクアウトさせる」**という構成です。エンドポイントセキュリティ（EDR等）やアクセス制御を組み合わせることで、セキュリティレベルを担保するアプローチです。
結局どのモデル使ってるの？
直近の自治体毎にどのモデルを活用しているのかが以下の通りです。
出典: 総務省：地方公共団体情報セキュリティポリシーに関するガイドラインの改定方針（「三層の対策」の状況（自治体分類別））（2023年４月１日時点）
見ての通り、都道府県や政令指定都市レベルでは、半分近くまでβ'モデルへの移行が完了しているが、それ以外の自治体ではほとんどが未だにαモデルを採用している状況です。
なぜなら、先ほどα'モデルのところにも書いた通り、ヒト・モノ・カネがかかるためです。
地方公共団体向けβ'モデル移行に向けた手順書の中で、実際にβ'モデルへ移行した自治体の事例が紹介されていますが、その中でも市町村規模（職員数約700人）の団体Bのケースでは、移行費用だけで約2億5千万円、運用経費（5年総額）で約28億円という規模の投資が必要だったとされています。また、プロジェクトには自治体職員約7人に加えて、外部委託を含めて約50人が携わり、検討期間を含めて約2年間の期間を要したとのことです。さらに、移行後も「セキュリティ脅威の増加」「導入維持コストの増加（セキュリティ対策費用等）」「不具合発生時の責任分界点の分析・判断の難しさ」といった新たな課題が生じていることも報告されています。このように、β'モデルへの移行は単なる技術的な変更ではなく、組織全体の体制整備や継続的な運用コストの確保が求められる、まさに「ヒト・モノ・カネ」が総合的に必要となる大規模なプロジェクトなのです。
つまり「大規模自治体であれば投資対効果が見合うが、中小規模の自治体ではコスト負担が重すぎて現実的ではない」というのが、多くの現場が抱える実情です。
それがきっかけとなって、2024 年 10 月に α' モデルが総務省のガイドラインに明記され、2025 年頃から「α' モデル元年」といった言い方をする人も出てきています。
で、今後どうなっていきそうかでいうと、いろんなサービス・業務をクラウド化していくというのはもう自治体においても止められないので
- 最終的に国としては、β'モデルが三層分離のデフォルトのモデルにしていきたい！
- とはいえ、コストかけずに実現する α'モデルも折衷案として規定しておく
- 結果的に今の α モデルはなくなっていき、ある程度の規模がある自治体は、β'モデル。それ以外の自治体は、α'モデル。
みたいに、2030 年頃までを目安に少しずつ切り替わっていくのではないか、というのが現時点での肌感です。
おわりに：前編を振り返って
この前編では、行政インフラの世界を理解するための「基礎知識」として、以下の3つのテーマを扱いました。
- 案件の生まれ方：入札・調達仕様書という起点
- 調達仕様書とは何で、どういうところを読むのか
- 三層分離と α / α' / β / β' モデルとは何か
ここまでで、行政インフラの世界の「前提条件」と「制約」が見えてきたと思います。
（ここまで、AWS など具体的なパブリッククラウドの話はほとんどしていません。
後編では、これらの前提を踏まえたうえで、
- ガバメントクラウド / 公共 SaaS とは何者か
- 「自前？ガバメントクラウド？どこに構築するか」の決定木 を事業者目線で考える
- パブリッククラウド／ガバメントクラウドでインフラを構築する際に気をつけているポイント
といった、より実践的な内容に踏み込んでいきます。
後編では、これらのあまり語られない分野に対して SRE がどう向き合っているのか、という話も書いていきますので、ぜひ続きも読んでいただければと思います。
あとがき: NotebookLM にスライド作ってもらった
NotebookLM にこの記事のリンクをソースに追加して、スライド作ってもらった。
内容は精査していないので、間違っている部分もあるかもしれませんが、大筋は参考になるかなと思うので、こちらもよかったら参考にしてみてください。
Discussion