こんにちは、BIGLOBEの松村です。
私たちBIGLOBEは、インターネットサービスプロバイダーとして、日々多くのお客さまと接点を持っています。その中で最も重要なのが、お客さまから寄せられる「生の声」です。しかし、電話やメール、メッセージなど、様々なチャネルに分散したお客さまの声を一つひとつ拾い上げ、サービス改善に繋げることには大きな課題がありました。
「お客さまの本当の気持ちを、もっと深く理解したい」
「データに基づいた客観的な事実で、サービスを改善したい」
そんな想いから、私たちはGoogle Cloudの生成AI「Gemini」を活用した 「お客さまの声・感情を可視化するシステム」 を構築しました。
本記事では、このシステムがどんな技術を使って生まれたのか、そして2025年3月の導入後に社内でどのような変化をもたらしたのか、そのリアルな道のりをご紹介します。
また、本記事内容は2025年8月5日～8月6日に開催されたGoogle Cloud Next Tokyo で発表した内容になります。
01. 見過ごされていた「お客さまの声」
プロジェクト発足前、私たちは3つの大きな課題に直面していました。
- 外部調査で明らかになったCX（顧客体験）評価の低迷
- 膨大な量に埋もれ、見過ごされていたお客さまの声
- 部門ごとに情報が分断される、縦割り・サイロ化された組織構造
外部調査でCX評価が思わしくないことをうけ、私たちはまず、お客さまがサービスを認知してから利用、時には残念ながら解約に至るまでの一連の流れを「カスタマージャーニー」として可視化することから始めました。しかし、この取り組みによって、部門が縦割りになっており、サービス全体を俯瞰して見ている担当者が誰もいないという組織的な課題が浮き彫りになりました。各部門が協力してジャーニーマップを作成した結果、各フェーズで多数のお客さまの「痛点（ペインポイント）」が存在することが判明したのです。しかし、その声はあまりにも膨大で、手作業では集計・分析が追いつきません。結果として、どの痛点がより重要なのか優先順位をつけられず、多くのお客さまの声が見過ごされている状況でした。
そこで私たちは、AIによって膨大な量の音声データを自動でテキスト化・分析し、 応対品質の向上 と サービス改善の両輪でCX向上 を目指すことにしました。オペレーター一人ひとりの対応を客観的に評価すると同時に、これまで見過ごされてきた重要な「痛点」を定量的に把握することで、データに基づいた具体的なアクションに繋げるため、新たなシステムの開発をスタートさせました。
02. Geminiが可能にした「声の感情分析」と、その技術的裏側
このシステムの心臓部となるのが、Google Cloudの生成AI「Gemini」です。従来の音声認識サービスが抱えていた「話者特定の難しさ」「感情分析の不可」「高コスト」といった課題を、Geminiは解決してくれました。
特に画期的だったのは、 音声データを直接入力することで、テキスト化された内容だけでなく、声の抑揚やトーンから感情を分析できる 点です。これにより、私たちは従来のサービスと比較して 利用コストを約50%〜90%削減 しつつ、 音声認識成功率99% という高い精度を実現しました。
システムアーキテクチャ：ニアリアルタイムな音声分析パイプライン
本システムは、以下のGoogle Cloudサービス群で構成されており、音声データがアップロードされてから数分で分析結果が可視化される、ニアリアルタイムなデータ処理パイプラインを構築しています。
- [入力] Cloud Storage: コールセンターシステムから出力された通話音声データが、通話終了の後、特定のバケットにアップロードされます。
- [処理起動] Pub/Sub & Cloud Run: Cloud StorageへのファイルアップロードをイベントトリガーとしてPub/Subがメッセージを発行。これをサブスクライブしているCloud Runが起動し、音声ファイルごとの分析処理を開始します。このイベントドリブンなアーキテクチャにより、サーバーレスで効率的な処理実行が可能になっています。
- [AI分析] Vertex AI (Gemini API): Cloud Runのプログラムが、音声データをVertex AIのGeminiモデルに送信し、後述する3つの主要な分析（①文字起こし・感情分析、②応対品質採点、③カテゴリ分類）を実行します。
- [データ格納] BigQuery: Geminiから返却されたJSON形式の分析結果（発話ごとのテキスト、話者、感情スコア、品質評価、カテゴリなど）は、構造化データとしてBigQueryのテーブルに格納されます。
- [可視化] Looker / Looker Studio: 利用者は、BigQueryに接続されたLookerやLooker Studioのダッシュボードを通じて、常に最新の分析結果をインタラクティブに確認できます。
- [監視] Google Chat: 処理中にエラーが発生した場合は、その内容が即座に開発者向けのGoogle Chatスペースに通知され、迅速な対応を可能にしています。
技術的挑戦と3つの工夫
開発においては、特に「精度」と「コスト」のトレードオフをいかに最適化するかが大きな挑戦でした。ここでは、その中心となった3つの技術的ポイントを深掘りします。
技術ポイント①：精度とコストを両立する、階層的な音声認識戦略
平均10分、長いものでは1時間を超える通話音声を、高性能なモデルで一度に処理するのはコスト的に非現実的です。そこで私たちは、性能とコストが異なるモデルを組み合わせる階層的なアプローチを採用しました。
- 1次処理 (コスト重視): まず、低コストで高速なGemini 1.5 Flashモデルを使い、音声データ全体の大まかな文字起こしを試みます。
- 2次処理 (精度重視): 1次処理で文字起こしが不完全だった場合、より高性能なGemini 2.5 Flashモデルでリトライ処理を行います。
この2段階の構成により、全体を低コストなモデルで処理し、必要な部分だけ高性能モデルを使うことで、コストを最適化しつつ音声認識成功率99%という高い精度を実現しました。
技術ポイント②：プロンプトエンジニアリングによる、AIの採点能力の最大化
オペレーターの応対品質をAIに評価させるため、評価項目（応対マナー、共感力など）、定義、評価例などを、AIが解釈しやすい マークダウンの表形式 でプロンプトに記述しました。さらに、約4万文字にも及ぶこの詳細なプロンプトは、Vertex AIの コンテキストキャッシュ機能 を利用することで、APIコストを約75%削減することに成功しました。
技術ポイント③：生成AIと従来技術のハイブリッドアプローチ
お客さまの「痛点」を特定するカスタマージャーニー分析では、生成AIと従来の自然言語処理技術を組み合わせるハイブリッドアプローチを取りました。
- Geminiの役割 (文脈理解・分類): Gemini 2.5 Flashが対話全体の文脈を理解し、「申込手続き」「接続設定」といった大まかなカテゴリに分類します。
- 自然言語処理の役割 (集計・定量化): カテゴリ分けされたテキストデータに対し、TF-IDFなどの従来手法を用いて特徴的なキーワード（ホットワード）を抽出・集計します。
この使い分けにより、生成AIの柔軟な文脈理解能力と、従来技術の厳密な集計・定量化能力の「良いとこ取り」を実現し、実用的なインサイトの発見に繋げています。
03. 導入から6ヵ月。AIへの不信から、データドリブン文化へ
ツールの導入だけでは組織は変わりません。現場との対話を重ね、AIへの不信感を乗り越え、データに基づいた意思決定が当たり前になるまでの道のりがありました。
- ① 導入当初（〜2ヵ月）：期待と不信の交錯 「実際のお客さまの声が聞ける」という期待の一方で、「AIの分析結果は信用できない」という根強い不信感がありました。まずは障害時の影響調査など、小さな課題解決で信頼を積み重ね、価値を実感してもらうことから始めました。
- ② 転換期（2ヵ月〜）：現場への浸透と活用の模索 各担当者の課題に合わせて分析内容やLookerレポートを個別最適化するなど、現場に歩み寄ることで、「AIも使える」という認識が広まりました。社内報告書で本システムの分析結果が引用され始めるなど、変化の兆しが見え始めました。
- ③ 現在（5ヵ月〜）：データドリブン文化の定着と自走 今では、現場担当者が特別なスキルなしでAIのチューニング（お客さま満足度の高いオペレーターの特徴をAIに学習させるなど）を行える専用アプリも開発して運用しています。お客さまの声を起点としたデータドリブンな施策が各方面で次々と生まれています。AIへの不信感は消え、誰もがデータに基づいて判断し、行動する文化が根付き始めています。
まとめ
かつて私たちは、お客さまの声を十分に活かしきれていませんでした。しかし、生成AIの活用と、それを最大限に活かすための技術的工夫、そして現場との地道な対話を通じて、応対品質の向上とサービス改善のサイクルを確立し、お客さまの声を起点としたCX改善を推進するデータドリブンな文化を醸成することができました。
この取り組みはまだ始まったばかりです。これからもBIGLOBEは、データとテクノロジーの力で一人ひとりのお客さまに寄り添い、より良いサービスを提供し続けていきます。
