【登壇レポート】「アカウントが増えてからでは遅い? ~ マルチアカウント統制の勘所 ~」というタイトルでミニセッションしました #AWSSummit

AWS Summit Japan 2026での登壇資料を公開します。アカウントが増え始めた組織に向けて、マルチアカウント統制を始めるための3つの勘所——ランディングゾーン、セキュリティガードレール、ユーザー管理——についてお話しした内容をまとめました。

AWS Summit Japan 2026

中村健一

2026.07.13

こんにちは。中村です。
AWS Summit Japan 2026 の弊社ブースミニセッションにて、「アカウントが増えてからでは遅い? ~ マルチアカウント統制の勘所 ~」というタイトルで登壇しました!
本記事では、そのときに使用した資料を公開します。
 登壇資料 概要AWS アカウントが増え始めた組織に向けて、マルチアカウント統制を始めるための 3 つの勘所を紹介するセッションです。
ランディングゾーン: AWS Control Tower でマルチアカウントの土台を標準化する
セキュリティガードレール: AWS Security Hub CSPM を中心に発見的統制を主役に据える
ユーザー管理: AWS IAM Identity Center でアクセスの 3 要素を見える化する
この3 つに順序はなく、意識して始めることが大切だと考えています。
 内容 こんな課題ありませんか?
AWS の利用が広がると、次のような課題が出てきます。
部署やプロジェクトごとにアカウントが無秩序に増え、オーナー不明の "野良" アカウントが生まれる
セキュリティ設定がアカウントごとにバラバラで、監査ログの長期保管や設定漏れに気付けない
監査対応のたびに全アカウントの証跡集めで消耗する
退職者のユーザーが消されずに残り、誰がどの権限で接続できるか分からない
どれか 1 つでも心当たりがあれば、マルチアカウント統制を検討するタイミングです。
 対応を後回しにする辛さ
セッションでは、アカウント発行を「家を建てること」、ガバナンスを「建築基準法」に例えました。

家を建ててから基準を変えると大工事になるように、アカウントが増えてから統制を効かせるには大きなコストがかかります。
アカウントが少ないうちは全体が見えるため、手作業の証跡集めや個別のユーザー管理でも回ります。

しかしアカウントが増えると、オーナーの特定、証跡集め、セキュリティレベルの統一、ユーザー管理のすべてが手に負えなくなります。
アカウントは "増える前提" で、AWS Organizations を利用して土台から整えるのが鉄則です。
 ① ランディングゾーン
ランディングゾーンとは、統制を効かせたマルチアカウント環境のことです。
導入には、AWS Control Tower を利用するパターンと、独自実装(Custom-built landing zone)のパターンがあります。

独自実装は個別要件に対応できる一方、開発から保守までの責任をユーザー側が負います。

多くのお客様には、AWS ベストプラクティスに沿った環境をテンプレートで整備できる AWS Control Tower から始めることをオススメしています。
AWS Control Tower は、AWS Organizations とベストプラクティスを束ねたマネージドラッパーです。
セットアップ後は、CloudFormation StackSets や Account Factory for Terraform (AFT) などの IaC 拡張オプション、AWS Backup のオプトインでランディングゾーンを最適化できます。
導入は早いほど吉です。

後回しにすると、既存アカウントを登録する際の影響調査が大変になるからです。
 ② セキュリティガードレール
「AWS Control Tower を有効化すれば AWS セキュリティサービスも一元管理される」わけではありません。

組織としてのセキュリティベースラインは、別途設計が必要です。
統制の方法は 2 つあります。
予防的統制: SCP (Service Control Policy) で操作自体を制限する
発見的統制: AWS Security Hub CSPM で危険な設定を検出する
予防的統制を厳しくしすぎると開発効率が落ちます。

そのため、予防は必要最低限に絞り、発見的統制を主役に据えて「検出 → 通知 → 是正」の流れを整備する運用をオススメしました。
検出は、通知まで整備してはじめて機能します。

AWS Control Tower が提供するデフォルト通知構成もありますが、AWS Config の変更内容が JSON 形式のままメール配信されるため、そのままでは読み解きが大変です。

セッションでは、EventBridge や Step Functions などのマネージドサービスを組み合わせて、通知文面をカスタマイズする構成を紹介しました。
 ③ ユーザー管理
アカウントが増え、メンバーも増えると、ユーザー管理のコストは掛け算で増加します。

AWS IAM Identity Center を利用すると、AWS Organizations 配下のすべてのアカウントに対するアクセスを一元管理できます。
第一歩は、認証元(ID ソース)を 1 つに決めることです。

既存の IdP があれば外部 IdP として連携し、なければ Identity Center ディレクトリを利用します。
続くアクセス設計では、「誰が」「どこに」「どの権限で」接続するかの 3 要素を見える化について紹介しました。
3 要素をグループ名に埋め込む命名規則 AWS_<グループ>_<接続先>_<役割> にすると、権限の割り当て実態を一目で識別できます。

たとえば AWS_DEV_Sandbox_Developer なら、開発チームがサンドボックス環境に対する開発権限を持つと読み取れます。

棚卸しやインシデント対応などの運用が効率化します。
 まとめ
アカウントが増えてからの統制は大工事になります。

だからこそ、"今" から始めてみませんか?
 後記ブースにお立ち寄りいただいた皆様、ありがとうございました！

本記事が、マルチアカウント統制を始めるきっかけになれば幸いです。