📚 GCP PCA 学習: 2026-05-15

セクション: 4.1 技術プロセスの分析と定義 前回からの繋がり: 前セクションの法令遵守設計で「何をしたか」の監査証跡が必須と学んだ。ここでは「何を・どうやって・検証するか」を CI-CD パイプラインの設計で実装する。

① 一言サマリー

「CI-CD パイプラインとは、コード変更から本番環境へのデプロイまでを自動化・検証する仕組みです」

② たとえ話

人が食べる仕出し弁当の製造ラインで考えます。

• 従来方式（CI-CD なし）: 料理人が各自でおかずを作り、衛生チェックなし → 毎回品質がバラバラ、腐った食材が混じることもある
• CI パイプライン（Continuous Integration）: 每个料理人が調理したら、その場で「材料の鮮度・温度・味」を自動検査マシンに通す。NGなら自動で廃棄
• CD パイプライン（Continuous Delivery / Deployment）: 検査をクリアしたおかずは「自動で梱包 → 冷却 → 配送センターへ」と進む。検査結果を全履歴で記録（監査証跡）
• Deployment ≠ Release: 配送センターまで届いて「すぐ売る / 時間をおく / 客別に調整」かは経営判断

つまり： - CI = コード検査を自動化（コンパイル・テスト・品質分析） - CD = デプロイを自動化（ステージング環境 → 本番環境） - 監査ログ = 誰が・いつ・何を・なぜ変更したかを全記録

③ 図解

