スキルの概要

適用対象: SDK v4

スキル ボットを使用してボットを 拡張 できます。 スキルは、他のさまざまなボットによって使用され、再利用が容易になります。この方法では、ユーザー向けボットを作成し、独自のスキルまたはサードパーティのスキルを使用して拡張できます。

  • スキル 、別のボットに対して一連のタスクを実行できるボットであり、ボットはスキルとユーザー向けボットの両方 — になります。
  • "スキル コンシューマー" は、1 つ以上のスキルを呼び出すことができるボットです。 ユーザー向けスキル コンシューマーは、"ルート ボット" とも呼ばれます。
  • "スキル マニフェスト" は、スキルが実行できるアクション、その入力と出力パラメーター、およびスキルのエンドポイントが記述された JSON ファイルです。
    • スキルのソース コードにアクセスできない開発者は、マニフェストの情報を使用してスキル コンシューマーを設計できます。
    • "スキル マニフェスト スキーマ" は、スキル マニフェストのスキーマが記述された JSON ファイルです。
    • スキルを実装 する方法と、 サンプル スキル マニフェストの スキル マニフェストを 記述する方法を参照してください。

つまり、ユーザーはルート ボットと直接対話し、ルート ボットはその会話ロジックの一部をスキルに委任します。

スキル機能は次のように設計されています。

  • スキルとコンシューマーは、HTTP プロトコルを使用して HTTP Bot Frameworkします。
  • スキル コンシューマーは複数のスキルを使用できます。
  • スキル コンシューマーは、スキルの実装に使用された言語とは関係なくスキルを使用できます。 たとえば C# ボットは、Python を使用して実装されたスキルを使用できます。
  • スキルは、スキル コンシューマーになり、その他のスキルを呼び出すこともできます。
  • スキルはユーザー認証をサポートしますが、ユーザー認証はスキルでローカルに行われ、別のボットに転送することはできません。
  • スキルは、Bot Framework アダプターとカスタム アダプターの両方と連携できます。

この図は、考えられる順列の一部を示しています。

ブロック図

概念のアーキテクチャ

スキルとスキル コンシューマーは別々のボットであり、ユーザーはそれらを個別に公開します。

  • スキル コンシューマーには、スキルを呼び出したり取り消したりする場合など、スキルを管理するためのロジックを追加する必要があります。 コンシューマーには、通常のボット オブジェクトとアダプター オブジェクトに加えて、アクティビティをスキルとやり取りするために使用されるスキル関連オブジェクトがいくつか含まれています。 スキル コンシューマーは、少なくとも 2 つの HTTP エンドポイントを実装します。
    • メッセージング エンドポイントは、ユーザー またはチャネルからアクティビティを受信します。 これは、すべてのボットが実装する通常のメッセージング エンドポイントです。
    • スキル からアクティビティを 受信するスキル ホスト エンドポイント。 これは、スキルが応答するサービス URL であるコールバック URL として機能します。 (スキル コンシューマーは、スキルから HTTP メソッド要求を受け取るコードをスキル ハンドラーとペアリングする必要があります)。
  • スキルでは、完了時にアクティビティを送信するロジックを追加する必要があります。そのため、スキル コンシューマーは、アクティビティのスキルへの転送を停止 endOfConversation する時間を知る必要があります。

次の図は、ユーザーから送信されたアクティビティがルート ボットを経由してスキルに到達し、再びユーザーに戻るまでのフローを示しています。

アーキテクチャの図

  1. ルート ボットのアダプターは、ユーザーからアクティビティを受信して、ルート ボットのアクティビティ ハンドラーに転送します。 (ユーザーからのアクティビティは、ルート ボットのメッセージング エンドポイントで受信されます)。
  2. ルート ボットは、スキル HTTP クライアントを使用してアクティビティをスキルに送信します。 クライアントは、スキル定義とスキル会話 ID ファクトリからコンシューマー スキルの会話情報を取得します。 これには、スキルがアクティビティへの応答に使用するサービス URL が含まれます。
  3. スキルのアダプターは、スキル コンシューマーからアクティビティを受信して、スキルのアクティビティ ハンドラーに転送します。 (コンシューマーからのアクティビティは、スキル ボットのメッセージング エンドポイントで受信されます)。
  4. スキルが応答すると、ルート ボットのスキル ハンドラーはアクティビティを受信します。 さらに、スキル会話 ID ファクトリからルート/ユーザー間の会話の情報を取得します。 その後に、アクティビティをルート ボットのアダプターに転送します。 (スキルからのアクティビティは、ルート ボットのスキル ホスト エンドポイントで受信されます)。
  5. ルート ボットのアダプターは、内部でプロアクティブ メッセージを生成して、ユーザーとの会話を再開します。
  6. ルート ボットのアダプターは、スキルからのメッセージをすべてユーザーに送信します。

スキルの管理とスキル トラフィックのルーティングには、次のオブジェクトを利用します。

  • "Bot Framework スキル" は、スキルのルーティング情報を記述したもので、スキル コンシューマーの構成ファイルから読み取られます。
  • "スキル HTTP クライアント" は、スキルにアクティビティを送信します。
  • "スキル ハンドラー" は、スキルからアクティビティを受信します。
  • "スキル会話 ID ファクトリ" は、ユーザー/ルート間の会話リファレンスとルート/スキル間の会話リファレンスの間で変換を行います。
  • Bot Connector サービスは、チャネルとボット間認証の両方を提供します。 認証構成 オブジェクトを使用 すると、スキルまたはスキル コンシューマーに要求の検証を追加して、アクセス権を持つアプリケーションまたはユーザーを制限できます。

