GeminiでクラウドPBX通話データを分析する

結論から言うと： クラウドPBXから3か月分の通話明細（CDR）をエクスポートし、営業時間・タイムゾーン・祝日カレンダーをコンテキストとしてGeminiに渡したうえで、月次平均ではなく「現地時間の時間帯×曜日」ごとの応答率と放棄率を出させます。そこで浮かび上がるのは、たいていの場合、電話システムの問題ではなくカバー時間の問題です。つまりこれは調達の判断ではなく、シフトの判断だということです。

オペレーション責任者に「うちは週にどれくらい電話を取り逃がしていますか」と聞くと、返ってくるのは肩をすくめる仕草か、前四半期のレポートでうろ覚えに見た数字くらいでしょう。「受付の人手は足りていますか」と聞けば、根拠のない自信に満ちた答えが返ってきます。どちらの問いにも正確な答えがあり、その答えはずっと電話システムの中に置かれたままになっています。

本記事は、それを取り出す手順です。クラウドPBXから何をエクスポートするか、数字が意味を持つようにGeminiへどう指示するか、実際の分析はどう進むか——そして多くの記事が飛ばす部分、つまり顧客の電話番号がぎっしり詰まったファイルをエクスポートした瞬間に生まれるプライバシー上のリスクをどう扱うか、です。

電話システムがすでに知っていて、誰も見ていない情報

クラウドPBXは、通過するすべての通話について通話明細記録（CDR）を書き出しています。一般的なレコードには、タイムスタンプ、発着信の方向、発信・着信番号、着信を受けたキューまたは内線、呼び出し時間、通話時間、結果コード（応答、放棄、留守番電話、話中、失敗）、多くの場合は誰が応答したかまで含まれます。中小企業なら3か月分でおおむね数千件から数万件です。

このサイズが、いちばん扱いにくい中間地帯です。表計算ソフトで目視して意味のあることを読み取るには多すぎ、BIプロジェクトやデータウェアハウス、ワークフォース管理プラットフォームを立てるには少なすぎます。結果として誰も見ないまま、電話のカバー体制についての議論は逸話のレベルにとどまります——直近でいちばん強く苦情を言った人の話が通ってしまうのです。

その一方で、マネージドクラウドPBXプラットフォームの標準ダッシュボードは「先月の応答率は94%でした」と喜んで表示します。この数字は正しいのですが、ほとんど役に立ちません。欠けている6%は月全体に均等にばらまかれてはいないからです。特定の時間帯、特定の曜日、特定のキュー、そしてたいていは特定の市場からの着信に集中しています。その集中を見つけることが、この作業のすべてです。

クラウドPBXから使える通話データを取り出す

ほぼすべてのホスト型PBXは、管理コンソールからCDRをCSVでエクスポートでき、多くは同じデータのAPIも提供しています。認定済みのセッションボーダーコントローラー（SBC）経由でMicrosoft Teamsに統合している場合、レコードは分かれていることがよくあります。PBX側がトランク側のレグを、Teams側がクライアント側のレグを保持する形です。両方をエクスポートして通話IDで突き合わせないと、「固定電話機ではなくTeamsで応答した通話」がまるごと静かに抜け落ちます。

コンソールが一度に出せる最長の期間を指定してください。実用上の下限は3か月です。1か月では、本当のパターンなのか、たまたま悪い2週間だったのかを区別できません。1年分は扱いにくいうえ、すでに変更済みの人員配置まで含んでしまいます。

CDRエクスポート——本当に重要な項目と、判断を誤らせる項目

