コンテンツにスキップ

📚 GCP PCA 学習: 2026-06-07

セクション: 5.2 GCP SDK を使った Google Cloud との連携 前回からの繋がり: IaC と Terraform で「環境をコード化」したら、実務では gcloud・gsutil・bq などのコマンドライン SDK で日々の操作・自動化・パイプライン構築を行う。SDK は「インフラ設定」から「データ操作」まで全サービスを統一インターフェースで操作できる仕組み。

① 一言サマリー

「GCP SDK とは、ローカル・CI-CD・Cloud Shell から Google Cloud のあらゆるサービスを操作するための統一ツールセット」。Cloud Console（UI）だけでなく、スクリプト・自動化・パイプラインをコード化する基盤。

② たとえ話

家に例えるなら： - Google Cloud Console = 物理的にドアベルを押して家の管理人に頼む（UI で操作、遅い、リスク） - gcloud / gsutil / bq = 家の管理人に「電話で指示する」（コマンドライン、速い、スクリプト化できる） - クライアントライブラリ（Python・Go・Node.js） = 家の管理人の「内線番号を知る」（プログラムから直接呼び出し、最速） - Cloud Shell = どこからでも「Wi-Fi で電話かけられる」（環境セットアップ不要、GCP 上で実行）

すべての方法が同じサービスを操作しているが、「誰が・どこから・どう操作するか」で使い分ける。

③ 図解

