自治体クラウドファースト調達ガイド 2026：標準化/ガバメントクラウド・RFP作成・10ステップ

1. 自治体システム標準化とガバメントクラウドの全体像

まず整理すべきは、現在進められている「標準化・共通化」の真の定義です。これまでは、自治体ごとに独自の条例や運用に合わせた「個別最適」なシステムをベンダーに特注（カスタマイズ）してきましたが、これが維持管理コストの高騰と、自治体間でのデータ連携の阻害要因となっていました。

標準化対象となる主要20業務の範囲

デジタル庁が指定する標準化対象業務は、住民基本台帳から税、福祉まで多岐にわたります。これらの業務を扱うシステムは、国が定める「標準仕様書」に準拠していなければなりません。

• 住民基本台帳系：住民基本台帳、選挙人名簿管理、印鑑登録、戸籍、戸籍附票
• 税務系：固定資産税、個人住民税、法人市民税、軽自動車税
• 福祉・医療系：国民健康保険、国民年金、介護保険、後期高齢者医療、障害者福祉、生活保護
• 子育て・保健系：児童手当、児童育成手当、乳幼児健康診査、母子保健、予防接種

ガバメントクラウド（Gov-Cloud）の役割と構造

ガバメントクラウドとは、政府が確保したクラウドサービス（IaaS、PaaS、SaaS）の利用環境であり、地方公共団体もこの基盤を利用することが原則とされています。これにより、各自治体が個別に物理サーバーやネットワークを構築・運用する負担を軽減し、迅速かつセキュアなシステム展開が可能になります。

従来のオンプレミス運用では、ハードウェアの保守期限（EOSL）に合わせた5年ごとの大規模リプレースが必要でしたが、ガバメントクラウドへの移行後は、基盤側のアップデートが継続的に行われるため、ハードウェア更新に縛られない柔軟なシステム運用が可能となります。

出典: デジタル庁：地方公共団体情報システムの標準化・共通化

【比較】ガバメントクラウド選定5大CSPの特性と自治体への適応性

デジタル庁は、高い技術要件とセキュリティ基準を満たす5つのクラウドサービスプロバイダ（CSP）を選定しています。自治体は、自庁が利用する業務システムがどのCSP上で動作するか、あるいは基盤そのものをどう選定するかを判断する必要があります。

出典: デジタル庁：ガバメントクラウド（Gov-Cloud）について

2. 失敗しないベンダー選定：クラウド時代の採点指標とRFP作成実務

これまでのオンプレミス型システムの調達では、ハードウェアのスペックや機能の網羅性が重視されてきました。しかし、クラウド調達では「サービスの継続性」「標準化への適合度」「運用監視の自動化」に重点を置く必要があります。

RFP（提案依頼書）に必ず盛り込むべき非機能要件の定義

機能面は「標準仕様書」に準拠することが前提となるため、差が出るのは「非機能要件」です。以下のポイントを数値化・明文化して提案を求めるべきです。

• SLA（サービス品質保証）の具体的定義：
  単なる「努力目標」ではなく、稼働率99.9%以上を維持するためのインフラ構成（マルチAZ等）の提示を求めます。また、万が一の停止時の報告フロー、およびサービスレベル未達時の返金規定やペナルティ規定についても、事前に契約案へ盛り込むことが推奨されます。
• 責任共有モデルの明示：
  CSP（基盤側）、SaaSベンダー（アプリ側）、自治体（設定・データ管理側）の境界線を明確にします。特に「バックアップの取得・復旧テスト」「OS・ミドルウェアのパッチ適用」「特権IDの管理」を誰が責任を持つかをRACI（実行責任者・説明責任者・協議先・報告先）チャート等で整理させます。
• 出口戦略（Exit Strategy）の策定：
  クラウドの最大の懸念は「ベンダーロックイン」です。契約終了時や次期ベンダーへの交代時に、蓄積されたデータをどのような形式（CSV, JSON, SQLダンプ等）で返還するか、またその移行作業費用が適正かをあらかじめRFPで問う必要があります。

ISMAPによるセキュリティ評価の徹底

政府が求めるセキュリティ水準を満たしているかを確認するため、ISMAP（政府情報システムのためのセキュリティ評価制度）の登録有無は必須の確認項目です。

