gpc-vitals-monitoring

GPC バイタルモニタリング

使用するタイミング

次のようなタスクでは、このスキルを使用します。

• gpc watch によるリアルタイムのロールアウト監視（複数メトリクス、自動アクション）
• クラッシュ率、ANR 率、その他の Android Vitals メトリクスの監視
• CI/CD 向けのしきい値ベースのアラート設定
• アプリの起動時間、フレームレート、バッテリー、メモリの追跡
• ユーザーレビューの確認と対応
• GPC の出力を使用した監視パイプラインの構築
• 期間ごとのバイタルの比較
• エラーの問題や異常の調査
• Play の一括レポート（インストール数、クラッシュ数、評価、収益、サブスクリプション）の CSV ダウンロード

必要な入力

• パッケージ名（または設定済みのデフォルト値）
• 監視するメトリクスの種類（クラッシュ、ANR、起動、レンダリング、バッテリー、メモリ）
• バージョンコード（任意 — リリースによる絞り込みに使用）
• しきい値（CI アラート用）

手順

0) 統合ヘルススナップショット — まずはこちらから

リリース、バイタル、レビューの全体像を 1 つのコマンドで確認できます。

gpc status

出力：

App: com.example.myapp · My App  (fetched 10:42:01 AM)

RELEASES
  production   v1.4.2   completed    —
  beta         v1.5.0   inProgress  10%

VITALS  (last 7 days)
  crashes     0.80%  ✓    anr         0.20%  ✓
  slow starts 2.10%  ✓    slow render 4.30%  ⚠

REVIEWS  (last 30 days)
  ★ 4.6   142 new   89% positive   ↑ from 4.4

6 件の API 呼び出しを並列実行し、3 秒未満で結果を取得します。1 時間キャッシュされます。

gpc status --days 14          # Wider vitals window
gpc status --cached           # Instant — no API calls (uses last fetch)
gpc status --refresh          # Force live fetch, ignore cache
gpc status --output json      # Full structured output for scripts

いずれかのバイタルのしきい値を超過した場合、終了コード 6 を返します。デプロイのゲートとして使用してください。

1) メトリクス別バイタルダッシュボード

gpc status の表示内容よりも詳しいメトリクス別の詳細を確認するには：

gpc vitals overview

2) クラッシュの監視

# Crash rate and top clusters
gpc vitals crashes

# Group by version code
gpc vitals crashes --dim versionCode

# CI threshold alerting — exit code 6 if crash rate exceeds threshold
gpc vitals crashes --threshold 0.02

終了コード 6 はしきい値を超過したことを示します。デプロイのゲートとして使用してください。

率のしきい値は、Google のレポート方式と同じく小数で指定します。2% は 0.02、1.09% は 0.0109、0.47% は 0.0047 です。率が 1 を超えることはないため、1 以上の値は、しきい値判定が発生しないままになることなく、THRESHOLD_INVALID（終了コード 2）で拒否されます。error-count は件数なので、件数を指定します。

3) ANR の監視

gpc vitals anr
gpc vitals anr --dim versionCode
gpc vitals anr --threshold 0.0047  # Google's bad behavior threshold

4) パフォーマンスメトリクス

# Cold/warm startup times (auto-includes startType as a required dimension)
gpc vitals startup

# Frame rate / rendering
gpc vitals rendering

# Battery usage
gpc vitals battery

# Stuck background wakelocks (despite the name, not a memory-usage metric)
gpc vitals memory

# Excessive wakeup rate
gpc vitals wakeup

# Low memory killer rate (LMK)
gpc vitals lmk

# Memory usage percentiles (v0.9.97+)
gpc vitals memory-rss
gpc vitals memory-bitmap

gpc vitals memory はスタックしたウェイクロックのメトリクスセットです（互換性のため、この名前を維持しています）。gpc vitals wakeup は過剰なウェイクアップ率です。実際のメモリ使用量を確認するには、以下の memory-rss / memory-bitmap を使用してください。いずれも他のバイタルサブコマンドと同じフラグに対応しています：--days <n>、--threshold <value>、--json。

メモリ使用量のパーセンタイル（gpc vitals memory-rss / memory-bitmap、v0.9.97+）

