自治体DXを加速！クラウド移行におけるセキュリティ・コスト設計と失敗しない実践ガイド

2025年度末に期限が迫る「自治体情報システムの標準化・共通化」は、日本の行政インフラにおける過去最大級の転換点です。従来、各自治体が個別にオンプレミスで構築・運用してきた「住民基本台帳」や「地方税」などの基幹業務システムを、デジタル庁が提供する共通基盤「ガバメントクラウド（Government Cloud）」へ移行することが求められています。^[1]

しかし、クラウド移行は単なる「サーバーの引っ越し」ではありません。地方自治体特有の「LGWAN（総合行政ネットワーク）」との接続維持、厳格なセキュリティ要件の遵守、そして従量課金制に伴う予算管理の難しさなど、実務担当者が解決すべき課題は多岐にわたります。本ガイドでは、デジタル庁の指針や主要クラウドサービスプロバイダー（CSP）の公式ドキュメントに基づき、失敗しないための設計・運用・移行手順を、15,000文字規模の技術的知見をもって詳述します。

1. ガバメントクラウド（GCAS）の定義と自治体に課される役割

まず、ガバメントクラウドの定義と、移行にあたって自治体が担うべき責務を整理します。ここでの理解が、後の設計ミスを防ぐ土台となります。

1-1. ガバメントクラウドの全体像

ガバメントクラウドとは、デジタル庁が契約し、地方公共団体や中央省庁が共通して利用できるクラウドサービス利用環境です。特定のベンダーに依存しない「マルチクラウド」を前提としており、以下の認定を受けたCSPが基盤を提供します。^[2]

• Amazon Web Services (AWS)
• Microsoft Azure
• Google Cloud
• Oracle Cloud Infrastructure (OCI)

各自治体は、デジタル庁が用意した「GCAS（Government Cloud Administrative Service）」というポータルを通じて、これらのリソースを調達・管理します。^[3]

1-2. 責任共有モデル：自治体の責任範囲

クラウド環境では、セキュリティの責任をCSPと利用者が分担する「責任共有モデル」が適用されます。これを誤認すると、重大な設定漏れによる事故に繋がります。

特に、「特権IDの管理」や「ログの監視」は自治体側の責任であることを再認識する必要があります。マネージドサービスを利用する場合でも、その設定権限を持つのは自治体側（または受託ベンダー）であり、不適切な設定による漏洩はCSPの責には問えません。

2. 主要CSPの徹底比較と選定のポイント

ガバメントクラウドとして認定されている主要サービスは、いずれも政府情報システムのためのセキュリティ評価制度（ISMAP）を満たしていますが、特性や得意領域が異なります。^[4]

2-1. CSP別の機能・強み一覧

2-2. 選定における「現実的な判断軸」

技術的な優劣だけでなく、以下の「運用継続性」を考慮してCSPを選定すべきです。デジタル庁の推奨方針^[5]も踏まえ、以下の3点をチェックしてください。

• 既存ライセンスの有無: すでに庁内でMicrosoft 365を全庁導入している場合、ID管理の統合や「Azure Hybrid Benefit」によるOSライセンス費用の削減効果から、Azureが有力な選択肢となります。
• 地場ベンダーの習熟度: 既存システムの保守を委託しているパートナー企業が、どのCSPの認定資格（AWS Certified, Azure Solutions Architect等）を多く保有しているかは、移行後の安定運用と障害対応スピードに直結します。
• ネットワーク経路: LGWAN-ASP等を通じた接続実績があるか、あるいは「ガバメントクラウド接続サービス」との相互接続性が検証済みかを確認してください。

3. 失敗しないセキュリティ設計：ゼロトラストへの転換

従来の自治体ネットワークは、三層の対策（LGWAN、業務系、インターネット系）に基づき、境界で防御する考え方でした。しかし、クラウド活用においては、「すべてのアクセスを信頼せず、常に検証する」というゼロトラストモデルへの転換が必須です。^[6]

3-1. ネットワーク分離と閉域接続の高度化

基幹業務システム（住民情報等）をクラウドに置く場合、インターネット経由の直接アクセスは原則として遮断します。デジタル庁が提供する「ガバメントクラウド接続サービス（GC-Connect）」を利用し、専用線または広域イーサネットによる閉域網を構築します。この際、ゲートウェイでのIDS/IPS（侵入検知・防御）や、FQDNベースのフィルタリングを組み合わせ、パケットレベルでの安全性を担保します。

