議事録作成に役立つローカル文字起こしとは？録音を社外のAIへ送らない方法

ローカル文字起こしとは、手元のPCで録音を文章にする方法です。話者識別を加えると、発言を「話者A」「話者B」のように分けて表示できます。

会議の録音を外部サービスへアップロードできなくても、文字起こしを諦める必要はありません。必要なAIモデルとプログラムをPCに用意し、録音をそのPCで処理する選択肢があります。AIモデルは、音声を認識するために使う学習済みのデータです。

私が個人で開発したアプリも、公開モデルを組み合わせて作っています。ここでは、その設計を例に自作の方法を紹介します。文字起こしと話者識別を別のAIに任せ、結果を結び付ける構成です。

発言の内容を文字にするAIと、発言者の切り替わりを調べるAIは、役割が違います。それぞれの結果を録音内の時刻で対応付けると、話者付きの文章になります。

開発したアプリでは、Whisperのlarge-v3-turboとCohere Transcribeを切り替えて使えます。Whisperはfaster-whisperという実行用ソフトウェアで動かします。Cohereも外部サービスへ音声を送るのではなく、取得したモデルをPC内で動かします。

私は、複数のモデルを比べたうえで、この組み合わせを選びました。処理の速さと認識品質のバランスを重視したためです。

Cohere Transcribe単体は、発言時刻と話者識別を出力しません。これは公式資料に明記されています。この開発例では別の処理で時刻を付け、Community-1の話者区間と照合します。Community-1は、必要なモデルを取得した後にインターネット接続なしで実行する方法が示されています。

録音を選んで処理を始めると、AIが文字起こしと話者分けを行います。人は出力を確認し、必要な箇所を聞き直したり、誤りを直したりできます。

細かな時刻を取得できなかった場合は、より大きな発話区間の時刻を使います。その際は、話者の切り替わりを確認するよう表示します。話者が付いていても、正しく対応しているかを人が確かめられる設計です。

JSONは、文章・発言時刻・話者情報をまとめて保存する形式です。Wordは、文章を読み返すための文書として書き出せます。

社内で使うときは、誰が誤りを直し、どこへ保存するかも決めておきます。自社に合う文字起こしの構成や確認・保存の流れを整理したい場合は、無料相談をご利用いただけます。

話者Aを実名へ変える際は、人が声を確かめてから登録します。短い相づちや声の重なりは誤判定しやすいため、話者の判断が難しい箇所を確認候補として表示します。アプリ内再生が使えない環境では、表示時刻を頼りに別のプレーヤーで聞き直せるようにしています。

公開されている学習済みモデルを使い、録音の読込みから確認・保存までをつなぐアプリを作ります。音声認識AIそのものを一から学習させる作業は不要です。

開発担当者に依頼するほか、コードを作成・修正できるAIに相談しながら、自分でアプリを作る方法もあります。必要な機能を伝え、AIが提案した構成やコードを試し、動きを確かめながら進めます。

AI-DLCは、AIに開発の計画・実装・テストを進めさせ、人が要所で確認・判断する開発方法です。このようなアプリに取り入れるなら、「録音をPC内で処理する」「話者ごとに表示する」「修正を保存して開き直せる」を完成の条件にし、AIと順に作って確かめます。

詳しい進め方は、関連記事「AI-DLCの進め方・実践手順とは？」で図解しています。

モデルを取得する初期準備では通信を使う場合があります。一方、会議で使うときは、準備済みモデルと録音をPC内で読み込みます。開発用AIの利用先と、完成したアプリでの録音の処理先は別に確認します。

私が開発したアプリには、GPU版に加え、GPUを使わないCPU版もあります。CPUは、一般的なPCの計算処理を担う部品です。GPUを搭載していないPCでも、文字起こしと話者識別を行えます。CPU版は処理に時間がかかるものの、私の利用では実用の範囲に収まっています。

開発では、認識モデルごとに必要なソフトウェアを分け、相互の影響を減らしています。重いAI処理は画面の操作と分け、進捗の表示や中断を行えるようにしています。モデルの選定に加えて、画面や保存の処理を組み立てる部分です。

Community-1などは、取得前に利用条件への同意やアカウントの準備が必要です。会社で使う場合は、モデルと実行用ソフトウェアの利用・配布条件も確認します。試作の範囲は、PCとモデルの準備から、確認・保存までを含めて決めます。

最初は、機密を含まない短い会話で試します。話者付きの文章を表示し、聞き直して直し、保存した結果を開けるところまでを、小さな試作の範囲にします。

例えば、同僚と「会議室は予約しましたか」「まだです。これから予約します」と交互に話して録音します。発言内容と、話者が切り替わる箇所を確認できます。短い録音は基本動作の確認に使い、実際の会議への適用は録音の長さや参加人数に合わせて確かめます。

開発用AIへの依頼例：「会議の録音を社外へ送らず、このPCで文字起こしするアプリを作りたいです。誰の発言かを分け、気になる箇所を聞き直して直し、Wordに保存できるようにしてください。まず必要な機能、使うモデル、作る順序、動作の確認方法を提案してください。機密のない短い会話で試しながら進めます。」

クラウドの開発用AIへ相談するときは、実際の会議録音や機密資料を渡さず、架空の会話で作成・テストします。完成したアプリがローカルで動くことと、開発中にAIへ渡してよい情報は、分けて考えます。

比べるのは、聞き間違いや話者の修正にかかる手間と、処理の待ち時間です。文字が合わなければ録音条件や認識モデルを、話者が違えば話者識別と時刻の対応を見直します。問題を分けると、次に直す箇所を決めやすくなります。

ローカル処理でも、保存先がクラウドへ自動同期されれば、録音や文章が外部に送られる場合があります。会議で使う前に、処理先に加えて保存先、閲覧できる人、録音の社内ルールをIT担当者と確認します。

録音を外へ送れない場合にも、自社の使い方に合う文字起こしを作る余地はあります。まずは話者付きの文章と聞き直し・保存に絞り、現場で使えるかを確かめるところから始められます。

公開モデルの役割・実行方法と、AI-DLCの説明に用いた公式資料です。個人開発したアプリの設計を、自作の例として紹介しています。

1. faster-whisper公式資料 — WhisperをCPU・対応GPUで動かす方法と、単語ごとの時刻の取得。
2. pyannote Community-1公式モデル資料 — 話者ごとの発言区間、話者数の指定、利用条件、ローカルでの実行。
3. Cohere Transcribe公式モデル資料 — 公開モデルを用いたローカル実行と、日本語音声の文字起こし。
4. Cohere Transcribe公式機能説明 — 音声から文字を出力する役割と、時刻・話者識別を備えないこと。
5. LM Studioのオフライン利用公式資料 — FAQで触れた、文章をまとめるAIをPC内で動かす場合の準備。
6. AWS公式：AI-Driven Development Life Cycle — AIが計画・確認質問・実装を進め、人が重要な判断を行う開発方法。

確認日：2026年10月23日。公開資料ではモデルの機能とローカル実行を確認しています。アプリの処理・保存、モデル比較とCPU版の使い勝手は、私の個人開発・利用の範囲です。