結果コード（disposition） は分析全体がぶら下がる項目であり、同時にプラットフォームごとの定義がもっとも不揃いな項目でもあります。何かを解釈する前に、各コードが実際に何を意味するのかベンダーのドキュメントで確認してください。
「放棄」と「不在応答」は別物です。 放棄とは、誰かが応答する前に発信者が切ってしまった通話です。一方「不在応答」は、鳴動グループ内の1台の内線が取らなかっただけで、2秒後に同僚が応答している場合が少なくありません。両方を失敗として数えると、存在しない危機を自分で作り出すことになります。
応答前の呼び出し時間 は、ファイル内でもっとも活用されていない項目です。平均応答速度は応答率よりも発信者の体験をよく表し、しかも先に動きます。人が切り始めるずっと前から、キューは呼び出し時間の形で劣化していきます。
通話時間 単体ではほとんど意味を持ちません。3分の通話は、何かが解決したなら良い通話ですが、そこに至るまでに2回転送されたのなら悪い通話です。
リピート発信はまとめる必要があります。 同じ番号が15分以内に3回かけてきたのは、3件の通話ではなく1人の不満を抱えた顧客です。まとめずに数えると、カバーがもっとも薄い時間帯でちょうど件数が水増しされます。
内線同士の通話は通常除外します。 実際の利用ではありますが顧客需要ではなく、算出するすべての比率を歪めます。

タイムゾーン、祝日、そして単純平均が問題を隠す理由

CDRのタイムスタンプは通常UTCか、何年も前に退職した誰かがテナントに設定したタイムゾーンで保存されています。顧客が日本、受付が香港、あふれ呼がシンガポールという構成であれば、現地時間に変換しない分析は、誰も気づけない形で間違ったグラフを生みます。

テナントのタイムゾーンを明示し、どの現地時間で結果がほしいのかを伝え、祝日リストも一緒に渡してください。香港・中国本土・日本・シンガポールの祝日は揃っていません。渡さなければ、ゴールデンウィークや旧正月が「原因不明の低稼働が2週間」として現れ、すべての平均値を静かに引き下げます。

実際に機能するプロンプトは地味です。CSVをアップロードし、ファイル自体が持てないコンテキストを添えます——拠点ごとの営業時間、シフトごとの受付人数、自社プラットフォームでの各結果コードの意味、祝日リスト、そして答えてほしい具体的な問いです。非常に大きなエクスポートを前提に計画を立てる前に、ファイルサイズと形式の制限についてGeminiの最新ドキュメントを確認してください。大きすぎる場合は月単位に分割して個別に分析します。

実例——3か月分のCDRから人員配置の提案まで

香港に本社、広東省に2つの工場を持ち、日本と東南アジアに顧客を抱える140人規模の製造業を例にとります。3か月で外部からの着信はおよそ11,000件。PBXのダッシュボードは応答率91%と表示しており、社内では以前から「問題ない」ということになっていました。

最初のプロンプトは意図的に狭く設定しました。現地時間の時間帯と曜日で通話をグループ化する。各グループについて着信総数、応答数、放棄数、応答または放棄までの呼び出し時間の中央値を出す。内線通話は除外する。同一番号からの15分以内の発信は1回の試行として扱う——以上です。

結果として3つのことが出てきました。1つ目は、就業日の最初の1時間が週でもっとも悪い時間帯だったことです。香港時間の08:00〜09:00に着信した通話は週の着信量のおよそ7分の1を占め、放棄率は日中平均の3倍以上でした。受付のシフトは09:00からでした。1時間先行する日本の顧客は、何年も無人のオフィスに電話をかけ続けていたことになります。

2つ目は昼休みです。12:30〜13:30の放棄率はおよそ3倍になり、呼び出し時間の中央値は40秒を超えていました。受付は名目上は輪番でカバーされており、実際にはされていませんでした。

3つ目はより小さく、より示唆的でした。17:30以降、日本語の着信が細く続いていたのです——件数は少ないものの放棄率が非常に高い。唯一のバイリンガル担当者がすでに退勤していたためです。

この3つの発見は、応答率91%という数字のどこにも現れません。

