Azure経験者のためのGCP入門：組織・プロジェクト・ロールの考え方を完全解説

はじめに

「Azureは使いこなしているが、GCPに触れる機会が来た」という方は多いのではないでしょうか。

GCPはAzureと似ている部分もありますが、リソース階層の考え方とIAMの設計思想が独特です。ここを正確に理解しないと、「なぜかアクセスできない」「権限を付与したのに反映されない」といったトラブルに悩まされます。

本記事では、Azureとの対応付けを軸に、GCPの組織・フォルダ・プロジェクト・ロールの考え方を具体例つきで解説します。

1. まず全体像を把握する：AzureとGCPの対応表

読者がAzureに慣れているため、まず概念の対応関係を整理します。

Azure	GCP	役割
Azure AD テナント / Entra ID テナント	組織（Organization）	企業全体の管理単位
管理グループ（Management Group）	フォルダ（Folder）	部門・環境ごとのグループ化
サブスクリプション（Subscription）	プロジェクト（Project）	リソース・課金の単位
リソースグループ（Resource Group）	（プロジェクト内で直接管理）	※GCPにリソースグループ相当はない
Azure RBAC	Cloud IAM	権限管理
ロール（Role）	ロール（Role）	権限のまとまり
セキュリティプリンシパル	プリンシパル（Principal）	権限を付与する対象

ポイント: Azureではサブスクリプションとリソースグループの2段階でリソースを管理しますが、GCPではプロジェクトが最小単位でリソースグループ相当の概念はありません。

2. GCPのリソース階層

GCPのリソースは以下の4階層で管理されます。

graph TD A["🏢 組織（Organization）\nexample.com"] --> B["📁 フォルダ（Folder）\n事業部門A"] A --> C["📁 フォルダ（Folder）\n事業部門B"] B --> D["📁 フォルダ（Folder）\n開発環境"] B --> E["📁 フォルダ（Folder）\n本番環境"] D --> F["📦 プロジェクト\nmy-app-dev"] E --> G["📦 プロジェクト\nmy-app-prod"] C --> H["📦 プロジェクト\nbiz-tools"] F --> I["☁️ リソース\nVM, GCS, BigQueryなど"] G --> J["☁️ リソース\nVM, GCS, BigQueryなど"] style A fill:#4285f4,color:#fff style B fill:#34a853,color:#fff style C fill:#34a853,color:#fff style D fill:#fbbc04,color:#000 style E fill:#fbbc04,color:#000 style F fill:#ea4335,color:#fff style G fill:#ea4335,color:#fff style H fill:#ea4335,color:#fff

各階層の役割

組織（Organization）

企業全体の最上位ルート
Google Workspace または Cloud Identity のドメインに紐づく
Azureの「Entra IDテナント」に相当
組織レベルで設定したポリシーは全フォルダ・プロジェクトに継承される

フォルダ（Folder）

部門・環境・チームごとのグループ化に使う
Azureの「管理グループ」に相当
フォルダは最大10階層まで入れ子にできる
フォルダへの権限付与は配下のプロジェクトすべてに継承される

プロジェクト（Project）

GCPにおける最も重要な概念
すべてのリソースはプロジェクトに属する（プロジェクト外にリソースは存在しない）
課金はプロジェクト単位で管理される
Azureの「サブスクリプション」に相当するが、より細かく分割する運用が一般的

リソース

VM（Compute Engine）、Cloud Storage、BigQuery など
必ずプロジェクト配下に存在する

3. プロジェクトの理解が最重要

GCPを使い始めて最初につまずくのがプロジェクトの概念です。

プロジェクトの3つの識別子

プロジェクトには3種類の識別子があります。

識別子	例	特徴
プロジェクト名（Name）	My App Dev	表示用の名前。変更可能、重複OK
プロジェクトID（Project ID）	my-app-dev-12345	グローバルで一意。作成後変更不可
プロジェクト番号（Project Number）	123456789012	Googleが自動採番。変更不可

注意: APIやCLIでプロジェクトを指定する際は「プロジェクトID」を使います。プロジェクト名ではないので注意が必要です。

AzureのサブスクリプションとGCPのプロジェクトの違い

