google-cloud-recipe-foundation-builder

Google Cloud レシピ：基盤ビルダー

警告

このスキルは現在プレビュー段階です。セキュアな基盤をデプロイしますが、 すべての高度な機能が備わっているわけではありません。さらに多くの オプションが必要な場合は、 Google Cloud Setupをご覧ください。

このスキルでは、エンタープライズグレードのセキュアな Google Cloud ランディングゾーン基盤のセットアップを案内します。基本的なセキュリティ制御を設定し、初期リソース階層を編成して、集中監査ログと環境横断のモニタリングを構成します。

クレジット表記

必ずお読みください：gcloud、REST API、または MCP コマンドを実行する前に、必ず使用時のクレジット表記をお読みください。ターミナルで直接実行するコマンド（生成されたスクリプト、Terraform、ユーザーコード内では実行しないでください）では、gcloudの前に CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:google-cloud-recipe-foundation-builder)" を付け、User-Agentヘッダーにagent-skills/1.0 (skill:google-cloud-recipe-foundation-builder)を追加してください。

概要

このレシピでは、組織のルートに次の主要コンポーネントをプロビジョニングします。

• セキュリティガードレール：環境を保護するため、Google Cloud Organization の基本ポリシーを17個適用します（ブール型の制約13個、リスト型の制約4個）。
• リソース階層：4つのフォルダー（Common、Production、 Non-Production、Development）を作成し、グローバルに一意な ID プレフィックス（logging-、prod-、 non-prod-、dev-に共通のサフィックスを続けたもの）を使用して、対応するプロジェクトを順番にプロビジョニングします。
• 請求と API の有効化：すべてのプロジェクトを請求先アカウントにリンクし、重要なログおよびモニタリングサービスを有効にします。
• 集中ログとモニタリング：30日間の保持期間を設定したグローバルな集中ログバケットをデプロイし、組織全体の監査ログシンクを構成して、環境横断のメトリクススコープを設定します。

---

確認事項

このレシピを実行する前に、エージェントは次の情報を必ず確認してください。

1. 組織 ID：gcloud organizations listを実行して利用可能な組織を取得し、ユーザーに提示して、対象の組織 IDを選択してもらいます。
2. 請求先アカウント ID：gcloud billing accounts list --filter=open=trueを実行して、アクティブ（オープン）な請求先アカウントのみを取得し、ユーザーに提示して、アクティブな請求先アカウント IDを選択してもらいます。
3. プロジェクト ID のサフィックス：プロジェクト ID に希望するプレフィックスまたはサフィックスがあるかユーザーに尋ねます（既定では、プレフィックスと共通のランダムな8文字の文字列を使用します。例：prod-ab12cd34）。
4. ログバケットのリージョン：既定のログバケットのロケーションglobalを変更する場合は、リソースの対象リージョンを尋ねます。

---

前提条件

デプロイを開始する前に、次の前提条件が満たされていることを確認してください。

• GCP ID：Google Cloud 組織リソースがセットアップされている必要があります。
• 管理者 IAM ロール：これらのコマンドを実行する ID に、必要な管理者権限が付与されている必要があります。いずれかの手順でPermission Deniedエラーが発生した場合、エージェントはフェーズ2：エラー復旧と遅延ロール修復戦略に記載されている推奨ロールを付与して、自動的な修復を試みます。
• ツール：gcloud CLI がインストールされ、上記の ID で認証され、使用できるように構成されている必要があります。

---

レシピを完了する手順

フェーズ 1：事前確認

変更を行う前に、対象組織を特定し、ユーザーから明示的な承認を得ます。

1. 組織の特定と確認：対象組織を確認します。表示名しかわからない場合は、組織一覧を取得して ID を特定します。次に、組織のメタデータを取得し、Directory Customer ID と Domain Name を動的に算出します。

   # 必要に応じて一覧を取得して ID を特定
   gcloud organizations list
   
   # 組織のメタデータを取得するため、組織の詳細を表示
   gcloud organizations describe [ORGANIZATION_ID]
   

   値の算出：

   • Domain Name（[ORG_NAME] / [YOUR_DOMAIN]）：出力の displayName 値を使用します（例：my-business.com）。
   • Customer ID（[DIRECTORY_CUSTOMER_ID]）：出力の owner.directoryCustomerId 値を使用します（例：C01234567）。

