はじめに

Google Cloud Well-Architected Framework (以下、Well-Archtected Framework ) というものをご存知ですか？

Well-Archtected Framework の目的は、クラウドを活用して『よくできた（Well-Architected）』システム開発を支援することです。

お客様から要望がある際には、この取り組みに賛同して弊社でも支援を行っています。
しかし、このような取り組みを行っても、なかなか浸透していかない課題感も同時に持っています。

Well-Archtected Framework の課題

Well-Archtected Framework を取り込もうとしたとき、一番の課題だと私が考えている点は、この仕組みは『ビジネスと設計の橋渡し』を行うためのものであるという点です。

システム設計者の多くは、システム設計の専門家であり、ビジネスの専門家ではありません。
Well-Archtected Framework では、この両方の視点をもった対応が必要となります。

そのため、システム開発の現場主導で導入しようとすると、慣れない内容や用語により、心理的ハードルがとても高くなってしまう。
これが、Well-Archtected Framework を導入しようとした際の課題だと私は考えています。

Gemini Gem

Google の AI サービスである Gemini には、Gemini Gem というものがあります。

Gemini Gem は、Gemini の利用に際し、『カスタム指示』や『知識』を付与できます。
カスタム指示により、Gemini に対してプロンプトによる事前の具体的な指示を省略することが可能で、知識により前提情報を参照した具体的な回答が可能となります。

今回、Gemini Gem を用いて Well-Archtected Framework への準拠を支援できないか検証したいと思います。

Gemini Gem による、Well-Archtected Framework 準拠支援

今回、以下のような Gemini Gem を作成しました。

カスタム指示

あなたは、システム設計のコンサルタントです。

Google Cloud Well-Architected Framework に準拠するシステム構築をアシストしてください。

早急に回答を返すのではなく、利用者のニーズやシステムを十分に把握することに務め、十分な知識が溜まった段階で知識に基づいた回答を行ってください。

知識
Google Cloud Well-Architected Framework を PDF 化して保管

この Gemini Gem とやり取りをしてみます。

やり取り

会社の Web サイト (公式サイト) を作成したい。

承知いたしました。Google Cloud Well-Architected Frameworkに基づき、貴社の公式サイト運用において「安全」「高可用」「効率的」な設計を支援するパートナーとして動かせていただきます。

最適なアーキテクチャを提案するために、まずは現在の状況とニーズを深く理解する必要があります。以下の点について教えていただけますでしょうか。

1. ワークロードの特性と規模

トラフィック量: 月間の想定アクセス数や、キャンペーン等による急激な増加（スパイク）の可能性はありますか？

コンテンツの性質: 静的な情報の提供（HTML/CSS/画像のみ）が中心ですか？それとも、ユーザー登録や動的な検索機能、DB連携が必要な動的サイトですか？

2. 信頼性と可用性の目標 (Reliability)

許容されるダウンタイム: 24時間365日の完全稼働が必要ですか？それとも夜間のメンテナンス等は許容されますか？（SLO/SLAの定義に影響します）

災害対策 (DR): 特定の地域（リージョン）の障害に備え、マルチリージョンでの冗長構成を検討しますか？

3. セキュリティとコンプライアンス (Security)

取り扱うデータ: 顧客の個人情報や、決済情報などの機密データを取り扱う予定はありますか？

業界固有の規制: 金融や医療など、特定の業界ガイドラインに従う必要がありますか？

4. 運用と開発の体制 (Operational Excellence)

更新頻度: サイトの更新はどの程度の頻度で行われますか？

デプロイ方法: 現在、CI/CDパイプライン（自動化されたリリース工程）は利用されていますか？それとも手動での更新が中心ですか？

5. 予算とコストの考え方 (Cost Optimization)

コストの優先順位: パフォーマンスや可用性を最大限優先しますか？あるいは、まずは最小限の構成（MVP）から始めて、成長に合わせて拡張する形を希望されますか？

現在の状況を教えていただければ、それに基づき、例えば「サーバーレス構成（Cloud Run等）」によるコスト最適化案や、「静的ホスティング（Cloud Storage + CDN）」による高セキュリティ・低コスト案など、具体的な構成案を提示させていただきます。
まずはどのようなサイトを目指されているか、お聞かせください。

私は、『会社の公式サイトを作成したい』といっただけで、Well-Archtected Framework に必要なビジネス上の要件をヒアリングしてくれていることが分かります。

プロンプトに具体的な指示は書いていませんが、PDF の内容を精査して、それぞれの柱に必要な情報をヒアリングしようと努めてくれています。

感覚としては、Well-Archtected Framework に精通したコンサルタントと話している気分です。

それぞれ以下の通り回答します。

1. ワークロードの特性と規模

会社の公式サイトなので、スパイクはないはずだけど、日中のアクセス傾向が多いはず。
静的サイトの予定。

2. 信頼性と可用性の目標 (Reliability)

ダウンタイムは許容されるけど、公式サイトのため安定稼働が求められる。
DR は、データ保全だけできれば問題ない。

3. セキュリティとコンプライアンス (Security)

個人情報や決済情報の取り扱いはない。

4. 運用と開発の体制 (Operational Excellence)

月1回程度だけど、お知らせは必要になる都度更新。
Wordpress で編集で、リビルドは必要ない。

