セクション2：アプリケーションの構築とテスト

公式試験ガイド 042426版 — Section 2: Building and testing applications

2.1 開発環境のセットアップ

3つの「開発する場所」と特徴比較

Cloud Workstations 深掘り（2026改訂で重要）

2026年改訂で 新規追加された頻出トピック。「企業の標準開発環境を強制する」シナリオで定番解答。

3層構造

3層リソースの役割

サポートされる IDE

• Base Editor（ブラウザ版 Code OSS）: ブラウザだけで使える VSCode 互換
• VSCode（ローカル）: Remote SSH で接続、ローカル UI で操作
• JetBrains IDE（ブラウザ JetBrains Gateway）: IntelliJ Ultimate / PyCharm Professional / GoLand
• SSH: 任意の IDE / Vim / Emacs から接続可

🆕 Gemini Cloud Assist 深掘り（2026改訂）

2026改訂で明示的にシラバスに加わった AI アシスタント。GCP コンソール、Cloud Code、Cloud Workstations の各所で動作。

🆕 MCP（Model Context Protocol）サーバー（2026改訂）

2026改訂で初出。AI モデルが外部リソース（GitHub、DB、社内API）に接続する標準プロトコル。試験で名前を覚えていれば即答可能なトピック。

MCP の概念

• 標準化: 各 AI ツール（Claude Desktop / Cursor / Cline 等）が同じプロトコルで外部を扱える
• ツール定義: 「GitHub の PR を取得」「BigQuery にクエリ」などを関数（tool）として定義
• リソース定義: ファイル / DB レコードをリソース URIで表現
• プロンプト: 共通のプロンプトテンプレートを配布可能

gcloud エミュレータでローカル開発

本番 GCP に課金されずに、ローカルでテスト・開発するためのツール群。

# テストコード（Pub/Sub エミュレータ利用）
import os
os.environ["PUBSUB_EMULATOR_HOST"] = "localhost:8085"

from google.cloud import pubsub_v1
publisher = pubsub_v1.PublisherClient()  # 自動的にエミュレータに接続
topic_path = publisher.topic_path("test-project", "test-topic")
publisher.create_topic(request={"name": topic_path})
publisher.publish(topic_path, b"hello")

2.2 ビルド

Cloud Build YAML の構造

# cloudbuild.yaml の完全構造例
steps:
  # 各ステップは Docker コンテナで実行
  - id: 'lint'
    name: 'python:3.11'              # 実行するコンテナイメージ
    waitFor: ['-']                   # 並列実行（依存なし）
    entrypoint: 'bash'
    args: ['-c', 'pip install ruff && ruff check src/']

  - id: 'unit-test'
    name: 'python:3.11'
    waitFor: ['-']                   # lint と並列
    entrypoint: 'bash'
    args: ['-c', 'pip install -r requirements.txt pytest && pytest tests/']
    env:
      - 'CI=true'

  - id: 'build'
    name: 'gcr.io/cloud-builders/docker'
    waitFor: ['lint', 'unit-test']   # 両方を待つ
    args: ['build',
           '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$SHORT_SHA',
           '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:latest',
           '.']

  - id: 'vuln-scan'
    name: 'gcr.io/cloud-builders/gcloud'
    waitFor: ['build']
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        gcloud artifacts docker images scan \
          us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$SHORT_SHA \
          --format=json | tee /workspace/scan.json
        # HIGH/CRITICAL があれば失敗
        ! grep -E '"severity":\s*"(HIGH|CRITICAL)"' /workspace/scan.json

  - id: 'push'
    name: 'gcr.io/cloud-builders/docker'
    waitFor: ['vuln-scan']
    args: ['push', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$SHORT_SHA']

  - id: 'deploy'
    name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args: ['run', 'deploy', 'my-app',
           '--image', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$SHORT_SHA',
           '--region', 'us-central1',
           '--no-traffic',
           '--tag', 'canary']

# images で push 対象を宣言（自動 push + provenance 生成）
images:
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/app:$SHORT_SHA'

# シークレットの宣言
availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/SLACK_WEBHOOK/versions/latest
      env: 'SLACK_WEBHOOK'

# ビルドオプション
options:
  machineType: 'E2_HIGHCPU_8'        # 高速ビルド用マシン
  logging: CLOUD_LOGGING_ONLY
  substitution_option: ALLOW_LOOSE

# Substitutions（自動定義 + カスタム）
substitutions:
  _REGION: 'us-central1'
  _ENVIRONMENT: 'staging'

# タイムアウト（デフォルト 10分、最大 24時間）
timeout: '1200s'

自動定義される Substitutions

ビルド時間短縮の5つの戦略（公式推奨）

options:
  machineType: 'E2_HIGHCPU_8'   # 8 vCPU 8GB（デフォルト e2-medium の 4倍）
  # 選択肢: E2_HIGHCPU_8 / E2_HIGHCPU_32 / N1_HIGHCPU_8 / N1_HIGHCPU_32

steps:
  # 既存イメージを pull（キャッシュ用）
  - name: 'gcr.io/cloud-builders/docker'
    entrypoint: 'bash'
    args: ['-c', 'docker pull IMAGE:latest || exit 0']

  # cache-from を使ってビルド
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build',
           '--cache-from', 'IMAGE:latest',
           '-t', 'IMAGE:$SHORT_SHA',
           '-t', 'IMAGE:latest',
           '.']