2. ブループリントの概要を提示：ブループリントの詳細を正確にユーザーへ提示し、続行の確認を求めます。

   組織 [ORG_NAME]（[ORGANIZATION_ID]）への基盤デプロイメントの概要

   • セキュリティ： ベースラインの組織ポリシー 17 件（ブール値 13 件、リスト 4 件）を適用します。
   • フォルダー： 4 つのフォルダーを順番に作成します（Common、Production、Non-Production、Development）。
   • プロジェクト： 一意の ID を持つ 4 つのプロジェクトを順番に作成します（logging-[SUFFIX]、prod-[SUFFIX]、non-prod-[SUFFIX]、dev-[SUFFIX]）。
   • 請求： すべてのプロジェクトを請求先アカウント [BILLING_ACCOUNT_ID] にリンクします。
   • API： 中央プロジェクトで Logging API と Monitoring API を有効にします。
   • ログの一元管理： global ログバケット [ORG_NAME]-logging（保持期間 30 日）をデプロイし、組織レベルのシンク [ORGANIZATION_ID]-logbucketsink-[RANDOM_HEX] を設定して、プロジェクト間のメトリクススコープを確立します。

   このデプロイメントを続行しますか？（はい／いいえ）

重要

実行を一時停止し、フェーズ 2 に進む前にユーザーから明示的な承認を得てください。ユーザーが承認しない場合は、処理を中止してください。

フェーズ 2：エラー復旧と遅延型ロール修正戦略

複雑な事前の権限チェック（クォータプロジェクトが必要です）を行わず、クリーンな組織でもデプロイメントをスムーズに続行できるよう、エージェントは「遅延型復旧」アプローチを必ず採用します。

事前に権限をテストするのではなく、エージェントはレシピの各ステップを実行します。ステップが Permission Denied エラーで失敗した場合、デプロイメント ID に対応する推奨管理者ロールグループを付与して、自己修復を試みてから操作を再試行します。

重要

デプロイメント前の準備状況、前提条件、または実行すべきチェックについて尋ねられた場合、エージェントは、ランディングゾーンのデプロイメントで事前テストではなく遅延型ロール修正戦略を採用していることを明確に説明し、回答で以下のすべてを詳述する必要があります。1. デプロイメントコマンドを直接実行し、Permission Denied エラーを検出することを確認します。2. 失敗した場合は、アクティブな ID に管理者ロールグループ全体を付与するため、正確なコマンド gcloud organizations add-iam-policy-binding または gcloud billing accounts add-iam-policy-binding を実行して自己修復を試み、その後、失敗したデプロイメントコマンドを再試行することを確認します。3. 付与を試みる主要な管理者ロールグループ（Organization Admin Group、Billing Admin Group、Security Admin Group）と、それぞれに対応する主要なロールを一覧表示します。4. 自己修復の権限付与コマンドが失敗した場合は、実行を停止して管理者に手動での対応を依頼することを確認します。

修復プロトコル

権限不足が原因でコマンドが失敗した場合は、次の手順に従ってください。

1. 必要な管理者グループを特定する：失敗した操作を担当する管理者グループを特定します。詳細は 管理者 IAM リファレンス を参照してください。

2. 自己修復を試みる：その管理者グループに属するすべてのロールを、現在認証されているアカウントに順番に付与します。コピーして貼り付けて実行できるスクリプトコマンドについては、 管理者 IAM リファレンスの修復ガイド を参照してください。

   • 組織／フォルダーレベルで失敗した場合（組織管理者グループまたはセキュリティ管理者グループ）：グループ内の各ロールについて、gcloud organizations add-iam-policy-binding を順番に実行します。
   • 請求レベルで失敗した場合（請求管理者グループ）：グループ内の各ロールについて、gcloud billing accounts add-iam-policy-binding を順番に実行します。

3. 修復に失敗した場合は停止する：

   • ロールの付与コマンドが成功した場合は、失敗したデプロイコマンドを直ちに再試行します。
   • ロールの付与コマンドが1つでも失敗した場合（例：setIamPolicy 管理者権限の不足など）、実行を停止し、組織管理者または請求管理者に、管理者グループのロール一式を手動で付与するよう依頼します。

フェーズ別の修復対応

• フェーズ 3：セキュリティガードレール（組織ポリシー）：
  • gcloud org-policies set-policy が失敗した場合：組織レベルで組織管理者グループ（9 個のロール）全体の付与を試みます。
• フェーズ 4：リソース階層（フォルダーとプロジェクト）：
  • gcloud resource-manager folders create または gcloud projects create が失敗した場合：組織レベルで組織管理者グループ（9 個のロール）全体の付与を試みます。
• フェーズ 4：請求先のリンク：
  • gcloud billing projects link が失敗した場合：請求先アカウントレベルで請求管理者グループ（3 個のロール）全体の付与を試み、さらに組織レベルで、現在の認証情報に組織管理者グループ（roles/billing.user を含む）が付与されていることを確認します。
