Google Cloud セットアップ
Google Cloud をコードで扱う前に押さえる、組織・プロジェクトの考え方と Terraform を動かすまでの段取り。“卵が先か鶏が先か”の state 問題まで
Google Cloud は『組織 → フォルダ → プロジェクト → リソース』の 4 階層で組み立てます。コード管理の第一関門は、台帳（state）の置き場づくりです。
- プロジェクト＝課金・権限が独立した“部屋”
- IaC の土台は業務と分けた専用プロジェクトに
- 認証は長期の鍵を作らず“鍵なし”が原則
Google Cloud はどう組み立てる？
最初のプロジェクトを作る前に、全体がどんな入れ物の重なりでできているかを押さえておきます。どの階層で権限や課金が決まるかが分かると、後から出てくる設定の話はすべて『どの入れ物に付けるか』の話に置き換えられます。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
構成図「Google Cloud の組み立て（4階層）」。ブロック4個、つながり3本。 【ブロック】 - 組織 (Organization): 会社そのもの - フォルダ (Folder): 部署・環境で束ねる - プロジェクト (Project): 作業の基本単位 - リソース: VM・ストレージ・DB など 【流れ】 - 上からの階層をたどる: 組織 (Organization) → フォルダ (Folder) → プロジェクト (Project) → リソース
組織とプロジェクトはどう分ける？
階層が分かると、今度は『どこで区切るか』に迷います。区切りを間違えると、権限の付け直しや請求の仕分けで後々苦労するため、先人の定番パターンを理由ごと知ってから、自社の規模に合わせて小さく始めるのが現実的です。
分け方の指針と理由
気になるセルはクリックで説明が出ます →
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。2列 × 5行。 【列】 1. どうする（推奨の構成） 2. なぜ（理由） 【比較】（観点ごとに） ■ 環境で分ける - どうする: 環境ごとに別プロジェクト / 開発 / 検証 / 本番 - なぜ: 事故が本番に波及しない / 課金も分離・本番は厳格に ■ アプリで分ける - どうする: アプリごとに別プロジェクト / アプリ×環境で1つ - なぜ: 相互影響・誤アクセスを防ぐ / 信頼境界が効く ■ フォルダで束ねる - どうする: フォルダにまとめて権限付与 / 個別でなくまとめて - なぜ: 1回で配下に継承される / 付け忘れ・外し忘れを防ぐ ■ 土台を分ける - どうする: IaCの土台は専用プロジェクト / 通常業務と混ぜない - なぜ: 強い権限を隔離・厳重管理 / 事故の範囲を限定 ■ ネットワークを集約 - どうする: 中央のホストに集約 / 各アプリは相乗り - なぜ: ネットワークを一元管理 / 各アプリは“繋ぐだけ”
Terraform までに何を整える？
コードを書き始める前の段取りが、Google Cloud では特に多めです。順番が前後すると謎のエラーに阻まれて手戻りしがちなので、急がば回れで土台から順に整えるのが、結局いちばん速い道になります。
各ステップをクリックすると、その内容の説明がここに表示されます。
この図をテキストで読む
ステップ図「Terraform を使うまでに必要なこと」。6ステップ。 【手順】（順番に） 1. 組織・請求を整える（ID基盤と課金） 2. 土台プロジェクトを作る（seed / bootstrap） 3. 実行アカウントを用意（鍵なし）（サービスアカウント / WIF） 4. 必要なAPIを有効化（土台のサービス群） 5. state置き場を用意（GCSバケット） 6. 権限を最小限に付ける（必要なロールだけ） 補足: 上から順に整えると、Terraform で Google Cloud を回せる土台になります 【流れ】 - 土台を整えるまでの流れ: 組織・請求を整える → 土台プロジェクトを作る → 実行アカウントを用意（鍵なし） → 必要なAPIを有効化 → state置き場を用意 → 権限を最小限に付ける
なぜ最初の state 置き場で詰まる？
台帳（state）はチームで共有するため、クラウドの置き場（バケット）に保存したい ── ところが、その置き場を作るのも Terraform の仕事です。最初の 1 回だけ順番が成立しないこの堂々巡りは、誰もが一度は通る初見の難所です。
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「卵が先か、鶏が先か ― state バケットのブートストラップ」。参加者4人、ステップ8個。 【参加者】（左から右） - あなた: Terraform を実行 - Terraform: コードから作る道具 - 手元のstate: 最初はPC内 - GCSバケット: 最終的な置き場 【流れ】（上から下へ） ── ① まずローカルで起こす（バケットはまだ無い） ── 1. あなた → Terraform: backend を書かずに terraform init 2. Terraform → 手元のstate: state を手元に保存 ── ② バケットを作る（state はまだ手元） ── 3. あなた → Terraform: terraform apply でバケットを作成 4. Terraform → GCSバケット: GCSバケットを作成（versioning 有効） ── ③ 置き場をクラウドへ切り替える（移行） ── 5. あなた → Terraform: GCS backend を書いて init -migrate-state 6. 手元のstate → GCSバケット: state をバケットへ移行 ── ④ 以降はクラウドの state で回す ── 7. あなた → Terraform: terraform plan で差分ゼロを確認 8. Terraform → GCSバケット: state を読み書き（ロック付き）
ブートストラップの注意（事故を防ぐ）
土台のサービスアカウントは強い権限を持つので、roles/owner のような無差別付与は避けます。state バケットは versioning を有効化し、認証は長期の鍵（JSON）ではなく鍵なし（WIF）や成り代わりを使います。state ファイルは機微情報を含みうるので Git にコミットしないでください。
読むときの注意 ― 事実は変わります
ロール名・API 名・推奨構成は執筆時点（2026年前半）のものです。実装前に必ず最新の公式ドキュメントを確認してください。土台づくりには、Google 公式のひな型（terraform-example-foundation の 0-bootstrap）に任せる近道もあります。
押さえておきたい用語
- 組織 / フォルダ / プロジェクト
- Google Cloud の階層。組織＝会社そのもの（最上位）、フォルダ＝部署・環境で束ねる仕切り、プロジェクト＝課金・権限・API が完結する作業の基本単位（信頼境界）。
- IAM（権限管理）と継承
- 「誰が・何に・何をできるか」を決める仕組み。上位（組織・フォルダ）で付けた権限は、配下のプロジェクト・リソースに自動で受け継がれます。
- サービスアカウント
- 人ではなく、プログラムやツール（Terraform・CI/CD 等）が使う専用のアカウント。
- Workload Identity Federation（WIF）
- 長期の鍵を持たず、CI の身分証を短命な Google Cloud 用トークンに交換して認証する“鍵なし”の仕組み。Google 推奨。成り代わり（インパーソネート）も同じ発想です。
- state（状態）とリモートバックエンド
- state は Terraform が「いま何をどう作ったか」を記録する台帳。チーム共有のため GCS バケットに置き、terraform init -migrate-state で置き場を引っ越せます。
- ブートストラップ / シードプロジェクト
- Terraform を回せる最小限の土台（state 置き場・実行アカウント）を最初に立ち上げる作業と、その専用プロジェクト。Google の Cloud Foundation Toolkit にひな型があります。
ここから先へ
この解説とつながりのあるページ