実務担当者のチェックポイント：

• 当該サービスが ISMAPクラウドサービスリスト に掲載されているか。
• 掲載されていない場合、ISMAP管理基準に準じた「監査報告書」や「第三者認証（SOC2 Type2等）」の提出が可能か。
• 特権ID管理（ログイン時の多要素認証、アクセスログの自動取得）がデフォルトで提供されているか。
• ログの長期保存（最低1年〜、重要度に応じ5年以上）が仕様に含まれているか。

【比較】自治体DXを支える主要SaaSの現在地

基幹系20業務以外でも、業務効率化や住民サービスの向上を目指し、導入が進んでいるSaaSの特性をまとめました。

会計業務のクラウド移行については、以下の詳細ガイドも実務の参考になります。特に「旧システムからのタグ変換」や「開始残高の調整」など、自治体会計特有の留意点が網羅されています。

freee会計導入マニュアル｜旧ソフト移行ガイド

3. 調達から導入完了までの10ステップ：実務スケジュールとアクション

標準化への移行は、単なるソフトの入れ替えではなく、数年規模の全庁プロジェクトです。一般的なステップと、各フェーズでの留意点をまとめました。

1. 現状調査（Fit&Gap分析）：
   現行システムの独自カスタマイズ箇所を徹底的にリストアップ。標準仕様で代替できるか、あるいは業務フローを変更（BPR）して対応するかを冷徹に判断します。ここで安易に「外出し開発」を認めないことが成功の鍵です。
2. 予算要望・財政協議：
   クラウド利用料（変動費）と、システム導入・保守料（固定費）を明確に分けて計上。デジタル基盤構造改革補助金などの国費負担枠を最大限活用するため、最新の交付要領を財政課と確認します。
3. RFP策定：
   前述の非機能要件に加え、データ移行（旧システムからのクレンジング）の分担を明記。特に「外字（JIS規格外文字）」の処理方針を決定します。
4. ベンダー選定（総合評価落札方式）：
   価格だけでなく、標準化対応の確実性、ガバメントクラウドへの習熟度、サポート体制、BCP対策を技術評価点として重く配点します。
5. 契約締結：
   長期保守の継続性や、法改正時の無償アップデート対応範囲、さらに「ガバメントクラウドの利用条件変更」に伴う仕様変更の扱いを明確にします。
6. 要件定義・設定設計：
   標準準拠システムの「パラメータ設定」を中心に行います。独自機能の追加は原則不可であることを、現場の担当課（原課）に対して首長・CIO名義で徹底します。
7. データ移行準備（クレンジング）：
   住所コードの標準化（アドレス・ベース・レジストリ準拠）や、生年月日の和暦・西暦変換ルールの統一。不整合データは移行前に修正を完了させます。
8. 接続テスト（ネットワーク）：
   LGWAN-ASP接続、または三層分離の緩和（α’モデル等）に基づくインターネット接続テストを実施。ファイアウォール設定やプロキシ経由の通信に不備がないかを確認します。
9. 職員研修・操作習熟：
   マニュアル整備に加え、操作説明動画の配信や、チャットボットによるFAQ対応を準備。本稼働直後のヘルプデスクへの問い合わせ集中を分散させます。
10. 本稼働・事後評価：
    当初のKPI（申請時間の短縮、紙の削減量、窓口滞在時間の短縮等）を測定。不具合や使い勝手の課題をベンダーへフィードバックし、運用の最適化を継続します。

SaaS導入における「アカウント管理の不備」や「退職者のアクセス権削除漏れ」を防ぐための自動化アーキテクチャについては、以下の記事が詳しく解説しています。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

4. 【運用・リスク管理】クラウド特有の異常系シナリオと対策

自治体がクラウドを導入した後に直面する「想定外のトラブル」と、その回避策を時系列・シナリオ別に整理します。

シナリオA：クラウド利用料が想定を大幅に超える（予算管理の異常）

クラウド（IaaS/PaaS）は従量課金制が多いため、大量のデータ通信や予期せぬアクセス負荷により、月額費用が予算枠を突き抜けるリスクがあります。

