公共・自治体システム ― ガバメントクラウドと長期運用 ― 生成AI時代のアーキテクチャ超入門

flowchart TB
    GOV[公共・自治体システム]
    A[① ガバメントクラウド<br/>認定ベンダーのみ]
    B[② 調達手続き<br/>仕様書・入札・複数社見積]
    C[③ 長期運用<br/>10年〜・職員異動を前提]
    GOV --> A
    GOV --> B
    GOV --> C
    classDef gov fill:#fef3c7,stroke:#d97706,stroke-width:2px;
    classDef cons fill:#fee2e2,stroke:#dc2626;
    class GOV gov;
    class A,B,C cons;

① ガバメントクラウド認定ベンダーのみ採用可

デジタル庁が認定したベンダーしか公共システムには使えません。2026年時点では AWS / Azure / GCP / Oracle Cloud / さくらインターネット が認定済みです。Cloudflareや個別SaaSは原則として使えません。

② 調達手続きが半年〜1年単位

仕様書策定 → 公告 → 入札 → 落札 → 契約までで最低半年かかります。アジャイルで回すには制度設計から見直しが必要で、現状は段階契約（要件定義契約 → 開発契約）で擬似アジャイルにする方式が定着しています。

③ 10年運用が前提

民間が3〜5年で作り直すスパンに対し、公共は10〜20年運用が普通です。職員も2〜3年で異動するため、特定担当者の暗黙知に依存する構成は確実に破綻します。

推奨スタック（全体像）

公共向けは「枯れた技術 + 認定済みベンダー + 標準準拠」が3点セットです。

領域	推奨	理由
クラウドベンダー	AWS / Azure（ガバメントクラウド認定）	デジタル庁の標準採用
言語	Java / C# / TypeScript	人材調達のしやすさ・10年後も書ける
FW	Spring Boot / .NET / Next.js	主流かつ安定
DB	PostgreSQL / Oracle	ACID必須・長期運用実績
認証	LGWAN-ASP / マイナンバー連携 / 庁内AD	公共固有の認証基盤
ID基盤	地方公共団体情報システム機構（J-LIS）	住民基本台帳ネットワークと連携
監視	ベンダー標準 + 24/7有人監視	SLAで明示

最新技術や尖った言語は人材確保の観点で禁忌。10年後に書ける人がいる言語に倒すのが鉄則です。

標準化（地方公共団体情報システムの標準化）への対応

2025年度末までに全国1,741自治体が、住民記録・税・福祉等の20業務について「標準準拠システム」へ移行する政府方針が走っています。これに該当する業務は、独自カスタマイズが原則禁止になりました。

区分	対応方針
標準化対象業務（20業務）	標準仕様準拠製品を選定、カスタマイズ禁止
標準化対象外業務	独自開発可、ただし標準化対象との連携APIは規定
非業務システム（庁内ポータル等）	民間並みの自由度

「標準仕様」に準拠したパッケージ（富士通・NTTデータ・日立等）を選んで、Fit to Standard（業務側を製品に合わせる）が現代の本命。業務側の独自要件を残してパッケージをカスタマイズするのは、Lidl SAP eLWIS事件と同じ轍です。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

項目	選択肢の例
ガバメントクラウドの選定	AWS / Azure / GCP / Oracle / さくら
標準化対象か	20業務該当 → 標準準拠 / 対象外 → 独自設計可
認証基盤	LGWAN-ASP / マイナンバー / 庁内AD
調達方式	一般競争入札 / 企画競争 / 随意契約
運用期間想定	5年 / 10年 / 20年
BCP水準	RPO 1時間 / RTO 4時間（標準）
監査要件	個人情報保護条例 / J-SOX類似
多言語対応	日本語のみ / 多言語（在日外国人対応）

公共向け固有の鬼門

禁じ手	なぜダメか
「アジャイル契約なし」でアジャイル開発	仕様変更で追加契約が必要、結局ウォーターフォール化
新興言語・新興フレームワーク採用	10年後の人材調達で詰む、退職した職員と同じ
個別職員の運用作業に依存	異動で消える、Runbookと自動化が必須
標準化対象業務の独自カスタマイズ	政府方針違反、補助金対象外に
認定外クラウド・認定外SaaS採用	監査で指摘、調達やり直し
Excelによる手作業集計の温存	業務改革の機会損失、長期的に維持コスト増
海外データセンターでの個人情報保管	法令違反、住民訴訟リスク
退職予定ベンダーへの全依存	撤退時にブラックボックス、保守継続困難

公共は「攻めの設計」より「枯れた選択の積み上げ」が正解です。

AI時代の視点

AI駆動開発が浸透しても、公共システムでは「AIが書いたコードを職員が責任持って説明できるか」が問われます。住民への説明責任があるため、ブラックボックスは原則として認められません。

AI時代に有利	AI時代に不利
標準準拠 + IaC + Git管理	独自設定・Excel手順書
Markdown化された運用手順	Word/PDFでベンダー納品
認定ベンダーのAI機能（AWS Bedrock等）	認定外AI SaaS（ChatGPT直接連携等）
RAG前提の標準化された業務データ	各課バラバラのExcelデータ

データ連携基盤（自治体間連携API・ベース・レジストリ）が整備されつつあり、ここに乗せるか否かでAI活用余地が決定的に変わります。

最終的な判断の仕方

公共システムの核心は「制度・人事・住民データの3制約のもとで、10年動く構成を選ぶ」ことに尽きます。民間の「最新技術で速く作る」感覚は通用せず、ガバメントクラウド認定・標準準拠・主流言語・職員異動を前提とした自動化、この4点を外すと数年単位で炎上します。

もう一つの軸は「Fit to Standard を貫く勇気」です。標準化対象業務で独自要件を主張するほど、製品アップデートに乗れず、5年後に塩漬けになります。業務側を製品に合わせる文化を経営層と合意するのが、ソリューションアーキテクトの最大の仕事です。

選定の優先順位

ガバメントクラウド認定ベンダーから選ぶ — 範囲外は調達不可
標準化対象業務はFit to Standard — 独自カスタマイズは政府方針違反
10年後に人材がいる言語・FWに倒す — 尖った選定は人事で詰む
運用は自動化・Markdown化 — 職員異動を前提に設計

「枯れた技術と標準準拠の積み上げ」派手さはなくても、これが住民を守る設計です。

まとめ

本記事は公共・自治体システムのケースについて、ガバメントクラウド・標準化・調達制約・10年運用・AI時代の説明責任まで含めて解説しました。如何だったでしょうか。

認定ベンダーから選び、標準準拠を貫き、人材確保を見据え、自動化で職員異動に備える。これが2026年の公共システムの現実解です。

次回は「モバイルアプリ専業」のケースについて解説します。iOS/Android両対応、ストア審査、E2E暗号化など、Webと違うモバイル固有の判断軸を扱う予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。