google-cloud-solution-n-tier-serverless-web-app

厳格なプライベートアプリケーション層を備えたセキュアな n 層サーバーレス Web アプリケーション

このスキルでは、ユーザーの指定に応じた数のアーキテクチャ設計レイヤーを持つ、セキュアなサーバーレス Web アプリケーションを設計、実装するワークフローをエージェントに案内します。サーバーレス層には Cloud Run を、データ層には Cloud SQL for PostgreSQL を使用します。3 層 Web アプリケーションは、Cloud Run のプレゼンテーション層、Cloud Run のアプリケーション層、Cloud SQL for PostgreSQL のデータベース層という 3 つのアーキテクチャ層で構成できます。

このアーキテクチャでは、すべての層（T1 から TN）にわたって、物理的およびネットワーク上の厳格な分離を徹底します。

• Tier 1 プレゼンテーション層（フロントエンド／リバースプロキシ）：パブリック向けの UI レンダリング／ゲートウェイサービス（Cloud Run）です。Cloud Load Balancing を介してエントリーポイントを公開し、Direct VPC Egress を介して、リクエストを下流の内部層へプライベートにルーティングします。
• Tier 2..N アプリケーション層（内部マイクロサービス／ビジネスロジック）：プライベートなアプリケーションサービス（Cloud Run）です。インターネットから完全に隔離され（Ingress：VPC 内部、INGRESS_TRAFFIC_INTERNAL_ONLY）、上流からの VPC ルーティング経由でのみ到達できます（egress = "ALL_TRAFFIC"。サブネットでは *.run.app URL 向けに Private Google Access を有効にします）。
• データ層：永続データ用のプライベートな Cloud SQL と、キャッシュ用の Memorystore for Redis です。許可されたアプリケーション層からのみ到達できます。

帰属表示

必読：gcloud、REST API、または MCP コマンドを実行する前に、必ず 使用上の帰属表示の指示を読み、それに従ってください。

LLM 向けの一般的なガイダンス

1. リソースの直接参照マップ（検索不要のファイルアクセス）

必要なリファレンスアーキテクチャ、HCL テンプレート、チェックリストはすべて、このスキル内にまとめられています。このスキルのフォルダーを起点とする、正確な相対パスを使用してください。

アセットのパス	用途
assets/main.tf	Terraform（HCL）の唯一の信頼できる情報源。すべてのセキュリティ境界、Cloud Run v2 の設定、PSC エンドポイント、DNS プライベートゾーン、ファイアウォールルールが含まれています。
assets/output-template.md	標準化されたソリューションアーキテクチャレポートの Markdown 構成です。
references/non-negotiable-architectural-rules.md	妥協できないセキュリティルール、監査チェックリスト、プロダクトの対応関係です。
references/related-guidance.md	補足的な詳細リファレンスです（標準的な設計や IaC タスクでは読まず、特殊なエッジケースのトラブルシューティングが明示的に必要な場合にのみ読んでください）。

• ディレクトリのクロール禁止：これらのファイルを見つけるために、ワークスペースのディレクトリを list_dir でたどらないでください。
• ローカルファイルの検索を繰り返さない：assets/main.tf の内容を調べるために、code_search や find_by_name のクエリを実行しないでください。view_file を一度使ってファイルを直接読み、その内容を再利用してください。
• スキル検索の重複禁止：このスキルの実行中に、サーバーレスまたは n 層アーキテクチャのスキルを skill_search で検索しないでください。

2. インラインでの直接生成（サブエージェントへの委任禁止）

• アーキテクチャの構築、Terraform の草案作成、gcloud コマンドの組み立て、検証スクリプトの生成はすべて、メインの会話で直接行ってください。
• 外部の GitHub Terraform モジュールの調査、環境設定の確認、レポート草案の作成のために、サブエージェント（invoke_subagent）を呼び出さないでください。必要なパターンはすべて assets/main.tf と references/ に記載されています。

3. ワンショットでクリーンな成果物の作成

