音声×AI SaaSインフラの最前線：4社が語るアーキテクチャ設計と運用戦略

株式会社ACES

株式会社ACESは「アルゴリズムで、人の働き方に余白を作る」というミッションを掲げ、テクノロジーで社会課題の解決を目指す会社です。
弊社にはDXパートナーサービスとAIソフトウェアの2つの事業部があります。今回はAIソフトウェア事業部でサービス提供を行っている「ACES Meet」というプロダクトの音声認識技術を支えるインフラアーキテクチャについて紹介します。
ACES Meetのプロダクト開発では、ソフトウェアとアルゴリズムの開発メンバーが同じチームで開発を行っています。ユーザーのフィードバックが直接届く環境で、素早くPDCAサイクルを回しながらアジャイル開発を行っています。

アーキテクチャ設計について

ACES Meetは高精度なアルゴリズムで会議を可視化するAI議事録ツールです。Zoom、Google Meet、Teamsなどのビデオ会議ツールやZoom Phoneなどの電話ツールのデータを取り込み、自動で音声認識を行って結果を出力しています。
ACESの音声認識モデルは社内のアルゴリズムエンジニアが開発しています。外部のオープンウェイトのモデルをベースとして、自社で作成・準備したデータでFinetuneを行ったモデルを作成しています。定量・定性的な評価を行い、継続的に精度を改善する仕組みを導入しています。
また、アルゴリズムのソースコードは社内ライブラリ化されており、ACES Meetのプロダクトだけでなく、他のプロジェクト・プロダクトでも再利用可能な設計となっています。

ACES Meetでは音声認識モデルの推論処理と学習処理をAWS上で動作させています。推論処理と学習処理は共にAWS Batchを利用しています。AWS BatchのバックエンドにはEC2を利用し、GPUサーバー上でDockerコンテナを動かしています。
AWS Batchを利用することで、EC2（GPUサーバー）をスケーラブルに起動・停止することが可能になります。利用状況に応じたEC2の起動・停止だけでなく、ジョブ及びキューの管理をAWSがマネージドで行ってくれるため、メンテナンス工数を下げながら最適な運用ができています。

SaaSを運用していくにあたり、適切なマルチテナント管理が重要になります。
ACES Meetでは辞書機能という名前で、テナント毎のFinetuneを提供しています。これは、あらかじめ用意されている各業界の単語リストを選択し、さらにユーザーが登録した単語リストを組み合わせて、テナント毎にモデルの学習処理を実行します。
学習が完了するとテナント毎に学習済みモデルが作成されるため、推論処理ではこの事前学習済みモデルを使って各テナントで音声認識を行います。それにより、各テナントの会議の文字起こしに、各業界の単語リストやユーザーが登録した単語リストの出現率が向上することを見込めます。
学習処理・推論処理いずれにおいても、テナントの分離を厳格に実施しています。インフラレベルで処理を分離し、データやモデルが混在しないように管理しています。例えば、1つのコンテナの中で1つの処理を行い、学習・推論処理が終了したらコンテナを都度破棄することで余計なデータが残らないようにしています。

また、ユーザーの会議や通話のデータ（録画・録音データ）はS3に保管しています。この録画・録音データに対してACES従業員のアクセスを禁止するため、インフラ基盤で技術的な対策を実施しています。
S3バケットのバケットポリシーを設定し、APIサーバーのIAMロールからのみS3のオブジェクトへのGETリクエストを許可しています。これにより、ACES従業員がAWSのマネジメントコンソールやAWS CLI等からS3バケットにアクセスした際にはGETリクエストがブロックされます。

今後の展望や取り組み予定

ACES Meetは音声認識を中心とした複数のアルゴリズムを活用し、会議の可視化や業務の効率化ができるツールとして、さらなる開発を続けていきます。
今後は以下のような取り組みを考えています。

• 対面会議など、同一マイク内の話者分割の精度を向上する。
  • アルゴリズムの処理だけでなく、ソフトウェアのUI/UXを含めて、オンライン会議だけでなく対面会議のような全員が集まるような会議でも適切に文字起こしが表示される。
• アルゴリズムのデプロイを安全かつ高頻度で行えるようにする。
  • 推論処理や学習処理の実行には時間がかかるため、動作確認を含めるとデプロイ作業のリードタイムが長時間発生する。品質を担保しつつ素早くデプロイするための環境を整備していく。

また、今回紹介できませんでしたが、ACES Meetでは音声認識やその他の様々な処理において生成AI（LLM）をフル活用しています。生成AIの活用をさらに加速するための取り組みも常に行っています。（例：AIワークフロー基盤・RAG基盤・自律的なAIエージェント基盤の構築など）

