©MIXI 2026/01/31 株式会社MIXI / 開発本部 / CTO室 / 開発基盤グループ 多⽻⽥ 俊 SRE Kaigi 2026 Room A 11:20 - 11:50 IaaS/SaaS管理における SREの実践 

©MIXI 2 ⽒名: 多⽻⽥ 俊（たばた しゅん）@bbq_all_stars 所属: 株式会社 MIXI 開発本部 CTO 室 開発基盤 グ ループ 経歴: ● 前職では主に Web アプリケーションのバック エンド開発を中⼼に、フロントや iOS アプリの 開発も経験 ● 現在は主に会社の基盤システムの設計から開発 ‧保守‧運⽤や、組織全体のクラウドやSaaS の運⽤を⾏う ⾃⼰紹介 

©MIXI 3 1. 組織の⽴ち位置 2. 組織運⽤における課題と解決のアプローチ 3. パターン①: InnerSource による権限移譲パターン 4. パターン②: ⾃動化 + Human-in-the-loop のパターン 5. まとめ 本⽇のお品書き 

©MIXI 4 開発本部 CTO室 開発基盤グループ 特定のプロダクト・ サービスに所属するエンジニア 横断的に複数のサービス・ プロジェクトに関わるエンジニア 開発基盤グループ 

©MIXI 5 背景 ● ツールの増加（特にAIツール） ● 管理作業の肥⼤化 ● 「強い権限を持つ管理者」への依存 ● 組織⽂化もあり、強く統制‧管理が⾏われて いなかった部分 ● 雑に Slack メンションで管理者に依頼が⾶ん でくることもある 直⾯していた「組織運⽤の課題」 

©MIXI 6 　開発スピードの低下 ● 申請 → 承認 → 作業待ち ● リードタイムの発生 ● 開発者の待ち時間が増加 　手作業の弊害 ● オペレーションミス ● 設定の属人化・ブラックボックス化 ● 誰が何のために設定したか不明 トイルとリスクの構造 

©MIXI パターン①: InnerSource による 権限移譲 

©MIXI 8 SRE とは、サービスの信頼性を担保するために、 運⽤をソフトウェアエンジニアリングの⼿法を ⽤いて課題を解決すること これにより、⾃動化、トイルの削減を⽬指していく。 

©MIXI 9 解決のアプローチ Concept 「申請」から「Pull Request」へ ● あらゆる管理操作を「コード（または設定 ファイル）」として表現する ● インターフェースを GitHub (PR) に統⼀する 共通する狙い 透明性: 誰が‧いつ‧何を‧なぜ変更したかがGitに残る 安全性: 「Apply/実⾏」の前に必ず「Review/Merge」の プロセスを挟む 

©MIXI 10 今回の課題に対し、対象の性質に合わせて2つのパターンを使い分けた。 適⽤した2つのパターン パターン① : InnerSource による権限移譲 対象: 変更に組織管理者の承認が必要な IaaS/SaaS 主語: 主に「事業部」 がコードを書き、PRを作る 目的: ボトルネックの解消と、開発の自律化 パターン②: ⾃動化 + Human-in-the-loop 対象: 変更に組織管理者の承認が必要ない SaaS 主語: 「Bot(機械)」 がPRを作り、「⼈間」 が判 断する ⽬的: トイルの削減と、誤削除リスクの回避 

©MIXI 11 IAM Identity Center (旧SSO) とは ● AWS Organization環境下の認証‧認可を統合 管理 ● User / Account / Permission Set を定義 構造上の制約と課題 ● Permission Set は組織の IAM Identity Center 管理アカウント 上のリソース ● 課題: 事業部はOrganizationの管理アカウン ト権限がないため、Permission Setの作成‧ 変更は管理者に依頼するしかない AWS IAM Identity Center の概要と課題 

©MIXI 12 実現したいこと   事業部 ● SSO 経由でログインできるユーザーの設定 ● Permission Set の Policy のカスタマイズ ● Permission Set、AWS アカウント、ユーザー の紐付け ● ユーザーの設定変更の承認   組織管理者 ● AWS アカウントと事業部の紐付けの承認 

©MIXI 13 実現したいこと   事業部 ● SSO 経由でログインできるユーザーの設定 ● Permission Set の Policy のカスタマイズ ● Permission Set、AWS アカウント、ユーザー の紐付け ● ユーザーの設定変更の承認   組織管理者 ● AWS アカウントと事業部の紐付けの承認 Terraformによる分割管理 CODEOWNERSによる権限委譲 CODEOWNERSによる権限設定 