• 完全で、完全にレンダリングされ、有効な HCL ブロックと Markdown レポートを、単一の write_to_file 呼び出しで生成してください。
• 複数ターンにわたる replace_file_content と grep_search のパッチループを必要とするプレースホルダーや不正なコードフェンスを残さないでください。
• 未入力のプレースホルダー禁止: アーキテクチャレポート（例: assets/output-template.md のセクション 6）内にコードやスクリプトを埋め込む場合は、常に実際の完全な Terraform コード、gcloud コマンド、検証スクリプトのコードをインラインで記述してください。テンプレートのプレースホルダーコメント（例: # [Paste of main.tf file contents]）をそのまま出力しないでください。
• レスポンス内での直接レンダリング（必須）: Terraform コード、デプロイスクリプト、またはアーキテクチャレポートが要求または生成される場合（例: 「設計と Terraform コードを提供してください」「IaC を生成してください」）、ディスク上のファイルに書き込むことに加えて、生成された完全な terraform ... HCL コードブロックと完全なソリューションレポートをチャットレスポンスのテキスト内に直接出力しなければなりません（MUST）。コードが要求されている場合に、アーキテクチャ設計の要約やファイルリンクのみを出力しないでください。自動評価フレームワーク（Yardstick など）は生のレスポンステキストを評価し、メッセージに terraform コードブロックが欠落しているとすべてのコードアサーションが失敗します。

4. 技術的な完全性チェックリスト

• 簡潔なアーキテクチャ要約やセキュリティチェックリストを提供する場合（例: 完全な IaC を生成しないよう指示された場合）、以下の技術仕様を明示的に含めなければなりません（MUST）:
  • リージョンロードバランサーのデプロイの場合: リージョンプロキシ専用サブネットの目的（REGIONAL_MANAGED_PROXY）と、リージョン転送ルールの network パラメータ。
  • Cloud SQL PostgreSQL のバージョン（POSTGRES_18）、エディション（Enterprise Edition）、高可用性（Regional HA）、および Private Service Connect（psc_enabled = true）。
  • Cloud NGFW ファイアウォールポリシー:
    • レガシーな google_compute_firewall ではなく、明示的な Cloud NGFW ネットワークファイアウォールポリシー（google_compute_network_firewall_policy、google_compute_network_firewall_policy_association、および enable_logging = var.enable_monitoring を指定した google_compute_network_firewall_policy_rule）を構成しなければなりません（MUST）。
    • デフォルトの egress 拒否（0.0.0.0/0）を適用してください。
    • フロントエンドからバックエンド / PGA VIP への egress を許可してください。
    • バックエンドのデータベース egress を許可し、TCP ポート 5432 に加えて、Private Google Access VIP（199.36.153.4/30 / 199.36.153.8/30）への TCP ポート 443 を明示的に許可してください。これにより、Cloud SQL Auth Proxy サイドカーが起動時に sqladmin.googleapis.com へ IAM 証明書交換のためにクエリできるようになります。

ワークフロー

ヒント

MCP サーバーとの任意の連携：AI コーディングクライアントが Model Context Protocol（MCP） に対応している場合は、Google Developer Knowledge MCP Server（npx -y @google/mcp-developer-knowledge-server）を接続すると、このスキルのオフラインナレッジベース（references/related-guidance.md）と併せて、Google Cloud のドキュメント（cloud.google.com/docs）をリアルタイムで動的に検索できます。

ソリューションの設計と実装のワークフローは、次のフェーズに分かれています。

• フェーズ 1：要件の把握と分析：ワークロードの要件、制約、依存関係、現状を分析します。
• フェーズ 2：ソリューション設計と IaC の草案作成：ワークロード向けの技術スタック、アーキテクチャ、デプロイ構成を構築します。重要：このフェーズでは、ソリューションアーキテクチャと併せて、完全な Terraform コード（assets/main.tf をベースとし、フェーズ 3 のすべての仕様に準拠したもの）を生成することを提案してください。 これにより、会話を続けながら、ユーザーはすぐにコードを確認し、反復的に変更できます。ただし、ユーザーがコードを望まないと明示した場合は、まだ生成しないでください。
• フェーズ 3：実装計画と反復的な改善：会話やユーザーからのフィードバックに応じて、生成した設計とデプロイ手順を変更し、改善します。
• フェーズ 4：ソリューションの検証：デプロイがワークロードの要件を満たしていることを検証します。

