スキルの概要

  • [アーティクル]

適用対象: SDK v4

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

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

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

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

  • スキルとコンシューマーは、Bot Framework プロトコルを使用して HTTP 経由で通信します。
  • スキル コンシューマーは複数のスキルを使用できます。
  • スキル コンシューマーは、スキルの実装に使用された言語とは関係なくスキルを使用できます。 たとえば、C# ボットでは、JavaScript を使用して実装されたスキルを使用できます。
  • スキルは、スキル コンシューマーになり、その他のスキルを呼び出すこともできます。
  • スキルはユーザー認証をサポートします。ただし、ユーザー認証はスキルに対してローカルであり、別のボットに転送することはできません。
  • スキルは、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 が作成されます。 これがスキルの会話状態に影響することがあります。

重要

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

ボット間認証

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

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

重要

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

要求検証

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

注意

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

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

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

重要

要求検証コントロールを指定しない場合、ボットがスキルまたはスキル コンシューマーであるかどうかに関係なく、別のボットからアクティビティを受信すると、ボットによってエラーまたは例外が生成されます。

スキル会話のデバッグ

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

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

それ以外の場合は、他のボットをデバッグするのと同じように、スキル コンシューマーまたはスキルをデバッグできます。 詳細については、「ボットのデバッグ」および「Bot Framework Emulatorを使用したデバッグ」を参照してください。

関連情報

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