graph LR subgraph Azure["Azure の考え方"] sub["サブスクリプション\n（大きめの単位）"] --> rg1["リソースグループ\n（本番）"] sub --> rg2["リソースグループ\n（開発）"] rg1 --> r1["VMなど"] rg2 --> r2["VMなど"] end subgraph GCP["GCP の考え方"] pj1["プロジェクト\n（本番）"] --> r3["VMなど"] pj2["プロジェクト\n（開発）"] --> r4["VMなど"] pj3["プロジェクト\n（共有サービス）"] --> r5["VPCなど"] end style sub fill:#0078d4,color:#fff style rg1 fill:#0078d4,color:#fff style rg2 fill:#0078d4,color:#fff style pj1 fill:#ea4335,color:#fff style pj2 fill:#ea4335,color:#fff style pj3 fill:#ea4335,color:#fff

GCPではプロジェクトを細かく分割するのが一般的です。例えば：

my-app-prod → 本番環境
my-app-dev → 開発環境
my-app-shared → 共有ネットワーク（Shared VPC）
my-app-logs → ログ集約専用

Azureで1つのサブスクリプション内でリソースグループを分ける感覚ではなく、プロジェクト自体を環境・用途ごとに作るイメージです。

4. Cloud IAM（権限管理）の仕組み

IAMの基本構造

GCPのIAMは「誰が（Who）、どのリソースに（On What）、何をできるか（What）」を定義します。

graph LR A["👤 プリンシパル（誰が）\nユーザー、SA、グループなど"] --> B["🔑 ロール（何を）\nroles/storage.admin など"] B --> C["📦 リソース（どこに）\nプロジェクト、フォルダ、組織"] style A fill:#4285f4,color:#fff style B fill:#34a853,color:#fff style C fill:#ea4335,color:#fff

プリンシパル（Principal）の種類

Azureの「セキュリティプリンシパル」に相当します。

種類	説明	Azure対応
Googleアカウント	個人ユーザー（@gmail.com など）	ユーザー
サービスアカウント（SA）	アプリ・VM用の非人間アカウント	サービスプリンシパル / マネージドID
Google グループ	ユーザーのグループ	セキュリティグループ
Google Workspace ドメイン	ドメイン全体のユーザー	ディレクトリ全体への適用
allAuthenticatedUsers	Googleアカウントを持つ全ユーザー	※Azureに直接対応なし（注意が必要）
allUsers	認証なし全ユーザー（公開）	※Azureに直接対応なし（公開設定）

重要: allUsers や allAuthenticatedUsers を本番環境で使うのは危険です。誤って公開設定にしないよう注意してください。

ロールの3種類

GCPのロールはAzureのRBACと似た構造ですが、3種類に分類されます。

① 基本ロール（Basic Roles）

旧称：プリミティブロール。非常に強力な権限を持つため、本番環境では使用非推奨。

ロール	説明	Azure対応
`roles/owner`	全権限 + IAM管理	所有者（Owner）
`roles/editor`	読み書き（IAM管理なし）	共同作成者（Contributor）
`roles/viewer`	読み取りのみ	閲覧者（Reader）

Azureの「所有者」がGCPの roles/owner に相当しますが、GCPではより細かいロールを使うことが強く推奨されます。

② 事前定義ロール（Predefined Roles）

Googleが用意した用途別ロール。実務では基本的にこれを使う。

roles/compute.instanceAdmin.v1    → Compute Engineの管理
roles/storage.objectAdmin         → Cloud Storageオブジェクトの管理
roles/bigquery.dataViewer         → BigQueryデータの参照
roles/container.developer         → GKEの開発者向け
roles/logging.viewer              → ログの閲覧

Azureの組み込みロール（Virtual Machine Contributor など）に相当しますが、GCPはさらに細かく分かれています。

③ カスタムロール（Custom Roles）

必要な権限だけを組み合わせた独自ロール。最小権限の原則を徹底したい場合に使用。

Azureの「カスタムロール」に相当します。

5. IAMポリシーの継承

これがGCPで最も重要な概念の一つです。

継承の仕組み

