このガイドでは、Dialogflow サービスの使用に関するベスト プラクティスについて説明します。 ここで示すガイドラインの目的は、効率と精度を向上させることと、サービスからのレスポンス時間を最適化することです。
すべてのエージェント タイプについての一般的なエージェントの設計のガイドと、音声エージェントの設計に特化した音声エージェントの設計のガイドもご覧ください。
プロダクション
エージェントを本番環境で実行する場合は、必ずプロダクションのベスト プラクティスを実施してください。
監査ログを有効にする
プロジェクトで Dialogflow API のデータアクセス監査ログを有効にします。変更履歴機能と同様に、監査ログを使用すると、プロジェクトに関連付けられた Dialogflow CX エージェントの設計時の変更を追跡できます。
エージェント バージョン
本番環境のトラフィックには、必ずエージェントのバージョンを使用してください。詳細については、 バージョンと環境 をご覧ください。
エージェントのバックアップを作成する
最新のエクスポートされたエージェント バックアップを維持します。これにより、ご自身またはチームメンバーがエージェントやプロジェクトを誤って削除した場合に迅速に復旧できます。
クライアントを再利用する
アプリケーションの実行の全期間中にわたって、*Client クライアント ライブラリ インスタンスを再利用することで、アプリケーションのパフォーマンスを向上させることができます。
最も重要な点は、SessionsClient クライアント ライブラリ インスタンスを再利用することで、インテント検出 API 呼び出しのパフォーマンスを向上させることができることです。
セッション リファレンスのプロトコルとバージョンを選択:
| プロトコル | V3 | V3beta1 |
|---|---|---|
| REST | セッション リソース | セッション リソース |
| RPC | セッション インターフェース | セッション インターフェース |
| C++ | SessionsClient | 利用できません |
| C# | SessionsClient | 利用できません |
| Go | SessionsClient | 利用できません |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | 利用不可 | 利用できません |
| Python | SessionsClient | SessionsClient |
| Ruby | 利用不可 | 利用できません |
詳細については、クライアント ライブラリのベスト プラクティスのガイドをご覧ください。
API エラー再試行
API メソッドを呼び出すときに、エラー レスポンスが返されます。エラー原因が一時的な問題のため、再試行が必要なエラーがもあります。エラーには次の 2 つの種類があります。
- Cloud API のエラー
- Webhook ステータスから送信されたエラー。
また、再試行には指数バックオフを実装する必要があります。これにより、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 オペレーションの一般的なパフォーマンスを示します。
| アクション | メモ |
|---|---|
| フローのアクション: 状態ハンドラ | 最も速いオペレーション |
| フロー: インテント検出（テキスト） | 最も速いオペレーション |
| フロー: パラメータ検出（テキスト） | 高速オペレーション |
| 音声認識（ストリーミング） | データが処理され、レスポンスが可能な限り早く返されます。合計実行時間は、主に入力音声の長さによって決まります。合計実行時間を使用してレイテンシを測定することをおすすめしません。 |
| 音声合成（ストリーミング） | 合計実行時間は、主に音声出力の長さによって決まります。データが処理され、レスポンスが可能な限り早く返されます。 |
| データストア: 生成 AI が無効 | 実際の時間はデータストアのサイズによって異なります。 |
| データストア: 生成 AI が有効 | パフォーマンスは、データストアのサイズ、使用中の言語モデル、プロンプトの出力と入力の長さによって異なります。 |
| 生成的フォールバック | パフォーマンスは、使用する言語とプロンプトの出力と入力の長さによって異なります。 |
| 生成ツール | パフォーマンスは、使用中の言語モデル、プロンプトの入力と出力の長さの複雑さ、ターンの生成ツールの数によって異なります。1 つのターンに複数の生成ツールがあると、言語モデルへの呼び出しが複数回行われます。 |
| ハンドブックの実行 | パフォーマンスは、ハンドブックの複雑さ、プロンプトの数、呼び出されたツールの実行時間によって異なります。プロンプトの出力と入力の長さは、このパフォーマンスに影響します。複数の言語モデル プロンプトが順番に実行され、合計呼び出し時間が長くなることがあります。 |
| ハンドブック: ツール | パフォーマンスは、ツールの基盤となる実行によって異なります。 |
| Webhook の呼び出し | パフォーマンスは、Webhook でのコードの実行時間によって直接決まります。 |
| エージェントのインポート / エクスポート | パフォーマンスはエージェントのサイズによって異なります。 |
| エージェント トレーニング | パフォーマンスは、フロー、インテント、トレーニング フレーズの数によって異なります。大規模なエージェントのトレーニングには数十分かかることがあります。 |
| 環境の作成 | 環境の作成にはエージェントのトレーニングが含まれるため、合計時間はエージェントのサイズと複雑さによって異なります。 |
重要な注意事項:
- ストリーミング: ストリーミング呼び出し（音声認識と合成）の場合、データは到着時に処理され、レスポンスは可能な限り早く返されます。 つまり、最初のレスポンスは通常、呼び出しの合計時間よりもはるかに速くなります。
- ハンドブック: LLM プロンプトは、ハンドブックの 指示、会話のコンテキスト、ツールの入力に基づいて作成されます。1 回のハンドブック呼び出しで複数の LLM プロンプトを実行できます。そのため、ハンドブックの実行は、発行されるプロンプトの数と呼び出しの複雑さによって異なります。
レイテンシに関する重要な考慮事項
- レイテンシの保証なし: Dialogflow SLA では、プロビジョンド スループットでもレイテンシは考慮されません。
- LLM のレイテンシ: LLM 処理では、レイテンシが大幅に発生する可能性があります。エージェントの設計とユーザーの期待値にこれを考慮してください。
- モニタリングとアラート: モニタリングとアラートを設定する場合は、LLM と音声サービスからのレスポンスのストリーミング特性を考慮してください。 完全なレスポンス時間が最初のレスポンス時間と同じであると想定しないでください。