JAWS DAYS 2026 Mashup for the Future AIエージェント時代 に備える AWS Organizations と アカウント設計 ― 権限と境界の視点で「アカウント設計」を再考する JAWS DAYS 2026 | 2026.03.07 | Track D KOSHIRO Hajime , KINTO Technologies 

#jawsug #jawsdays2026 #jawsdays2026_d 1. システムの境界が曖昧なまま AIエージェント が自律的にAWSリソースを操 作できるようになると、意図しない操作を止められなくなる 2. AWSアカウントを「システム境界の単位」として機能させることが土台 その上にガードレールを重ねて多層防御を実現しよう 対象読者: • AWSのガバナンス設計に悩んでいる方 • AIエージェントをAWSで動かすことを考えている方 この発表のポイント 

#jawsug #jawsdays2026 #jawsdays2026_d • Name: KOSHIRO Hajime • Company: KINTO Technologies Corporation • Role: Senior Infrastructure Architect • Likes: AWS, Terraform • 初めての CfP、初めての JAWS DAYS 参加です！ 自己紹介 X: kodai1_jp 

#jawsug #jawsdays2026 #jawsdays2026_d AIエージェント から Agentic AI へ AIエージェント = 人の指示でタスクを遂行する（人の延長） 人 指 示 結 果 AI エージェント 知覚 判断 行動 ⟲ 人の指示に基づいてループ 環境（AWS / API / DB） Agentic AI の本格展開に向けて、権限とスコープをどう管理していくべきだろうか。 Agentic AI = 役割と権限を持ち自律的に判断・実行する（人と同格） 組織 役割+権限 Agentic AI 知覚 判断 行動 ⟲ 自らゴールを分解しループ 環境（AWS / API / DB） 「人の延長」ではなく「独立した行為者」 H O T T O P I C S 

#jawsug #jawsdays2026 #jawsdays2026_d 権限管理の課題は以前から存在していた 少数の Account × 複数環境 × 多数のサービス prod 限られた VPC 環境: 本番系（複数） ... 多数のサービスが同居 stg 限られた VPC 環境: ステージング系（多数） ... 多数のサービスが同居 dev 限られた VPC 環境: 開発系（複数） ... 多数のサービスが同居 起きていた課題 1 2 3 Quota 制限 リソース上限に何度も遭遇 IAM 権限の肥大化 サービス増で厳密な設計が必要に 運用コストの増大 一つの基盤に全てを載せる限界 サービス増で既に限界 — AIエージェントの追加がこの問題をさらに加速させる O U R S T O R Y 

#jawsug #jawsdays2026 #jawsdays2026_d 基盤中心 → プロダクト軸への転換 O U R S T O R Y Before 基盤中心の構成 少数Accountに全部載せ Quota / IAM / Blast Radius サービス増で限界に Now プロダクト軸で再定義 コンテキスト図で境界を可視化 プロダクト単位で OU / Account 新旧共存で段階的に移行中 After Account = システム境界 境界 = コンテキスト = Account Agentic AI の安全な実行基盤 スコープ明確 / blast radius 最小 プロダクトのコンテキスト境界が、Agentic AI の実行スコープの根拠になる 

「境界」はどこにある？ スケールするプロダクト／システムの境界線の探し方 

#jawsug #jawsdays2026 #jawsdays2026_d "Think in Systems" — システム思考で考える "Every service, every API, every queue is part of a larger system. You can't change one part in isolation." 「すべてのサービス、API、キューは、より大きなシステムの一部。1つの部分を単独では変えられない」 — Werner Vogels, re:Invent 2025 Keynote 対象システム Actor 人 / Agentic AI Event トリガー External System 操作 / 指示 API / 連携 システムの内と外を正しく把握することが重要 

#jawsug #jawsdays2026 #jawsdays2026_d 境界の設計はAWSの外側から始まる C4モデル (Context, Container, Component, Code) を応用し、解像度を段階的に上げる Biz ビジネスコンテキスト プロダクトの存在意義 誰に、どんな価値を届けるか 事業上の制約と優先順位 L1 システムコンテキスト システム全体の外部境界 誰が使い、何と連携するか 責務のスコープはどこまでか L2 AWS マッピング アカウント分割の決定 対象システム → Account 外部システム → 他Account アカウントを設計する => 論理的な境界が先。AWS アカウントへの対応づけは最後 

#jawsug #jawsdays2026 #jawsdays2026_d C4モデルでコンテキスト境界を探す System Context (C4 Level 1) 購入者 [Person] 店舗管理者 [Person] EC サイト [Software System] 決済 [External System] 配送 [External System] AI エージェント [Software System] 自律操作 Container Diagram (C4 Level 2) EC サイト [System Boundary] 注文処理 [Container: API] Web フロント [Container: SPA] 在庫管理 [Container: API] DB [Container: RDS] 決済 [External] AI エージェント [Software System] API呼出し 自律アクセス この図を描けば「境界」が見える → Account設計 / Permission設計 の入力情報になる ※参考: C4モデル（Context, Container, Component, Code） 