Google Play の 2027 年 2 月の品質要件では、動的メモリをP90で評価します。次の 2 つのコマンドは、Play Developer Reporting のメモリメトリクスセットから P50、P75、P90、P95、P99 を取得します。

• gpc vitals memory-rss -- 匿名 RSS とスワップの使用量
• gpc vitals memory-bitmap -- ビットマップメモリの使用量

gpc vitals memory-rss --app com.example.app --days 30
gpc vitals memory-rss --app com.example.app --dim deviceRamBucket   # hardware dimension
gpc vitals memory-rss --app com.example.app --dim appState          # foreground vs background
gpc vitals memory-bitmap --app com.example.app --dim deviceModel
gpc vitals memory-rss --app com.example.app --threshold <value>     # gates on P90, exit 6 on breach

Reporting API はこれらのデータを日次集計でのみ提供するため、GPC では日次集計を適用します。--threshold は P90（anonRssAndSwapMemoryUsageP90 / bitmapMemoryUsageP90）に対して評価されます。これは Google の要件で使用されるものと同じパーセンタイルです。gpc verify checklist は要件自体を追跡します。Google がしきい値を公開するまでは、事前チェックルールはありません。

Low-Memory-Killer 率（gpc vitals lmk、v0.9.58+、v0.9.59 で修正）

背景：v0.9.58 では、名前を誤ったリソース（lowMemoryKillerRateMetricSet）がリリースされ、404 エラーになりました。v0.9.59 が動作するビルドです。実際の Google リソースは lmkRateMetricSet で、メトリクスは userPerceivedLmkRate、userPerceivedLmkRate7dUserWeighted、userPerceivedLmkRate28dUserWeighted、distinctUsers です。LMK クエリには v0.9.59 以降を使用してください。

gpc vitals lmk --app com.example.app --days 7

他のバイタルサブコマンドと同じフラグに対応しています：--days <n>、--threshold <value>、--json。

注： バイタルのメモリデータの精度は v0.9.41 で向上しました（Bug H：メトリクスフィールド名を stuckBackground から stuckBg に修正）。

エラー発生件数（gpc vitals error-count、v0.9.57+）

gpc vitals error-count は、Play Developer Reporting API から、指定した期間内のエラー問題の発生件数を取得します。率ではなく絶対件数を使った CI ゲートを設定する場合に使用してください。

gpc vitals error-count --app com.example.app --days 7
gpc vitals error-count --app com.example.app --days 7 --threshold 100

件数が --threshold を超えると、終了コード 6 を返します（他のバイタルコマンドと同じ CI の規約です）。

4a) バージョン間の指標比較

すべての主要指標について、2つのバージョンコードを並べて比較します。

gpc vitals compare-versions <v1> <v2>

# Example
gpc vitals compare-versions 141 142

# Wider time window
gpc vitals compare-versions 141 142 --days 14

# JSON output for scripting
gpc vitals compare-versions 141 142 --json

# Markdown table (for GitHub comments, Slack, etc.)
gpc vitals compare-versions 141 142 --format markdown

比較対象：クラッシュ率、ANR率、起動時間、レンダリング、バッテリー、メモリ。各バージョンには重複しない7日間のウィンドウを使用します。リグレッションはターミナル出力で赤色に強調表示されます。

注： gpc vitals compare-versions は重複しない7日間のウィンドウを使用します。APIデータの遅延を考慮し、どちらのウィンドウも今日の2日前までに制限されます。

データ鮮度に基づく範囲調整（v0.9.70+）： Google の vitals データは、通常リアルタイムより3～4日遅れます。GPC は、vitals クエリを実行する前に各指標セットのデータ鮮度エンドポイントを照会し、日付範囲を自動的に調整するようになりました。これにより、要求した日付範囲が Google で利用可能なデータ期間を超えた場合に発生していた 400 INVALID_ARGUMENT エラーを防ぎます。設定は不要です。

4b) リアルタイムのロールアウト監視（gpc watch、v0.9.67+）

gpc watch は、ロールアウト監視を統合したコマンドです。一定間隔でロールアウト状況（ほぼリアルタイム）と vitals データ（2～4日遅延）をポーリングし、しきい値を確認して、しきい値超過時に対応します。

