Deep Dive: サービス別・技術的事故ケース集

🚨 症状 / 🔬 原因

訓練コードと一緒に CSV を Docker image に焼き込み → image build が 30 分以上、ジョブ起動が遅く、image rebuild の度に転送料金がかかる。 公式：「Don't store training data together with your code, whether you create a Python training application or a custom container image.」

✅ 対処

データは必ず GCS / BigQuery に分離。コンテナにはコードのみ。Artifact Registry へのプッシュサイズも抑える。

📝 試験ポイント

image build 時間・転送量・再現性のため、データとコードを分けるのは基本。

🚨 症状

FP16 mixed precision を入れて訓練速度を上げようとしたら、数 epoch で loss=NaN になり訓練が破綻。

🔬 原因

FP16 のダイナミックレンジが狭く、勾配が overflow / underflow。loss scaling なしでは小さな勾配が 0 に丸まる。

✅ 対処

• BF16 に切替（A100/H100/TPU はネイティブ対応、レンジが広い）
• FP16 を使うなら dynamic loss scaling（torch.cuda.amp.GradScaler 等）
• 学習率を 1/10 に下げて Warmup を追加
• 勾配クリッピング（torch.nn.utils.clip_grad_norm_）

📝 試験ポイント

「混合精度の高速化」が選択肢にあるとき、BF16 を優先するシナリオが多い。

🚨 症状

Primary + Reduction Server だけ使いたく、workerPoolSpecs[0] と workerPoolSpecs[2] を指定して [1] を省略 → job 作成が失敗。

🔬 原因

公式：「The fixed ordering means specifications must be provided for all preceding pools, even if empty, to specify later pools.」

✅ 対処

workerPoolSpecs[1] に空の spec（replica-count=0）を入れて連続性を保つ。または Primary に必要分まとめて押し込む。

🚨 症状

新世代 TPU v5p に移行したのに、想定よりスループットが出ない。コードはそのまま動くが、利用率（MXU usage）が低い。

🔬 原因

公式：「You can run the same code on different versions of TPUs as long as the TPUs have the same number of TensorCores or chips ... However, if you change to a TPU type with a larger or smaller number of TensorCores or chips, you will need to perform significant tuning and optimization.」 世代変更でバッチサイズ・シャーディング戦略・compute/memory ratio が変わる。

✅ 対処

• バッチサイズを TPU chip 数に合わせて再調整
• JAX なら jax.sharding で分散を見直し
• profiler で MXU 利用率を測定

📝 試験ポイント

「世代を上げれば自動で速くなる」は誤り。シャーディング・チューニングのコストを必ず計算する。

🚨 症状

Multislice 構成で訓練中、1 つの slice の ICI 障害で全 slice の訓練が止まり、checkpoint も中途半端な状態。

🔬 原因

Multislice は DCN 越しに同期で all-reduce を行うため、1 slice の障害が全体に伝播。「ICI resiliency」は OCS 周りの障害を自動再ルーティングするが、その間「temporary degradation in ICI performance」になる。

✅ 対処

Orbax (JAX) / PyTorch DCP でチェックポイント周期を短く（10〜30 分）。非同期チェックポイント で訓練停止時間を最小化。Pathways は障害耐性が高い実装になっているのでフレームワーク選定でも考慮。

🚨 症状

カナリア 10% で問題なかった新モデルを 100% に切り替え。途端に p99 レイテンシ激増、エラー率上昇、SLO 違反。

🔬 原因

新モデルがメモリ多消費で oom-killer に killed されながら自動 restart を繰り返している、または min_replicas が足りずスケールアウト中。10% トラフィックでは隠れていた性能特性が 100% で顕在化。

✅ 対処

• 段階拡大：5% → 25% → 50% → 100% で各段階で p99 / error rate を観測
• min_replicas を予測ピーク負荷に設定（オートスケール頼みにしない）
• 同一 Endpoint の旧モデル version を残し、即座に traffic_split で戻せる 体制
• shadow deploy で 本番影響ゼロ でレイテンシ予測

📝 試験ポイント

「新モデルを安全に展開する」シナリオ。カナリア + traffic_split + 旧 version 保持 がセットで正解。

🚨 症状

Dedicated Public Endpoint に gRPC でリクエストを投げたら 404 Not Found。HTTP では動く。

🔬 原因

公式：「gRPC requests requiring the `x-vertex-ai-endpoint-id` header for proper endpoint identification」。HTTP は URL path で解決、gRPC はヘッダで解決。

✅ 対処

gRPC client で x-vertex-ai-endpoint-id: ENDPOINT_ID を metadata に追加。各種 gRPC client SDK で interceptor 化推奨。

🚨 症状