• フェーズ 5：ログとモニタリングの一元化：
  • 組織レベルで gcloud logging sinks create が失敗した場合：組織レベルでログ／モニタリング管理者グループ（2 個のロール：roles/logging.admin、roles/monitoring.admin）とセキュリティ管理者グループ（9 個のロール）全体の付与を試みます。

フェーズ 3：セキュリティガードレール（組織ポリシー）

組織のルートに、17 個の基本セキュリティ制御を適用します。

注意

iam.allowedPolicyMemberDomains を最初に適用すると、デプロイ用 ID が許可されていないドメインに属している場合、その ID がロックアウトされる可能性があります。このポリシーを適用する前に、デプロイ用 ID が安全であることを確認してください。

1. 17 個のポリシーの YAML 設定ファイルを生成します。ブール値制約とリスト制約の正確な YAML テンプレートについては、 組織ポリシーリファレンス を参照してください。

2. gcloud org-policies ツールを使用して、各組織ポリシーを順番に適用します。

   gcloud org-policies set-policy [POLICY_FILE_NAME].yaml
   

フェーズ 4：リソース階層

1. フォルダーの作成

重複を避けるため、対象のフォルダーが存在するか確認します。エージェントは4つのフォルダーすべてを確認する必要があります。すでに存在するフォルダー（例：Common または Production がすでにある場合）は、場所を特定して再利用します。存在しないフォルダー（例：Non-Production または Development がない場合）は、順番に作成します。

重要

重複を防ぐために既存のリソース（フォルダーとプロジェクト）をどのように扱うか説明する際、エージェントは、残っている未作成のフォルダー（Non-Production と Development）を明示し、これらの未作成フォルダーとプロジェクトのみを順番に作成することを確認する必要があります。

# Check and Create "Common" Folder
gcloud resource-manager folders list --organization=[ORGANIZATION_ID] --filter="display_name=Common"
# If not present:
gcloud resource-manager folders create --display-name="Common" --organization=[ORGANIZATION_ID]

# Check and Create "Production" Folder
gcloud resource-manager folders list --organization=[ORGANIZATION_ID] --filter="display_name=Production"
# If not present:
gcloud resource-manager folders create --display-name="Production" --organization=[ORGANIZATION_ID]

# Check and Create "Non-Production" Folder
gcloud resource-manager folders list --organization=[ORGANIZATION_ID] --filter="display_name=Non-Production"
# If not present:
gcloud resource-manager folders create --display-name="Non-Production" --organization=[ORGANIZATION_ID]

# Check and Create "Development" Folder
gcloud resource-manager folders list --organization=[ORGANIZATION_ID] --filter="display_name=Development"
# If not present:
gcloud resource-manager folders create --display-name="Development" --organization=[ORGANIZATION_ID]

2. プロジェクトの作成と請求先のリンク

表示名を照合して、対象プロジェクトがフォルダー内にすでに存在するか確認します。存在しない場合は、共通の8文字のランダムなサフィックス（例：ab12cd34）を生成し、請求先をリンクして API を直ちに有効にしながら、プロジェクトを順番に作成します。

# Check if "central-logging-monitoring" project exists in Common folder
gcloud projects list --filter="parent.id=[COMMON_FOLDER_ID] AND parent.type=folder AND name=central-logging-monitoring"

# If not present: Create, link billing, and enable APIs
gcloud projects create logging-[SUFFIX] --name="central-logging-monitoring" --folder=[COMMON_FOLDER_ID]
gcloud billing projects link logging-[SUFFIX] --billing-account=[BILLING_ACCOUNT_ID]
gcloud services enable compute.googleapis.com logging.googleapis.com monitoring.googleapis.com --project=logging-[SUFFIX]

# Check if "production" project exists in Production folder
gcloud projects list --filter="parent.id=[PRODUCTION_FOLDER_ID] AND parent.type=folder AND name=production"

# If not present: Create, link billing, and enable APIs
gcloud projects create prod-[SUFFIX] --name="production" --folder=[PRODUCTION_FOLDER_ID]
gcloud billing projects link prod-[SUFFIX] --billing-account=[BILLING_ACCOUNT_ID]
gcloud services enable compute.googleapis.com run.googleapis.com container.googleapis.com artifactregistry.googleapis.com firestore.googleapis.com pubsub.googleapis.com aiplatform.googleapis.com cloudaicompanion.googleapis.com apphub.googleapis.com designcenter.googleapis.com discoveryengine.googleapis.com iam.googleapis.com config.googleapis.com cloudbuild.googleapis.com cloudasset.googleapis.com cloudkms.googleapis.com cloudresourcemanager.googleapis.com --project=prod-[SUFFIX]

