Teams PhoneのCall Queue履歴レポートで、期間を広げたときに一部の通話が表示されない場合は、Power BIレポートテンプレートの15万行上限を最初に確認してください。各レポートタブは最大150,000行までしか取得せず、上限を超えて通話データが除外されても警告やエラーは表示されません。
基本的な対処は、レポートの日付範囲を短くすることです。それでも必要な通話を取得できない場合は、Power Query EditorでReportRowCountLimitを変更します。キューや担当者を画面上のフィルターで絞るだけでは、15万行上限を回避できない点にも注意が必要です。(Microsoft Learn)
Teams Call Queue履歴レポートで通話が欠落する原因
Microsoftが提供するTeams Phoneの履歴レポートでは、Call Queue、Auto Attendant、エージェントなどの通話状況をPower BIで分析できます。
問題になるのが、レポートタブごとに設定されている150,000行の取得上限です。選択した期間内のデータ量が上限を超えると、レポートにはすべての通話が表示されなくなる可能性があります。
さらに厄介なのは、次のような通知が表示されないことです。
- 行数上限に達したという警告
- 一部の通話が除外されたというメッセージ
- 取得できなかった行数
- 欠落した日付やキューの情報
レポートの更新が正常終了していても、表示内容が完全とは限りません。月次レポートや全社集計で期間を長く設定している場合は、特に注意が必要です。(Microsoft Learn)
15万行はレポート全体ではなくタブごとの上限
150,000行の制限は、Power BIファイル全体の合計ではなく、各レポートタブに適用されます。
そのため、Call Queueのタブで上限に達していても、Auto Attendantのタブは問題なく表示されることがあります。逆に、あるタブだけ集計値が不自然に少なくなっている場合は、そのタブが上限に達している可能性があります。
また、15万行を「15万件のユニーク着信」と単純に読み替えることはできません。レポートレベルや通話経路、Auto AttendantからCall Queueへの転送などによって、同じ一連の通話が複数の分析対象に現れることがあるためです。
上限判定では、通話件数ではなく取得されるレコード行数を意識する必要があります。
キューを選択しても取得行数は減らない
Teams Phone履歴レポートでは、選択した日付範囲について、利用者が参照を許可されているTeams Phone Agent、Auto Attendant、Call Queue、エージェントのデータを取得します。
重要なのは、画面上で特定のCall Queueを選択していても、データ取得時には権限のある対象全体が読み込まれる点です。キューやエージェントによる絞り込みは、取得後にPower BI内でローカルに行われます。(Microsoft Learn)
たとえば、分析担当者が次の3つのキューを参照できるとします。
| Call Queue | 1日あたりの取得行数 |
|---|---|
| 問い合わせ窓口 | 8,000行 |
| 予約受付 | 7,000行 |
| サポート窓口 | 10,000行 |
| 合計 | 25,000行 |
画面上では「問い合わせ窓口」だけを選択していても、7日分の取得対象は概算で次のようになります。
25,000行 × 7日 = 175,000行
表示したいキューだけなら56,000行ですが、実際の取得対象は175,000行になるため、150,000行上限を超えます。
この場合、キューのスライサーを操作しても解決しません。日付範囲を短くするか、取得上限そのものを変更する必要があります。
本当に15万行上限が原因か確認する方法
通話が見つからない原因は、15万行上限だけではありません。データ反映の遅延、アクセス権限、リソースアカウントの選択、ネストされた通話フローなども確認する必要があります。
まずは、次の観点で切り分けます。
| 現象 | 疑われる原因 | 確認方法 |
|---|---|---|
| 期間を短くすると通話件数が増える | 15万行上限 | 月単位を週単位、日単位に分割する |
| 月間集計より週別集計の合計が多い | 15万行上限 | 同じ条件で期間だけを分割して比較する |
| 直近数時間の通話だけ表示されない | データ反映の遅延 | 数時間後に再更新する |
| 特定のキューだけ常に表示されない | 権限または対象選択 | リソースアカウントとVoice Applications Policyを確認する |
| ネストされたキューの件数が合わない | 転送経路や表示名の違い | 転送元のリソースアカウントも確認する |
| 期間を短くしても一部通話がない | テレメトリ未受信など | 他のログや運用記録と照合する |
期間を分割して合計値を比較する
15万行上限を確認する実務的な方法は、同じ期間を複数に分割して集計結果を比較することです。
たとえば、7月1日から7月31日までの月間レポートに120,000件と表示されている場合、同じ条件で次のように分割します。
- 7月1日から7月7日
- 7月8日から7月14日
- 7月15日から7月21日
- 7月22日から7月28日
- 7月29日から7月31日
分割後の合計が月間レポートの値を上回る場合は、月間取得時に行数上限へ到達した可能性が高いと判断できます。
比較するときは、次の条件をそろえてください。
- レポートレベルをそろえる
- Call Queueやエージェントのフィルターをそろえる
- 同じPower BIファイルを使う
- 更新タイミングをそろえる
- 当日ではなく、通話データの反映が落ち着いた過去日を使う
Teams Phone履歴データは通常、通話終了後30分程度で利用可能になりますが、反映まで数時間かかる場合があります。また、新しいデータを表示するにはレポートの更新が必要です。(Microsoft Learn)
15万行上限への対処方法を選ぶ
対処方法は、レポートの目的によって使い分けます。
| 利用目的 | 適した対処 | 理由 |
|---|---|---|
| 日次・週次の運用確認 | 日付範囲を短くする | 処理負荷が小さく、最も確実 |
| 月次・年次の傾向分析 | Per Dayを利用する | 取得行数を大幅に減らせる |
| 個別通話の詳細調査 | ReportRowCountLimitを増やす | Per Callの明細を維持できる |
| 一部キューだけを分析 | 権限範囲を限定する | 不要なキューのデータ取得を減らせる |
| 上限変更後にタイムアウトする | 期間分割またはReportExecutionMinutes変更 | 実行時間不足に対応できる |
原則として、最初から上限値を大幅に増やすのではなく、日付範囲の短縮を先に試すのが安全です。
対処法1：日付範囲を短くする
日付範囲の短縮は、Microsoftが最初の対処として案内している方法です。レポートの構造を変更しないため、Power BI Desktopの性能やPower BI Serviceの更新時間への影響も抑えられます。(Microsoft Learn)
取得可能な日数を概算する
1日あたりの取得行数が分かる場合は、次の式で安全に扱える期間を概算できます。
取得可能日数の目安 = 150,000 ÷ 1日あたりの取得行数
たとえば、権限のあるすべての対象を合計して1日30,000行になる場合は、次の計算になります。
150,000 ÷ 30,000 = 5日
上限ぎりぎりでは日ごとの増減に対応できないため、実際には3日から4日程度に区切るほうが安全です。
重要なのは、画面に表示している1つのキューではなく、その利用者が参照できる対象全体の取得行数で計算することです。
明細が不要ならPer Dayを使う
個々の通話明細が不要で、日別の着信数、応答数、放棄呼数などの傾向だけを確認したい場合は、Per Dayレポートが適しています。
| レポートレベル | 取得内容 | 向いている用途 |
|---|---|---|
Per Call | 個々の通話レコード | 通話詳細、エージェント対応の調査 |
Per Day | 対象ごとの日次集計 | 月次傾向、長期間の推移確認 |
Per Dayは、Auto Attendant、Call Queue、エージェントごとに日単位の集計レコードを取得するため、Per Callよりも行数を抑えられます。
ただし、Per Dayの日付境界はUTCの00:00から23:59:59です。利用者が指定したUTCオフセットは反映されません。日本時間では、おおむね午前9時から翌日午前8時59分59秒までが1日として集計されるため、日本時間の暦日と一致しない点に注意してください。(Microsoft Learn)
対処法2：ReportRowCountLimitを増やす
日付範囲を短くできない場合や、長期間の個別通話明細が必要な場合は、Power Query EditorでReportRowCountLimitを変更します。
変更前には、元のPower BIファイルを複製してバックアップを残してください。
ReportRowCountLimitの変更手順
- Teams Phone履歴レポートをPower BI Desktopで開きます。
- リボンから「データの変換（Transform data）」を選択します。
- Power Query Editorの左側で
ReportRowCountLimitを選択します。 - 右側に表示される現在の値を、必要な行数より大きい値に変更します。
- Power Query Editorを閉じます。
- 変更の適用を求められたら「はい」を選択します。
- レポートが更新されたことを確認します。
- 分割期間の合計と比較し、必要なデータが取得できたか検証します。
- Power BIファイルを保存します。
Microsoftのドキュメントでは、取得行数自体に明示された上限はないとされています。ただし、行数を増やすほど実行時間と応答時間が長くなり、Power BI Desktopの性能にも影響します。(Microsoft Learn)
設定値は必要量から決める
設定値は、単に大きくすればよいわけではありません。
たとえば、1日25,000行を7日間取得する場合は、概算で175,000行必要です。この場合は、200,000行または250,000行程度から検証を始める方法があります。
一方、1日25,000行を30日間取得すると、概算で750,000行になります。この規模では、上限を一気に100万行まで増やすより、次の運用を検討したほうが安定します。
- 1週間単位で期間を分割する
- 長期傾向は
Per Dayで確認する - 個別調査が必要な期間だけ
Per Callを使う - 分析担当者の参照対象を必要なキューに限定する
ReportRowCountLimitの変更値は、Microsoftが推奨する固定値ではありません。テナントの通話量、PC性能、更新頻度に合わせて段階的に増やしてください。
Power BI Serviceを利用している場合
Power BI Serviceでレポートを共有している場合は、Power BI Desktop側で設定を変更して保存した後、対象のワークスペースへ再発行します。
Power BI Desktopファイルを再発行すると、Power BI Service上のセマンティックモデルは、更新後のモデルに置き換えられます。既存レポートやダッシュボードへの影響を確認したうえで実施してください。(Microsoft Learn)
再発行後は、次の項目を確認します。
ReportRowCountLimitの変更が反映されているか- データソースの資格情報が有効か
- スケジュール更新が正常終了するか
- 更新時間が大幅に伸びていないか
- 分割期間との比較で欠落が解消したか
上限を増やしたらタイムアウトする場合
ReportRowCountLimitを増やすと、取得対象が増えるため、レポートが制限時間内に完了しないことがあります。
この場合は、Power Query EditorにあるReportExecutionMinutesを変更できます。
ReportExecutionMinutesの変更手順
- Power BI Desktopで「データの変換」を選択します。
- Power Query Editorの左側で
ReportExecutionMinutesを選択します。 - 右側の値を、現在より大きい値に変更します。
- Power Query Editorを閉じます。
- 変更を適用します。
- レポートを保存します。
Microsoftも、取得行数を増やすと実行時間が長くなり、データが返る前にタイムアウトする可能性があると案内しています。(Microsoft Learn)
ただし、ReportExecutionMinutesの引き上げは最初の対処ではありません。次の順序で調整してください。
- 日付範囲を短くする
- 不要な参照対象を減らす
Per Dayで代替できないか検討するReportRowCountLimitを必要最小限だけ増やす- それでもタイムアウトする場合に
ReportExecutionMinutesを増やす
実行時間だけを大幅に延ばすと、問題のある設計をそのまま維持することになります。
権限範囲を見直して取得行数を減らす
レポートタブは、利用者が参照を許可されているすべての対象についてデータを取得します。そのため、分析担当者が必要以上に広いアクセス権を持っていると、15万行上限へ到達しやすくなります。
特定部門のキューだけを分析する担当者には、Voice Applications PolicyとAuthorized usersを使い、対象のAuto AttendantやCall Queueを限定する方法があります。
Microsoftも、履歴レポートへのアクセス制御にはVoice Applications Policyを推奨しています。CQDアクセスロールとVoice Applications Policyの両方が割り当てられている場合はCQDロールが優先され、すべての対象を参照できる状態になることがあります。(Microsoft Learn)
権限を見直す際は、レポート性能だけでなく、最小権限の原則も考慮してください。
通話欠落を防ぐ実務的なレポート設計
大量のTeams Phone通話を継続的に分析する場合は、1つのレポートで長期傾向と個別明細を同時に扱おうとしないほうが安定します。
長期分析用と詳細調査用を分ける
次の2種類に分けると、15万行上限へ対処しやすくなります。
| レポート | レベル | 期間 | 用途 |
|---|---|---|---|
| 長期傾向レポート | Per Day | 月単位・年単位 | 着信傾向、応答率、放棄呼の推移 |
| 詳細調査レポート | Per Call | 日単位・週単位 | 個別通話、エージェント対応、異常調査 |
長期分析では集計データを使い、個別通話が必要になったときだけ対象期間を絞って詳細レポートを開く構成です。
月次レポートは分割検証を行う
月次レポートを作成する場合は、月間値だけでなく週別または日別の合計も確認します。
特に通話量が増加している組織では、前月まで問題がなかった設定でも、当月から15万行を超えることがあります。ReportRowCountLimitを一度変更して終わりにせず、定期的に次の項目を記録しておくと異常を発見しやすくなります。
- 1日あたりの概算取得行数
- レポート対象期間
ReportRowCountLimitの設定値- 更新にかかった時間
- 月間値と分割集計値の差
- Power BIテンプレートのバージョン
よくある誤った対処
| 誤った対処 | 問題点 | 正しい対応 |
|---|---|---|
| キューのフィルターだけを変更する | 取得後のローカル絞り込みなので行数が減らない | 日付範囲または権限範囲を変更する |
| 更新成功を完全性の証明と考える | 上限超過時も通知されない | 期間分割した合計と比較する |
| 最初から数百万行に設定する | 更新遅延やタイムアウトを招く | 必要量を見積もり段階的に増やす |
Per DayとPer Callをそのまま比較する | 集計粒度と日付境界が異なる | 同じレポートレベルで比較する |
| 当日のデータだけで欠落を判断する | データ反映に時間がかかることがある | 過去の確定期間で確認する |
| Teams Phone履歴レポートを監査記録として使う | 完全性が保証された監査ログではない | 必要に応じて別の記録手段を用意する |
Teams Phone履歴レポートは診断テレメトリを基にしており、ネットワーク障害やプロキシ設定などによって完全なテレメトリが届かない場合があります。このため、Microsoftは監査、コンプライアンス、給与計算に利用するシナリオをサポートしていません。(Microsoft Learn)
欠落を防ぐために今すぐ確認すること
Teams Call Queue履歴レポートで通話が欠落しているように見える場合は、次の順序で対応します。
- レポートを更新し、直近データの反映遅延ではないことを確認する
- 月単位の期間を週単位または日単位に分割する
- 分割後の合計と長期間レポートの値を比較する
- 長期傾向だけなら
Per Dayへ切り替える - 個別通話が必要なら
ReportRowCountLimitを必要最小限だけ増やす - タイムアウトする場合は期間を再分割し、必要に応じて
ReportExecutionMinutesを調整する - Power BI Serviceを利用している場合は再発行後の更新結果を確認する
- 分析担当者の権限範囲が広すぎないか見直す
特に重要なのは、警告がないから完全なレポートとは限らないことと、画面上でCall Queueを絞っても取得行数は減らないことです。
まず日付範囲を短くして分割集計を行い、そのうえで本当に必要な場合だけReportRowCountLimitを増やす運用にすると、通話欠落とPower BIの性能低下を両方防ぎやすくなります。
コメント