ボットのテレメトリ データを分析する
この記事の対象: SDK v4
ボットの動作の分析
次のクエリ集は、ボットの動作を分析するために使用できます。 このコレクションを使用して、Azure Monitor Log Analytics でカスタム クエリを作成したり、監視ダッシュボードと Power BI 視覚化ダッシュボードを作成したりできます。
前提条件
次の概念を基本的に理解しておくと役立ちます。
- Kusto クエリ
- Azure portal で Log Analytics を使用して Azure Monitor ログ クエリを記述する方法
- Azure Monitor のログ クエリの基本概念
ダッシュボード
Azure ダッシュボードには、お客様のクエリから生成された情報を表示および共有する優れた方法が用意されています。 カスタム ダッシュボードを構築し、自分がダッシュボードに追加するタイルにクエリを関連付けることで、ボットのアクティビティを監視しやすくなります。 ダッシュボードの詳細と、クエリを関連付ける方法については、「Log Analytics データのダッシュボードを作成して共有する」を参照してください。 この記事の残りの部分では、ボットの動作の監視に役立つクエリ サンプルをいくつか紹介します。
Kusto クエリのサンプル
Note
この記事のすべてのクエリについて、ピリオド、チャネル、ロケールなど、さまざまなディメンションでピボットすることをお勧めします。
期間あたりのユーザー数
このサンプルでは、過去 14 日間において、ボットと対話した個別のユーザー数を日別に示す折れ線グラフが得られます。 期間は、queryStartDate、queryEndDate、interval の各変数に異なる値を割り当てることで簡単に変更できます。
重要
認証されたユーザーである場合にのみ、このクエリで一意のユーザーの正しい数を取得します。また、結果はチャネルの機能によっても異なります。
// number of users per period
let queryStartDate = ago(14d);
let queryEndDate = now();
let groupByInterval = 1d;
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| summarize uc=dcount(user_Id) by bin(timestamp, groupByInterval)
| render timechart
ヒント
Kusto の summarize 演算子は、入力テーブルの内容を集計したテーブルを生成するために使用されます。
bin 関数は Kusto のスカラー関数であり、summarize operator と組み合わせて使用すると、クエリ結果が指定値でグループ分けされます。 上のサンプルでは日によってグループ分けしていますが、Kusto では h (時間)、m (分)、s (秒)、ms (ミリ秒)、microsecond (マイクロ秒) を使用することも可能です。
render 演算子を使用すると、さまざまなグラフを簡単にレンダリングできます。たとえば、x 軸に日時をとり、y 軸に任意の数値列を使用できる折れ線グラフである timechart などがあります。 自分のデータに指定期間の一部が含まれていない場合でも、x 軸上の間隔は自動的に適切に調整されます。 render ステートメントを使用しない場合の既定値は table です。
期間ごとのユーザー数のクエリ結果のサンプル
期間あたりのアクティビティ
この例では、過去 14 日間の 1 日あたりの会話数、ダイアログ数、メッセージ数など、目的のディメンションごとのアクティビティの量を測定する方法を示します。 期間は、querystartdate、queryEndDate、interval の各変数に異なる値を割り当てることで簡単に変更できます。 目的のディメンションは、次のextend例の句によって定義され、 metric InstanceId、DialogId、または activityId のいずれかに設定できます。
metric に、表示したいディメンションを設定します。
// Measures the number of activity's (conversations, dialogs, messages) per period.
let queryStartDate = ago(14d);
let queryEndDate = now();
let groupByInterval = 1d;
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| extend InstanceId = tostring(customDimensions['InstanceId'])
| extend DialogId = tostring(customDimensions['DialogId'])
| extend ActivityId = tostring(customDimensions['activityId'])
| where DialogId != '' and InstanceId != '' and user_Id != ''
| extend metric = InstanceId // DialogId or ActivityId
| summarize Count=dcount(metric) by bin(timestamp, groupByInterval)
| order by Count desc nulls last
| render timechart
ヒント
Kusto の extend 演算子は、計算列を作成してそれらを結果セットに追加するために使用されます。
期間ごとのアクティビティのクエリ結果のサンプル
期間あたりのユーザーごとのアクティビティ
このサンプルでは、一定期間におけるユーザーごとのアクティビティ数をカウントする方法を示します。 このクエリは、期間ごとのアクティビティ クエリに ドリルダウンして、期間 ごとのユーザーごとのアクティビティに焦点を当てます。 アクティビティには、ダイアログ、会話、メッセージがあります。 このクエリは、ボットとのユーザー操作を測定します。これは、次のような潜在的な問題を見つけるのに役立ちます。
- 1 人のユーザーによるアクティビティが多い日は、攻撃やテストを意味する可能性があります
- ある期間にやり取りがほとんどない場合、サービスの正常性に問題がある可能性があります
ヒント
by user_Id を削除すると、全般的なボット アクティビティの量を取得し、時間とダイアログ、メッセージ、または会話でピボットできます。
// number of users per period per dialogs
let queryStartDate = ago(14d);
let queryEndDate = now();
let interval = 6h;
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| extend InstanceId = tostring(customDimensions['InstanceId'])
| extend DialogId = tostring(customDimensions['DialogId'])
| extend ActivityId = tostring(customDimensions['activityId'])
| where DialogId != '' and InstanceId != '' and user_Id != ''
| extend metric = ActivityId // InstanceId // DialogId // or InstanceId for conversation count
| summarize Count=dcount(metric) by user_Id, bin(timestamp, groupByInterval)
| order by Count desc nulls last
ユーザーごとのアクティビティごとのクエリ結果のサンプル
| user_Id | timestamp | Count |
|---|---|---|
| User-8107ffd2 | 2019-09-03T00:00:00Z | 14 |
| User-75f2cc8f | 2019-08-30T00:00:00Z | 13 |
| User-75f2cc8d | 2019-09-03T00:00:00Z | 13 |
| User-3060aada | 2019-09-03T00:00:00Z | 10 |
完了したダイアログ
ダイアログのテレメトリ クライアントを設定すると、ダイアログ (とその子) から、"開始済み" や "完了済み" など、いくつかの既定のテレメトリ データが出力されるようになります。 このサンプルを使用すると、"完了済み" ダイアログを "開始済み" ダイアログと比較して測定できます。 開始されたダイアログの数が完了した数を超える場合、一部のユーザーはダイアログ フローを完了していません。 このクエリを使用すると、潜在的なダイアログ ロジックを特定してトラブルシューティングできます。 また、最も頻繁に使用されるダイアログを識別するためにも使用できます。
ウォーターフォール ダイアログの入力候補
// % Completed Waterfall Dialog: shows completes relative to starts
let queryStartDate = ago(14d);
let queryEndDate = now();
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| where name=="WaterfallStart"
| extend DialogId = customDimensions['DialogId']
| extend InstanceId = tostring(customDimensions['InstanceId'])
| join kind=leftouter (
customEvents
| where name=="WaterfallComplete"
| extend InstanceId = tostring(customDimensions['InstanceId'])
) on InstanceId
| summarize started=countif(name=='WaterfallStart'), completed=countif(name1=='WaterfallComplete') by tostring(DialogId)
| where started > 100 // filter for sample
// Show starts vs. completes
| project tostring(DialogId), started, completed
| order by started desc, completed asc nulls last
| render barchart with (kind=unstacked, xcolumn=DialogId, ycolumns=completed, started, ysplit=axes)
ヒント
Kusto の join 演算子を使用すると、各テーブルの指定の列で値を照合することで、2 つのテーブルの行をマージして新しいテーブルを形成できます。
project 演算子は、自分の出力に表示したいフィールドを選択するために使用されます。 新しいフィールドを追加する extend operator と同様に、project operator では、既存のフィールド セットから選択することも、新しいフィールドを追加することもできます。
アダプティブ ダイアログの開始と完了
// % Completed adaptive dialog: shows completes relative to starts. This type is the default dialog type when using Power Virtual Agents or Composer.
customEvents
| where name=="AdaptiveDialogStart" or name == "AdaptiveDialogComplete"
| extend DialogId = tostring(customDimensions['DialogId'])
| summarize started=countif(name=='AdaptiveDialogStart'), completed=countif(name=='AdaptiveDialogComplete') by DialogId
| project DialogId, started, completed
| order by started desc, completed asc nulls last
| render barchart with (kind=unstacked, xcolumn=DialogId, ycolumns=completed, started, ysplit=axes)
ダイアログ完了クエリの結果のサンプル
未完了のダイアログ
このサンプルを使用すると、指定期間において、開始されたもののキャンセルまたは破棄されたために完了しなかったダイアログ フローの数をカウントできます。 これを使用すると、不完全なダイアログを確認し、ユーザーの混乱やユーザーの関心の喪失のためにアクティブにキャンセルされたかどうかを調べることができます。
ウォーターフォール ダイアログが完了していない
// Show incomplete dialogs when using waterfall dialogs.
let queryStartDate = ago(14d);
let queryEndDate = now();
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| where name == "WaterfallStart"
| extend DialogId = customDimensions['DialogId']
| extend instanceId = tostring(customDimensions['InstanceId'])
| join kind=leftanti (
customEvents
| where name == "WaterfallComplete"
| extend instanceId = tostring(customDimensions['InstanceId'])
) on instanceId
| summarize cnt=count() by tostring(DialogId)
| order by cnt
| render barchart
アダプティブ ダイアログが完了していない
// Show incomplete dialogs for adaptive dialogs; this type is the default dialog type when using Power Virtual Agents or Composer.
let queryStartDate = ago(14d);
let queryEndDate = now();
customEvents
| where name == "AdaptiveDialogStart"
| extend DialogId = tostring(customDimensions['DialogId'])
| join kind=rightanti (
customEvents
| where name == "AdaptiveDialogComplete"
| extend DialogId = tostring(customDimensions['DialogId'])
) on name, DialogId
| summarize cnt=count() by DialogId
| order by cnt
| render barchart
ヒント
Kusto の order 演算子 (sort operator と同じ) は、1 つ以上の列を基準にして入力テーブルの行を並べ替えるために使用されます。 注: クエリの結果から null 値を除外する場合は、ステートメントでwhereフィルター処理できます。たとえば、"and isnotnull(Timestamp)" を追加したり、先頭または末尾に null 値を返したりするには、order ステートメントの末尾またはnulls first末尾に null 値を追加nulls firstします。
dialog-incompletion クエリ結果のサンプル
ダイアログ シーケンスのドリルダウン
会話中のウォーターフォール ダイアログの開始、ステップ、完了
この例では、会話 (instanceId) でグループ化された一連のダイアログ ステップを示します。これは、ダイアログの中断につながるステップを特定するのに役立ちます。
このクエリを実行し、SampleDialogId の代わりに目的 DialogId の <値を入力します>
// Drill down: Show waterfall start/step/complete for specific dialog
let queryStartDate = ago(14d);
let queryEndDate = now();
let DialogActivity=(dlgid:string) {
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| extend DialogId = customDimensions['DialogId']
| extend StepName = customDimensions['StepName']
| extend InstanceId = customDimensions['InstanceId']
| where DialogId == dlgid
| project timestamp, name, StepName, InstanceId
| order by tostring(InstanceId), timestamp asc
};
// For example see SampleDialogId behavior
DialogActivity("<SampleDialogId>")
ヒント
このクエリは、クエリ定義関数を使用して記述されています。これは、単一クエリのスコープ内で定義および使用されるユーザー定義関数であり、let ステートメントを通じて定義されます。 このクエリが query-defined function を使用せずに記述された場合:
let queryStartDate = ago(14d);
let queryEndDate = now();
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| extend DialogId = customDimensions['DialogId']
| extend StepName = customDimensions['StepName']
| extend InstanceId = customDimensions['InstanceId']
| where DialogId == "<SampleDialogId>"
| project timestamp, name, StepName, InstanceId
| order by tostring(InstanceId), timestamp asc
サンプル クエリの結果
| timestamp | name | StepName | InstanceId |
|---|---|---|---|
| 2019-08-23T20:04... | WaterfallStart | null | ...79c0f03d8701 |
| 2019-08-23T20:04... | WaterfallStep | GetPointOfInterestLocations | ...79c0f03d8701 |
| 2019-08-23T20:04... | WaterfallStep | ProcessPointOfInterestSelection | ...79c0f03d8701 |
| 2019-08-23T20:04... | WaterfallStep | GetRoutesToDestination | ...79c0f03d8701 |
| 2019-08-23T20:05... | WaterfallStep | ResponseToStartRoutePrompt | ...79c0f03d8701 |
| 2019-08-23T20:05... | WaterfallComplete 1 | null | ...79c0f03d8701 |
| 2019-08-28T23:35... | WaterfallStart | null | ...6ac8b3211b99 |
| 2019-08-28T23:35... | WaterfallStep 2 | GetPointOfInterestLocations | ...6ac8b3211b99 |
| 2019-08-28T19:41... | WaterfallStart | null | ...8137d76a5cbb |
| 2019-08-28T19:41... | WaterfallStep 2 | GetPointOfInterestLocations | ...8137d76a5cbb |
| 2019-08-28T19:41... | WaterfallStart | null | ...8137d76a5cbb |
1完了
2破棄済み
解釈: ユーザーは GetPointOfInterestLocations ステップで会話を破棄しているようです。
Note
ウォーターフォール ダイアログではシーケンス (開始、複数のステップ、完了) が実行されます。 シーケンスが開始を示しているのに完了されていない場合、ユーザーによるダイアログの破棄またはキャンセルが原因でダイアログが中断されたことを意味します。 この詳細な分析では、この動作を確認できます (完了した手順と破棄された手順を参照)。
ウォーターフォールの開始、ステップ、完了、キャンセル ステップの集計値
このサンプルでは、ダイアログ シーケンスが開始された合計回数の集計値、ウォーターフォール ステップの総数、正常に完了した件数、キャンセル数が表示され、WaterfallStart の数と WaterfallComplete および WaterfallCancel の総数との差から、破棄の総数がわかります。
// Drill down: Aggregate view of waterfall start/step/complete/cancel steps totals for specific dialog
let queryStartDate = ago(14d);
let queryEndDate = now();
let DialogSteps=(dlgid:string) {
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| extend DialogId = customDimensions['DialogId']
| where DialogId == dlgid
| project name
| summarize count() by name
};
// For example see SampleDialogId behavior
DialogSteps("<SampleDialogId>")
ウォーターフォール集計クエリの結果のサンプル
| name | count |
|---|---|
| WaterfallStart | 21 |
| WaterfallStep | 47 |
| WaterfallComplete | 11 |
| WaterfallCancel | 1 |
解釈: ダイアログ シーケンスの 21 回の呼び出しのうち、11 回しか完了せず、9 回は破棄され、1 回はユーザーによって取り消されました。
ダイアログの平均時間
このサンプルでは、ユーザーが特定のダイアログに費やした時間の平均値を測定します。 ボットは、ユーザーが完了するまでに時間がかかるダイアログを簡略化することでメリットが得られる場合があります。
// Average dialog duration
let queryStartDate = ago(14d);
let queryEndDate = now();
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| where name=="WaterfallStart"
| extend DialogId = customDimensions['DialogId']
| extend instanceId = tostring(customDimensions['InstanceId'])
| join kind=leftouter (customEvents | where name=="WaterfallCancel" | extend instanceId = tostring(customDimensions['InstanceId'])) on instanceId
| join kind=leftouter (customEvents | where name=="WaterfallComplete" | extend instanceId = tostring(customDimensions['InstanceId'])) on instanceId
| extend duration = case(not(isnull(timestamp1)), timestamp1 - timestamp,
not(isnull(timestamp2)), timestamp2 - timestamp, 0s) // Abandoned aren't counted. Alternate: now()-timestamp
| extend seconds = round(duration / 1s)
| summarize AvgSeconds=avg(seconds) by tostring(DialogId)
| order by AvgSeconds desc nulls last
| render barchart with (title="Duration in Dialog")
平均期間のクエリ結果のサンプル
ダイアログの平均ステップ数
この例では、呼び出された各ダイアログの "長さ" を、平均、最小、最大、標準偏差で計算して示します。 これは、ダイアログの質の分析に役立ちます。 次に例を示します。
- ステップが多すぎるダイアログは、簡略化の機会を評価する必要があります。
- 最小値、最大値、平均値の差が大きいダイアログでは、ユーザーがタスクを完了しようとして行き詰まっている可能性があります。 タスク完了までのパスを短縮できないか、またはダイアログの複雑さを軽減する方法がないかを検討することをお勧めします。
- 標準偏差が大きいダイアログでは、複雑なパスまたは壊れたエクスペリエンス (破棄/キャンセル) が提案されます。
- 手順が少ないダイアログは、完了しなかったため、そのようになることがあります。 こうした判断を行うには、完了と破棄の比率分析が有用です。
// min/max/std/avg steps per dialog
let queryStartDate = ago(14d);
let queryEndDate = now();
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| extend DialogId = tostring(customDimensions['DialogId'])
| extend StepName = tostring(customDimensions['StepName'])
| extend InstanceId = tostring(customDimensions['InstanceId'])
| where name == "WaterfallStart" or name == "WaterfallStep" or name == "WaterfallComplete"
| order by InstanceId, timestamp asc
| project timestamp, DialogId, name, InstanceId, StepName
| summarize cnt=count() by InstanceId, DialogId
| summarize avg=avg(cnt), minsteps=min(cnt),maxsteps=max(cnt), std=stdev(cnt) by DialogId
| extend avgsteps = round(avg, 1)
| extend avgshortbysteps=maxsteps-avgsteps
| extend avgshortbypercent=round((1.0 - avgsteps/maxsteps)*100.0, 1)
| project DialogId, avgsteps, minsteps, maxsteps, std, avgshortbysteps, avgshortbypercent
| order by std desc nulls last
平均ステップクエリ結果のサンプル
| ダイアログ ID | avg steps | min steps | max steps | std | avg short by steps | avg short by percent |
|---|---|---|---|---|---|---|
| FindArticlesDialog | 6.2 | 2 | 7 | 2.04 | 0.8 | 11.4% |
| CreateTicket | 4.3 | 2 | 5 | 1.5 | 0.7 | 14% |
| CheckForCurrentLocation | 3.9 | 2 | 5 | 1.41 | 1.1 | 22% |
| BaseAuth | 3.3 | 2 | 4 | 1.03 | 0.7 | 17.5% |
| onboarding | 2.7 | 2 | 4 | 0.94 | 1.3 | 32.5% |
__Interpretation: たとえば、FindArticlesDialog は min/max の間に広がりがあり、調査し、場合によっては再設計して最適化する必要があります。
アクティビティ メトリック別のチャネル アクティビティ
このサンプルでは、指定期間においてボットが受信した、チャネルあたりのアクティビティの量を測定します。 これは、受信メッセージ、ユーザー、会話、ダイアログのいずれかのメトリックをカウントすることで実行されます。 これは、サービスの正常性分析やチャネルの使用頻度の測定に役立ちます。
// number of metric: messages, users, conversations, dialogs by channel
let queryStartDate = ago(14d);
let queryEndDate = now();
let groupByInterval = 1d;
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| extend InstanceId = tostring(customDimensions['InstanceId'])
| extend DialogId = tostring(customDimensions['DialogId'])
| extend ActivityId = tostring(customDimensions['activityId'])
| extend ChannelId = tostring(customDimensions['channelId'])
| where DialogId != '' and InstanceId != '' and user_Id != ''
| extend metric = user_Id // InstanceId or ActivityId or user_Id
| summarize Count=count(metric) by ChannelId, bin(timestamp, groupByInterval)
| order by Count desc nulls last
| render barchart with (title="Users", kind=stacked) // or Incoming Messages or Conversations or Users
ヒント
これらのバリエーションを試すこともお勧めします。
- タイムスタンプバケットを使用せずにクエリを実行します
bin(timestamp, groupByInterval)。 - 個別のユーザーと
countすべてのユーザー イベント アクティビティに使用dcountすることもできます。 これは、リピート ユーザーにも適しています。
channel-activity-by-activity クエリの結果のサンプル
解釈: エミュレーター テストは以前は最も一般的でしたが、ライブに移行すると、DirectLineSpeech が最も人気のあるチャネルです。
人気別の意図の合計数
このサンプルは LUIS 対応ボットに適用されます。 使用頻度別の全意図の概要、および対応する意図検出の確実性スコアが示されます。
Note
Language Understanding (LUIS) は、2025 年 10 月 1 日に廃止されます。 2023 年 4 月 1 日以降は、新しい LUIS リソースを作成することはできません。 より新しいバージョンの言語理解が、現在、Azure AI Language の一部として提供されています。
Azure AI Language の機能である会話言語理解 (CLU) は、LUIS の更新バージョンです。 Bot Framework SDK での言語理解のサポートの詳細については、「自然言語の理解」を参照してください。
- 実際には、ビューはメトリックごとに分離する必要があります。
- 使用頻度の高い意図パスは、ユーザー エクスペリエンスのために最適化することをお勧めします。
- 平均スコアが低い場合、認識力が低く、実際のユーザーの意図を捉え損なっていると考えられます。
// show total intents
let queryStartDate = ago(14d);
let queryEndDate = now();
customEvents
| where timestamp > queryStartDate
| where timestamp < queryEndDate
| where name startswith "LuisResult"
| extend intentName = tostring(customDimensions['intent'])
| extend intentScore = todouble(customDimensions['intentScore'])
| summarize ic=count(), ac=avg(intentScore)*100 by intentName
| project intentName, ic, ac
| order by ic desc nulls last
| render barchart with (kind=unstacked, xcolumn=intentName, ycolumns=ic,ac, title="Intents Popularity")
人気度別の意図のクエリ結果のサンプル
解釈: 最も一般的な意図など、確認は平均で 23% の信頼度でのみ検出されます。
ヒント
棒グラフは、Kusto クエリで使用できる十数個のオプションの 1 つにすぎません。 他のオプションには、anomalychart、areachart、columnchart、linechart、scatterchart などがあります。 詳細については、render 演算子のトピックを参照してください。
ボット分析のインストルメンテーションのスキーマ
次の表に、ボットのテレメトリ データが記録される最も一般的なフィールドを示します。
一般的なエンベロープ
Application Insights インストルメンテーションの一般的なログ分析フィールド。
| フィールド | 説明 | サンプル値 |
|---|---|---|
| name | Message type (メッセージの種類) | BotMessageSend、BotMessageReceived、LuisResult、WaterfallStep、WaterfallStart、SkillWebSocketProcessRequestLatency、SkillWebSocketOpenCloseLatency、WaterfallComplete、QnaMessage、WaterfallCancel、SkillWebSocketTurnLatency、AuthPromptValidatorAsyncFailure |
| customDimensions | SDK のボット分析 | activityId=<id>、activityType=message、channelId=emulator、fromId=<id>、fromName=User、locale=en-us、recipientId=<id>、recipientName=Bot、text=find a coffee shop |
| timestamp | イベントの日時 | 2019-09-05T18:32:45.287082Z |
| instance_Id | 会話 ID | f7b2c416-a680-4b2c-b4cc-79c0f03d8711 |
| operation_Id | ターン ID | 084b2856947e3844a5a18a8476d99aaa |
| user_Id | 一意のチャネル ユーザー ID | emulator7c259c8e-2f47... |
| client_IP | クライアント IP アドレス | 127.0.0.1 (プライバシー保護のため記録されないことがあります) |
| client_City | クライアントの市区町村 | レドモンド (検出された場合。記録されないことがあります) |
Note
Azure AI QnA Maker は 2025 年 3 月 31 日に廃止されます。 2022 年 10 月 1 日以降、新しい QnA Maker リソースまたはナレッジ ベースを作成できなくなります。 Azure AI Language の一部として、質問応答機能の新しいバージョンが提供されました。
Azure AI Language の機能であるカスタム質問応答は、QnA Maker サービスの更新バージョンです。 Bot Framework SDK での質問と回答サポートの詳細については、「自然言語理解」を参照してください。
Note
Language Understanding (LUIS) は、2025 年 10 月 1 日に廃止されます。 2023 年 4 月 1 日以降は、新しい LUIS リソースを作成することはできません。 より新しいバージョンの言語理解が、現在、Azure AI Language の一部として提供されています。
Azure AI Language の機能である会話言語理解 (CLU) は、LUIS の更新バージョンです。 Bot Framework SDK での言語理解のサポートの詳細については、「自然言語の理解」を参照してください。
カスタム ディメンション
ボット固有のアクティビティ データの大部分は、customDimensions フィールドに格納されます。
| フィールド | 説明 | サンプル値 |
|---|---|---|
| activityId | メッセージ ID | <id>: 8da6d750-d00b-11e9-80e0-c14234b3bc2a |
| activityType | メッセージの種類 | message、conversationUpdate、event、invoke |
| channelId | チャネル識別子 | emulator、directline、msteams、webchat |
| fromId | From 識別子 | <id> |
| fromName | クライアントからのユーザー名 | John Bonham、Keith Moon、Steve Smith、Steve Gadd |
| locale | クライアント元のロケール | en-us、zh-cn、en-GB、de-de、zh-CN |
| recipientId | 受信者識別子 | <id> |
| recipientName | 受信者名 | John Bonham、Keith Moon、Steve Smith、Steve Gadd |
| text | メッセージのテキスト | コーヒー ショップを探してください |
カスタム ディメンション: LUIS
Note
Language Understanding (LUIS) は、2025 年 10 月 1 日に廃止されます。 2023 年 4 月 1 日以降は、新しい LUIS リソースを作成することはできません。 より新しいバージョンの言語理解が、現在、Azure AI Language の一部として提供されています。
Azure AI Language の機能である会話言語理解 (CLU) は、LUIS の更新バージョンです。 Bot Framework SDK での言語理解のサポートの詳細については、「自然言語の理解」を参照してください。
LUIS インストルメンテーションでは、次のカスタム ディメンション フィールドにデータが格納されます。
| フィールド | 説明 | サンプル値 |
|---|---|---|
| 意図 | LUIS で検出された意図 | pointOfInterestSkill |
| intentScore | LUIS 認識スコア | 0.98 |
| エンティティ | LUIS で検出されたエンティティ | FoodOfGrocery = [["コーヒー"]]、KEYWORD= ["コーヒー ショップ"] |
| Question | LUIS で検出された質問 | コーヒー ショップを探してください |
| sentimentLabel | LUIS で検出されたセンチメント | 肯定的 |
カスタム ディメンション: QnAMaker
Note
Azure AI QnA Maker は 2025 年 3 月 31 日に廃止されます。 2022 年 10 月 1 日以降、新しい QnA Maker リソースまたはナレッジ ベースを作成できなくなります。 Azure AI Language の一部として、質問応答機能の新しいバージョンが提供されました。
Azure AI Language の機能であるカスタム質問応答は、QnA Maker サービスの更新バージョンです。 Bot Framework SDK での質問と回答サポートの詳細については、「自然言語理解」を参照してください。
QnAMaker インストルメンテーションでは、次のカスタム ディメンション フィールドにデータが格納されます。
ヒント
質問や回答などの個人情報のログ記録を有効にするには、QnA Maker クラスのコンストラクターで log personal information パラメーターを true に設定する必要があります。
| フィールド | 説明 | サンプル値 |
|---|---|---|
| question | QnA で検出された質問 | 何を実行できますか? |
| 回答 | QnA の回答 | 質問があるなら、お答えできるかもしれません。 |
| articleFound | QnA | true |
| questionId | QnA 質問 ID | 488 |
| knowledgeBaseId | QnA KB (キロバイト) ID | 2a4936f3-b2c8-44ff-b21f-67bc413b9727 |
| matchedQuestion | 一致した質問の配列 | [自分の役割について説明してもらえますか?」、"自分について少し教えていただけますか?"、"私を助けていただけますか"、"何ができるか"、"何ができるか"、"どのように私を助けることができるか"、"ヘルプを行うことができますか?"、"ヘルプを行う方法"、"プロジェクトで自分をどのように使用できますか?"、"機能についてお問い合せください","何ができるか?", ...] |
参照
- ログ クエリの記述に関するチュートリアルについて「Azure Monitor でログ クエリの使用を開始する」を確認する
- Azure Monitor からのデータの視覚化
- ボットにテレメトリを追加する方法を確認する
- Azure Monitor のログ クエリの詳細について確認する
- Bot Framework アプリケーション インサイト イベントの完全な一覧
- Log Analytics データのダッシュボードを作成して共有する