変更要約: Professional Cloud Architect 第1章を新規作成（ドメイン1「設計と計画」前半: 要件からアーキテクチャ＝ビジネス/技術要件・リソース階層・組織ポリシー・KPI/SLO、コンピュート/ストレージ/データの選択＝CE/GKE/Cloud Run/Functions・Cloud Storage/PD/Filestore・Cloud SQL/Spanner/Firestore/Bigtable/BigQuery）。
1.1要件からアーキテクチャへ
ビジネス要件と技術要件を引き出し、それを Google Cloud のアーキテクチャへ落とし込む考え方、リソース階層（組織→フォルダ→プロジェクト）の設計、ステークホルダーの期待やコンプライアンス制約の反映、そして成功指標（KPI/SLO）に基づく設計判断を理解します。
Professional Cloud Architect は、ビジネスの目標を Google Cloud 上の堅牢なアーキテクチャへ翻訳する役割です。最初の仕事は、技術ではなく 要件を正しく捉えることです。要件を取り違えると、後段の設計がすべてずれます。
1.1.1ビジネス要件と技術要件
アーキテクトはまず ビジネス要件（コスト削減、市場投入の速さ、可用性目標、規制対応など）と 技術要件（性能、スケーラビリティ、レイテンシ、移行制約など）を引き出します。これらを 成功指標（KPI や SLO）として定量化し、設計上のトレードオフ（コスト対可用性、速度対統制）を判断する基準にします。「要件→指標→設計判断」の流れが、Architect の問題でくり返し問われます。
1.1.2リソース階層とプロジェクト設計
Google Cloud の統制は リソース階層（組織→フォルダ→プロジェクト→リソース）に沿います。プロジェクトは課金と権限の基本単位で、ポリシー（IAM や 組織ポリシー）は階層に沿って継承されます。環境（本番/開発）や部門でフォルダ/プロジェクトを分け、最小権限とコンプライアンス境界を設計します。「環境/部門の分離＝フォルダ・プロジェクト」「一貫したルールの強制＝組織ポリシーの継承」と結びます。
「要件 → 設計」が頻出。例：「市場投入を最速に」＝マネージド/サーバーレス寄り、「厳しい規制」＝データ所在地・組織ポリシー・コンプライアンス境界、「本番と開発を分離」＝フォルダ/プロジェクト分割、「全社一貫の制約」＝組織ポリシーの継承、「目標を定量化」＝KPI/SLO。
混同に注意：
①プロジェクトは課金/権限の基本単位で、安易に1つに詰め込まない。
②組織ポリシーは IAM の許可とは別（制約の強制）。
③要件はビジネスと技術の両面を捉える（片方だけだと最適解を外す）。
1.1.3この節のまとめ
- ビジネス要件と技術要件を引き出し、KPI/SLO として定量化して設計判断の基準にする
- リソース階層＝組織→フォルダ→プロジェクト。プロジェクトは課金/権限の基本単位
- 環境/部門の分離はフォルダ/プロジェクト、一貫した制約は組織ポリシーの継承で
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. アーキテクチャ設計の最初に最も重視すべきものはどれですか？
Q2. Google Cloud で課金と権限の基本単位となるのはどれですか？
Q3. 本番環境と開発環境を分離し、環境ごとに異なるポリシーを継承させたい。最も適した方法はどれですか？
Q4. 設計上のトレードオフ（コスト対可用性など）を判断する基準として最も適切なものはどれですか？
Q5. 組織ポリシーと IAM の関係として正しいものはどれですか？
Q6. 「市場投入の速さ」を最優先するビジネス要件に対し、設計の方向性として最も適切なのはどれですか？