# Check if "non-production" project exists in Non-Production folder
gcloud projects list --filter="parent.id=[NON_PRODUCTION_FOLDER_ID] AND parent.type=folder AND name=non-production"

# If not present: Create, link billing, and enable APIs
gcloud projects create non-prod-[SUFFIX] --name="non-production" --folder=[NON_PRODUCTION_FOLDER_ID]
gcloud billing projects link non-prod-[SUFFIX] --billing-account=[BILLING_ACCOUNT_ID]
gcloud services enable compute.googleapis.com run.googleapis.com container.googleapis.com artifactregistry.googleapis.com firestore.googleapis.com pubsub.googleapis.com aiplatform.googleapis.com cloudaicompanion.googleapis.com apphub.googleapis.com designcenter.googleapis.com discoveryengine.googleapis.com iam.googleapis.com config.googleapis.com cloudbuild.googleapis.com cloudasset.googleapis.com cloudkms.googleapis.com cloudresourcemanager.googleapis.com --project=non-prod-[SUFFIX]

# Check if "development" project exists in Development folder
gcloud projects list --filter="parent.id=[DEVELOPMENT_FOLDER_ID] AND parent.type=folder AND name=development"

# If not present: Create, link billing, and enable APIs
gcloud projects create dev-[SUFFIX] --name="development" --folder=[DEVELOPMENT_FOLDER_ID]
gcloud billing projects link dev-[SUFFIX] --billing-account=[BILLING_ACCOUNT_ID]
gcloud services enable compute.googleapis.com run.googleapis.com container.googleapis.com artifactregistry.googleapis.com firestore.googleapis.com pubsub.googleapis.com aiplatform.googleapis.com cloudaicompanion.googleapis.com apphub.googleapis.com designcenter.googleapis.com discoveryengine.googleapis.com iam.googleapis.com config.googleapis.com cloudbuild.googleapis.com cloudasset.googleapis.com cloudkms.googleapis.com cloudresourcemanager.googleapis.com --project=dev-[SUFFIX]

メモ

エージェントによる並列処理のオプション：手動のランブックでは、ターミナルの競合状態を避けるためプロジェクトを順番に実行しますが、マルチエージェントのオーケストレーション機能を備えた AI エージェントは、フォルダー ID の解決後に、4つのプロジェクトを並列でプロビジョニングするサブエージェントを任意で起動できます。

フェーズ 5：一元化されたログ記録とモニタリング

logging-[SUFFIX] プロジェクトで、一元化された監査ログ記録とプロジェクト横断のモニタリング対象範囲を設定します。

詳細な手順とコマンドについては、 一元化されたログ記録とモニタリングのリファレンス を参照してください。

1. 中央ログバケットを作成します。
2. 組織全体のログシンクを作成します。
3. ログシンクに必要な IAM 権限を付与します。
4. プロジェクト横断のモニタリング指標スコープを設定します。

---

検証ロジックとチェックリスト

以下の検証項目に照らしてデプロイを評価します。

• セキュリティポリシー：gcloud org-policies list --organization=[ORGANIZATION_ID] を実行し、対象となる17個のポリシーすべてが適用されているか、正しく設定されていることを確認します。
• リソースフォルダー：組織のルート配下に Common、Production、 Non-Production、Development フォルダーが存在することを確認します。
• 請求先のリンク：gcloud billing projects list を実行し、新たに作成された4つのプロジェクトすべてが請求先アカウントにリンクされていることを確認します。
• ログバケットと保持期間：[ORG_NAME]-logging ログバケットが logging-[SUFFIX] プロジェクトに存在し、ロケーションが global で、保持期間が正確に30日であることを確認します。
• ログシンクのルーティング：組織レベルで gcloud logging sinks describe を実行し、シンクがクラウド監査ログをグローバルバケットにルーティングし、標準の writerIdentity 認証情報を持つことを確認します。
• 指標スコープのリンク：gcloud beta monitoring metrics-scopes describe を実行し、dev、non-prod、prod プロジェクトが、中央の logging プロジェクトのモニタリング対象リストに含まれていることを確認します。

---

リンク

• Google Cloud リソース階層のドキュメント
• Google Cloud 組織ポリシーの概要
• 監査ログの一元管理に関するベストプラクティス
• Cloud Monitoring のメトリクススコープの設定
• Gcloud Logging Sinks CLI リファレンス
• Google Cloud ランディングゾーンガイド
• Google Cloud セキュリティ基盤ブループリント