#jawsug #jawsdays2026 #jawsdays2026_d アカウント境界を設計する4つの観点 責任 オーナーシップの単位で境界を引く 責任を持つチームが同じシステムを、1つのアカウントにまとめる 影響範囲 blast radiusを意識して境界を設計する 障害や誤操作の影響が他システムに波及しない粒度で区切る 権限 権限の到達範囲をアカウント境界で制限する エージェントが自律動作する前提で、最小権限を実現できる設計にする ガバナンス コンプライアンス要件ごとに境界を揃える 監査・データ主権の要件が異なるシステムは、別のアカウントとして設計する 境界の設計がアカウント設計に繋がる。ここが曖昧だと、エージェント時代に耐えられない 

アカウントを束ねるOU設計 AWS Organizations の組織管理・ポリシー管理をどう使うか 

#jawsug #jawsdays2026 #jawsdays2026_d AWS Organizations — OU という「境界の器」 Root Management Account Foundational OUs Security OU Log Archive / Audit Infrastructure OU Network / Shared Svc Application OUs Workloads OU Prod / Staging / Dev Experimental OUs Sandbox OU Sandbox Account(s) Advanced OUs Deployments OU GenAI OU (後述) 設計のポイント 1. OU階層は浅く保つ 深いネストは避けRoot直下にフラット配置 2. 統制・運用を考慮して設計 SCPやRCPの適用単位となるため、業務上の要件を考 慮して作成する 3. 小さく始めて拡張 Advancedは成熟度に応じて追加 

#jawsug #jawsdays2026 #jawsdays2026_d OU設計でできることは限定的 コンテキスト図 システム A システム B 共有基盤 → 境界が見える アカウント分割 Acct: System-A Acct: System-B Acct: Shared-Infra → 境界 = アカウント OU 配置 Workloads OU System-A Acct System-B Acct Infrastructure OU Shared-Infra Acct OUは統制ポリシー(SCP/RCP)の適用単位。 

#jawsug #jawsdays2026 #jawsdays2026_d 生成AIに特化したOUを作るとしたら？ Management Account Security OU Workloads OU App-Prod App-Dev Sandbox OU 不要なケース — Bedrock API 呼ぶだけ 各アプリが Bedrock API を直接呼ぶだけ AI 固有の SCP/RCP が不要 他ワークロードと同じ統制で十分 → Workloads OU で十分 有効なケース — AI固有 SCP/RCP + 複数Acct 他 OU と異なる SCP/RCP が必要 モデル制限、データ持ち出し制御 等 対象アカウントが複数（1つならaccount-level SCPで十分） → GenAI OU を分離 「統制要件が異なり、対象が複数あるから分ける」というのが原則 GenAI OU RAG Hub ML Exp AI 固有 SCP/RCP 

まとめ 境界設計の先にある、AWSアカウント 内のエージェント統制 

#jawsug #jawsdays2026 #jawsdays2026_d 境界の内側にもガードレールはある Account 内のエージェント統制 — Bedrock AgentCore + IAM Amazon Bedrock AgentCore Runtime 実行環境 Memory 記憶管理 Gateway API連携 Identity 認証認可 Observability 可観測性 + Policy (Preview) — Cedar によるエージェント→ツールの細粒度制御 + Resource-based Policy これらが最も効果を発揮するのは「アカウント境界」が正しいとき 

#jawsug #jawsdays2026 #jawsdays2026_d 明日からできること AWSアカウントを「システム境界の単位」として機能させることが土台。 その上に 3層のガードレール（Role → Resource Policy → Cedar）を重ねる L4 AgentCore Policy L3 Resource-based Policy L2 Execution Role ★ まずこれ: 自分のAWSアカウント構成を「コンテキスト図」にしてみる ☐ 各アカウントの「境界の根拠」を言語化できるか確認 ☐ AIエージェントがアクセスする「アカウントを特定」する ☐ 「境界を越えるアクセス」がどこにあるか洗い出す L1 アカウント境界 + OU 

Thank You! Hajime KOSHIRO | KINTO Technologies スライド公開: 2026/03/09 フィードバック・ご質問はお気軽に！ JAWS DAYS 2026 | Track D 見えない境界は、守れない。 — Think in Systems 

#jawsug #jawsdays2026 #jawsdays2026_d • AWS Organizations — Best Practices • https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/ • Amazon Bedrock AgentCore • https://aws.amazon.com/bedrock/agentcore/ • AgentCore Identity — Terminology • https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-terminology.html • Securing AI agents with AgentCore Identity (AWS Security Blog) • https://aws.amazon.com/blogs/security/securing-ai-agents-with-amazon-bedrock-agentcore-identity/ • Werner Vogels re:Invent 2025 Keynote — Renaissance Developer • https://reinvent.awsevents.com/keynotes/ • Donella Meadows『Thinking in Systems: A Primer』(Chelsea Green Publishing, 2008) References