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