# Basic: monitor crashes + ANR on production, poll every 15 minutes
gpc watch

# Watch a beta rollout with tighter thresholds
gpc watch --track beta --crash-threshold 0.015 --anr-threshold 0.005

# Auto-halt the rollout on any threshold breach
gpc watch --on-breach halt

# Notify + halt + send webhook on breach
gpc watch --on-breach notify,halt,webhook \
  --webhook-url https://hooks.slack.com/services/XXX

# CI mode: 3 rounds, 5-minute interval, NDJSON output
gpc watch --rounds 3 --interval 300 --json

# Monitor all 6 metrics
gpc watch --metrics crashes,anr,lmk,slowStarts,slowRender,errorCount

6つの指標： crashes、anr、lmk、slowStarts、slowRender、errorCount。

しきい値超過時の3つのアクション（--on-breach と組み合わせて指定できます）：

• notify — OS 通知（macOS、Linux、Windows）
• halt — Google Play API を使って進行中のロールアウトを停止
• webhook — しきい値超過イベントを JSON として --webhook-url に POST

しきい値は、CLI フラグ > .gpcrc.json の vitals.thresholds.* > デフォルト値（クラッシュ 2% / 0.02、ANR 1% / 0.01、LMK 3% / 0.03、起動遅延 5% / 0.05、レンダリング遅延 10% / 0.1）の優先順位で決まります。フラグと設定値は小数で指定します。

自動停止： ロールアウトが100%に達した場合、しきい値超過によって停止した場合、--rounds の上限に達した場合、または Ctrl+C を押した場合、監視ループは停止します。

終了コード： 0 = 問題なし、6 = 1つ以上のしきい値を超過。

Webhook ペイロード：

{
  "type": "breach",
  "round": 3,
  "rollout": { "track": "production", "versionCode": "142", "userFraction": 0.1 },
  "vitals": { "crashes": { "value": 0.025, "threshold": 0.02, "breached": true } },
  "breaches": ["crashes"],
  "halted": true
}

毎回 URL を渡さなくて済むよう、Webhook URL を設定ファイルに指定します。

{
  "webhooks": { "watch": "https://hooks.slack.com/services/XXX" }
}

注： gpc vitals watch（単一指標の監視コマンド）も引き続き使用できますが、v0.9.67 以降、ロールアウト監視には gpc watch が推奨コマンドです。

5) エラー追跡と異常検知

# Detected anomalies
gpc vitals anomalies

# Error issues and reports
gpc vitals errors search

v1.0.0-rc.1 での変更： プロジェクトで Play Developer Reporting API が無効になっている場合、またはサービスアカウントがこのアプリの vitals を読み取れない場合、gpc vitals と gpc anomalies list は 終了コード 4 で失敗します。人間向けの出力では引き続き原因を説明し、有効化 URL を stderr に表示します。--json にはコードと Google のメッセージが含まれます。v0.9.47 から v0.9.99 まではメッセージを表示して終了コード 0 で終了していたため、CI の --threshold ゲートが指標を一度も読み取らずに成功する可能性がありました。vitals 以外のコマンドには影響しません。

6) レビューのセンチメント分析

外部 API を必要としない、ローカル NLP ベースのレビューセンチメント分析です。

gpc reviews analyze

# Filter by date range
gpc reviews analyze --since 2026-01-01
gpc reviews analyze --days 30

# Filter by language
gpc reviews analyze --lang en

# JSON output
gpc reviews analyze --json

# Markdown report (for GitHub, Confluence, etc.)
gpc reviews analyze --format markdown

出力には以下が含まれます。

• 時間経過に伴うセンチメントの傾向（肯定的／中立／否定的）
• トピックのクラスタリング（ユーザーが最もよく話題にする内容）
• キーワード頻度の表
• バージョン別の評価分布

すべての処理はローカルで行われ、サードパーティの NLP サービスは呼び出されません。

7) レビューの監視

# Recent reviews
gpc reviews list

# Filter by rating
gpc reviews list --stars 1-2

# Filter by language
gpc reviews list --lang en

# Filter by time
gpc reviews list --since 7d

# Full text of truncated reviews (v0.9.83+)
gpc reviews list --full-text

# Single review details
gpc reviews get <review-id>