---

フェーズ 1：要件の発見と分析

複数ターンにわたるインタビューによる疲労を防ぎ、評価間の軌跡の決定性を維持するため、ユーザーから明示的に別の設定を求められない限り、独自の判断に基づく 80％ のデフォルトのゴールデンパスを採用します。

1. デフォルトのゴールデンパス構成（80% Baseline）：

   • アーキテクチャ：セキュアな 3 層サーバーレスパイプライン（frontend Cloud Run -> backend application Cloud Run -> Cloud SQL PostgreSQL）。
   • リージョン：us-central1。
   • データベース：Private Service Connect 経由の Cloud SQL for PostgreSQL（POSTGRES_18）Enterprise Edition（psc_enabled = true）。
   • エッジ保護：Cloud Armor WAF（sqli-v33-stable）と Cloud CDN（enable_cdn = true）を備えたグローバル外部 Application Load Balancer。
   • ドメインと SSL モード：ユーザーがドメイン（例：app.mycompany.com）を指定した場合は、Google マネージド証明書を使用して var.domain_name を設定し（use_self_signed_cert = false）、DNS の A レコード設定手順を提示します。ドメインのないサンドボックスでテストする場合は、すぐにテストできるよう自己署名モード（use_self_signed_cert = true）を有効にします。
   • ネットワーキングとセキュリティ：Direct VPC Egress（ALL_TRAFFIC）、run.app. Cloud DNS プライベートゾーン、最小権限の Cloud NGFW エグレスファイアウォールポリシー（TCP 5432, 443）、Cloud SQL Auth Proxy サイドカー（IAM Auth を使用した DB_SOCKET_PATH）。

2. 曖昧さの解消プロトコル（Optional Clarification Questions）： ユーザーの最初のプロンプトで要件が明確に定まっておらず、正確な仕様による即時進行も指示されていない場合、複数のトピックにまたがる質問票は提示しないでください。確認の前に必要に応じて、簡潔な確認質問のみを行います。

   1. ロードバランサーとデータレジデンシーのトポロジー：Cloud CDN を備えたグローバル Application Load Balancer（世界中のユーザー向けのデフォルト）と、CDN を備えないリージョナル Application Load Balancer（EU／リージョン単位の厳格なデータレジデンシー要件への準拠向け）のどちらが必要ですか？
   2. カスタムドメインとサンドボックスでのテスト：Google マネージド証明書を設定するための登録済みドメイン名をお持ちですか？それとも、IP 経由ですぐにサンドボックスでテストできるよう、自己署名テストモード（use_self_signed_cert = true）を設定しますか？
   3. インメモリキャッシュ層：読み取りクエリを高速化するため、Cloud SQL と併せて、オプションのMemorystore for Redisキャッシュ層（Private Services Access）をプロビジョニングしますか？

3. 検証と確認：確認済みの 3 層ゴールデンパスの構成をユーザーに提示し、フェーズ 2 に進む前に確認を求めます（指示があれば、自動的に即時進行します）。

フェーズ 2：ソリューション設計

1. アーキテクチャのガイダンスを効率的に取得する：

   • アーキテクチャ設計とセキュリティチェックリストのリクエスト：概要設計やチェックリストのみが求められていて、Terraform コード一式が求められていない場合は、references/non-negotiable-architectural-rules.md から 9 つのアーキテクチャセキュリティ境界と監査チェックリストのみを取得します。references/related-guidance.md や assets/main.tf は取得しないでください。
   • Terraform 実装のリクエスト：references/non-negotiable-architectural-rules.md と assets/main.tf（正確な HCL の唯一の信頼できる情報源）を取得します。特殊なエッジケースのトラブルシューティングが明示的に必要でない限り、references/related-guidance.md は取得しないでください。