3-2. ID・アクセス管理（IAM）の最小権限原則

「誰が、いつ、どこから、どのリソースに」アクセスできるかを厳格に制御します。実務上は、以下の設定を「標準」として組み込むべきです。

• 多要素認証（MFA）の義務化: パスワードのみの認証を廃止し、FIDO2準拠のハードウェアキーや認証アプリ、またはクライアント証明書を必須とします。
• 特権IDの時限付与: 常時管理権限を持つアカウントを運用せず、保守作業時のみ承認フローを経て一時的に権限を付与する「Just-In-Time (JIT) アクセス」を採用します。
• 条件付きアクセス: 「庁内LAN（特定のIPアドレス）以外からのアクセスを拒否する」「最新のパッチが当たっていない端末を拒否する」といった動的なポリシーを適用します。

3-3. ログの不変性担保と統合監視

万が一の不正アクセスや設定ミスが発生した際、原因を遡れるようにログを設計します。^[7]

・不変ストレージへの転送: AWS CloudTrailやAzure Activity Logを、専用の「ログ集約用アカウント」内の変更不能（Object Lock等）なバケットへ即時転送します。

・異常検知の自動化: SIEM（Security Information and Event Management）を活用し、「通常ありえない深夜帯のログイン」「大量のデータエクスポート」を検知した際に、自動でアカウントを一時凍結するようなオートメーションを実装します。

4. 【全10ステップ】クラウド移行の完全実践手順

既存のオンプレミス環境からガバメントクラウドへ移行するための、実務的なロードマップを解説します。これは、デジタル庁の「地方公共団体情報システム標準化基本方針」に沿ったプロセスです。^[8]

ステップ1：現状資産のアセスメント（精緻な棚卸し）

既存システムのOSバージョン、ミドルウェア（Java, .NET等）のバージョン、DBサイズ、外部API連携の有無をすべて洗い出します。ここで「Windows Server 2008 R2」などのレガシーOSが残っている場合、クラウド移行前に最新OSへのアップグレードまたはアプリの再構築が必要となり、工数が大幅に変動します。

ステップ2：移行戦略の策定（6Rの適用）

すべてのシステムをそのまま「リフト」するのは非効率です。以下の「6R」に基づき、業務ごとに方針を決定します。^[9]

ステップ3：ガバメントクラウド利用申請とGCAS設定

デジタル庁への利用申請を行い、アカウントを入手します。その後、GCAS（ガバメントクラウド運用管理補助者）のガイドに従い、支払管理設定や組織プロファイルの登録を行います。このプロセスには組織内の決裁を含むため、最低でも3ヶ月のリードタイムを見込む必要があります。

ステップ4：ランディングゾーン（着陸地点）の構築

システムを載せる前の「共通基盤設定」を行います。
・AWSの場合: AWS Control Towerを使用し、セキュリティ通知設定、ログ集約、リージョン制限を一括適用します。^[10]
・Azureの場合: Azure Landing Zoneアクセラレータを活用し、マネージドIDやネットワークトポロジを標準化します。

ステップ5：IaC（Infrastructure as Code）による環境定義

手作業での設定変更は、本番環境と検証環境の「設定差分」を生み、障害の温床となります。TerraformやAWS CloudFormationなどのIaCツールを用い、インフラ構成をコードで管理します。これにより、環境の再現性が担保され、監査時のエビデンスとしても機能します。

ステップ6：データ移行のプロトタイプ（PoC）

住民基本台帳などの大規模DBを実際に移行できるか試行します。
・オンライン移行: AWS DMS (Database Migration Service) 等を使用。
・オフライン移行: 数十TBを超える場合は、Snowball Edge等の物理デバイスを用いた輸送を検討します。^[11]

ステップ7：アプリケーションの改修とクラウド最適化

「IPアドレスが固定であること」を前提とした古い設計や、共有フォルダ（SMB）への依存を排除します。特に、クラウド特有の「一時的なネットワーク断」に備えたリトライ処理（指数バックオフ等）の組み込みは、システムの可用性を高めるために必須です。