# Reply to a review (max 350 chars — validated before sending)
gpc reviews reply <review-id> --text "Thank you for your feedback"

# Auto-paginate all reviews (API returns max 10 per page by default)
gpc reviews list --all

# Start from a specific index (for manual pagination)
gpc reviews list --start-index 20

# Export reviews
gpc reviews export --format csv --output-file reviews.csv

v0.9.47 で追加： --all はすべてのレビューをページネーションで取得します。返信テキストは送信前に Google Play の350文字制限に照らして検証され、制限を超えると直ちに終了コード 2 で終了します。注：Reviews API が返すのは、過去7日間の本番環境のレビューのみです。

v0.9.83 で追加： reviews list は、各レビューに hasReply、lang、明示的な [truncated] マーカーを追加します。また、切り詰められていない全文を取得する --full-text フラグも追加します。reviews list --json は、統一された { reviews, nextPageToken, meta.count } エンベロープを使用します（配列のみを読み取るスクリプトとの互換性がありません）。

参照：

• references/review-management.md

8) しきい値ベースの CI ゲート

--threshold を使用して、バイタルの品質に基づいてロールアウトをゲートします。

# Gate on crash rate (exits with code 6 if breached)
gpc vitals crashes --threshold 0.02

# Gate on ANR rate
gpc vitals anr --threshold 0.0047

# Combine in a script
gpc vitals crashes --threshold 0.02 && \
gpc vitals anr --threshold 0.0047 && \
echo "Vitals OK — safe to promote"

ゲートは、データがない状態では決して通過しません（v1.0.0-rc.1+）。 --threshold を指定した実行でメトリクス値が返されない場合、終了コード 0 ではなく、THRESHOLD_NO_DATA を伴って終了コード 6 で終了します。よくある原因は、--app の指定ミス、Play のデータ反映に 2〜4 日かかること、アプリのトラフィックが少なすぎることです。--app を確認するか、--days の範囲を広げるか、その実行では --threshold を外してください。同じコマンドで 403 が発生した場合は、終了コード 4 で終了します。

ゲートによるバイタルの判定方法（v1.0.0-rc.2+）。 レートのしきい値は割合です（0.02 = 2%）。1 以上を指定すると THRESHOLD_INVALID（終了コード 2）で拒否されます。ゲートは直近 1 日の最悪値を比較します。起動は起動タイプごと、エラーカウントはレポートタイプごとに行があり、--dim を指定すると、各ディメンション値がそれぞれ独立した行になります。そのため、--dim deviceModel --threshold 0.02 は、いずれか 1 つのデバイスモデルが 2% を超えると失敗します。gpc watch は最新日の値を判定し、しきい値を設定した監視対象のメトリクスを読み取れなかった場合は終了コード 4 で終了します。releases rollout increase --vitals-gate と gpc train advance は、データがない場合に処理を進めず、ブロックします。rc.2 より前は、gpc watch が Google のレスポンスを誤って読み取っていたため、値を取得できませんでした。--on-breach halt に依存する前にアップグレードしてください。

CI では、終了コード 6 を使用して昇格をブロックします。

- name: Check vitals before promotion
  run: |
    gpc vitals crashes --threshold 0.02
    gpc vitals anr --threshold 0.0047
- name: Promote to production
  if: success()
  run: gpc releases promote --from beta --to production --rollout 10

参照先：

• references/ci-gating.md

8a) ロールアウト増加時のバイタルゲート（--vitals-gate、v0.9.74+）

ロールアウトコマンドの --vitals-gate フラグは、ロールアウト率を上げる前にクラッシュと ANR のしきい値を確認します。いずれかのしきい値を超えている場合、増加処理は完全にスキップされ、GPC は終了コード 6 で終了します。メトリクスに問題がある間、より高いロールアウト率でユーザーに配信されることはありません。

以前の動作（v0.9.74 より前）： GPC は先にロールアウト率を上げ、その後バイタルを確認し、しきい値を超えていれば停止していました。このため、しきい値超過の期間中、ユーザーには新しい、より高いロールアウト率が適用されていました。

新しい動作（v0.9.74+）： GPC は先にバイタルを確認します。しきい値を超えている場合、ロールアウト率の増加は行われません。

