Yodo Labs
← ケーススタディ一覧に戻る

公開日 2026年3月1日

リアルタイム会議コパイロットのインターフェース：アンビエント質問検出とAIコンテキスト提案

アンビエント質問検出を備えたリアルタイム会議コパイロットの構築

課題

クライアント対応の技術チームは、会議後ではなく、会議中のリアルタイムなAI意思決定支援を必要としていました。既存の代替手段は、会話中にチャットボットへ手動で質問を入力する方法（認知負荷が高く、文脈が途切れる）か、会議後の文字起こしに頼る方法（記録には有用だが、会議中の意思決定には無力）のどちらかしかなく、いずれも不十分でした。

ソリューション

Yodo Labs は、リアルタイム会議コパイロットを設計・構築しました。OSレベルで音声をキャプチャし、文字起こし上で質問を検出した時点で内部文書から関連するコンテキストを能動的に提示するアンビエントシステムであり、会議中にユーザー操作は一切不要です。

成果

  • 質問完了から約1秒以内にコンテキストを表示
  • 会議中の操作不要、完全アンビエント動作
  • Zoom、Teams、Google Meet、電話で同一コパイロットスタックが動作。会議室の音声をデバイスに入力すれば対面会議にも対応
  • セッション単位のクラウド処理、サードパーティによるデータ保持なし
  • 会議後のフォローアップを削減。後追いではなくその場で回答可能に

クライアントの背景

クライアントは、複雑な技術的議論をクライアント対面で日常的に行うテクノロジーコンサルティングファームです。ソリューションアーキテクトやテクニカルリードは、製品仕様、システムアーキテクチャ、実装制約にまたがる詳細な質問に日々対応しており、越境案件では複数言語にわたることも少なくありません。

課題

重要な技術会議では、会話は高速に進行します。クライアントから予想外の質問が出たとき、コンサルタントは正確で根拠のある情報を数秒以内に回答しなければなりません。何かを調べるために間を空ければ流れが途切れ、曖昧に答えれば信頼を損ないます。

クライアントのチームは2つのカテゴリの回避策を試みましたが、いずれも不十分でした。

リアルタイムだが認知負荷が高い： 一部のチームメンバーは、会議中にChatGPTなどのツールを開き、質問が出るたびに手動で入力していました。このアプローチは、聞くこと・要約すること・入力することを同時に要求し、認知負荷が高くなります。AIクエリの品質（会話の文脈が欠落）とコンサルタント自身の会議への集中力の両方が低下しました。

低負荷だがリアルタイムではない： 他のメンバーは、会議の録音や事後の文字起こしに頼っていました。文書化やレビューには有用でしたが、質問が発せられたまさにその瞬間、最も支援が必要な時点では何のサポートも提供しません。情報は残りますが、会議中の意思決定速度は向上しませんでした。

会議プラットフォームのAI機能（Zoom AI Companion、Google Gemini in Meet）は会議後のサマリーやアクションアイテムを提供しましたが、核心的な要件であるリアルタイムの意思決定支援には対応していません。さらに、クライアントのチームは案件によってZoom、Microsoft Teams、Google Meet、電話、場合によっては対面会議と複数の通信ツールを使い分けており、単一プラットフォームのAI機能では普遍的なソリューションになりえませんでした。

Yodo Labs のソリューション

Yodo Labs は、すべてのコンポーネントがリクエスト/レスポンスではなく連続的なデータフローで動作するストリーミングアーキテクチャに基づく、三層構成のリアルタイム会議コパイロットを構築しました。

アーキテクチャ概要

システムは、リアルタイムパイプラインにおけるそれぞれの役割に特化した三つの層で構成されます。

  1. ネイティブデスクトップ・コンパニオンアプリケーション: OSレベルの音声キャプチャ
  2. ストリーミング・リレーサービス: リアルタイム音声認識と質問検出
  3. Webベースのコパイロットインターフェース: 文字起こし、検出された質問、AI生成コンテキストのアンビエント表示

リアルタイム・ストリーミングパイプライン

