ガバメントクラウドが「セキュア」と言える根拠はどこにあるか

「ガバメントクラウドはセキュアだから安心」という認識は、ある意味で正しく、ある意味で危険な誤解を含んでいます。デジタル庁が整備するガバメントクラウドには、クラウドサービス事業者（CSP）に対して可用性99.99%・国内データ保管・ISMAP登録という厳格な技術要件が課されています（出典: デジタル庁「2025年度公募に向けた検討状況」2025年11月）。

しかしながら、そのセキュリティの「恩恵」をどこまで受けられるかは、自治体側の対応次第です。本記事では、一次ソースに基づいて「ガバメントクラウドのセキュリティが担保される仕組み」と、「自治体が自ら対応しなければならない7つの要件」を整理します。

---

ガバメントクラウド調達のセキュリティ要件（CSP側）

ガバメントクラウドに採択されるクラウドサービスは、デジタル庁が定める以下の技術要件をすべて満たす必要があります。

要件	内容
可用性	稼働率99.99%以上を保証
データ保管	データは日本国内のデータセンターに保管
クラウドセキュリティ	ISMAPに登録されていること
災害対策	地理的に離れた日本国内の複数リージョンにDCを設置
暗号化	暗号鍵の生成・保管・使用が可能なHSM（ハードウェアセキュリティモジュール）を整備
アクセス制御	CSPは利用者の情報にアクセスできないよう制御
人材育成	クラウド技術人材のトレーニング体制と資格制度を保有

（出典: デジタル庁「2025年度ガバクラ調達方針（案）」2025年11月）

現在のガバメントクラウド採択事業者はAWS・Google Cloud・Microsoft Azure・Oracle Cloud Infrastructure（OCI）・さくらのクラウドの5サービスです（2026年3月時点）。これらはすべてISMAP登録済みです。

---

責任共有モデルを正しく理解する

ガバメントクラウドのセキュリティで最も重要な概念が責任共有モデルです。従来のオンプレミス環境では、ハードウェア・OS・ミドルウェア・アプリケーション・設備・運用まで、すべてのセキュリティ対策を自治体側で検討する必要がありました。

クラウドではこの責任範囲が以下のように分担されます。

flowchart TD
    A["CSP責任範囲\n物理設備・ハードウェア\nネットワーク基盤・ハイパーバイザー\nISMAP登録で担保済み"]
    B["自治体責任範囲\n業務アプリケーション\n利用者端末・IAM設定\nクラウド利用設定・データ保護"]
    C["共同対応\nネットワーク接続設計\nログ管理・監視体制\nインシデント対応手順"]

    A --> C
    B --> C

デジタル庁の「政府情報システムのクラウドサービス利用に係る基本方針」では、ISMAP登録済みのクラウドについては「クラウドが提供する部分のセキュリティレベルを利用システムが特に検証を行う必要はない」としています（出典: デジタル庁 クラウドサービス利用基本方針）。

つまり、CSPが提供するインフラ側は信頼できる前提として扱えますが、業務アプリケーション・IAM（アクセス制御）・クラウド設定・端末管理は引き続き自治体側の責任です。

---

自治体が対応すべき7つのセキュリティ要件

上記の責任共有モデルを踏まえ、自治体がガバメントクラウド移行時に対応すべき要件を7つに整理します。

要件1: セキュリティポリシーの策定・公表

総務省が2025年3月に改定した「地方公共団体における情報セキュリティポリシーに関するガイドライン」では、2026年4月1日までに「サイバーセキュリティ基本方針」を策定・公表することが義務化されました。ガバメントクラウドへの移行と同期して、セキュリティ体制の明文化が求められています（出典: 総務省 情報セキュリティポリシーガイドライン 2025年3月改定）。

要件2: マイナンバー利用事務系の分離対応

標準準拠システムをガバメントクラウド上に構築する場合、マイナンバー利用事務系（住民基本台帳・個人番号利用事務等）の端末・サーバと専用回線で接続されるクラウド上の領域については、引き続きマイナンバー利用事務系として扱う必要があります。これは、いわゆる「三層分離」の考え方がガバメントクラウド移行後も部分的に維持されることを意味します（出典: 総務省「地方公共団体情報システム標準化基本方針」改定案 2024年12月）。

要件3: IAM（アクセス制御）の適切な設定

責任共有モデルにおいて、クラウド利用における設定（IAMポリシー・アカウント管理等）は自治体側の責任です。具体的には以下の対応が必要です。

