はじめに
今回、AWS re:Invent2025で生成AIを活用してAWSのガバナンス作業を自動化するセッション「Building and validating cloud controls with generative AI（COP350）」に参加してきました。
デモ中心で実践的な内容だったので、紹介します。
ガバナンスの課題
セッションでは、架空のクラウドオペレーションエンジニア「Nita」が300以上のAWSアカウントを管理するシナリオが紹介されました。彼女のチームが抱える課題は、まさに私たちと同じでした。
- スケールでの一貫性: アカウントが増えるほど、一貫したコントロールの維持が難しい
- リアクティブなガバナンス: 問題を検出できても、予防する仕組みが弱い
- アカウントカスタマイズの負荷: Control Tower Account Factoryでアカウントは作れるが、カスタマイズに時間がかかる
使用されたツール群
デモで使用されていた構成は以下の通りです。
| ツール | 役割 |
|---|---|
| Kiro CLI | Kiroのターミナル版。Amazon Q Developer CLIの技術（エージェントモード、MCP、ステアリング等）を基盤としており、Q CLIのリブランド・後継版として位置づけられる。 |
| MCP サーバー | AWS Knowledge、AWS API、CloudTrailなどをエージェントに接続 |
| Knowledge Base | SRAやConfigルールのドキュメントをインデックス化 |
| CFCT | Control Towerアカウントへのカスタマイズ自動適用パイプライン |
特に面白かったのがMCPサーバーの「ロール」という概念です。Solutions ArchitectやFoundationといったロールを指定すると、そのユースケースに必要なMCPサーバー群がまとめて読み込まれます。
{
"env": {
"aws-foundation": "true",
"solutions-architect": "true"
}
}
ロールとMCPサーバのマッピングは以下のページを確認できます。
これでKnowledge、AWS API、Pricing、Cost Explorer などのMCPサーバーにアクセスできるようになります。
さらに、ナレッジベースに対してインテリジェント検索やセマンティック検索を実行できるように、最適なインデックスタイプを使用してナレッジベースのインデックスを作成しています。
デモ1: Config Organization Ruleの作成
やりたいこと
「アカウント内でパブリックIPアドレスを使用して起動されたEC2インスタンスを検出するのに役立つAWS Configルールを作成」
実際のプロンプト
エージェントの動き
- Knowledge Baseを検索してマネージドルールを探す
-
EC2_INSTANCE_NO_PUBLIC_IPを発見 - CloudFormationテンプレートを自動生成
- デプロイ用シェルスクリプトも作成
- デプロイ実行
失敗からの自動リカバリが凄い
ここからが面白いところ。デプロイが失敗しました。
普通なら CloudFormation のイベントを見に行って、エラーを特定して、テンプレートを修正して...という作業が必要ですが、Kiroは違いました。
- CloudFormationスタックイベントを自動解析
- 「Organization Config Ruleはルール名を返す。ARNじゃない」という問題を特定
- テンプレートを自動修正
- 失敗したスタックを削除
- 再デプロイ
2回目も失敗（frequencyパラメータの問題）しましたが、3回目で成功。全部自動です。
最後に Config Aggregator から非準拠インスタンスをクエリして、2アカウントで3インスタンスが違反していることを確認するところまで、ターミナルから出ずに完結しました。
デモ2: Shift Left戦略の実装
Shift Leftとは
従来、コンプライアンスチェックは「デプロイ後に検出」が主流でした。Shift Leftは、これを開発ライフサイクルにおいて早い段階で検出し、修正させる考え方です。
| コントロール種別 | タイミング | AWSでの実装 |
|---|---|---|
| Detective（検出） | デプロイ後 | AWS Config Rules |
| Preventive（予防） | API呼び出し時 | SCP / RCP |
| Proactive（先制） | デプロイ前 | CloudFormation Guard Hook |
デモの流れ
-
違反の多いConfigルールを特定
→ KMSキーのタグ付けルールとLambdaのX-Rayトレースが有効になってないLambda関数を特定
-
Shift Leftコントロールを自動生成
- KMSルール → SCP（Service Control Policy）を生成
- Lambdaルール → CloudFormation Guard Hook を生成
-
CFCTパイプライン経由でデプロイ
- git pushでCodePipelineをトリガー
専用エージェントの作成
このデモでは「Shift Left Specialist」という専用エージェントを作成していました。
さらに shift-left-best-practices.md というコンテキストファイルを読み込ませて、Shift Leftのベストプラクティスをエージェントに教えています。
デモ3: アカウント作成 + SRA準拠カスタマイズ
SRA（Security Reference Architecture）とは
AWSが公開しているセキュリティのベストプラクティス集です。「どのアカウントにどのセキュリティサービスをどう配置すべきか」がまとまっていて、GitHubにCloudFormationテンプレートも公開されています。
Knowledge BaseにSRAを読み込ませる
アカウント作成
エージェントは Control Tower の Service Catalog Product を使ってアカウントを作成しました。Organizations APIを直接叩くのではなく、Control Towerのベストプラクティスに従った方法です。
パッチソリューションの自動設計
- CFCTマニフェストファイルをレビューしてSRAの前提条件が整っているか確認
- SRAガイドラインと既存のCFCT構造に沿ったパッチソリューションのデプロイを設計
- デプロイ変更を行う前に、計画を提示して承認を待つ
この指示だけで、エージェントが、
- Knowledge BaseからSRAのパッチソリューションを検索
- 必要なコンポーネントを特定（Patch Manager、Maintenance Window等）
- 2つのCloudFormationテンプレートを生成
- 前提条件用（ベースライン設定）
- メインソリューション（Maintenance Window × 3）
- CFCTマニフェストを更新
- パラメータの確認（スキャンモード or インストールモード、スケジュール等）
エージェントが「Labs OUでいいですか？」「スキャンモードとインストールモード、どっちにしますか？」と確認してくれるのが良かったです。
スクリプト運用(例)との比較
アカウント作成はbashスクリプトで自動化していると仮定した場合、以下の通りです。
# スクリプト例（抜粋）
aws organizations create-account \
--email aws-+${PRODUCT}-${ENVIRONMENT}@example.com \
--account-name ${PRODUCT}-${ENVIRONMENT}
# OU移動
aws organizations move-account \
--account-id ${ACCOUNT_ID} \
--destination-parent-id ${DEST_OU_ID}
# タグ設定、Budget設定...
これはこれで動きますが、COP350のアプローチと比較すると下表にまとめられます。
| 観点 | スクリプト運用 | COP350のアプローチ |
|---|---|---|
| アカウント作成 | Organizations API直叩き | Control Tower Account Factory |
| カスタマイズ | 固定的（bashで個別設定） | Knowledge Baseから柔軟に生成 |
| コンプライアンス | 別途手動設定 | Configルール・SCP・Hookを自動生成 |
| エラーハンドリング | 手動対応 | 自動トラブルシュート |
| 拡張性 | スクリプト改修が必要 | 自然言語で指示 |
まとめ
このセッションで感じたのは、生成AIがガバナンスの「Gatekeeper」から「Enabler」への転換を加速するということです。
従来のガバナンスは「これはダメ」「あれもダメ」とブロックするイメージが強かったですが、生成AIを活用することで、
- 「こういうルールが必要」→ 自動生成・デプロイ
- 「デプロイ失敗した」→ 自動トラブルシュート
- 「このアカウントにはPCI DSS準拠の設定を」→ Knowledge Baseから自動構成
というEnablerが可能になります。
特に印象的だったのは、
- MCP サーバーのロール概念: ユースケースに応じたツールセットの切り替え
- 自動トラブルシュート: 失敗→原因特定→修正→再デプロイの自動化
- Knowledge Baseの活用: SRAなどのベストプラクティスをエージェントに参照させる
アカウント数が増え、コンプライアンス要件が複雑化する中で、このような生成AIを活用したガバナンス自動化は積極的に検討していきたいと思いました。