PyTorch モデルを TorchServe コンテナでデプロイ、{"instances": [{"feature1": 0.1, "feature2": 0.2}]} で送ったら全件 400。

🔬 原因

公式：「TorchServe's default handlers expect each instance to be wrapped in a `data` field」。フォーマットが {"instances": [{"data": <value>}]} 必須。

✅ 対処

クライアント側で data ラッパーを追加。または custom handler を書いて任意フォーマットを受け付ける。

📝 試験ポイント

TF と PyTorch でリクエスト形式が違う。TF は _bytes 終わりの alias、PyTorch は data ラッパー。

🚨 症状

1000 インスタンスを 1 リクエストで送信、1 件のフォーマットエラーで全体が失敗してレスポンスが {"error": "..."} のみ。

🔬 原因

公式：「If inference fails for any instance, the response body contains no inferences. Instead, it contains a single error entry」。部分成功はない仕様。

✅ 対処

• per-instance validation をクライアント側で必須実装
• 大きなバッチを 小さく分割（1 失敗の影響範囲を限定）
• または Batch Prediction Job（こちらは行単位エラーレポートあり）

🚨 症状

2024 年に Optimized Online Serving で構築した特徴量ストアが、ある日から API エラーを返し始める。新機能も追加されない。

🔬 原因

公式サンセット：「Beginning on May 17, 2026, no new features will be added and only critical patches will be provided. On February 17, 2027, the capability will be fully sunset.」

✅ 対処

• 新規プロジェクトは Bigtable Online Serving 一択
• Embeddings は Vector Search へ分離（Bigtable serving は embeddings 非対応）
• 既存 Optimized 利用プロジェクトは 2026/5 までに移行完了 を計画

📝 試験ポイント

サンセット日付（2026/5/17 と 2027/2/17）と移行先（Bigtable + Vector Search）を覚える。

🚨 症状

BQ で feature テーブルの値を更新したが、online lookup では 古い値のまま。30 分待っても変わらない。

🔬 原因

新 Feature Store は pull 型。BQ が更新されても FeatureViewSync を起動するまで online store に反映されない。自動同期ではない。

✅ 対処

• Schedule sync を設定（毎時 / 毎日）
• ETL 完了後に明示的に feature_view.sync() を呼ぶ
• Cloud Composer / Workflows で「BQ 更新 → sync → 確認」の DAG

📝 試験ポイント

「Feature Store 値が古い」問題は sync 忘れ が定番原因。

🚨 症状

Feature Group を作成しようとしたら「region mismatch」のエラー。

🔬 原因

公式：「All Vertex AI Feature Store resources must be located in the same region or the same multi-regional location as your BigQuery data source.」

✅ 対処

BQ dataset を Feature Store と同じ region で再作成、または Feature Store を BQ と同じ region で作る。multi-regional の場合は同一 multi-regional 内ならOK。

🚨 症状

日次再訓練の Pipeline で、preprocess ステップが cache hit してスキップ。古い前処理結果を使った訓練が成功扱い → 古いモデルが本番デプロイ。

🔬 原因

KFP v2 のキャッシュは 入力ハッシュベース。preprocess の入力（GCS path、parameter）が変わらないと cache hit する。新データが同じ path に追記されるパターンでは入力ハッシュ不変。

✅ 対処

• 本番再訓練 Pipeline では component の enable_caching=False を明示
• または入力にタイムスタンプ / バージョンを必ず入れる（パス変える）
• 開発時のみ cache 有効、本番は無効が安全

📝 試験ポイント

「最新データを使うはずなのに古い結果」は cache を疑う。

🚨 症状

Pipeline 内に 20 並列の HPT タスクを書いたら、ある時刻にすべて起動 → GPU quota 超過で大半が失敗、課金は走る。

🔬 原因

公式：「By default, pipeline tasks run in parallel.」依存性のないタスクは自動で同時起動。リソース予算超過に注意。

✅ 対処

• task1.after(task2) で明示的にシリアル化
• または dsl.ParallelFor の parallelism 引数で並列度制限
• 事前に GPU/TPU quota を引き上げ申請
• Spot VM + Dynamic Workload Scheduler で確保確実化

🚨 症状

検証で Pipeline Schedule を「毎時実行」に設定 → 月末になると数十万円の請求。

🔬 原因

Schedule リソースは「作成 → そのまま」。明示的に pause / delete しない限り永続。失念しがち。

✅ 対処

• Schedule に 有効期限（end_time）を必ず設定
• Cloud Billing Budget Alert で閾値超過時に通知
• 非本番 schedule は「検証完了 → pause」を CI に組み込む
• BigQuery Billing export で run 単位コスト分析

🚨 症状

本番 Endpoint で v2 を採用、ある日 alert が来なくなった。Support に問い合わせるも SLA なし。

🔬 原因