graph LR
    DevLocal["💻 ローカルPC
gcloud CLI"]
    DevCI["⚙️ CI-CD パイプライン
Terraform / gcloud"]
    DevShell["☁️ Cloud Shell
gcloud / gsutil / bq"]
    AppCode["📱 アプリケーション
Python / Go / Node.js"]

    GCP["🔧 Google Cloud API
（全サービスの統一インターフェース）"]

    Services["サービス群
Compute / Storage / BigQuery
IAM / Monitoring / etc"]

    DevLocal --> GCP
    DevCI --> GCP
    DevShell --> GCP
    AppCode --> GCP
    GCP --> Services

    style GCP fill:#4285F4,color:#fff
    style Services fill:#34A853,color:#fff
    style DevLocal fill:#FBBC04,color:#000
    style DevCI fill:#EA4335,color:#fff
    style DevShell fill:#A142F4,color:#fff
    style AppCode fill:#00BCD4,color:#fff

④ 仕組みの深掘り

gcloud CLI の内部動作

  1. 認証（Authentication）
  2. gcloud auth login で Google アカウント認証 → OAuth 2.0 トークン取得
  3. gcloud config set project ID でデフォルトプロジェクト指定
  4. Service Account キーを使う場合：gcloud auth activate-service-account --key-file=...

  5. トークンは ~/.config/gcloud/application_default_credentials.json に自動保存

  6. API 呼び出しの仕組み

  7. gcloud コマンドはすべてREST API（JSON）または RPC API（gRPC）にマッピング
  8. 例：gcloud compute instances create my-vm → /compute/v1/projects/{project}/zones/{zone}/instances へ POST

  9. gcloud はこの API 呼び出しを「ラップして、人間が読みやすいコマンドにしたもの」

  10. CLI 引数 → API リクエストの変換 

    gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --machine-type=n1-standard-1 \
  --image-family=debian-12 \
  --image-project=debian-cloud
    ↓ 
    {
  "name": "my-vm",
  "zone": "zones/us-central1-a",
  "machineType": "zones/us-central1-a/machineTypes/n1-standard-1",
  "disks": [{
    "sourceImage": "projects/debian-cloud/global/images/family/debian-12"
  }]
}

  11. 非同期オペレーション（Long-running Operation）

  12. Compute Engine VM 作成・削除は数秒～数分かかる
  13. gcloud は Operation ID を取得し、--async で即座に返すか、--wait で完了を待つ

  14. 背景：GCP API は大規模操作を非同期で処理するため、ポーリング（Operation.get()）で進捗確認

  15. レート制限・リトライ

  16. gcloud は自動的にExponential Backoffでリトライ（指数関数的待機）
  17. 429 Too Many Requests → 1 秒待機 → リトライ → 2 秒待機 → リトライ...
  18. 本来は手動で実装する必要があるが、gcloud・SDK が自動化している

認証スコープ（Scopes）

Service Account の権限は「IAM Role（粗粒度）」と「OAuth Scopes（細粒度）」の 2 段階で制御：

┌─────────────────────────────────────────┐
│ IAM Role: compute.admin                 │ ← 「Compute Engine 全権」
│ (what you can do)                       │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│ OAuth Scopes: cloud-platform            │ ← 「すべての Scope を有効」
│ (which APIs you can reach)              │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│ Actual: Compute Engine API 呼び出し OK  │
└─────────────────────────────────────────┘

Scope が https://www.googleapis.com/auth/compute.readonly だけの場合、IAM Role が compute.admin でも「読み取り専用」に制限される。

Cloud Shell の優位性

local PC                Cloud Shell
─────────────────────────────────────
gcloud インストール     プリインストール ✓
Python / Go 環境構築    各言語プリセット ✓
API 認証情報セットアップ GCP に統合 ✓
ファイル転送           クラウドストレージ直結 ✓
セッション保持         Cloud Persistent Disk で自動 ✓

→ 結論：初学者・試験勉強 → Cloud Shell、本番 CI-CD → gcloud in Container

⑤ 他サービスとの使い分け

用途 選定サービス 理由
単発のコマンド実行 gcloud CLI gcloud compute instances list 1 行で完結
複数サービスの連鎖操作 gcloud CLI + Bash スクリプト リスト反復・条件分岐が容易
インフラ IaC・宣言的管理 Terraform（gcloud ではなく） 冪等性・差分検出・State 管理が必須
本番パイプラインから GCP 操作 Cloud Build + gcloud / API CI-CD ネイティブな認証・監査ログ自動記録
アプリケーション内からの操作 クライアントライブラリ（Python・Go・Node.js） SDK が API エラーハンドリング・リトライを自動化
一時的な検証・デバッグ Cloud Shell 環境準備ゼロ・GCP リソースに直結
大規模ファイル転送 gsutil（+並列転送） マルチパート・リトライ・チェックサム自動
BigQuery 探索クエリ bq CLI（+--max_rows=1000） SQL 実行・結果取得が 1 コマンド

PCA 試験の判断軸： - UI（Console）を指定する選択肢 → 「スケーラビリティに欠ける」× - gcloud だけで足りる場合に Terraform 選択 → 「複雑性の過剰」× - API 呼び出しが必須な場合に Cloud Shell で gcloud だけ → 「認証・監査ログ不備」×

⑥ 実務への応用

例 1: Web スタートアップの CI-CD パイプライン

# Cloud Build の cloudbuild.yaml
steps:
  - name: 'gcr.io/cloud-builders/gke-deploy'
    args: ['run', '--help']

  - name: 'gcr.io/cloud-builders/gcloud'
    args:
      - 'container'
      - 'images'
      - 'scan'
      - 'gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA'

  - name: 'gcr.io/cloud-builders/kubectl'
    args: ['set', 'image', 'deployment/my-app', 'my-app=gcr.io/$PROJECT_ID/my-app:$COMMIT_SHA']
    env: ['CLOUDSDK_COMPUTE_ZONE=us-central1-a', 'CLOUDSDK_CONTAINER_CLUSTER=my-cluster']

→ git push すると： 1. Dockerfile ビルド 2. gcloud で脆弱性スキャン 3. kubectl で GKE にローリングアップデート 4. デプロイ完了ログが Cloud Logging に記録 すべてが自動化・監査可能。

例 2: BigQuery 夜間バッチ処理

# Cloud Scheduler（毎晩 0:00 JST）から実行
#!/bin/bash
bq query --use_legacy_sql=false \
  --destination_table=project.dataset.daily_summary \
  --replace \
  'SELECT DATE(timestamp) as date, COUNT(*) as cnt FROM `project.dataset.events` GROUP BY date'

# 結果を Slack に通知
curl -X POST https://hooks.slack.com/... \
  -d "Processed $(bq query --use_legacy_sql=false 'SELECT COUNT(*) FROM project.dataset.daily_summary' --format=csv | tail -1) rows"

→「誰が・何を・いつ実行した」が Cloud Audit Logs に自動記録 → 監査対応・トラブルシューティングが容易。

例 3: 受託開発で複数環境管理

# 開発環境・ステージング・本番で異なるプロジェクト
export PROJECTS=('dev-project' 'staging-project' 'prod-project')
export ZONES=('us-central1-a' 'us-central1-b' 'us-central1-c')

for i in "${!PROJECTS[@]}"; do
  gcloud config set project ${PROJECTS[$i]}
  gcloud compute instances create "web-$(date +%s)" \
    --zone=${ZONES[$i]} \
    --machine-type=n1-standard-1 \
    --image-family=debian-12
done

→ 1 スクリプトで 3 環境すべてに同じ構成を自動デプロイ（ドリフト防止）。

⑦ よくある誤解・落とし穴

誤解 1: 「gcloud コマンドはすべて Cloud Shell で」

❌ 誤り： 

# Cloud Shell で手動実行したら OK？
gcloud compute instances create --image...

✓ 正解： - 本番は Cloud Build（CI-CD）で gcloud を実行 → Cloud Audit Logs に記録 - Cloud Shellで手動実行 → 監査ログが「Cloud Shell ユーザー」に紐付き、後で「誰がやったか」追跡困難

PCA 試験的判定：「自動化・監査可能性」が評価軸。

誤解 2: 「Service Account キーはコードに埋め込む」

❌ 危険： 

# .py ファイルに埋め込んだら git に commit されて漏洩
os.environ['GOOGLE_APPLICATION_CREDENTIALS'] = '/path/to/key.json'  # ❌ コード埋め込み

✓ 正解： 

# Workload Identity Federation（信頼できるリソースから認証）
# または Secret Manager を使用
gcloud secrets create db-password --data-file=- < password.txt

Service Account キーは生成しない（Workload Identity で認証）。

誤解 3: 「API リファレンスを見ながら REST API を curl で叩く」

❌ 非効率： 

curl -X POST https://compute.googleapis.com/compute/v1/projects/...
  -H "Authorization: Bearer $(gcloud auth print-access-token)"
  -H "Content-Type: application/json"
  -d '{...}'

✓ 推奨： 

gcloud compute instances create my-vm --zone=us-central1-a  # 1 コマンド

ただし「カスタム API フィールドをセットしたい」場合のみ REST API を使う。

誤解 4: 「oauth2l（OAuth トークン生成ツール）をいちいち実行する」

❌ 手動管理： 

oauth2l fetch --client_secret=... cloud-platform
# トークンが期限切れ → 再実行

✓ gcloud が自動管理： 

gcloud auth login  # 1 回だけ
gcloud compute instances list  # 以降はトークン自動更新

誤解 5: 「bq query の結果を Python で処理するなら BigQuery API を直接使う」

❌ 複雑： 

from google.cloud import bigquery
client = bigquery.Client()
job = client.query("SELECT ...")  # 非同期
result = job.result()  # ポーリング待機

✓ gcloud + Bash パイプ（小規模）： 

bq query --use_legacy_sql=false --format=csv \
  'SELECT * FROM table LIMIT 1000' | python process.py

ただし「大規模（100GB+）・リアルタイム・複数クエリの並列実行」なら Python SDK が必須。

誤解 6: 「gcloud は単なる UI ラッパー」

❌ 誤解： 

# Cloud Console で VM 作成 = gcloud compute instances create で OK？

実際： - gcloud は Console より豊富なオプションを持つ（例：--create-disk で詳細ディスク設定） - gcloud でしかできない機能も多い（例：--async で非同期実行） - PCA 試験：gcloud の存在を知っていることが前提

⑧ 理解度チェック

次のシナリオで最適なアプローチを選んでください：

「Web スタートアップが GCP で新しい Compute Engine インスタンスを開発・ステージング・本番の 3 環境に自動デプロイしたい。変更管理・監査ログ・段階的ロールアウトをすべて満たす必要があります。どのツールの組み合わせを選びますか？

  • (A) Cloud Shell で gcloud compute instances create を 3 回実行
  • (B) Terraform + Cloud Build（Git push → 自動デプロイ）+ Service Account 認証
  • (C) Cloud Console UI で手動作成 → 3 環境に復製
  • (D) gcloud コマンドを Python スクリプトで実行し、ローカルから手動実行」
答え（クリック） **正解：(B) Terraform + Cloud Build（Git push → 自動デプロイ）+ Service Account 認証** **各選択肢の評価**： - **(A) Cloud Shell で `gcloud compute instances create` を 3 回実行**：gcloud は便利だが手動実行のため「誰がいつ変更したか」の監査ログが曖昧になり、変更管理ゲートが機能しない。繰り返し実行性も低い（毎回手入力のリスク）。 - **(B) Terraform + Cloud Build（Git push → 自動デプロイ）+ Service Account 認証**：✓ 正解。理由は以下： 1. **Terraform**：IaC で「3 環境の構成を宣言的に管理」→ ドリフト検出・再現性確保 2. **Cloud Build**：Git push トリガー → 自動デプロイ → Cloud Audit Logs に「誰が・どのコミット・いつ」を記録 3. **段階的ロールアウト**：Terraform Workspace で環境分離 + Cloud Deploy で Canary リリース 4. **Service Account**：Human キーを避け、Workload Identity で認証 → 監査可能 - **(C) Cloud Console UI で手動作成 → 3 環境に復製**：UI は「マウスクリック」ベースのため、スクリプト化・自動化・監査が不可能。PCA 試験では即 ×。 - **(D) gcloud コマンドを Python スクリプトで実行し、ローカルから手動実行**：gcloud の 3 回実行と同じ問題。「ローカルから手動」という点で、変更管理ゲート・監査ログの一元化が失われる。本番運用では Service Account キーをローカルに配置する必要があり、セキュリティリスク。

⑨ 深掘り補足

最新 GA 機能（2026 年 6 月）

  1. Cloud Location Finder（GA）：位置情報ベースのリソース検出。gcloud locations list で対応リージョン確認可能。

  2. gcloud Syntax Suggestion（Preview）：gcloud コマンド入力時に AI が正しいフラグ・値を提案する機能。gcloud compute instances create --ai-hints で試験的に利用可能。

gcloud の内部実装

gcloud は Pythonで実装されており、~/.config/gcloud/ 配下に： - properties：デフォルトプロジェクト・ゾーン・エディタ等の設定 - configurations/：複数プロファイル管理（gcloud config configurations list） - application_default_credentials.json：OAuth トークン（自動更新）

# 複数プロファイル切り替え
gcloud config configurations list
gcloud config configurations activate dev-project
gcloud config configurations activate prod-project

API 呼び出しのデバッグ

# API リクエスト・レスポンスの詳細ログを表示
gcloud compute instances create my-vm --log-http

PCA 試験では「gcloud がバックグラウンドで何の API を呼び出しているか」を理解することで、トラブルシューティング・最適化ができるようになる。

クライアントライブラリ（Python の例）

from google.cloud import compute_v1
from google.api_core.gapic_v1 import client_info

# 自動リトライ・タイムアウト設定
client = compute_v1.InstancesClient(
    client_options={
        'api_audience': 'https://www.googleapis.com',
        'client_info': client_info.ClientInfo(gapic_version='v1')
    }
)

# 非同期オペレーション
operation = client.insert(project='my-project', zone='us-central1-a', body={...})
print(f"Operation ID: {operation.name}")

クライアントライブラリは gcloud より低レベルだが、プログラム内での詳細制御が可能。「アプリケーション内から GCP リソース操作」が必須ならクライアントライブラリ、「CI-CD パイプラインから簡潔に実行」なら gcloud。

Workload Identity Federation（推奨認証方式）

Service Account キーの生成を避けるための最新パターン：

# GitHub Actions から GCP へ認証（キーなし）
- name: Authenticate to Google Cloud
  uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: 'projects/123456/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
    service_account: 'github-actions@my-project.iam.gserviceaccount.com'

- name: Deploy
  run: gcloud compute instances ...

PCA 試験では「Workload Identity Federation を使っている」設計が最高点。Service Account キーは「レガシー（後方互換性のため残存）」。

次回: 6.1 モニタリング・ロギング・プロファイリング・アラートの設計