【AWS re:Invent 2025】Balancing Agility and Compliance feat. The Digital Agency of Japan (COP349) 参加レポート

本稿では、AWS re:Invent 2025 で開催された、Balancing Agility and Compliance feat. The Digital Agency of Japan (COP349) の参加レポートになります。

誰か時差ボケに効く薬をください。
内村でございます。

ただいま、アメリカはネバダ州のラスベガスで開催されている AWS re:Invent 2025 に参加しています。
私が唯一予約していた Breakout Session の Balancing Agility and Compliance feat. The Digital Agency of Japan (COP349) について纏めました。
AWS アカウントの管理や、安全性、可用性などの課題を抱えられている方のためになれますと幸いです。

内容についての諸注意
セッション概要
セッション全体のストーリー
Nivas Durairaj
Norihito Yamamoto（デジタル庁 CCO）
Yukitaka Ohmura（AWS Japan SA）
最近のガバナンス系ローンチ
最後に

内容についての諸注意

当記事は 2025年12月時点で調査した製品、サービス内容を記載しています。最新の情報に関しては各種公式サイト、マニュアル等をご確認下さい。
当記事作成の際には十分注意しておりますが、内容に公式と相違がある場合は公式を優先とさせていただきます。
当記事内の試算およびそれに準ずる内容は、本資料の説明のために用いるものであり、不利益が生じた場合、一切の責任は負いかねますので予めご了承ください。

セッション概要

タイトル
- Balancing Agility and Compliance feat. The Digital Agency of Japan（COP349）
登壇者
- Nivas Durairaj – WW Cloud Operations Specialist, AWS
- Yukitaka Ohmura – Manager, Specialist Solutions Architect, AWS Japan
- Norihito Yamamoto – Chief Cloud Officer, Digital Agency（日本デジタル庁）

30 省庁・1,700 自治体・5,000 以上の AWS アカウントという超大規模な公的機関を対象に、「中央集権的なガバナンス」と「現場の俊敏性・自治」をどう両立させるか、をテーマにしたセッションです。

セッション全体のストーリー

大きく 3 パート構成でした。
（敬称略）

Nivas Durairaj
- 「クラウドガバナンスとは何か」「アジリティとコンプライアンスは対立ではなく両立させるもの」
  - → AWS Organizations / AWS Control Tower / AWS Config / AWS Security Hub などを使った教科書的ベストプラクティス
- クラウドガバナンスの基本設計
Norihito Yamamoto（デジタル庁 CCO）
- コロナ禍での「デジタル敗戦」を踏まえたデジタル庁設立の背景
- マイナンバーカードと Government Cloud（政府共通クラウド）の位置づけ
- 『ガバナンス』『地方自治（ローカル・オートノミー）』『スケーラビリティ』という 3 つの目的をどう両立したか。
Yukitaka Ohmura（AWS Japan SA）
- デジタル庁の事例を一般化した「4 つのクラウドガバナンスベストプラクティス」
- その上で、最近のガバナンス系新機能ローンチの紹介（Account Transfer, Billing Transfer, Control Tower Controls only など）。

Nivas Durairaj

「アジリティ vs コンプライアンス」ではなく『両方』が必要

開発チーム
- 新しいサービス（特に Generative AI / Agentic AI）を素早く試したい
- 裁量と実験の自由度を求める
中央運用・セキュリティチーム：
- 組織全体での標準化・スケール
- 法規制・スタンダードへの準拠を担保したい

表面上はベクトルが逆を向いているように見えるが、ガードレールで “やっていい範囲” をはっきりさせ、そこは全力で走れるようにするというのがポイント。

AWS 的「クラウドガバナンス」の定義と Landing Zone

「ルール・プロセス・レポートのセットであり、ビジネス要件に沿った形でクラウド基盤を導くもの」
実装の出発点
- AWS Organizations ＋ AWS Control Tower による multi-account Landing Zone
- Identity Center 統合（SSO）
- Log Archive アカウントへの CloudTrail / Config ログ集中
- Audit / Security アカウントに Config Aggregator 等を配置
ベストプラクティス
- アカウントを“最小の単位（building blocks）”として使う
- アカウントプロビジョニングは自動化／標準化
- アクティビティログと設定変更ログを必ず中央集約
- 強いフェデレーション（IdP 連携）を前提にする

3種類のガバナンスコントロール

