「強制アップデート」か「チームの自律」か。エンタープライズ運用が抱えるジレンマ

AI開発やクラウド共通基盤の運用では、「セキュリティ更新をどう適用するか」が重要なテーマになっています。新しい技術を素早く取り入れるほど、安全性を保つための更新作業も増加します。特にエンタープライズでは、統制を効かせながら開発スピードを落とさない設計が求められます。〈みずほ〉も、まさにこの課題に向き合ってきました。

現在〈みずほ〉では、AI活用の広がりを受けて、働き方や開発のあり方が大きく変わりつつあります。業務予定の整理や資料作成といった日常的な作業だけでなく、アプリケーション開発の一部をAIに任せる動きも出始めています。こうした変化が進むほど、AIを安全かつ継続的に活用できる開発基盤の重要性は高まっていきます。

こうした開発を支える基盤は「作って終わり」ではありません。構築した土台を継続的に安全に稼働させることが重要であり、そのためにはセキュリティ更新の運用が欠かせません。〈みずほ〉には、「みずほWiz Base」の前身となる共通基盤から積み上げてきた運用ノウハウがありましたが、それでも更新作業には解消しがたいジレンマがありました。

基盤を管理するプラットフォーム側は、サイバー攻撃や脆弱性を防ぐために「少しでも早く更新を適用したい」と考えます。一方、基盤を利用する各開発チーム（テナント）は、「予期しないシステム変更により、本番環境に影響が及ぶことは避けたい」と警戒します。先送りできないセキュリティ更新と、稼働中のシステムを守りたいテナント側の事情。どちらも正当な要求でありながら、この二つは構造的に衝突してしまいます。〈みずほ〉はこの課題に対し、実際の基盤運用の中で、強制アップデートとチームの自律を両立する方法を模索してきました。

一括更新の限界から「ハイブリッド運用」へ。判断軸と三つの設計要素

〈みずほ〉も当初は、プラットフォームチームが各アカウントへセキュリティ更新を一括で適用する「フルサービス型」の方式を採用していました。しかし利用規模が拡大すると、テナントごとの影響確認や更新タイミングの調整が増えていきます。プラットフォームチームが新バージョンを開発しても「旧バージョンの更新調整が終わっていないテナントがいるため、全体へリリースできない」という事態に陥りました。テナント側の事情によって、プラットフォームチームの改善サイクルまで止まってしまったのです。

この状態から抜け出すために、〈みずほ〉はAWS Service Catalogによる配布へ移行し、テナントがサポート期限内であれば自分たちのタイミングで製品バージョンを更新できるよう、セルフサービス化を進めました。ただし、すべてをテナントに委ねると、更新が放置されるリスクがあります。そこでたどり着いたのが、「すべてを強制する」か「すべてをテナントに任せる」かという二者択一ではなく、アカウントの性質に合わせて運用方式を使い分けるハイブリッド運用です。

これを実際に機能させるには、ただ方式を分けるだけでは不十分です。この運用を再現可能な仕組みとして根付かせるため、〈みずほ〉ではまず運用方式を分ける判断軸を定め、そのうえでハイブリッド運用における三つの設計要素を積み上げていきました。

判断軸（何を強制し、何をセルフサービスにするか）
運用方式を明確に線引きするために、「本番業務への影響」「更新のオーナーシップ」「調整コスト」を基準にしました。プラットフォームチームの管理アカウントや、本番業務に影響しないサンドボックス領域は、テナントとの調整が不要なためプラットフォーム側で強制アップデート（フルサービス）を実施します。一方で、本番業務に関わるテナントアカウントは、各テナントが影響確認を行ったうえで、サポート期限内に自分たちのタイミングで更新するセルフサービスへと切り替えました。

ここで重要なのは、すべてのアカウントを一律に扱うのではなく、業務影響の有無と更新判断の主体に応じて、フルサービス更新とサポート期限付きのセルフサービス更新を切り分けることです。この分類が、以降の世代管理・責任分界・CI/CDパイプライン設計の出発点になります。

判断軸の全体像

設計要素① 世代管理（テナントの更新タイミングに期限付き猶予を与える）
世代管理は、テナントごとに異なる更新タイミングをシステム的に許容する仕組みです。AWS Service Catalogの製品として複数世代を並行提供し、テナントが検証・承認を終えたタイミングで更新できるようにします。実は〈みずほ〉もここで一度つまずきました。当初「常に最新版のみ」を提供し、旧版を即座に廃止した結果、テナントにより更新可能なタイミングが異なることから、「検証済みのバージョンに更新しようとしたら、すでに廃止されていた」という事態が発生したのです。この反省から、最大三世代のバージョンを並行提供する方式へ切り替えました。旧世代にもサポート期限を設けてテナントに猶予を与えつつ、更新されないままの状態を防いでいます。