steps:
  # キャッシュ復元
  - name: 'gcr.io/cloud-builders/gsutil'
    args: ['-m', 'cp', '-r', 'gs://cache-bucket/pip-cache', '/workspace/.cache']
    waitFor: ['-']

  # ビルド（キャッシュを使う）
  - name: 'python:3.11'
    entrypoint: 'bash'
    args: ['-c', 'pip install --cache-dir=/workspace/.cache/pip -r requirements.txt']

  # キャッシュ保存
  - name: 'gcr.io/cloud-builders/gsutil'
    args: ['-m', 'cp', '-r', '/workspace/.cache', 'gs://cache-bucket/']

# .gcloudignore（gitignore と同様の構文）
.git
.github
*.md
docs/
node_modules/
__pycache__/
*.pyc
dist/
build/
vendor/
.env*

Cloud Build でのシークレット利用

# cloudbuild.yaml
availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/SLACK_WEBHOOK/versions/latest
      env: 'SLACK_WEBHOOK'      # この名前で参照される環境変数

steps:
  - name: 'gcr.io/cloud-builders/curl'
    entrypoint: 'bash'
    secretEnv: ['SLACK_WEBHOOK']        # step ごとに参照を宣言
    args:
      - '-c'
      - |
        curl -X POST -H 'Content-Type: application/json' \
          -d "{\"text\":\"Build succeeded: $SHORT_SHA\"}" \
          "$$SLACK_WEBHOOK"            # $$ で参照（$ は substitution と衝突）

Artifact Registry 深掘り

Container Registry (gcr.io) の後継。新規プロジェクトでは必須選択。

サポートする形式（フォーマット）

Container Registry との違い

リポジトリ作成

# Docker リポジトリの作成
gcloud artifacts repositories create my-app \
  --repository-format=docker \
  --location=us-central1 \
  --description="Production app images" \
  --kms-key=projects/$PROJECT_ID/locations/us-central1/keyRings/binauthz/cryptoKeys/registry-cmek

# Docker 認証設定
gcloud auth configure-docker us-central1-docker.pkg.dev

# Push
docker push us-central1-docker.pkg.dev/$PROJECT_ID/my-app/image:v1

Buildpacks による Dockerfile 不要のビルド

Cloud Native Buildpacks をベースにした、ソースコードからコンテナを自動生成する仕組み。

