🎄 WiseVine Advent Calendar 2025 – Day 16！ 🎄
この記事は、WiseVine Advent Calendar 2025の記事です。
はじめに
こんにちは。WiseVine で SRE をしている jkkitakita です。
Web系SREの知らないGovTech・行政インフラの世界（前編）では、Web 系 SRE / インフラエンジニアが行政システムの世界に入る際に押さえておきたい「前提条件」と「制約」について解説しました。
- 入札・調達仕様書：案件の生まれ方と、仕様書が契約の根拠になる構造
- 調達仕様書の読み方：SRE 目線で見るべき非機能要件（可用性・性能・セキュリティ・運用）
- オンプレ vs クラウド：クラウド第一原則と、2025年度末の標準化期限
- 三層分離と α / α' / β / β' モデル：LGWAN を中心としたネットワーク分離の考え方
中編となる本記事では、これらの前提を踏まえたうえで、ガバメントクラウド、及び、その周辺のキーワードについて筆者の解釈も含みながら解説していきたいと思います。
- ガバメントクラウドとは何か、なぜ生まれたのか
- 公共 SaaS・共通 SaaS とは何か、その違い
- 事業者としてどこでシステムを構築するかの判断軸
1. ガバメントクラウド とは
まず「ガバメントクラウド」を一言でいうと、 デジタル庁が政府方針（重点計画等）に基づいて選定した、公共情報システム向けの“安全かつ合理的な利用環境としての複数クラウド（IaaS/PaaS/SaaS）” です。
単に「AWS使えます」みたいな話ではなく、公共情報システムを“効果的かつ効率的に整備・運用するための利用環境”として提供される枠組み、という立て付けになっています。
ポイントとしては、以下の通りです。
- **“デジタル庁が選定した複数のパブリッククラウド”**である（= 何でも好きなCSPを使う話ではない）
- 対象は IaaS だけでなく PaaS / SaaS まで含む（=「行政システム向けに、必要な層をまとめて使える前提の環境」）
- 法律上の位置づけとしても「国と（公共情報システム整備運用者が）共同して利用できるクラウドサービス」という整理がされている
背景：クラウド移行が目的化した反省から
クラウド第一原則（クラウド・バイ・デフォルト原則）は、2018年6月に初版決定された「政府情報システムにおけるクラウドサービスの利用に係る基本方針」で示されました。しかし、ただオンプレミスをクラウドに移行するだけ（クラウドリフト）で、クラウドのメリットを十分に享受できていないケースが散見されたため、これが主な理由のようです。
ここでいうクラウドのメリットとしては、概ね一般的なオンプレミスをクラウドに移行したことによるメリットのことです。
- コスト削減
- セキュリティ・ガバナンス強化
- 業務効率化と迅速なシステム構築
- データ連携・標準化の促進
などなど。
一方で、最近では、結局現在進めている標準20業務のガバクラ移行において「コスト削減」するどころか「コスト増加」してることを指摘されており、そのための色々な対策をデジタル庁主導で、デジタル行財政改革会議など検討されております。
この後で紹介しますが、「公共SaaS」が、主に「コスト削減」のメリットを最大限享受するための打ち手として現在進行形で検討されています。
ガバメントクラウド で使える IaaS
2025年度（令和7年度）時点で、ガバメントクラウドとして利用可能なクラウドサービスは以下の5つです。
| CSP（クラウドサービスプロバイダ） | サービス名 | 採択年度 |
|---|---|---|
| Amazon Web Services, Inc. | Amazon Web Services（AWS） | 2021年度~ |
| グーグル・クラウド・ジャパン合同会社 | Google Cloud | 2021年度~ |
| Microsoft Corporation | Microsoft Azure | 2022年度~ |
| 日本オラクル株式会社 | Oracle Cloud Infrastructure（OCI） | 2022年度~ |
| さくらインターネット株式会社（※） | さくらのクラウド | 2023年度~ |
（※）さくらインターネット株式会社の「さくらのクラウド」は、令和7年度末（2026年3月末）までにガバメントクラウドとしての技術要件を満たせば、利用環境として追加される見込みです。国産クラウドとして初めての選定となる可能性があり、注目されています。
これらのサービスは、**ISMAP（政府情報システムのためのセキュリティ評価制度）**に登録済みであることが前提条件となっており、一定の技術要件とセキュリティ基準を満たしたクラウドサービスのみが選定されています。
ISMAP（政府情報システムのためのセキュリティ評価制度）とは
ISMAP（Information system Security Management and Assessment Program）は、政府が求めるセキュリティ要求を満たすクラウドサービスを評価・登録する制度です。
政府向けシステム、及び、その事業者に求める ISMS のようなものです。実際、ISO/IEC 27001/27002/27017、NIST SP 800-53 等の国際規格を参照して策定されています。
国としては ISMAP 推進したい一方で、2022年4月1日 株式会社グラファーのISMAPクラウドサービスリストの登録取下げあたりをきっかけに、「本当に ISMAP は必要があるのか？意味があるのか？」といった懐疑的な意見もできているというのが実態です。
ISMAP制度は、「監査項目が多い」「取得・更新費用が高額」「作業負担や人件費コストが大きい」など、取得だけでなく維持も高いハードルがある点が主な課題とされています（参考資料）。
感覚としては、ざっくり2年くらいかけて、初期合計5,000万~1億円、維持費も毎年数千万円以上、それに人件費もとなると「そこまでするメリットがあるのか」「そこまでキャッシュが潤沢ではないスタートアップはそもそも難しい」と懐疑的になる企業が出てくるのも仕方ないことかなと個人的には思います。
参考: ISMAP公式サイト
とはいえ実態としては、ほとんど全部 AWS と思ってもらってもいいような状況になっています。これの私が感じている理由としては
- AWS がクラウドの先駆者で一番枯れていること
- 他自治体での実績が十分であること
- Google Cloud や Azure は、玄人向けな印象（筆者の感想）
地方自治体における意思決定において「同規模の他自治体において、実績があるかどうか」というところが重要で「1. AWS がクラウドの先駆者で一番枯れていること」「2. 他自治体での実績が十分であること」というポイントが、IaaS だけに限った話ではなく重要になることが多い印象です。そもそも、Google Cloud や Azure を選ぶ明確な理由もないので、必然と言えば必然だなと感じています。
一方で、Oracle、OCIが、この業界においては、Google CloudやAzureよりもシェアを獲得しているのは特徴的で、面白いなと思いました。多分、Oracle のオンプレミスを使っていたSI等の事業者の方々がそのまま OCI を使っているのかなーという印象です。
参照元: Youtube - 地方公共団体情報システム機構 - 06_ガバメントクラウドと自治体DX 2025
インフラ・ネットワーク構成図
Web 系エンジニアの方が気になるであろう「ガバメントクラウド上の AWS アーキテクチャは、民間SaaSと何が違うのか？」という点についてお伝えします。
結論から言うと、AWS 上のアーキテクチャ自体は、民間で設計するのとさほど違いはありません。
EC2、ECS、Lambda、RDS、S3、CloudFront… といった AWS サービスの組み合わせ方や、Well-Architected Framework に沿った設計の考え方は、民間の Web サービスと基本的に同じです。「ガバメントクラウドだから、このサービスが使えない！」といったことは基本的にないと思ってもらって、個人的には問題ないかなと思っています。
- 原則、国内リージョンのみしか選べない（これは納得
- CloudFront も Global だけど使える。それに関連する WAF、ACM、Lambda@Edge なども us-east-1 だけど使える。
- EC2は非推奨。基本的にECS、Lambdaなどのマネージドなコンテナ・サーバーレスサービスを使うようにする
など、割と気にせず使えます。
デジタル庁が調査した結果、2024年6月26日時点での国、及び、地方公共団体のAWS サービスの利用状況は以下のような状況となっています。
参照元: Youtube - 地方公共団体情報システム機構 - 06_ガバメントクラウドと自治体DX 2025
余談ですが、私の認識では、ちょっと前までは、EC2禁止みたいな話くらいの話だったような気がするのですが、、、恐らく、標準20業務のガバクラ移行する過程で、クラウドリフトしないといけないオンプレが多かったため、緩和されたのかもしれません。
また、行政システムでは非機能要件、特に可用性、機密性、完全性、RPO、RTOなどの障害対策が非常に重要です。そのため、東京リージョン（ap-northeast-1）だけでなく、大阪リージョン（ap-northeast-3）でもサービスが継続して提供できるかどうかが重要な観点となります。
基本的には、AWS Backup 等を使って適切にリージョン間でデータ保持をしていくなどの設計をすれば、ほとんどのマネージドサービスは、大阪リージョン（ap-northeast-3）でも対応しているので、特に気になることもありません。
東京リージョンにあって、大阪リージョンにない AWS サービス
AWS Services by Region で、比較してみたところ以下のような AWS サービスが東京リージョンにあって、大阪リージョンにありませんでした。
個人的にぱっと見感じたのは
- 全体的には、あまり利用されていない、または、運用のためのサービスは対応していない
- 上記以外の AWS サービスでも、基本的にステートレスなAWSサービスがほとんど。
- 比較的新しいサービスなので、今後対応予定かな？
- AWS App Runner
- Amazon Bedrock AgentCore
- 下記サービスは、対応してないのは、少し気になる。結構、IoT系のサービスだと使うことも多いかなという印象のため。
- AWS IoT Core
- AWS IoT Greengrass
- リファレンスアーキテクチャ（第5章 AWS） の「5-1-4-7. データ管理_IoT連携機能」とかで、AWS IoT Core/Greengrass を紹介されているけど、これは東京リージョンが停止したら、多分提供できなくなるor海外リージョンを使う必要がある。と思われる。
AWS App Runner
AWS Audit Manager
AWS CodeArtifact
AWS Deadline Cloud
AWS Fault Injection Service
AWS IoT Core
AWS IoT Greengrass
AWS IoT SiteWise
AWS Resilience Hub
AWS Signer
AWS Verified Access
AWS Wickr
Amazon AppFlow
Amazon Bedrock AgentCore
Amazon Comprehend
Amazon DataZone
Amazon Detective
Amazon DynamoDB Accelerator
Amazon Elastic VMware Service (EVS)
Amazon Interactive Video Service (IVS)
Amazon Kendra
Amazon Keyspaces (for Apache Cassandra)
Amazon Kinesis Video Streams
Amazon Lex
Amazon Lightsail
Amazon Location Service
Amazon Managed Blockchain (AMB)
Amazon Managed Grafana
Amazon MemoryDB
Amazon Personalize
Amazon Quick Suite
Amazon Rekognition
Amazon SageMaker Ground Truth
Amazon Transcribe
Amazon Translate
Amazon WorkSpaces
Amazon WorkSpaces Applications
違いがあるとすると、ネットワーク周りです。
前編の「4. 三層分離と α / α' / β / β' モデルの変遷」で解説した通り、利用者（自治体職員など）の環境、及び、対象業務がどの層の業務なのかによって、AWS 環境へのネットワーク経路が異なります。
例えば、現在ガバクラ移行を行なっている標準20業務は、基本的に「マイナンバー利用事務系」の業務がほとんどなので、どのモデルであっても閉域環境で分離されている業務なので、庁内ネットワークとAWS VPC を繋ぐ必要があり、ネットワーク管理用のAWS アカウントを用意して、AWS Transit GatewayやDirect Connectとかを使ってネットワーク設計・構築をしています。
α'モデルは LBO（ローカルブレイクアウト）によりインターネット経由でアクセスするため、経路としては β/β' モデルに近い形になります。ただし、LBO 側の設定で通信先をホワイトリスト形式で制限していることが多いとい見解もあったりするようです。
このように、「誰が」「どこから」アクセスするか によって、VPC 設計やセキュリティグループ、WAF の設定、認証・認可の仕組みが変わってきます。民間の Web サービスでは「インターネットからのアクセス」を前提に設計することが多いですが、行政システムでは 閉域網からのアクセスを前提としたネットワーク・インフラ設計 が求められるケースが多い点が大きな違いです。
ちなみに余談ですが、ネットワーク・インフラを意識して、アプリケーションを開発しない場面もしばしばあります。例えば、フロントエンドが SPA の場合、外部 CDN から CSS や Web フォントを取得できない等の制約が発生する可能性があります。
そのため、設計時には、利用する外部リソースの洗い出しと、LBO のホワイトリスト設定への追加可否を確認しておくことが重要です。場合によって、プロキシサーバーを立てる等の対応が必要にあることもあります。社内で、ゼロトラストを推進していたり、CASB導入していたりする場合と同じような課題ではあります。
2. 公共 SaaS とは
「公共 SaaS」は、2025年4月1日 に、デジタル庁からガバメントクラウドにおけるSaaS（公共SaaS）についてで、初めて定義が公開された比較的新しい概念です。
定義
公共 SaaS とは、以下のように定義されています。
ガバメントクラウドを利用環境として、重点計画に記載の「公共・準公共分野」に該当し、制度官庁が標準仕様を定める情報システムを SaaS として構築したもの。
つまり、単に「クラウド上で動く行政向け SaaS」というだけでなく、国が定めた標準仕様に準拠した SaaS であることがポイントです。
背景: デジタル行財政改革会議
公共 SaaS の概念は、デジタル行財政改革会議で議論されてきた「国・地方デジタル共通基盤の整備・運用に関する基本方針」の中核である「共通 SaaS」を、ガバメントクラウド上で具体化するものです。
この基本方針では、共通 SaaS の費用負担や推進の型も整理されています。
| 推進パターン | 費用負担 | 概要 |
|---|---|---|
| パターン A 相当（国営） | 国が費用負担 | 国が主導して共通化を推進 |
| パターン B 相当（民営） | 地方負担（国が初期支援） | 民間事業者が開発、地方自治体が利用料を負担 |
冒頭の「1. ガバメントクラウドとは」で触れた「コスト削減」のメリットを最大限享受するための打ち手として、公共 SaaS の普及が期待されています。各自治体が個別にシステムを構築・運用するのではなく、標準仕様に基づいた SaaS を共同利用することで、開発・運用コストの削減を目指しています。
個人的には、 パターン A 相当（国営）は、後述の共通SaaSの場合と違いがなくなってきそうな印象なので、パターン整理する上で概念として定義しているだけで、実質、 パターン B 相当（民営）のみ なのだろうと思っています。
共同利用方式との違い: クラウド利用料の負担構造
公共 SaaS のコスト削減効果を理解するうえで重要なのが、従来の「共同利用方式」との違いです。
単独利用方式と共同利用方式
従来のガバメントクラウドの利用形態には、大きく「単独利用方式」と「共同利用方式」の 2 つがあります。
| 方式 | 概要 | メリット | デメリット | 向いているケース |
|---|---|---|---|---|
| 単独利用方式 | 各自治体が自分のガバメントクラウド個別領域（テナント等）を自ら運用管理 | 個別要件を反映しやすい、リリース計画を自団体都合で組める | 運用体制を自前で用意する負担、スケールメリットが効きにくい | 政令市など大規模団体、内製・運用ガバナンスを自団体で強く持ちたい場合 |
| 共同利用方式 | 複数の自治体が同一の運用管理補助者（運用受託者）に運用を委ね、標準化・共通化した運用でまとめて回す | 運用の省力化、共同調達でスケールメリット、標準仕様への追従がしやすい | リリース時期・設定方針の調整が必要、個別要望の反映に制約 | 中小規模団体、運用人員が限られる場合、都道府県主導の共同調達を活用したい場合 |
どちらの方式でも、団体ごとの環境・データはクラウド上で論理的に分離されます（許可しない限り他環境と接続されない）。
現在、標準化対象20業務のガバメントクラウド移行では、国が「共同利用方式」の普及を推進しており、共同調達・共同運用のスキームが整備されつつあります。
自治体がガバメントクラウド上のシステムを利用する際には、大きく 「クラウド利用料」 と 「サービス利用料」 の 2 種類のコストが発生します。
- クラウド利用料: AWS や Azure などの CSP に支払うインフラ利用料（コンピュート、ストレージ、ネットワーク等）
- サービス利用料: ASP / SaaS 事業者に支払うアプリケーション利用料（開発・保守・運用費用を含む）
これらの費用負担構造が、方式によって大きく異なります。
共同利用方式の契約・支払スキーム
ASP とガバメントクラウド運用管理補助者が同一の者となる場合。ASPとガバメントクラウド運用管理補助者が別々のスキームがよく見かけるが、自治体の実態としては、、そこを分けるメリットはほぼないらしい。
| 費用項目 | 支払の流れ |
|---|---|
| クラウド利用料 | 自治体 → デジタル庁 → CSP |
| サービス利用料（ASP / アプリケーション利用料） | 自治体 → ASP 事業者 |
共同利用方式では、自治体がクラウド利用料を直接負担します。そのため、FinOps（クラウドコスト最適化）の責任は自治体側にあります。
感覚としては、自治体の方々が AWS Cost Explorer や Calculator をみて「今使ってないし、Fargateのコストもっと下げられるんじゃない？」みたいなことを考えないといけないようなイメージ。FinOpsの責任が自治体にあるっていうのはそういうことだと思っています。下記 Youtube で、デジタル庁が主催している共創PFの取り組みで、実際に自治体職員の方々が AWS コスト最適化のワークショップとかをやっている様子とかも公開されています。
ただやはり、1エンジニアとしては、コスト最適化を根本的に見直そうとすると、アーキテクチャの見直しが必要な場面も多々あるので、自治体側にその役割を持たせるのは、私も構造的な問題があるように感じているので、今回の公共 SaaS の策定に繋がっていったのだろうと感じます。
ただそもそもの元々でいうと、デジタル庁としては、この形をやりたかったはずなのかなと思うのですが、なぜ最初からそれができなかったのか。についての問題はどこにあるのかは今後調べていきたいなと思っています。
公共 SaaS の契約・支払スキーム
次に、公共 SaaS です。公共 SaaS は、パターン A（国が提供）とパターン B（民間事業者が提供）で契約・支払スキームが異なります。
パターン A: 国が提供する場合
| 費用項目 | 支払の流れ |
|---|---|
| クラウド利用料 | 国（デジタル庁 / 主管府省庁） → CSP |
| SaaS 利用料 | 無償が原則（有償の場合は制度官庁等が独自に設定・運用） |
パターン B: 民間事業者が提供する場合
| 費用項目 | 支払の流れ |
|---|---|
| クラウド利用料 | SaaS 事業者 → デジタル庁 → CSP |
| SaaS 利用料 | 自治体 → SaaS 事業者（DMP で契約手続きを容易化） |
FinOps 責任の違い
| 方式 | クラウド利用料の負担者 | FinOps の責任 |
|---|---|---|
| 共同利用方式 | 自治体 | 自治体 |
| 公共 SaaS（パターン A） | 国 | 国 |
| 公共 SaaS（パターン B） | SaaS 事業者 | SaaS 事業者 |
特にパターン B では、SaaS 事業者がクラウド利用料を負担する構造になっています。これにより、FinOps の責任が事業者側に移り、事業者は自社の利益を最大化するために、積極的にコスト最適化に取り組むインセンティブが生まれます。
これでこれまでの先ほど述べた共同利用方式の責任の所在を自治体ではなくなるという課題を解消されました。
ただし、この構造には課題もあります。事業者が「クラウド利用料の変動リスク」を負うため、移行インセンティブが限定的になる可能性があります。この課題に対しては、最初は実績に近い料金設定から始め、事業者が FinOps を進めてコスト効率を改善した段階で、一般的な SaaS 料金形態に移行するといった柔軟なアプローチが提案されています。
一方で、公共 SaaS の制度設計に対しては「後出しジャンケン」ではないかという指摘もあります。
標準20業務で共同利用方式を推奨してきたが、それだと自治体の負担が増加したり、事業者側が値上げをしてきたり、ただクラウドリフトしただけでSaaSではなかったり、色々な課題を解消したい意図がこの公共SaaSに表現されていると私は感じています。
参考:
- ガバメントクラウドにおける SaaS（公共 SaaS）について
- 標準化後の自治体システム運用のあり方を考える - note
- 公共SaaSの詳細がついに発表されたけど事業者としてどう思う？ - note
重点計画に記載の公共・準公共分野とは
ここまでで、公共 SaaS が出てきた背景や意図、主に、コスト削減の側面から解説しましたが、ここからは定義の話に戻ります。
公共 SaaS の定義に出てくる「重点計画に記載の公共・準公共分野」とは、デジタル社会の実現に向けた重点計画で定められた、デジタル化を推進すべき領域のことです。
| 項目 | 公共分野 | 準公共分野 |
|---|---|---|
| 主な運営主体 | 国・地方自治体 | 民間企業・団体（学校法人、医療法人、インフラ企業など） |
| サービスの性質 | 統治、行政事務、安全保障 | 生活に不可欠なサービス（ライフライン） |
| 具体例 | 住民基本台帳、税務システム | 防災・医療・こども・教育 など |
公共分野は、国や地方自治体が直接運営する行政サービスの領域です。住民基本台帳や税務システムなど、いわゆる「標準化対象20業務」がここに含まれます。
準公共分野は、民間企業や団体が運営しつつも、国民生活に不可欠なサービスを提供する領域です。具体的には以下のような分野が挙げられています。
- 健康・医療・介護: 電子カルテ、オンライン診療、介護情報の連携
- 教育: GIGA スクール、学習データの活用
- こども: 母子健康手帳のデジタル化、保育・子育て支援
- 防災: 災害情報の共有、避難所運営支援
- モビリティ: MaaS、交通データの連携
- 農林水産: スマート農業、農業データ連携基盤
これはなんとなく一般の人でもイメージが沸くかなと思います。
制度官庁と標準仕様書
公共 SaaS の定義に出てくる「制度官庁が標準仕様を定める」という部分について解説します。
制度官庁とは
制度官庁（制度所管省庁） とは、その業務（制度）を所管する中央省庁のことです。標準化のために新たに任命されるわけではなく、各業務の根拠法や制度設計を所管している省庁が、そのまま制度官庁となります。
例えば、「住民記録」が総務省所管となっているのは、根拠法である 住民基本台帳法（昭和42年法律第81号）を総務省（自治行政局 住民制度課）が所管しているためです。同法の施行規則も総務省令として制定・改正されており、住民基本台帳ネットワークシステム（住基ネット）の運用主体である J-LIS（地方公共団体情報システム機構）の監督も総務省が担っています。
標準20業務では以下の通りになっています。
| 制度官庁 | 所管する業務 |
|---|---|
| 総務省 | 住民記録、印鑑登録、戸籍附票、選挙人名簿管理、固定資産税、個人住民税、法人住民税、軽自動車税 |
| 法務省 | 戸籍 |
| 文部科学省 | 就学 |
| 厚生労働省 | 国民健康保険、国民年金、後期高齢者医療、介護保険、障害者福祉、生活保護、健康管理 |
| こども家庭庁 | 児童手当、児童扶養手当、子ども・子育て支援 |
標準仕様書とは
2025年12月現在、各制度官庁およびデジタル庁が策定している標準的な仕様は以下の通りです。
参考: 地方公共団体の基幹業務システムの標準化のために検討すべき点について（2022年10月改定）
| 分類 | 項目 | 概要 | 整備主体 | 仕様書名称 |
|---|---|---|---|---|
| 1. 業務フロー | - | 業務の流れを BPMN 形式で可視化 | 各制度官庁 | 〇〇システム標準仕様書 |
| 2. 機能要件 | 2.1 機能要件 | システムが提供すべき機能の一覧・詳細 | 各制度官庁 | 〇〇システム標準仕様書 |
| 2.2 画面要件 | 画面レイアウト、入力項目、遷移の定義 | 各制度官庁 | 〇〇システム標準仕様書 | |
| 2.3 帳票要件 | 出力帳票のレイアウト、項目、形式の定義 | 各制度官庁 | 〇〇システム標準仕様書 | |
| 2.4 データ要件 | データ項目、データ型、コード体系の定義 | デジタル庁 | データ要件・連携要件標準仕様書 | |
| 2.5 連携要件 | 外部システムとの連携方式、API 仕様 | デジタル庁 | データ要件・連携要件標準仕様書 | |
| 3. 非機能要件 | 3.1 規模性 3.2 性能 3.3 信頼性 3.4 移行性 3.5 セキュリティ 3.6 システム環境・エコロジー |
性能、可用性、セキュリティ等の品質要件 | デジタル庁 | 地方公共団体情報システム非機能要件の標準 |
| 4. 共通機能 | - | 認証、データ連携機能など業務横断の共通機能 | デジタル庁 | 共通機能標準仕様書 |
このうち、よく SNS や記事なので、「標準仕様書」と言われる場合は「〇〇システム標準仕様書」のことを指していることが多いのかなと感じます。
また、「4. 共通機能」の部分についてですが、地方公共団体の基幹業務システムの標準化のために検討すべき点について（2022年10月改定） の中では軽く触れていますが、具体化されていない状況でした。その後整備され、共通機能標準仕様書 として策定されています。詳細は実際の資料を参照していただければと思いますが、ここで言う 共通機能とは、標準準拠システムに必要な機能のうち、複数の標準準拠システムに共通する機能のこと。具体的には、「申請手続等を行うマイナポータルと標準準拠システムの間を連携する機能」や「標準準拠システムが、他の標準準拠システムにデータを送信又は他の標準準拠システムからデータを受信することを効率的かつ円滑に行う機能」など、主に認証やデータ連携などの機能は、どの標準準拠システムでもこれらの機能を実装する場合はこの共通機能標準仕様書も満たす必要がある。というものです。
標準仕様書はどうやって作られるのか
まず、大きく2つのステップに分かれます。
- 標準化対象事務として選定する
- 標準仕様書の策定・改訂
1. 標準化対象事務として選定する
結論としては、私の調べた限りでは、今後どういうプロセス、計画で標準化対象事務として選定していく想定なのかはわかりませんでした。
現在、2025年度末までに向けて対応を進めている標準20業務に関しては、標準化法の趣旨を踏まえ、標準化法第２条第１項に規定する「情報システムによる処理の内容が各地方公共団体において共通し、かつ、統一的な基準に適合する情報システムを利用して処理することが住民の利便性の向上及び地方公共団体の行政運営の効率化に寄与する事務」であるかという観点から、恐らく 総務省の
自治体システム等標準化検討会 などから始まり、その後、最終的に、2021年6月18日閣議決定された「デジタル社会の実現に向けた重点計画」において決められたもので、今後の選定プロセスは明確には決まっていない印象を受けました。
恐らくですが、デジタル庁や総務省が旗振りをしながら、標準化対象事務の選定するような検討会なのかを立ち上げていくのではないかなーと勝手に感じております。
2. 標準仕様書の策定・改訂
標準化対象事務として選定したら、標準仕様書は以下の流れで策定されていきそうな気がします。
- 検討会の設置: 制度官庁が、自治体職員・有識者・事業者を交えた検討会を設置
- 意見聴取・審議: 現場の業務フローや課題をヒアリングし、仕様を審議
- 仕様書の策定・公開: 制度官庁が標準仕様書を策定し、Web サイトで公開
とはいえ、対象となるシステムで処理する標準化対象事務が指定された日から起算して、原則として１年間で策定する必要がある。と定められていることも考えると、検討会の設置の部分に関しては、そもそも標準化対象事務の選定する前から始めて、そのまま検討会の中で議論するのか、別途分科会みたいな形で議論を進めるのかは、その場の議論次第なのかなという印象です。
「〇〇の標準化ってどうやって経緯で検討されているのか？」など興味がある標準化対象事務があれば、標準化対象事務の標準仕様策定に係る検討会 に検討会のリンク一覧があるので、見てみてもらえればと思います。
改訂に関しても、この検討会の中で実施される想定とみて良いかなと思っています。2025年1月にデジタル長から発表された「標準仕様書の改定・運用について（基本的な考え方）」で具体的な改訂の流れが示されています。
その中で、標準仕様書の改訂が必要 = 制度改正されるということなので、制度改正の検討段階から標準仕様書の改訂の検討も並行して進めて、遅くとも制度改正の施行日の１年以上前に標準仕様書を改訂して、公開する必要があるとされています。
参照元: 標準仕様書の改定・運用について（基本的な考え方） 2025/１/29 デジタル庁 地方業務システム基盤チーム
3. 共通SaaSと公共SaaSの違い（筆者の解釈）
「ガバメントクラウド」周辺の議論で頻出する 「共通SaaS」 と 「公共SaaS」。最初、同じものを指しているのかと思ったのですが、調べてみると違うものでした。
そもそもでいうと、公共SaaS（2025年4月）は、この共通SaaS（2024年6月）の概念を参考に、生まれた概念のように個人的には解釈しています。
共通SaaSは、デジタル行財政改革会議の「国・地方デジタル共通基盤の整備・運用に向けた検討体制構築準備会合 ワーキングチーム（第１回）」で示された以下の図をベースにみると理解が進むかなと思います。
国・地方デジタル共通基盤の整備・運用に向けた検討体制構築準備会合 ワーキングチーム（第１回） - 資料２
この図から私が感じたポイントは、以下の通りかなと思いました。
-
個別開発→標準化→共通化していきたい。
- 標準化したものもゆくゆくは共通化（同じものをみんなで利用する）していきたい
- 緊急時や国策として重要なシステムに関しては、国が所有した1つのシステムに統合（共通化？）していきたい（共通化A）
-
共通化B のことを 公共 SaaS（パターンB） とほとんど同義だと捉えると理解しやすい。
- 共通化B を「共通化の基本形とすることを想定」とあるので、中長期的には、ここがボリュームゾーンにしていきたいのだろう。
- 一方、共通化A が、公共 SaaS（パターンA）かというとそういうわけではない
- 共通SaaSの共通化Aは、国全体で、1システムなので、機能要件の標準化する必要がないため、標準仕様書は存在しない。別途仕様書策定して進めるだけ。
- 非機能要件、データ要件・連携要件は準拠していくなどの方針になるかなと思いますが。
- そもそも、公共 SaaS（パターンA）は整理する上で概念として存在するだけで、ほとんど使われることは、想定していないのではないかと思う。
- 共通SaaSの共通化Aは、国全体で、1システムなので、機能要件の標準化する必要がないため、標準仕様書は存在しない。別途仕様書策定して進めるだけ。
改めて、個人的には、やはりまだまだ公共SaaSがまだ曖昧だなと感じています。
実は、前述した「標準化対象事務として選定する」のところで、そのプロセスが曖昧という話をしましたが、共通SaaSのための「共通化候補の選定」のプロセスは、すでにある程度決まっていて、すでに進んでいます。具体的には、デジタル行財政改革会議の国・地方デジタル共通基盤推進連絡協議会ワーキングチームの中でざっくりとしたイメージがあって、すでに令和6年度、7年度とそのプロセスが進んでいるようです。
参照元: デジタル行財政改革会議 - 国・地方デジタル共通基盤推進連絡協議会ワーキングチーム - 各種議事
ここで共通化対象となっているのは
- 国民・住民のニーズ（利用者起点）に即しているか
- 効果の見込みがあるか
- 実現可能性があるか
の3点を基準に共通SaaSとするシステムを選定して、決めたら、国が主導で共通システムを構築して導入するような流れになっている。
例えば、令和7年度の共通化の対象候補となる業務・システムとして、以下の11つが挙げられている
| # | 候補名 | 制度所管府省庁 | 選定理由 |
|---|---|---|---|
| 1 | 国・地方AI共通サービス（自治体照会事務の自動化等） | デジタル庁（総務省） | 小規模団体ではデジタル人材不足や投資対効果が見込めないため、全国展開によるセキュリティ配慮のAI利用環境で個別構築よりコスト最小化が狙える |
| 2 | ふるさと住民登録制度プラットフォーム | 総務省 | 関係人口の可視化・地域貢献の新制度。国による共通システムで地方の事務負担も含めてコスト最小化 |
| 3 | 土木施設に関する住民からの通報等システム | 国土交通省 | 住民が管理者を把握しておらず、道路以外の土木施設も含め共通化でコストの最小化が見込める |
| 4 | 畜犬管理システム | 厚生労働省、環境省 | 狂犬病予防法と動物愛護管理法で手続きが二重化。転居時の自治体間連携も負担で、共通化によるコスト最小化が可能 |
| 5 | 職務上請求システム | 法務省、総務省、デジタル庁 | 士業者の戸籍・住民票請求が紙運用で効率悪化。システム化で事務負担軽減・不正防止・コスト最小化 |
| 6 | 自動車臨時運行許可申請システム | 国土交通省（デジタル庁） | 申請方法が自治体ごとに違い煩雑。仮ナンバー返納管理も未デジタル化。標準様式プリセット活用で共通化 |
| 7 | 納税証明書等の請求・交付システム | 総務省（デジタル庁） | 窓口・郵送が多く電子交付未対応。電子申請～決済～交付の完結で利便性と効率化、コスト最小化 |
| 8 | 住所・所在地情報管理システム | デジタル庁（総務省） | 地番と住居番号等が分散管理で重複コスト。アドレス・ベース・レジストリとして一元整備しコスト最小化 |
| 9 | 決算統計業務システム | 総務省 | 地方財政調査の作業が多大。元データ提出→国側集計で事務負担減・コスト最小化 |
| 10 | 幼稚園の被害状況等の情報収集・共有システム | 文部科学省（こども家庭庁） | 災害時の情報収集がメール・エクセルで非効率。既存システム活用でコスト削減 |
| 11 | 奨学給付金申請システム | 文部科学省（デジタル庁） | 就学支援金・奨学給付金で申請方法が異なる。e-Shien活用による一体的オンライン申請でコスト最小化 |
参照元: 共通化の対象選定に向けた令和７年度の対象候補の選定及び作業依頼について（案）
ざっと眺めてもらって、なんのシステムか想像つかないものもあるかと思いますが、どれも恐らく先ほどの 共通化A（国所有の1システム） となるのではないかと思っています。共通化Aなので、いわゆる標準仕様書は定義せずに、いつも通り、仕様書を策定して、調達して開発、運用、保守する形になるかなと個人的には感じています。
「共通化」「標準化」「共通SaaS」「公共SaaS」などの言葉が飛び交っていて、新参者の私には読み解くのが非常に困難なのですが、みんな向かってる方向性は同じだと信じて、あと数年でシステムの標準化・共通化の議論に決着させていってほしいなと願っています。。。！
4. どうやったら「公共SaaS」になれるのか？
ここまでで、それぞれの制度や言葉の定義がどうなっているのかを整理してきました。次に1事業者として気になるのは、じゃあどうやったら今私たちが開発しているSaaSが、公共SaaSになれるのかというところです。改めて公共 SaaS の定義を確認すると「ガバメントクラウドを利用環境として、重点計画に記載の「公共・準公共分野」に該当し、制度官庁が標準仕様を定める情報システムを SaaS として構築したもの」でした。
- 重点計画に記載の「公共・準公共分野」に該当するかどうか
- 制度官庁が標準仕様を定める情報システムかどうか
1. はざっくり行政向けのシステムであれば、ok と捉えたとして、問題は 2. です。
「2. 制度官庁が標準仕様を定める情報システムかどうか」かどうか。つまり、標準仕様書があるかどうか。です。
現時点では、標準20業務、及び、それに付随する業務以外の、標準仕様書は公開されていない認識です。
厚生労働省の「火葬等許可事務システム」は、標準20業務？
標準準拠システム 標準仕様書をよく見ると、「火葬等許可事務システム」など「これは標準20業務なのか？」というものも標準仕様書として定義されています。
筆者が調べたところによると、火葬等許可事務自体は、標準20業務ではない。しかし、歴史的経緯によって、標準20業務の「戸籍」と「火葬等許可事務」がパッケージとして提供されていた背景があるようです。
つまり、ルール上は「公共SaaS パターンB は民間」と定義されていても、2025年12月現在においては、ほとんどの業務が標準仕様が定義されていない状況です。そもそも全量としてどの程度の業務があるのかも、筆者は把握できていないです。またこの前述の通り、この標準化対象事務がどのように決まっていくのかも外から見ると不明瞭です。ぼーっとしていると、気づいたら、いつの間にか標準化対象事務が決まって、そのまま検討会が立ち上がって、競合となるような SIer の方々が、構成員や準構成員として検討会に参加していて、標準仕様書の策定プロセスに参加・意見できない状況になるんだろうと感じています。検討会への参加しないと入札時に負けるとかっていうわけではないと思いますが、事業者としては、参加するかどうかの意思表示ができるような状況には、しておくのが良いのかなーとは個人的には思いました。つまり何が言いたいかというと、現時点では、国の進めるペースや仕様の状況を各省庁とコミュニケーションを取っていくことしかできないのかなという現状です。すでに、自分たちが提供したいシステムが該当する業務、制度官庁とのコネクションがあれば、そこにアプローチしてもいいですし、まずは、ガバメントクラウドにおけるSaaS（公共SaaS）についての「3.5 公共SaaSの利用申請等（民間事業者が提供）」にあるデジタル庁の問い合わせ窓口に連絡するのも良いかもしれません。
5. 結局、自社提供パブリッククラウド・共通SaaS・公共SaaSどこで構築するの？
私自身もそうだったのですが、行政向け業界のエンジニアからすると「行政向けのインフラは全部ガバメントクラウドなのかな？」くらいのふわっとした認識しかないので、改めて、自社提供パブリッククラウドorガバメントクラウドどっちに構築していくのかについて、ここまでの内容も踏まえた簡単な決定木を示しておこうと思います。事業者として「」を判断する際の、大まかなフローは以下の通りです。
おわりに：中編を振り返って
この中編では、前編で整理した「前提条件」と「制約」を踏まえたうえで、ガバメントクラウドとその周辺概念について解説しました。
- ガバメントクラウドとは: デジタル庁が選定した複数のパブリッククラウド（AWS、Google Cloud、Azure、OCI、さくらのクラウド）で構成される利用環境
- 公共 SaaS とは: 制度官庁が標準仕様を定める情報システムを SaaS として構築したもの。FinOps 責任の所在が共同利用方式と異なる
- 共通 SaaS と公共 SaaS の違い: 共通化 A/B のパターンと、それぞれの位置づけ
- 事業者としてどこで構築するか: 標準化対象事務かどうか、標準仕様書の有無による判断フロー
ここまでで、「ガバメントクラウドとは何か」「公共 SaaS / 共通 SaaS の違いは何か」「事業者としてどう判断すべきか」という点が見えてきたかと思います。
後編では、これらの知識を踏まえたうえで、
- パブリッククラウド／ガバメントクラウドでインフラを構築する際に気をつけているポイント
- SRE として行政システムにどう向き合っているか
といった、より実践的な内容に踏み込んでいきます。ぜひ続きも読んでいただければと思います。
スライド by NotebookLM
Discussion