興味がある方は是非一緒に働きましょう！
https://recruit.acesinc.co.jp/

◆執筆：三田村 健　株式会社ACES 共同創業者/ソフトウェアエンジニア　@Ken_Mitamura

【株式会社ACESのエンジニア求人】
https://findy-code.io/companies/1206/jobs

株式会社IVRy

私たちは、電話自動応答を起点として、AI対話システムを開発・運営しています。AIやソフトウェアを活用し業務を効率化することで、人が介在する仕事の価値を最大化し、楽しく・豊かに事業活動を行うことができる世界の実現を目指しています。

会社や組織フェーズに合わせて柔軟にアップデート可能な組織デザインを採用しており、現状は、組織にプロジェクト/サークルという名称をつけて、組織ごとの役割や目的を明確化した運用を行っています。

事業フェーズ毎に柔軟な組織運営ができるよう3ヶ月毎に見直しするプロジェクト制を導入し、運営しています。人材育成や評価が浮いてしまう問題をサークルというマトリクス組織の形でフォローし、人の成長にもコミットメントできる組織設計としています。

アーキテクチャ設計について

■ 音声生成AIの導入・活用
当社では、サービス開発の初期段階からプロダクトの中核機能としてAIテクノロジーを位置づけることを戦略的に決定していました。全体的なアーキテクチャは創業当初から大きく変わらず、技術的な基盤を強固にすることができました。

対話システムの実現において、音声合成（TTS）技術による自然な発話生成、音声認識（ASR）による高精度な音声データのテキスト変換、そして対話生成（LLM）による文脈を考慮した応答生成など、会話フローの各段階で必要となるAI技術を統合的に活用しています。これらの技術を組み合わせることで、より自然な対話体験をユーザーに提供することが可能となっています。

現在使用しているAIモデルについては、すべて外部APIを利用する方針を採用しています。この選択は、マネージドサービスとしての拡張性を確保できることに加え、AI技術、特に音声関連モデルの進化速度が非常に速いという現状を考慮したものです。常に最適なモデルを選定するため、複数のプロバイダーのソリューションを並行して評価・検証する継続的なプロセスを確立しています。

■ システム設計や運用における工夫・課題とその解決策
音声データ処理におけるアーキテクチャ上の工夫として、まずハルシネーション（誤った情報生成）を防ぐため、対話処理エンジンを複数のAIコンポーネントに分割しています。これにより各コンポーネント辺りで解くべき問題が明確になり、レスポンス速度が向上するという利点もあります。

また、外部APIは時に不安定なため、LLMのAPIコールにはフォールバックメカニズムを採用しています。これにより、複数のLLMに対して同一形式でリクエストできるようになりました。メインのLLM APIリクエストが失敗したり、応答時間が長すぎたりした場合でも、ユーザー体験を損なわない工夫を実装しています。

今後の展望や取り組み予定

通話の品質をエンドツーエンドで担保する仕組みをすでに導入していますが、今後はサービスの拡大と複雑性の増加に対応しながらも開発効率を維持する取り組みを継続していきたいと考えています。

また、あらゆる対話シナリオにおいてユーザー体験に直結する対話の質を評価する課題にも取り組んでいます。具体的には「話が通じない」「不適切な応答」「文脈の断絶」などの問題を定量的に測定するための指標開発を進めています。これにより対話システムの弱点を特定し、継続的な改善サイクルを確立していきます。

このような客観的な評価値のトラッキングに基づいてユーザーの「目的達成率」をはかれるようにしていきたいと考えています。単なる技術的な精度だけでなく、ユーザーが求めている結果にどれだけ到達できたかという本質的な成功指標を確立することで、より人間中心のAIシステム開発を推進し、長期的にはこれらの指標に基づいた自己改善機能を持つAIシステムの構築を目指しています。

◆執筆：近藤 圭太　Engineering Manager　@k0703k

【株式会社IVRyのエンジニア求人】
https://findy-code.io/companies/1610/jobs

株式会社ナレッジワーク

株式会社ナレッジワークは「LIFE WITH ENABLEMENT できる喜びが巡る日々を届ける」をミッションに、現在は主に大手企業を対象に営業支援およびセールスイネーブルメントAI「ナレッジワーク」を中心に開発・提供しています。
ナレッジワークはマルチプロダクトを展開しており、今回事例として紹介する「ナレッジワークAI商談記録」は日本語文字起こし機能、Salesforceとの連携、オンライン・オフライン両方の商談対応、要約機能、話者分離機能を備えています。
ナレッジワークAI商談記録では多くのAIモデルを内製しており、AIリサーチャーによって開発したモデル・処理をAIエンジニアがデプロイする、という体制で開発しています。