# Increase rollout only if the crash rate is within the configured threshold
gpc releases rollout increase --track production --to 50 --vitals-gate

# Use in a staged rollout script
gpc releases rollout increase --track production --to 10 --vitals-gate
gpc releases rollout increase --track production --to 25 --vitals-gate
gpc releases rollout increase --track production --to 50 --vitals-gate
gpc releases rollout increase --track production --to 100 --vitals-gate

--vitals-gate に独自のしきい値フラグはありません。.gpcrc.json の vitals.thresholds.crashRate を割合として読み取ります（0.02 は 2%）。このキーがない場合、警告を表示してゲートをスキップします。

終了コード 6 は、バイタルのしきい値を超えており、ロールアウト率の増加が適用されなかったことを示します。終了コード 0 は、バイタルがしきい値を満たし、ロールアウト率が増加したことを示します。

CI では、最初に失敗したゲートでパイプラインを停止するために if: success() ガードを使用します。

- name: Ramp to 25%
  run: gpc releases rollout increase --track production --to 25 --vitals-gate

- name: Ramp to 50%
  if: success()
  run: gpc releases rollout increase --track production --to 50 --vitals-gate

- name: Full rollout
  if: success()
  run: gpc releases rollout increase --track production --to 100 --vitals-gate

ゲートのしきい値は、.gpcrc.json の vitals.thresholds.crashRate に割合として設定します（0.02 は 2%）。

参照先：

• references/ci-gating.md

8b) バイタルゲートのクラッシュ率修正（v0.9.82）

以前のバージョンでは、rollout increase のバイタルゲートによるクラッシュ率チェック（--vitals-gate フラグ）が、チェックを黙ってスキップしていました。原因は、GPC が Reporting API から返される MetricSetResponse の形式に存在しない .data フィールドにアクセスしていたことです。その結果、クラッシュ率にかかわらず、ゲートは常に通過していました。

v0.9.82 での修正では、rows[last].metrics[firstMetric].decimalValue.value を読み取ります。これは、gpc train が同じ API からクラッシュ率を読み取る方法と一致します。--vitals-gate のクラッシュ率チェックを正しく動作させるには、v0.9.82+ へのアップグレードが必要です。

8c) 設定内の VitalsThresholds（v0.9.82）

@gpc-cli/config の GpcConfig と ResolvedConfig で、VitalsThresholds が正式に型付けされたフィールドになりました。.gpcrc.json でプロジェクト全体のしきい値を設定できます。

{
  "vitals": {
    "thresholds": {
      "crashRate": 0.02,
      "anrRate": 0.005
    }
  }
}

設定のしきい値はフラグと同様に割合です。0.02 は 2%、0.005 は 0.5% です。これらの値は、--vitals-gate、gpc watch、gpc vitals crashes/anr --threshold のデフォルトとして使用されます。CLI フラグは引き続き設定より優先されます。

9) Reporting API のレート制限

Play Developer Reporting API のレート制限は毎秒 10 クエリです。GPC はこれを自動的に処理します。制限に達すると、リクエストはキューに入れられ、バックオフを挟んで再試行されます。設定は不要です。

10) 監視パイプライン

JSON 出力を監視スタックにパイプします。

# Send crash data to your monitoring tool
gpc vitals crashes --output json | jq '.data' | curl -X POST ...

# Periodic check (cron)
gpc vitals overview --output json >> /var/log/gpc-vitals.jsonl

11) レポート：CSV の一括ダウンロード（v0.9.93 から利用可能）

Play は、Publisher API 経由ではなく、デベロッパーアカウントにリンクされた Google Cloud Storage バケットに、月次の一括レポートを CSV ファイルとして配信します。GPC v0.9.93 以降では、gpc reports が同じサービスアカウントを使用してバケットを直接読み取ります。v0.9.93 より前のこれらのコマンドは、データの保存場所を案内するメッセージを表示するだけでした。

一度だけ必要な権限付与。 Play はサービスアカウントにレポート用バケットへのアクセス権を自動で付与しません。バケットへのアクセス権は、ユーザー自身のログインアカウントにのみ付与されます。Play Console -> Users and permissions -> the service account -> Account permissions で "View app information and download bulk reports (read-only)" を有効にしてから、反映まで数分お待ちください。この権限がないと、すべてのレポートコマンドが REPORT_ACCESS_DENIED（終了コード 4）で失敗します。gpc doctor で確認できます。このコマンドには、権限がない場合に警告を表示する reports-bucket プローブがあります。