• 根本原因： 開発環境の消し忘れ、DDoS攻撃によるトラフィック増、不適切なDBクエリによる演算負荷。
• 対策：
  • 各CSPの予算アラート（Budgets）機能を設定し、予算の80%, 100%超過時にメールやチャットへ自動通知。
  • 不要な開発・検証環境の夜間自動停止スクリプトの導入。
  • あらかじめ予備費を計上しておくか、定額制（リザーブドインスタンスやセービングプラン）を組み合わせたコスト固定化。

シナリオB：広域災害時のサービス停止（可用性の欠如）

特定のデータセンターが被災した場合でも、罹災証明の発行などの行政継続（BCP）が求められます。

• 根本原因： リージョン（地域）単位の広域障害、または特定のAZ（アベイラビリティゾーン）の全損。
• 対策：
  • ガバメントクラウドが推奨する「マルチAZ」構成を標準とし、物理的に離れた拠点での冗長化を確認。
  • 最悪の事態（インターネット断絶）に備え、オフラインでも最低限の業務が継続できる「紙ベース」または「スタンドアロンPC」での予備フローを定義。
  • 定期的なディザスタリカバリ（DR）試験の実施。

シナリオC：ベンダーの経営破綻・サービス終了（継続性の喪失）

特にスタートアップ企業のSaaSを導入する場合、サービス継続リスクを考慮する必要があります。

• 根本原因： 企業の倒産、または不採算による公共事業からの撤退。
• 対策：
  • エスクロー契約（ソースコードやデータの第三者預託）の検討。
  • 標準的な形式でのデータエクスポート機能を定期的に実行し、自治体側でバックアップ（二次保管）を保有する運用。
  • 契約書に「サービス終了の1年以上前までの通知」を義務化する。

シナリオD：データ移行時、旧システムの「ゴミ」が新システムを破壊する

旧システムで独自に入力していた外字や、論理矛盾のあるデータが標準準拠システムでのエラーを誘発します。

• 根本原因： 長年のカスタマイズで肥大化した独自外字、バリデーション（入力チェック）をすり抜けた不正な日付データ等。
• 対策：
  • 移行前の「データクレンジング」工程に十分な期間（3〜6ヶ月）を割く。
  • 不整合データの強制変換ルール（例：不正な日付は一律で最小値を設定するなど）をあらかじめベンダーと合意しておく。
  • 外字はJIS規格（第1〜第4水準）への置換を原則とする。

5. 自治体ネットワークの変遷：LGWANとクラウド接続の最適解

クラウドファースト調達において、最も議論となるのが「ネットワーク分離（三層分離）」との整合性です。総務省のガイドライン改定により、現在は「α’（アルファダッシュ）モデル」や「β（ベータ）モデル」など、より柔軟な接続形態が許容されています。

出典: 総務省：地方公共団体における情報セキュリティ対策

業務の自動化とセキュリティの両立については、以下のアーキテクチャ解説もご覧ください。Google Workspace等を活用したノンコード開発の現場実務が詳細に語られています。

Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

6. 先行事例に見る「成功の型」と共通要因

ガバメントクラウド先行事業や、早期に全庁DXを完遂した自治体には、明確な共通要因が存在します。

ケース1：福島県磐梯町（デジタル変革のトップランナー）

課題： 人口減少下での持続可能な行政サービスの構築と、旧態依然とした業務フローの刷新。
導入： 日本初の「自治体最高デジタル責任者（CDO）」を外部から招聘。AWSを活用した行政手続きのフルオンライン化を推進しました。
運用： 単なるツール導入に留まらず、職員の意識改革プログラムを同時に実施。
結果： 住民の「書かない・待たない」窓口を実現し、オンライン申請率が国内トップクラスに向上。

ケース2：東京都渋谷区（標準化と独自施策の共存）

課題： 多様な住民ニーズに応えるための迅速なシステム改修と、問い合わせ対応の飽和。
導入： LINE公式アカウントを窓口（UI）とし、バックエンドのCRMにSalesforceを採用して連携。
運用： 標準化対象の基幹業務は着実に移行しつつ、住民接点のフロントエンドを独自開発で強化。
結果： 住民票の写しなどの申請が24時間スマホで完結。窓口の混雑緩和と職員の事務負担軽減を同時に達成。

成功自治体に共通する「3つの型」と失敗を避ける条件

1. 「標準準拠」を徹底し、浮いたリソースで「フロントエンド」に投資：
   基幹系での無理なカスタマイズを一切行わず、そこから生まれた予算と人員を、住民が直接触れるアプリやUIの開発に集中させています。
2. トップ（首長）による強力なガバナンス：
   「これはIT部門の問題ではなく、経営（町政・市政）の問題である」と首長が宣言し、縦割り組織の壁を打破して全庁的な協力を得ています。
3. 外部人材とプロパー職員の「ハイブリッド・チーム」：
   民間出身の技術スペシャリストと、行政法規や現場実務に精通したベテラン職員が対等に議論し、無理のない設計を行っています。

7. 自治体DX推進における「実務の要点」チェックリスト

調達・導入の各フェーズで、見落としがちな実務ポイントをチェックリスト形式でまとめました。

8. 実務でよくある質問（FAQ）

Q1: 標準化対応により、現在の便利な機能が使えなくなるのでは？

A: 多くの機能は「標準仕様」に含まれますが、特定の自治体固有の特殊な処理（条例に基づく独自の減免措置など）は、標準システムの範囲外となる場合があります。これを機に、法的な根拠に乏しい慣習を廃止する「BPR」として捉えることが重要です。どうしても必要な場合は、周辺システム（サブシステム）として外出しで構築する検討が必要ですが、コスト増に直結するため慎重な判断を要します。

Q2: ガバメントクラウドの利用料はどこが支払うのですか？

A: 原則として各自治体がCSPと直接契約、またはシステムベンダー経由で契約し、利用料を支払います。ただし、標準化移行に伴う費用については、国からの財政支援措置（デジタル基盤構造改革補助金等）が用意されています。補助対象の範囲（どこまでが補助され、どこからが自己負担か）については、最新の総務省通知を必ず確認してください。

Q3: 小規模な自治体でもクラウド化は必須ですか？

A: はい。地方公共団体情報システム標準化法により、全1,741市区町村に20業務の標準化移行が義務付けられています。小規模な自治体ほど、自前で高価なサーバーやセキュリティ設備を抱えるよりも、クラウドを「共同利用」する方が、1団体あたりのコストメリットやセキュリティ品質が飛躍的に向上します。

Q4: セキュリティパッチの適用は誰の責任ですか？

A: 利用形態によります。SaaSの場合はベンダーが全てを担いますが、IaaS/PaaSの場合は「責任共有モデル」に基づきます。一般的には、OS・ミドルウェア以上のパッチ適用は自治体（または委託先ベンダー）、それ以下のインフラ層はCSPが責任を持ちます。RFPおよび契約書において、この「責任の境界線」を明確にしていないと、重大な脆弱性が放置されるリスクがあります。

Q5: ネットワーク分離（三層分離）の見直しは必須ですか？

A: 必須ではありませんが、クラウドサービスの利便性を最大限享受するには、従来の「αモデル」から、より柔軟な「α’モデル」や「βモデル」への移行、あるいは「β’モデル」の検討が推奨されます。総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」の最新版を参照し、自庁のセキュリティ耐性と利便性のバランスを再定義してください。

Q6: 電帳法（電子帳簿保存法）への対応はどうすればよいですか？

A: クラウドシステム調達時に「JIIMA認証（電帳法対応の法的要件を満たす製品認証）」の有無を確認してください。また、単に「保存できる」だけでなく、検索要件や真実性の確保が運用フローとして確立できるかを、経理・監査部門と協議する必要があります。会計ソフト単体での対応が難しい場合は、証憑管理に特化したSaaSを連携させる構成も有効です。

9. まとめ：2025年度末へのラストスパート

自治体DXの完遂は、単なるITのアップグレードではなく、日本の行政そのものを「持続可能」な形へリデザインする国家的なプロジェクトです。ガバメントクラウドへの移行期限である2025年度末はゴールではなく、その後の柔軟なデジタル行政に向けた「スタートライン」です。

本ガイドで解説した調達戦略やリスク管理を基に、ベンダーとの健全なパートナーシップを築きつつ、住民にとって真に価値のあるデジタル行政を実現されることを期待します。

また、広告データの活用による自治体の広報最適化や、データ基盤の構築については以下のアーキテクチャ解説も実務のヒントとなります。

広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