ステップ8：並行運用とユーザー受け入れテスト（UAT）

オンプレミスとクラウドを同時に稼働させ、リアルタイムでデータを同期します。この期間に、実際の窓口職員が操作し、レスポンス速度や帳票出力の動作に問題がないかを確認します。画面遷移が1秒遅れるだけで、窓口業務は大混乱に陥るため、徹底した検証が必要です。

ステップ9：本番切り替え（カットオーバー）と監視開始

DNSまたはルーティングの切り替えを行い、全トラフィックをクラウドへ向けます。万が一の重大不具合に備え、「1時間以内に旧環境に戻す」ためのロールバック手順書を、事前にリハーサルしておくことが成功の鍵です。

ステップ10：コスト最適化（ライトサイジング）

移行完了から3ヶ月程度経過した段階で、リソースの使用率を分析します。想定より負荷が低いサーバーのスペックを下げ（インスタンスタイプの変更）、予約済みインスタンス（RI）やセービングスプランを適用することで、ランニングコストを最大40〜60%削減可能です。

5. クラウドコスト管理（FinOps）の実務

自治体の予算は「年度ごとに固定」されているのに対し、クラウドは「使った分だけ課金」される従量制です。このギャップを埋めるための「FinOps（クラウド財務管理）」が不可欠です。^[12]

5-1. 予算超過を防ぐための多段アラート

• 予算閾値の設定: 月間予算の50%, 80%, 100%, 120%に達した時点で、IT部門と財政部門へ自動メール通知が行われるよう設定します。
• 不要リソースのスケジュール停止: 夜間や休日に稼働する必要のない「検証環境」や「開発環境」を、サーバーレススクリプト（Lambda等）で自動シャットダウンさせます。これだけで、対象リソースのコストを約60%削減できる場合があります。

5-2. データ転送料金（Egress）の制御

見落としがちなのが「データ転送料金」です。クラウドへのアップロード（Ingress）は無料ですが、「クラウドから庁内LANへデータをダウンロードする（Egress）」際には課金が発生します。大容量のバックアップデータを毎日庁内に持ち帰るような設計は、予期せぬコスト高騰を招きます。バックアップは同一クラウド内の他リージョンへ保存するのが鉄則です。^[13]

6. 異常系の時系列シナリオ：トラブル発生時の初動対応

設計通りにいかないのがクラウド実務です。想定される異常事態とその対策を、時系列シナリオで整理しました。

シナリオA：急激なコスト高騰（コスト・スパイク）

1. [09:00 発生] 予算アラートが発報。月次予算をわずか3日で80%消費したことを検知。
2. [09:30 原因究明] Cost Explorerで分析した結果、特定のサーバーが無限ループでログを出力し、ストレージ（EBS/S3）書き込み料が激増していると判明。
3. [10:00 対策] 当該サーバーのプロセスを強制停止。APIレートリミットを適用し、不具合箇所のコード修正を実施。

シナリオB：DR（災害復旧）発動時のデータ欠損

1. [14:00 発生] メインリージョン（東京）で大規模な広域障害が発生。BCPに基づきバックアップリージョン（大阪）へ切り替え。
2. [15:00 課題] 非同期レプリケーションを採用していたため、直近5分間の入力データが大阪側に反映されていないことが判明。
3. [対応] 業務ごとに許容可能なデータ欠損時間（RPO）を再定義。住民票など最重要データについては、コストはかかるが「マルチAZ（同時書き込み）」構成への変更を検討。

シナリオC：設定ミスによるストレージ公開

1. [18:00 発生] 委託業者の作業員が、一時的なファイル共有のためにS3バケットを誤って「公開（Public）」に設定。
2. [18:01 自動検知] ガードレール機能（AWS Config Rules等）がポリシー違反を即座に検知。
3. [18:02 自動修復] システムが自律的にバケット設定を「非公開」に強制変更。管理者にインシデント通知。

7. 自治体におけるクラウド活用の成功事例詳解

デジタル庁が公開している公式事例の中から、特に実務的な示唆に富むものを深掘りします。^[14]

事例1：兵庫県神戸市（ガバメントクラウド先行移行）

【課題】 5年ごとの物理サーバー更新に伴う数億円規模の予算確保と、震災などの災害発生時の業務継続性（DR）。