graph TD A["🏢 組織\nroles/bigquery.admin → data-team@"] --> B["📁 フォルダ（本番）\nroles/compute.viewer → ops-team@"] A --> C["📁 フォルダ（開発）"] B --> D["📦 プロジェクト（本番）\nroles/storage.admin → dev-team@"] B --> E["📦 プロジェクト（DR）"] F["📌 プロジェクト（本番）で有効な権限"] F --> G["✅ data-team@: bigquery.admin（組織から継承）"] F --> H["✅ ops-team@: compute.viewer（フォルダから継承）"] F --> I["✅ dev-team@: storage.admin（プロジェクト直接）"] style A fill:#4285f4,color:#fff style B fill:#34a853,color:#fff style C fill:#34a853,color:#fff style D fill:#ea4335,color:#fff style E fill:#ea4335,color:#fff style F fill:#fbbc04,color:#000

上位階層で付与した権限は、配下のすべてのリソースに自動的に継承されます。

継承の重要ルール

継承は一方向：上から下へのみ。子から親への継承はない
権限の剥奪はできない：上位で付与した権限を下位で削除することは原則できない
Deny ポリシーは例外：IAM Deny（別機能）を使えば明示的な拒否が可能（ただし設計に注意）

Azureとの重要な違い: AzureのRBACでは Deny 割り当てで継承された権限を否定できますが、GCPの通常のIAMにはこの仕組みがありません。GCPの IAM Deny は別途設定が必要です。

6. サービスアカウント（Service Account）の使い方

GCPで特徴的なのが**サービスアカウント（SA）**の使い方です。

Azureのマネージドエンティティとの比較

graph LR subgraph Azure["Azure"] vm_az["VM"] --> mi["マネージドID\n（自動的にAADに登録）"] mi --> res_az["Azureリソース\n（RBACで権限付与）"] end subgraph GCP["GCP"] vm_gcp["VM（Compute Engine）"] --> sa["サービスアカウント\n（手動で作成・割り当て）"] sa --> res_gcp["GCPリソース\n（IAMで権限付与）"] end style mi fill:#0078d4,color:#fff style sa fill:#ea4335,color:#fff

サービスアカウントの2つの使われ方

1. リソースのアイデンティティとして

VMやCloud RunなどのリソースにSAを割り当て、そのリソースが他のGCPサービスにアクセスする際のID。

例：Cloud Run（SA: [email protected]）
→ Cloud Storage に読み書き権限を付与
→ Cloud Run のコードから認証なしで GCS にアクセス可能

2. アプリケーションからの認証として

キーファイル（JSON）を使って外部アプリがGCPにアクセスする。ただしキーの管理が難しいため非推奨。代わりにWorkload Identity Federationを使うのが現代的な方法。

サービスアカウントへの権限付与

SAは2つの視点で権限管理します。

graph LR A["👤 人間ユーザー"] --"roles/iam.serviceAccountUser\n（SAを使う権限）"--> B["🤖 サービスアカウント"] B --"roles/storage.objectAdmin\n（GCSを操作する権限）"--> C["📦 Cloud Storage"] style A fill:#4285f4,color:#fff style B fill:#34a853,color:#fff style C fill:#ea4335,color:#fff

SAそのものへの権限：ユーザーがSAを「使う」ための権限（roles/iam.serviceAccountUser）
SAがリソースに持つ権限：SAが実際に操作できるリソースへの権限

7. よくある設計パターン

エンタープライズ向け組織構造

graph TD ORG["🏢 組織: example.com"] --> FOLDER_PROD["📁 フォルダ: 本番"] ORG --> FOLDER_NON_PROD["📁 フォルダ: 非本番"] ORG --> FOLDER_SHARED["📁 フォルダ: 共有インフラ"] FOLDER_PROD --> PJ_PROD_APP["📦 my-app-prod"] FOLDER_PROD --> PJ_PROD_DATA["📦 my-data-prod"] FOLDER_NON_PROD --> PJ_DEV["📦 my-app-dev"] FOLDER_NON_PROD --> PJ_STAGING["📦 my-app-staging"] FOLDER_SHARED --> PJ_NETWORK["📦 共有ネットワーク（Shared VPC）"] FOLDER_SHARED --> PJ_LOGGING["📦 ログ集約"] FOLDER_SHARED --> PJ_BILLING["📦 課金管理"] style ORG fill:#4285f4,color:#fff style FOLDER_PROD fill:#ea4335,color:#fff style FOLDER_NON_PROD fill:#34a853,color:#fff style FOLDER_SHARED fill:#fbbc04,color:#000

