概要
会議の録音、設計レビューの録画、問い合わせ窓口の通話記録など、社内には音声のデータが大量にあります。ところが、その多くは「聞き直す時間がない」「どこで何を話したか分からない」という理由で、保存されたまま使われていません。クラウドの文字起こしサービスを使えば手軽にテキスト化できますが、顧客との通話や未公開の設計の議論を社外のサービスに送ることは、情報管理の規程上認められないケースが少なくありません。
音声認識モデル(Whisper)を社内のサーバーで動かせば、音声を一度も社外に出さずに文字起こしを完結できます。テキストになった会議録や通話記録は、ほかの社内文書と同じようにナレッジとして検索でき、AIによる要約や問い合わせ対応にも使えるようになります。
オンプレミスでの文字起こしの全体の流れ、認識エンジンとモデルの選び方、精度を上げる運用、文字起こし結果を検索とAI活用につなげる方法、社外に出さないための確認点を順に解説します。
音声が活用されにくい理由と、文字起こしで変わること
音声データの活用が進まない理由は、主に次の3つです。
| 状況 | 文字起こしで変わること |
|---|---|
| 1時間の会議の要点を確認するのに、1時間聞き直す必要がある | テキストを検索し、該当箇所だけを読める |
| 「あの件はどの会議で決まったか」を誰も覚えていない | 過去の会議録を横断して、意味で検索できる |
| 通話の内容が担当者の記憶とメモにしか残らない | 通話記録を蓄積し、似た問い合わせへの過去の対応を探せる |
ポイントは、文字起こしそのものよりも、テキストになった後に検索・要約・再利用できる状態になること です。そのためには、文字起こしを単独のツールとして置くのではなく、社内のナレッジやAIの仕組みと同じ基盤の上でつなげておく必要があります。
全体の流れ
オンプレミスでの文字起こしは、次の流れで処理します。
[録音ファイル・録画ファイル・ブラウザでの録音] ↓ [音声の取り出しと変換:16kHz・モノラルのWAVへ] ↓ [無音の判定:無音なら認識せずに空文字を返す] ↓ [音声認識(Whisper):社内のGPUまたはCPUで実行] ↓ [テキスト(+発話区間ごとのタイムスタンプ)] ↓ ├ チャットで要約・議事録化 ├ ナレッジに登録して検索 └ 社内システムからAPIで呼び出し
音声の変換
Whisperは16kHz・モノラルの音声を入力とします。MP3やM4Aなどの圧縮形式、MP4やMOVなどの動画ファイルは、FFmpegで音声トラックを取り出して変換します。最初から16kHz・モノラルのWAVであれば変換は不要で、そのぶん処理が速くなります。ブラウザで録音する場合は、端末側で16kHz・モノラルのWAVにしてから送ると、サーバー側の変換を省けます。
無音の判定
Whisperには、無音や雑音だけの区間に対して、実際には話されていない文章を出力してしまう性質(いわゆる幻聴)があります。音量が一定の水準を下回る音声は認識にかけずに空の結果を返す、発話のない区間を音声区間検出(VAD)で除いてから認識する、といった前処理を入れることで、この問題を抑えられます。
認識エンジンの選び方
Whisperをオンプレミスで動かす実装として、代表的なものが2つあります。
| 項目 | whisper.cpp | faster-whisper |
|---|---|---|
| 実装 | C/C++による推論 | CTranslate2による推論 |
| モデル形式 | ggml形式 | CTranslate2形式 |
| 向く環境 | CPU、Apple Silicon(Metal) | NVIDIA GPU(CUDA)。CPUでもint8で動作 |
| 特徴 | 依存が少なく、配布しやすい | 同じモデルでも高速。VADを組み込める |
すでにNVIDIA GPUを搭載したAIサーバーがある場合はfaster-whisper、GPUのない環境や小型の端末ではwhisper.cppが選択肢になります。
DigitalBaseでは、配置されたモデルの形式とGPUの有無から、この2つを自動で選びます。両方の形式のモデルがある場合は、CUDAが使えればfaster-whisperを、使えなければwhisper.cppを選びます。管理画面から実際に使われているエンジンとデバイス(CUDAかCPUか)を確認できます。既定では社内で動くWhisperを使い、外部の文字起こしAPIに切り替える設定にした場合だけ音声が社外に送られます。
モデルの大きさの選び方
Whisperのモデルには、tiny・base・small・medium・largeといった大きさの段階があります。大きいモデルほど精度が上がり、処理時間とメモリ使用量が増えます。large相当の精度を保ちながら軽量化したdistil-largeのような派生モデルもあります。
選定の目安は次のとおりです。
- 短い発話・メモ程度:小さいモデルで十分なことが多い
- 会議・インタビューの議事録:中程度以上のモデル
- 専門用語が多い・正確な記録が必要:大きいモデル、またはGPUでの実行を前提にする
実際の処理時間は、GPUの性能、音声の品質、録音の長さで大きく変わります。導入前に、自社の代表的な録音を数本使って、精度と処理時間を確かめることをお勧めします。
精度を上げる運用
言語を固定する
Whisperは言語を自動判定できますが、短い発話や冒頭が無音の録音では判定を誤ることがあります。日本語の会議や通話が中心であれば、言語を日本語に固定すると認識が安定します。
語彙のヒントを与える
製品名・型番・社内の略語・取引先の名前などは、一般的な語彙にないため誤認識されやすい語です。Whisperには、認識を誘導するための初期プロンプトを与えられます。部署や用途ごとによく出る語をまとめておき、文字起こしのたびに渡すと、表記の揺れや誤変換を減らせます。
初期プロンプトの例(品質会議): 「不具合報告、是正処置、なぜなぜ分析、FMEA、主軸、ベアリング、トルク」
録音の品質を整える
認識精度は、モデルよりも録音の品質に左右されることが少なくありません。
- 会議室では、話者の近くにマイクを置く(部屋の隅の1台より、卓上の複数台)
- 空調や機械の音が大きい場所では、指向性のあるマイクを使う
- オンライン会議は、会議ツールの録音機能で各参加者の音声を直接録る
話者の区別について
Whisper自体は、誰が話したかを区別する機能(話者分離)を持ちません。通話のように「自社の担当者」と「お客様」の区別が重要な場合は、録音の段階で話者ごとに別のチャンネルに分けておき、チャンネルごとに別のファイルとして文字起こしする方法が確実です。ステレオの音声をそのまま渡すと、多くの実装ではモノラルに混ぜてから認識するため、話者の区別は失われます。
検索とAI活用につなげる
会議録をナレッジに入れて検索する
音声ファイルを社内文書と同じようにナレッジに取り込めば、文字起こしと分割・埋め込みが一度に行われ、PDFやWordの資料と並べて検索できるようになります。共有フォルダに会議の録音を置く運用にしておけば、フォルダ単位でまとめて取り込み、新しい録音が増えたときに差分だけを取り込み直すこともできます。
「先月の品質会議で、ベアリングの交換周期について何が決まったか」と聞くと、会議録の該当部分を根拠として回答が返ってくる状態を目指します。
チャットで要約してから残す
1本の録音を議事録にしたい場合は、チャットに音声ファイルを添付し、文字起こしの結果をもとに要約や決定事項・宿題の整理をAIに依頼します。録音が長く、文字起こしの全文がそのままではAIの入力に収まらない場合は、全文を会話の中だけの一時的な検索の対象にし、質問に関係する部分を探して渡すといった工夫が必要です。
整理が終わった会話は、そのままナレッジに取り込んでおくと、後から「議事録の決定事項」として検索できます。
社内システムからAPIで呼び出す
コールセンターの記録システムや社内の業務アプリから文字起こしを使う場合は、OpenAIのAudio APIと互換の形式で呼び出せるようにしておくと、既存のクライアントライブラリをそのまま使えます。
# 説明用の汎用コード(OpenAI互換のクライアントで社内のエンドポイントを呼ぶ) from openai import OpenAI client = OpenAI(base_url="https://<社内のAI基盤>/v1", api_key="<発行したAPIキー>") with open("call_20261105.wav", "rb") as f: result = client.audio.transcriptions.create( model="whisper-1", file=f, language="ja", prompt="製品名、型番、サポート窓口", response_format="verbose_json", # 発話区間ごとのタイムスタンプ付き ) for seg in result.segments: print(f"{seg.start:7.1f}s {seg.text}")
タイムスタンプ付きの形式で受け取れば、「問い合わせ内容を述べている区間」「対応を案内している区間」を後から切り出して、通話記録システムに保存するといった使い方ができます。APIキーごとに利用量を記録しておけば、どの部署・どのシステムがどれだけ使っているかも把握できます。
社外に出さないための確認点
オンプレミスで動かしていても、設定や運用次第で音声が外に出る経路は残ります。導入時に次の点を確認します。
| 確認点 | 内容 |
|---|---|
| 認識エンジンの設定 | 外部の文字起こしAPIに送る設定になっていないか |
| ブラウザでの録音 | ブラウザのマイクはHTTPS(またはlocalhost)でしか使えない。HTTPで運用する場合は録音済みファイルのアップロードで代替する |
| 端末側の録音アプリ | スマートフォンの録音アプリがクラウドに自動で同期していないか |
| 録音ファイルの保存先 | 共有フォルダのアクセス権が、会議の参加者や担当部署に限られているか |
| ナレッジの公開範囲 | 取り込んだ会議録を検索できる人の範囲が、元の録音を聞ける人の範囲と一致しているか |
| 保存期間 | 録音と文字起こしの保存期間を、社内の文書管理規程に揃えているか |
特に見落としやすいのが、ナレッジの公開範囲です。経営会議の録音を全社向けのナレッジに取り込めば、録音ファイルを厳重に管理していても、検索を通じて内容が広く読めてしまいます。録音の管理と同じ基準で、取り込む先のナレッジを分けます。
限界と注意点
- 文字起こしには誤りが含まれる:数値・固有名詞・否定の言い回しは特に誤りやすいため、重要な決定事項は元の録音で確認できるよう、文書から録音への参照を残しておきます。
- 個人情報が含まれる:通話記録には氏名・電話番号・住所が含まれます。ナレッジに入れる前に、必要に応じて伏せ字にする工程を設けます。
- 長時間の録音は処理に時間がかかる:取込を夜間にまとめる、GPUの空いている時間帯に実行するなど、ほかのAI処理と計算資源を取り合わない運用を考えます。
まとめ
会議や通話の録音は、社外に出さずに文字起こしできるようになることで、初めて検索とAI活用の対象になります。
- 社内で完結させる:Whisperを社内のGPU・CPUで動かし、外部APIに送る設定になっていないことを確認する
- 前処理を入れる:16kHz・モノラルへの変換、無音の判定、VADで幻聴を抑える
- 精度を上げる運用:言語の固定、語彙のヒント、録音環境の改善、話者ごとのチャンネル分け
- 使える形につなげる:ナレッジへの取込で検索可能にし、チャットで要約し、社内システムからはAPIで呼ぶ
- 公開範囲を揃える:取り込み先のナレッジを、元の録音と同じ基準で管理する
聞き直さなければ分からなかった音声が、文書と同じように探せて、AIに質問できる情報に変わります。