【導入】 AWS（ガバメントクラウド）を基盤に採用。住民基本台帳を含む基幹業務20業務を順次移行。^[15]

【成果】
・迅速な拡張: 新型コロナウイルス対応時の給付金申請など、急激なアクセス増に対し、数分でサーバーリソースを増強。
・職員のシフト: 物理インフラの保守（テープ交換、室温管理等）から解放され、職員が「市民サービスのUX改善」という本来のDX業務に注力可能に。

【成功の型】 ベンダーに「丸投げ」せず、市役所内にエンジニアリングを理解する技術チームを組織し、IaC（Infrastructure as Code）による自前での環境管理を推進したこと。

事例2：兵庫県加古川市（スマートシティとデータ連携）

【課題】 各課でバラバラに保持されているデータを統合し、エビデンスに基づく政策形成（EBPM）を実現したい。

【導入】 Google Cloud（BigQuery）を活用したデータ連携基盤を構築。^[16]

【成果】 見守りカメラの稼働状況や、住民からの不具合通報アプリのデータを地図上でリアルタイム可視化。
【示唆】 クラウド移行は単なる「コスト削減」ではなく、「データの民主化」を進めるための土台であることを証明した。^[17]

8. 自治体IT担当者が知っておくべきFAQ

Q1. LGWAN接続を維持したままクラウドへ移行できますか？

A1. はい。デジタル庁が提供する「ガバメントクラウド接続サービス（GC-Connect）」を利用することで、従来のLGWAN環境からクラウド上のシステムへセキュアにアクセス可能です。ただし、動画配信などの大容量通信を行う場合は、回線帯域の設計に注意が必要です。^[18]

Q2. ベンダーへの「丸投げ」はなぜ危険なのですか？

A2. クラウドは毎週のように新機能が追加され、仕様も変更されます。ブラックボックス化すると、不要な高額オプションが放置されたり、最新のセキュリティパッチが適用されていないことに自治体自身が気づけず、結果として「法的・社会的責任」を負うことになるからです。

Q3. データセンターの場所（リージョン）は選べますか？

A3. ガバメントクラウドでは、原則として「日本国内（東京・大阪）」のリージョンを利用することが強く推奨されています。海外リージョンは法域の問題（データ主権）やレイテンシ（通信遅延）のリスクがあるため、特段の理由がない限り避けるべきです。^[19]

Q4. 既存のオンプレミス用ソフトをそのまま動かせますか？

A4. 技術的には「リホスト」が可能ですが、ソフトウェアのライセンス体系（BYOL：Bring Your Own License）によっては、クラウド上での利用が禁止されていたり、追加料金が発生したりする場合があります。事前にパッケージベンダーへの確認が必要です。

Q5. 移行中に住民サービスを止める必要はありますか？

A5. データの整合性を完全に保つため、最終的な切り替え（カットオーバー）時には、数時間から1日程度のメンテナンス（サービス停止）が必要になるのが一般的です。週末や深夜を利用し、住民へは十分な事前周知を行う必要があります。

Q6. 20業務以外のサブシステムもクラウドに移行すべきですか？

A6. 標準化対象の20業務を最優先すべきですが、保守期限が近いものや、他部署とのデータ連携が見込まれるもの（防災、観光等）は積極的に検討すべきです。ただし、移行コストと運用コストを天秤にかけた「投資対効果（ROI）」の精査は必須です。

9. まとめ：2025年度末を見据えた「持続可能な」設計を

ガバメントクラウドへの移行は、自治体にとって単なるシステム更新ではなく、「行政経営のデジタル化」そのものです。2025年度末の期限に向けて、以下の3点を改めて確認してください。

1. セキュリティの自律管理: 責任共有モデルを理解し、IAMやログ監視を自治体の主導で設計すること。
2. コストの継続監視: 予算超過を防ぐためのアラートと、ライトサイジング（最適化）を運用フローに組み込むこと。
3. データの利活用: 移行をゴールとせず、集約されたデータをいかに市民サービスの向上やEBPMに繋げるかのビジョンを持つこと。

デジタル庁の「ガバメントクラウド技術マニュアル」^[20]は随時更新されています。常に最新の一次情報を参照し、ベンダーと対等な立場で議論できる知見を蓄積していくことが、自治体DXの成功へと繋がります。