「クラウドネイティブ会議」レポート 7

【クラウドネイティブ会議】厳格な統制と開発者体験を両立する、Wiz Baseにおけるゴールデンパスの実践

セキュリティや統制を維持しながら、開発者に制約を感じさせないことを両立させる仕組みについて、みずほ銀行が自行の事例を解説したセッションを紹介する。

木村 慎治

6:00

生成AI活用が全社的に広がる中、エンタープライズ企業には、セキュリティや統制を維持しながら、開発スピードをどう高めるかが求められている。みずほ銀行では、AIエージェントを稼働させる共通プラットフォーム「Wiz Base」の上で、開発者が複雑な制約を意識せずにアプリケーション開発へ集中できる仕組みを整備してきた。

クラウドネイティブ会議に登壇したみずほ銀行の松尾優成氏と仁賀井球人氏は「エンタープライズの厳格な制約を開発者に意識させない:クラウドネイティブ開発基盤設計」と題し、エンタープライズ要件と開発者体験を両立するクラウドネイティブ開発基盤設計について語った。

AI活用を支えるWiz Baseと、開発本格化で見えた認知負荷

みずほ銀行では全社でAI活用に力を入れており、業務効率化、情報収集・分析、コミュニケーション支援、ビジネス支援など、AI関連の案件が急速に増加している。こうした状況を受け、同社ではセキュアで統一されたAI開発環境の必要性が高まった。

そこで誕生したのが、AIプラットフォーム「Wiz Base」である。Wiz Baseは、AWS上に構築されたAIエージェントを稼働させる共通プラットフォームであり、ネットワーク、セキュリティ、運用共通機能を通じて、エンタープライズ要件を満たす統制とセキュリティを提供する。「これらを通じて感じているのは、やはりセキュアで統一されたAI開発環境が必要だということです。そこで生まれたのがWiz Baseです」と松尾氏は説明した。

一方で、Wiz Base上での開発が本格化すると、新たな課題も見えてきた。AI関連アプリがWiz Baseに集約され、開発体制も急拡大したことで、多様なバックグラウンドを持つメンバーが参加するようになったが、Wiz Baseや社内ルールに詳しいメンバーばかりではなかった。AIやWiz Baseによって個々の技術的ハードルは下がったものの、アプリ開発の前に超えるべきハードルはむしろ増えたのである。

Wiz Base 上での開発が本格化

Wiz Base 上での開発が本格化

リリース直後には、自社ルールの制約やプラットフォーム仕様に関するドキュメントが膨大となり、ベストプラクティスも未確立だった。各チームが閉域ネットワーク接続の仕様や申請方法をそれぞれ調べ、同じ問題にぶつかる状況が生まれていた。

制約を吸収し、安全で速い道を示すゴールデンパス

こうした課題に対して、同社が導入したのが「ゴールデンパス」である。ゴールデンパスとは、プラットフォームで推奨される開発手法、ツール、パターンを組み合わせて提供するものだ。複雑な基盤要件や統制ルールを吸収し、開発者が「安全で速い道」をそのまま利用できる状態を作る。重要なのは、自由度を完全に奪うのではなく、自由度を保ちながらベストプラクティスへ自然に誘導する点である。

ゴールデンパスとは

ゴールデンパスとは

松尾氏は、プラットフォームと実案件の関係を多層構造として整理した。最下層にはAWSサービスがあり、その上にWiz Baseが統制やセキュリティ、ログ監査などの共通機能を提供する。さらにその上で、安全な作り方を定義するレイヤーがゴールデンパスである。案件固有の実装は、その上に乗る形になる。つまり、プラットフォームの制約をゴールデンパスで吸収し、実案件との溝を埋めるアプローチである。「プラットフォームと実案件の溝を埋めるアプローチ、それがゴールデンパスとしてやっていることになります」と松尾氏は語った。

ゴールデンパスが提供する価値として、松尾氏は5つのメリットを示した。開発開始までの時間を短縮するクイックスタート、テンプレートによるセキュリティ自動準拠、標準化されたCI/CDパイプラインによるリリーススピードの向上、ベストプラクティスやコードの資産化、そしてフィードバックを基にした継続的改善である。エンタープライズの制約が複雑でも、ゴールデンパスで吸収すれば、開発者は安全かつ高速に前進できるという考え方だ。

6つのコンポーネントで実現する開発者体験

後半では仁賀井球人氏が、ゴールデンパスを構成する6つのコンポーネントを詳しく紹介した。用意されたのは、AIコンテキスト、ドキュメントサイト、カスタムコンストラクト、サンプルアプリ、CI/CDワークフロー、ガードレールである。これらを組み合わせることで、開発者に制約を意識させない体験を実現している。

ゴールデンパス

ゴールデンパス

AIコンテキストは、組織のルールやドメイン知識をパッケージ化して配布する仕組みである。AIエージェントの活用が広がる一方で、使い方が個人やプロジェクトに閉じると、回答やコード生成の品質がばらつく。そこで、組織にカスタマイズされたAIコンテキストを配布し、AI活用を組織の標準資産として運用できる状態を目指した。

