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 リソースで見た目が同じなので、混乱に拍車をかけています。
なぜこのようなことになっているのか、Microsoft のサポートの方に確認してみたところ、下記のような回答をいただきました。 簡単に言うと、各サービスの生い立ちの違いによるものだそうです。 わかりにくいですが、この辺りはそういうものなのだと納得するしかないですね。
各サービスの違いについて
LUIS は 当初 Azure と紐づかないサービスとして提供されており、Azure のリソースがなくても新しい LUIS のアプリケーションを作成できるように作られたサービスになっておりました。 そのため、アプリケーションの作成や編集を行うオーサリングキーは LUIS ポータルで作成されるものになっております。
後に LUIS が Azure の Cognitive Service として正式にリリースされた後、Azure のリソースとして関連付けるためにエンドポイントキーを Azure ポータルで取得する LUIS のリソースキーと紐づけております。 それぞれの LUIS のアプリケーションそのものは Azure リソースに紐づいておらず、各ユーザーアカウント (メールアドレス) に紐づいており、エンドポイントへのアクセスキーのみが Azure のリソースとして存在しております。
対しまして QnA Maker は Azure のリソースと紐づくことを当初から想定してリリースされたサービスになっているため、アプリケーションの作成や編集を行うために Azure のサブスクリプションキーが必要になります。
このように LUIS と QnA Maker ではリリースまでの経緯に違いがあることから、各種キーの扱いも異なっております。