Amazon Web Services ブログ
デジタル庁様がAWS re:Invent 2025 で登壇「ガバメントクラウドで実現した俊敏性とコンプライアンスのバランス」
米国ラスベガスで2025年12月1日-5日に開催された AWS re:Invent 2025 では、デジタル庁様がユーザー事例ブレイクアウトセッションに登壇されました。
デジタル庁様の大規模かつ効率的な統制のあり方を説明したこのセッションの内容は日本の一般企業のガバナンスにも参考になるものと思います。
このブログでは日本のお客様向けに日本語でセッションの内容をご紹介します。英語ではありますが YouTubeに上がっているセッション動画もぜひご覧ください。
セッション概要
タイトル：
[COP349] Balancing Agility & Compliance feat. The Digital Agency of Japan（俊敏性とコンプライアンスのバランス – 日本のデジタル庁を迎えて）
セッション概要：
規制業界は、クラウドにおける厳格なセキュリティとコンプライアンス要件に対応しながら、俊敏性を持ってイノベーションを推進するという課題に直面しています。このセッションでは、日本政府が各省庁と1,700以上の地方公共団体にわたってクラウド導入のための集約型ガバナンスモデルを成功裏に実装し、5,000以上のアカウントをシームレスに管理できるようにした事例を学びます。AWS Control Tower、AWS Config、AWS Security Hubなどの AWS クラウドガバナンスサービスにより、規制業界や公共部門は運用を合理化し、ガバナンスを強化し、進化するコンプライアンス要件を満たして、中央制御と地方の自律性のバランスを取ることができます。
登壇者：
- デジタル庁, Chief Cloud Officer 山本 教仁 様
- AWS, World Wide Cloud Governance Principal Specialist Nivas Durairaj
- AWS Japan, Manager, Specialist Solutions Architect 大村 幸敬
AWSガバナンスのベストプラクティス
最初に AWS Cloud Governance Specialistの Nivas よりAWSにおけるガバナンスのベストプラクティスについて解説しました。
公共部門、ヘルスケア、金融業界といった機微な情報を扱う規制業種では、俊敏性とコンプライアンスという大きく２つのニーズがあります。俊敏性では、生成AIのようなイノベーションの活用、そして変化に追従して迅速に成果を出すことが求められます。コンプライアンスでは、セキュリティルールへの適合、および中央の管理者が統制しつつも多数の利用者（開発者）がスケーラブルに利用できることが求められます。
これを開発者と中央の管理者という観点で言い換えてみます。開発者は技術的な意思決定を自由に行って実験を繰り返せる環境を使って、イノベーションと迅速なリリースを実現したいと思っています。一方で中央管理者は運用効率化のために環境の標準化を求め、組織全体にわたってセキュリティとコンプライアンス統制の可視化を実現したいと思っています。
ここに、俊敏性とコンプライアンスという反対方向に働く緊張が発生することになります。この２つをAWS上ではどのようなバランスで実現するのか、というのがこのセッションのキーポイントです。
AWSではクラウドガバナンスを「組織がベストプラクティスに準拠するよう導く、ルール、プロセス、およびレポートの集合」と定義しています。
詳細はQRコードに示した、AWSのウェブサイトをご覧ください。
ベストプラクティスとしては、環境に関するベストプラクティス、コントロール（統制）に関するベストプラクティスの２つがあります。
環境のベストプラクティスはこの４つです。（詳細はセッション資料を参照してください）
- システムごとにアカウントを使用する（マルチアカウント管理を行う）
- アカウントの作成とカスタマイズを自動化する
- すべてのアカウントの活動を記録する
- 強力なID管理基盤を実装する
コントロール（統制）のベストプラクティスは次の3つです。（詳細はセッション資料を参照してください）
- コントロール（統制）の目的をセキュリティフレームワークに適合させる
- 予防的統制の前に発見的統制を適用する
- コントロールを継続的に監視しテストする
これらはベストプラクティスではありますが、規制業種の実際のシステムに適用することを考えた場合、多くの実装上の課題に直面することになります。ガバナンスの観点では、法律への適合方法、巨大な組織でもスケールする実装。俊敏性の観点では、アカウント作成とカスタマイズを誰が行うのか、利用者の認証方法、セキュアな基本設定を広く組織全体に展開する方法などです。
これらを実現した事例として、日本のデジタル庁によるガバメントクラウドを紹介します。
デジタル庁ガバメントクラウドの取り組み
ここから、デジタル庁 CCO 山本様に、ガバメントクラウドでの取り組みを紹介していただきました。
日本のデジタル庁は2021年に発足。コロナ禍の最中でした。コロナ禍ではワクチン接種の記録やワクチンの所在を短期間で確認することは当初困難でした。政府と社会のこういった課題をデジタルの力で解決することを目的としてデジタル庁が設立されました。以後４年間にわたってマイナンバーカードなどの施策を実現しています。ガバメントクラウドはこれらの施策の基盤となるものです。
ガバメントクラウドでは中央省庁だけでなく、地方公共団体や準公共領域の団体のシステムも稼働しており、急速に利用が増えています。2025年9月の時点で6,085アカウントが稼働しており、2025年は1ヶ月平均で370アカウントが増えています。
こういった急速なアカウント増加に対応するため、アカウントの追加や利用者のID追加作業の自動化は必須です。自動化以前では利用者の追加にかかるリードタイムは５営業日でしたが、現在は翌日までの追加が可能になっています。また利用者を１名追加することにかかるデジタル庁管理者の作業は30分から1時間であり、１ヶ月あたり370アカウントの追加であれば259時間を要する計算でした。しかし自動化によってこの作業量は現在ゼロを実現しています。
ガバナンス実現の文脈で、ガバメントクラウドがプラットフォームとして重要視すべき要素は3つあります。一つはもちろんガバナンスですが、日本の地方公共団体における固有の考慮として、地方の独立性（Local autonomy）があります。ガバナンスを実現するためには管理者であるデジタル庁が個々の環境を管理できたほうが効率的ですが、地方の独立性を重視する立場からは、デジタル庁が個々の環境を直接操作することはできません。さらに多数の自治体がガバメントクラウドを利用する場合でも、デジタル庁がそのボトルネックとなることなく俊敏性を提供するためには、スケーラビリティが必要となります。
この「ガバナンス」と「地方の独立性」そして「俊敏性とスケーラビリティ」の3つをバランスすることが、ガバメントクラウドにとって重要となります。
ガバメントクラウドの全体像がこちらです。ガバメントクラウドでは複数のクラウドサービスプロバイダー（CSP）を利用しており、利用者は個々のクラウド環境を直接利用することができます。提供するクラウド環境を払い出す機能や監査ログの記録やダッシュボードといった管理機能はユーザのクラウド環境の外側にあって、クラウド環境利用を阻害しないような構成となっています。これによって利用者はCSPが持つテクノロジをそのまま利用できるようにしています。このアーキテクチャは俊敏性とスケーラビリティを実現することに役立っています。
ガバナンスの実現にあたっては、法制面と技術面の両方から対応しています。法制面では日本法の下での日本政府と CSP との直接契約、データが日本に所在すること、そしてこれが適切に運営されていることを監査と ISMAP 認定で確認しています。技術面では利用者登録時にマイナンバーカードによる認証を行った上で、利用時は MFA で認証します。データは FIPS 140 認定の HSM （ハードウェアセキュリティモジュール）に格納された暗号キーで暗号化することができ、正しく認証したユーザのみが利用可能で、デジタル庁の管理者やCSPも含め外部からアクセスした場合でも読み取ることはできません。このようにして強固なガバナンスを実現していますが、同時に利用者の作成作業などは完全に自動化されており、俊敏性とスケーラビリティの両方を実現しています。
先に示したデータのガバナンスによって地方の環境の独立性も実現されることになります。すなわちデジタル庁の管理者であっても個々の自治体が持つAWSアカウントのデータにアクセスことはできません。さらに個々のアカウントに対してデジタル庁管理者が直接操作を行うことはなく、アカウントの作成や設定は全て自動化されています。またこの操作も毎年の監査を受けています。
アジリティとスケーラビリティ実現はここまでも述べてきましたが、さらに実際の環境における情報をガバメントクラウドとして管理しつつ、全てを自動化するための仕組みを導入しています。これは後ほど技術詳細と共に再度ご説明します。
ガバメントクラウドではマルチクラウド戦略をとっていますが、これは次の３つの戦略に基づいています。（詳細はセッション動画をご覧ください）
- 1つのシステムは1つの CSP で動作させる（複数のCSPを跨がない）
- 複数のクラウドを統合的に管理するシステムは使用しない
- データとプログラムの移行可能性を考慮する（ポータビリティの高いコンテナを採用するなど）
山本さんから最後にガバメントクラウドにおける AI の活用について説明がありました。日本は AI を活用し、ガバメント AI を準備するというポリシーを掲げています。デジタル庁の AI クラウド環境はその基礎となる予定とのことです。
デジタル庁でのベストプラクティス実現方法
最後のパートでは、ガバメントクラウドの実装をサポートした、AWS Japan のソリューションアーキテクト マネージャー 大村から技術的な実装の詳細について解説しました。冒頭 Nivas が提示したベストプラクティスからガバメントクラウド実装のキーとなった４つを取り上げました。
１つ目に取り上げるベストプラクティスは「コントロール（統制）の目的をセキュリティフレームワークに適合させる」です。
デジタル庁ではプリンシプル・ベース・アプローチ（原則主義アプローチ）により、法律から規制、そしてガイドラインへと抽象度の高い要求を徐々に具体化しています。これらのガイドラインをNIST CSFやNIST SP800-53といったフレームワークやコントロールカタログを参照して具体的な管理策にマッピングすることで、実装に落とし込めるようにしています。
さらに、ガバメントクラウドでは、これらのコントロールを実現するにあたり「運用効率を損なうことなく、適切なセキュリティ対策を実現する」という目的を掲げています。そのため、予防的統制は最小限とし、主に発見的統制を使ったガバナンスを実装する方針としています。予防的統制の実装には AWS Organizations の Service Control Policy を使用して特定の操作そのものをできないようにしています。発見的統制の実装には AWS Security Hub CSPM を使用して、操作自体を制限するのではなく、設定内容に統制からの逸脱がある場合、迅速に検出できるようにしています。これは AWS Config が構成情報を記録していることで実現できています。Security Hub CSPM には CIS ベンチマークや、 AWS Foundational Security Best Practice といったスタンダードがすでに用意されており、これらは NIST SP800-53 等のフレームワークとマッピングされています。これによって発見的統制の実装が容易になっています。
２つ目に取り上げるベストプラクティスは「強力な ID 管理基盤を実装する」です。
ガバメントクラウドでは数千もの利用者やアカウントを管理する必要があり、高いセキュリティを維持しつつスケーラブルに運用するためには、強力な認証基盤とその自動化が重要です。山本さんが紹介されたように、利用者登録の際の認証はマイナンバーカードで自動化しています。これにより当初手動で5日間かかっていたリードタイムを翌日（１日）へと劇的に短縮しました。さらに IAM Identity Center (IIC) では利用するゲストアカウントにアクセスするための権限を Permission Set で設定しますが、個々の利用者、アカウントごとにこれを作成すると設定の管理対象が膨大になり、サービスクォータ（上限）に抵触する可能性もあります。そこで、管理者と非管理者という２つの Permission Set だけを使うシンプルな実装を行っています。管理者権限は IAM ロールの作成が可能で（予防的統制により IAM ユーザの作成は禁止しています）、非管理者権限はロールの切り替えのみが可能である、という仕組みです。これにより利用者が個々のアカウントで必要なロールを作りつつも、IIC の Permission Set 数が爆発的に増えることのない仕組みを実現しています。
３つ目に取り上げるベストプラクティスは「アカウントの作成とカスタマイズを自動化する」です。
まず初回のみのアカウント設定について説明します。
利用者がAWSアカウントを作成したい場合は GCAS (Government Cloud Assistant Service) というデジタル庁が開発したポータルからリクエストします。アカウント作成自体は AWS Control Tower が行い、アカウントの並列作成をサービス上限以下にコントロールするための Amazon SQS 、そして初期設定手続きを定義する AWS Lambda 関数を、AWS Step Functions ワークフローで繋ぐ形で実現しています。Control Tower には Account Factory Customization という AWS Cloud Formation を使ったアカウント初期設定の仕組みがあります。Cloud Formationのような Infrastructure as Code は「あるべき状態（設定）」を定義するのに適しています。しかしガバメントクラウドで行う初期設定作業には、エンタープライズサポートへの登録などAPIしか利用できない操作も多く、そのような「手続き」を定義するには Lambda 関数の方が適しています。さらに、アカウント作成では自治体名や支払い用メールアドレスといった、AWS の設定とは関係のない実世界の情報も管理する必要があります。これらは GCAS 上のデータベースに登録し、ここでも手動での管理を排除しています。このようにアカウント作成時の初回設定を完全に自動化しています。
利用者のアカウントにはセキュリティの基本設定である「セキュアベースライン」を展開します。これは展開後も継続してメンテナンスする必要があるため「あるべき状態」を定義する Infrastructure as Code が適しています。ガバメントクラウドでは CDK を使用してセキュアベースラインを定義しています。このデプロイは、AWS Service Catalog を使った「Pull（引っ張る）スタイル」でおこないます。これはデプロイ対象であるセキュアベースラインをデジタル庁管理者が Service Catalog の Product として作成し、デプロイは地方公共団体の管理者が自ら（引っ張ってきて）行うやり方です。Pullスタイルの対義語は「Push（押す）スタイル」ですが、これは Cloud Formation StackSet のような、中央の管理者が全ての環境にデプロイするやり方を指します。ガバメントクラウドで Pull スタイルを採用した理由は、一つは管理の独立性の考えに基づき、デジタル庁管理者が地方公共団体などのアカウントにアクセスしないようにする必要があったことです。もうひとつの理由は、Push スタイルの場合、セキュアベースラインをアップデートする際にデジタル庁管理者が地方公共団体管理者と実施タイミングや設定内容を調整する必要があり、デジタル庁管理者の運用がスケールしないためです。Pull スタイルであることで、デジタル庁管理者は Service Catalog の Product を更新するだけでよく、地方公共団体管理者は自らの都合のよいタイミングで、自らの環境の状態を理解した上で、更新を実施することができます。これもまたスケーラブルなセキュアベースライン実現のために必要な仕組みです。
最後に取り上げるベストプラクティスは「コントロールを継続的に監視しテストする」です。
ガバメントクラウドでは、地方公共団体のアカウントで発生したセキュリティイベントは直接地方公共団体の管理者へ通知され、管理者が自ら修正する責務があります。これはセキュアベースラインに設定された Amazon EventBridge と AWS Chatbot によって実現しています。これもデジタル庁管理者を介することなく対応する仕組みによって、管理の独立性とスケーラビリティを実現しています。一方でデジタル庁管理者は多数のアカウント全体の統制について、その統制の状況を把握する必要があります。これは AWS Security Hub CSPM のレポートによって実現しており、少数の、特に注意が必要なセキュリティイベントについては、デジタル庁管理者が定期的にチェックを行い、必要に応じて改善提案を行っています。このようにして、多数のアカウントを対象にしていてもセキュリティイベントが適切に対応される仕組みを実現しています。
まとめ
このセッションでは、日本の中央省庁や地方公共団体という現実の世界のシステムを管理する上で、ガバメントクラウドがガバナンスと俊敏性を両立させるためにどのように考え、実装しているのかを紹介しました。また、それがAWSのベストプラクティスにも適合していることをご紹介しました。
会場には日本の方も多くご参加いただき、登壇後に質疑応答もいただきました。ご来場いただきありがとうございました！
著者：大村幸敬 (AWS Japan, Manager, Solutions Architect)