ドキュメントサイトは、設計思想から申請手順までを集約したSSoT、すなわちSingle Source of Truthである。人間にもAIにも読める情報源として整備し、開発者が必要な情報へ迷わず到達できるようにした。

ゴールデンパスを構成するコンポーネントの中でも中核となるのが、カスタムコンストラクトである。これは、統制を内包したCDK(Cloud Development Kit)のインフラ部品であり、開発者は少ないコードでWiz Base準拠のインフラを構築できる。閉域ネットワークやVPCの扱いなど、基盤固有の制約はコンストラクト側で吸収される。開発者は複雑な設定をすべて理解しなくても、安全なインフラ部品を利用できる。

CDKを採用した理由としては、Wiz Base環境との整合性、Terraformのようなステート管理が不要であること、コンストラクトの配布と再利用のしやすさ、TypeScriptによる型安全なインフラ定義が挙げられた。型補完によって、何を設定できるのかがわかりやすくなる点も、開発者体験の向上につながる。

サンプルアプリは、ゴールデンパスのコンポーネントを実際に使ったリファレンス実装である。共通Cognitoを用いたSSO、DB接続、ログ、生成AIとの接続などのサンプルを内包する。当初はライブラリ化も検討されたが、案件ごとの固有要件に対応しにくくなることや、内部理解の認知負荷が高まることから、サンプル実装として提供する形を選んだ。コードを読んで学べること、必要に応じて自由にカスタマイズできることを重視した判断である。

CI/CDワークフローでは、GitHub ActionsのReusable Workflowsを活用した。パラメーターを埋め、20~30行程度のラッパーを書くことで、標準化されたワークフローを構築できる。フロントエンドとバックエンドを一括デプロイするfullstack-deploy、インフラのみをデプロイするcdk-deploy、コンテナイメージをビルドしてpushするcontainer-build、ECSサービスのタスク定義を更新するecs-updateなどが用意された。

ガードレールは、組織にカスタマイズされたルールを配布し、デプロイ前に静的解析を行う仕組みである。CDK Nagを用いたカスタムルールにより、デプロイ前チェックとシフトレフトを実現する。SCPやAWS ConfigによるWiz Base側の統制に加え、アプリ側の実装段階でも組織ルールに沿っているかを確認できるようにした。

同じところで詰まらない開発基盤へ

仁賀井氏は、ゴールデンパス導入の効果を具体的な数値で示した。アカウント払い出しから疎通までの各工程は大きく短縮され、AWS環境構築は1ヶ月から2時間弱へ、CI/CD構築は3日から30分へ短縮された。セキュリティ設定レビューも、都度個別対応していた状態から、チェック通過をもって完了できる形へ変わった。現在、ゴールデンパスは約10案件に適用されているという。「新しい案件のたびに、同じところで詰まるというものが構造的に解消されたことがわかると思います」と仁賀井氏は説明した。

アカウント払い出しから疎通までの各工程が劇的に短縮された

アカウント払い出しから疎通までの各工程が劇的に短縮された

利用者からは「アプリ開発に集中できた」「数十行書いただけでWiz Base準拠のインフラが構築できた」「AIに訊けばゴールデンパス準拠のコードを書いてくれる」といった声が寄せられたという。制約を取り除くのではなく、開発者に意識させない形へ抽象化したことが、開発者体験の向上につながったのである。

ただし、良いものを作れば自然に使われるわけではない。ユーザーからは「そもそも何が楽になるのか」「そういうものもあったんですね」といった反応もあり、同社ではマーケティングとイネーブリングにも力を入れるようになった。初回利用時の伴走や相談会で知ってもらうこと、実際の案件メンバーを開発に巻き込んで一緒に作ること、環境払い出し時点でGitHubテンプレートを用い、最初からゴールデンパスに乗れる状態を提供することに取り組んでいる。

最後に仁賀井氏は、ゴールデンパスの取り組みを4点にまとめた。1つ目は「制約は変えられない。変えるべきは開発者体験」である。エンタープライズの統制を緩めずに、開発者の認知負荷だけを取り除くことに重点を置いた。2つ目は「意識させない」は最高の開発者体験であるという点だ。ドキュメントを読ませて理解させるのではなく、自然と安全な道を歩ける状態を作ることを目指した。3つ目は、インフラの抽象化だけでは足りないということだ。カスタムコンストラクトやCI/CDだけでなく、ドキュメントやAIコンテキストまで一式で提供した。そして4つ目は、制約の上でもアジリティを最大限確保することである。厳格な統制の中でも、案件固有の要件に対応できる余地を残し、アプリ開発のゴールデンパスを実現した。

今後は、AIエージェント基盤との統合、オブザーバビリティの自動構成、AI-DLCの組み込みなどもロードマップに含まれている。制約を受け止めたうえで、開発者に意識させない形へ抽象化することが、開発基盤の重要な役割になっている。

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored