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

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ケーススタディ」カテゴリ追補として、公共・自治体システムのケースを解説する記事です。

民間SaaSと違い、公共システムは「ガバメントクラウド認定」「調達制約」「10年単位の運用」「住民データ取り扱い」という固有の制約に縛られます。本記事では認定ベンダーの選定、政府の標準化（地方公共団体情報システムの標準化）への準拠、調達手続きを織り込んだ設計の進め方を整理します。

本記事のテーマについてさらに詳しく知りたい方は『情報処理教科書 システムアーキテクト 2025～2026年版』も参考にしてみてください。

そもそも公共システムのアーキテクチャとは何か

市役所の窓口業務を想像してください。民間サービスと違い、「全住民に平等にサービスを提供する義務」「公金の適正な執行」「職員が異動しても業務が止まらない設計」が大前提です。効率やスピードより、公平性・透明性・長期安定性が優先されます。

公共システムのアーキテクチャは、ガバメントクラウド認定・調達手続き・10年単位の運用・住民データの厳格な管理という、民間SaaSとは根本的に異なる制約の中で設計します。

もし民間と同じ感覚で設計すると、認定外ベンダーの採用で調達がやり直しになったり、政府の標準化基準に適合せず使えないシステムが出来上がります。

なぜ公共システム特有の設計が必要なのか

民間の設計常識がそのまま通用しないから

公共システムはガバメントクラウド認定ベンダーしか使えない・調達に半年〜1年かかる・カスタマイズが原則禁止の標準化対象業務がある──といった、民間SaaSとは全く異なるルールで動いています。民間の成功体験をそのまま持ち込むと、調達段階でやり直しになります。

「全住民に平等に」という使命が設計を規定するから

公共システムは利益最大化ではなく公平性・透明性・継続性が最優先です。特定ベンダーへのロックイン・特定端末への依存・特定スキルへの属人化は、職員が2〜3年で異動する公共組織では致命的です。

10〜20年の運用を前提に設計するから

民間が3〜5年で作り直すスパンに対し、公共は10〜20年の運用が前提です。最新技術や尖った言語は、10年後に保守できる人材が確保できないリスクがあります。「枯れた技術＋認定ベンダー＋標準準拠」が鉄則になるのは、この長期運用前提が理由です。

公共システムの3つの大前提

民間と同じ感覚で設計に入ると確実に詰みます。最初に押さえるべき制約は次の3つです。

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

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

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

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

③ 10年運用が前提

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

推奨スタック（全体像）

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

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

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

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

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

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

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

やってはいけないこと

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

| 「民間SaaSの成功構成を持ち込む」と鵜呑み | ガバメントクラウド認定外は調達不可、監査・住民データ要件で破綻 | | 「10年後の技術は予測できない」と流行技術を採用 | 職員異動・人材調達で詰む、枯れた言語（Java・C#）が鉄則 |

AI判断軸

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

ガバメントクラウド認定ベンダーのAI機能を使う

公共システムでAIを活用する場合、ガバメントクラウド認定ベンダー（AWS・Azure・Google Cloud・Oracle Cloud・さくらインターネット）が提供するAI機能を使うことが前提条件です。ChatGPTのような非認定SaaSに行政データを送信することは、セキュリティポリシー上認められないケースが大半です。

AWS Bedrock、Azure OpenAI Service、Google Cloud Vertex AIなどの認定ベンダー内AI機能であれば、データが国内リージョンに留まり、既存のセキュリティ基準（ISMAP等）の範囲内で利用できます。調達仕様書にAI活用要件を含める場合も、認定ベンダーのサービス名を明記することで調達審査を通しやすくなります。

運用手順のMarkdown化がAI自動化の前提になる

公共システムの運用は3〜5年ごとの職員異動が前提です。Word/PDFで納品された運用手順書は異動時に引き継がれない、またはバージョン管理されず古くなるという問題が繰り返し発生しています。

運用手順をMarkdownでGitリポジトリに格納し、バージョン管理する方式に変えると、2つのメリットが得られます。1つは異動時の引き継ぎが「リポジトリへのアクセス権付与」だけで完結すること。もう1つは、Markdown化された手順書がAIエージェントの入力として使えるようになり、障害対応の初動自動化や定型作業の実行をAIに委ねられるようになることです。

Word形式の手順書は人間しか読めませんが、Markdownの手順書は人間にもAIにも読める「機械可読な運用ナレッジ」として長期的に価値を持ちます。

この記事に関連する記事

https://senkohome.com/arch-intro-case-ai-product/ https://senkohome.com/arch-intro-case-enterprise/ https://senkohome.com/arch-intro-case-mobile/

まとめ

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

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

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

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

本記事で扱った内容の詳細は AWS 公共機関向け も合わせて参考にしてください。

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