変更要約: Professional Cloud Developer 第5章を新規作成（ドメイン4「統合」前半: データ/ストレージ/メッセージング＝Cloud SQL/Firestore/Cloud Storage 接続・コネクションプール・Cloud SQL Auth Proxy・ADC・Pub/Sub 発行/購読/at-least-once/デッドレター、Google Cloud API の利用＝サービス有効化・クライアントライブラリ/REST/gRPC・バッチ/結果制限/ページネーション/キャッシュ・指数バックオフ・サービスアカウント）。
5.1データ・ストレージ・メッセージングとの統合
Cloud SQL・Firestore・Cloud Storage などデータストアへの接続管理、各種データソースへの読み書き、Pub/Sub によるデータの発行と購読、そして接続の安全性とプール・認証（Cloud SQL Auth Proxy など）を理解します。
アプリは単体では完結せず、データストアやメッセージングと統合して価値を出します。接続を安全・効率的に管理することが鍵です。
5.1.1データストアへの接続
アプリは Cloud SQL・Firestore・Cloud Storage など複数のデータストアへ接続し、読み書きします。データベースへは コネクションプール で接続を再利用し、過剰な接続を避けます。Cloud SQL への安全な接続には Cloud SQL Auth Proxy（IAM 認証・暗号化で公開 IP を露出させない）を使います。認証は アプリケーションデフォルト認証情報（ADC） とサービスアカウントで行います。「Cloud SQL に安全接続＝Cloud SQL Auth Proxy」「接続の再利用＝コネクションプール」と結びます。
5.1.2メッセージングによる発行と購読
Pub/Sub は、データを 発行（publish） する側と 購読（subscribe） する側を疎結合にするメッセージングです。発行者はトピックへメッセージを送り、購読者はサブスクリプションから受け取ります（プッシュ/プル）。これにより、スパイクの吸収・非同期処理・複数の購読者への配信ができます。順序や重複（at-least-once）の扱い、デッドレターも設計します。「疎結合な非同期配信＝Pub/Sub の発行/購読」を押さえます。
「要件 → 手段」が頻出。例：「Cloud SQL へ公開 IP を露出せず安全接続」＝Cloud SQL Auth Proxy、「接続の枯渇を防ぐ」＝コネクションプール、「発行者と購読者を疎結合に」＝Pub/Sub、「スパイクを吸収し非同期処理」＝Pub/Sub のサブスクリプション、「処理失敗メッセージの退避」＝デッドレタートピック。
混同に注意：
①Pub/Sub は通常 at-least-once＝重複し得るので冪等に処理する。
②コネクションプールを使わないと接続枯渇が起きやすい。
③Cloud SQL Auth Proxy は安全接続の手段で、公開 IP 直結より推奨。
5.1.3この節のまとめ
- データストア接続は ADC＋サービスアカウント、Cloud SQL は Auth Proxy、接続はプールで再利用
- Pub/Sub で発行/購読を疎結合に（スパイク吸収・非同期・複数購読者）
- Pub/Sub は at-least-once＝冪等処理、失敗はデッドレターへ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Cloud SQL へ公開 IP を露出させず、IAM 認証・暗号化で安全に接続したい。使うのはどれですか？
Q2. データベースへの接続を再利用し、接続の枯渇を防ぎたい。最適な方法はどれですか？
Q3. 発行者と購読者を疎結合にし、非同期にメッセージを配信したい。最適なのはどれですか？
Q4. Pub/Sub は通常 at-least-once 配信です。購読側で重複に備えるべき設計はどれですか？
Q5. 処理に繰り返し失敗するメッセージを退避させたい。Pub/Sub で使うのはどれですか？
Q6. アプリから Google Cloud サービスへ認証する基本的な方法はどれですか？