スキル クライアントとスキル ハンドラーの両オブジェクトは、"会話 ID ファクトリ" を使用して、ルート ボットがユーザーとの対話に使用する会話と、ルート ボットがスキルとの対話に使用する会話の間で変換を行います。

スキル マニフェスト

スキル マニフェストは 、スキルが実行できるアクション、その入力パラメーターと出力パラメーター、スキルのエンドポイント、スキルのディスパッチ モデルを記述する JSON ファイルです。

スキル マニフェスト スキーマの詳細については、スキル マニフェスト を記述する 方法に関するページを参照してください

ボット間通信

設計するボットの種類に関係なく、この設計の一定の側面を理解しておくことが重要です。

スキル アクション

一部のスキルでは、さまざまなタスクや "アクション" を実行できます。 たとえば、To Do スキルで、個別の会話としてアクセスできるアクティビティの作成、更新、表示、削除を許可できます。

会話リファレンス

ユーザー/ルート間の会話とルート/スキル間の会話は異なります。

"会話 ID ファクトリ" は、スキル コンシューマーとスキルの間のトラフィックの管理を支援します。 このファクトリは、ルート/ユーザー間の会話 ID とルート/スキル間の会話 ID の間で変換を行います。 つまり、ルートとスキルの間で使用される会話 ID を生成し、その ID から元のユーザー/ルート間の会話 ID を復旧します。

サーバー間の調整

ルートとスキル ボットは HTTP を介して通信します。 そのため、スキルからアクティビティを受信するルート ボットのインスタンスと、開始アクティビティを送信したインスタンスが同じでない場合があります。つまり、これら 2 つの要求は、異なるサーバーで処理される可能性があります。

  • アクティビティをスキルに転送する前に、必ずスキル コンシューマーで状態を保存してください。 これにより、スキルからトラフィックを受信するインスタンスは、スキルを呼び出す前に、前のインスタンスが中断したところから処理を再開できます。
  • スキル ハンドラーは、スキルからアクティビティを受信すると、それをスキル コンシューマーに適した形式に変換し、コンシューマーのアダプターに転送します。

スキル コンシューマーとスキルの状態

スキル コンシューマーとスキルは、それぞれの状態を別々に管理します。 ただしコンシューマーでは、スキルとの通信に使用する会話 ID が作成されます。 これがスキルの会話状態に影響することがあります。

重要

既に説明したように、スキル コンシューマーがユーザー アクティビティをスキルに委任した場合に、そのコンシューマーの別のインスタンスがスキルの応答を受信することがあります。 コンシューマーは、アクティビティをスキルに転送する直前に、会話状態を保存する必要があります。

ボット間認証

アプリ ID とパスワードは、スキルとスキル コンシューマーをローカルでテストするために必要Emulator。 スキルを Azure にデプロイするには、引き続き Azure サブスクリプションが必要です。

サービス レベルの認証は、Bot Connector サービスで管理されます。 このフレームワークでは、ベアラー トークンとボット アプリケーション ID を使用して各ボットの ID が検証されます。 (Bot Frameworkは、 認証構成オブジェクト を使用して、受信要求の認証ヘッダーを検証します)。

重要

これには、デプロイされたボット (スキル コンシューマーと使用するスキル) に、有効なアプリケーション資格情報が必要です。

要求検証

認証構成に 要求検証を追加 する必要があります。 要求は認証ヘッダーの後に評価されます。 要求を拒否するには、検証コードでエラーまたは例外をスローします。

注意

ボットがアプリ ID とパスワードを持っている場合は、要求の検証を実行します。それ以外の場合、要求の検証は実行されません。

通常であれば認証される要求を、さまざまな理由で拒否することができます。

  • スキル コンシューマーが、会話を開始した相手である可能性があるスキルからのトラフィックのみを受け入れる必要がある場合。
  • スキルが有料サービスの一部であり、データベースに登録されていないユーザーのアクセスを禁止する必要がある場合。
  • スキルへのアクセスを特定のスキル コンシューマーに限定する場合。

重要

要求検証機能を提供しない場合、ボットがスキルまたはスキル コンシューマーの場合でも、別のボットからアクティビティを受信すると、ボットによってエラーまたは例外が生成されます。

スキルの会話のデバッグ

スキルコンシューマーとスキル コンシューマー間のトラフィックは認証されます。このようなボットをデバッグする場合は、追加の手順があります。

  • スキル コンシューマーと、それが直接または間接的に使用するすべてのスキルが実行されている必要があります。
  • ボットがローカルで実行されている場合、およびボットの中にアプリ ID とパスワードがある場合は、すべてのボットに有効な ID とパスワードが必要です。
  • ボットがすべてデプロイされている場合は、ngrok を使用して任意のチャネルからボットをデバッグ する方法に関するページを参照してください
  • 一部のボットがローカルで実行され、一部がデプロイされている場合は、スキルまたはスキル コンシューマーをデバッグする方法 に関するページを参照してください

それ以外の場合は、他のボットをデバッグするのと同じように、スキル コンシューマーまたはスキルをデバッグできます。 詳細については、ボットのデバッグに関するページと「デバッグ」を参照Emulator。

関連情報

ユーザーから見ると、自分たちはルート ボットと対話しています。 スキルにとってスキル コンシューマーは、ユーザーとの通信に使用するチャネルです。