公式：「If you need production-level support and want to monitor a model that's deployed on a Vertex AI endpoint, use Model Monitoring v1.」v2 は依然 Preview。

✅ 対処

• 本番 Endpoint 監視は v1（GA）
• v2 は Batch / 外部モデル / Feature Attribution Drift を使いたいケース
• 並行運用：「maintain both versions concurrently until you have fully migrated」

📝 試験ポイント

v2 が「新しいから常に良い」ではない。Preview と GA の使い分け。

🚨 症状

本番 1 日目から毎時 drift alert。実際にはモデルは正常稼働。

🔬 原因

ベースラインに 訓練データではなく開発用の小さなサンプル を使った、または 分布が大きく異なる旧バージョンの本番ログ を使った。 JS Divergence の閾値が デフォルトのまま（経験的にデフォルトは保守的）で false positive 続出。

✅ 対処

• ベースラインは 訓練に実際に使ったデータ、または 本番安定期の数日分
• 閾値は 過去ベースライン上で再現性ある値 に調整（PSI で 0.1〜0.3 程度）
• 2 週間「Inspect Only」で運用してから alert を有効化

📝 試験ポイント

Monitoring 導入は「baseline 設定 + 閾値チューニング + warm-up 期間」が必須プロセス。

🚨 症状 / 🔬 原因

Data Drift は出ないがビジネス KPI が劣化。Concept Drift（P(Y|X) の変化）を検知したいが、真のラベルが日次しか取れない ため即時検知できず。

✅ 対処

• Proxy メトリクス を併用（CTR、信頼度の分布、人手レビュー結果）
• ラベル取得を高速化（feedback loop の自動化）
• Feature Attribution Drift で「重要度の入れ替わり」を観測（ラベル不要）

🚨 症状

レビュー全件感情分析を ML.GENERATE_TEXT で実行、無計画に Gemini Pro を指定して 1 千万行投入 → トークン課金が想定の 100 倍。

🔬 原因

BQML から呼ぶ Gemini も 通常の API 課金と同じ。1 行あたりトークン数 × 1 千万行で爆発。Pro vs Flash で 10 倍差。

✅ 対処

• Flash を使う（精度十分なら）
• Batch API を利用（約 50% 割引、BQML から直接は不可なので Dataflow 経由）
• 小サンプルでコスト試算 → スケール
• LIMIT 付きで段階実行、cost dry run で見積もり

🚨 症状 / 🔬 原因

BQML model を export → 別環境（GKE）にデプロイしたら精度がずれる。原因は BQ 側の暗黙的な前処理（auto encoding / null 処理） が別環境で再現されていない。

✅ 対処

Export 時に TRANSFORM 句の内容も含めて export、推論側でも同じ前処理を実行。または BQML から直接 ML.PREDICT で推論し、結果を別環境に転送。

🚨 症状

Explicit Cache で大量ドキュメントを 24 時間 cache、コスト削減を実現していた。元 GCS ファイルを置き換えたら、cache が無効化された がエラーは出ず、知らない間に毎リクエストが full price に。

🔬 原因

公式：「When caching objects that are stored in a Cloud Storage bucket, don't make changes to objects until the cached contents are expired or deleted ... can cause the associated cached contents to be unusable.」エラー出ず silent。

✅ 対処

• GCS のソースファイルは 不変運用（バージョン付きパス）
• 更新時は新パスを使い、新しい cache を作る
• cachedContentTokenCount をモニタリング → 0 が続いたら alert

🚨 症状 / 🔬 原因

機密データを cache に入れたが、ソース GCS バケットを境界に入れ忘れて、結果的に 外部 project から GCS を読める状態。 公式：「include your bucket in your service perimeter as well to protect your cache content.」

✅ 対処

Cache 本体（Vertex AI service）+ GCS バケット + Customer-managed KMS の全てを VPC SC perimeter に含める。アクセスレベルで明示的に許可ユーザーを定義。

🚨 症状 / 🔬 原因

マイクロサービスの API を全部 Gemini に渡そうとして 600 個の FunctionDeclaration を 1 リクエストで送信 → 上限超過エラー。 公式：「up to 512 FunctionDeclarations」。

✅ 対処

用途別にツールセットを分割（カテゴリで絞り込み）、または 2 段階関数呼び出し（1 段目で「どのカテゴリの関数が必要か」、2 段目で実際の関数）。

🚨 症状 / 🔬 原因

Function Calling + Thinking モデルで multi-turn 構成。各ターンで response から functionCall だけ抽出して保存 → thought_signature を捨ててしまい 推論コンテキストが切れて精度低下。 公式：「Return the entire response with all parts back to the model in subsequent turns.」

✅ 対処

レスポンス全体を保存し、次ターンの conversation history に「全 parts そのまま」を含める。SDK の sample コードを忠実に踏襲。