中核的なエンジニアリング課題はレイテンシでした。コパイロットがライブ会話中に有用であるためには、質問完了からコンテキスト提案が画面に表示されるまでの時間が約1秒でなければなりません。これは従来のリクエスト/レスポンス型アーキテクチャでは実現できず、すべての層でストリーミング処理が必要です。

1) OSレベル音声キャプチャ（デスクトップ・コンパニオン）

コンパニオンアプリケーションは、プラットフォームネイティブの音声API [1] を使用してOSレベルでシステム音声をキャプチャし、ローカルWebSocket接続を通じてコパイロットクライアントに音声フレームをストリーミングします。特定のアプリケーションにフックするのではなくシステムの音声出力をキャプチャするため、同一のコパイロットスタックが各種ビデオ会議プラットフォームやデバイス経由の電話に対応し、特定の通信ツールとの統合は不要です。対面会議では、マイク入力や会議室AV機器をデバイスに接続することで、同じパイプラインが適用されます。

コパイロットクライアントは音声をエンコードし、文字起こしのためにクラウドリレーサービスに送信します。音声はストリーミングセッション内で一時的に処理され、セッション終了後にサードパーティサービスに音声データが保持されることはありません。

2) ストリーミング・リレーサービス：音声認識と質問検出

リレーサービスは音声チャンクを受信し、連続的なストリーミングセッションでクラウド音声認識エンジンに転送します [2]。完全な発話を待つのではなく、中間結果が到着するたびに処理し、フロントエンドがリアルタイムで逐語的に文字起こしを表示できるようにします。

複数言語を含むセッションでは、ユーザーがセッション開始時に想定される言語セットを設定します。リレーサービスはこの設定に基づいて、適切なリージョンエンドポイントとSTTモデルバリアントを事前に選択し、文字起こし精度・言語カバレッジ・レイテンシのバランスを取ります。セッション内では、クラウドSTTエンジンが設定された言語セット全体で自動言語検出を行います [2]。

リレーはまた、このシステムを単なる文字起こしツールと区別するコンポーネント、アンビエント質問検出を実行します。専用の検出パイプラインがストリーミング文字起こし出力上で動作し、会議後ではなく、またユーザーが手動でフラグを立てるのでもなく、質問が文字起こしに現れた時点で検出します。

検出ロジックは言語的多様性に対応しています。各スクリプトの疑問符、ラテンアルファベット言語の疑問文パターン、CJK言語の文末疑問助詞（日本語の「か」、中国語の「吗」「呢」など）を処理します。設定可能な蓄積バッファと最小長閾値により、部分的な文字起こしやフィラースピーチからの誤検出をフィルタリングします。

質問が検出されると、システムはユーザーが事前にアップロードした参照文書（製品仕様書、アーキテクチャ図、提案書、過去の会議メモ）に対する検索ステップを即座にトリガーし、ファウンデーションモデルAPIを使用してコンテキストに基づく提案を生成します。レスポンスはコパイロットインターフェースにストリーミングバックされ、検出された質問とともに表示されます。通常、質問完了から約1秒以内です。

3) コパイロットインターフェース

Webベースのインターフェースは、アンビエントで周辺的な使用を想定して設計されています。セカンダリモニターや画面の一部に表示し、会議中の操作は不要です。三つの同期パネルを表示します。

  • 逐語的にレンダリングされるリアルタイム文字起こし
  • 検出された質問と、提案されたコンテキスト・キーワードを表示する質問パネル
  • 会議後や休憩時にさらに深く探索するためのオプションのチャットパネル

すべてのパネルはストリーミング接続で更新されます。インターフェースは意図的にミニマルに設計されています。会議中、ユーザーの注意はツールではなく会話に向けられるべきです。

データ処理とセッションライフサイクル

システムは、クライアントの社内セキュリティレビューを満たすよう設計されました。音声はユーザーのデバイスでローカルにキャプチャされ、リアルタイム文字起こしのためにクラウドSTTサービスに一時的にストリーミングされます。アクティブなストリーミングセッションの終了後、サードパーティサービスに音声データや文字起こしデータが保持されることはありません。文書検索は、クライアントのインフラストラクチャ内に保存されたプリインデックスコンテンツに対して動作します。セッション録画や文字起こしは、クライアント自身の環境にのみ、既存のデータガバナンスポリシーに基づいて保持されます。

