Azure AI Bot Service ボットの一般的なトラブルシューティング

  • [アーティクル]

この記事の対象: SDK v4

以下のよく寄せられる質問は、一般的なボット開発や運用上の問題のトラブルシューティングに役立ちます。

ボットに関する問題をトラブルシューティングするにはどうすればよいですか。

  1. Visual Studio Code または Visual Studio を使用して、ご利用のボットのソース コードをデバッグします。
  2. ボットをクラウドにデプロイする前に、Bot Framework Emulator を使用してボットをテストします。
  3. Azure などのクラウド ホスティング プラットフォームにボットをデプロイし、Azure portal のボットのダッシュボードで組み込み Web チャット コントロールを使用して、ボットへの接続をテストします。 Azure にデプロイした後でボットに関する問題が発生した場合は、「Understanding Azure troubleshooting and support」(Azure のトラブルシューティングとサポートについて理解する) のブログ記事を参考にしてください。
  4. 認証を、起こり得る問題から除外します。
  5. ボットで使用する予定の Web チャット、Teams、またはその他のチャンネルでボットをテストします。 これは、エンド ツー エンド ユーザー エクスペリエンスを確認するのに役立ちます。
  6. ダイレクト ラインや Web チャットなど、追加の認証要件があるチャネルでのボットのテストを検討してください。
  7. ボットをデバッグする方法に関する記事、およびそのセクションに示されているデバッグに関するその他の記事をご覧ください。

認証に関する問題をトラブルシューティングするにはどうすればよいですか。

ボットの認証に関する問題のトラブルシューティングについて詳しくは、Bot Framework 認証のトラブルシューティングに関する記事をご覧ください。

ボットとチャネルの間のネットワーク接続をテストするには、どうすればよいですか?

以下の手順で生成された IP アドレスを使用して、それらのアドレスとの接続をブロックするルールがあるかどうかを確認できます。 「失敗した接続のファイアウォール トレースを確認する」セクションを参照してください。

ボットからチャネルへの接続をテストする

  1. ブラウザーで、Azure portal に移動します。

  2. 接続をテストするボット App Service を選択します。

  3. 左側のウィンドウの [開発ツール] セクションで、[高度なツール] を選択します。

  4. 右側のウィンドウで、[移動] を選択します。 Kudu 情報ページが表示されます。

  5. 上部のメニュー バーから、[デバッグ コンソール] を選択します。 次に、ドロップダウン メニューで [CMD] を選択します。 Kudu ボット Web アプリ コンソールが開きます。 詳細については、「Kudu」を参照してください。

    kudu cmd console

  6. nslookup directline.botframework.com を実行して、DNS 解決が機能しているかどうかチェックします。 nslookup (ネーム サーバー ルックアップ) は、ドメイン ネーム システム (DNS) に対してクエリを実行して、ドメイン名または IP アドレス マッピング、またはその他の DNS レコードを取得するためのネットワーク管理コマンドライン ツールです。 DNS 解決が機能している場合、このコマンドへの応答には関連情報が含まれます。

    kudu cmd console bot channel dns

    WHOIS IP ルックアップ ツールは、IP アドレスに関する情報を取得するのに役立ちます。

  7. curl -I directline.botframework.com を実行します。 (-I オプションは、ヘッダーのみを含む応答を取得するために使用されます)。HTTP 状態 301 が返されることをダブルチェックして、接続があることを確認します。

    kudu cmd console http 301

チャネルからボットへの接続をテストする

curl は運用サイトにアクセスできず、directline.botframework.com はパブリック インターネット上にあるため、シミュレーション モードで curl を使用する必要があります。 たとえば、携帯電話のホットスポットを使用して、仮想プライベート ネットワーク (VNET) の外部で次に示す手順を実行します。 「Azure Virtual Network とは」も参照してください。

  1. nslookup ivr-sr-bot.botapps.amat.com を実行します。 このコマンドへの応答に関連情報が含まれる場合、DNS 解決は機能しています。

    kudu cmd console channel bot dns

  2. curl -I https://ivr-sr-bot.botapps.amat.com/api/messages を実行して、適切な HTTP 状態コード (405「メソッドは許可されていません」など) が返されるかどうかをチェックします。 要求で指定されたメソッドは、指定された URI で識別されるリソースに対しては許可されていません。 これは、接続があることをチェックする方法にすぎません。

    kudu cmd console http 405

  3. ボットから応答が返されない場合は、クライアントの IP アドレスを書き留めます。

