はじめに

会議の音声をテキストに変換し、要約を作るAIツールは、すでに多くの企業で利用され始めています。

しかし、会議データの価値は、議事録を作成した時点で終わるものではありません。

過去の商談で、顧客はどのような懸念を示していたか
ある製品機能について、複数の顧客からどのような要望が出ているか
プロジェクトの重要な意思決定は、いつ、どの会議で行われたか
退職者や異動した担当者が持っていた知識を、後から探せるか
自分に関係する会議から、次に取るべきアクションを抽出できるか

こうした問いに答えるには、文字起こしを保存するだけでなく、膨大な会議データから文脈に合う情報を高速に検索する仕組みが必要です。

AI文字起こしサービスを提供するNottaは、会議の文字起こし、翻訳、要約から、さらに一歩進んだ「コンテキスト検索」へとサービスを発展させています。その過程で、3,000万時間を超える音声データを扱う検索基盤に性能上の課題が生じました。

Nottaは検索基盤をZilliz Cloudへ移行し、Zillizの顧客事例によると、検索レイテンシを1,000ms以上から約100msへ短縮しました。

本稿では、この事例を通じて、会議データをRAGとベクトル検索で企業知識へ変える方法と、日本企業にとっての意味を整理します。

本稿に記載する利用者数、性能、コストなどの数値は、Zillizが公開したNottaの顧客事例に基づきます。特定時点・特定ワークロードにおける結果であり、すべての環境で同じ効果を保証するものではありません。

Nottaとは

Nottaは、会議やインタビューなどの音声をテキスト化し、要約、翻訳、共有、共同編集を支援するAIサービスです。

会議AIは3つの段階で進化する

NottaのCTOであるTJ Dai氏は、会議の生産性向上を、情報密度を高める3つの段階として説明しています。

音声をテキストへ変換する
AIで内容を要約する
文脈に応じて必要な情報やインサイトを検索する

第1段階では、「何が話されたか」を記録できます。

第2段階では、長い会議を短時間で把握し、決定事項やアクションアイテムを抽出できます。

第3段階では、会議単体ではなく、過去の複数の会議を横断して知識を利用できます。

たとえば営業担当者が、次のように質問できる状態です。

この顧客が過去3か月の商談で繰り返し懸念している点と、こちらが約束した対応をまとめてください。

この質問に答えるには、単純なキーワード一致だけでは不十分です。「価格が高い」と「予算との折り合いが難しい」のように、異なる表現でも意味が近い発言を探す必要があります。

そこで、会議の文字起こしをEmbeddingへ変換し、ベクトル検索とRAGを利用します。

会議データをRAGで検索する仕組み

基本的な処理の流れは次のようになります。

会議音声
  ↓
音声認識・話者識別
  ↓
文字起こし・チャンク分割・メタデータ付与
  ↓
Embeddingモデルでベクトル化
  ↓
Zilliz Cloudへベクトルとメタデータを保存
  ↓
質問に関連する会話をベクトル検索
  ↓
検索結果をLLMへ渡して回答・要約・提案を生成

会議データでは、ベクトルだけでなくメタデータも重要です。

会議日時
参加者と所属
顧客名、案件名、プロジェクト名
発言者
言語
部門や閲覧権限
Zoom、Teams、対面会議などの情報源

ベクトル検索で意味の近い発言を見つけ、メタデータフィルタで対象期間、顧客、部署、アクセス権限を絞り込むことで、業務に沿った検索が可能になります。

また、製品名、型番、人物名、契約用語のように完全一致が重要な情報には、キーワード検索も有効です。実用的な会議検索では、ベクトル検索、キーワード検索、フィルタ、Rerankerを組み合わせることが重要になります。

3,000万時間規模で生じた検索性能の課題

Nottaは当初、パブリッククラウド事業者が提供する検索サービスに、ベクトル検索用のインデックスを追加した構成を利用していました。