アーキテクチャ設計について

■ オンライン会議


■ オフライン会議


議事録を生成するパイプラインの処理フローは以下のようになります。

1. 話者分離（ただし、オンライン会議の場合はWeb会議システムの話者・発話情報を利用）
2. 音声区間検出（VAD）・音声認識（ASR）
3. 文字起こしの後処理
   • フィラー・吃音の削除
   • 漢数字をアラビア数字に変換
   • 句読点の挿入（系列ラベリング）
   • 辞書による単語の上書き
4. LLMによる要約

この中でLLMのみAPIを利用し、その他は内製のモデルやルールベースの処理を使用しています。内製化してる理由は2つで、1つは話者分離や後処理といった他の処理と柔軟に組み合わせてカスタマイズが容易になるためです。 2つ目はコストメリットでAPIを利用するよりも安く抑えることができるため内製化しています。 一方LLMは、APIと同等レベルのOSS LLMを動かすには、インフラ管理に労力を割かなければならないことが想定されたのですが、少人数でサービス開発をしている状況を踏まえてAPIを活用しています。

開発時の課題として、プロダクトとして議事録の精度を最優先するため、高精度なASRモデルを開発しました。その結果、処理に一定の時間を要していましたが、精度を維持したまま高速化するためにアーキテクチャの最適化を行いました。結果として、1時間の会議でおよそ10〜20分でユーザーに結果を表示できるようにしました。これらの施策はゴールではなく、将来のStreaming ASR導入やリアルタイムAIエージェントの実現に向けた基盤強化につながっていますので、今回は現段階の工夫点について紹介します。

オンライン会議では、録画ボットを利用して音声データを取得し、10秒単位でチャンク化してS3に保存します。文字起こしタスクではそのチャンクデータを逐次読み込みながらVAD→ASRを実行しています。会議のバックグラウンドで解析処理を進めることで、体感的な待ちを抑えられます。さらに音声ストリーミング時の欠損に備え、各フラグメントと併せて欠損のメタ情報も保存。会議終了後はそのメタ情報に基づき、欠損区間のみを元の全体音声から抽出して ASR を再実行し、欠損を補完します。

オフライン会議の場合、録音時の通信環境が悪く、オンライン会議と同等の音声ストリーミングが達成できない懸念がありました。またオフライン会議ではWeb会議システムのように「誰が・いつ話したか」の情報がないため話者分離も実行する必要があります。そこでオンラインとは根本的にアーキテクチャを変え、会議全体の音声データをASRの並列処理する方法を取っています。

並列化を行うために、VADとASRを別タスクとして分離し、VADのセグメントを分割して複数のASRタスクで解析する、という処理に変更しました。また、文字起こしのタスクと並列で話者分離を実行し、後処理で話者情報と文字起こし情報を結合することで、全体での処理時間短縮を実現しています。

今後の展望や取り組み予定

今後取り組んでみたいことは3つあります。1つは解析ワークフローのさらなる高速化に取り組んでいきます。具体的には、話者分離タスクをCPUからGPUに移行する、コンテナイメージを最適化して起動のオーバーヘッドを削減するなどの改善余地があります。加えて、ASRモデルについても次に述べるStreaming ASRによる高速化が挙げられます。こうした施策を積み上げることで、1秒でも速い結果表示を実現していきたいと考えています。

2つ目に、現在使用しているASRモデルと同等精度のStreaming ASRモデルの開発です。これは単なる高速化手段にとどまらず、商談中にリアルタイムでフィードバックを返す「AIエージェント」構想の実現に欠かせない要素です。それを実現するためには現在のASRモデルでは限界があるため、速度・精度を両立したStreaming ASRモデルの開発とプロダクト実装を進めて行きます。

最後に、学習したモデルのプロダクト上での精度比較を、もっと簡単にできる仕組みを導入したいです。現在だとstg環境に新モデルをデプロイして、prod環境の出力と見比べる、という定性評価を行っています。しかしその方法だと、環境毎の設定によって精度差が発生するものもあるため切り分けが難しくなります。そのため、シャドウテストなど、同じ環境で2つ以上のパイプラインを実行できるようにして、より厳密な比較検証をできる環境を作っていきたいです。

◆執筆：みつい

