数十万時間の音声を現実的なコストでLLMにより24時間監視するまで ― ピグパーティのAIボイス監視システム

こんにちは。AIオペレーション室でバックエンドエンジニアを担当しているユンスです。今回は、ピグパーティの松岡 穂高、AIオペレーション室の岡 修平、濱口 宝とともに開発した、24時間稼働するAIボイス監視システムについてご紹介します。本記事では、アバターSNSサービス『ピグパーティ』において、従来の人手を中心とした音声監視体制が抱えていた監視カバレッジの限界を、AIによってどのように乗り越えたのか、その設計と改善の過程をお伝えします。

ピグパーティとは？

ピグパーティは、アバターを通じて自分らしさを表現し、ユーザー同士のコミュニケーションを楽しめるアバターSNSサービスです。2015年のサービス開始以来、累計ユーザー数は1,000万人を突破しています。数万人のユーザーがリアルタイムに交流する仮想空間を安定して提供するため、大規模トラフィックの処理やレンダリング最適化といった技術的課題を乗り越えながら、途切れのないコミュニケーション体験を届け続けています。

ボイスパーティ

ピグパーティの主なコミュニケーション手段はテキストチャットですが、それに加えてボイスパーティ機能により、音声によるリアルタイムコミュニケーションも展開しています。ユーザーが自分の部屋やパーティルームでパーティを開く際にボイスチャットを有効にすると、参加者同士が音声で会話できる機能です。

ボイス監視の必要性

ボイスパーティはピグパーティのユーザーとの繋がりをより楽しめる機能ですが、同時にテキストチャットとは異なる次元の監視課題を生み出します。テキストであれば入力時点でキーワードフィルタリングを適用できますが、音声は発話が終わるまで内容を確認できません。音声を監視するにはまずSpeech to Text(STT)によるテキスト化が必要で、イントネーション・話す速さ・背景ノイズなど変動要因も多いため、自動化のハードルはテキストや画像よりはるかに高くなります。そのため音声監視は人が直接聞いて判断する手作業への依存度が高く、監視できるカバレッジにも構造的な限界がありました。

現在ピグパーティでは、次の行為を利用規約に反する行為と定めています。

ピグパーティは、幅広いユーザーに利用されています。監視カバレッジの限界は単なる運用効率の問題にとどまりません。不適切な発言や個人情報の聞き出しといったリスクからユーザーを守るには、人の力だけではカバーしきれない範囲を技術で補う仕組みが欠かせません。

システムアーキテクチャ

既存のデータパイプライン

ピグパーティの既存システムは、ボイスチャットの音声データを一定単位のセグメントに分割し、AWS S3へ保存するデータパイプラインで構築されています。保存された音声は管理画面を通じて確認でき、監視担当者が内容を聞いて判断する運用になっていました。

私たちは、この既存パイプラインをそのまま活かす方針でAI監視システムを設計しました。新しい音声収集インフラを別途構築するのではなく、S3へのセグメント保存をトリガーに自動化パイプラインをつなぐことで、導入コストと既存システムへの影響を最小限に抑えています。

AI監視パイプライン

既存のS3パイプラインの上に、前処理 → STT変換 → AI判定 → 監視システム連携という自動化レイヤーを載せました。各ステップの責務を明確に分離し、STTエンジンや判定モデルを差し替えても変更がシステム全体に波及しない設計にしています。

初期アーキテクチャ

初期は、STTで変換したテキストを1つの高性能モデルが判定し、違反の可能性がある件を社内監視システムへ連携するシンプルな構成でスタートしました。

この構成は、素早く検証して運用を始めるには適していました。しかし監視範囲を広げていくと、すべてのリクエストを高性能モデルで処理するコストと、過検出によって増えていく人のレビュー量が、新たなボトルネックになりました。

現在のアーキテクチャ

