1. はじめに
こんにちは。株式会社ACESでAIエンジニアのEMをしている阿久澤(@kei_akuzawa)です。最近新しく遊んだボードゲームは『サンレンタン』です。左脳ばかりでなく右脳も鍛える必要がありそうです。
さて、今回は「音声認識」を題材に、構造化AIに対しての個人的なポジションを語る記事となります。ここで構造化AIとは、「音声認識」「ドキュメント構造化」「物体検知」といった、非構造化データをLLMが理解しやすい形式に変換するアルゴリズム全般を指す弊社の造語です。
ACESは2022年3月ごろから『ACES Meet』というAI議事録SaaSを運営していますが、この内部では自社開発した音声認識システムが使われ続けてきました。音声認識に限らず、松尾研究室の出自を活かした構造化AIモデルの開発力は、長らく弊社のコアコンピタンスの一つでした。
しかし現在、Whisper、GPT等の「基盤モデル」が伸長する中で、「音声認識システムをどこまで内製するべきか」が問い直されています。基盤モデルとはインターネット上の膨大なデータを用いて事前学習され、幅広いタスクに転用できるAIモデルのことです。基盤モデルの発展に伴い、書き起こしのような汎用タスクはAPI call一発で実行可能になるため、一見すると音声認識システムの開発は不要・または非常に簡単に見えると思います。
このような状況下にあって、弊社では音声認識を含むデータ構造化AIを開発・技術資産化することについて、方針の見直しや注力ポイントの変更を絶えず迫られてきました。現在のACESは、大規模な予算や計算基盤を必要とする基盤モデル層のプレイヤーではありません。しかし今現在でも、基盤モデルとは別のレイヤーで構造化AIの開発を続けています。本記事では、その理由と内容について簡単にご紹介します。
2. なぜやるか
2.1 システム全体の最適化により、優れた体験を提供する
さて、基盤モデルの進化によって、一定品質の書き起こしを得ること自体はかなり容易になっています。今後も、汎用的な音声認識モデルの性能は上がり続け、モデル単体の性能差で差別化をすることは難しくなると考えています。
一方で現在の基盤モデルのAPI call単体では、実際のプロダクトや顧客業務で求められる要件や品質を満たすことは困難な場合が多いです。例えばACES Meetであれば、①文字起こしをその発言者・発言時刻とセットで表示する、②一時間を超える長尺の会議を処理する、といった要件が発生します。これに対して、Hugging FaceのWhisper（オープンソースで誰でも利用可能な音声認識モデル）では、30秒程度の音声を書き起こしに変換する機能しか持たないために、単体で要件を満たすことは不可能です。*1
この例は、我々がプロダクト上で稼働させている音声認識のアルゴリズムが「一つのモデル」ではなく、複数の処理を組み合わせた「システム」であることを示唆しています。音声区間検知、話者照合、書き起こし生成など、いくつかのコンポーネントをパイプラインとして構築し、ユーザー体験を支えるのに必要な機能・品質を実現しています。
ここに、ACESが構造化AIを開発・改善し続ける理由があります。基盤モデルを外部サービスをそのまま使うだけでは実現できない機能要件・届かない品質要件は、システム全体の設計と統合によって達成する必要があるのです。基盤モデルや外部APIを否定することはなく、むしろコンポーネントの一部としては積極的に採用しています*2。その上で、各コンポーネントの精度が高いことを前提に、システム全体としての最適化＝「すり合わせ / インテグラル」は最終的な差別化にとってクリティカルである、というのが現在の私の肌感覚です。
ただし注意点として、基盤モデルや外部サービスが代替可能な領域は徐々に広がっていくはずです。例えば音声区間検知と書き起こし生成をセットで行うAPIなども存在します。そうした流れの中で、外部サービスで十分な領域はブラックボックス的に任せて使いつつ、より広範なシステム全体の最適化に仕事の力点が移っていくことにはなるでしょう（極端な例では、高級言語の誕生によってプログラマーの仕事が変わったのと似たような構図と考えています）。
2.2 企業のAI OSとインテグレートする
それでは、音声認識システムが近い将来に求められる「より広範なシステム全体で最適化された状態」についても、現在から見据えておけるとよいでしょう。私は、「音声認識システムが企業のAI OSにインテグレートされた状態」だと考えています。AI OSとは、ACESの定義だと「企業のAI活用基盤」、すなわち各部門・各業務に散在するデータとAI Agentをサイロ化させず、適切なガバナンスのもとで多様なユースケースを高速に実装・運用するための共通基盤を指します*3。
音声認識システムとAI OSの間には、「双方向のシナジー」が存在すると考えています。一つ目の方向は、書き起こしの品質向上が後段のAI業務活用の質を底上げする流れです。書き起こしは企業活動の中で生み出されるデータの中で大きな比重を占め、AI OS上で様々な業務に接続されていく可能性があります（商談ログから顧客ナレッジを抽出して別商品の提案可能性を探る、顧客の声を製品開発にフィードバックするなど）。このときに固有名詞の表記揺れや発言者名の取り間違えがあると、後続業務でのAI活用の品質にも波及するため、書き起こし品質はAI OSにとって重要です。
二つ目の方向は、AI OS上に蓄積された企業データが書き起こし品質を継続的に高める流れです。例えば会議参加者の名前やニックネーム、あるいは製品名や社内用語といった企業固有の単語リストを使うことで、汎用モデルが知らない単語や苦手なレアワードの認識精度が上がるかもしれません。あるいは、特定発言の話者がシステム上取得できないときに、他の参加メンバー・対象会議と紐づくプロジェクト等がわかっていれば、そうしたコンテキストから発言者を推測することは容易になりそうです。
ACES は AI OS を事業の中心に据えています。そして、「業務の中で蓄積される企業データが書き起こしを賢くし、その書き起こしが企業文脈としてさらに業務活用される」というFBループの構築は、チャレンジの価値があると考えています。
3. 何をやるか
こうした考えのもと、ACESでは音声認識開発の重点項目を以下の三つに置いています。
3.1 より早く・より少ない工数で、基盤モデルの進展に追従する
一つ目は、基盤モデルの進展に追従し続けることです。先に述べた通り、弊社はAPI、オープンウェイト問わず、使えるものは積極的に採用します。必要に応じてfinetuningを行いますが、独自モデルを持つこと自体を目的にはしていません。しかし2026年現在も基盤モデルの進化は速く、基盤モデルの選定は一度決めたら終わる技術選定というよりも、継続的な運用課題となっています。
このような状況のもと、「より早く・より少ない工数」で基盤モデルの進展に追従するため、弊社では最新モデルの性能を簡単に計測することのできるベンチマーク/リーダーボード開発や、モデルに対する互換性を高める音声認識パイプラインのリファクタリングを行っています。
3.2 企業固有のコンテキストを取り入れる
二つ目は、企業ごとのコンテキストを取り込むことです。ACES Meetでは、ユーザーが登録した単語の認識精度を高める辞書機能や、事前に登録された声紋と会議音声データ上の話者を対応させる機能などを開発しています。
ここで重要なのは、単に「辞書登録機能を提供する」ことではありません。そもそもコンテキストとして利用できる情報は何か、辞書登録された単語が認識されなかったときにユーザーが修正できるか、その修正を次回以降に活かせるかまで含めて、一つの体験として設計する必要があります*4。こうした音声認識に関わる広範な体験が、音声認識システム開発の扱うスコープになっています。
3.3 細かいことをちゃんとやる
三つ目は、ざっくりした言い方にはなってしまいますが、「細かいことをちゃんとやる」ことを意識しています。前述の通り現行の音声認識システムは、複数の処理が積み重なったパイプライン的なシステムです。このようなシステムでは、各処理では小さな誤差であっても、それらが堆積し最終出力では大きな違いを生むことがあります。また前述の通り、システム内部のスコープからさらに広げて、人間の修正・学習ループを含めた利用シナリオ全体においても、随所に工夫の余地があります。「（大前提として基盤モデルの精度は全体精度に対して支配的な貢献をしているものの）競合とベースモデルの条件が揃った下では細かい工夫の積み上げが依然として優位性につながる」というのが、現状の手応えです。
4. 終わりに
現在は、基盤モデルの発展により、高性能なモデルを多くの企業が利用できます。しかし、音声認識システムの開発が不要になったわけではありません。基盤モデルを適切に選択し、差し替え可能な形で組み込み、企業固有の文脈を学習させ、UXまで踏み込んでシステムとして成立させる。そのための開発としてやるべきことは多くあります。
この構図は、ドキュメント構造化、物体検知など、「構造化AI=非構造データをLLMが扱える形に変換する技術」の多くにおいても共通すると考えています。プロダクト/顧客価値を左右する部分について、その時々で最適な技術選定ができる状態を保ち、またモデル外延を含めたシステム全体を最適化する能力は、ラストワンマイルの差別化に繋がると考えています。
最後に、ACESでは現在、複数のエンジニアポジションで採用を行っています。ACESの開発に興味を持っていただけた方は、ぜひカジュアル面談でお話ししましょう！
ACESの採用情報はこちら↓
*1:ACES Meetで求められる他の要求/要件、例えば「書き起こしの可読性」、「企業固有単語の認識率」、「誤りをユーザーが修正しやすいUX」などについても、同様と考えています。
*2:外部APIとして利用する、オープンウェイトのモデルを利用する、オープンウェイトのモデルをfinetuneした上で利用する、といった採用形態の実績があります。
*3:ACESにおけるAI OSの考え方の詳細についてはこちら: 株式会社ACES インタビュー／「AI OS」とは何か──1社で100個のAIを動かすために企業が準備すべきこと | AXIS Insights, わたしたちの技術｜AI OSとは｜株式会社ACES
*4:AIとUXの設計については以前のブログで詳細に語っています: AIのUXは『Guidelines for Human-AI-Interaction』に基づいて決めよう——ACES Meetの事例を添えて—— - ACES エンジニアブログ