推奨されるロール付与の原則

原則	内容
最小権限	必要最小限のロールのみ付与
事前定義ロール優先	基本ロール（owner/editor）は使わない
グループ経由での付与	個人ではなくグループにロールを付与
定期的な棚卸し	不要な権限の削除・レビュー
SA鍵の廃止	キーファイルの代わりにWorkload Identityを使用

8. 実際によく使うコマンド

プロジェクトの操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 現在のプロジェクト確認
gcloud config get-value project

# プロジェクト一覧
gcloud projects list

# プロジェクトを切り替え
gcloud config set project my-app-dev-12345

# プロジェクト作成
gcloud projects create my-new-project --folder=FOLDER_ID

IAMポリシーの確認・付与

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# プロジェクトのIAMポリシー確認
gcloud projects get-iam-policy my-project-id

# ロールの付与（ユーザーに対して）
gcloud projects add-iam-policy-binding my-project-id \
  --member="user:[email protected]" \
  --role="roles/storage.objectAdmin"

# ロールの付与（サービスアカウントに対して）
gcloud projects add-iam-policy-binding my-project-id \
  --member="serviceAccount:[email protected]" \
  --role="roles/bigquery.dataViewer"

# 付与したロールの削除
gcloud projects remove-iam-policy-binding my-project-id \
  --member="user:[email protected]" \
  --role="roles/storage.objectAdmin"

使用可能なロール一覧

1
2
3
4
5
6
7
8
# 全ロール一覧（多い）
gcloud iam roles list

# 特定サービスのロールを検索
gcloud iam roles list --filter="name:roles/storage"

# ロールの詳細（含まれる権限）確認
gcloud iam roles describe roles/storage.objectAdmin

9. つまずきやすいポイントまとめ

ポイント① プロジェクトIDは変更不可

プロジェクト作成時に決めるプロジェクトIDは後から変更できません。-dev や -prod のサフィックスを最初から含めて命名規則を決めておきましょう。

ポイント② 組織がないと一部機能が使えない

個人のGmailアカウントで試す場合、「組織」が存在しません。フォルダの作成、組織レベルのポリシー、Shared VPCなど、一部機能は組織が必要です。業務利用ではGoogle Workspaceかクラウドアイデンティティを使いましょう。

ポイント③ 権限の反映に少し時間がかかる

IAMポリシーを変更してから実際に反映されるまで、最大数分かかることがあります。変更直後にアクセスエラーが出ても、少し待ってから再試行してみましょう。

ポイント④ サービスアカウントのなりすまし

あるSAが別のSAにroles/iam.serviceAccountTokenCreatorを持つと、そのSAになりすますことができます。これを意図せず付与しないよう注意が必要です。

ポイント⑤ プロジェクトの削除は30日後

プロジェクトを削除してもすぐには消えません。**30日間は「削除予約中」**の状態になり、その間に誤削除を取り消すことができます。ただし30日経過後は復元不可になります。

まとめ

概念	Azure対応	GCPのポイント
組織	Entra ID テナント	Google Workspace/Cloud Identityドメインに紐づく
フォルダ	管理グループ	最大10階層の入れ子が可能
プロジェクト	サブスクリプション	課金・リソースの最小単位。細かく分割が基本
IAMロール	Azure RBAC ロール	基本/事前定義/カスタムの3種類
サービスアカウント	マネージドID	アプリ・VMのアイデンティティ。キーファイルは非推奨
権限継承	管理グループ→サブスクリプション継承	上位から下位へ一方向。否定はIAM Deny（別設定）

GCPの設計は「プロジェクトを小さく分けて、IAMは上位で一元管理する」という思想が根本にあります。Azureで言う「サブスクリプションを細かく切る」感覚に近いですが、さらに積極的な分割が推奨されます。

最初は戸惑うかもしれませんが、階層構造と権限継承のルールさえ押さえれば、Azureの経験者なら比較的スムーズに理解できるはずです。