🚨 症状

HuggingFace から面白いモデルを Model Garden 経由でデプロイ。実は 悪意あるコード（pickle injection など） を含み、推論時に GCP 認証情報を外部に送信していた。

🔬 原因

公式：「Models deemed suspicious or those that have the ability to potentially execute remote code are indicated in Model Garden but can still be deployed.」フラグは表示されるが deploy 自体は止められない。

✅ 対処

• 「suspicious」フラグは 絶対に無視しない
• OSS モデル選定時は organization policy で vetted モデルのみ allow、それ以外は deny
• デプロイ前に第三者セキュリティスキャン
• サービスアカウントの権限を最小化（ML 推論に必要なものだけ）
• VPC SC で外部送信を遮断

📝 試験ポイント

「OSS モデルは Model Garden 経由なら必ず安全」は嘘。HuggingFace スキャン + Google スキャン + フラグ確認 + 組織ポリシー の 4 段で守る。

🚨 症状

Model Armor を「safety filter は High、prompt injection は Low」で Inspect and Block で本番化 → 通常の問い合わせの 30% が false positive で拒否、サポート問い合わせが殺到。

🔬 原因

公式推奨：「start with Inspect only mode to understand potential block rates and efficacy for your specific use case」を無視したパターン。閾値もユースケース調整なし。

✅ 対処

• 最初は必ず Inspect Only で 2〜4 週間運用
• Cloud Logging を分析、false positive と true positive の比率を測定
• 閾値をカテゴリ別に分離：通常は High、prompt injection は Low and above（公式推奨）
• 入出力で別テンプレート（decoupling）
• 段階的に Block 化：軽微カテゴリから順次

🚨 症状 / 🔬 原因

攻撃者が 50 個目以降の URL に悪意ある URL を仕込み、Model Armor を回避してフィッシングリンクを生成出力。 公式制限：「Model Armor scans only the first 40 URLs found in prompts and responses.」

✅ 対処

• アプリ側で URL 数を制限（事前に 40 個まで truncate）
• 出力をアプリ側でも再スキャン（Cloud DLP で URL infoType）
• ホワイトリスト方式（信頼ドメインのみ通す）

🚨 症状

Explainable AI を本番システムに組み込んでいたが、2027 年 3 月 16 日 以降 API が呼べなくなる。

🔬 原因

公式：「deprecated as of March 16, 2026」、「access will no longer be available after March 16, 2027」。

✅ 対処

• 2026/3 以降の新規プロジェクトは Agent Platform Inference の Explainability を使う
• 既存 Explainable AI 利用は 2027/3 までに移行完了

🚨 症状 / 🔬 原因

画像分類モデルに何となく Sampled Shapley を選んで、1 リクエスト 30 秒以上かかる。
公式：「more computationally expensive than necessary」when applied to differentiable models。

✅ 対処

差別可能（DNN）なら Integrated Gradients、画像のリージョン重要度なら XRAI。steps_count を 50〜100 に調整。

🚨 症状 / 🔬 原因

「田中太郎さん（45 歳、東京都新宿区在住）」を「***さん（45 歳、東京都新宿区在住）」のように名前だけマスク → 文脈で個人特定可能。k-anonymity を満たさない。

✅ 対処

• DLP の de-identification template で関連属性も同時マスク
• generalization（年齢 → 年齢層、住所 → 区まで）
• k-anonymity / l-diversity / t-closeness の risk analysis 機能を併用
• 機密度が高いケースは differential privacy

🚨 症状 / 🔬 原因

日本人の名前・住所などは英語ほど DLP の builtin infoType が充実していない。false negative で見落とし。

✅ 対処

• custom infoType（regex / dictionary / hotword）を作成
• 日本語に特化したサードパーティライブラリ・ML モデルと併用
• likelihood を LIKELY 以上（厳しめ）に設定

🚨 症状 / 🔬 原因

「面倒だから Workbench に Owner ロール付与」→ ノートブックから誤って本番 DB をドロップ。

✅ 対処

• 最小権限の原則：Workbench は notebooks.runner + 必要な data viewer のみ
• 本番 DB は 別プロジェクトに分離
• 監査ログ（Cloud Audit Logs）で予期せぬアクセスを検知
• VPC SC で本番リソースを境界保護

🚨 症状 / 🔬 原因

VPC SC を有効化 → Vertex AI Pipelines のサービスアカウントが perimeter 外 になり、突然全 pipeline が PERMISSION_DENIED。

✅ 対処

• VPC SC の Ingress / Egress Rules で Vertex AI service agent を許可
• Dry-run モード で事前検証（実際にブロックする前にログだけ）
• Service Agent の identity を VPC SC perimeter の access level に追加