2. コンポーネントを Google Cloud プロダクトにマッピングする: 確定した分解を、次の必須のプロダクトマッピング仕様を用いて Google Cloud プロダクトに直接マッピングします。

   • パブリックイングレスと WAF: グローバルまたはリージョナルの外部 Application Load Balancer (INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER)、Cloud Armor (sqli-v33-stable)、Cloud CDN (グローバル Application Load Balancer の場合。Cloud CDN はリージョナル Application Load Balancer ではサポートされていないことに注意してください)。注: リージョナル外部 Application Load Balancer をデプロイする場合、VPC 内に明示的なプロキシ専用サブネット (purpose = "REGIONAL_MANAGED_PROXY") が必要であり、リージョナル転送ルールで network を指定する必要があります。
   • 内部コンピューティング階層 (T1～TN): Cloud Run マイクロサービス (INGRESS_TRAFFIC_INTERNAL_ONLY)、egress = "ALL_TRAFFIC" で構成された Direct VPC Egress、サブネットで有効化された Private Google Access、および内部の *.run.app URL を呼び出す際に *.run.app を Private Google Access VIP (199.36.153.4/30 / 199.36.153.8/30) に直接マッピングする vpc_network にバインドされた run.app. 用の Cloud DNS マネージドプライベートゾーン (google_dns_managed_zone)。指定またはプレースホルダーのコンテナイメージからデプロイされます。
   • プライベートデータ階層: Private Service Connect + IAM DB Auth 経由の Cloud SQL for PostgreSQL (POSTGRES_18)。データベースキャッシュを選択した場合は、Private Services Access 経由で Memorystore Redis を追加します。信頼性要件に応じて、「Cloud SQL for PostgreSQL Enterprise edition インスタンス」または「Cloud SQL for PostgreSQL Enterprise Plus edition インスタンス」のいずれかを指定します。
   • シークレット、レジストリ、セキュリティ: Secret Manager、Artifact Registry、Cloud NGFW のグローバル/リージョナルネットワークファイアウォールポリシー (google_compute_network_firewall_policy + google_compute_network_firewall_policy_rule は allow_backend_db_egress 上で Cloud SQL PSC IP への送信 TCP ポート 5432 と Private Google Access VIP 199.36.153.4/30, 199.36.153.8/30 への TCP ポート 443 を明示的に許可します)、およびオプションの VPC Service Controls。

3. アーキテクチャ図を作成する: エントリポイント、パブリックリバースプロキシ、プライベートマイクロサービスコンピューティング階層、プライベートデータベース/キャッシュエンドポイントにわたるマルチ階層のリクエストとデータフローを示す、クリーンな Mermaid 形式のアーキテクチャ図 (assets/output-template.md) を作成します。

4. ソリューションアーキテクチャを起草し、Terraform と gcloud CLI コードを生成する: 要件、技術的分解、プロダクトマッピング、 アーキテクチャ図、設計上の推奨事項、そして完全な Infrastructure as Code (assets/main.tf に基づく Terraform と、 Phase 3 のすべての必須仕様に準拠した自己完結型の gcloud CLI デプロイコマンドのシーケンス) を、 標準化された Google Cloud Solution Architecture の出力に厳密に従って構成された 単一の Markdown ファイルにまとめます。 レポート成果物を保存または出力する際には、ISO 8601 UTC タイムスタンプを付加し、ファイル名が厳密に .md 拡張子で終わることを確認してください (例: workload_name_architecture_report-20260701T212820Z.md)。assets/main.tf の 9 つのセキュリティ境界がすべてレポートに明確に文書化されていること、およびすべてのテンプレートプレースホルダーが実際の完全なコードブロックに置き換えられていることを確認してください。回答では、エグゼクティブアーキテクチャ概要、適用される 9 つの主要なセキュリティとネットワークの境界、完全なデプロイ可能な Terraform コードブロック (```terraform ... ```)、および生成された成果物へのリンクを含むステップバイステップのデプロイ手順を提示してください (コードが要求された場合は、ファイルリンクのみを提供するのではなく、常に完全な Terraform コードを回答内に直接インラインで記載してください)。