失敗した接続のファイアウォール トレースを確認する

nslookup ivr-sr-bot.botapps.amat.com および nslookup directline.botframework.com の IP アドレスを使用して、いずれかの方向でこれらのアドレスとの接続をブロックしているルールがあるかどうかをチェックします。

Bot Framework SDK for .NET を使用しています。 ボットに関する問題をトラブルシューティングするにはどうすればよいですか。

例外を探す

Visual Studio 2019 で、[デバッグ]>[Windows]>[例外設定] の順に移動します。 [例外設定] ウィンドウで、[Common Language Runtime Exceptions]\(共通言語ランタイム例外\) の横にある [スローされたときに中断] チェック ボックスをオンにします。 スローされた例外やハンドルされない例外がある場合にも、出力ウィンドウに診断の出力が表示されることがあります。

呼び出し履歴を確認する

Visual Studio で、マイ コードのみをデバッグするかどうかを選択できます。 完全な呼び出し履歴を調べることで、問題に関する詳細な分析情報が得られる場合があります。

すべてのダイアログ メソッドの最後が、次のメッセージを処理するプランであることを確認する

すべてのダイアログ ステップは、ウォーターフォールの次のステップにフィードされるか、現在のダイアログを終了してスタックから取り出す必要があります。 ステップが正しく処理されない場合、会話は期待どおりに続きません。 ダイアログの詳細については、ダイアログの概念に関する記事を参照してください。

HTTP 状態コード 429 "要求が多すぎます" のエラーの原因は何ですか。

HTTP 状態コード 429 のエラー応答は、一定時間に発行された要求が多すぎることを示します。 応答の本文には問題の説明が含まれています。また、要求間の最低限必要な間隔が示されている場合があります。 このエラーの発生源の 1 つとして、ngrok ツールが考えられます。 無料プランを利用しており、ngrok の制限に達している場合は、Web サイトの料金と制限のページに移動して、他のオプションを確認してください。

ボット メッセージがユーザーによって受信されないのはなぜですか。

応答で生成されるメッセージ アクティビティは正しくアドレス指定されている必要があります。そうでないと、意図した宛先にメッセージが届きません。 ほとんどの場合、これを明示的に処理する必要はありません。メッセージ アクティビティのアドレス指定は SDK によって処理されます。

アクティビティを正しくアドレス指定するために、適切な会話 ID の詳細と共に、送信者に関する詳細を含めます。 ほとんどの場合、メッセージ アクティビティは到着したものに応答して送信されます。 そのため、アドレス指定の詳細は、インバウンド アクティビティから取得できます。

トレースまたは監査ログを調べると、メッセージが正しくアドレス指定されているかどうかを確認できます。 メッセージが正しくアドレス指定されていない場合は、ボットにブレークポイントを設定し、メッセージに対して ID が設定される場所を確認します。

ASP.NET でバックグラウンド タスクを実行するにはどうすればよいですか。

場合によっては、非同期タスクを開始することができます。このタスクでは数秒間待機してから、コードが実行されてユーザー プロファイルがクリアされるか、会話やダイアログの状態がリセットされます。 これを行う方法の詳細については、「How to run Background Tasks in ASP.NET」 (ASP.NET でバックグラウンド タスクを実行する方法) を参照してください。 具体的には、HostingEnvironment.QueueBackgroundWorkItem の使用を検討します。

使用しているボットで最初に受信されたメッセージへの応答に時間がかかります。 時間を短縮するにはどうすればよいですか。

ボットは Web サービスであり、Azure を含む一部のホスティング プラットフォームでは、サービスで一定時間にトラフィックが受信されない場合、そのサービスは自動的にスリープ状態になります。 ご利用のボットでこのようになった場合は、次回のメッセージの受信時に最初からやり直す必要があり、その応答には、既に実行されている場合よりもかなり時間がかかります。

