スキルの概要

この記事の対象: 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 スキルで、個別の会話としてアクセスできるアクティビティの作成、更新、表示、削除を許可できます。

• 1 つのアクションを実装する単純なスキルについては、スキルを実装する方法を参照してください。
• ダイアログを使用して複数のアクションを実装するスキルについては、スキル内でダイアログを使用する方法を参照してください。

会話リファレンス

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

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

サーバー間の調整

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

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

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

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

ボット間認証

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

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

要求検証

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

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

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

スキルの会話のデバッグ

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

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

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

追加情報

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

• スキル コンシューマーの詳細については、スキル コンシューマーについてのページを参照してください。