• 最小権限の原則に基づくIAMポリシー設定
• 管理者アカウントのMFA（多要素認証）有効化
• サービスアカウントへの不要な権限付与の禁止
• アクセスログの定期的な監査

要件4: クラウドリファレンスアーキテクチャへの準拠

デジタル庁のGCASガイドでは、ガバメントクラウド利用システムに対して「クラウドのリファレンスアーキテクチャベストプラクティスに準拠した最新の対策を行うこと」を原則としています。オンプレミス時代のセキュリティ対策をそのままクラウドに持ち込むことは推奨されず、各CSPが提供するリファレンスアーキテクチャ（AWS・Azure・Google Cloud・OCIそれぞれに提供）を参照した設計が求められます（出典: GCASガイド セキュリティ対策（共通））。

要件5: 三層対策からの移行計画の策定

従来の「三層分離（マイナンバー利用事務系・LGWAN接続系・インターネット接続系の分離）」は、ガバメントクラウドへの移行に伴って抜本的な見直しが進められています。デジタル庁・総務省は「将来的にはゼロトラストアーキテクチャに基づくネットワーク構成に対応するよう検討を進める」としており、三層からゼロトラストへの段階的移行が自治体の中期的な課題となります（出典: 総務省「自治体DX推進計画 第2.2版」2023年12月）。

要件6: ゼロトラストアーキテクチャへの対応検討

2026年3月、デジタル庁は「国・地方ネットワーク ゼロトラスト実証事業」の結果を公表しました。この事業では、札幌市（人口約200万人）からすさみ町（人口約3,000人）まで規模の異なる4団体でゼロトラスト環境の検証が行われ、「三層分離では巧妙化するサイバー攻撃への対応に限界がある」という問題意識が確認されました（出典: デジタル庁「国・地方ネットワーク ゼロトラスト実証」2026年3月）。

ゼロトラスト実装に向けた主な考慮事項は以下の通りです。

観点	内容
リスク	防御の焦点がネットワーク境界からID・データに移行する。主なリスクはID不正利用とポリシー設定ミス
コスト	既存システムへの認証実装または新規開発が必要。内製人材育成または外注コストが発生
段階的対応	短期間での全システム対応は困難。規模・財政状況に応じた段階的移行計画が現実的
リファレンス	肝付町（鹿児島県）の先行事例がリファレンスモデルとして公開されている

要件7: インシデント対応体制の整備

ガバメントクラウドへの移行後も、個人情報の漏えい等が発生した場合の本人への通知・報告義務は自治体が負います。クラウド移行前に以下の体制を整備しておく必要があります。

• CSIRT（情報セキュリティインシデント対応チーム）または担当者の明確化
• インシデント発生時のCSPへの通報フロー確認
• 個人情報保護委員会への報告手順の整備
• 庁内連絡体制（首長・総務・IT担当）の確立

---

ISMAPとは何か：ガバメントクラウドの「信頼の基盤」

ISMAPは「政府情報システムのためのセキュリティ評価制度」（Information system Security Management and Assessment Program）の略称で、政府が定めるセキュリティ要求を満たすクラウドサービスを評価・登録する制度です。ガバメントクラウドに採択されるサービスはすべてISMAP登録が必須要件とされています。

ISMAP登録の意義は「自治体がクラウドのインフラ側セキュリティを個別に検証しなくてよい」という点にあります。ただし、ISMAP登録はあくまでクラウドの物理・ネットワーク層の評価であり、業務アプリケーション層の安全性は評価対象外です。

2025年以降、ISMAP管理基準も改訂が継続されており、最新のガイドラインへの追従が必要です。

---

三層分離とゼロトラストの違いを整理する

現在の自治体セキュリティの転換点を理解するために、従来の三層分離とゼロトラストの違いを整理します。

項目	三層分離（従来）	ゼロトラスト（移行先）
基本思想	ネットワークを物理的に分離してリスクを遮断	「全てを信頼しない」。すべてのアクセスを都度検証
防御の焦点	ネットワーク境界	ID・データ・アプリケーション
クラウドとの親和性	低（物理分離前提のため）	高（クラウドネイティブな設計と一致）
テレワーク対応	困難（専用端末・専用回線が必要）	容易（認証ベースで場所を問わずアクセス可）
移行コスト	既存インフラが前提のため追加コスト小	認証基盤・監視体制の新規構築が必要
自治体対応状況	ほぼ全自治体が実施中	先行自治体での実証段階（2026年時点）

