LiveBrief

LiveBriefは、対面の商談やヒアリング中の音声をリアルタイムに文字起こしし、その瞬間にいちばん必要な支援を1枚のカードで提示するスマホ向けPWAです。開発者本人の個人利用を想定したMVPで、公開URLで稼働してはいますが、一般向けの提供は行っていません。

解決する課題

重要な対話の最中は、聞きながら理解し、メモを取り、次の回答を組み立てる作業が同時に進みます。技術商談や専門家ヒアリングではさらに、知らない用語と、即答を求められる質問がその場で降ってきます。

既存の文字起こしアプリや議事録AIが担うのは、主に終わった会話の記録と要約です。会話のさなかに「次に何を言うか、何を確認するか」を支える道具は、まだ薄いままでした。

そこでLiveBriefは、「記録するアプリ」ではなく「会話中の判断と応答を支えるアプリ」として設計しました。会議アプリへのボット参加は対象外で、対面と現場での利用だけを想定しています。

主な機能

セッション中は、日本語の音声をリアルタイムに文字起こしします。確定前の暫定文字列は薄く、確定した発話は濃く表示し、確定した発話の差分だけが分析へ回ります。分析からは、初出の専門用語の解説、論点と合意事項の要約更新、自分宛ての質問の検出、回答候補の生成が返ってきます。

ただし、これらを画面に同じ大きさで並べることはしません。縦持ちのスマホで会話しながら読み切れる量は多くないからです。その瞬間に最重要の1件だけを優先カードとして画面上部に出し、残りは下部のタブへ退避させます。優先順位の最上位は自分への質問と回答候補で、警告、初出用語、要約がそれに続きます。回答候補には15秒回答、慎重な回答、確認質問の3モードがあり、質問の検出から表示までは5秒以内を目標にしています。

回答候補の根拠には、事前の登録内容と会話そのものを使います。セッション前に会議の目的、自分の役割、資料、想定質問、言ってはいけない表現を事前コンテキストパックとして登録でき、回答カードには引用した根拠と確信度が添えられます。

それでも、回答候補は表示するだけです。自動で発話や送信をする経路は設けておらず、採用するかどうかの判断は常に利用者が行います。セッション中の操作も開始、一時停止、重要マークの3ボタンが中心で、記録に残したくない話題の前には、音声を取得も送信もしないプライベート区間を1タップで挟めます。

セッションを終えると、全文、3段階の要約、決定事項、担当と期限付きのToDo、未解決論点、用語集、フォローアップ文案などの成果物を構造化して生成する設計です。

開発の背景

文字起こしや議事録のAIは、すでに数多くあります。それでも、会話が終わってから助けてくれる道具と、会話の最中に助けてくれる道具は別物です。BenriWorksが欲しかったのは後者で、企画の原則には「最大の議事録」ではなく「次の行動を変える最小の支援」を作る、と置きました。議事録、ToDo、報告メールを終了後に別々に作り直す再作業を減らす成果物生成は、この原則を補う位置付けです。

技術と設計

Next.js 15とReact 19、TypeScriptを基盤に、UIをTailwind CSS v4で組んだPWAです。認証とデータベースはSupabaseで、全テーブルに行レベルのアクセス制御(RLS)を適用しています。

文字起こしにはGoogle CloudのSpeech-to-Text V2を使います。このAPIのストリーミング認識にはブラウザから直接接続できないため、あいだにCloud Run上の最小のリレー(WebSocketをgRPCへ中継するサーバ)を置きました。音声はこのリレーのメモリを通過するだけで、ディスクにもログにも書きません。ホスティングのVercelにもSupabaseにも音声は流れず、保存されるのは確定した文字列と構造化データだけです。生音声を既定で保存しないことが、プライバシー設計の出発点です。

分析にはGemini APIを使います。常時回る差分分析は軽量モデルが担い、上位モデルは利用者が回答候補を求めてタップしたときにだけ呼びます。1回の呼び出しで用語、要約差分、質問、決定事項をまとめて構造化出力させ、会話全文の再送はしません。

設計の手間の多くは、外部APIの都合の吸収に費やしました。Speech-to-Textのストリーミング認識は1ストリームあたり約5分が上限で、さらに無音が約10秒続くとストリームが強制切断されます。リレーは上限の手前で新しいストリームを先行して開き、古いストリームの最終結果を受け取ってから切り替えることで、発話の連番を途切れさせないままローテーションします。無音に対しては、切断される前にリレーが自らストリームを閉じ、次の音声で透過的に再開します。採用したモデルと日本語の組み合わせでは話者分離が使えないことも検証中に判明したため、未対応の設定を自動で無効化して文字起こしを続ける処理を入れました。

費用の制御はサーバ側で行います。セッションには予算上限を設定でき、超過するとサーバは分析APIを呼ばずにHTTP 429を返します。クライアントはこれを受けて分析だけを止め、文字起こしと保存は最後まで続けます。一度解説した用語はキャッシュし、同じ語では生成APIを呼び直しません。

現在の状態と既知の課題

現在の状態はプロトタイプです。冒頭に書いたとおり開発者本人の個人利用を想定したMVPで、一般向けの提供は予定していません。

Phase 0の検証記録では、約7分半の連続セッション1回の実測で、発話の終了から確定表示までの遅延はp50で649ms(目標は2秒以内)、途中1回のストリームローテーションをまたいだ発話連番の欠落は0件でした。同じセッションの費用は1時間換算で$1.19(目標は$1.25以内)です。

ただし、検証はまだ序盤です。重要語の認識率テスト、画面ロックや着信をまたぐ実機での検証、60分の連続セッション、概算費用と実請求の突合は未実施です。話者分離は前述のとおりMVPでは見送り、発話テキストからの宛先判定で代替しています。