サービス使用のベスト プラクティス

このガイドでは、Dialogflow サービスの使用に関するベスト プラクティスについて説明します。ここで示すガイドラインの目的は、効率と精度を向上させることと、サービスからのレスポンス時間を最適化することです。

すべてのエージェント タイプについての一般的なエージェントの設計のガイドと、音声エージェントの設計に特化した音声エージェントの設計のガイドもご覧ください。

プロダクション

エージェントを本番環境で実行する場合は、必ずプロダクションのベスト プラクティスを実施してください。

監査ログを有効にする

プロジェクトで Dialogflow API のデータアクセス監査ログを有効にします。これにより、このプロジェクトにリンクされている Dialogflow エージェントの設計時間の変更を追跡できます。

エージェント バージョン

本番環境のトラフィックには、必ずエージェントのバージョンを使用してください。詳細については、バージョンと環境をご覧ください。

エージェント バックアップを作成する

最新のエクスポートされたエージェント バックアップを維持します。これにより、ご自身またはチームメンバーがエージェントやプロジェクトを誤って削除した場合に迅速に復旧できます。

クライアントを再利用する

アプリケーションの実行の全期間中にわたって、*Client クライアント ライブラリ インスタンスを再利用することで、アプリケーションのパフォーマンスを向上させることができます。

最も重要な点は、SessionsClient クライアント ライブラリ インスタンスを再利用することで、インテント検出 API 呼び出しのパフォーマンスを向上させることができることです。

セッションのリファレンスをご覧ください。

詳細については、クライアント ライブラリのベスト プラクティスのガイドをご覧ください。

エージェントに対するバッチ アップデート

短時間に多数のエージェント アップデート API リクエストを個別に送信する場合は、リクエストが制限される可能性があります。これらの設計時 API メソッドは、1 つのエージェントのアップデート頻度が高い場合には処理されません。

一部のデータ型には、この目的のためのバッチメソッドがあります。

  • 多数の EntityTypes の create、patch、または delete リクエストを送信する代わりに、batchUpdate または batchDelete メソッドを使用します。
  • 多数の Intents の create、patch、または delete リクエストを送信する代わりに、batchUpdate または batchDelete メソッドを使用します。

API エラー再試行

API メソッドを呼び出すときに、エラー レスポンスが返されます。エラー原因が一時的な問題のため、再試行が必要なエラーがもあります。エラーには次の 2 つの種類があります。

また、再試行には指数バックオフを実装する必要があります。これにより、API サービスの負荷が大きい場合に、システムが許容レートを検出できます。

Cloud API のエラー

Google が提供するクライアント ライブラリを使用している場合は、指数バックオフを使用した Cloud API エラーの再試行が実装されます。

REST または gRPC を使用して独自のクライアント ライブラリを実装した場合は、クライアントの再試行を自分で実装する必要があります。 再試行する必要があるエラーと必要ないエラーについては、API 改善の提案: 自動再試行の構成をご覧ください。

Webhook エラー

API 呼び出しによって Webhook 呼び出しがトリガーされると、Webhook がエラーを返す場合があります。Google が提供するクライアント ライブラリを使用している場合でも、Webhook エラーは自動的に再試行されません。コードは、Webhook から受信した 503 Service Unavailable エラーを再試行する必要があります。Webhook エラーの種類とそれらの確認方法については、Webhook サービスのドキュメントをご覧ください。

負荷テスト

コードを本番環境にリリースする前に、システムの負荷テストを実施することをおすすめします。負荷テストを実装する前に、次の点を考慮してください。

概要 詳細
段階的な負荷の増加。 負荷テストでは、Dialogflow サービスに適用される負荷を段階的に増大する必要があります。このサービスは、実際のトラフィックではまれにのみ発生する負荷の急増を処理するようには設計されていません。サービスが負荷の需要に合わせて調整を行うのに時間を要するため、テストが目的の負荷に達するまでリクエスト レートを徐々に上昇させます。
API 呼び出しの課金。 テスト中の API 呼び出しは課金の対象であり、プロジェクトの割り当てによる制限を受けます。
テストダブルの使用。 負荷テスト中に API を呼び出す必要はありません。負荷テストの目的が、システムの負荷の処理方法を決定することの場合、実際の API 呼び出しの代わりにテストダブルを使用することをおすすめします。テストダブルを使用すると、読み込み中の API の動作をシミュレートできます。
再試行の実施。 負荷テストでは、バックオフを使用して再試行を行う必要があります。