一部のホスティング プラットフォームでは、スリープ状態にならないようにご利用のサービスを構成することができます。 ボットが Azure AI Bot Service Web Apps でホストされている場合は、Azure portal でご利用のボットのサービスに移動し、[アプリケーション設定]、[常時接続] の順に選択します。 このオプションは、すべてではなく、ほとんどのサービス プランで利用できます。

メッセージの配信順序を保証するにはどうすればよいですか。

Bot Framework では、メッセージの順序が可能な限り保持されます。 たとえば、メッセージ A を送信し、その HTTP 操作の完了を待機してから、メッセージ B を送信する別の HTTP 操作を開始する場合などです。SMS や電子メールなどの一部のチャンネルでは、ユーザーがメッセージを受信する順序は保証されません。

メッセージ テキストの部分がドロップされるのはなぜですか。

Bot Framework や多くのチャネルでは、Markdown での書式設定の場合と同じように、テキストが解釈されます。 Markdown 構文として解釈される可能性のある文字が、ご利用のテキストに含まれているかどうかを確認してください。

同じボット サービス エンドポイントで複数のボットをサポートするにはどうすればよいですか。

このサンプルに、正しい MicrosoftAppCredentials で Conversation.Container を構成し、シンプルな MultiCredentialProvider を使用して複数のアプリケーション ID とパスワードを認証する方法が示されています。

Bot Framework では識別子はどのように動作しますか。

Bot Framework の識別子について詳しくは、Bot Framework の識別子に関するガイドをご覧ください。

ユーザー ID にアクセスするにはどうすればよいですか。

Bot Framework チャンネルでは、ユーザーが送信した Activity の from.Id フィールドにユーザーの ID が示されます。 SMS および電子メールのメッセージでは、このプロパティで生のユーザー ID が示されます。 一部のチャンネルでは from.Id プロパティを隠すため、そのチャンネルのユーザー ID とは異なる、ユーザーに対して一意の ID が含まれます。 既存のアカウントに接続する必要がある場合は、サインイン カードを使用して独自の OAuth フローを実装し、ユーザー ID を独自のサービスのユーザー ID に接続できます。

自分の Facebook のユーザー名が表示されなくなったのはなぜですか。

ご利用の Facebook のパスワードを変更しましたか。 変更すると、アクセス トークンが無効になり、Azure portal で Facebook Messenger チャネル用のボットの構成設定の更新が必要になります。

自分のボットから認証済みのサービスを使用するにはどうすればよいですか。

Microsoft Entra ID 認証については、「ボットに認証を追加する」チュートリアルを参照してください。

Note

認証およびセキュリティ機能をご自分のボットに追加する場合は、コードで実装するパターンが、ご利用のアプリケーションに適したセキュリティ標準に準拠していることを確認する必要があります。

ユーザーの所定の一覧に自分のボットへのアクセスを制限するにはどうすればよいですか。

SMS や電子メールなどの一部のチャネルでは、対象範囲外のアドレスが提供されます。 このような場合は、ユーザーからのメッセージに from.Id プロパティの生のユーザー ID が含まれます。

Facebook、Slack などの他のチャネルでは、ボットで事前にユーザーの ID を予測できない方法で、対象範囲内のアドレスまたはテナント アドレスが提供されます。 このような場合は、ログイン リンクまたは共有シークレットを使用してユーザーを認証し、ボットを使用する権限があるかどうかを判断する必要があります。

ダイレクト ライン 1.1 の会話がすべてのメッセージの後、やり直されるのはなぜですか。

Note

このセクションは、最新バージョンの Direct Line プロトコル 3.0 には適用されません。

ダイレクト ラインの会話がすべてのメッセージの後、やり直される場合、ダイレクト ライン クライアントによってボットに送信されたメッセージの from プロパティが欠落しているか null である可能性があります。 ダイレクト ライン クライアントによって、from プロパティが欠落しているか null であるメッセージが送信されると、ダイレクト ライン サービスで自動的に ID が割り当てられるため、クライアントから送信されたすべてのメッセージは、新しい別のユーザーから送信されたものと見なされます。

