JAWS DAYS 2026 Mashup for the Future AWS IAM は誰の責任か？ Cloud Infrastructure チーム が全部守る設計はなぜ失敗するのか 辻 水月 / KINTOテクノロジーズ 

#jawsug #jawsdays2026 #jawsdays2026_x 名前：辻 水月 / TSUJI Mizuki 所属：KINTOテクノロジーズ 役割：マネージャー クラウドアーキテクト X ：@mizukibbb 自己紹介 

#jawsug #jawsdays2026 #jawsdays2026_x 今日のゴール 詰まりの構造を整理して、現象を言語化 1 IAMが「なぜ壊れるのか」を、責任範囲の視点で整理します 2 最終責任はInfraのまま、操作を委ねる設計の考え方を共有します 3 

そのIAM運用、 いつか詰まります 

#jawsug #jawsdays2026 #jawsdays2026_x KINTOテクノロジーズの組織構造 そのIAM運用、いつか詰まります セキュリティ組織 プラットフォーム開発部 Cloud Infrastructure SRE, DBRE Platform Engineering Security Operation SCoE A プロダクトチーム B プロダクトチーム C プロダクト X プロダクト サービス サービス サービス サービス サービス サービス サービス • トヨタ自動車グループの一員として一定基準以上のセキュリティを満たす必要性 • 統制と品質を担保しながら、素早くサービス立ち上げするスピードの維持 

#jawsug #jawsdays2026 #jawsdays2026_x → いつの間にかInfraがボトルネック こんな状態ありませんか？ そのIAM運用、いつか詰まります • Lambdaを追加したい • そのたびにInfraへ依頼 • 関数定義もIAM RoleもInfraが作成 • 作成待ちで開発が止まる 

#jawsug #jawsdays2026 #jawsdays2026_x • 権限は中央で管理できていた • 例外対応もInfraが握れていた • 大きな事故は起きていなかった それでも限界が見えたのは、技術ではなく構造の問題でした でも、セキュリティは守れていた そのIAM運用、いつか詰まります 

問題はIAMではなく 「責任」だった 

#jawsug #jawsdays2026 #jawsdays2026_x どの様な責任分担していたか？ 問題はIAMではなく「責任」だった Cloud Infrastructure • AWS内の全システムのリソースを作成/管理 • CloudFront Distribution • Lambda関数定義 / IAM ロール • SFNステートマシン定義 / IAM ロール など プロダクト チーム • 自身で作成したソースや定義などを管理 • Lambdaソース • SFnコード など 

#jawsug #jawsdays2026 #jawsdays2026_x Lambdaなどの責任ポイント 問題はIAMではなく「責任」だった Cloud Infrastructure Lambdaなどはアプリケーションサービスのため、 個別のLambdaのアプリの責任点はプロダクトにある だから“操作”もプロダクトに寄せないと詰まる プロダクト チーム • 責任ポイント • ランタイム選択 • ビジネスロジック • エラーハンドリング • 冪等性の担保 • etc • 責任ポイント • IAM権限 • 同時実行数 • ログ出力先 • etc 例えばLambdaだったら・・・ 

#jawsug #jawsdays2026 #jawsdays2026_x 責任と操作を分離し委任する 問題はIAMではなく「責任」だった Cloud Infraが責任を持ちつつ、 プロダクトチームへ操作を委任できればボトルネックの解消が可能に プロダクト チーム Cloud Infrastructure 責任 操作 操作 委任 

#jawsug #jawsdays2026 #jawsdays2026_x どうやって分離する？ 問題はIAMではなく「責任」だった ＝ ルールを決めて守らせる IAMで「責任」と「操作」を分けます 責任 操作 ＝そのルールの範囲で使う なぜ分けられる？ → ルール（Policy）と、使う主体（Role）を分離できるから 

#jawsug #jawsdays2026 #jawsdays2026_x IAMは誰の責任か？ 問題はIAMではなく「責任」だった Cloud Infrastructure （最終責任） 決める / 守らせる 責任 プロダクトチーム (操作委任) 作る／運用する 操作 IAM Policy 標準IAMポリシー (ABAC) SCP 最低限のSCP IAM Role サービス用ロール IAM Policy 標準IAMポリシー アタッチ 運用方針/手順 Lambda Function 関数定義 ソースコード 

Infraが “全部やらない”と決めた日 

#jawsug #jawsdays2026 #jawsdays2026_x 方針転換（Infraは“作る”から“設計する”へ） Cloud Infraが“全部やらない”と決めた日 • InfraがIAM Role/リソースを作る やめた • 最終責任はInfra（統制と品質） 守った • 標準（ABAC）＋禁止（SCP） 作った 

#jawsug #jawsdays2026 #jawsdays2026_x ABACで「委ねられる」状態を作る Cloud Infraが“全部やらない”と決めた日 ポイント：ポリシーは汎用化し、差分（アクセス範囲）はタグで表現する Cloud Infrastructure プロダクト チーム 【定義】 標準ポリシー（ABAC） を用意 【識別】 AWSリソースに 「属性（タグ）」を付与 【自律】 開発者が「枠内」で 自由に操作 タグが一致する範囲で開発 者が自ら変更可能に！ 自分のプロジェクトタグが 付いたリソースなら操作 OK system=kinto env=dev など 1 2 3 

#jawsug #jawsdays2026 #jawsdays2026_x ABACの落とし穴と対策 Cloud Infraが“全部やらない”と決めた日 落とし穴 対策（ガードレール） タグ無しリソースが残る タグが正しくない・偽装される Create系操作にConditionでtag必須に 命名がブレる 命名規約 をポリシーで制御 例外が恒久化して“標準”が育たない 期限付き + 振り返りで標準へ昇格（プロセス化） タグ一致で許可（ABAC）／ タグが無いものは許可しない 

#jawsug #jawsdays2026 #jawsdays2026_x • 委ねるには『標準（ABAC）』と『禁止（SCP）』を最小限に定義 する 委ねるための仕組み（最低限） Cloud Infraが“全部やらない”と決めた日 線引き（ガードレール） ＝ 禁止 / 標準 / 委譲 禁止（SCP) • 管理者系の付与 • 無制限な *:* 標準（ABAC） • 標準ポリシー • 命名 / タグルール 委譲（開発） • Role 作成 • 日々の変更 

#jawsug #jawsdays2026 #jawsdays2026_x • 待ちが減り、Infraは設計/改善へ。 • 責任が明確になり運用が持続可能に 結果 Cloud Infraが“全部やらない”と決めた日 Before / After（効果） 項目 Before（依頼→待ち） After（自律＋ガードレール） 開発スピード 待ちが発生 自律的に進む Infra負荷 作業が集中 設計 / 改善へ 責任 混在しがち 明確になる 

最終責任はInfra、操作は全員 

#jawsug #jawsdays2026 #jawsdays2026_x 持ち帰ってほしいこと（3つ） 最終責任はInfra、操作は全員 Infraが「最終責任」だけでなく「作業」まで抱えていないか？ 責任範囲（誰が決めて、誰が作るか）が言語化されているか？ ガードレールは『最低限』になっているか？ 

お知らせ 

#jawsug #jawsdays2026 #jawsdays2026_x • ブース出展してます！ • ぜひお話しましょう！ • ガチャガチャでトミカ当たったりします 

#jawsug #jawsdays2026 #jawsdays2026_x AWS主催 の グローバル なイベントである 10,000 AIdeas Competition セミファイナル出場コンテンツも展示してます！ 

Fin