この記事では、よく寄せられる一般的な質問に回答します。
この記事の対象: SDK v4
入力しても何も行われないのはなぜですか。
一部のチャネルでは、クライアントでの一時的な入力の更新がサポートされていません。
SDK のコネクタ ライブラリとビルダー ライブラリの違いは何ですか。
コネクタ ライブラリは、REST API の説明部分です。 ビルダー ライブラリには、会話ダイアログ プログラミング モデルやその他の機能 (プロンプト、ウォーターフォール、チェーン、ガイド付きフォーム入力など) が追加されています。 Builder ライブラリでは、自然言語の理解などの Azure AI サービスへのアクセスも提供されます。
ユーザー メッセージは HTTPS メソッド呼び出しにどのように関連しますか。
ユーザーがチャネル経由でメッセージを送信するときに、Bot Framework Web サービスでは、ボットの Web サービス エンドポイントに対して HTTPS POST が発行されます。 ボットからは、そのチャネル上のユーザーに対して、0 件、1 件、または多くのメッセージが返信される場合があります。その場合、送信されるメッセージごとに Bot Framework に対して別の HTTPS POST が発行されます。
"プロアクティブ" と "リアクティブ" の違いは何ですか。
ボットの観点から、"リアクティブ" は、ユーザーがメッセージをボットに送信して会話を開始し、ボットでそのメッセージに応答して反応することを意味します。 これに対して、"プロアクティブ" は、ボットでユーザーに最初のメッセージを送信して会話を開始することを意味します。 たとえば、タイマーの期限が切れたときやイベントが発生したときに、ユーザーに通知するプロアクティブ メッセージがボットから送信される場合があります。
ユーザーにプロアクティブ メッセージを送信するにはどうすればよいですか。
プロアクティブ メッセージを送信する方法を示す例については、GitHub の BotBuilder-Samples リポジトリ内にある C# の V4 のサンプルと Node.js の V4 のサンプルをご覧ください。
ETag とは何ですか。 ボット データ バッグ ストレージにどのように関連しますか。
ETag は、オプティミスティック コンカレンシーのためのメカニズムです。 ボット データ バッグ ストレージでは ETag を使用して、データ更新の競合を防ぎます。 HTTP 状態コード 412 "必須条件に失敗しました" の ETag エラーは、ボットが最初の操作を完了する前に複数のメッセージが並列で受信されたことを示します。 ダイアログ スタックおよび状態は、ボット データ バッグに格納されます。 たとえば、ご利用のボットで、該当する会話の新しいメッセージの受信時に前のメッセージがまだ処理されている場合、"前提条件が満たされていません" という ETag エラーが表示されることがあります。
レート制限とは何ですか?
Bot Framework サービスは、どのボットも他のボットのパフォーマンスに悪影響を及ぼすことがないように、不正な呼び出しパターン (サービス拒否攻撃など) からサービス自体と顧客を保護する必要があります。 このような保護を実現するために、Microsoft のエンドポイントにレート制限 ("調整" とも呼ばれます) が追加されました。 レート制限を適用することで、クライアントまたはボットが特定の呼び出しを行うことができる頻度を制限できます。 たとえば、レート制限を有効にすると、ボットは多数のアクティビティを投稿する場合に、それらを一定期間にわたって分割して投稿する必要があります。 レート制限の目的は、ボットの総容量の上限を設けることではありません。 人間の会話パターンに従っていない会話インフラストラクチャの不正使用を防ぐことを目的としています。 たとえば、2 人の人間が使用できる量を超えたコンテンツにより、2 つの会話を飽和状態にするなどです。
レート制限値を教えてください。
サービスとユーザーを保護しながら、できるだけ緩やかなものにするために、レート制限値は継続的に調整されています。 しきい値が変更されることがあるため、現時点では数値を公開していません。 最後に、App Service でボットをホストしている場合、ボットは App Service の制限にバインドされます。 詳細については、「Azure サービスの SLA の概要」を参照してください。レート制限の影響を受ける場合は、お気軽に bf-reports@microsoft.com にお問い合わせください。
チャネルを使用して転送されるファイルのサイズ制限は何ですか?
一部のチャネルでは、送信できるファイルのサイズまたは種類に制限があります。 たとえば、Direct Line と Facebook ではアクティビティ ペイロードは 262,144 バイトに制限されますが、Bot Framework Emulator には制限はありません。 このような制限はチャネルによって課されます。 この制限を超えるメッセージを送信すると、次のようなエラーが発生する可能性があります。要求コンテンツの長さが 262,144 バイトの制限を超えました。 ただし、リソースへのリンクをインターネットの添付ファイルとして指定することはできます。 添付ファイルの送信の詳細については、「メッセージにメディアを追加するには」を参照してください。
レート制限の影響を受けているかどうかを確認するにはどうすればよいですか?
要求が大量であっても、お客様がレート制限を受けることはまずありません。 ほとんどのレート制限は、(ボットまたはクライアントからの) アクティビティの一括送信、極端なロード テスト、またはバグによってのみ発生します。 要求が調整されると、要求の再試行が成功するまでの待機時間 (秒単位) を示す Retry-After ヘッダーと共に、HTTP 429 (Too Many Requests) 応答が返されます。 この情報を収集するには、Azure Application Insights を使用してボットの分析を有効にします。 また、メッセージをログに記録するコードをボットに追加することもできます。
レート制限はどのように発生しますか?
レート制限は、次のいずれかの条件によって発生します。
- ボットがメッセージを送信する頻度が高すぎる場合
- ボットのクライアントがメッセージを送信する頻度が高すぎる場合
- Direct Line クライアントが新しい Web ソケットを要求する頻度が高すぎる場合
どうやって人間へのハンドオフを実装するのですか?
ボットがユーザーを理解していない場合や要求を自動化できない場合など、ボットから人間に会話を転送 (ハンドオフ) する必要がある場合があります。 このような場合、ボットは人間へ転送を行います。 Bot Framework SDK では、人間へのハンドオフがサポートされています。 ハンドオフ操作を通知するためのイベントの種類がいくつかあります。 これらのイベントは、ボットとエージェント ハブ (エンゲージメント ハブとも呼ばれます) の間で交換されます。 このエージェント ハブは、エージェント (通常は人間) がユーザーからの要求とボットからのエスカレーション要求を受信して処理できるようにするアプリケーションまたはシステムとして定義されます。 詳細については、「会話をボットから人間に移行する」の記事を参照してください。