バケットの解決。 デフォルトは pubsite_prod_<developerId> です。developerId 設定キーまたは GPC_DEVELOPER_ID から導出されます。アカウントのバケットが異なる場合は、Play Console -> Download reports に表示される Cloud Storage URI をそのままコピーして、次のように上書きします。

設定	設定方法
フラグ（優先）	--bucket pubsite_prod_1234567890
環境変数	GPC_REPORTS_BUCKET=pubsite_prod_1234567890
設定	"reports": { "bucket": "pubsite_prod_1234567890" }
導出されるデフォルト	developerId / GPC_DEVELOPER_ID

# List report files for a type, optionally narrowed to one month
gpc reports list installs --app com.example.myapp --month 2026-02
gpc reports list earnings --month 2026-02
gpc reports list crashes --app com.example.myapp --limit 20 --next-page <token>

# Stats reports (per app), decoded UTF-8 CSV on stdout
gpc reports download stats --app com.example.myapp --month 2026-02 --type installs
gpc reports download stats --app com.example.myapp --month 2026-02 --type crashes \
  --dimension country --output-file crashes-2026-02.csv

# Financial reports (account-level, no --app)
gpc reports download financial --month 2026-02 --type earnings
gpc reports download financial --month 2026-02 --type play_balance \
  --output-file balance-2026-02.csv

reports list <report-type> は単一のレポートタイプ（stats / financial ではありません）を受け取り、他の list コマンドと同じ --json エンベロープ { reports, nextPageToken, meta.count, message? } を返します。Stats タイプは設定済みのアプリに絞り込まれます。Financial タイプはアカウント単位です。

レポートタイプ。Financial：earnings、sales、estimated_sales、play_balance。Stats：installs、crashes、ratings、reviews、store_performance、subscriptions。sales と estimated_sales は同じ Play レポートを指す別名で、同じデータを返します。

ディメンション（--dimension、Stats のみ。デフォルトは overview）：overview、country、language、os_version、device、app_version、carrier、traffic_source。Play はディメンションごとに、月単位で 1 つの CSV を公開します。Reviews レポートにはディメンションがありません。指定したディメンションがその月に存在しない場合、エラーメッセージに利用可能なディメンションが表示されます。

エンコードとアーカイブ：Play はこれらのオブジェクトを gzip 圧縮し、UTF-16 でエンコードして保存します。GPC は展開して UTF-8 テキストに再エンコードするため、出力を標準の CSV ツールにそのままパイプできます。Financial レポートは ZIP アーカイブとして配信されます。CSV が 1 つだけのアーカイブは自動的に展開されます。CSV が複数含まれるアーカイブの場合は、--output-file report.zip（生のアーカイブを保存）または --json（すべてのエントリをインライン化）を指定します。

--json を指定すると、ダウンロードコマンドは次の 3 種類のエンベロープのいずれかを出力します。

{ "objectName": "...", "csv": "..." }
{ "objectName": "...", "outputFile": "...", "bytes": 1234 }
{ "objectName": "...", "entries": [{ "name": "...", "csv": "..." }] }

最小権限：devstorage.read_only スコープを要求するのは、レポートコマンドと対応する gpc doctor プローブだけです。また、ストレージ用スコープのトークンは別途キャッシュされるため、他のコマンドのトークンにストレージへのアクセス権は含まれません。付与した権限がまだ反映されていない場合は、gpc auth clear-cache を実行すると、認証情報を削除せずにキャッシュ済みトークンを消去できます。

この処理に固有のエラーコード：REPORT_ACCESS_DENIED（4、権限付与が不足）、REPORT_BUCKET_UNKNOWN / REPORT_BUCKET_INVALID（2）、REPORT_BUCKET_NOT_FOUND（4）、REPORT_OBJECT_NOT_FOUND（4）、REPORT_AUTH_REJECTED（3）。一覧は gpc-troubleshooting を参照してください。

検証

