AIチャットのログ分析は何から始める？｜8行の例で解決率の分母を確かめる

AIチャットのログを分析するときは、まず「1件」を何で数え、どの会話を集計対象にするかを決めます。同じログでも、重複行やテスト会話を混ぜると割合が変わります。また、画面上の「解決済み」が、利用者自身による解決確認なのか、システム側の判定なのかも分けて見ましょう。

この記事は、社内FAQ用AIチャットの利用状況を報告する担当者向けです。Microsoft Copilot Studioの公式資料を手掛かりに、集計条件から改善箇所を選ぶまでを整理します。掲載する8行は説明用の架空データで、実際の製品から出力したCSVではありません。実機での操作、利用効果、回答精度の測定は行っていません。公式資料の確認日は2026年10月17日です。

ログを見る前に、期間と「1件」の単位を決める

最初に、質問の数を調べるのか、会話セッションの結果を調べるのかを決めます。ここでのセッションは、製品が分析用に区切った一まとまりです。メッセージ1通を、そのまま1セッションとは数えません。

Copilot Studioの監視の概要では、一つの会話が一つ以上の分析セッションを含む場合があると説明されています。さらに、セッションデータの公式説明には、セッションを識別するSessionIDや、結果を表すSessionOutcomeなどの項目が載っています。自分の製品でも、出力される項目と区切り方を確認してください。

集計メモには、次のように条件を残します。

UTCは協定世界時です。例の期間を日本時間に直すと、10月1日9時以上、10月2日9時未満になります。「10月1日分」という言葉だけで日本時間の一日と混ぜないようにします。Microsoftの概要資料も、分析の日時がUTCで表示されると説明しています。

利用環境と製品の版もメモに加えます。Copilot Studioのモニターには、テストパネルで試した活動が表示されないという制約があります。本稿の「テスト」行は、管理者が別途用意した分析用表へ混ざった場合の教材で、公式CSVにテスト区分列が必ずあるという意味ではありません。

架空の8行を整理し、分母と結果を計算する

次の表では、各行の開始日時がすべて例の期間内にあるものとします。「No.」は教材の行番号、「テスト」「利用者評価」は説明用に整えた列です。実際のCSVとは列名も値も一致しません。

まずNo.2とNo.3を比べます。この例では、同じセッションの同じ記録が二重に入ったと確認できたため、一方を集計から外します。実データでIDが同じというだけで消すのは早計です。複数行で一つの会話を表す出力なら、行をまとめる処理が必要になります。元データは保存し、外した行と理由を記録します。

次に、動作確認用のL06を除きます。残った本番セッションは、L01、L02、L03、L04、L05、L07の6件です。L05の「対話なし」も、利用の入口を見るために残します。

ここから、実際に対話した5件を分母にした結果の割合を計算します。L05を除く対象IDを列挙しておけば、あとから同じ集計を再現できます。

入力8行 → 重複1行を除外 → 一意の7件 → テスト1件を除外 → 本番6件 → 対話なし1件を別枠へ → 対話した5件

この矢印は、今回の教材で使う集計手順です。各製品の標準ダッシュボードが、必ず同じ手順や分母で計算するという説明ではありません。

「確認済み解決40％」は、解決済み60％の内訳です。両方を足して100％に近づける項目ではありません。結果の全体を確かめるなら、解決済み60％＋転送20％＋途中終了20％＝100％と見ます。

分母を本番全体の6件にする別の指標なら、解決済みは3÷6＝50％です。60％と50％は、どちらかが単純な計算間違いなのではなく、対象が違います。報告書には「対話した5件中3件」と件数を添えてください。

解決済みでも、回答の正しさは別に確かめる

Copilot Studioの対話エージェントを監視する公式資料は、解決済みを二つに分けています。一つは利用者が成功を確認したもの、もう一つは利用者の確認なしにエージェントのロジックで完了としたものです。暗黙解決の扱いは、クラシックと生成AIの構成で異なります。

この例でも、L02は利用者の確認がない暗黙解決です。「解決済み3件」を「3件とも正しい回答を確認した」とは読み替えません。 L01やL07に利用者の確認があっても、業務担当者が根拠資料との一致まで検査した証拠とは別です。

利用者評価も同じ分母ではありません。この教材で評価を付けたのはL01とL07の2件なので、平均は（5＋3）÷2＝4.0です。未回答を0点に変えて6件で割った約1.33は、回答者による平均評価ではありません。「評価平均4.0、回答2件／本番6件」と記載します。2件だけの平均を、全利用者が満足したという結論にしないでください。

反対に、転送されたL03も、それだけで失敗とは限りません。本人確認や個別の判断を人へ引き継ぐ運用なら、転送は予定どおりの結果かもしれません。減らすべき転送と、守るべき転送を分けます。

ログの欠け方にも注意します。Microsoftのセッションデータ資料では、ChatTranscriptに表示するボット応答を1応答あたり512文字までとしています。また、SharePointを知識ソースにした回答が、REDACTEDとして伏せられる場合も説明しています。記録に本文がないことと、利用者へ回答しなかったことは同じではありません。

本稿では、ログに含まれない部分を推測で埋めません。必要な閲覧権限を持つ管理者へ、確認できる範囲を問い合わせます。回答全文が確認できなければ、その会話の正確性は「未確認」のまま残してください。取得できる日付の範囲や保存条件は、対象環境の現行設定でも確認します。

数字を上げる前に、直す会話を一つ選ぶ

集計の次は、結果を一つずつ原因へつなぎます。ここで、L02のログを権限のある担当者が読めたと仮定します。利用者は「添付する様式の場所は？」と質問しましたが、回答は保存先を示さず「申請手順をご確認ください」で終わっていた、という架空の状況です。

この場合、解決率の分母を変えるより先に、様式の置き場所が回答の根拠へ入っているかを調べます。資料に場所がなければ、内容の管理者へ追加を頼みます。資料にはあるのに検索で取れないなら、検索対象や文書の構造を確認します。根拠は取れているのに案内されないなら、回答の作り方を点検します。

これは修正先を選ぶための手順例です。期間ごとの利用者や質問が変わるため、解決率が上がったことだけで、修正の効果を証明したとはしません。まずは元の質問へ必要な案内を返せるかを確かめ、それから同条件の集計を比較します。

分析表へ会話本文を丸ごと複製する必要もありません。分析する権限と目的を確かめ、共有用にはセッションID、分類、確認結果など必要な項目を残します。個人情報や機密が含まれる原文は、許可された場所と閲覧範囲で扱ってください。外部AIへ実ログを送る作業は、この記事の手順には含めていません。

最初の報告は「解決率60％」の一行で終えず、「対話した5件中、確認済み解決2件・暗黙解決1件。L02の様式案内を確認する」と書きます。分母と未確認箇所が分かれば、数字を整えるための集計から、次に直す会話を決める分析へ進めます。

参照資料

• Microsoft Learn：監視の概要。分析セッション、UTC表示、テストパネルの活動の扱いを確認。取得メタデータのms.dateは2026年6月1日、updated_atは2026年10月14日。
• Microsoft Learn：対話エージェントを監視する。確認済み／暗黙の解決、転送、評価などの定義を確認。ms.dateは2026年6月1日、updated_atは2026年10月14日。
• Microsoft Learn：Copilot Studioからダウンロードしたセッションデータについて。SessionID、SessionOutcome、本文の省略と取得の前提を確認。ms.dateは2026年8月27日、updated_atは2026年10月16日。いずれも2026年10月17日確認。