「強制アップデート」か「チームの自律」か？エンタープライズが辿り着いたプラットフォームのハイブリッド運用/cloudnative-kaigi-hybrid-platform-operations

「クラウドネイティブ会議」での登壇資料です。
イベントURL：https://kaigi.cloudnativedays.jp/

Transcript

1. © 2026 Mizuho Bank, Ltd. 2026年5月15日 情報数理工学研究所 デジタル技術開発部 「強制アップデート」か「チームの自律」か？ エンタープライズが辿り着いたプラットフォームのハイブリッド運用 クラウドネイティブ会議 （免責事項） 当レポートは情報提供のみを目的として作成されたものであり、商品の勧誘を目 的としたものではありません。本資料は、当社が信頼できると判断した各種デー タに基づき作成されておりますが、その正確性、確実性を保証するものではあり ません。また、本資料に記載された内容は予告なしに変更されることもあります。
2. © 2026 Mizuho Bank, Ltd. 自己紹介 1 業務経歴 ⚫ 国際系金融システムの開発・保守 ⚫ CCoE でプラットフォームの継続的サービス改善 ⚫ クラウドネイティブをテーマとした社内コミュニティの企画・運営 ⚫ お客さま向け AWS プラットフォーム / ゴールデンパスの設計・運用 登壇・寄稿 ⚫ クラウドネイティブ会議 Day1 Cloud Native Track ⚫ DevOpsDays Tokyo 2026 / ServerlessDays Tokyo 2024 / builders.flash etc... 松尾 優成 Yusei Matsuo デジタル技術開発部 上席主任研究員
3. © 2026 Mizuho Bank, Ltd. 本日話すこと・話さないこと 2 ⚫ セキュリティ更新の運用モデル （フルサービス/セルフサービスのハイブリッド） ⚫ 判断軸の設計と失敗談 ⚫ 世代管理・責任分界の考え方 話すこと ⚫ 実装の詳細 ⚫ セキュリティ製品そのものの選定・評価 ⚫ プラットフォーム立ち上げ時の検討（AWS Control Tower 導入経緯など） 話さないこと ※実装の詳細は AWS 公式ウェブマガジン『builders.flash』で紹介しています！ 「AWS builders.flash みずほ」で検索！
4. © 2026 Mizuho Bank, Ltd. はじめに 3 〈みずほ〉における AI 活用の加速 全社で AI 活用に力を入れており、AI 案件が急激に増加 セキュアで統一された AI 開発環境の構築が必要 業務効率化 ・Wiz Chat (汎用AIチャット) ・スライドジェネレーター (スライド資料自動作成) ・Wiz OCR (高精度で紙・手書き文書をデータ化) 情報収集・分析 ・みずほDeepResearch (情報収集・レポート作成) ・Wiz Search (社内手続検索) ・壁打ち魔人 (アイデア・仮説の壁打ち) コミュニケーション支援 ・Wiz Translate (ファイル翻訳) ・Wiz Translate (リアルタイム翻訳) ビジネス支援 ・RM Studio (お客さまへの提案を支援) ・AIインタビュアー (暗黙知を形式知化) ・Dify (AIエージェント構築) 活用サポート ・Wiz Buzzコミュニティ(社内SNS) etc…
5. © 2026 Mizuho Bank, Ltd. はじめに 4 AI プラットフォーム “Wiz Base” 誕生 ⚫ AWS 上に構築された AI エージェントを稼働させる共通プラットフォーム ⚫ エンタープライズ要件を満たす統制とセキュリティ プラットフォームの 構築初期～中期をお話しします！ 規模感（2026年4月時点） • テナント： 約80 • AWS アカウント：約150
6. © 2026 Mizuho Bank, Ltd. Platform as a Product の考え方を採用し、スクラムの手法で開発 （プラットフォームを「製品」として捉え、継続的な改善とユーザー体験向上を重視） ✓ 開発チーム：4～5名（内製） ✓ 主な技術スタック：AWS Control Tower / CDK ✓ AWS 上にプラットフォーム共通機能を開発 • アカウント発行・初期設定 • セキュリティ設定 • 不正操作検知・障害情報の通知集約 • 違反設定の自動修復、ダッシュボード • etc... プラットフォーム初期の開発体制と構築方法 5 本セッションではセキュリティ製品の更新運用にフォーカス
7. © 2026 Mizuho Bank, Ltd. プラットフォーム初期のアプローチ 6 当初のアプローチ：フルサービス型で一括更新 プラットフォームチームが AWS CDK CLI で各アカウントへ 直接デプロイ・更新 （テナント数分の作業が必要） セキュリティ共通機能も プラットフォームチームが 一括管理 テナントが少数の時代は この運用で回っていたが…
8. セキュリティ更新のジレンマ セキュリティ更新を急いで適用したい でも、勝手に変えて本番環境を壊したくない この2つの要求は構造的に衝突する 7 Problem
9. © 2026 Mizuho Bank, Ltd. なぜ更新が詰まるのか（1） 8 更新の待ち行列が発生 ✓ エンタープライズの統制が厳しい環境では、変更作業に調整が必要 ⚫ 変更に伴う影響確認・リリース時期の調整 ⚫ 多数のアプリケーション・チームが存在し、環境ごとに変更可能なタイミングが異なる テナント数が増えるほど待ち行列が膨らむ
10. © 2026 Mizuho Bank, Ltd. なぜ更新が詰まるのか（2） 9 単なる自動化では解決しない ✓ 現状、「全自動で一斉更新」はエンタープライズの統制環境で採れない ✓ 問題の本質は「環境ごとに変更可能なタイミングが異なるという構造」 デリバリーを自動化しても、調整コストは消えない… AI で一定の効率化はできるが、チームごとに人の確認は必要（Human-in-the-Loop） 今週、更新していいよ 2週間後に 更新していいよ 調整コスト 環境 A 環境 B 環境 C
11. © 2026 Mizuho Bank, Ltd. フルサービス型の限界 10 利用者増加に伴い、各アカウントの更新で調整コストが爆発 ✓ 更新の待ち行列が常態化 ✓ プラットフォームチーム自身の改善サイクルも停滞 新バージョンの開発が 完了しているのに、 旧バージョンの更新未済で リリースできない…！
12. AWS Service Catalog への移行とセルフサービス化 11
13. © 2026 Mizuho Bank, Ltd. AWS Service Catalog への移行とセルフサービス化 12 フルサービスから AWS Service Catalog による配布へ移行することに 任意のタイミングで 任意のバージョンを 更新できる！ （セルフサービス化） プラットフォームチームの開発サイクルとテナントの更新サイクルを分離できる！ 製品ごとにバージョン管理 ⇒更新未済のチームがいても 新バージョンをリリース可
14. © 2026 Mizuho Bank, Ltd. AWS Service Catalog への移行とセルフサービス化 13 しかし、すべての AWS アカウントで セルフサービスにするのは現実的でなかった… ✓ セルフサービスに委ねるべきでない領域がある （サンドボックス環境など） ✓ テナントに任せきりだと、更新が放置されるリスクも… セルフサービス化で一つの課題は解決したが、新たな問いが生まれた
15. ハイブリッド運用という選択 二者択一ではなく、フルサービスとセルフサービスの使い分け すべてを統一するのではなく、判断軸を設計する 14 Solution
16. © 2026 Mizuho Bank, Ltd. 判断軸 15 ① フルサービス ⇒プラットフォームチームの管理アカウント（テナント調整不要） ② セルフサービス ⇒プラットフォーム利用者のテナントアカウント（各チームのサイクルで更新） フルサービス or セルフサービス の大きな判断軸）
17. © 2026 Mizuho Bank, Ltd. 判断軸 16 ① フルサービス ⇒プラットフォームチームの管理アカウント（テナント調整不要） ② セルフサービス ⇒プラットフォーム利用者のテナントアカウント（各チームのサイクルで更新） ただし、テナントアカウントにも種類があり 一律セルフサービスではない フルサービス or セルフサービス の大きな判断軸）
18. © 2026 Mizuho Bank, Ltd. 判断軸 17 テナントアカウントの運用方式 テナントアカウントでも組織単位（OU）の属性に応じて方式が異なる Workload OU 本番・ステージング・開発環境用の AWS アカウント群 セルフサービス更新 Sandbox OU PoC・技術検証用の AWS アカウント群 フルサービス更新 ⚫ 本番稼働中のシステムがあり、 影響確認・調整が必要 ⚫ 利用者が自身のタイミングで更新を適用 ⚫ ただし「サポート期限」を設定し、放置を防止 ⚫ 検証用途で本番業務に影響しないため、 強制更新が可能 ⚫ サンドボックス環境の更新し忘れを防ぐため、 プラットフォーム側で一括更新 ⚫ テナントの更新負担を軽減
19. © 2026 Mizuho Bank, Ltd. 判断軸 18 強制/セルフサービスの考え方 「本番業務への影響 / 更新のオーナーシップ / 調整コスト」で判定 対象アカウントの特性 運用方式 主な判定理由 プラットフォーム提供側で 管理 フルサービス （強制更新） ✓ リリース前に自チームでテスト済 ✓ 他チームとの調整不要 サンドボックス （PoC・技術検証など） フルサービス （強制更新） ✓ 本番影響なし (サンドボックス利用規約で事前周知) 本番稼働 セルフサービス （サポート期限付き） ✓ 各チームとの調整が必要 開発・ステージング環境 セルフサービス （サポート期限付き） ✓ 各チームとの調整が必要 (本番環境リリースとの整合が必要)
20. © 2026 Mizuho Bank, Ltd. 判断軸 19 判断軸の全体像 管理アカウント + サンドボックス ⇒フルサービス テナントアカウント (本番・ステージング・開発) ⇒セルフサービス
21. ハイブリッド運用の設計要素 20
22. © 2026 Mizuho Bank, Ltd. 21 ハイブリッド運用の設計要素 世代管理 Service Catalog の製品で 複数世代を並行提供 責任分界 プラットフォームチームと テナントの役割分担 CI/CDパイプライン フルサービス自動更新と セルフサービス公開を一気通貫
23. © 2026 Mizuho Bank, Ltd. 22 ハイブリッド運用の設計要素 世代管理 Service Catalog の製品で 複数世代を並行提供 責任分界 プラットフォームチームと テナントの役割分担 CI/CDパイプライン フルサービス自動更新と セルフサービス公開を一気通貫
24. © 2026 Mizuho Bank, Ltd. 世代管理 23 単一世代（最新版のみ）提供の失敗 セルフサービス化した当初は「常に最新版のみ」を提供 （セキュリティ周りのアップデートは最新に追従してほしいという判断） 製品の更新に間に合わないケースが続出… 「検証・承認済みのバージョンで更新したいのに廃止された」という声 ⇒ プラットフォーム側で旧版を再リリースするなどリカバリが必要となった v1.2 v1.1 v1.3 v1.0 テナントの更新タイミングがバラバラなのに 一世代前の旧バージョンを即座に廃止 latest
25. © 2026 Mizuho Bank, Ltd. 世代管理 24 なぜ単一世代は失敗したのか ✓ 利用者側が2世代以上前のバージョンから、廃止済みバージョンへ 更新するケースを想定していなかった（例: v1.1 → v1.2） ✓ 利用者ごとにリリースサイクル・凍結期間・リソース状況が異なる （利用者の検証・承認に必要なリードタイムを十分に織り込めていなかった） プラットフォームの更新サイクルに すべての利用者が追従できるという前提が誤り v1.2 v1.1 v1.3 v1.0
26. © 2026 Mizuho Bank, Ltd. 世代管理 25 世代管理の導入 旧世代を一定期間サポートし続けることで、利用者に猶予を与える ✓ 単一バージョンではなく、最大3世代を並行提供 ✓ 2世代前のバージョンまではサポートするように期限を設定 2025年の実績では、ほとんどのテナントが期限前に更新を完了！ 「いつでも更新できる」状態を作ることが、結果的に更新を加速させた
27. © 2026 Mizuho Bank, Ltd. 世代管理 26 世代管理を機能させるための工夫点 Point 1 サポート期限の設計 ⚫ 新世代のリリース時に古い 世代のサポートを終了し、 常に最大3世代を並行提供 ⚫ 緊急性のない更新は 最低1ヵ月空けてリリース (更新頻度が多いと テナントの負荷が増加) Point 2 ダウングレード非保証 Point 3 可視化と通知 ⚫ バージョン情報を一元管理 ⚫ ダッシュボードで 全体の更新状況を可視化 (AWS Resource Explorer) ⚫ 期限切れが近いテナントへ 移行促しの通知 ⚫ 旧世代から新世代への 移行手順を提供 ⚫ 新世代から旧世代への ダウングレードは サポート対象外 (新世代で構成やパラメータ が変わる場合あり)
28. © 2026 Mizuho Bank, Ltd. 27 ハイブリッド運用の設計要素 世代管理 Service Catalog の製品で 複数世代を並行提供 責任分界 プラットフォームチームと テナントの役割分担 CI/CDパイプライン フルサービス自動更新と セルフサービス公開を一気通貫
29. © 2026 Mizuho Bank, Ltd. 責任分界 28 責任分界の明確化 ✓ 単一世代提供の失敗は、責任分界の曖昧さが根本原因 テナントの更新が間に合わないたびに、プラットフォームチームが旧バージョンの再提供や 個別調整に追われていた ✓ 世代管理の導入とあわせて、双方の役割を明確に設計 プラットフォームチームの責任範囲 テナントの責任範囲 ⚫ 製品のバージョン提供・動作保証 ⚫ サポート期限の明確化 ⚫ 管理アカウント・サンドボックスへの強制適用 ⚫ サポート期限内に自アカウントを更新 ⚫ 更新タイミングの調整と影響確認
30. © 2026 Mizuho Bank, Ltd. 29 ハイブリッド運用の設計要素 世代管理 Service Catalog の製品で 複数世代を並行提供 責任分界 プラットフォームチームと テナントの役割分担 CI/CDパイプライン フルサービス自動更新と セルフサービス公開を一気通貫
31. © 2026 Mizuho Bank, Ltd. CI/CD パイプライン 30 ハイブリッド運用のルールを CI/CD パイプラインに埋め込む 同一パイプライン内で新バージョン公開とフルサービス更新を両立 ソース • Git リポジトリ から取得 ビルド • 依存関係 インストール • テンプレート 生成 • 単体テスト 製品デプロイ • 新バージョンの 製品を Service Catalog 管理 アカウントに デプロイ • 組織連携で 全アカウントへ 新バージョンを 自動公開 フルサービス 対象判定 • 管理アカウント/ サンドボックス アカウント一覧 を取得 バージョン 更新 • フルサービス対 象に対して製品 バージョン更新 APIを実行 テナントアカウント（Workload OU）は 任意タイミングでセルフサービス更新
32. © 2026 Mizuho Bank, Ltd. （参考）CI/CD パイプラインの概要図 31 組織単位ごとのガバナンス戦略！ AWS Service Catalog 製品の セキュリティ運用と CI/CD パイプライン実践例 https://aws.amazon.com/jp/builders- flash/202602/mizuho-rt-ci-cd-pipeline/ CI/CD の詳細は builders.flash で 公開中！
33. まとめ 32
34. © 2026 Mizuho Bank, Ltd. 33 1. 統制と自律は、設計で両立できる ⚫ 領域ごとにフルサービスとセルフサービスを使い分ける（ハイブリッド運用） ⚫ 運用方式の境界を決める判断軸が重要 2. 世代管理は、自律運用の前提条件 ⚫ 猶予とサポート期限を設けることで、テナントの更新は結果的に加速する ⚫ 責任分界を明確にすることで、プラットフォームチームとテナント双方の 更新運用が回る まとめ ハイブリッド運用により、セキュリティ製品の更新は 個別調整に追われる状態から改善サイクルが回る運用へ
35. © 2026 Mizuho Bank, Ltd. 34 改善サイクルを次の領域へ ✓ AI の進化に合わせて、強制と自律の境界を見直し続ける ⚫ AI が調整・判断を代行できる領域では、フルサービスを段階的に拡大 ⚫ 業務影響や更新タイミングをテナントが判断する領域ではセルフサービスが引き続き有効 ✓ 開発者体験をさらに高めるため、ゴールデンパスを整備中 ⚫ 推奨される開発手法・AI・ツール・パターンをセルフサービスで提供 ⚫ 開発者が複雑な制約を意識せず、アプリ開発に集中できる状態を目指す 今後の展望 Day1 でゴールデンパスの 事例を紹介！
36. © 2026 Mizuho Bank, Ltd. 35 Security-JAWS DAYS ~10th Anniversary Event~ に〈みずほ〉が登壇！ ⇒ 本セッションで触れたセキュリティ製品の活用・運用改善を、別の角度から紹介！ 関連セッションのご案内 2026年5月16日（土）16:30-16:50 全社統制を維持しながら現場負担をどう減らすか ～プラットフォームチームとセキュリティチームで進めた Security Hub 活用による AWS 統制の見直し～
37. © 2026 Mizuho Bank, Ltd. 宣伝：〈みずほ〉ではともに働く仲間を募集しています！ 36 〈みずほ〉では、生成 AI を活用して AI 推進する人材を積極的に募集中！ 事業モデル（オペレーショナルモデル）の変革を進め、新たな金融の価値創造に挑みます 「みずほ AI 採用」で検索！ ◼ 主な職務内容（AI テックリード / エンジニア / PdM / PM など） 生成AIを用いたPoC開発、技術基盤の整備、LLM技術調査とAIエージェント開発