• gpc status で、リリース、バイタル、レビューの3つのセクションがエラーなしで表示されます
• gpc watch --rounds 1 で、エラーなしで1回のポーリングが完了します
• gpc vitals overview でデータが返されます（十分なインストール数が必要です）
• しきい値コマンドは、終了コード 0（OK）または 6（しきい値超過）を返します
• gpc reviews list で最近のレビューが返されます
• JSON 出力が解析可能です：gpc vitals crashes --output json | jq .
• gpc doctor で reports-bucket が合格として表示されます（bulk-reports の権限が付与されています）
• gpc reports list installs --month <last full month> で少なくとも1つのオブジェクトが返されます

失敗時の症状とデバッグ

症状	考えられる原因	修正方法
バイタルデータがない	アプリのインストール数が不十分	バイタルにはかなりのインストール数が必要です。小規模なアプリではデータがない場合があります
THRESHOLD_INVALID（終了コード 2）	率のしきい値がパーセンテージで指定されている（例：2.0）	2% の場合は小数を使います：0.02（v1.0.0-rc.2 以降）
API_METRIC_GAMES_ONLY（終了コード 4）	ゲーム以外のアプリで vitals rendering を実行している	想定どおりです。Google はゲームにのみ低速レンダリングのデータを提供します（v1.0.0-rc.2 以降）
THRESHOLD_NO_DATA（終了コード 6）	--threshold が設定されているものの、指標値が返されなかった	--app の指定が誤っている、データの反映が遅れている、またはトラフィックがありません。--app を確認し、--days の範囲を広げるか、その実行では --threshold を外してください（v1.0.0-rc.1 以降）
Reporting API の有効化リンクとともに終了コード 4 が表示される	Reporting API が無効になっている、またはサービスアカウントにこのアプリの読み取り権限がない	プロジェクトで Play Developer Reporting API を有効にし、サービスアカウントにアクセス権を付与してください。v1.0.0-rc.1 より前は終了コード 0 でした
--threshold が常に合格になる	しきい値が高すぎる、または rc.2 より前のバージョンでパーセンテージとして指定されている	しきい値は小数です（0.02 = 2%）。まず gpc vitals crashes で現在の率を確認してください
Reviews API のレート制限	リクエストが多すぎる	Reviews API の制限は、GET が1時間あたり200件、POST が1日あたり2,000件です。リクエストの間隔を空けてください
レポートが見つからない	月の形式が正しくない	YYYY-MM 形式を使ってください（例：2026-02）
いずれかのレポートコマンドで REPORT_ACCESS_DENIED が表示される	サービスアカウントに bulk-reports の権限がない	Play Console -> ユーザーと権限 -> サービスアカウント -> アカウントの権限 の順に開き、「アプリ情報の表示と一括レポートのダウンロード（読み取り専用）」を有効にします。数分待ってから gpc auth clear-cache を実行し、再試行してください
REPORT_BUCKET_UNKNOWN	developerId がなく、明示的なバケットも指定されていない	developerId / GPC_DEVELOPER_ID を設定するか、--bucket / GPC_REPORTS_BUCKET / reports.bucket を指定してください
REPORT_BUCKET_NOT_FOUND	アカウントのバケット名が pubsite_prod_<developerId> ではない	Play Console -> レポートのダウンロード から Cloud Storage URI を正確にコピーし、--bucket で設定してください
ディメンション付きで REPORT_OBJECT_NOT_FOUND が表示される	その月のレポートに該当のディメンションが公開されていない	エラーに存在するディメンションが一覧表示されます。レビューのレポートにはディメンションがありません
レポートを指定した月のデータが返されない	その月がまだ終了していない	Play では月が終了してからその月のレポートが公開されます。完了済みの直近の月を指定してください
複数 CSV を含む財務アーカイブを出力できない	REPORT_MULTIPLE_ENTRIES	--output-file report.zip でアーカイブを保存するか、--json を使ってすべてのエントリーをインラインで出力してください
クラッシュクラスターが空	リリース直後	クラッシュデータの集計には時間がかかります。2～4日後にもう一度確認してください

関連スキル

• gpc-setup：認証と設定
• gpc-release-flow：アップロードと段階的公開の管理
• gpc-ci-integration：CI でのバイタルチェックの自動化