現在は、役割の異なるモデルを段階的につなぐModel Cascade構成を採用しています。1段目の軽量モデルは実際の違反を取りこぼさないよう候補を広めに検知し、後段の精密判定モデルは文脈を読み直して明らかな誤検知を取り除きます。最終的にNGとするかどうかの判断は自動化せず、運営チームが行います。

• S3イベントトリガー: 音声セグメントがS3に保存されると、イベント通知を契機に監視パイプラインが自動で動き出します。

• 前処理パイプライン: VADによる無音除去、区間サンプリング、倍速圧縮を適用し、STTに渡す音声量を削減します。

• STT変換: 前処理済みの音声をSTTモデルに渡してテキスト化します。

• 1次判定: 軽量モデルが高い再現率を目標に、違反の可能性がある会話を幅広く検知します。

• 2次・3次判定: より精密なモデルが会話の文脈や境界事例を読み直し、明らかな誤検知を段階的に取り除きます。

• 監視システム連携: 最終候補と判定根拠を社内監視システムへ連携します。

• 人による最終判断: 運営チームが実際の音声と判定根拠を確認したうえで、対応するかどうかを決定します。

この設計で最も重視したのは、既存インフラの再利用とモデルの差し替えやすさです。音声収集からS3保存までの安定した流れはそのままに、S3以降のステップだけを拡張しました。おかげでサービスへの影響を抑えつつ、STTエンジンや判定モデルを運用状況に合わせて入れ替えられるようになっています。

課題と解決策

上記パイプラインの各ステップを実装する過程で、3つの技術的課題にぶつかりました。ここからは、それぞれの課題と解決策をあわせてご紹介します。

課題1: ノイズ・方言・話速との戦い — 高精度なSTT(Speech To Text)を実現するための技術選定

ボイス監視の出発点は、音声をテキストに変換するSTT処理です。しかし実際のボイスパーティは、STTにとって難易度の高い環境です。周囲の雑音、端末やマイク特性の違い、話速やスラング、地域ごとの方言、複数人が同時に話す状況など、多様な条件下でも安定した認識精度を出すことが課題でした。

STTエンジンの選定で特に重視したのは、次の3点です。

• ノイズ環境での認識精度: ボイスチャット特有のノイズが混じる環境でも、安定した変換品質を出せるか

• 既存インフラとの統合のしやすさ: すでにAWS上で動いているシステムとスムーズに連携できるか

• スケーラビリティ: トラフィックの増加に応じて柔軟にスケールできるか

初期の選定では、ユーザーごとにマイク性能・周囲の騒音・イントネーションや話速が大きく異なること、そしてSTT段階のエラーが後段の違反判定にそのまま伝播することを重視しました。そこでコストよりも多様なボイス環境での認識精度を優先し、当時のベンチマークでWER 4.3%を記録したAmazon Transcribeが最適だと判断しました。ピグパーティはすでにAWSインフラ上で動いていたため、S3連携やIAMベースの認証など、既存システムとの統合もスムーズでした。Whisper Largeはオープンソースゆえに柔軟にカスタマイズできる利点がありますが、自前のGPUインフラの運用コストとスケーラビリティの問題から、初期の選択肢からは外しました。

運用拡大後のSTTエンジン切り替え

初期の選択は、多様なボイス環境で必要な認識精度を確保し、素早くシステムを立ち上げるうえでは合理的でした。しかし監視範囲の拡大に伴ってSTTの処理量が大きく増え、コストが主要な課題として顕在化しました。そこで、必要な認識精度を維持できることを条件に、実際のボイスデータを用いて処理単価と運用効率を再検証しました。その結果、現在はAmazon Transcribeに代えてGPT系のTranscribeモデルを使用しています。

課題2: 月数十万時間におよぶ音声の処理コストを現実的な水準に抑えるまで

ピグパーティのボイスパーティで発生する音声データは、月およそ数十万時間にのぼります。STTは処理する音声の長さに比例して課金される従量制のため、この膨大な音声をそのまま処理するとコストは一気に膨らみます。コストを現実的な水準まで下げること、それが課題でした。

このコスト問題は、3つの前処理テクニックを組み合わせて解決しました。