設計要素② 責任分界（誰が何に責任を持つか）
責任分界は、プラットフォームチームとテナントの責任範囲を定めることです。複数バージョンが混在する中でこの境界が曖昧だと、更新遅れの個別調整がすべてプラットフォームチームにのしかかります。そこで、プラットフォームチームは「新バージョンの提供」「サポート期限の明示」「管理領域への強制適用」を担い、テナント側は「期限内の自己更新」「影響確認とタイミング調整」を担うと明確化しました。これにより、双方が自身の責任範囲に集中できるようになります。

設計要素③ CI/CDパイプライン（定めたルールを自動で回す）
CI/CDパイプラインで実装したのは、ここまでのルールを自動実行させる仕組みです。〈みずほ〉では、同一パイプライン内で、Gitリポジトリからソースを取得し、依存関係のインストールやテンプレート生成、単体テストを行ったうえで、管理アカウント上のAWS Service Catalogへ新バージョンをデプロイします。その後、配布設定に基づいて全アカウントへ新バージョンを展開し、管理アカウントやサンドボックス等のフルサービス対象を判定して、該当領域だけにバージョン更新を実行します。セルフサービス対象のテナントアカウントには新バージョンのデプロイのみを行い、各テナントがサポート期限内に自分たちのタイミングで更新できる状態を作ります。

なお、今回の発表内容のうち、AWS CDKを用いたマルチアカウント管理の仕組みや、AWS Service Catalog製品のセキュリティ運用・CI/CDパイプラインの実装に近い内容は、AWS公式ウェブマガジン「builders.flash」でも紹介しています。

参考：builders.flash（AWS公式ウェブマガジン）
〈みずほ〉がAWS CDKで実装したマルチアカウント管理の仕組み 第1回：AWS Service Catalogを使ったセルフサービス型機能の提供
〈みずほ〉がAWS CDK で実装したマルチアカウント管理の仕組み 第3回：組織単位ごとのガバナンス戦略！AWS Service Catalog製品のセキュリティ運用と CI/CDパイプライン実践例

まず強制と自律の境界を定め、世代管理でテナントごとの更新タイミングに猶予を持たせ、責任分界で双方の役割を明確にし、CI/CDパイプラインで更新プロセスを自動化する。この順番で土台を組み立てることで、ハイブリッド運用は属人的な調整ではなく、再現可能な仕組みとして回り始めます。

期限付きの自律が、更新を前に進める。〈みずほ〉が描くAI時代のプラットフォーム運用

ハイブリッド運用とその三つの設計要素を導入したことで、常態化していた更新待ちの行列は改善しました。ポイントは、各テナントの事情に応じて自由に運用するのではなく、サポート期限を設けた「期限付きの自律」にしたことです。

最新版から二世代前までを許容し、更新の期限が近いテナントには可視化と通知で更新を促す。この二つを両立させたことで各テナントが計画的に動けるようになり、2025年の実績では、ほとんどのテナントが期限内に自主的な更新を完了しました。この経験から見えてきたのは、プラットフォームを構築する際は、初期設計の段階から世代管理を設計に組み込むべきだということです。後になってからテナントの検証体制や更新プロセスを変えるには、大きな負担がかかるからです。

こうした運用の安定性を土台に、現在の〈みずほ〉が進めているのが、AI開発をより推進するための基盤（ゴールデンパス）の整備です。ゴールデンパスとは、推奨される開発手法、AI活用の仕組み、ツール、設計パターンをセルフサービスで提供し、開発者が複雑な統制や制約を必要以上に意識しすぎることなくアプリケーション開発に集中できるようにする取り組みです。速く作り続けられる攻めの環境と、システムを止めずに守り抜くハイブリッド運用。この両輪がそろって初めて、大規模なプラットフォームは持続可能になります。

今後はAI自身の進化に合わせ、プラットフォームにおける「強制」と「自律」の境界線も柔軟に見直していく考えです。AIが影響確認や調整を支援できる領域ではフルサービスの適用範囲を広げつつ、業務影響や更新タイミングをテナントが判断する必要がある領域ではセルフサービスを引き続き有効に使います。現在は、人がプロセスの中心に入りながらAIと協働する仕組みを整えている段階です。ただし、それは最終的な到達点ではありません。将来的には、AIが開発や運用の一部を自律的に主導し、人は設計・維持・統括といった役割に軸足を移していくことを見据えています。

クラウドネイティブ会議に登壇して説明する松尾

PROFILE

みずほ銀行 情報数理工学研究所 デジタル技術開発部 上席主任研究員

松尾 優成

2015年にみずほ情報総研（現：みずほ銀行）へ入社。国際系金融システムの開発・保守を担当後、「CCoE（Cloud Center of Excellence）」で銀行向けプラットフォームの継続的サービス改善に従事。その後、お客さま向けプラットフォームの構築・運用を担当し、プラットフォームエンジニアリングを実践。現在は内製開発強化の一環として、ゴールデンパスの整備と開発者体験向上に取り組んでいる。その他、〈みずほ〉のテック×ビジネスコミュニティ「コクリエ」を運営。

※所属、肩書きは取材当時のものです。

文・写真/みずほDX編集部