初期段階のキーワード検索やセマンティック検索には対応できていましたが、文字起こしデータが3,000万時間規模へ増えると、検索レイテンシが1,000msを超えるようになりました。

チャット形式のAI機能では、ユーザーが質問を入力してから、関連情報の検索、LLMによる生成、画面表示まで、複数の処理が連続します。検索だけで1秒以上かかると、生成処理を含む全体の待ち時間はさらに長くなります。

特に会議検索では、次のような処理が同時に必要になる場合があります。

長い文字起こしから関連チャンクを探す
ユーザーや組織ごとに検索対象を分離する
期間、参加者、案件などでフィルタする
複数の候補をRerankする
高いRecallを維持しながら低レイテンシを実現する

データ量が増えた時に必要なのは、ベクトルを保存できることだけではありません。検索品質、応答速度、同時実行数、インフラコストを同時に管理できる基盤が必要です。

Zilliz Cloudへの移行

Nottaは、この課題を解決するために検索基盤をZilliz Cloudへ移行しました。

公開事例で紹介されている主な結果は次のとおりです。

項目	移行前	Zilliz Cloud移行後
検索レイテンシ	1,000ms以上	約100ms
性能改善	-	約10倍
データ規模	3,000万時間以上の文字起こし	同規模データを移行
計算オーバーヘッド	基準値	最大80%削減
チューニング	手動調整が必要	自己最適化機能を活用

約100msという検索時間は、顧客事例でリアルタイムアプリケーションの目安として挙げられている200msを下回っています。

移行では、3,000万時間以上の音声データを大きな中断なく移管できたことも成果として紹介されています。大規模な検索システムでは、性能だけでなく、既存サービスへの影響を抑えた移行方法も重要な評価項目です。

Cardinal Search Engineが果たした役割

顧客事例では、性能改善を支える技術として、Zilliz CloudのCardinal Search Engineが紹介されています。

ワークロードに応じた検索戦略の最適化

ベクトル検索では、Recall、検索速度、メモリ、ストレージの間にトレードオフがあります。データの分布やクエリの特徴が変われば、適した検索設定も変わります。

Cardinalは、異なるワークロードに合わせて検索戦略を調整し、手作業によるチューニングの負担を減らします。

これによりNottaのエンジニアは、インデックス設定の細かな調整よりも、パーソナライズ、検索体験、AIによるインサイト生成など、利用者に直接価値を届ける機能へ時間を使いやすくなりました。

Graph-IVFハイブリッドインデックス

事例では、Graph-IVFハイブリッドインデックスにより、長い会議データに対する複雑なクエリで、速度と精度のバランスを取っていると説明されています。

グラフ型インデックスとIVF系の探索方法には、それぞれ異なる特性があります。ワークロードに合わせて検索経路を選択・最適化することで、大規模データに対して高い検索品質と低レイテンシの両立を目指します。

x86とARMでのマルチスレッド実行

Cardinalはx86とARMの両方でマルチスレッド実行を利用し、さまざまな構成やワークロードで安定した性能を提供する設計です。

このような検索エンジン側の最適化は、クラウドインフラの選択肢を広げ、性能だけでなく価格性能比を改善する上でも意味があります。

日本企業にとっての3つの示唆

Nottaの事例は、日本企業が会議AIや社内RAGを導入する際にも参考になります。

1. 議事録作成だけでROIを考えない

文字起こしや要約による時間削減は分かりやすい効果です。しかし、より長期的な価値は、蓄積した会話を再利用できることにあります。

たとえば次のような用途が考えられます。

営業会議から顧客の要望や失注理由を横断分析する
コールセンターの会話からVOCや製品課題を抽出する
開発会議から設計判断と背景を検索する
採用面接から評価根拠を権限付きで確認する
役員会議やプロジェクト会議の決定事項を追跡する
海外拠点との多言語会議を共通の知識として利用する