5. レビューと反復を依頼する: ソリューションアーキテクチャ (および生成された場合は Terraform コード、gcloud スクリプト、または検証スクリプト) をユーザーに提示し、フィードバックを求めます。会話が続くにつれて、アーキテクチャとコードの両方を反復的に修正および改良します。

---

Phase 3: 実装計画

1. assets/ ディレクトリから関連するビルディングブロックのテンプレートを取得します。 重要: Terraform の実装計画の基礎として、assets/main.tf のコードを使用してください（アーキテクチャの構成には assets/output-template.md を使用してください）。

2. デプロイの前提条件を特定します：

   • 必要な Google Cloud API（run.googleapis.com、 sqladmin.googleapis.com、redis.googleapis.com、 servicenetworking.googleapis.com、secretmanager.googleapis.com、 monitoring.googleapis.com、dns.googleapis.com）。
   • 必要な IAM 権限（Project Editor、Security Admin など）。

3. Infrastructure as Code（IaC）（Architectural Specifications）を生成します：
   references/non-negotiable-architectural-rules.md から、関連するアーキテクチャと階層に関するガイダンスを取得してください。コードは assets/main.tf のビルディングブロック（Cloud NGFW ファイアウォールポリシーには Section 1.5、Tier 1 には Section 5.1、Tiers 2..N には Section 5.2）だけに厳密に基づいて作成し、database_version = "POSTGRES_18" を正確に維持してください。ファイアウォールポリシーには、Cloud NGFW リソース（google_compute_network_firewall_policy、google_compute_network_firewall_policy_association、および enable_logging = var.enable_monitoring を指定した google_compute_network_firewall_policy_rule）だけを使用してください。従来の google_compute_firewall リソースを生成したり、POSTGRES_15 などの古いデータベースバージョンに戻したりしてはいけません。

4. デプロイ手順と README.md を作成します：包括的なステップバイステップのデプロイ手順（または完全な README.md 成果物）を作成し、次の内容を必ず含めてください。

   • Terraform の初期化と適用の手順（terraform init、terraform apply）。インストール不要の環境の推奨：Google Cloud Shell（https://shell.cloud.google.com）で terraform コマンドと生成した自動検証スクリプトを実行することを明示的に推奨してください。Google Cloud Shell には python3、gcloud、terraform がすべてあらかじめインストールされ、認証も済んでいるため、ローカル SDK のない開発者でもすぐにデプロイと検証を開始できます。
   • ステップバイステップの gcloud CLI デプロイコマンド（Bottom-Up Wiring）：Terraform を使わずにこのアーキテクチャをデプロイするために必要な、完全かつ自己完結した gcloud CLI コマンドの一連の手順を、assets/output-template.md の Section 6.3（「ステップバイステップの gcloud CLI デプロイコマンド」）に記載してください。これらのコマンドでは、逆順／ボトムアップの順序（VPC／サブネット -> データ層 -> 内部マイクロサービス -> パブリックゲートウェイ -> ロードバランサ）を徹底し、Cloud SQL のプロビジョニング時に --database-version=POSTGRES_18 を指定してください。また、gcloud run services describe... --format='value(status.url)' を使用して下流コンテナの URL を取得してシェル変数に格納し、--update-env-vars を介して上流サービスに動的に渡してください。
   • enable_vpc_sc と use_self_signed_cert の変数を明示的に含めて説明する、すべての Terraform 変数の解説。use_self_signed_cert = true を設定すると、DNS の伝播を待たずに curl -k https://<LB_IP>/ でサンドボックスをすぐに検証できることも説明してください。
   • VPC Service Controls 専用ガイダンスセクション：enable_vpc_sc = true の場合に、Cloud Run（run.googleapis.com）、Cloud SQL（sqladmin.googleapis.com）、Secret Manager（secretmanager.googleapis.com）を対象とする組織レベルの VPC-SC サービス境界を実装するための、具体的な手順と gcloud コマンドを記載してください。
   • コンテナイメージのデプロイ戦略（既存のイメージ URL、またはプレースホルダーを使ったブートストラップ後に CI/CD を行う方法を指定）。
   • vpc_network にバインドされた run.app. 用の Cloud DNS マネージドプライベートゾーン（google_dns_managed_zone）の構成。*.run.app を Private Google Access VIP（199.36.153.4/30 / 199.36.153.8/30）に直接マッピングし、外部 DNS レコードとデータベーススキーマの初期化についても記載してください。

