{% endstep %}
{% endstepper %}
***
## レポート内容の説明
### 1. データ概要
| 指標 | 説明 |
| ------- | --------------------------------- |
| 総会話数 | 日付範囲内のこのチャットプラットフォームの総会話数 |
| 分析済み | 実際にLLMが分析した会話数（「最大サンプル数」の制限を受けます） |
| サンプリング率 | 分析済み ÷ 総会話数（パーセンテージ） |
| 処理時間 | この分析タスクの開始から完了までにかかった秒数 |
{% hint style="info" %}
総会話数が「最大サンプル数」を超える場合、コストと時間を抑えるため、システムはクラスタリング後のサンプリング戦略で代表的な会話を選んで分析します。
{% endhint %}
### 2. 解決状況
中核指標「**解決率**」の計算式：
```
解決率 = (解決済み数 + 一部解決数) ÷ 分析済み数
```
* **解決済み**（緑）：Agentがユーザーの質問に完全に回答した
* **一部解決**（オレンジ）：一部の内容に回答した、または方向性は正しいが不完全だった
* **未解決**（赤）：回答できなかった、または誤った回答をした
解決率が50%を上回ると緑、下回ると赤で表示され、状態をひと目で把握できます。
### 3. パフォーマンス指標
この期間中のAgentの処理パフォーマンスを表示します。
* **総トークン使用量**：入力トークンと出力トークンの合計
* **1ターンあたりの平均トークン数**：会話の1ターンあたりに消費されるトークン数の平均
* **平均応答時間**：メッセージを受信してから返信が完了するまでの総所要時間
* **平均初回トークン時間（TTFT）**：メッセージを受信してから最初のトークンを出力し始めるまでの時間
### 4. トピッククラスターの分布
すべての会話を「意味の類似度」でクラスタリングし、横棒グラフで各トピックの出現回数と割合を表示します。外れ値の会話は「Noise / Outliers」に分類されます。
このビューで、ユーザーが最もよく質問するトピックをすばやく把握できます。
### 5. 解決／失敗原因の分布
システムは分析した会話ごとにステータスまたは失敗原因を付与し、次のように集計します。
| 原因 | 説明 |
| ----------- | ------------------------ |
| 解決済み | Agentが正しく回答できた |
| 一部解決 | 回答の方向性は正しいが不完全だった |
| ナレッジベースの不足 | ナレッジベースに関連する内容がない |
| 指示が制限的すぎる | ロール指示が妥当な返信を妨げた |
| ツールの失敗 | ツールの実行エラー、または未実行 |
| ユーザーの意図が不明確 | ユーザーのメッセージが曖昧で、意図を判断できない |
| 範囲外 | ユーザーの質問がAgentの対応範囲外だった |
| ハルシネーション応答 | AIが存在しない、または誤った情報を生成した |
| 不明 | 上記のいずれにも分類できない |
この分布は、その後の改善アクションを直接導きます。ナレッジベースの不足が多い場合は内容を追加し、指示が制限的すぎる場合が多ければロール指示を調整し、ハルシネーションが多ければナレッジベースと指示の制約を強化します。これは知識の不足を見つけるための唯一の自動化された手段です。プラットフォームは「検索結果なし」の質問を別途記録・エクスポートしないため、この分析のサンプリング結果と[会話ごとの分析](#per-conversation-analysis)を組み合わせて、ナレッジベースを補強してください。
### 6. よくある質問ランキング
件数順に並べたトピック一覧で、各トピックの**出現回数**と**解決率**を表示します。任意の行を展開すると、そのトピックの意図の例を確認でき、クラスタリングが期待どおりかをすばやく確認できます。
### 7. トピック別パフォーマンス分布
トピックごとにトークン数と所要時間を分解し、「コストが高い」または「遅い」トピックを見つけます。
* 平均の入力／出力／合計トークン数
* 平均応答時間
* 平均初回トークン時間
あるトピックのトークン数が極端に多い場合は、ロール指示やナレッジベースの検索の最適化を検討してください。所要時間が長い場合は、ツール呼び出しの回数が多いか、内容が長すぎる可能性があります。
### 8. 分析サマリー
すべての分析結果をLLMが総合して生成するMarkdown形式のレポートで、通常は次の内容を含みます。
* 全体のパフォーマンスサマリー
* 主な問題パターン
* 優先度の高い改善提案
* 具体的な調整の方向性
デフォルトでは折りたたみブロックで表示され、タイトルをクリックすると展開して読めます。
### 9. 会話ごとの分析
展開すると、分析された会話を1件ずつ確認できます。各会話には次の情報が含まれます。
* **意図**（User Intent）：ユーザーが本当に知りたかったこと
* **トピック**（Topic）：所属するトピッククラスター
* **説明**（Resolution Detail）：解決状況の詳細な説明
* **改善提案**（Suggestions）：その会話に対する具体的な最適化の方向性
***
## 詳細設定の説明
詳細設定ではサンプリングと実行の戦略を制御します。まずはデフォルト値で実行し、必要に応じて調整することをおすすめします。
| パラメータ | デフォルト値 | 説明 |
| ------------- | ------ | ------------------------------------------ |
| クラスターごとのサンプル数 | 10 | 各トピッククラスターから、LLMでの分析に回す会話の最大数 |
| 最大サンプル数 | 150 | レポート全体で分析する会話の最大数（コストの上限を制御） |
| 並列数 | 8 | LLM分析の並列処理数。大きいほど高速ですが、瞬間的なリソース消費も増えます |
| 最大取得会話数 | — | データベースから取得する会話の総数の上限 |
| 最小会話メッセージ数 | — | メッセージ数がこの値未満の会話は除外されます（意味のない短い会話の分析を避けるため） |
{% hint style="warning" %}
**コストに関する注意**：分析ではLLMのトークンクォータ（入力＋出力＋Embedding）を消費します。分析前にシステムが組織のクォータを確認し、クォータが不足している場合はタスクを作成できません。
{% endhint %}
***
## 活用シーン
### シーン1：四半期の品質レビュー
**ニーズ**：マネージャーが、前四半期のWeb Chatチャットプラットフォームの会話品質と主な問題を把握したい。
**操作**：
1. 日付範囲に前四半期を選択する
2. 最大サンプル数を300に設定する（サンプルを拡大）
3. 分析を実行し、「解決／失敗原因の分布」と「よくある質問ランキング」に注目する
4. ナレッジベースの不足、指示が制限的すぎるなど、頻度の高い原因に対する改善タスクを計画する
### シーン2：バージョン更新後の影響評価
**ニーズ**：先週ロール指示を調整したため、会話品質が改善したかを知りたい。
**操作**：
1. 「調整前の1週間」と「調整後の1週間」で、それぞれ分析レポートを2つ作成する
2. 2つのレポートの解決率と失敗原因の分布を比較する
3. 特定の失敗タイプが減少しているかを確認する
### シーン3：トピッククラスターによるナレッジベースの補完
**ニーズ**：ユーザーがよく質問する内容を見つけ、ナレッジベースを体系的に補充したい。
**操作**：
1. 直近1か月の会話を分析する
2. 「よくある質問ランキング」から、頻度が高く解決率が低いトピックを選ぶ
3. 「意図の例」を展開して、実際の聞かれ方を確認する
4. ナレッジベースに戻り、対応するFAQやドキュメントを追加する
***
## よくある質問
### Q：一部の会話が分析されないのはなぜですか？
システムは「最大サンプル数」と「最小会話メッセージ数」で絞り込み、クラスタリング後に代表的なサンプルを抽出します。総会話数が多い場合は、コストを抑えるために代表的なサンプルのみが対象になります。
### Q：解決率はどのように判定されますか？
分析用LLMは、分析した各会話を**次の9種類のステータスのいずれかに直接分類**します：解決済み、一部解決、ナレッジベースの不足、指示が制限的すぎる、ツールの失敗、ユーザーの意図が不明確、範囲外、ハルシネーション応答、不明。
解決率の計算式：
```
解決率 = (解決済み + 一部解決) ÷ 分析済みの総数
```
「解決済み」と「一部解決」はどちらも解決率の分子に含まれ、残りの7種類のステータスはすべて未解決として扱われます。
### Q：同じチャットプラットフォームに対して、同時に複数の分析を作成できますか？
できますが、**日付範囲が実行中の分析と重複してはいけません**。「このチャットプラットフォームには実行中の分析があり、日付範囲が重複しています」というエラーが表示された場合は、その分析が完了するまで待つか、別の日付範囲を選択してください。
### Q：分析にはどれくらい時間がかかりますか？
会話量、最大サンプル数、並列数、選択したモデルによって異なります。一般的に、150件のサンプリングで数分から十数分程度です。システムのデフォルトの処理制限時間は110分で、超過すると自動的に失敗としてマークされます。
### Q：分析が失敗した場合はどうすればよいですか？
ステータスが「失敗」と表示された場合は、レポート一覧の「エラーメッセージ」列を確認できます。よくあるメッセージと対処方法は次のとおりです。
* 「Analysis timed out — the worker may have crashed during processing.」処理が制限時間を超過：「最大サンプル数」を下げて分析量を減らし、再試行することをおすすめします
* 「Analysis task was never picked up by a worker.」タスクが割り当てられなかった：しばらくしてからもう一度お試しください
* その他のメッセージ：スクリーンショットを撮り、MaiAgentのサポート窓口に報告して調査を依頼してください
{% hint style="info" %}
**クォータ不足**の場合は、分析の作成時点でブロックされて通知が表示されるため、「失敗」ステータスのレポートには表示されません。
{% endhint %}
### Q：アカウントで「受信トレイ分析」が表示されないのはなぜですか？
「受信トレイ分析」は、「カスタマーサポート」のアクセス権限の下位項目です。デフォルトでは、MaiAgentのロールに「カスタマーサポート」のアクセス権限があれば、この機能も含まれます。
表示されない場合は、次のような原因が考えられます。
* お使いのMaiAgentロールに「カスタマーサポート」のアクセス権限がない
* 組織管理者が、お使いのロールに対して「受信トレイ分析」の下位権限を無効にしている
組織管理者に連絡し、[ロール権限管理](/maiagent-user-guide/ja/org/roles/role-permission.md)ページで確認・調整してもらってください。
***
## 注意事項
{% hint style="info" %}
**権限について**
* 「受信トレイ分析」は「カスタマーサポート」のアクセス権限の下位項目で、「カスタマーサポート」権限を持つすべてのMaiAgentロールにデフォルトで含まれています
* 組織管理者は[ロール権限管理](/maiagent-user-guide/ja/org/roles/role-permission.md)ページで、この機能を各ロールに開放するかどうかを調整できます
* この権限を持つメンバーは、所属する組織内のすべての分析レポートを作成・閲覧できます
{% endhint %}
{% hint style="warning" %}
**コストに関する注意**
* 分析のたびに、LLMの入力／出力トークンとEmbeddingトークンを消費します
* 作成前に、ダイアログで日付範囲と最大サンプル数を確認することをおすすめします
* 詳細設定で最大サンプル数を調整して、コストの上限を制御できます
{% endhint %}
{% hint style="danger" %}
**データ保護**
* 分析の過程で、会話内容が選択したLLMに送信されて処理されます
* 組織のデータ取り扱いポリシーに沿った、コンプライアンスに適合するモデルを選択してください
{% endhint %}
***
## 関連機能
{% hint style="info" %}
**関連情報**
* [利用分析](/maiagent-user-guide/ja/build/agent/usage.md)：Agent単位の定量KPIダッシュボード
* [受信トレイ検索機能](/maiagent-user-guide/ja/serve/daily-operations/reply/inbox-search.md)：特定の会話をすばやく検索
* [会話ビューア](/maiagent-user-guide/ja/serve/daily-operations/reply/conversation-viewer.md)：1件の会話の全体の流れを確認
* [評価インサイトレポート](/maiagent-user-guide/ja/build/agent-ops/evaluation-insights.md)：AgentOpsのバッチテスト後の自動インサイト
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.maiagent.ai/maiagent-user-guide/ja/serve/daily-operations/reply/inbox-analysis.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