これを解決するには、ダイレクト ライン クライアントによって送信される各メッセージの from プロパティを、メッセージを送信しているユーザーを一意に表す安定した値に設定します。 たとえば、ユーザーが既に Web ページまたはアプリにサインインしている場合、ユーザーが送信したメッセージの from プロパティの値として、その既存のユーザー ID を使用できます。 あるいは、ページの読み込み時またはアプリケーションの読み込み時にランダムなユーザー ID を生成し、その ID を Cookike またはデバイス状態で格納し、ユーザーが送信したメッセージの from プロパティの値として、その ID を使用することもできます。

ダイレクト ライン 3.0 サービスから HTTP 状態コード 502 "ゲートウェイが不適切です" という応答が返される原因は何ですか。

ご利用のボットに接続しようとしたときに、要求が正常に完了しない場合は、ダイレクト ライン 3.0 から HTTP 状態コード 502 が返されます。 このエラーは、ボットからエラーが返されたか、要求がタイムアウトになったことを示します。ご利用のボットで生成されたエラーの詳細については、Azure portal 内のボットのダッシュボードに移動して、影響を受けるチャネルに関する "問題" リンクをクリックしてください。 ご利用のボットに対して Application Insights が構成されている場合は、そこで詳細なエラー情報を見つけることもできます。

ボットを作成するときに Authorization_RequestDenied という例外が発生するのはなぜですか。

Azure AI Bot Service ボットを作成するためのアクセス許可は、Microsoft Entra ID ポータルを使用して管理します。 Microsoft Entra ID 管理センターでアクセス許可が適切に構成されていない場合、ユーザーがボット サービスを作成しようとしたときに Authorization_RequestDenied 例外が発生します。

まず、ディレクトリの "ゲスト" であるかどうかを確認します。

  1. Azure Portal にサインインします。
  2. [すべてのサービス] を選択し、「active」を検索します。
  3. [Microsoft Entra ID] を選びます。
  4. [ユーザー] を選択します。
  5. 一覧からユーザーを見つけて、[ユーザー タイプ] が [ゲスト] でないことを確認します。

Microsoft Entra ID User-type

[ゲスト] でないことを確認したら、アクティブ ディレクトリ内のユーザーがボット サービスを作成できることを確認するために、ディレクトリ管理者が次の設定を構成する必要があります。

  1. Microsoft Entra ID 管理センターにサインインします。 [ユーザーとグループ] に移動して、[ユーザー設定] を選択します。
  2. [アプリの登録] セクションで、[ユーザーはアプリケーションを登録できる] を [はい] に設定します。 これで、ディレクトリ内のユーザーがボット サービスを作成できるようになります。
  3. [外部ユーザー] セクションで、[ゲストのアクセス許可を制限する] を [いいえ] に設定します。 これで、ディレクトリ内のゲスト ユーザーがボット サービスを作成できるようになります。

Microsoft Entra ID Admin Center

自分のボットを移行できないのはなぜですか。

dev.botframework.com に登録されているボットを Azure に移行する必要があるが、ボットの移行で問題が発生する場合は、ボットが既定のディレクトリ以外のディレクトリに属していることが原因である可能性があります。 以下の手順を試してみてください。

  1. ターゲット ディレクトリから、既定のディレクトリのメンバーではない新しいユーザーを (メール アドレスを使用して) 追加し、移行のターゲットとなるサブスクリプションに対する共同作成者ロールをそのユーザーに付与します。

  2. 開発者ポータルから、移行する必要があるボットの共同所有者として、ユーザーのメール アドレスを追加します。 その後、サインアウトします。

  3. 新しいユーザーとして開発者ポータルにサインインして、ボットの移行に進みます。

詳細情報はどこで入手できますか。

  • Stack Overflow で既に回答済みの質問を検索するか、botframework タグを使用してご自分の質問を投稿します。 Stack Overflow には、わかりやすいタイトル、完全かつ簡潔な問題の説明、問題を再現するための十分な詳細情報が必要などのガイドラインがあります。 機能要求や非常に広範な質問はトピックから外れています。新しいユーザーは、Stack Overflow ヘルプ センターにアクセスして詳細を確認する必要があります。
  • Bot Framework SDK での既知の問題に関する情報を確認する場合や、新しい問題を報告する場合は、GitHub の BotBuilder に関する問題を参照してください。
  • Gitter の BotBuilder コミュニティ ディスカッション。