手法1: Silero VADによる無音区間の除去。 VAD(Voice Activity Detection)は、オーディオストリームの中から人の声がある区間とない区間を判別する技術です。実際のボイスチャットでは、誰も話していない沈黙の時間が録音全体のかなりの割合を占めます。軽量モデルのSilero VADでこの無音区間をSTT処理の前にカットすることで、無駄な処理コストを大幅に削減しました。Silero VADを選んだのは、モデルサイズが小さく前処理のレイテンシがほとんど気にならないこと、そして多様なノイズ環境でも発話区間検出の安定性が実証されているためです。

手法2: 区間ランダムサンプリング。 ボイスパーティの音声セグメントは、一定の長さ単位でS3に保存されます。このセグメント全体をSTTに渡すのではなく、各セグメントから一定時間の区間をランダムに抽出して監視対象とする方式を導入しました。違反発言は特定の時点に集中するというより会話全体に散らばる傾向があるため、ランダムサンプリングが監視品質に与える影響は限定的です。この手法だけでも、STTに渡すデータ量を大きく減らすことができました。

手法3: 音声の倍速処理。 研究（arXiv: 2403.07937）では、英語・スペイン語の音声と複数のSTTエンジンを用いた評価において、音声速度を1.5倍程度まで上げた場合は、1.75倍や2倍の場合と比べて認識性能の劣化が比較的小さい傾向が示されています。この結果を参考に、利用するSTTエンジンと実際の対象音声で検証を行ったうえで、音声を高速化して処理対象の長さを圧縮する手法を導入しました。

3つの手法を組み合わせることで、元の音声から最大約90%のデータ量削減を実現できました。監視品質を保ちながら処理コストを現実的な水準に抑えるための、核心となる最適化でした。

前処理だけでは解決しなかったLLMコスト

音声データ量を削減した後にも、もう一つのコスト問題が残っていました。監視カバレッジが広がるほど、STT後のLLM判定リクエストも増えていくためです。初期はすべてのリクエストを単一の高性能モデルで処理していたため、トラフィックが増えるほどコストがほぼ線形に増加していました。

Model Cascadeで問題を構造的に解決する

トラフィックの多いサービスにLLMを導入する際に使える手法の一つがModel Cascadingです。すべてのリクエストを最も高価なモデルに送るのではなく、安価で高速なモデルが大半のリクエストを先に処理し、精密な判断が必要な候補だけを高性能モデルに回す方式です。

AWSも生成AIシステムのコスト・性能最適化の方法として、小さなモデルが一般的なリクエストを処理し、失敗したり確信度が低いリクエストだけをより強力なモデルへ渡す階層型の構成を紹介しています。DoorDashも休日の需要予測にCascade ML構成を適用し、単一モデルでは扱いづらい問題を役割の異なる複数のステージに分解しました。適用分野や目的は違っても、1つのモデルにすべての責任を負わせず、各ステージのモデルがそれぞれの目標に集中できるようにするという原理は共通しています。

全体のリクエストは単価の低い1段目が処理し、後段に行くほど渡されるリクエスト数は減っていきます。そのため高性能モデルは難しい候補だけに集中でき、最後は人が実際にNGとするかどうかを決定します。

ピグパーティでは、この構成を次のように適用しました。

• 1次・軽量モデル — 高い再現率: 低コストのモデルで全リクエストを処理しながら、実際の違反を取りこぼさないよう候補を広めに収集します。

• 2次・精密判定モデル — 誤検知の除去: 1次でNGと分類された件だけを読み直し、キーワードは危険に見えるものの文脈上は問題のない事例を除外します。

• 3次・最終フィルタモデル — 境界事例の再チェック: それでも曖昧さの残る候補をもう一度検討し、人が確認すべきキューの大きさをコントロールします。

• 運営チーム — 最終判断: 自動化されたモデルが担うのは候補の絞り込みまでで、実際にNGとするかどうかは人が決定します。

導入結果 — 1段階構成から3段階構成へ

