第2回：設計図を引こう！Google Cloud の「組織（Organization）」基本のキ
はじめに
お疲れ様です。SKY こと関谷です。
前回の第1回では、クラウドを安全に使うための「地図」として、責任共有モデル、多層防御（Defense in Depth）、ゼロトラスト（Zero Trust） を確認しました。これらはクラウド セキュリティを考えるうえでの普遍的な原則です。
今回からは、その「地図」をもとに 設計図（Landing Zone） を描いていきます。クラウドはすぐにプロジェクトを作って試せる反面、「とりあえず」で進めると将来の運用・監査・コスト最適化で大きなつまずきになりがちです。
この第2回では、まず なぜ土台作りが重要なのか をリスク面から整理し、次に リソース階層の理解、フォルダ構成の型、プロジェクト命名規則の作り方 を順に解説します。
ブログシリーズその他の執筆
＊2025.09.22更新*
本編
番外編
2-1. はじめに：なぜ「土台作り（Landing Zone）」が重要なのか？
クラウドの良さは「すぐ試せること」。ただし、このスピード感は 設計が追いつかないまま運用に入る リスクと表裏一体です。最初の 1～2 個のプロジェクトなら勢いで回せても、10・100 と増える頃には、命名・権限・ネットワーク・ログの“ちょっとした判断”の積み重ねが、統制不能な複雑さとなって現れます。Landing Zone は、そうした将来の“ほつれ”を 構造で防ぐ基礎工事 です。
リスクについて
-
セキュリティリスク：公開不要なリソースを外に晒してしまう
例）検証で開けたポートや外部 IP を閉じ忘れ、本番公開のまま残存。脆弱性対応やインシデント時に影響範囲が読めなくなります。 -
管理コスト増：命名ルールがバラバラで棚卸しが困難
例）誰の・何のためのプロジェクトかが分からず、権限見直しや課金精査が人海戦術に。監査・説明責任も重くなります。 -
後戻り困難：既存サービスを止めずに再設計は難しい
例）動いている CI/CD、監視、課金、権限の紐づけを“生かしたまま”移し替える作業は、現場にとって大きな負担です。
Landing Zone とは？
Google Cloud で言う「Landing Zone」とは、安全かつ拡張性を見据えた基本構造やルールを最初に整えること です。人の注意に頼らず、“作れない・通らない” という仕組み でミスを抑えます。
| 項目 | 考えるべき内容 | 効果 |
|---|---|---|
| リソース階層 | 組織・フォルダ・プロジェクトをどう分けるか | 権限・ポリシーを統一的に適用できる |
| 命名規則 | 環境やシステム名をどう表現するか | 一目で用途や環境が分かる |
| ガードレール | 組織ポリシーや IAM ルールを最初に定義 | セキュリティ事故を未然に防ぐ |
| 共通基盤 | ネットワークやログをどこで集中管理するか | 全体の効率化・統制強化 |
補足の解説（表のねらい）
- リソース階層：上位（Organization/Folder）で“原則”を定め、下位（Project）で“最小限の例外”だけを許すと、レビューと監査が楽になります。
-
命名規則：
env-system-teamのような機械可読な形にすると、自動化（検索・集計・クォータ管理）が一気に進みます。 - ガードレール：本番フォルダに「外部 IP 禁止」「サービス アカウント鍵作成禁止」「許可リージョン限定」などを先に敷くと、“うっかり” を構造的に防止。
- 共通基盤：Shared VPC、ログ集約、監視、 CI/CD の“置き場”を最初に固定しておくと、各プロジェクトは“つなぐだけ”で標準準拠に。
構造的に落ちる落とし穴（なぜ起きる？）
- 人の善意・注意に依存：担当交代・多忙・属人化で、例外運用が常態化します。
- “一度きりの特例”が積み重なる：期限なしの例外は事実上の恒久ルールに。将来の統廃合で足かせになります。
- 監視とコストの“後付け”：先に集約先を決めないと、各チームごとの局所最適になり全体像が見えません。
先に整えると何が変わる？
- 安全性：本番に強い制約、開発は緩める——“環境で差をつける” が素直に実現。
- 速さ：命名・ラベル・ネットワーク・ログの“決めごと”があると、新規プロジェクトが申請テンプレで数分〜数時間で立ち上がります。
- 説明可能性：どの資産がどの原則で守られているかを 構造で 示せるため、監査・取引先説明が楽になります。
導入ステップ（小さく速く始める）
- 原則を 1 枚に：環境区分（prod/stg/dev/sbx）、禁止事項（外部 IP・鍵作成など）、リージョン方針を箇条書き化。
- フォルダの“型”を選ぶ：環境優先 or 部門優先。どちらかで最小スコープを試す。
-
命名・ラベルを固定：
[env]-[system]-[team]-[nn]、env/system/team/costcenter/ownerを共通キーに。 - 共通基盤の置き場を作る：Shared Services にネットワーク・ログ・監視・ CI/CD を先置き。
- 例外運用を仕組み化：申請→承認→期限付き（自動リマインド）で“特例の常態化”を防止。
最初の 30 日チェックリスト
- 組織ポリシーの 禁止リスト（外部 IP、鍵作成、許可リージョン）を作り、本番フォルダに適用
- 命名テンプレと 必須ラベル を Wiki と申請フォームで周知
- Shared VPC／ログ集約プロジェクト／監視の 集約先 を開設し、接続手順を標準化
- 課金アラート と 監査ログ の保存先・保持期間を決定
- サンドボックスに TTL／自動停止 の仕組みを導入（放置資産を作らない）
アンチパターンと回避策
- プロジェクト乱立（組織直下） → フォルダで環境 or 部門を切り、原則はフォルダに集約
- 表示名だけ運用 → Project ID を主語に。小文字・英数・ハイフン、変更不可を前提にルール化
- “暫定の例外”が恒久化 → 例外は期限付き・再承認必須・可視化（ダッシュボード）
- 監視・コスト“後で考える” → 初日から集約先とアラートを標準メニューに
Landing Zone 全体像
2-2. Google Cloud の世界観：リソース階層を理解する
2-1 で「土台（Landing Zone）」の大切さを確認しました。続く 2-2 では、その土台を乗せる 器＝リソース階層 をもう一段わかりやすく噛み砕きます。ポイントは、
- それぞれの階層に「役割」と「責任境界」がある、
-
上で決めた原則が下に継承される、の 2 つです。
ここが腑に落ちると、「どこに何のルールを置くか」「例外はどこで表現するか」が迷いにくくなります。
4 つの階層と“責任の持ち場”
-
組織（Organization）：全社の“屋根”
- ドメイン（ Cloud Identity / Google Workspace）と結びつく最上位の入れ物。
- 全社原則の置き場：外部 IP の作成禁止、鍵の作成禁止、許可リージョンの固定など、誤操作を防ぐ強いルールをここで定めると効果大。
- 監査・コンプライアンスの観点では、一貫した原則が 1 箇所にある こと自体が強みになります。
-
フォルダ（Folder）：運用の“型”を分ける仕切り
- 部門・環境（Production / Staging / Development / Sandbox）・共通基盤（Shared Services）など、運用の違い を表します。
- 継承の中継点：本番だけ制約を厳しく、開発は緩める、といった “環境の差” を フォルダで 表現。
- 入れ子にできるため、部門 × 環境 の二軸構造にも馴染みます。ただし深くしすぎると迷子になりがちなので、目安は 2～3 段。
-
プロジェクト（Project）：実務の“主語”
- 課金・監査ログ・クォータ・権限の 最小単位。ここで VM、バケット、 DB などの実体（リソース）を作ります。
- 詰め込み過ぎ注意：1 プロジェクトにすべてを抱え込むと、権限分離・変更リズム・障害影響の切り分けが難しくなります。
- システムの性質に応じて、「アプリ系」と「データ系」を分けるなど、責任境界で分割 すると運用が楽です。
-
リソース（Resource）：実体そのもの
- Compute Engine の VM、Cloud Storage のバケット、Cloud SQL のインスタンス等。
- リージョン / ゾーン の概念が絡むため、レイテンシ・可用性・災害対策を意識した配置が必要です。
「継承」を味方につける（原則は上位、例外は下位）
- 上で決めたことは下へ流れる：Organization / Folder に置いた IAM や 組織ポリシーは、その配下の Project / Resource に継承されます。
- 原則は上位に一度だけ：外部 IP 禁止、鍵作成禁止、許可リージョンなど、事故を生まない大枠のルールは上位 に。
- 例外は下位に限定：どうしても必要な例外は、特定フォルダ（例：Staging）や特定プロジェクトに寄せると、見通しが保てます。
- レビューのしやすさ：例外を下位に集約すると、「どこが標準外なのか」をレビューや監査で素早く把握できます。
リソース階層と継承
よくある迷いどころと考え方
-
Q. フォルダの切り方は“環境別”と“部門別”どっち？
A. 統制をシンプルに始めたいなら “環境別” が扱いやすい。責任・予算を部門で完結させたい大規模組織は “部門別”＋各部門の下に環境フォルダが相性良し。 -
Q. 1 つのシステムを 1 プロジェクトにまとめて良い？
A. 小規模なら可。ただし運用が育つにつれ、責任境界ごとに分割（例：アプリ系とデータ系）しておくと、権限分離・変更管理・障害影響の抑制に効きます。 -
Q. フォルダはどれくらい深くして良い？
A. 2～3 段が目安。深さより 命名・ラベルの一貫性 と “どこに何の原則を置くか” の分かりやすさ を優先します。
“どこに何を置くか” の実務ヒント
- Organization：全社原則（組織ポリシー）、全社ロールの最小付与、監査ログ・セキュリティ通知の基本方針。
- Production フォルダ：外部公開の原則禁止、許可リージョン固定、サービス アカウント鍵禁止など 強い制約。
- Development / Sandbox フォルダ：コスト上限、外部公開の原則不可、期限付きの例外運用（自動リマインド）。
- Shared Services フォルダ：Shared VPC、ログ集約、監視、 CI/CD の 置き場。各 Project はここに“つなぐ”だけで標準準拠。
-
Project：命名・ラベルの統一（
env/system/team/costcenter/ownerなど）。課金・監査の主語 であることを意識。
サンプル（イメージ）
-
EC サイト：
-
Productionフォルダ配下にprod-ec-site-app（アプリ系）とprod-ec-site-data（データ系）を分離。 - フォルダで外部 IP 禁止・許可リージョン固定。アプリ Project は Private 経由で入口を受け、Data Project は内部のみ通信。
- ログと監視は
Shared Servicesに集約し、横断観測を標準化。
-
2-3. 【具体的な方法】失敗しないフォルダ構成パターン
2-2 で「どの階層に何を置くか」を掴んだら、次は “運用の型” をフォルダで表現する 段階です。ここが腹落ちしていると、後ろの IAM 設計やログ集約、ネットワーク標準化までが一気にスムーズになります。結論から言うと、実務で扱いやすいのは 環境優先 と 部門優先 の 2 パターン。どちらも正解になり得ますが、選定の軸を先に共有しておくのがコツです。
まず押さえる設計方針（共通原則）
- 原則はフォルダでまとめて適用：強いルール（外部公開禁止、許可リージョン固定、鍵作成禁止など）は、プロジェクト単位でバラバラにしないで フォルダ に載せます。
- 例外は下位に寄せる：どうしても必要な例外は、特定のプロジェクト／特定のサブフォルダに “閉じ込める”。可視化と監査が楽になります。
- Shared Services を最初に用意：ネットワーク（ Shared VPC など）、ログ・監視、 CI/CD は 置き場を固定。各プロジェクトは “つなぐだけ” にします。
-
命名・ラベルは全フォルダで共通キー：
env/system/team/costcenter/ownerを決め、在庫・課金・監査の横断で迷わない土台に。
環境優先パターン（シンプル）
Organization
├─ Production
├─ Staging
├─ Development
├─ Sandbox
└─ Shared Services
向いているケース
- まず 統制をシンプル に始めたい（中規模以下の導入直後や、クラウド初心者チームが多い）。
- 本番だけは 特に厳格 にしたい（外部 IP 禁止、鍵作成禁止、変更フロー厳格など）。
運用のポイント
- Production フォルダ：厳格な組織ポリシー・ IAM 条件を集約。デプロイ経路も固定（例： CI/CD からのみ）。
- Staging フォルダ：本番に近い制約で最終検証。公開は限定、監査ログは本番同等。
- Development / Sandbox：利便性を確保しつつ、コスト上限・期限付き例外・外部公開禁止でリスクを制御。
- Shared Services： Shared VPC、 Cloud NAT、 DNS、ログ集約、監視、 CI/CD 基盤の “置き場”。環境ごとに参照。
利点と注意
- 利点：環境で縦串 に統制できる（本番だけ厳格、開発は緩める）。
- 注意：部門別の可視化は ラベル・課金ビュー で補います（
team=salesなど）。
部門優先パターン（大規模・縦割り文化向け）
Organization
├─ Sales
│ ├─ Production / Staging / Development
├─ IT
│ ├─ Production / Staging / Development
└─ Shared Services（全社共通）
向いているケース
- 組織が大きく、責任と予算が部門単位 で完結している。
- 各部門が自律的にプロジェクトを増やし、スピードと責任 を両立させたい。
運用のポイント
- 各部門の Production に強い制約を適用。部門内の Shared Services（共通ライブラリ、内向け API、部門内ログ集約など）を併設してもよい。
- 全社横断のネットワーク・監査・監視は 全社 Shared Services に集約し、部門内共通 と役割分担。
- 標準の違いが部門ごとに増えすぎないよう、全社原則は Organization か全社 Shared Services で固定。
利点と注意
- 利点：権限委譲・予算管理が 部門の責任範囲に自然に一致。
- 注意：部門ごとの例外が増えすぎないよう、原則（禁止・必須）を全社で単一化。
フォルダ単位でのガードレール例
| フォルダ | 制約例 | 目的 |
|---|---|---|
| Production | 外部 IP 禁止 / サービス アカウント鍵禁止 | 重大事故防止 |
| Staging | 本番に近いが一部緩和 | 移行前の検証 |
| Development | コスト上限 / 外部公開不可 | 開発者の利便性と安全性 |
| Shared Services | ネットワーク / ログ集約 | 全社統合管理 |
使い方の解像度を上げるヒント
- Production：許可リージョン固定、強制暗号化（必要に応じて CMEK）、デプロイは特定の CI/CD サービス アカウントのみ、人手直操作は原則不可。
- Staging：本番と同等のネットワーク・ IAM・監査ログを適用。外部公開が必要な場合は ** IP 制限・期限付き**。
- Development：コストアラート、短命プロジェクトの ** TTL ルール**、外部公開不可。安全な速さ を担保。
- Shared Services： Shared VPC ホスト、 Cloud DNS、 Cloud NAT、ログの集約先（ Cloud Logging / BigQuery）、 Cloud Monitoring ワークスペース、 Artifact Registry、 CI/CD。
フォルダ構成例
2-4. 誰が見ても分かる！プロジェクト命名規則の決め方
フォルダ設計で “型” ができたら、現場の運用で一番効いてくるのが プロジェクトの命名 と メタデータ（ラベル等） です。Google Cloud では、課金・監査・権限・クォータ の多くがプロジェクトを単位に動きます。つまり、プロジェクトの名前づけが “在庫管理の索引” となり、トラブル対応や棚卸し、コスト最適化の速度に直結します。
命名は「今の担当が分かればよい」では不十分です。異動・引継ぎ・第三者の監査 を前提に、見ただけで意味が分かる・機械でも扱いやすい 形にしましょう。
含めるべき要素
| 要素 | 例 | 意味 |
|---|---|---|
| 環境 |
prod, stg, dev, sbx
|
本番 / 検証 / 開発 / 実験 |
| システム名 |
ec-site, hr-system
|
EC サイト / 人事システム |
| 部門名 |
sales, it
|
営業部 / 情報システム部 |
| 番号 |
01, 02
|
拡張や複数環境対応 |
命名例
prod-ec-site-salesit-hr-system-devdata-analytics-stg-01
読み解き方の例
-
prod-ec-site-sales→ 「本番（prod）／ EC サイト（ec-site）／ 営業部（sales）」 -
data-analytics-stg-01→ 「ステージング（stg）／ データ分析（data-analytics）／ 1 系列目（01）」
プロジェクトの識別子を正しく扱う
-
Project ID：URL や API、スクリプトで主に使う 一意の識別子。小文字英数字とハイフン を基本に、後から変更できない 前提で設計します（例：
prod-ec-site-sales）。 - Project name（表示名）：人が見るための名前。変更可能ですが、運用の主語にはしない 方が安全です。
- Project number：数値の内部一意キー。覚えなくて OK。ただし監査ログや一部連携で目にします。
実務の鉄則：Project ID を“唯一の真実”として設計・自動化。表示名はサブ。ダッシュボードも Project ID で揃えるとブレません。
命名ルールを “運用” に落とすコツ
-
テンプレート固定：
[env]-[system]-[team]-[nn]を標準に。systemは小文字・ハイフン区切り、略語の表を Wiki に。 - 申請フォーム化：Google Forms などで必須項目にし、入力ミスを構造的に防止。自動でラベル・フォルダ・請求先を紐づけて作成。
-
衝突回避の仕組み：
[nn]を 2 桁で確保（01から）。将来の分割や DR 用の増設にも対応しやすくなります。 - 命名とラベルの二層設計：名前で “人が読む”、ラベルで “機械が集計”。両輪で迷いをなくします。
ラベル設計（運用で効く最小セット）
-
共通キーを全社で固定：
env, system, team, costcenter, ownerなど。検索・請求・棚卸しの 横断軸 に。 - 全リソースにも同じキー：VM やバケット、ジョブにも 同じキーセット を付与。資産の可視化 が一気に進みます。
- 作成時に自動付与：プロジェクト作成フローでラベルを必須に。後付けは必ず漏れます。
命名とラベル
2-5.本回のまとめ
クラウドを安全かつ効率的に活用するためには、初期の「土台作り（Landing Zone）」が極めて重要です。行き当たりばったりで始めると、将来的に管理が複雑になり、セキュリティリスクやコスト増大を招く可能性があります。
今回の要点は以下の通りです。
なぜ土台作りが重要か？:
初期の設計を怠ると、プロジェクトが増えるにつれて命名規則や権限管理がバラバラになり、統制が取れなくなります。これは将来のセキュリティインシデントや、運用コストの増大に直結します。
リソース階層の理解:
Google Cloudは「組織」「フォルダ」「プロジェクト」「リソース」という階層構造になっています。この階層を理解し、上位の階層で設定したルール（ポリシー）が下位に継承されることを利用して、一貫性のあるガバナンスを効かせることが基本です。
具体的な設計パターン:
フォルダ構成は、本番・開発などの「環境」を優先するか、部署などの「部門」を優先するかの型を決めます。さらに、誰が見ても分かるようなプロジェクトの命名規則を設けることで、管理の属人化を防ぎます。
結論として、最初にしっかりとした設計図を描き、仕組みで統制を効かせることで、将来にわたって安全でスケーラブルなクラウド環境を維持できるのです。
次回の第3回では、いよいよ IAM（Identity and Access Management）の鉄則 に進みます。
第2回で作った “型（階層・フォルダ・命名・ガードレール）” の上に、「誰に」「何を」「どこまで」 をどう重ねるのか。実務で使える最小権限の考え方や、 Google グループを用いた権限設計のコツを分かりやすく解説します。
参照情報
-
Google Cloud Resource Hierarchy の基本
リソースの階層構造の概念と役割。組織・フォルダ・プロジェクトなどの関係を整理する基本的知見。 -
Landing Zone のベストプラクティス
セキュリティや標準化を踏まえた、設計初期段階の Landing Zone 構築に関する推奨事項。 -
Enterprise foundations blueprint（セキュリティ設計の全体像）
組織構造、認証・認可、リソース階層、ネットワーク、ログなどを統合的に扱う設計ガイド。 -
General best practices | Cloud Architecture Center
Landing Zone、リソース階層、セキュリティ設計などを包括的にガイドするアーキテクチャセンターのまとめページ。
Discussion