成果

コパイロットは、概念実証（PoC）としてクライアントのソリューションアーキテクチャおよびテクニカルコンサルティングチームに納品されました。

  • リアルタイムの意思決定支援： 質問完了から約1秒以内に関連コンテキスト提案が表示され、コンサルタントはフォローアップメールに先送りすることなく、会話中に根拠のある情報で回答できるようになりました。
  • ゼロ運用オーバーヘッド： アンビエントかつハンズフリーの設計により、チームの会議運営方法に変更は不要でした。新しいボタンを押す必要も、チャットウィンドウへの切り替えも、会議後の処理ステップもありません。
  • クロスプラットフォーム対応： OSレベルの音声キャプチャにより、単一の通信プラットフォームへの依存を排除。リモート会議をツール横断でカバーし、会議室の音声をデバイスに入力すれば対面の場面にも対応しました。
  • データガバナンス： セッション単位のクラウド処理でサードパーティによるデータ保持がないアーキテクチャが、クライアントの社内セキュリティおよびデータガバナンスレビューをクリアしました。
  • 拡張の基盤： モジュラー型ストリーミングアーキテクチャにより、コアパイプラインの再設計なしに追加チームや隣接ユースケース（例：越境会議のリアルタイム通訳）への展開が可能な基盤を確立しました。

パイプラインアーキテクチャを選択した理由: エンドツーエンド Speech-to-Speech との比較

上述のSTT-to-text-LLMパイプラインに決定する前に、Yodo Labs はエンドツーエンドの Speech-to-Speech モデルを代替候補として評価しました。商用サービスとしてOpenAI Realtime API [3]、オープンソースモデルとしてMoshi [4]（Kyutai）、GLM-4-Voice [5]（智譜AI）、Llama-Omni [6] を検証しました。

エンドツーエンドの Speech-to-Speech モデルは、中間的な文字起こしやテキスト生成ステップを排除することでレイテンシ面の優位性を提供し、一部の商用実装ではファンクションコーリングや外部ツール連携もサポートしています [3]。しかし、本ユースケースにおける評価では、パイプラインアーキテクチャの方が検索品質、中間処理（文字起こしストリーム上での質問検出など）、構造化出力生成においてより優れた制御を提供しました。専用の音声認識エンジンとテキストベースの言語モデルを組み合わせるパイプラインは、より優れたモデルが利用可能になった際に個別のコンポーネントを独立してアップグレードまたは置換することも容易です。この評価が、納品システムのアーキテクチャ選択に直接反映されました。

Speech-to-Speech アーキテクチャが成熟していくにつれて、特に推論の深さと多言語対応において、将来のイテレーションではより統合的なアプローチを採用できる可能性があります。現在のアーキテクチャはこの移行を見据えて設計されています。層間のストリーミングインターフェースは抽象化されており、STT-to-text-LLMパイプラインをエンドツーエンドモデルに置換する場合、リレーサービスの変更は必要ですが、音声キャプチャやフロントエンド層への変更は不要です。

参考文献

  1. Apple ScreenCaptureKit, 音声キャプチャドキュメント. developer.apple.com/documentation/screencapturekit
  2. Google Cloud Speech-to-Text V2, ストリーミング認識. cloud.google.com/speech-to-text/v2/docs
  3. OpenAI Realtime API. platform.openai.com/docs/guides/realtime
  4. Défossez, A. et al., Moshi: a speech-text foundation model for real-time dialogue. Kyutai. github.com/kyutai-labs/moshi
  5. GLM-4-Voice, エンドツーエンド音声モデル. 智譜AI. github.com/THUDM/GLM-4-Voice
  6. Fang, Q. et al., LLaMA-Omni: Seamless Speech Interaction with Large Language Models. github.com/ictnlp/LLaMA-Omni