Model Cascadeの効果を、初期の1段階構成と現在の3段階構成で比較すると、次のようになります。ここでのNG率は、人が確認するレビュー候補のうち、実際に違反だった割合です。この値が高いほど、誤検知が少なく、確認すべき候補を的確に絞り込めていることを意味します。

つまり、3段階化によって人が確認する必要のない候補の約7割を自動で除外し、レビューキューの実NG率を9.2%から32.98%まで高めながら、LLMコストも約7割削減できました。低コストの1段目で広く候補を拾い、後段の精密モデルを必要な候補にだけ適用することで、コストとレビュー精度の両方を改善しています。

一方で、3段目フィルタのホールドアウト検証における実NG維持率は83.78%であり、自動除外による見逃しのリスクは残ります。この結果を踏まえ、AIはレビュー候補の絞り込みを担い、候補を実際にNGとするかどうかの最終判断は人が行う設計としています。

※ NG率とレビュー量は、異なる時期の運用データおよびホールドアウト検証から算出した代表値であり、同一母集団に対するA/Bテストの結果ではありません。

Model Cascadeの目的は、単に安いモデルへ置き換えることではありません。コストの低いステージでは広く探し、高価なステージでは必要な候補だけを精密に判定する、という役割の分離が核心です。これによりLLMコストと人の運用負担を同時に抑えながら、各ステージの見逃しと誤検知を個別に測定できるようになりました。

課題3: 曖昧な発言を正しく扱う

「あとで2人で話そう」という発言を考えてみます。単にゲームの攻略の話をしたいだけかもしれませんし、外部連絡先の交換につながる危険な入口かもしれません。アバターSNSというドメインの特性上、ユーザーの日常会話が絶え間なく行き交うため、違反発言と日常会話の境界は非常に曖昧です。単純なキーワードマッチングや二値(OK/NG)の判定では、この境界を扱いきれません。厳しすぎれば無実のユーザーが不利益を被り、緩すぎれば実際の違反を見逃してしまう。このバランスをどう取るかが課題でした。

私たちは判定を単純な二値ではなく、スペクトラムスコアリング方式で設計しました。

具体的には、ピグパーティの利用規約を判定基準としてAI判定モデルのプロンプトに与え、出会いの誘導・個人情報の共有・誹謗中傷といった違反類型ごとに、発言の違反スコアを0.0〜1.0で出力させます。判定をスコア化することで、明確な違反と曖昧な発言を区別し、モデルの判定根拠を比較しやすくなります。

サービスの心地よい雰囲気を損なうことなく、実質的な危険行為には確実に対応するための仕組みです。

3段階のAI判定の後にも、人による最終確認が必要な理由

音声は一定の長さのセグメントに分割して処理されるため、各セグメントだけでは会話全体の文脈を把握できない場合があります。さらに、周囲の音や複数人の発話など、テキスト化された情報だけでは話者の意図を判断しきれないケースもあります。

そのため、3段階のAI判定は人が確認すべき候補を絞り込むところまでを担い、候補を実際にNGとするかどうかは、運営チームが音声と判定根拠を確認したうえで決定します。

プロンプト設計、モデルバージョン、しきい値が変われば、False PositiveとFalse Negativeのバランスも変わります。実際、レビュー量をより積極的に削る設定では見逃しが増えました。だからこそ単一の「精度」だけを最大化するのではなく、実際の違反の維持率と人がレビューできる量をあわせて見ながら、運用基準を調整し続けることが重要です。

まとめ

AIボイス監視システムの導入により、現在ピグパーティではボイスチャットを24時間監視しています。監視カバレッジを100%まで広げ、AIが確認すべき会話の候補を抽出し、運営チームが最終判断する体制を実現しました。

個人情報の公開や出会いの誘導といったリスクから利用者を守ることは、サービスにとって重要な取り組みです。AIと人それぞれの強みを組み合わせながら、ユーザーがより安心してコミュニケーションを楽しめる環境づくりに貢献していきます。