音声の文字起こしをVPSで動かす

レン

会議の録音を文字起こししたいんだけど、外部サービスに音声を上げるのは気が引けて…

プロクラ

その懸念はもっともだね。音声認識モデルは自分のサーバーでも動かせるから、外に出さずに処理できるよ。社内の会話や顧客との通話を扱うなら、この選択には十分な理由がある。

CPUだけで動くのか

動きますが、実時間より遅くなるのが普通です。1時間の音声に、それ以上の処理時間がかかると考えてください。会議のあとでまとめて回すような使い方なら問題になりませんが、話しながら文字にする用途には向きません。ここでも「誰が、どれくらい待つのか」が判断の分かれ目になります。

プロクラ

動くよ。ただし実時間より時間がかかると考えて。1時間の音声に対して、それ以上の処理時間がかかることが普通なんだ。モデルのサイズと、CPUの性能次第で大きく変わる。

レン

遅いのは困るなあ…

プロクラ

リアルタイムで字幕を出す用途には向かないね。でも「録音を投げておいて、後で結果を受け取る」使い方なら十分実用的だよ。夜のうちに処理させておく、という運用もできる。

構成のポイント

• 処理は必ず非同期にする。Webのリクエストの中で処理すると、応答待ちでタイムアウトする
• 処理待ちの音声をためる仕組み（キュー）を用意する
• モデルのサイズを選べる。小さいほど速く、大きいほど正確
• メモリは選ぶモデル次第。小型なら数GBから
• 同時に複数の処理を走らせない。CPUを食い合って全体が遅くなる

扱うデータへの配慮

音声には、書き起こす予定のない会話も含まれます。会議の前後の雑談や、同席者の発言も一緒に録られています。文字にした時点で検索できる形になるので、保存期間と閲覧できる人の範囲を、録音そのものより慎重に決めてください。

ウィルスン

…音声ファイルとその書き起こし。会議の中身、顧客の声、時には個人情報そのもの。サーバーに置いたまま忘れられているそれらは、ワタシにとって上等な獲物だ。

プロクラ

処理が終わった音声ファイルは、置きっぱなしにせず消す仕組みまで作っておこう。「外に出したくないから自前で処理する」のに、自分のサーバーに溜め込んでいては本末転倒だからね。

実際の精度と、後処理

プロクラ

文字起こしは万能ではないよ。固有名詞、専門用語、複数人が同時に話す場面は苦手だ。そのまま議事録にはならないと考えて、確認して直す前提で使うのがいい。

• 録音の質が結果を大きく左右する。マイクの位置が効く
• 固有名詞は間違いやすい。よく出る語は一括で置換する仕組みを用意すると楽
• 話者を分ける処理は別の仕組みが要る
• 要約させるなら、文字起こしの結果を人が一度確認してからにする

時間の目安を運用に組み込む

プロクラ

処理にどれくらいかかるかは、モデルの大きさとCPUで大きく変わる。最初に自分の環境で1本測って、その時間を前提に運用を組もう。「終わったら通知する」形にしておけば、待ち時間は問題にならないよ。

• 受け付けたら、まず「受け付けました」と返す
• 処理は順番待ちの列に入れ、1つずつ進める
• 終わったら通知する（メールやチャットへ）
• 失敗したときも通知する。黙って消えるのが一番困る

レン

待てる用途なら十分使える。終わった音声は消す仕組みまで作る。