【株式会社ナレッジワークのエンジニア求人】
https://findy-code.io/companies/1361/jobs

株式会社RevComm

音声コミュニケーションの課題をテクノロジーで解決する SaaS MiiTel を開発・提供しています。ブラックボックス化の解消や会話データの利活用を目的とし、可視化・解析することで、チームの生産性向上や業務改善を支援しています。

MiiTel RecPod は MiiTel のサービスの一つです。対面営業や窓口業務など、オフライン (対面) コミュニケーションを AI で最適化します。
私たちのチームでは MiiTel の各サービスを横断して、社内サービス向けの解析機能を開発しています。

アーキテクチャ設計について

■ 音声生成AIをどのように導入・活用しているか
MiiTel RecPod には基本機能として会議の音声を録音し、文字起こしをする機能があります。一般的な用途として、ユーザーは会議終了後に文字起こしなどの情報を確認し、会議の振り返りを行います。

文字起こしにかかる時間は、録音した音声の長さに依存します。会議にかかる時間は比較的長く、これはそのままユーザーの待ち時間となります。ユーザーは会議終了後に録音した音声をアップロードすることで、文字起こし結果を確認できるようになりますが、この方法ではユーザーが文字起こしを確認できるようになるまでにどうしても時間がかかります。そこで、会議終了直後に文字起こしを確認できる状態を目指し、高精度であると評価されている内製の音声認識モデルを使って、追加開発することになりました。

■ システム設計や運用における工夫・課題とその解決策
会議終了後にアップロードされた音声データを解析する方針では速度改善に限界があります。そこで、クライアントには短い音声データを会議中逐次送ってもらい、会議の進行と並行して文字起こしをする方針を採用しました。この仕組みだと、文字起こしが得られるまでの待ち時間は会議時間に依存しなくなり、長い会議の場合待ち時間が大きく短縮されます。

この機能では音声データを受け取るために Kinesis を利用しています。クライアントから送られてくる音声は数百ミリ秒程度の長さであり、解析サーバーでは文字起こしの前処理として、これらを連結する必要があります。KCL を使うことで、解析サーバーは細切れになった音声データを同じサーバーで受け取り、処理できます。

音声認識のリクエストには SQS を利用した非同期通信を採用しました。HTTP や gRPC のような同期通信では、スパイクした時にリクエストを捌くのが難しくなるという課題があります。間に SQS を挟むことで、リクエストをバッファすることが可能となり、スパイクした時でも音声認識サーバーは安定して処理を続けることができるようになります。他にも、音声認識サーバーの負荷が高まった時の影響を解析サーバーが受けにくくなることや、音声認識サーバーを他のサーバーとは独立にスケールさせられることもメリットとして挙げられます。同様の理由でレスポンスには MemoryDB の Pub/Sub を利用することにしました。

ちなみにサーバーレスを選択しなかったのは起動時のオーバーヘッドを避けるためです。音声認識モデルのサイズは一般に大きく、起動に時間がかかります。そのため、起動と終了を頻繁に繰り返すサーバーレスの仕組みでは、オーバーヘッドの影響を受けやすくなります。一度起動したサーバーが稼働し続ける構成では、オーバーヘッドを避けられることにより、処理の遅延が発生しにくいというメリットがあります。

リアルタイムに文字起こしを提供する機能では、処理の遅延がユーザー体験に大きく影響します。以上のような非同期の仕組みを採用することで、高速かつ安定した音声認識処理を実現しました。

今後の展望や取り組み予定

音声認識の精度に関しては引き続き研究チームと協力して向上させていく計画ですが、ここでは、機能拡張性とコスト最適化の向上に向けた取り組みを紹介します。

本記事では文字起こしを取り上げました。文字起こしの場合は、音声データの一部の区間があれば解析が可能ですが、例えば、話者識別を高い精度で行う場合は、理想的には音声データ全体が必要となります。分割した音声データでも可能な文字起こしの結果と音声データ全体が必要な話者識別の結果をうまく統合できるような構造にして機能拡張性を高くしていく改善を行う予定です。

また、音声解析では GPU インスタンスなど高価なインスタンスが必要になることが多いです。サービスレベルを維持しながら、これらのインスタンスの利用を最適化するために、Kubernetes へデプロイするサービスの単位をなるべく小さく分割していく予定です。現状すでに活用している Karpenter や KEDA といったツールの設定と合わせることで、さらなるコスト最適化を目指します。

◆執筆：髙橋卓杜　AI Div.

【株式会社RevCommのエンジニア求人】
https://findy-code.io/companies/1363/jobs