音声解析の精度向上に向けた試行錯誤とオーケストレーション層による解決

はじめに

弊社では商談音声を自動解析し、内製CRMに登録するシステムを運用しています。
本記事では、音声解析の精度向上のために試行錯誤した内容と、最終的に効果があった施策について共有します。

TL;DR（結論）

• オーケストレーション層の導入: 動的なモデル変更（Max token制限への対応）と解析ステップの分割
• 文脈の維持: 過度な前処理を廃止し、生データの活用による文脈維持
• AI音声解析の成功の担保: フォールバック機構による精度と確実性の両立

背景

システム概要

商談音声を処理するために、当初は以下のフローを構築

制約条件

• アップロードから音声解析完了通知までの時間を20分以内に完了
• CRMに登録できるJSON形式での出力
• 音声解析の100%成功（失敗は許容されない）

課題

音声解析の精度低下による主な問題点

• 修正工数の増大: 営業担当者による手作業での修正時間の増大
• CRMデータの品質低下: 修正漏れによる不正確な情報の蓄積
• システム利用率の低下: システムへの不信感による利用の回避

❌ 効果がなかった施策

❌ 1. 文字起こしモデルを日本語特化モデルに変更

仮説:
日本語特化モデルによる文字起こし精度の向上

検証内容:
既存の whisper large-v3-turbo と日本語特化モデル Kotoba-Whisper v2.2 の比較
Whisper側も言語を日本語（language='ja'）に指定し、同一音声に対する文字起こしの精度を比較

結果:
既存の whisper large-v3-turbo の方が高精度

Geminiによる判定において、日本語設定の whisper large-v3-turbo の方がハルシネーションや誤認識が少ない
特化モデルの強みよりも、Largeモデルの基礎性能の高さが優位に働いた結果と推測

❌ 2. ffmpegを用いたノイズ除去と沈黙除去

仮説:
ノイズ・沈黙除去による認識精度の向上およびハルシネーションの低減

検証内容:
ffmpegのオーディオフィルターによる周波数カットと無音除去処理の追加

ffmpeg -i input.m4a \
  -af "highpass=f=80,lowpass=f=8000,silenceremove=stop_periods=-1:stop_duration=1:stop_threshold=-35dB" \
  -ar 16000 -ac 1 -c:a pcm_s16le output.wav

• highpass / lowpass: 人の声の周波数帯域以外（ノイズ）のカット
• silenceremove: 1秒以上続く-35dB以下の無音区間の削除

結果:
未加工（既存フロー）の方が高精度

精度低下の主因は、一律の閾値適用による必要な音声情報の欠落

• 必要な音声の消失: 録音環境の差異を考慮しない一律処理（-35dB）により、語尾や相槌など微細な音声まで除去

Whisper等のモデルにおいては、過度な加工よりも生データの活用が音声特徴（文脈）維持に有効と判明

❌ 3. 話者分離 (Diarization)

仮説:
話者分離による発言者区別と文脈理解の促進、解析精度の向上

検証内容:
約80分の音声に対し、pyannote.audioのspeaker-diarizationパイプラインをGPU環境にて検証

結果:

• 話者分離処理: 約4分
• 文字起こし処理: 約17分
• 合計処理時間: 約21分
• GPU使用量: 2.4GB → 8GB（約3.3倍に増加）

精度向上は見込めるものの、コストと速度の観点から採用見送り

実運用導入における課題点

1. インフラコストの増大: GPUメモリ使用量が約3.3倍（2.4GB→8GB）となり許容範囲を超過
2. 処理速度の要件未達: 合計処理時間が約21分となり、「20分以内」の制限時間を超過

精度向上に対しコストと時間の負荷が過大であり、現在のビジネスフェーズには不適合と判断

⚠️ 4. 単純なモデル変更

仮説:
高性能モデル採用による文脈理解力および精度の向上

検証内容:
解析モデルを gemini-2.5-flash-lite へ変更して検証

結果:
精度は向上するも、解析失敗（エラー）ケースが発生

「解析成功率100%」の要件未達要因

1. 出力トークン上限への到達: 生成能力の高さゆえの出力冗長化（詳細な考察など）、および長時間商談時のレスポンス途絶
2. JSON形式の破損: レスポンス途絶によるJSON構造破壊、パースエラーの発生

精度は高いものの、ビジネス要件（確実性）担保の困難さにより、単純な置き換えを断念

✅ 効果があった施策

モデル変更の有効性確認に伴う、オーケストレーション層の導入
以下の仕組みにより、精度向上と処理の確実性を同時実現

1. オーケストレーション層による動的モデル変更

上位モデル（gemini-2.5-flash-lite）の高精度と、ビジネス要件である「解析成功率100%」の両立

課題:
上位モデルによる「出力トークン上限」起因のエラー発生と、それによる完全性の欠如

解決策:
エラー発生時の自動モデル切り替え（フォールバック）フローの構築

導入効果:

• 精度と安定性の両立: 通常時の高精度解析と異常時の確実なリカバリ
• 長時間の商談への対応: トークン消費の激しい長時間商談における処理完了の担保
• ビジネス要件の充足: 「成功率100%」という絶対要件のクリア

2. オーケストレーション層による解析ステップの分割

オーケストレーション層導入による解析プロセスの柔軟な分割・制御

課題:
解析とJSON化の結合による保守性の低さと、エラー切り分けの困難さ

解決策:
オーケストレーション層による「解析処理」と「データ整形（JSON化）」の分離

導入効果:

• 保守性の向上: 解析ロジックとデータ構造（JSON）の独立管理
• 影響範囲の極小化: JSON仕様変更時の解析ロジックへの影響排除
• 障害対応の迅速化: エラー発生箇所（解析 or 整形）の特定容易化
• 最適モデルの適用: 各ステップに応じた最適モデルの選択

3. 過度な前処理（フィラー除去）の廃止

課題:
フィラー除去（「えー」「あのー」等の削除）を目的に導入した sumy が、実際には過度な情報の圧縮を引き起こしていた問題
単なる不要語句の削除にとどまらず、文脈維持に必要な重要情報まで欠落

解決策:
外部ライブラリ（sumy）による前処理の完全撤廃および、Whisperが出力した生データの活用

導入効果:

• 相槌やニュアンスの理解: 「なるほど」「はい」といった相槌や言い淀みが残ることで、AIが会話の温度感や意図を正確に把握
• 解析精度の改善: 必要な情報が欠落しないことによる、回答品質の向上

最終的なシステム構成

sumy排除およびオーケストレーション層（フォールバック）の実装

まとめ

1. AIには「生データ」が最適:
   人間視点の「きれいなデータ」は文脈を削ぎ落とすリスクがあり、未加工データの活用が精度向上につながる
2. 実運用には「フォールバック」が不可欠:
   最新モデルの不安定さをアーキテクチャでカバーすることで、ビジネス要件を満たすことができる
3. 責務分離によるシステムの安定化:
   解析と整形を分離することで、各工程の最適化とデバッグの容易性を実現

補足

本記事の改善策は特定業務（商談音声解析）特化のため、他ユースケースでは検証を推奨
音声の長文特性に対し、AI（Gemini）を用いた精度比較を実施（データ使用はオプトアウト済み）