©MIXI 14 ● .github/CODEOWNERS: ディレクトリと事業部の GitHub Team 承認権限の紐 付け ● common/: 事業部情報から各種リソースを作成 ● project_a, project_b.../: 各事業部が管理するTerraformディレクトリ リポジトリとディレクトリ構成 repository-structure .github/ └── CODEOWNERS # 権限紐付け common/ # [組織管理] ├── tfe.tf ├── oidc.tf └── variable.tf project_a/ # [事業部管理] ├── permission.tf └── variable.tf project_b/ # [事業部管理] └── ... 

©MIXI 15 GitHubの特定のパスに対して、必須承認者 or チーム を割り当てる機能。 これにより、特定のファイル/ディレクトリの PR の承認権限を委譲することができる。 CODEOWNERS .github/CODEOWNER # 組織管理者がオーナー /.github/ @octcat-org/admin /terraform/common/ @octcat-org/admin /terraform/modules/ @octcat-org/admin # 各事業部ディレクトリは、各事業部チームに委譲 /terraform/project-a/ @octcat-org/project-a-team /terraform/project-b/ @octcat-org/project-b-team ... 

©MIXI 16 ● 組織管理者が承認するディレクトリ ● 事業部のための HCP Terraform の workspace や、 Terraform に必要な権限を⽤意 ● 構成: ○ tfe.tf: workspace作成 ○ tfc_oidc_iam_role.tf: workspace の plan / apply を実⾏するための IAM Role 作成 ○ tfc_oidc_provider.tf: OIDC Federationの設定 ○ variable.tf: 事業部とアカウント紐付け IAM Role の condition によって、 account_ids に設定し た AWS アカウントのみに対して操作できる権限を付与 common (組織管理部分) common/variable.tf locals = { divisions = { project_a = { account_ids = { "account-a" = "000000000000" "account-b" = "111111111111" ... } } project_b = { account_ids = { "account-c" = "222222222222" ... } } } ... } 

©MIXI 17 ● 事業部が承認するディレクトリ ● 個々のユーザーが、どういう policy で、どの AWS にアクセスするかを制御する ● 構成: ○ permission.tf: ■ policy の定義 ■ Permission Set の作成 ■ Permission Set の作成、ユーザー、 AWS アカウントの紐付け設定 ○ variable.tf 各事業部が管理するディレクトリ project_a/variable.tf locals = { accounts = { account-a = { policy-a = { users = [ "[email protected]", "[email protected]", ... ] } policy-b = { users = [ "[email protected]", ... ] } ... } account-b = { ... } ... } } 

©MIXI 18 全体のフロー 1. 初期セットアップ common/ ● 事業部とAWSアカウントを紐付けるPR を作成 ● 組織管理者が承認 ● HCP Terraform workspace作成 2. ⽇常運⽤ projects/project_a/ ● ユーザー変更のPRを作成 ● 事業部メンバーが承認 → マージ ● HCP Terraformが⾃動Apply 管理者は初期設定のみ。⽇常運⽤は事業部で完結。 

©MIXI 19 ● Admin権限を渡すわけではない ○ 事業部が触れるのはあくまで「定義ファイル」のみ ● 技術的な安全装置 ○ Stateの分離: 事業部ごとの workspace（State）が分かれているため、他事業部の設定を破壊できない ○ OIDCのスコープ制限: 事業部 workspaceのIAM Roleは、common で許可されたAWSアカウントに対してのみ操作可能 ガードレールと安全性 

©MIXI 20 CNAPPソリューション「Wiz」への適⽤ ● Wiz の Project と User 管理にも同様のスキームを適⽤ ● 事業部管理のクラウドのセキュリティ情報を、事業部が⾃ 由に閲覧できるようにしたい ● AWS管理のリポジトリ構成‧思想をそのまま横展開 Wiz での利⽤例 

©MIXI 21 Wiz の構成 Project ● 複数のクラウドアカウントを束ねる単位 ● 事業部ごとに Project を作成 ● Project とクラウドアカウントの紐付け は、Wiz の管理者が確認したい User ● 事業部ごとに User の作成と Project と User の紐付けを⾏う ● 各 Project の User 管理は、事業部で 管理してもらいたい 

