この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。
Google Cloud公式のIdentity and Access Management（IAM）資料を確認し、「誰に・どの役割を・どの範囲で与えるか」という権限管理の基本を初心者向けに整理します。Project階層、Role、Permission、最小権限も扱います。
情報確認基準日: 2026-09-19
まず一言でいうと
IAM（Identity and Access Management）は、Google Cloudで誰が、どのリソースに、何をできるかを管理する仕組みです。Principalは「誰」、Roleは「できることのセット」、Permissionは「個々の操作権限」と考えると理解しやすくなります。
Google全体での位置づけ
| 観点 | IAM |
|---|---|
| 大分類 | Google Cloud / セキュリティ・ID・アクセス制御 |
| 大きな目的 | Cloudリソースへのアクセスを必要な人・処理だけに制限する |
| パーツ | PrincipalとRoleをResourceへ結び付ける権限管理基盤 |
| 一緒に使うもの | Organization、Folder、Project、Service Account、各Cloudサービス |
| 主な利用者 | IT管理者、セキュリティ担当、クラウド運用者、開発者 |
flowchart LR P[Principal<br/>ユーザー・グループ・Service Account等] --> B[Role Binding] R[Role<br/>Permissionの集合] --> B B --> X[Resource<br/>Organization / Folder / Project] X --> S[Compute / Storage / BigQuery等]
RoleとPermissionの違い
Permissionは「特定の操作を許す最小単位」、Roleは複数のPermissionをまとめたものです。通常は目的に合うRoleをPrincipalへ付与します。
Roleには、広い権限を持つBasic role、Googleがサービス別に用意するPredefined role、組織で作るCustom roleがあります。初心者は広すぎるBasic roleを安易に使わず、用途に合うPredefined roleを探す考え方を覚えると安全です。
Resource hierarchyと継承
Google CloudにはOrganization → Folder → Project → 各サービスのResourceという階層があります。上位のコンテナに設定したAllow policyが下位へ影響することがあるため、実効的なアクセスを調べるときは上位階層のポリシーも確認します。
利用者別の実務例
一般利用者・事務職
「ログインできること」と「Cloudデータを見られること」は別です。アカウントがあってもIAM Roleが無ければ対象リソースを操作できない場合があります。
IT管理者
部署・運用チーム・自動処理ごとに必要なRoleを整理し、ProjectやFolderなど適切な範囲へ付与します。異動や委託終了時に権限を見直せる運用も重要です。
開発者
アプリやCI/CDではService Account等の非人間IDを利用することがあります。開発者本人の強い権限をアプリへ流用せず、ワークロードに必要なRoleだけを与えます。
Microsoft経験者はどう理解する？
| Google Cloud | Microsoft Azureの近い概念 | 共通点 / 違い |
|---|---|---|
| IAM | Azure RBAC | Roleを主体へ割り当てResourceへの操作を制御する考え方が近い |
| Principal | User / Group / Service Principal等 | 呼称・ID基盤の構造は異なる |
| Organization / Folder / Project | Management Group / Subscription / Resource Group周辺 | 階層は完全な一対一対応ではない |
| Service Account | Managed Identity / Service Principal周辺 | 認証方法や鍵管理の設計が異なる |
Azure RBAC経験者は「Google Cloud版のResourceアクセス制御」と考えると入りやすいですが、Google CloudのResource hierarchyとRole体系を改めて確認します。
API・CLI・認証
IAMはGoogle Cloud ConsoleだけでなくREST API、Client Libraries、gcloud CLIからも扱えます。プログラムからGoogle Cloud APIを呼ぶ際はApplication Default Credentials（ADC）など、実行環境に応じた認証方法を利用できます。
権限変更は影響が大きいため、初心者向けの最初のサンプルでは変更より読み取りを優先します。
安全に試す
gcloud iam roles describe roles/viewer
何を見る？ roles/viewer というRoleの情報を確認します。
成功すると？ Roleのタイトル、説明、含まれるPermissionなどが表示されます。
1か所変えると何が分かる？ Google公式のRole一覧で別のRole名を確認して置き換えると、RoleごとにPermissionが違うことを比較できます。存在しないRole名を推測せず公式一覧で確認してください。
セキュリティで重要なこと
最小権限：必要な操作だけを許可する。
上位階層からの権限継承も確認する。
長期的な強権限を常用せず、一時的・監査可能なアクセス方式も必要に応じ検討する。
Service Accountのprivate keyを公開GitHubへ保存しない。
IAM変更を「エラーが消えるまで権限を足す」方法で解決しない。
IAMにはAllow policy以外にもDeny policy、IAM Conditions、Principal Access Boundary、Privileged Access Managerなど、アクセスを細かく制御する仕組みがあります。必要性が出た段階で公式資料を確認します。
料金・アカウント・Project
IAMはGoogle Cloudリソースのアクセス管理基盤です。IAM設定だけでなく、Google Cloudアカウント、Organization/Folder/Project構造、操作対象サービスの料金・権限を合わせて設計します。
Google公式情報
次に何をすればよい？
検証Projectで「Principal / Role / Resource」の3点を書き出し、Google Cloud Consoleで現在のアクセス設定を読み取り確認します。変更が必要なら、目的に合うPredefined roleを公式Role一覧から探して検討します。
Papanda TRY：Principal→Role→Resourceを可視化
架空IAM policy JSONをPowerShellで読み、principal、role、resourceを3列表示します。権限を自動変更せず、Owner/Editorなど広いroleを「要確認」と表示する棚卸し専用Daily Codeにします。
結局どういうサービス？
IAMは、Google Cloudで「誰に何をさせてよいか」を決める権限管理の土台です。必要なPrincipalへ必要なRoleを必要なResource範囲だけ付与するために使います。