graph LR
    A["👨‍💻
Developer
コード変更"] --> B["🚀 Cloud Build
（自動ビルド・テスト）"]
    B --> C{{"✅ 全テストOK?"}}
    C -->|NO| D["❌ 変更を却下
（Slack通知）"]
    C -->|YES| E["📦 成果物
Artifact Registry
に保存"]
    E --> F["🎯 Cloud Deploy
（デプロイ自動化）"]
    F --> G["🔄 Canary 5% → Green 25%
→ Blue 100%"]
    G --> H["✔️ 本番環境
Compute Engine/GKE"]
    H --> I["📊 Cloud Logging
監査証跡
（全変更記録）"]

    style A fill:#e1f5ff
    style B fill:#fff3e0
    style C fill:#fce4ec
    style E fill:#f3e5f5
    style F fill:#e0f2f1
    style H fill:#e8f5e9
    style I fill:#fffde7

各段階の役割：

• CI（Continuous Integration）: Cloud Build が Git push をトリガーに自動実行
• コンパイル・ユニットテスト・静的分析・コンテナイメージビルド
• 失敗したら Slack / Email で開発者に通知

• 成功したら Artifact Registry に成果物保存

• CD（Continuous Delivery/Deployment）: Cloud Deploy が Artifact Registry から自動取得・デプロイ

• Canary デプロイ（5% → 25% → 100%）で段階的リスク低減
• ロールバック自動化（エラー率・ レイテンシ突発的増加で自動検出）

• Blue-Green デプロイで 0 ダウンタイム切り替え

• Audit（監査証跡）: Cloud Logging が全ステップ記録

• 誰が・いつ・どの Git Commit・どの成果物をデプロイしたか
• GDPR / HIPAA / PCI DSS 等の監査要件満たし

④ 仕組みの深掘り

なぜ CI-CD が必要か？

PCA 試験の採点軸は「ビジネスリスク最小化」です。

従来のサイロ型（各チームが独立して作業）には以下の問題がある：

1. デプロイ失敗率が高い
2. 手作業が多い → ヒューマンエラー → 本番トラブル

3. 環境差異（ローカル・ステージング・本番で設定が異なる）

4. リグレッション（後戻り）が検出できない

5. 既存機能を壊した状態でデプロイ → ユーザーからクレーム

6. 自動テストなしで「動いていると思い込む」

7. ロールバックが遅い

8. 問題発生時に「だれが・どの成果物をデプロイしたか」が不明
9. 復旧に数時間かかる → ビジネス損失

CI-CD で解決する仕組み

[1] Git Commit push
      ↓
[2] Cloud Build webhook トリガー自動実行
      ├─ コンパイル（Java / Go / Python 等）
      ├─ ユニットテスト（カバレッジ 80% 以上）
      ├─ 統合テスト（DB 連携テスト）
      ├─ 脆弱性スキャン（Container Image Scanning）
      ├─ 静的コード分析（SonarQube 等と連携）
      └─ コンテナイメージビルド → Artifact Registry 保存
          ↓ （失敗時は Slack 通知・ここで止まる）
[3] Cloud Deploy が Artifact Registry から成果物取得
      ├─ Stage 環境にデプロイ（自動テスト実行）
      ├─ Canary デプロイ（5% トラフィック流す）
      │  └─ エラー率 < 0.5% なら次フェーズへ
      ├─ Green デプロイ（25% トラフィック）
      │  └─ エラー率 < 0.5% なら次フェーズへ
      └─ Blue デプロイ（100% トラフィック・本番環境）
          ↓
[4] Cloud Logging に全ステップ記録
      ├─ Deploy ID / Git Commit Hash / Deployer / Timestamp
      ├─ デプロイ結果（成功 / 失敗 / ロールバック）
      └─ エラー内容（本番で発生したら Cloud Logging で即検索可能）

重要な概念：

• CI フェーズ（Build）: コード品質を客観的に検証
• 「開発環境で動いた」→「本番でも動く」という信頼醸成

• テストカバレッジ低い → CI で検出・改善を促す（チェックゲート）

• CD フェーズ（Deploy）: リスク最小化戦略

• Canary デプロイ：5% → 25% → 100% と段階的
• Blue-Green デプロイ：切り替えは「瞬時」、障害時は「瞬時に前バージョンへ戻す」

• これにより SLO（例：99.99% 稼働率）達成

• テスト戦略との関連:

• ユニットテスト：開発者が関数単位で検証
• 統合テスト：複数サービス間の連携を検証（DB・API 連携）
• 負荷テスト：本番規模の同時アクセスに耐えるか
• E2E テスト（Optional）：UI から本番 API まで通すテスト（遅いので実施頻度は低め）

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

「Cloud Build」vs「Cloud Run」の勘違い

「Cloud Deploy」vs「Terraform」の勘違い

「Cloud Build」vs「GitHub Actions」の技術選定

PCA 試験の「正解軸」: - 「GCP 内で完結するか」→ Cloud Build - 「オンプレミス / AWS と混在するか」→ GitHub Actions / Jenkins - 「Canary デプロイで段階的リリースしたい」→ Cloud Deploy - 「インフラ（VPC / GCE）を IaC で管理したい」→ Terraform

⑥ 実務への応用

シナリオ 1: Web スタートアップ（Node.js + GKE）

要件: - 毎日 3～5 回のリリースが必要 - 新機能はカナリアで 10% から開始 - 本番トラブル時は 5 分以内にロールバック必須 - 開発チーム 5 名・デプロイ担当者不在（全員ディベロッパー）

設計:

GitHub: Node.js リポジトリ (main ブランチ)
  ↓ (push webhook)
Cloud Build:
  ├─ npm install
  ├─ npm run test (Jest ユニットテスト)
  ├─ npm run lint (ESLint + Prettier)
  ├─ npm run security-audit (npm audit)
  ├─ Docker build → Artifact Registry に image push
  └─ Cloud Deploy trigger
    ↓
GKE Autopilot Cluster:
  ├─ Stage 環境（Cloud Build から 自動デプロイ）
  │  └─ Smoke Test（API health check）実行
  ├─ Canary: 10% トラフィック（5 分様子見）
  ├─ Green: 50% トラフィック（5 分様子見）
  └─ Blue: 100% トラフィック（本番）

Cloud Logging:
  └─ 全ステップを自動記録（Slack / PagerDuty に連携）

ロールバック流程:
  - エラー率が 1% を超える → Cloud Deploy が自動ロールバック
  - 手動ロールバック：「kubectl rollout undo」と同等の操作を 1 クリック

メリット: - デプロイ 30 秒で完了（手作業 0） - テスト落ち → 自動で本番デプロイ阻止 → DevOps 文化醸成 - 監査ログ完全・PCI DSS / HIPAA 対応可能

シナリオ 2: 受託開発（既存 Java アプリ + Compute Engine）

要件: - レガシー Java アプリ（Spring Boot）のマイグレーション - 本番環境 Compute Engine 5 台（MIG で自動スケール） - テスト環境で毎日検証 - 変更管理が厳格（経営層へ毎週報告）

設計:

GitLab: Java リポジトリ
  ↓ (push webhook)
Cloud Build:
  ├─ Maven build (mvn clean package)
  ├─ JUnit テスト実行
  ├─ SonarQube スキャン（品質ゲート：A グレード以上）
  ├─ OWASP Dependency Check（脆弱性スキャン）
  └─ JAR → GCS / Artifact Registry に保存
    ↓
Cloud Deploy:
  ├─ Staging 環境に新 JAR デプロイ
  │  ├─ smoke test（curl http://staging:8080/health）
  │  └─ JMeter 負荷テスト（100 TPS 30 秒）
  ├─ 本番 Canary デプロイ（1 台の MIG インスタンス）
  │  └─ 5 分監視 → エラー率 0 なら次フェーズ
  ├─ 本番 Blue-Green（残り 4 台）
  └─ ロールバック：前バージョンの JAR に即切り替え

Blue-Green デプロイの実装:
  ├─ Load Balancer が「Group-A（古いバージョン）」と「Group-B（新バージョン）」に振り分け
  ├─ 新 JAR が Group-B に全デプロイされたら、Load Balancer を「Group-B 100%」に切り替え
  └─ 1 時間問題なし → Group-A を削除（古いバージョン完全削除）

監査ログ:
  ├─ Cloud Logging に全ステップ記録
  ├─ 経営層向けレポート：「5月15日 14:32、JAR v2.1.3 をデプロイ、変更者: Alice」
  └─ コンプライアンス監査：「変更承認ワークフロー（Jira ） → デプロイ → 記録」を 100% 検証可能

メリット: - 経営層向けレポートが「自動生成」（デプロイ結果を Cloud Logging クエリで集計） - テスト環境で毎日検証 → 本番での問題ゼロ - 変更管理が厳格でも、CI-CD で「誤操作」「設定誤り」が 99% 防げる

シナリオ 3: AI / データ分析パイプライン（Python + Cloud Functions）

要件: - 毎日 午前 2 時に モデル再学習パイプライン実行 - 新モデル精度が前月比で 2% 以上向上したら自動本番デプロイ - デプロイ失敗時は自動で前月のモデルに戻す

設計:

Git: Python リポジトリ（training.py）
  ↓ (定時トリガー: Cloud Scheduler)
Cloud Build:
  ├─ python -m pytest tests/
  ├─ データセット取得（BigQuery から）
  ├─ モデル再学習（scikit-learn）
  ├─ 精度評価（前月比較）
  │  └─ 精度 >= 前月 + 2% ? → YES: デプロイ, NO: スキップ
  └─ Model Registry（Vertex AI Model Registry）に保存
    ↓
Cloud Deploy:
  ├─ Cloud Functions v2 更新（新モデル使う関数にデプロイ）
  ├─ テスト: 予め用意した検証データセットで精度確認
  └─ Canary: 5% のリクエストで新モデルテスト
    ↓
本番: Cloud Functions
  ├─ API リクエスト → 新モデルで予測
  ├─ レイテンシが 200ms 超過 → 自動ロールバック（前月モデル）
  └─ Cloud Logging に全予測記録（説明可能性対応）

メリット: - モデル精度の自動監視 → デプロイ判断も自動化（人間の判断が不要） - ロールバック自動化 → 精度劣化のリスク最小化

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

誤解 1: 「テストを全部 Cloud Build でやれば品質は 100% 保証される」

❌ 間違い。テスト自動化は「品質の前提条件」ですが「十分条件」ではない。

• Cloud Build で「ユニットテスト・カバレッジ 80%」パスしても、実装ロジックが間違っていれば本番で障害
• テストケース設計が不適切 → テストは通るが、想定外のユーザー操作で障害
• 解決策: テストカバレッジに加えて「エラーバジェット」（許容される障害時間・エラー率）を SLO に組み込み

誤解 2: 「Canary デプロイ = リスク 0」

❌ 間違い。5% に流すトラフィック量が少ないと「珍しいエッジケース」を見落とす。

• 例：アクセスパターンが「平日 9-17 時に集中」の場合、深夜 2 時の Canary デプロイで 5% テストしても無意味
• 解決策: Canary デプロイの監視指標を「エラー率」だけでなく「レイテンシ・CPU 使用率・メモリ」も含める

誤解 3: 「デプロイ自動化 = DevOps」

❌ 間違い。デプロイ自動化は「手段」であって「目的」ではない。

• 目的は「ビジネス要件を素早く・安全に本番に反映する」こと
• CI-CD 導入しても「テスト品質が低い / ロールバック手順がない」なら効果なし
• PCA 試験の採点軸: デプロイ自動化に加えて「監視（SLI）・アラート（SLO 越え時通知）・ポストモーテム（根本原因分析）」がセットになっているか

誤解 4: 「Terraform で VPC を IaC 管理すれば、CI-CD は不要」

❌ 間違い。IaC（Terraform）と CI-CD（Cloud Build/Deploy）は別物。

• Terraform：インフラリソース（VPC / GCE / Load Balancer）の定義・バージョン管理
• Cloud Build/Deploy：アプリケーション（コンテナ / JAR / Python）の自動ビルド・テスト・デプロイ
• 両者は直交（互いに独立）していて、ベストプラクティスは両者を組み合わせる
• Terraform で「GKE クラスタ環境」を定義
• Cloud Build/Deploy で「GKE 上のアプリ」を自動デプロイ

誤解 5: 「Cloud Build の構成ファイル（cloudbuild.yaml）は複雑・学習コストが高い」

❌ 間違い。基本は YAML の順序型リスト。

steps:
  - name: gcr.io/cloud-builders/maven    # ステップ 1: Maven build
    args: ['clean', 'package']
  - name: gcr.io/cloud-builders/docker   # ステップ 2: Docker build
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/app:$SHORT_SHA', '.']
  - name: gcr.io/cloud-builders/docker   # ステップ 3: Artifact Registry push
    args: ['push', 'gcr.io/$PROJECT_ID/app:$SHORT_SHA']

シンプルな構造。複数の Build Step を順序立てて実行するだけ。

落とし穴 6: 「Cloud Deploy で Canary デプロイしたら、本番ユーザーの 5% が影響を受ける」

❌ 考え方が間違っている。正しくは「本番トラフィックの 5% を新バージョンに流す」。

• 例：本番トラフィック 1,000 RPS → Canary は 50 RPS
• Canary で問題が発生 → 新バージョンへの 50 RPS が失敗・ロールバック
• 結果：全ユーザーへの影響は「0.05% のリクエスト失敗」で済む（SLA 99.9% でも許容範囲）

⑧ 理解度チェック

シナリオ: 金融機関のカスタマーポータル（Web アプリ）のリリース戦略

要件： - 毎週 1 回、新機能をリリース - 本番環境 Compute Engine 10 台（MIG で自動スケール） - 過去 6 ヶ月間、デプロイ後 30 分以内に障害が 3 回発生 - SLA は 99.99%（年間ダウンタイム 52 分以内） - コンプライアンス：「全変更を 6 年間監査可能」

問題: 上記要件を満たす CI-CD パイプラインはどれか？

• (A) Cloud Build でテスト実行後、Compute Engine MIG に直接デプロイ（100% トラフィック一括）
• (B) Cloud Build でテスト実行後、Cloud Deploy で Staging 環境検証 → Canary 5% → Green 50% → Blue 100%
• (C) GitHub Actions で CI 実行 → Jenkins でデプロイ（オンプレミス Jenkins で履歴管理）
• (D) Cloud Build でビルド後、Artifact Registry に保存。デプロイは手作業（スプレッドシートで変更管理）

⑨ 深掘り補足（PCA 試験範囲外・オプション）

最新 GA: Cloud Deploy リリース管理機能

⚠️ 最新情報（2026年5月時点）

Cloud Deploy は以下の GA 機能をリリース： - Release Monitor: デプロイ後 24 時間のメトリクス自動監視。エラー率・レイテンシ・SLI が SLO を超えたら自動アラート。 - Deployment Dashboards: Cloud Console で「本番環境のデプロイ履歴・成功率・ロールバック回数」をリアルタイム可視化。 - GitOps Integration: Git リポジトリの「release branch」に Tag を push → 自動デプロイ（手作業不要）。

実務への応用: - SRE チームが「デプロイ成功率 99% 以上」をメトリクスとして追跡可能 - 毎週のスタンドアップで「先週のデプロイ 5 件中 1 件ロールバック」という事実ベースの議論が可能

テスト戦略: 「ピラミッド」vs「アイスクリーム」

ピラミッド（推奨）          アイスクリーム（避けるべき）
    △ E2E 少ない                     ▲ E2E 多い
   △△ 統合 中程度                  ▲▲ 統合 少ない
  △△△ ユニット 多い              ▲▲▲ ユニット 中程度

• ピラミッド: ユニットテスト → 統合テスト → E2E テスト の順に「数が減る」。
• 理由：ユニットテストが高速（100ms）で、E2E テストが低速（10秒）。

• CI-CD では「ユニット失敗 → 即フィードバック」で開発効率向上。

• アイスクリーム: E2E テストが多い → CI-CD が遅い（数分かかる）→ 開発者のフィードバック待機時間が長い（生産性低下）。

PCA 試験でのポイント: - テスト戦略を聞かれたら「ピラミッド構造で、ユニットテストの数が最も多い」と答える。

ロールバック戦略: 「Blue-Green」vs「Canary」vs「Rolling」

PCA 試験での選択軸： - SLA 99.99% 以上 → Blue-Green（ロールバック時間が瞬時） - ユーザー影響を最小化 → Canary（5% テスト） - リソース（メモリ）制約がある → Rolling（ただしダウンタイムリスク上がる）

次回: 4.2 ビジネスプロセスの分析と定義