©MIXI 22 承認フローの分離 ● projects/ (クラウド紐付け): セキュリティ管理者が承認 (勝⼿な紐付け防 ⽌) ● users/ (ユーザー追加): 事業部が承認 (CODEOWNERSで委譲) ポイント: AWSの管理⽅法に加えて、GitHub Teamの管理も Terraformに追加。 Wiz の管理⽤のディレクトリ構成 repository-structure .github/CODEOWNERS github-teams/ # GitHub Team管理 projects/ # クラウド紐付け users/ # Userアサイン 

©MIXI 23 結果  時短 ● 組織管理者の作業時間 の短縮 ● リードタイムの短縮 ● 作業待ち時間  効率化 ● 組織管理者を作業から 解放 ● 本質的な基盤改善に集 中  ガバナンス ● 透明性の向上 ● ブラックボックス → Git Log ● チーム内相互レ ビューの⽂化 

©MIXI パターン②: ⾃動化 + Human-in-the-loop 

©MIXI 25 ● 課題の性質 ○ Terraform Providerが充実していない、またはAPIしかない ○ 管理者の承認なしにユーザー追加は⾃由だが、適切に削除がされていないケース ● ゾンビアカウント問題 ○ SSOでログイン⾃体は防げるが、SaaS上にアカウントデータは残るケースがある ○ 結果: 退職者が「アクティブユーザー」としてカウントされ、ライセンス課⾦が継続してしまう SaaS管理における問題 

©MIXI 26 ツール概要 アプローチ ● 「作成（⼊⼝）」は各 事業部にお任せ ● 「棚卸し（出⼝）」に 特化して中央管理する 処理フロー: ● 定期実⾏ (GitHub Actions) ● → 各SaaS API取得 ● → ⼈事DB取得 ● → 差分検知 ● →退職者のリストの PR を作成 ● →PRをマージすること で棚卸し Rust を採⽤ ● 型安全性: 変更に強い 堅牢なコード ● 運⽤: シングルバイナ リでGitHub Actions上 で軽快に動作 

©MIXI 27 ⾃動化の壁 ● ⼈事DBには「⼈間」しかいない ● しかしSaaS上には、CI/CD⽤や連携⽤の 「Botア カウント」 が多数存在する Risk ● 機械的に差分削除すると、Botも消されてしまい、 開発ラインが⽌まる なぜ全⾃動削除しないのか？ (Bot問題) 

©MIXI 28 解決策 ツールは「削除を実⾏」するのではなく、「削除⽤設定 ファイルの変更PR」を作る。 運⽤フロー 1. 検知: ツールが退職候補者を diff.json に追加する PRを作成 2. 判断: 管理者がPRを確認 (Botが含まれていないか チェック) 3. 実⾏: マージをトリガーに実際の削除APIが叩かれる Human-in-the-loop の安全設計 

©MIXI 29 結果 時短 ● 棚卸し作業時間の短縮 コスト ● 不要ライセンスの定期開放 品質 ● オペレーションミスの排除 

©MIXI まとめ 

©MIXI 31 適⽤した2つのパターン パターン①: InnerSource による権限移譲 ● ⼿法: Terraform + CODEOWNERS ● 役割: 「権限の委譲」と「⾃律的な設定」 ● 成果: ボトルネック解消、リードタイム短 縮 パターン②: ⾃動化 + Human-in-the-loop ● ⼿法: GitHub Actions + Human-in-the-loop ● 役割: 「負債の排除」と「安全な⾃動化」 ● 成果: コスト削減、ミスの根絶 共通点: インターフェースを GitHub (Pull Request) に統⼀した 

©MIXI 32 「ちょうど良い統制」の正体 ガチガチの統制 無法地帯のカオス 我々が⽬指したガバナンスの形 「コードによる標準化」 × 「PRと承認による相互監視」 ● 誰が書いても同じ品質になり（標準化） ● 変更履歴が残り、適切な⼈がチェックする（相互監視） これが、⾃律的なMIXIのカルチャーにフィットした。 

©MIXI 33 ● ブラックボックスだった「管理業務」を、エンジニアリングによって透明化‧可視化した。 ● 信頼性 (Reliability) は、システムだけでなく、組織のプロセス にも実装できる。 ● ⼿作業を減らし、再現性を⾼め、回復可能（Revert可能）にする。 Infrastructure as Code から Operation as Code へ 組織管理を SRE しよう 

©MIXI