Preventive（予防）
- Service Control Policies（SCP）
- Resource Control Policies（RCP：S3 / KMS / Secrets Manager のデータパーミッションを上限管理）
- Declarative Policies（VPC / EC2 / EBS の望ましい設定を宣言的に強制）
Proactive（事前チェック）
- CI/CD や IaC デプロイ前に設定を検査
- 「Shift-left」による品質・コスト最適化
Detective（検知）
- AWS Config（Conformance Pack＋Aggregator）
- Security Hub（CIS, Foundational Security Best Practices など）

端的に纏めると、
「いきなり Preventive をガチガチにかけない」
「まず Detective で “現状どれだけ非準拠なのか” を把握してから段階的に締める」

Norihito Yamamoto（デジタル庁 CCO）

デジタル庁 Government Cloud の実例

背景とスケール

コロナ禍で、紙と手作業の限界（ワクチン接種状況の把握など）が表面化
- 「デジタル敗戦（digital defeat）」という言葉が出るほどの状況に
2021年9月にデジタル庁創設
マイナンバーカード：約 1 億人（人口の 80%）が保有。医療・税・各種情報が連携
Government Cloud
- 中央省庁だけでなく、1,700 の地方公共団体や準公的組織が利用
- AWS アカウントは 6,000+、毎月 300〜400 アカウント新規作成

この規模を人手の運用で回すのは不可能なので、アカウント払い出しはフル自動化が必須

Before
- アカウント発行まで平均 5 営業日
- 1 アカウントあたりの作業：作成 30 分＋複数アカウントに関連する事前作業が数十時間規模
After（i.e. 自動化後）
- 申請の翌日からクラウド利用可能
- アカウント作成に関わる手作業工数はほぼゼロに

3 つの目的：『Governance』『Local Autonomy』『Scalability』

Government Cloud は次の 3 つを同時に満たす必要がある。

Governance（統治・統一されたセキュリティ／コンプライアンス）
Local Autonomy（地方自治体の独立性・自律性）
Scalability（数千アカウントを継続的に増やせる拡張性）

これらは本来トレードオフ関係に見える、
but, 設計を工夫することで同時に成立させている、というのがこの話の肝。

Governance：制度面と技術面

「ガバナンス」は「2層構造」として説明されていました。

制度面（Institutional）
- データは日本国内で保存
- 政府と CSP（AWS）が直接契約（Japanese law ベース）
- ISMAP などのクラウド認証・監査を前提に、法令・契約に基づいた運用が担保されている
- → 法律面・契約面で「主権性」「国内管理」を確保している、というメッセージ
技術面（Technical）
- データは利用者自身の KMS キーで暗号化
- キーは FIPS 140 認証 HSM に格納
- キーオーナーはマイナンバー＋MFA で強固に認証される
- デジタル庁職員も CSP も、暗号化をバイパスしてデータを見ることはできない設計
- 「制度（契約・法）と技術（暗号化＋鍵管理）の両方でガバナンスを担保」かつ、この仕組みはスケーラビリティに大きな悪影響を与えない（暗号化処理以外はボトルネックを作らない）

Local Autonomy：地方自治体の独立性の担保

ローカル政府の環境には『事前定義された自動化プロセスのみ』がアクセス可能
デジタル庁職員は、基本的に地方自治体のアカウントに直接ログインできない
管理アカウントにアクセスする場合も、定められた手順と監査が必須で、そのプロセス自体が毎年監査対象になる

すなわち、「地方自治体の環境は、クラウド事業者や中央政府からも技術的・運用上独立している」というローカル・オートノミーを強調。

Scalability：現実世界の組織構造とのマッピング

AWS Organizations の OU 構造だけでは、現実の組織階層・責任分担をそのまま表しきれない（現場の組織構造はもっと複雑）

そこで

AWS Organizations は AWS のベストプラクティス（SCP 構造など）に従って設計
現実世界の組織構造とは、独自の管理システム（GCAS: Government Cloud Assistance Services）でマッピング

GCAS とは？その役割

アカウント申請・管理のポータル（＝いわゆる“自販機” UI）
組織名・担当者メールアドレスなど「現実世界の情報」のマスタ管理
請求情報の可視化ダッシュボード等も提供

すなわち、「クラウドのガバナンス構造（AWS Orgs）」と「現実世界の組織構造」を分離し、その間を GCAS が橋渡しすることで、スケーラブルな運用を実現。

マルチクラウド戦略の方針

とくに印象深かったのが、ここ。
マルチクラウドに関する 3 つのルールです。