この転換は、ガバメントクラウドへの移行と並行して段階的に進められます。2026年度時点では、ゼロトラストへの完全移行を自治体に即座に求めているわけではありませんが、移行計画の策定と先行事例の学習が重要なステップとなります。

---

FAQ: 自治体IT担当者からよくある質問

Q1. ガバメントクラウドに移行したら、自治体のセキュリティ担当者は何をすればよいですか？

ガバメントクラウド移行後は、物理インフラのセキュリティ管理からは解放されます。代わりに、IAM設定・クラウド利用設定・アプリケーション層のセキュリティ・端末管理が主な対応範囲となります。GCASガイドが提供するリファレンスアーキテクチャを参照し、各CSP推奨の設定を適用することが推奨されています（出典: GCASガイド）。

Q2. マイナンバー利用事務系は引き続き分離が必要ですか？

はい。標準準拠システムがガバメントクラウド上に構築される場合でも、マイナンバー利用事務系の端末・サーバと専用回線で接続されるクラウド上の領域は「マイナンバー利用事務系」として扱います。三層分離の完全廃止ではなく、段階的な移行が想定されています（出典: 総務省「地方公共団体情報システム標準化基本方針」改定案）。

Q3. 小規模自治体でもゼロトラスト対応は必要ですか？

現時点（2026年度）では、ゼロトラストへの即時対応を全自治体に義務付ける制度はありません。デジタル庁の実証事業では、すさみ町（人口約3,000人）のような小規模自治体での実装可能性も検証されており、将来的な方向性は明確です。当面は三層分離の適切な運用を維持しつつ、ゼロトラスト移行の情報収集・計画策定を進めることが現実的な対応です（出典: デジタル庁「国・地方ネットワーク ゼロトラスト実証」2026年3月）。

Q4. サイバーセキュリティ基本方針の策定期限（2026年4月）が迫っています。何から始めればよいですか？

総務省の2025年3月改定ガイドラインを参照し、自団体のセキュリティポリシーをガバメントクラウド移行後の責任範囲に合わせて見直すことが出発点です。既存のポリシーがオンプレミス前提で書かれている場合、責任共有モデルに対応した形への改訂が必要です（出典: 総務省 情報セキュリティポリシーガイドライン 2025年3月改定）。

---

GCInsightで自団体のセキュリティ対応状況を確認する

ガバメントクラウドへの移行進捗や各自治体の対応状況は、GCInsight（gcinsight.jp）で確認できます。移行の遅延リスクや業務別の移行状況を可視化しており、セキュリティ対応と合わせた移行計画の立案に活用できます。

• 移行遅延リスク一覧 — 移行が遅延している自治体の状況
• クラウド別ベンダー情報 — 各CSPのセキュリティ機能・特徴
• 都道府県別進捗 — 自団体と近隣自治体の比較

---

まとめ: ガバメントクラウドのセキュリティは「折半」である

ガバメントクラウドのセキュリティを一言で表すなら「責任の折半」です。デジタル庁・CSPが整備するインフラ基盤（ISMAP登録・国内データ保管・高可用性）と、自治体が整備するアプリケーション・IAM・端末管理・体制面が組み合わさって初めて、真に安全なシステムが実現します。

2026年度の移行期限を前に、自治体IT担当者には以下のアクションが求められます。

1. 責任共有モデルの理解と庁内での共有
2. 2026年4月のサイバーセキュリティ基本方針策定・公表
3. マイナンバー利用事務系の分離設計の確認
4. IAM設定・アクセスログ監査体制の整備
5. ゼロトラスト移行に向けた情報収集・計画立案の開始

ガバメントクラウドのセキュリティは「移行すれば終わり」ではなく、継続的な対応が求められるテーマです。GCInsightは自治体のガバメントクラウド移行を支援する情報を継続的に提供します。

---

参考文献・出典

• デジタル庁「ガバメントクラウド」政策ページ
• デジタル庁「GCASガイド セキュリティ対策（共通）」
• デジタル庁「政府情報システムのクラウドサービス利用に係る基本方針」
• デジタル庁「国・地方ネットワーク ゼロトラスト実証事業報告」2026年3月
• デジタル庁「国・地方ネットワークの将来像及び実現シナリオに関する検討会報告書」2024年5月
• 総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」2025年3月改定
• 総務省「自治体DX推進計画 第2.2版」2023年12月
• 総務省「地方公共団体情報システム標準化基本方針（改定案）新旧対照表」2024年12月
• ISMAPポータル 制度案内