# ソースから直接 Cloud Run へ
gcloud run deploy my-service --source . --region us-central1
# 内部で起きること:
# 1. ソースを ZIP して GCS にアップ
# 2. Cloud Build が起動
# 3. Buildpacks が言語を自動検出（requirements.txt → Python、package.json → Node.js）
# 4. セキュリティパッチ済みベースイメージを選択
# 5. アプリ依存をインストール、最小イメージ生成
# 6. Artifact Registry に push
# 7. Cloud Run にデプロイ
# 8. HTTPS URL を返却

サポートされる言語

• Python（requirements.txt / Pipfile / pyproject.toml）
• Node.js（package.json）
• Go（go.mod）
• Java / Kotlin（pom.xml / build.gradle）
• Ruby（Gemfile）
• .NET（*.csproj）
• PHP（composer.json）

2.3 テスト

テストピラミッド（Cloud Build 上の実装）

AI コーディングアシスタントを使ったテスト生成

# ユニットテストの雛形を AI に生成させ、人間がエッジケースを補完するパターン

# AI に「order_service.py のテストを書いて」と指示すると…
def test_create_order_success():
    order = create_order(user_id="u1", items=[("p1", 2)])
    assert order.status == "PENDING"
    assert order.total == 200

def test_create_order_empty_items_raises():
    with pytest.raises(ValueError):
        create_order(user_id="u1", items=[])

# 人間がエッジケースを追加（AI が見落としがち）
def test_create_order_negative_quantity_raises():
    with pytest.raises(ValueError):
        create_order(user_id="u1", items=[("p1", -1)])

def test_create_order_inventory_exhausted():
    # 在庫切れシナリオは AI が見落としがち
    with pytest.raises(InventoryError):
        create_order(user_id="u1", items=[("out_of_stock_item", 1)])

サプライチェーンセキュリティ（SLSA）

Section 2 の仕上げトピック。Cloud Build → Artifact Registry → Binary Authorization の流れを完全に理解する。

SLSA レベルとは

SLSA = Supply chain Levels for Software Artifacts。サプライチェーンセキュリティの成熟度を 4段階で表現。

Provenance（プロビナンス）とは

「このイメージは誰が・どのソースから・どのビルダーで作ったか」のメタデータ証跡。改ざん検出と監査に使う。

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "us-central1-docker.pkg.dev/my-project/my-repo/app",
    "digest": {"sha256": "abc123..."}
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://cloudbuild.googleapis.com/...",
      "externalParameters": {
        "sourceRepository": "https://github.com/my-org/my-repo",
        "sourceRevision": "abc1234567890"
      },
      "internalParameters": { "projectId": "my-project" },
      "resolvedDependencies": [...]
    },
    "runDetails": {
      "builder": { "id": "https://cloudbuild.googleapis.com/GoogleHostedWorker@v0.3" },
      "metadata": {
        "invocationId": "projects/.../builds/...",
        "startedOn": "2026-05-28T12:00:00Z",
        "finishedOn": "2026-05-28T12:03:42Z"
      }
    }
  }
}

Binary Authorization で provenance を検証

provenance を attestor の署名と組み合わせれば、デプロイ時に「本当に Cloud Build で・本当にこのリポジトリのこのコミットから作られたか」を検証できる。

Artifact Analysis（脆弱性スキャン）

# 手動スキャン
gcloud artifacts docker images scan IMAGE_URL

# Cloud Build 内で実行 + HIGH/CRITICAL があれば失敗
gcloud artifacts docker images scan IMAGE_URL --format=json | \
  python -c "
import json, sys
data = json.load(sys.stdin)
high_critical = [v for v in data['response']['scan']['discoveryOccurrence']['vulnerability']
                 if v['severity'] in ('HIGH', 'CRITICAL')]
if high_critical:
    print(f'Found {len(high_critical)} HIGH/CRITICAL vulnerabilities')
    sys.exit(1)
"

🚨 事故ケース集（postmortem 形式）

セクション2 試験戦略まとめ