モデルに数えさせないでください。 これがこのワークフロー全体でもっとも重要な習慣です。言語モデルは数千行にわたる算術を確実にはこなせません。近似したり、サンプリングしたり、もっともらしい合計値を自信たっぷりに出したりします。そうではなく、集計そのものを書かせてください——Googleスプレッドシートの数式、ピボットの仕様、あるいは自分でCSVに対して実行できる短いPythonスクリプトです。そのうえで実行し、突き合わせます。問いの形を決めることと答えを解釈することにモデルを使い、数字そのものは決定論的な計算で出す。経営層の前に出る数字は、モデルなしでも再現できるべきです。

人員配置の問いにも同じ規律が要ります。「何人必要ですか」と聞けば、自信に満ちた当て推量が返ってきます。「処理時間の中央値4分、放棄率5%以下という目標のもとで、各時間帯に必要な時間あたり人員はいくつになるか、計算過程も示してください」と聞けば、検証でき、反論もできる算術が返ってきます。

AI支援分析 vs PBX標準レポート vs コンタクトセンタープラットフォーム

PBXの標準レポート は無料で、リアルタイムで、すでに動いています。総数、内線ごとの稼働、トランク使用率といった用途では実際に優秀です。弱いのは、時間帯×市場×キュー×結果というように問いが複数の軸をまたぐ場合です。設計者が想定した問いにしか答えられないからです。
CDRエクスポートに対するAI支援分析 は、単発の診断的な問いに対する正しい道具で、調達コストはゼロです。夜10時に誰も想定していなかった問いを立て、深夜までに根拠のある答えを得られます。制約も現実的です。リアルタイムのビューではなくスナップショットであること、誰かがエクスポート作業をする必要があること、そしてすべての数字を検証する必要があることです。
コンタクトセンタープラットフォーム（CCaaS） が買えるのは、リアルタイムのキュー管理、需要予測、遵守率トラッキング、オペレーター単位の品質評価です。電話が主要な顧客チャネルで、オペレーターが15人以上いるならライセンス費用に見合います。他の業務と兼務しながら電話を取る6人体制の受付にとっては、表計算ソフトと良い問いがあれば午後1回で診断できる課題に対して、大きな固定費を払うことになります。

誠実な順序は、先に診断し、後で買うことです。コンタクトセンタープラットフォームを購入寸前だった企業のかなりの割合が、本当の課題はシフト表だったと気づきます。

本当の答えは電話システムの問題ではない

こうした分析のほとんどで、結論は「電話システムが不十分だ」ではありません。「08:15に誰も席にいない」であり、「日本語で応対できる唯一の担当者は1つ隣のタイムゾーンにいて17:30に退勤する」であり、「あふれ呼が1日2回しか確認されない留守番電話に転送されている」です。

これらはカバー体制の判断であり、実際のレバーはそう多くありません。シフト表を動かす——費用はかからず、たいていはこれで足ります。カバー時間を延ばす——早番・遅番に費用を払うか、時間外のトラフィックをすでに24時間365日稼働している多言語ヘルプデスクに転送するかです。ルーティングを変更し、未応答の通話を留守番電話ではなく人がいる場所にあふれさせる。あるいは、その放棄率は許容できると判断する——これも完全に正当な答えです。それが事故ではなく判断である限りは。

分析は、それを判断に変えるためのものです。「電話の人手をもう少し増やしたほうがいい気がします」は予算会議で毎回負けます。「08:00台で着信の34%を失っており、その1時間は着信全体の14%を占め、その大半は日本からです」は負けません。

ここを外さない——通話データのプライバシー、録音の同意、そしてITを巻き込むタイミング

CDRのエクスポートとは、要するにタイムスタンプ付きの顧客電話番号のファイルです。香港のPDPO、シンガポールのPDPA、中国本土のPIPL、そしてGDPRのもとでは、これは個人データにあたります。番号は個人を特定し、通話パターンはその個人について何かを語るからです。AIツールに近づける前に、4つのことを決めておく必要があります。

