まくろぐ

LUIS と QnA Maker でキーの管理方法が異なるのはなぜか?

更新:
作成:
Microsoft の素敵なサービス、LUIS と QnA Maker で扱うキー情報に関するコラムです。

LUIS や QnA Maker サービスを利用するためのエンドポイントキーは、下記の 2 種類が提供されます。

  • 実運用のためのキー: チャットクライアントなどからの、一般的な問い合わせを処理するためのキー。
  • 管理用のキー: 各サービスの情報を取得したり、データを編集したりするためのキー。

LUIS も QnA Maker も便利なサービスなのですが、Azure リソースとの結びつけ方法や、キーの管理方法が異なっているため、最初はわけがわからなくなるかもしれません。 例えば、Azure ポータル上の RESOURCE MANAGEMENT / Keys のページで表示されるキー(サブスクリプションキー)が、LUIS の場合は実運用のためのキーであるのに対し、QnA Maker の場合は管理用のキー であったりします。

LUIS/QnA を使用する場合は、それぞれ、エンドポイントキーとしてどちらのキーを使用するかを間違えないようしなければいけません。

  • LUIS のサブスクリプションキー(実運用のためのキー): Azure ポータルの LUIS リソースの Keys で表示されるもの
  • LUIS のオーサリングキー(管理用のキー): LUIS ポータルの Authoring Key で表示されるもの
  • QnA Maker のエンドポイントキー(実運用のためのキー): QnA Maker ポータルのプロファイル設定で表示されるもの
  • QnA Maker のサブスクリプションキー(管理用のキー): Azure ポータルの QnA Maker リソースの Keys で表示されるもの

この時点で、キーの管理方法が QnA Maker と LUIS では完全に逆になっています。 Azure 上でのインタフェースは LUIS リソースと QnA Maker リソースで見た目が同じなので、混乱に拍車をかけています。

/p/8myms6s/keys-between-luis-and-qna1.png
図: LUIS リソースの Keys 管理画面
/p/8myms6s/keys-between-luis-and-qna2.png
図: QnA Maker リソースの Keys 管理画面

なぜこのようなことになっているのか、Microsoft のサポートの方に確認してみたところ、下記のような回答をいただきました。 簡単に言うと、各サービスの生い立ちの違いによるものだそうです。 わかりにくいですが、この辺りはそういうものなのだと納得するしかないですね。

各サービスの違いについて

LUIS は 当初 Azure と紐づかないサービスとして提供されており、Azure のリソースがなくても新しい LUIS のアプリケーションを作成できるように作られたサービスになっておりました。 そのため、アプリケーションの作成や編集を行うオーサリングキーは LUIS ポータルで作成されるものになっております。

後に LUIS が Azure の Cognitive Service として正式にリリースされた後、Azure のリソースとして関連付けるためにエンドポイントキーを Azure ポータルで取得する LUIS のリソースキーと紐づけております。 それぞれの LUIS のアプリケーションそのものは Azure リソースに紐づいておらず、各ユーザーアカウント (メールアドレス) に紐づいており、エンドポイントへのアクセスキーのみが Azure のリソースとして存在しております。

対しまして QnA Maker は Azure のリソースと紐づくことを当初から想定してリリースされたサービスになっているため、アプリケーションの作成や編集を行うために Azure のサブスクリプションキーが必要になります。

このように LUIS と QnA Maker ではリリースまでの経緯に違いがあることから、各種キーの扱いも異なっております。

まくろぐ
サイトマップまくへのメッセージ