会議AIを単なる効率化ツールではなく、企業知識を収集する入口として捉えると、活用範囲が広がります。

2. 日本語と日本の業務文化を検索設計へ反映する

日本語の会議では、主語の省略、婉曲表現、社内略語、製品固有名詞などが多く使われます。また、「検討します」が肯定なのか保留なのかは、前後の文脈によって異なります。

高品質な検索を実現するには、ベクトルデータベースだけでなく、次の設計も必要です。

日本語・多言語に適したEmbeddingモデル
話題や発言単位を考慮したチャンク分割
辞書、固有名詞、専門用語への対応
キーワード検索とベクトル検索の併用
日本語に対応したReranker
実際の社内質問を使った評価データセット

Nottaが日本市場の業務習慣を理解して成長したように、検索やRAGでも、利用者の言語と業務文脈に合わせることが重要です。

3. セキュリティと権限を後回しにしない

会議データには、顧客情報、価格交渉、人事情報、製品計画、経営判断など、高い機密性を持つ情報が含まれます。

そのため、全社員がすべての会議を横断検索できる設計は現実的ではありません。検索時には、ユーザーの権限に応じて対象データを絞り込む必要があります。

検討すべき項目には次があります。

組織、部署、案件、参加者に基づくアクセス制御
元の会議システムと検索基盤の権限同期
保存データと通信の暗号化
監査ログとデータ保持期間
退職・異動時の権限更新
個人情報保護法や社内規程への対応
回答とともに参照元会議・発言箇所を提示する仕組み

公開事例では、NottaがHIPAA、GDPR、CCPA、APPIなどの要件に対応していると説明されています。ただし、適用範囲や最新の認証状況は、導入時に各サービスの公式情報と契約条件を確認する必要があります。

パーソナライズされた会議インテリジェンスへ

NottaのCTOは、今後の会議文字起こし製品における競争力は、ユーザーごとの会議データや利用パターンに基づくパーソナライズから生まれると述べています。

たとえば同じ会議でも、営業担当者、開発者、マネージャーでは必要な情報が異なります。

営業担当者には、顧客の懸念と次回の提案材料
開発者には、技術的な決定と未解決の課題
マネージャーには、進捗、リスク、担当者、期限
経営層には、複数部門に共通する傾向と意思決定材料

高速なベクトル検索が重要になるのは、各ユーザーの質問、権限、過去の行動に合わせて、膨大な会議データから異なるコンテキストをリアルタイムに取得する必要があるためです。

つまり、会議AIの次の段階は、全員に同じ要約を見せることではありません。それぞれの仕事に必要な知識とアクションを、必要な時に届けることです。

まとめ

Nottaの事例は、会議データの活用が、文字起こし、要約、コンテキスト検索という段階で進化していることを示しています。

3,000万時間を超える文字起こしデータを対象にRAGを提供するには、ベクトルを保存できるだけでは足りません。低レイテンシ、高い検索品質、同時実行、フィルタ、運用負荷、インフラコストをまとめて考える必要があります。

NottaはZilliz Cloudへ移行し、顧客事例によると次の成果を得ました。

検索レイテンシを1,000ms以上から約100msへ短縮
約10倍の検索性能改善
計算オーバーヘッドを最大80%削減
手動チューニングの負担を軽減
3,000万時間以上のデータを大きな中断なく移行

日本企業にとって特に重要なのは、会議AIを「議事録作成ツール」で終わらせず、企業内に蓄積される会話を検索可能な知識へ変える視点です。

営業、開発、サポート、経営などの会話を、権限を保ちながら横断的に検索できれば、過去の意思決定を探す時間を減らし、顧客理解や次のアクションにつなげられます。

Zilliz Cloudは、そのために必要な大規模ベクトル検索とRAGの検索レイヤーを支える選択肢の一つです。

参考

Scaling AI-Powered Meeting Intelligence: How Notta Achieved 10X Faster Search with Zilliz Cloud