このダッシュボードとアラートのスイートを使用すると、Google Home エコシステムとの高品質な統合をプロアクティブに維持できます。Google は、すべてのユーザーに高品質のエコシステムを提供できるよう、パートナー様をサポートすることに尽力しています。
ダッシュボードは 3 つのセクションで構成されており、それぞれが統合全体の品質に貢献する重要な部分をカバーしています。
Google からパートナーへの指標 - Google から クラウド バックエンドへの呼び出しの健全性を測定します。
システムの健全性 - パートナーから Google への指標 - システムから Google への呼び出しの健全性を測定します。
デバイスの健全性 - 状態の精度 - ユーザー クエリの処理に使用される Google システムに保存されている状態の精度を測定します。
指標が目標値を満たしていない場合は、ユーザー エクスペリエンスに影響する可能性がある問題を示すために赤でハイライト表示されます。次の情報では、各目標の詳細と、それがユーザーにとって重要な理由について説明します。
次のボタンをクリックしてもダッシュボードに直接移動しない場合は、[概要] ページを選択し、[ダッシュボード] を選択します。次に、[マイ ダッシュボード] リストから [Google Home Vitals ダッシュボード（Cloud）] を選択して、ダッシュボードを表示します。
Google からパートナーへの指標
[クエリ/実行の成功率 >= 99.5%] 指標は、ユーザーのコマンドが正しく処理される頻度を測定します。これにより、「デバイスに接続できません」などのアシスタントのレスポンスや、処理されていないコマンドを誤って確認するのを防ぐことができます。
「成功」の定義とは
Google Home プラットフォームが、意図したアクションが処理されたこと、またはリクエストされた状態が取得されたことを示す有効なレスポンスを受信した場合、トランザクションは成功とマークされます。
実行をブロックしない例外（たとえば、lowBattery 例外を伴う SUCCESS ステータス）を含むレスポンスは、成功したトランザクションとしてカウントされます。
警告が表示されたにもかかわらず、コマンドがデバイスに到達し、インテントが満たされました。
「失敗」の定義とは
一般的なプラットフォーム エラーコードに記載されているエラーで、[パートナーが対応可能] とマークされているものは、QUERY と EXECUTE の成功率を計算する際に「失敗」と見なされます。また、エラーと例外に記載されているエラーも「失敗」と見なされますが、次の例外があります。
| 失敗の例外 | ||
|---|---|---|
| aboveMaximumLightEffectsDuration | armLevelNeeded | inOffMode |
| alreadyArmed | bagFull | lockedToRange |
| alreadyAtMax | belowMinimumLightEffectsDuration | lowBattery |
| alreadyAtMin | binFull | maxSpeedReached |
| alreadyClosed | cancelArmingRestricted | minSpeedReached |
| alreadyDisarmed | deadBattery | notSupported |
| alreadyDocked | degreesOutOfRange | offline |
| 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 |
[クエリ/実行のレイテンシ（p90）<= 1,000 ミリ秒] 指標は、リクエストされたアクションの待ち時間を測定します。これにより、ユーザーが長時間待つ必要がないようにします（たとえば、ライトが消えるまで数秒待つなど）。
レイテンシの指標
レイテンシは、統合の応答性がエンドユーザーにどのように感じられるかを示す重要な指標です。ダッシュボードには、90 パーセンタイル（P90）のレイテンシが表示されます。これは、「最も遅い」ユーザーのエクスペリエンスを表します（たとえば、P90 が 800 ミリ秒の場合、リクエストの 90% が 800 ミリ秒以内に確認されます）。
Google は、技術的な正確性を確保するため、ステータス チェックとデバイス コマンドでレイテンシを異なる方法で測定します。
1. QUERY レイテンシ（問い合わせ）
これは、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 のクラウドとパートナー様のクラウド間の「レスポンス確認」時間を測定します。物理ハードウェア（電球など）が物理的な状態の変化を完了するまでの時間は測定されません。これは、クラウド間パスの外部にあるローカル メッシュ ネットワークのレイテンシが関係することが多いためです。
レイテンシを短縮するためのオプション
ジオルーティングに関するアーキテクチャの推奨事項
Anycast IP の実装が難しい場合は、ユーザーが最も近いリージョンのデータセンターで処理されるように、次の費用対効果の高い代替手段をおすすめします。
グローバル ロード バランシング（GLB）
静的ルーティングではなく、グローバル アプリケーション ロードバランサ （ほとんどの主要なクラウド プロバイダから入手可能）を使用します。
仕組み: ネットワーク エッジに配置される単一のグローバル エントリ ポイント（URL）を構成します。ロードバランサは、Google のフルフィルメント クラスタからのリクエストの地理的な送信元を自動的に検出し、最も近いリージョンの正常なバックエンドにトラフィックをルーティングします。
メリット: Anycast のパフォーマンスを、構成の複雑さとコストを大幅に削減して実現できます。
位置情報認識型 DNS（GeoDNS）
仕組み: DNS クエリの地理的位置に基づいて、フルフィルメント URL を異なる IP アドレスに解決するように DNS プロバイダを構成します。
実装: DNS プロバイダが Google の出口ポイント向けに最適化されていることを確認します。Google のリージョン フルフィルメント サービス（米国、EU、アジアなど）がドメインを解決すると、その特定のリージョンのデータセンターの IP アドレスが返されます。
アプリケーション レイヤでの最適化戦略
インフラストラクチャ レベルのルーティングに加えて、アプリケーション レイヤで次の戦略を実装して、リクエスト処理のレイテンシを短縮できます。
「トランポリン」プロキシ方式
プライマリ データセンターを維持する必要がある場合は、リージョンの軽量プロキシ サーバー（トランポリン）を使用して初期ハンドシェイクを処理します。
Google がグローバル URL にアクセスします。
リージョン プロキシ（軽量の Nginx や Lambda 関数など）がリクエストを受信します。
プロキシは、内部の高速バックボーンを介してペイロードをプライマリ データベースに転送します。
メリット: これにより、「TCP ハンドシェイク」時間が短縮されます。これは、長距離リクエストのレイテンシの最大の要因となることがよくあります。
アクセス トークンのリージョン ヒント
アカウント リンク（OAuth）プロセス中に、システムはユーザーのホーム リージョンを特定できます。
実装: Google に発行された
access_tokenにリージョン ID をエンコードします。Google がフルフィルメント リクエストを送信すると、ゲートウェイはトークンをすぐに検査し、データベース検索を行わずにリクエストを正しいリージョン クラスタにルーティングできます。
システムの健全性 - パートナーから Google への指標
[成功率 >= 99.5%] を維持すると、Google Home でデバイスの状態が 正しく表示され、デバイスの追加と削除が行われ、自動化がトリガーされ、 履歴イベントが Google Home app (GHA) のアクティビティ タブに表示されるようになります。
成功率は、クラウドが状態の更新をプッシュしたときに Google から返される HTTP レスポンス コードに基づいて計算されます。Google 側のインフラストラクチャの問題でパートナー様が不利益を被らないように、この指標では Google 内部エラーが失敗数から除外されます。計算に含まれる API 呼び出しについては、 HomeGraph API リファレンスをご覧ください。
「成功」の定義とは
- 2xx（成功）: 状態の更新が Home Graph によって正常に受信、処理されました。
「失敗」の定義とは
- 4xx（パートナー エラー）: これらは失敗を表し、クラウドから送信されたリクエストに問題があることを示します。一般的なコードは次のとおりです。
- 400 Bad Request: 無効な構文のため、サーバーがリクエストを処理できませんでした。一般的な原因としては、不正な形式の JSON や、文字列値に "" でなく null を使っていることなどが挙げられます。
- 404 Not Found: リクエストされたリソースが見つかりませんでした。このエラーは通常、リクエストされたデバイスが見つからないことを意味します。ユーザー アカウントがリンクされていないか、無効な
agentUserIdを受け取った可能性があります。agentUserIdが SYNC レスポンスで提供された値と一致していること、DISCONNECTインテントが適切に処理されていることを確認してください。 - 429 Resource Exhausted: 統合が割り当てられた割り当てを超えています。 割り当ての管理については、ダッシュボードの上部にある「ステップ 1」セクションの手順をご覧ください。
デバイスの健全性 - 状態の精度
[状態の精度 >= 99.5%] を満たすか、それ以上の精度を達成すると、ユーザーがデバイスの状態を表示したり、Home に相談 などの AI 機能を使用したりしたときに、正しい結果が表示されるようになります。状態の精度が低い場合、自動化がトリガーされず、履歴エントリが GHAのアクティビティ タブに適切なタイミングで表示されないことがあります。詳細については、状態を報告するをご覧ください。
品質ダッシュボードでは、[全体的な精度] と [最も低いタイプ/トレイトの組み合わせ] という 2 つの異なる指標を使用して、1 時間ごとにこの情報を追跡します。
1. 精度のコンポーネント
この指標は、Google が報告された状態を既知のインテントの結果と照合できる「サンプル」から導出されます。
2. ダッシュボードの指標（1 時間ごとの計算）
ダッシュボードでは、1 時間間隔 で精度が計算されます。1 時間の合計サンプル数が 100 未満（S_Total < 100）の場合、その時間の精度は N/A に設定されます。
ビュー 1: 全体的な精度（グローバル平均）
これは、すべてのデバイスタイプとトレイトを組み合わせた統合の全体的な精度を表します。エコシステム全体の健全性の加重平均を示します。
- 計算: すべてのデバイスの状態の合計精度 / すべてのデバイスの状態の合計数
ビュー 2: 最も低いタイプ/トレイトの組み合わせ
これにより、統合で最も信頼性の低い特定のカテゴリが特定されます。品質の高い大量のデバイスが、品質の低い少量のデバイスを隠すのを防ぎます。たとえば、状態の精度が 99.5% を超えるライトが大量にあるが、状態の精度が低いスイッチが少量しかない場合、平均値では見過ごされる可能性のあるスイッチの改善が必要であることをハイライト表示します。
- 計算: すべてのトレイト / デバイス の組み合わせの状態の精度/状態の合計数の最小値。