Resource Manager

解決する課題

プロジェクトが増えても、全社共通のルールと権限を破綻させずに統制できます。

• プロジェクトが数百に増え、権限や設定を一つずつ管理したくない → 上位階層でまとめて付与し継承させたい
• 部門・環境（本番／検証）ごとに境界を分けて整理したい
• 全社で「外部公開を禁止」などのガードレールを一括で効かせたい
• 退職・削除したプロジェクトを安全に復旧／恒久削除したい
• 課金・請求の単位を組織構造に合わせて管理したい

主要概念と用語

• 組織（Organization）: リソース階層の最上位ノード。Google Workspace または Cloud Identity のドメインに 1 対 1 で対応し、全社のルート境界になる。AWS Organizations の管理アカウント＋組織ルートに近い
• フォルダ（Folder）: 組織配下でプロジェクトをグループ化する中間ノード。部門・チーム・環境ごとの分割に使う。ネスト（入れ子）が可能。AWS の **OU（組織単位）**に相当
• プロジェクト（Project）: リソースを実際に入れる基本コンテナで、API 有効化・課金・IAM・割り当ての境界。AWS のアカウントに近い役割を担う
• リソース階層（Resource Hierarchy）: 組織 → フォルダ → プロジェクト → リソースという親子構造。IAM ロールと組織ポリシーはこの階層に沿って上位から下位へ継承される
• プロジェクト識別子: 一意で不変のプロジェクト ID、グローバルに不変の数値プロジェクト番号、変更可能な表示名の 3 種がある
• 組織ポリシー（Organization Policy）: 階層のノードにアタッチして挙動を制約するガードレール。Resource Manager が管理面を提供する
• タグ（Tags）: キーとバリューの組をリソースに付与し、条件付き IAM や組織ポリシーの判定に使えるメタデータ
• ライエン（Liens）: プロジェクトの誤削除を防ぐためのロック

仕様・制限・クォータ

• グローバルサービス（リージョンに依存せず、階層は全リージョン共通で参照される）
• プロジェクト ID はグローバルに一意かつ不変。一度作ると ID 自体は変更できず、削除後も一定期間は再利用を予約される
• フォルダはネスト可能だが、階層の深さ・1 ノード配下の数などに上限がある。プロジェクト数も組織あたりの割り当てで管理され、引き上げは申請が必要
• 組織がなくてもプロジェクトは作れるが、フォルダ・組織ポリシー・継承による一括統制は組織があって初めてフル活用できる
• プロジェクト削除は即時恒久削除ではなく、一定の保留期間つきソフト削除で、その間は復元できる
• API 名は cloudresourcemanager.googleapis.com。操作には対応する IAM ロール（例: roles/resourcemanager.projectCreator、roles/resourcemanager.folderAdmin など）が必要

内部の仕組み

Resource Manager は各リソースの親（parent）参照を保持し、組織・フォルダ・プロジェクトのツリーを構成します。IAM の許可ポリシーや組織ポリシーを評価する際、各サービスはこのツリーを下位から上位へさかのぼって有効な設定を合成します。

1. リソースに対する操作要求が来る
2. そのリソース → プロジェクト → フォルダ → 組織と親をたどって継承された IAM バインディングと組織ポリシーを集約
3. 合成結果に基づき許可・拒否やガードレールの制約を適用

設計パターン / ベストプラクティス

• 最初に組織を用意する: Cloud Identity / Workspace で組織ノードを作り、フォルダ・組織ポリシー・継承を使える土台を整える
• フォルダで意味のある境界を切る: 部門・チーム・環境（本番／ステージング／検証）でフォルダを分け、共通ルールは上位に、個別設定は下位に置く
• 環境ごとにプロジェクトを分離: 本番と非本番を別プロジェクトにし、課金・割り当て・障害の影響範囲（blast radius）を分離する
• 権限はグループ＋上位階層で: 個人ではなくグループに、できるだけ高い適切なノードでロールを付与し、入退社や組織変更に強くする
• 組織ポリシーでガードレール: 「外部 IP の禁止」「特定リージョン以外でのリソース作成禁止」などを上位で一括適用する
• ライエンで本番プロジェクトを保護し、誤削除を防ぐ

運用・監視

• Cloud Asset Inventory で階層全体のリソースと IAM ポリシーを横断的に棚卸し・エクスポートする
• Cloud Audit Logs（管理アクティビティ）でプロジェクト・フォルダの作成／移動／削除など、階層変更の操作履歴を監査する
• プロジェクトの移動（reparent）で部門再編に追随できるが、IAM・組織ポリシーの継承が変わるため、移動後の有効権限を確認する
• 削除したプロジェクトは保留期間内なら復元（undelete）可能。恒久削除前提の運用と取り違えない
• アクセスできない／想定外に許可される場合は、継承込みの有効ポリシーを階層の上から順に点検する

コスト

Resource Manager 自体（組織・フォルダ・プロジェクトの作成や階層管理、API 呼び出し）は無料です。課金されるのは各プロジェクト内で使う Compute・Storage などのリソースであり、課金は組織構造ではなくプロジェクトに紐づく請求先アカウントで集計されます。

セキュリティ

• 最小権限を階層で設計: 強力な roles/resourcemanager.organizationAdmin などの組織管理ロールは少人数に限定する
• プロジェクト作成・削除の権限を絞る: 誰でもプロジェクトを乱立できないよう、作成ロールを統制する
• 組織ポリシーで強制ガードレール: IAM だけでは縛れない構成上の禁止事項（外部公開・特定サービス無効化など）を上位で固定する
• タグと条件付き IAM を組み合わせ、環境や属性に応じてアクセスを絞り込む
• 誤削除・誤移動を防ぐため、ライエンと監査ログによる変更追跡を併用する

Well-Architected の観点

• 運用の優秀性: フォルダで論理境界を整理し、組織ポリシーで設定を標準化することで、規模が増えても一貫した運用ができる
• セキュリティ: IAM と組織ポリシーを階層継承で一括適用し、最小権限とガードレールを全社に行き渡らせる。プロジェクト分離で影響範囲も限定できる
• 信頼性: 本番・非本番をプロジェクトで分け、ライエンとソフト削除で誤操作からの回復性を高める
• コスト最適化: 請求先アカウントとプロジェクト構造でコストを配賦・可視化し、部門別の管理を容易にする

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 組織直下にフォルダを作成（ORG_ID は組織ノードの数値 ID）
gcloud resource-manager folders create \
  --display-name="production" \
  --organization=ORG_ID

# 作成したフォルダの ID を確認
gcloud resource-manager folders list --organization=ORG_ID

# そのフォルダ配下にプロジェクトを作成（プロジェクト ID は不変・グローバル一意）
gcloud projects create my-prod-app-001 \
  --name="My Prod App" \
  --folder=FOLDER_ID

# 既存プロジェクトを別フォルダへ移動（継承される権限が変わる点に注意）
gcloud beta projects move my-prod-app-001 --folder=ANOTHER_FOLDER_ID

# フォルダ単位でロールを付与（配下プロジェクトに継承される）
gcloud resource-manager folders add-iam-policy-binding FOLDER_ID \
  --member="group:platform-team@example.com" \
  --role="roles/viewer"

# 組織配下の階層（フォルダ・プロジェクト）を一覧で把握
gcloud projects list --filter="parent.id=FOLDER_ID"