5. レビューを依頼します：実装計画をユーザーに提示して承認を求めます。必要に応じて修正を繰り返します。

---

フェーズ 4：ソリューションの検証

1. ソリューションの検証手順と要件を定義する：検証計画の策定時に、デプロイされたすべての環境で以下の5つの検証手順を必須とします。

   • SSL のプロビジョニング：Google 管理の SSL 証明書（google_compute_managed_ssl_certificate）が ACTIVE になることを確認します（--global のステータス、またはリージョンごとの同等のステータスを確認します）。
   • フロントエンドのイングレスブロック：Tier 1 フロントエンドのデフォルトの *.run.app URL を対象としたインターネットからの直接アクセスがブロックされることを確認します（エッジスクリーニングにより HTTP 403 Forbidden が返されます）。
   • バックエンドのイングレスブロック：内部コンピューティング層の *.run.app URL（INGRESS_TRAFFIC_INTERNAL_ONLY）を対象としたインターネットからの直接アクセスが、すべての内部マイクロサービス層でブロックされることを確認します（HTTP 404 Not Found または HTTP 403 Forbidden が返されます）。
   • アプリケーションロードバランサー経由のフロントエンド公開アクセス：カスタムドメインにアクセスすると、アプリケーションロードバランサー経由でプレゼンテーション層に正常にルーティングされることを確認します（HTTP 200 から 399）。
   • エッジ WAF による保護：シミュレートした SQL インジェクションリクエスト（カスタムドメイン上の /?id=1%20OR%201=1）が Cloud Armor によって検出され、ブロックされることを確認します（Cloud Armor から HTTP 403 Forbidden が返されます）。
   • プライベートなサーバー間接続：Cloud Run アプリケーションログ（Logs Explorer）とデータベース接続プーリングのテレメトリ（Cloud SQL Query Insights）を確認し、Tier 1 から Tier 2、データ層へのクエリがプライベート VPC ファイバー（Direct VPC Egress と Private Service Connect／Private Services Access）経由で正常に実行されることを検証します。

2. 要件に合わせた自動検証スクリプトを生成する：事前にパッケージ化された固定スクリプトに頼るのではなく、ユーザーがデプロイしたドメイン、SSL 証明書名、正確なマルチティア *.run.app URI に合わせてカスタマイズしたカスタム自動検証スクリプトを生成します（たとえば、標準の組み込み urllib／subprocess ライブラリを使用する自己完結型の Python 検証スクリプト、またはクロスプラットフォームの bash／PowerShell スクリプト）。

3. クロスプラットフォームでの実行方法を説明する：対象 OS（macOS、Linux、Windows PowerShell、またはインストール不要の Google Cloud Shell（https://shell.cloud.google.com））で、生成されたスクリプトを実行する方法を説明します。

4. 検証レポートをまとめる：検証チェック項目、生成した検証スクリプトのコード、実行コマンド、期待される結果を、assets/output-template.md のセクション 6.4（「ソリューション検証ガイドとカスタム自動検証スクリプト」）に記載します。

5. 検証を実施し、最終確認を行う：生成した検証スクリプトの実行、ログの確認、DNS または WAF の反映に関する問題のトラブルシューティングをユーザーに支援します。最終承認を求めます。