1 つの一体的なシステムを複数クラウドに分割しない
- 可用性や冗長化のためなら、1 つの CSP 内でリージョン・AZ を分けるべき
- マルチクラウド分割はコスト増・オペレーションの複雑化を招く
『1 つの運用組織は、基本 1 つの CSP を担当』
- 1 チームで複数クラウドをフルカバーしようとすると、スキル習得・知識蓄積が倍々ゲームで増える
『データポータビリティは重要だが、コアアプリはコンテナなどポータブルな形を優先』
- FaaS（例：Lambda）だけに強く依存した設計よりも、コンテナで中立性を担保する方針

Yukitaka Ohmura（AWS Japan SA）

ここが、他のお客様にもそのまま使える、参照できる箇所。
4 つのベストプラクティスをご提示。

Best Practice 1：セキュリティフレームワークと目的を紐づける

法律（サイバーセキュリティ基本法等）
政府向け統一基準（NISC の統一基準）
デジタル庁の「セキュリティ・バイ・デザインガイドライン」

これらを、「NIST CSF」「NIST SP 800-53」などのフレームワーク／コントロールカタログにマッピング。

AWS 側の実装
- Preventive：SCP は最小限（例：IAM ユーザーや Access Key 作成禁止など）
- Detective：Security Hub の CIS / AWS Foundational Security Best Practices を活用して標準コントロールを実装

ポイント。

いきなり SCP でガチガチにせず、まず Detective で状況把握
コントロール目的をフレームワークと紐づけることで、監査・説明がしやすくなる

Best Practice 2：強固なアイデンティティ基盤

課題
- ユーザー作成に 5 日かかる
- 数千ユーザーを IAM Identity Center で扱う必要がある（permission set 上限 3,500 など）
アプローチ
- マイナンバーカードを用いた独自認証基盤を GCAS 上に構築
- これにより、ユーザー作成リードタイムを 5 日 → 約 1 時間に短縮

IAM Identity Center について。

Permission set を「Admin」と「Non-admin（SwitchRole 専用）」の 2 種類に絞る
Admin ユーザーはアカウント作成時に Admin ロールを持ち、その権限で現地の Developer / Operator ロールを作成
IAM ユーザーは原則禁止、すべてフェデレーション＋ロールベースに統一

シンプルなモデルに割り切ることで、数千ユーザー規模でも運用可能になる。

Best Practice 3：アカウントプロビジョニングとカスタマイズの自動化

ユーザー → GCAS からアカウント申請
GCAS → Step Functions → SQS → Lambda → Control Tower の流れで自動でアカウント作成
- Control Tower の同時アカウント作成制限（最大 5 つ）の考慮
- Enterprise Support の有効化など、CloudFormation では難しい処理を Lambda で実装

GCAS は、現実世界の情報（自治体名／請求先／連絡先など）も保持し、アカウントに紐づけて管理する。

Baseline 配布モデル（Push ではなく Pull）
- デジタル庁が直接各アカウントに CloudFormation を「押し込む」ことはしない（ローカル・オートノミーのため）
代わりに
- Service Catalog の Product として「セキュアベースライン（プロトタイプデプロイ）」を提供
- 自治体の Admin がその Product を選んで自分のアカウントにデプロイ
- ベースライン更新時も、Product のバージョンを上げれば、各自治体が自分のタイミングで新バージョンを適用

中央と現場の調整コストを減らしつつ、セキュアなベースラインを届ける仕組み。

Best Practice 4：コントロールの継続的モニタリング＆テスト

セキュリティイベントの一次対応責任は、各ローカル政府の管理者にある設計
Baseline の一部として
- EventBridge ルール＋通知機構（おそらく SNS / ChatOps など）を事前に展開
- Security Hub からのフィンディングを各アカウントの Admin に直接通知
デジタル庁側は？
- Security Hub からのレポートで、Government Cloud 全体のポスチャを把握
- クリティカルなイベントのみ抽出し、必要に応じて自治体に連絡

「アラートの分散処理（中央に全部集めない）＋定期的な全体ヘルスチェック」でスケーラブルにセキュリティを維持するモデル。

最近のガバナンス系ローンチ

最後に Nivas から。
アップデートの紹介。

Account Transfer
- アカウントを別 Organizations に移す際、これまで必要だった「一旦スタンドアロン化してクレジットカード紐づけ」プロセスが不要に
AWS Billing Transfer
- 複数 Organizations をまたぐ環境でも、請求情報を中央に寄せて分析可能に
- ただしセキュリティ管理はあくまで各 Org 単位
AWS Control Tower – Controls only モード
- 既に自前 Landing Zone を持っているお客様でも、Control Tower のコントロール群（SCP / RCP / Config ルールなど）だけを横取りして使える