このダッシュボードとアラートのスイートを使用すると、Google Home エコシステムとの高品質な統合をプロアクティブに維持できます。Google は、すべてのお客様に高品質なエコシステムを提供できるよう、パートナーをサポートすることに尽力しています。
ダッシュボードには 3 つのセクションがあり、それぞれが統合全体の品質に貢献する重要な部分をカバーしています。
Google からパートナーへの指標 - Google からクラウド バックエンドへの呼び出しの健全性を測定します。
システムの状態 - パートナーから Google への指標 - システムから Google への呼び出しの状態を測定します。
デバイスの状態 - 状態の精度 - Google システムに保存されている状態の精度を測定します。これは、ユーザーのクエリを処理するために使用されます。
指標が目標値に達していない場合は、ユーザー エクスペリエンスに影響する可能性のある問題を示すために、赤色でハイライト表示されます。次の情報では、各ターゲットの詳細と、それがユーザーにとって重要である理由について説明します。
次のボタンからダッシュボードに直接移動できない場合は、[概要] ページを選択し、[ダッシュボード] を選択してから、[マイ ダッシュボード] リストから [Google Home Vitals ダッシュボード（Cloud）] を選択してダッシュボードを表示します。
Google からパートナーへの指標
クエリ/実行の成功率 >= 99.5% の指標は、ユーザーのコマンドが正しく実行される頻度を測定します。これにより、アシスタントが「デバイスにアクセスできません」などの応答を返したり、まだ実行されていないコマンドを誤って確認したりすることを回避できます。
同期成功率 >= 99.5% 指標は、同期リクエストが正しく処理される頻度を測定します。これにより、Google Home に表示されるデバイスが、クラウド インフラストラクチャに接続されているデバイスと同期されていることを確認できます。
「成功」の定義
Google Home プラットフォームが、目的のアクションが実行されたか、リクエストされた状態が取得されたことを示す有効なレスポンスを受信すると、トランザクションは成功としてマークされます。
非ブロッキング例外を含むレスポンス（lowBattery 例外を伴う SUCCESS ステータスなど）は、成功したトランザクションとしてカウントされます。コマンドがデバイスに到達し、警告にもかかわらずインテントが満たされました。
「失敗」の定義はどれですか？
一般的なプラットフォーム エラーコードに記載されているエラーのうち、パートナーが対応可能とマークされているものは、QUERY、EXECUTE、SYNC の成功率を計算する際に「失敗」と見なされます。また、エラーと例外で見つかったエラーも「失敗」ですが、次の例外があります。
| 失敗の例外 | ||
|---|---|---|
| aboveMaximumLightEffectsDuration | armLevelNeeded | inOffMode |
| alreadyArmed | bagFull | lockedToRange |
| alreadyAtMax | belowMinimumLightEffectsDuration | lowBattery |
| alreadyAtMin | binFull | maxSpeedReached |
| alreadyClosed | cancelArmingRestricted | minSpeedReached |
| alreadyDisarmed | deadBattery | notSupported |
| alreadyDocked | degreesOutOfRange | オフライン |
| alreadyInState | deviceJammingDetected | percentOutOfRange |
| alreadyLocked | deviceNotMounted | rangeTooClose |
| alreadyOff | deviceNotReady | relinkRequired |
| alreadyOn | deviceOffline | remoteSetDisabled |
| alreadyOpen | deviceTurnedOff | safetyShutOff |
| alreadyPaused | discreteOnlyOpenClose | targetAlreadyReached |
| alreadyStarted | functionNotSupported | tooManyFailedAttempts |
| alreadyStopped | inAutoMode | valueOutOfRange |
| alreadyUnlocked | inEcoMode |
実行レスポンスの状態の同等性
EXECUTE レスポンスで SUCCESS ステータスを返す場合、レスポンス ペイロードの states オブジェクトには、実行しているトレイトで定義されているすべてのアクティブな状態フィールドと更新された状態フィールドが含まれている必要があります。必須の状態フィールドを省略したり、複雑なトレイトに対して空の states オブジェクトを返したりすると、Google Home プラットフォームは実行結果を解析できず、AGENT_ISSUE または INVALID_RESPONSE の失敗として登録し、クエリと実行の成功率が低下します。
クエリ/実行レイテンシ（p90）<= 1,000 ミリ秒の指標は、リクエストされたアクションの待機時間を測定し、ユーザーが長時間待たされることがないようにします。たとえば、照明が消えるまで数秒待つことがないようにします。
レイテンシの指標
レイテンシは、エンドユーザーが統合の応答性をどのように感じるかを示す重要な指標です。ダッシュボードは、90 パーセンタイル（P90）レイテンシを追跡します。これは、「最も遅い」ユーザーのエクスペリエンスを表します（たとえば、P90 が 800 ミリ秒の場合、リクエストの 90% が 800 ミリ秒以下で確認されます）。
Google では、技術的な精度を確保するため、ステータス チェックとデバイス コマンドでレイテンシの測定方法を変えています。
1. クエリのレイテンシ（質問）
これは、Google がデバイスの現在の状態をリクエストしたときの Cloud-to-cloud のラウンドトリップ時間を測定します。
- 開始: Google がフルフィルメント URL に
action.devices.QUERYリクエストを送信します。 - 測定ウィンドウ: クラウドが HTTP レスポンス全体を受信、処理、送信して Google に返すまでに要した時間。
- 終了: Google がサービスから最終レスポンス ペイロードを受信して確認します。
2. EXECUTE レイテンシ（アクション）
これは、Google がデバイスに制御リクエストを送信したときのコマンド確認時間を測定します。
- 開始: Google がフルフィルメント URL に
action.devices.EXECUTEリクエストを送信します。 - 測定ウィンドウ: クラウドがコマンドを受信して確認応答を返すまでにかかった時間。
- 終了: Google が
SUCCESS、PENDING、OFFLINEのステータス レスポンスを受信します。 - 技術的な範囲: この指標は、Google のクラウドとお客様のクラウド間の「応答確認」時間を測定します。物理ハードウェア（電球など）が物理的な状態変化を完了するまでにかかる時間は測定されません。これには、クラウド間のパス外のローカル メッシュ ネットワークのレイテンシが含まれることが多いためです。
EXECUTE/QUERY レイテンシのタイムラインの内訳
EXECUTE または QUERY のレイテンシのタイムスタンプを分析する場合、合計ラウンドトリップ時間は次の順次フローに分割できます。
この内訳は Google 側とパートナー側のタイムスタンプを比較するため、パートナー サーバーは NTP（ネットワーク タイム プロトコル）と同期する必要があります。わずかなクロック ドリフト（50 ～ 100 ミリ秒）でも、計算された配送日数（t2 -
t1 と t4 - t3）が歪み、転送レイテンシが負になるなど、論理的に不可能な指標につながる可能性があります。
[t1] リクエスト送信済み（Google アウトバウンド）: Google がインテント リクエストを開始します。t1 は直接公開されないため、最終的なインバウンド タイムスタンプから合計レイテンシを差し引いて概算されます。
ネットワーク転送（t1～t2）: フルフィルメント エンドポイントに到達するまでの推定ネットワーク転送時間とキュー時間。
[t2] リクエスト受信（パートナー Ingress）: リクエストが環境の API Gateway または Ingress サーバーに到着した正確なタイムスタンプ。
パートナー処理（t2～t3）: クラウド環境内での内部実行、ルーティング、デバイス処理のレイテンシ。
[t3] レスポンス送信（パートナーの下り（外向き））: サービスがフルフィルメント レスポンスを Google に返送したときのタイムスタンプ。
戻りトランジット（t3～t4）: 戻りネットワーク ルーティングと Google への接続完了時間。
[t4] リクエストの完了（Google インバウンド）: Google が最終レスポンスを受信して処理します。このタイムスタンプは、Google Cloud ログに receiveTimestamp として明示的に記録されます。
これらの指標がどのように関連しているかを示すために、合計レイテンシ（latencyMsec）が 1, 700 ミリ秒で、Google Cloud receiveTimestamp（t4）が 2026-05-25T15:25:00.550Z のサンプル EXECUTE リクエストについて考えてみましょう。
| ステージ / チェックポイント | タイムスタンプ / 期間 | ソースと計算方法 |
|---|---|---|
[t1] Google アウトバウンド |
15:24:58.850Z |
計算値: t4（.550Z）- 1700ms |
| ネットワーク トランジット | 150 ミリ秒 | 派生: t2 - t1 |
[t2] パートナーの Ingress |
15:24:59.000Z |
確認済み: パートナー ゲートウェイのログに記録されている |
| パートナーの処理 | 1,300 ミリ秒 | 派生: t3 - t2（内部実行時間） |
[t3] パートナー下り（外向き） |
15:25:00.300Z |
監視対象: パートナーの下り（外向き）ログに記録 |
| 返品の配送 | 250 ミリ秒 | 派生: t4 - t3 |
[t4] Google Inbound |
15:25:00.550Z |
観測: Google Cloud ログに receiveTimestamp |
レイテンシを短縮するためのオプション
ジオルーティングに関するアーキテクチャの推奨事項
エニーキャスト IP の実装が不可能な場合は、ユーザーが最も近いリージョン データセンターからサービスを受けられるように、費用対効果の高い次の代替手段をおすすめします。
グローバル ロード バランシング（GLB）
静的ルーティングの代わりに、グローバル アプリケーション ロードバランサ（ほとんどの主要なクラウド プロバイダで利用可能）を使用します。
仕組み: ネットワーク エッジに配置される単一のグローバル エントリ ポイント（URL）を構成します。ロードバランサは、Google のフルフィルメント クラスタからリクエストの地理的な送信元を自動的に検出し、最も近いリージョンの正常なバックエンドにトラフィックをルーティングします。
メリット: 構成の複雑さと費用を大幅に削減しながら、エニーキャストのパフォーマンスを実現できます。
位置情報を認識する DNS（GeoDNS）
仕組み: DNS クエリの地理的位置に基づいて、フルフィルメント URL を異なる IP アドレスに解決するように DNS プロバイダを構成します。
実装: DNS プロバイダが Google の下り（外向き）ポイントに最適化されていることを確認します。Google のリージョン フルフィルメント サービス（米国、EU、アジアなど）がドメインを解決すると、その特定のリージョンのデータセンターの IP アドレスが返されます。
アプリケーション レイヤでの最適化戦略
インフラストラクチャ レベルのルーティングに加えて、アプリケーション レイヤで次の戦略を実装して、リクエスト処理のレイテンシを短縮できます。
「トランポリン」プロキシ方式
プライマリ データセンターを維持する必要がある場合は、リージョンの軽量プロキシ サーバー（トランポリン）を使用して最初のハンドシェイクを処理します。
Google がグローバル URL にアクセスします。
リージョン プロキシ（軽量の Nginx や Lambda 関数など）がリクエストを受信します。
プロキシは、内部の高速バックボーンを介してペイロードをプライマリ データベースに転送します。
メリット: これにより、「TCP handshake」時間が短縮されます。これは、長距離リクエストのレイテンシの最大の要因となることがよくあります。
アクセス トークンのリージョン ヒント
アカウント リンク（OAuth）プロセス中に、システムはユーザーのホーム リージョンを識別できます。
実装: Google に発行された
access_tokenに地域識別子をエンコードします。Google がフルフィルメント リクエストを送信すると、ゲートウェイはトークンをすぐに検査し、データベースを検索することなく、リクエストを正しいリージョン クラスタにルーティングできます。
システム ヘルス - パートナーから Google への指標
成功率 99.5%以上を維持することで、Google Home でのデバイスの状態が正確になり、デバイスの追加と削除、自動化のトリガー、履歴イベントが Google Home app (GHA) の [アクティビティ] タブに表示されるようになります。
成功率は、クラウドが状態の更新をプッシュしたときに Google から返される HTTP レスポンス コードに基づいて計算されます。Google 側のインフラストラクチャの問題でパートナーがペナルティを受けないようにするため、この指標では Google の内部エラーは失敗数から除外されます。計算に含まれる API 呼び出しについては、HomeGraph API リファレンスをご覧ください。
「成功」の定義
2xx（成功）: 状態の更新が Home Graph によって正常に受信され、処理されました。
「失敗」の定義はどれですか？
4xx（パートナー エラー）は、失敗を表し、クラウドから送信されたリクエストに問題があることを示します。一般的なコードは次のとおりです。
400 無効なリクエスト
原因: 構文が無効なため、サーバーがリクエストを処理できませんでした。一般的な原因としては、不正な形式の JSON や、文字列値に "" でなく null を使っていることなどが挙げられます。
解決策: リクエスト本文が有効な JSON であること（文字列フィールドに不正な構造や null 値がないこと）を確認し、agentUserId が SYNC レスポンスの値と一致していることを確認します。
404 見つかりません
原因: deviceId または agentUserId が HomeGraph に見つかりません（まだ同期されていない、すでにリンクが解除されている、ID が一致しない）。
ソリューション:
agentUserIdが SYNC レスポンスで提供された値と一致していることを確認してください。- Home Graph SYNC API を使用して、404 見つかりません エラーの原因が HomeGraph にデバイスまたはユーザーが存在しないことかどうかを判断します。
- デバイスまたはアカウントの追加、削除、名前変更、更新の後に
requestSyncをトリガーして、状態が最新の状態に保たれるようにしてください。 DISCONNECTインテントを適切に処理して、古いデバイスの報告を停止します。DISCONNECTインテントを受信すると、クラウド サービスは Request Sync と Report State を使用して Google への変更の公開を停止する必要があります。
429 リソース不足
原因: 統合が割り当てられた割り当てを超えています。
解決策: 割り当て管理のダッシュボードの「ステップ 2a: 割り当ての問題をデバッグする」セクションの手順をご覧ください。詳細については、スマートホームの割り当てと上限もご覧ください。
デバイスの状態 - 状態の精度
状態の精度が 99.5%以上であれば、ユーザーがデバイスの状態を確認したり、Home に相談 などの AI 機能を使用したりする際に、正しい結果が表示されるようになります。状態の精度が低いと、自動化がトリガーされなかったり、GHA の [アクティビティ] タブに履歴エントリが適切なタイミングで表示されなかったりすることがあります。詳細については、Report State をご覧ください。注: 状態の精度の目標は、サポートされているすべてのトレイトで達成する必要があります。
1. 精度コンポーネント
この指標は、報告された状態を既知のインテントの結果と照合して検証できる「サンプル」から導出されます。技術的な精度については、次の 2 つの異なる経路で評価されます。
- クエリベースの精度: ユーザーまたはシステムがデバイスの現在のステータスを積極的に問い合わせたときに検証されます。
- EXECUTE に基づく精度: 制御リクエスト後に報告されるコマンド実行後のデバイスの状態を評価することで検証されます。
2. ダッシュボードの指標（1 時間ごとの計算）
ダッシュボードでは、1 時間の間隔に基づいて精度が計算されます。統計的な信頼性を確保し、低シグナルノイズの統合にペナルティを科さないようにするため、Google は最小トラフィック量のしきい値を適用しています。特定の特性とデバイスの組み合わせで、5 日間のローリング ウィンドウで合計サンプル数が 100 未満の場合、その精度は統計的に有意ではないと見なされ、なし に設定されます。
1 時間に両方の経路で十分なサンプル量がある場合、特定の州の 1 時間あたりのベースライン精度は、2 つの独立した割合の平均として計算されます。
1 時間ごとの状態の精度 =（クエリの精度 % + 実行の精度 %）÷ 2
各経路は次のように定義されます。
- クエリの精度（%） =（1 時間あたりのクエリの正確なサンプル数）/（1 時間あたりのクエリの合計サンプル数）
- 実行精度（%） =（1 時間あたりの実行精度サンプル数）÷（1 時間あたりの実行合計サンプル数）
特性精度スコア（特性ごとに計算） = SUM（クエリの正確なサンプル + 実行の正確なサンプル）/ SUM（クエリの合計サンプル + 実行の合計サンプル）
品質スコアは、エコシステム全体の厳格な最小パフォーマンスを評価するため、サポートされている対象のすべてのトレイトが、個別に 99.5% 以上の状態精度の目標を満たす必要があります（これはトレイト全体の平均ではありません）。
このビューにより、精度が非常に高い大量のデバイスが、少量のデバイスの精度に関する問題を隠蔽することを防ぐことができます。あまり使用されていない特性によってスコアが低下することを懸念しているパートナーは、あまり使用されていない特性が最小トラフィック量チェックによって自動的に保護され、必要なサンプルしきい値を満たさない限り、最低タイプと特性スコアに反映されないことを保証できます。
3. デバイスの状態とステータスの精度を向上
不一致は、Home Graph に保存されている状態がリアルタイムの QUERY の結果と一致しない場合に発生します。
「フィールドがありません」というエラー
DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD の例
reportStateLog: { accuracy: "INACCURATE" agentId: "abc" detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD" deviceId: "curtain" deviceType: "action.devices.types.CURTAIN" isMissingField: true isOffline: false queriedTime: "2026-04-13T12:20:26Z" queryReportStateDifferences: { queryState: "open_close { open_percent: 0.0 missing open_direction }" reportState: "open_close { open_state { open_percent: 100.0 open_direction: "LEFT" } }" } reportedTime: "2022-05-13T07:14:35Z" requestId: "123" result: "INACCURATE" snapshotTime: "2026-04-13T12:20:26Z" stateName: "open_state" traitName: "TRAIT_OPEN_CLOSE" }
DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD の例
reportStateLog: { accuracy: "INACCURATE" agentId: "abc" detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD" deviceId: "sensor" deviceType: "action.devices.types.SENSOR" isMissingField: true isOffline: false queriedTime: "2026-04-28T10:40:33Z" queryReportStateDifferences: { queryState: "temperature_setting { thermostat_mode: "off" thermostat_temperature_ambient: 20.0 active_thermostat_mode: "none" }" reportState: "temperature_setting { thermostat_mode: "off" active_thermostat_mode: "none" }" } reportedTime: "2024-09-20T15:00:00Z" requestId: "123" result: "INACCURATE" snapshotTime: "2026-04-28T10:40:33Z" stateName: "thermostat_temperature_ambient" traitName: "TRAIT_TEMPERATURE_SETTING" }
原因: DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD エラーまたは DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD エラーの場合、同じデバイスの QUERY レスポンスと Report State リクエストの間でペイロード フィールドのセットが異なります。
解決策: 両方のパスでデータ構造が同じであることを確認します。SYNC にトレイトが含まれている場合、対応するフィールドがプロアクティブ レポートとリアクティブ クエリの両方に存在し、一貫している必要があります。
「不正確」エラー
DETAILED_ACCURACY_RESULT_INACCURATE の例
reportStateLog: { accuracy: "INACCURATE" agentId: "abc" detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_INACCURATE" deviceId: "outlet" deviceType: "action.devices.types.OUTLET" isMissingField: false isOffline: false queriedTime: "2026-04-12T16:02:58Z" queryReportStateDifferences: { queryState: "on_off { on: false }" reportState: "on_off { on: true }" } reportedTime: "2025-03-10T01:56:44Z" requestId: "abc" result: "INACCURATE" snapshotTime: "2026-04-12T16:02:58Z" stateName: "on" traitName: "TRAIT_ON_OFF" }
原因: DETAILED_ACCURACY_RESULT_INACCURATE エラーの場合、QUERY レスポンスで返された値と最後の Report State 値の間に不一致があります。
解決策: デバイスのステータスが変更されるたびに Report State がトリガーされるようにします。また、Report State と QUERY の両方が常にまったく同じ最新の値と、データの整合性を維持するために必要なすべてのフィールドを提供するようにします。
DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE の例
"reportStateLog": { "isMissingField": false, "snapshotTime": "2026-04-13T07:56:21Z", "traitName": "TRAIT_ON_OFF", "detailedAccuracyResult": "DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE", "executionReportStateDifferences": { "expectedPostExecutionDeviceState": { "onOff": { "on": false } }, "preExecutionDeviceState": { "onOff": { "on": true } }, "executionCommand": { "requestId": "test001", "beginTimestamp": "2026-04-13T07:56:20Z", "action": { "trait": "TRAIT_ON_OFF", "actionType": "ONOFF_OFF" }, "status": { "statusType": "SUCCESS_STATUS" }, "endTimestamp": "2026-04-13T07:56:21Z", "executionType": "PARTNER_CLOUD" }, "reportState": {} }, "accuracy": "MISSING_REPORT_STATE", "deviceType": "action.devices.types.LIGHT", "agentId": "abc", "stateName": "on", "result": "MISSING_REPORT_STATE" }
原因: DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE エラーの場合、パートナーはコマンドを正常に実行しましたが、更新されたデバイスの状態を Google に報告しませんでした。
解決策: コマンドの実行後に必ず Report State の更新を送信して、Home Graph が新しいデバイスの状態を受信するようにします。
DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED の例
eportStateLog: { accuracy: "INACCURATE" agentId: "abc" detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED" deviceId: "switch" deviceType: "action.devices.types.SWITCH" isMissingField: false isOffline: true queriedTime: "2026-04-13T13:53:26Z" queryReportStateDifferences: { queryState: "online { online: false } " reportState: "" } reportedTime: "1970-01-01T00:00:00Z" requestId: "test001" result: "INACCURATE" snapshotTime: "2026-04-13T13:53:26Z" stateName: "online" traitName: "TRAIT_ONLINE" }
原因: DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED エラーの場合、QUERY の結果で現在のステータスが提供されているにもかかわらず、このデバイスの Report State が受信されていません（ステータスが空で、報告されたタイムスタンプがエポックになっています）。これは、状態の更新がトリガーされていないか、HomeGraph に到達していないか、デバイスが接続ステータスまたは動作ステータスの遷移を正常に報告していないことを示します。
解決策: すべての状態変化に対して Report State がトリガーされ、正常に送信されるようにします。バックエンド ロジックがステータスの更新を正しく処理し、Google HomeGraph への配信の成功を確認し、デバイスが状態を常に同期してユーザー インターフェースと自動化エンジンを正確に保つことを確認します。