エンドユーザー デバイスから Dialogflow を安全に呼び出す

Dialogflow API へのアクセスに使用する秘密鍵をエンドユーザーのデバイスに保存しないでください。これは、鍵をデバイスに直接保存する場合と、アプリケーションでハードコーディングする場合について該当します。クライアント アプリケーションが Dialogflow API を呼び出す必要がある場合は、安全なプラットフォームでデベロッパー所有のプロキシ サービスにリクエストを送信する必要があります。プロキシ サービスでは、実際の認証済み Dialogflow 呼び出しを行うことができます。

たとえば、Dialogflow を直接呼び出すモバイルアプリは作成しないでください。そのようなアプリケーションを作成すると、秘密鍵をエンドユーザーのデバイスに保存する必要があります。その代わりに、モバイルアプリは安全なプロキシ サービスを介してリクエストを渡す必要があります。

パフォーマンス

このセクションでは、Dialogflow 内のさまざまなオペレーションのパフォーマンス情報について概説します。レイテンシを理解することは、レスポンシブ エージェントの設計と現実的なパフォーマンスの期待値の設定に重要ですが、これらの値は Dialogflow SLA の一部ではありません。

モニタリング ツールとアラート ツールを構築する場合、大規模言語モデル（LLM）と音声処理は通常、ストリーミング メソッドを使用して処理されることに注意してください。レスポンスはできるだけ早くクライアントに送信されます。多くの場合、メソッド呼び出しの合計時間よりもはるかに早く送信されます。詳細については、大規模言語モデル（LLM）のベスト プラクティスをご覧ください。

オペレーションあたりのパフォーマンス

次の表に、Dialogflow オペレーションの一般的なパフォーマンスを示します。

アクション メモ
インテント検出（テキスト） 高速なオペレーション
パラメータ検出（テキスト） 高速なオペレーション
音声認識（ストリーミング） データはできる限り早く処理され、レスポンスが返されます。合計実行時間は主に入力音声の長さによって決まります。合計実行時間を使用してレイテンシを測定することはおすすめしません。
音声合成（ストリーミング） 合計実行時間は主に出力音声の長さによって決まります。データはできる限り迅速に処理され、レスポンスが返されます。
Webhook の呼び出し パフォーマンスは、Webhook 内のコードの実行時間によって直接決まります。
インポート / エクスポート エージェント パフォーマンスはエージェントのサイズによって異なります。
エージェント トレーニング パフォーマンスは、フロー、インテント、トレーニング フレーズの数によって異なります。大規模なエージェントのトレーニングには数十分かかることがあります。
環境の作成 環境の作成にはエージェントのトレーニングが含まれるため、合計時間はエージェントのサイズと複雑さによって異なります。

主な注意事項:

  • ストリーミング: ストリーミング呼び出し（音声認識と合成）では、データは受信時に処理され、できるだけ早くレスポンスが返されます。つまり、通常、最初の応答は通話の合計時間よりもはるかに短くなります。
  • ハンドブック: LLM プロンプトは、ハンドブックの手順、会話のコンテキスト、ツール入力に基づいて構築されます。1 つのハンドブック呼び出しで複数の LLM プロンプトを実行できます。そのため、プレイブックの実行時間は、発行されるプロンプトの数と呼び出しの複雑さによって異なります。

レイテンシに関する重要な考慮事項

  • レイテンシの保証なし: Dialogflow SLA では、プロビジョニングされたスループットの場合でも、レイテンシは考慮されません。
  • LLM レイテンシ: LLM 処理により、レイテンシが大幅に増加する可能性があることに注意してください。この点をエージェントの設計とユーザーの期待に反映してください。
  • モニタリングとアラート: モニタリングとアラートを設定する際は、LLM と音声サービスのレスポンスがストリーミングされる性質を考慮してください。完全な応答時間が最初の応答時間と同じであると想定しないでください。