アップロード前に仮名化する。 発信番号をハッシュ化するか下4桁を切り落とし、対応表はファイルの外に置きます。時間帯ごとの件数を数えるのに、誰がかけてきたかを知る必要はありません。この一手で、分析上のコストをほとんど払わずに露出の大半を取り除けます。
録音と文字起こしはまったく別のカテゴリとして扱う。 CDRはメタデータですが、録音はコンテンツです。アジア太平洋の多くの法域で、録音には告知または同意の義務、より長い保存期間の議論、そしてはるかに難しい越境移転の論点が伴います——特にPIPL下の中国本土由来のデータではそうです。通話録音を汎用AIツールに独断でアップロードしてよい人は誰もいません。
個人アカウントではなく法人プランを使う。 主要なAIサービスはいずれも、データの取り扱い・保持・学習利用に関する取り決めが消費者向けと法人向けで異なります。組織として該当する契約を結んでいないなら、その分析は「承認された」のではなく、単に「起きてしまった」だけです。
ファイルがその後どこに置かれるかを決める。 3か月分の顧客通話記録が社員のダウンロードフォルダや個人のクラウドドライブに残っている状態は、ノートPCの紛失をきっかけに発動する情報漏えい通知の予約にほかなりません。

ここから先、この作業は気の利いたプロンプトではなくITガバナンスになります。当社のAI+ サポートサービスは、まさにこの領域——適切なプラン層の選定、データ取り扱いルールの設定、そして仮名化を「担当者が覚えていればやる作業」ではなく標準手順にすること——を対象としています。エクスポートそのもの、APIのアクセス権、保持ポリシー、アクセス制御は、日々インフラを運用しているチームの担当です。当社のお客様の多くにとって、それはBrocentのマネージドITサポートチームです。プラットフォームの購入を決める前に自社の通話データについてセカンドオピニオンが必要でしたら、お問い合わせください。

よくある質問

通話明細はPDPO・PDPA・PIPLのもとで個人データにあたりますか。

一般的には該当します。電話番号は識別子であり、CDRはそれを時刻・通話時間・着信部署と結び付けます。3つの制度いずれもこれを個人データとして扱います。分析前に番号を仮名化すればリスクは大幅に下がり、件数や時間帯の分析には何の影響もありません。

通話録音をAIで分析するのに同意は必要ですか。

録音はCDRより明確に高いハードルで、答えは法域と、録音時に発信者へ何を伝えたかによって変わります。録音アナウンスが「品質向上と研修のため」しか述べていなければ、その録音を第三者のAIサービスに渡すことは表明した目的の範囲を超える可能性があります。これは始めた後ではなく、始める前に確認してください。

「放棄」と「不在応答」の違いは何ですか。

放棄は、応答される前に発信者が切った通話で、発信者の我慢が尽きたことの直接的な指標です。「不在応答」は多くのプラットフォームで特定の内線が応答しなかったことを指し、鳴動グループでは他の誰かが取るため日常的に発生します。顧客体験にとって重要なのは放棄の数で、不在応答はしばしば単なるノイズです。

これで実際に電話対応の必要人数がわかりますか。

需要がカバーを上回るタイミングを正確に示せます。それがその判断の入力になります。ただし、それ単体で説明可能な人員数を出すことはできません。処理時間やエスカレーション率、その担当者が他に何をしているかを知らずに人員数を出せると主張するツールは、推測しています。分析でギャップの大きさを測り、そこに自社のサービス目標を当ててください。

Microsoft Teams電話でも使えますか。

使えますが、注意点が1つあります。認定SBC経由でPBXをTeamsに統合している場合、通話記録は2つのシステムに分かれていることがよくあります。両方を取得して結合しないと、応答率は固定電話機に有利な方向へずれます。単一のエクスポートを信頼する前に、自社の構成が何をどこに書いているかを確認してください。