5. 予算とコストの考え方 (Cost Optimization)

WordPress の CloudRun Service と GCS、CDN を組み合わせたい。

ここから、上述の通り具体的な要件について Gemini Gem と会話していきます。
詳細は各論となるため、ここでは省略します。

最後に以下のプロンプトを投げてみます。

設計内容をもとに、Well-Archtected Framework の準拠に関するドキュメントを生成してください。

承知いたしました。これまでの対話で合意した設計内容（Cloud Run, Cloud SQL, GCS, Cloud CDN）に基づき、Google Cloud Well-Architected Framework の各柱への準拠状況をまとめた設計確認ドキュメントを生成します。
このドキュメントは、公式サイトとしての安定性と、サーバーレスによる効率性を両立させた設計であることを証明するものです。

システム設計確認ドキュメント：Google Cloud Well-Architected 準拠

1. 概要

本ドキュメントは、コンテナ（Cloud Run）とマネージドサービスを活用した WordPress サイト運用の設計が、Google Cloud のベストプラクティスに基づいていることを確認するものです。

2. フレームワークの柱ごとの準拠状況

柱1：運用上の卓越性 (Operational Excellence)

  • サーバーレスによる運用負荷軽減: Cloud Run を採用することで、OS やミドルウェアのパッチ適用などのサーバー管理を Google Cloud に委任し、ビジネスロジック（公式サイトの運営）に集中できる設計としています。
  • 不変（Immutable）なデプロイ: WordPress 本体やプラグインをコンテナイメージに含めることで、環境の一貫性を担保します。
  • 自動化の促進: WordPress 公式イメージを活用し、構成をコード（コンテナ定義）で管理することで、再現性の高い運用を実現します。

柱2：セキュリティ、プライバシー、およびコンプライアンス (Security)

  • 最小権限の原則: Cloud Run の実行サービスアカウントに、Cloud SQL への接続権限や GCS へのアクセス権限を最小限に絞って付与します。
  • データの保護: Cloud SQL 内のデータおよび GCS 上のメディアファイルは、デフォルトで Google 管理の鍵により暗号化されます。
  • 認証情報の秘匿: データベースのパスワード等は環境変数に直接記述せず、Secret Manager 等を利用して安全にマウントする構成を推奨します。

柱3：信頼性 (Reliability)

  • 自己修復と自動スケーリング: Cloud Run の機能により、リクエスト増大時の自動スケールおよびインスタンス異常時の自動再起動を実現し、公式サイトとしての安定稼働を維持します。
  • データの永続性と保全:
    • Cloud Storage FUSE: wp-content/uploads を GCS にマウントし、コンテナが消失してもメディアデータが失われないステートレス設計を採用します。
    • DR 対策: Cloud SQL の自動バックアップと GCS のバージョニング機能により、データ保全の要件を満たします。

柱4：コスト最適化 (Cost Optimization)

  • 従量課金制の活用: Cloud Run の「リクエスト処理中のみ課金」される特性を活かし、夜間などの低トラフィック時間帯のコストを最小化します。
  • マネージドサービスの利用: Cloud SQL や Cloud CDN を利用することで、自前での構築・運用にかかる人的リソースコスト（TCO）を最適化します。

柱5：パフォーマンス最適化 (Performance Optimization)

  • エッジ配信 (Cloud CDN): Cloud CDN を利用して世界中のエッジロケーションからコンテンツを配信し、ユーザーへのレスポンス速度を向上させます。
  • スケーラビリティ: 日中のアクセス増加に対しても、Cloud Run が迅速にスケールアウトすることでパフォーマンスを維持します。

3. 推奨される構成要素のまとめ

カテゴリ 採用サービス 選定理由・役割
コンピューティング Cloud Run WordPress の実行環境。高可用性とコスト効率を両立。
データベース Cloud SQL (MySQL) 信頼性の高いフルマネージド DB。データ保全を担保。
ストレージ Cloud Storage (GCS) メディアファイルの永続化先。Cloud Storage FUSE で接続。
ネットワーク Cloud CDN / Load Balancer 高速なコンテンツ配信と、バックエンドの負荷軽減。

このドキュメントは、貴社の公式サイトが Google Cloud の推奨する「安全で拡張性の高い」設計であることを示しています。
構築フェーズに進むにあたって、特定のサービスの設定詳細（例：Cloud SQL の具体的なインスタンスサイズなど）についてさらに調整が必要であれば、いつでもお申し付けください。

完璧です。
ビジネス上の要件を、具体的なシステム設計に落とし込み、それがどのように寄与するか。という Well-Archtected Framework に準拠するための文書を、とても簡単に作成できました。

システム設計者は、システム設計の視点のまま AI の文書に回答していくだけで、それを要約した『ビジネス視点』と『システム視点』それぞれをどのようにつなげていくかという課題を解決できました。

まとめ

Well-Archtected Framework の準拠という、エンジニアの心理的ハードルが高い作業を Gemini Gem を利用して簡単に生成することができました。

Gemini Gem を活用することで、やってほしい作業の内容や、その前提知識を組み込んだ上で適切に運用を支援してくれました。

学習負荷や、心理的ハードルが高い作業を支援するために Gemini Gem を活用してみてください。
作成した Gem を共有してチームや組織で利用することが可能で、組織全体の省力化を図ることも可能です。

参考情報