ローカルLLMで文字起こし｜会議の録音を外に出さずに文字にする方法

ローカルLLMでの文字起こしとは、会議の録音を社外のクラウドに送らず、自社のPCの中で文字にして議事録の形まで整えることです。文字にするのはWhisper系の音声認識モデル、誤変換の手直しや要約を受け持つのがローカルLLMという2段構成で、どちらもPCの中だけで動かすことが出来ます。ただ、社内で使い続けるには、録音データの置き場所と消し方、担当者が替わったときの引き継ぎまで決めておく必要があります。自社で組むか、既製のサービスに任せるかは、その運用を誰が担えるかで決まってくるでしょう。

ローカルLLMそのものの仕組みやメリット、動かせるモデルの一覧はローカルLLMとは何かにまとめてありますので、ここでは会議の録音を文字にする場面に絞ってお話しします。

ローカルLLMの文字起こしは、文字にする役と整える役の2段構成

音声を文字に変えるのはLLMではなく、Whisperのような音声認識モデルの仕事になります。OpenAIが公開しているWhisperは、READMEで汎用の音声認識モデルと説明されており、コードと重みはMITライセンスで配布されています。OllamaでLLMを動かしても、それだけで録音が文字になるわけではありません。OllamaのFAQにも音声の文字起こしについての記載は見当たらず、2つの道具を組み合わせて使う形が現実的です。

役割を分けると、全体の流れは次のようになります。

1. 会議の録音ファイルを、文字起こしをするPCに置く
2. Whisper系のモデルで、録音をそのまま文字にする（話し言葉のままの文字起こし）
3. 必要なら話者分離の道具で、誰がどこを話したかを分ける
4. ローカルLLMに文字を渡し、誤変換の手直し、要約、議事録の形への整形をさせる
5. 人が録音や元の文字と突き合わせ、議事録として確定させる

2段に分ける利点は、それぞれの役に向いた道具を別々に選べることにあります。文字にする精度を上げたいときは音声認識のモデルを、議事録の書きぶりを変えたいときはLLMとその指示文を替えれば済みます。反対に、どちらか一方で全部をこなそうとすると、うまくいかなかったときにどこを直せばよいか分かりにくくなってしまいます。最初に役割の線を引いておくだけで、後の調整がずっと楽になるでしょう。

録音も文字も社外に出ない仕組み（情報漏洩対策）

ローカルで処理する一番の理由は、録音と文字起こしの結果を社外のサーバーに送らずに済むことにあります。Whisperもfaster-whisperも、モデルを手元に置いてしまえば、文字起こしの処理そのものはPCの中で完結します。整える役のOllamaも、公式FAQで、ローカルで動かす場合はプロンプトやデータを同社が見ることはないと説明しています。クラウドの文字起こしサービスのように、録音ファイルをアップロードする工程そのものがなくなるわけです。

ただし、ローカルの道具でも外とつながる場面はいくつか残ります。Ollamaは手元で動かす使い方のほかに、モデル名の末尾が「:cloud」のクラウドのモデルを選ぶと、Ollamaのサーバーで処理する仕組みも持っています。社内で使うなら、クラウドのモデルを選べないように最初から機能を切っておきましょう。公式FAQでは、環境変数OLLAMA_NO_CLOUD=1の設定でクラウド機能を止められると案内されており、止めるとログに「Ollama cloud disabled: true」と表示されます。

もう1つは、ネットワークへの公開設定です。Ollamaは既定で127.0.0.1のポート11434で待ち受けるため、そのPCの中からしか使えない状態になっています。複数人で使おうとして公開先を変えると、同じネットワークの別の機器からも届くようになり、録音を文字にした内容を誰が読めるかの範囲が広がってしまいます。

オフライン・ネットなしで動かすには

モデルと道具をそろえた後は、ネットにつながない状態でも文字起こしと整形を続けることが出来ます。ただし、最初のインストールとモデルのダウンロードの時だけはネットが要ります。kotoba-whisperのモデルはHugging Faceのページから、ローカルLLMのモデルはOllamaのライブラリから取得する流れになります。Ollamaも、モデルを取得した後は手元で動きますが、macOSとWindowsでは更新を自動でダウンロードする仕組みのため、その時には通信が起きます。

完全に切り離した端末で使いたい場合は、ネットにつながる別のPCでモデルを用意し、社内の決めた手順で持ち込む形になります。持ち込みの手順を決めないまま始めると、担当者ごとに入れ方がばらばらになりかねません。オフラインで動くことと、運用の手順が決まっていることは別の話だと考えておいてください。

文字にする役：Whisper・faster-whisper・kotoba-whisperの選び方

迷ったら、GPUのない事務用PCではfaster-whisper、日本語の会議が中心ならkotoba-whisperも試す、という順で選ぶのが無理のない始め方になります。3つは別々の道具ではなく、Whisperをもとにした親戚のような関係にあります。

• Whisper（OpenAI）：本家の実装です。実行にはffmpegというコマンドの道具を別に入れる必要があり、長い音声は30秒の窓をずらしながら処理するとREADMEに書かれています。
• faster-whisper（SYSTRAN）：WhisperをCTranslate2という仕組みで作り直したものです。MITライセンスで、ffmpegを別に入れなくても動き、CPUで8ビットに量子化して動かす例もREADMEに載っています。
• kotoba-whisper-v2.0（Kotoba Technologies）：Whisper large-v3を教師にして作った日本語向けの蒸留モデルです。Apache-2.0ライセンスで、ReazonSpeechという日本語の音声データで学習されています。

速さについては、どれも提供元の記載にとどまります。faster-whisperのREADMEには、同じ精度で本家のWhisperより最大4倍速く、使うメモリも少ないとあり、kotoba-whisper-v2.0のモデルカードには、large-v3より6.3倍速く、誤り率はlarge-v3と同程度に低いままだと書かれています。いずれも提供元の自己申告で、互いに比べられる数字ではありません。自社の会議でどれだけ速いかは、実際の録音で試してみるまで分からないと考えるのが安全です。

本家のWhisperのREADMEには、モデルの大きさごとに必要なGPUメモリの目安も並んでいます。tinyとbaseが約1GB、smallが約2GB、mediumが約5GB、largeが約10GB、turboが約6GBという値で、いずれも提供元が示す目安になります。turboはlarge-v3を速くした版で、精度の低下はわずかだと説明されていますが、翻訳用には学習されていません。日本語の会議を日本語のまま文字にする用途であれば、この点は気にしなくても大丈夫でしょう。

日本語の精度：Whisper large-v3とkotoba-whisperをどう比べるか

日本語の精度は、公開されている数字よりも、自社の録音で比べた結果を信じたほうが確かです。WhisperのREADMEには、精度は言語によって大きく変わるとあります。kotoba-whisperはlarge-v3を土台に日本語のデータで作られているものの、先ほどの誤り率の話も提供元の説明です。

比べるときは、同じ録音を2つのモデルにかけ、次の点を見てみてください。

• 社名、商品名、取引先の名前など、固有名詞がどれだけ正しく出るか
• 数字や日付、金額の聞き違いがないか
• 相づちや言いよどみが残りすぎて、読みにくくなっていないか
• 複数人が同時に話した部分で、文字が抜けたり混ざったりしていないか

試す録音は、会議室のマイク1本で録ったもの、オンライン会議から取り出したもの、と条件の違うものを2〜3本用意すると差が見えやすくなります。社外秘の内容が入っていない社内勉強会の録音などを使えば、試験の段階で扱いに悩むこともありません。

整える役：Ollamaで動かすローカルLLMによる要約・誤変換の校正

文字起こしの結果は、話し言葉のままで読みにくいため、ローカルLLMに整えてもらう工程を挟むと議事録として使いやすくなります。Ollamaなら、Qwen、Gemma、gpt-ossなどのモデルを手元のPCで動かせます。頼む仕事は、大きく分けて次の3つです。

• 誤変換の手直し：社名や専門用語の聞き違いを、文脈から正しい表記に直させる
• 整文：えー、あのー、といった言いよどみを除き、読める文に整えさせる
• 要約と整形：決まったこと、宿題、次回までに確かめることを抜き出させる

3つを1回の指示でまとめて頼むより、手直しと整文を先に済ませ、その結果から要約を作らせるほうが確かめやすくなります。どこで内容が変わったかを後から追えるからです。長い会議では、議題ごとに文字を区切って渡すと、1回あたりの確認の量も減らせます。

議事録の出力形式とプロンプト（決定事項・宿題・未決事項）

議事録の形は、社内で使っている書式に合わせて最初に決めてしまうのが近道です。LLMへの指示文（プロンプト）には、次のような項目を入れておくと、毎回同じ形で出てきます。

• 会議名、日付、参加者（話者分離の結果に名前を当てはめたもの）
• 決定事項：誰が何を決めたか
• 宿題：担当者と期限
• 未決事項：次回に持ち越した論点
• 原文にない内容は書かないこと、聞き取れない箇所は「不明」と残すこと

Ollamaには、答えの形をJSONの項目で決めて返させる構造化出力の機能もあります。公式ドキュメントでは、決まった項目のデータを確実に取り出す用途が挙げられており、議事録の項目を毎回そろえたい場合に役立ちます。この機能はクラウド版では対応しておらず、ローカルで動かす場合のものと書かれています。

指示文の最後に、原文にない言葉を足さないよう念を押しても、LLMが補ってしまうことはあります。整えた後の文章は、元の文字起こしと並べて確かめる前提で使ってください。

PCスペック・メモリの目安とモデルサイズの選び方

文字にするだけなら事務用のノートPCでも動かせますが、整える役のLLMまで同じPCで動かすなら、メモリに余裕のある機械が要ります。faster-whisperのREADMEにはCPUで動かす例があり、GPUのないPCでも小さいモデルから試すことが出来ます。GPUで動かす場合は、CUDA 12用のcuBLASとcuDNN 9という部品をそろえる必要があります。

整える役のLLMは、モデルのファイルだけでも数GBから十数GBになります。Ollamaのライブラリに表示されているダウンロードの大きさは、qwen3.5の9bが6.6GB、gpt-ossの20bが14GB、gemma4の26bが約16〜19GBです。gpt-oss-20bは16GBのメモリで動くよう設計されているとOpenAIは説明していますが、これも提供元の記載となります。実行するときは、会話の長さに応じた分のメモリがさらに加わる点にも気をつけてください。

文字起こしと整形を同じPCでするなら、一度に両方を動かさず、文字起こしを終えてから整形に移る順番にするとメモリの取り合いを避けられます。PCを選ぶときの目安をまとめると、次のようになります。

• 文字にするだけ：GPUのない事務用PCでも、faster-whisperの小さめのモデルから試せる
• 整形まで1台で：LM Studioの動作要件ではメモリ16GB以上が推奨で、モデルの大きさに合わせてそれ以上を考える
• GPUを使う：WhisperのlargeならGPUメモリ約10GBが提供元の目安で、LLMと同時に載せるならさらに要る

Macで考えるなら、Apple日本の公式サイトではMac mini（M6）がユニファイドメモリ16GBで149,800円（税込）からと表示されており、購入時に24GB、32GBへ変えられます。メモリは後から増やせる記載がないため、整形まで任せるつもりなら最初から多めの構成を選ぶことになるでしょう。必要なPCの考え方をもっと詳しく知りたい方は、ローカルLLMに必要なPCの目安も参考になります。

※価格は2026年10月3日時点のApple日本の公式表記（税込・最小構成）です。GPUメモリの値は各提供元の目安で、実際の速さを保証するものではありません。

無料・APIキー不要・月額なしでも、費用がゼロにはならない

道具そのものは無料で使えます。Whisperとfaster-whisperはMIT、kotoba-whisper-v2.0はApache-2.0のライセンスで、Ollamaも自分の機械でモデルを動かす分は料金がかかりません。クラウドの文字起こしAPIのように、使った時間に応じて請求が増えることもなく、APIキーを発行する手間も省けます。

その代わりに、別の形で費用が出てきます。メモリの多いPCやGPUの購入、構築と更新を担う担当者の時間、使い方を社員に教える時間が、それにあたります。月額の請求がない分、費用が見えにくくなるのがローカルの特徴とも言い換えられます。社内で比べるときは、ライセンス料の有無だけでなく、誰の手がどれだけ動くかを並べて考えてみてください。

Python・CLIでの構築手順（流れと必要なもの）

自分で組む場合の流れは、録音の用意、文字起こし、整形、確認の4段に分かれます。コードの細かい書き方は道具の版で変わるため、ここでは各段で何が要るかを順に並べます。

1. 録音を用意する：会議室の録音ならICレコーダーやPCの録音ファイル、オンライン会議なら会議ツール側の録画・録音を取り出します。Zoomの録音の取り出し方や、Zoom自体の文字起こし機能の設定はZoom 文字起こしの方法で扱っています。
2. Pythonの環境を作る：faster-whisperはPythonのライブラリとして動きます。本家のWhisperを使うならffmpegも別に入れます。
3. モデルを選んで取得する：faster-whisperならモデルの大きさ（smallなど）と、CPUかGPUか、量子化の方式（CPUならint8など）を決めます。kotoba-whisperはHugging Faceのモデルページから取得します。
4. 文字起こしを実行する：言語を日本語に指定して実行し、結果をテキストファイルに保存します。本家のWhisperのコマンドなら、READMEに日本語の音声で言語を指定する例が載っています。
5. Ollamaを入れる：Windowsは管理者権限なしでホームフォルダに入り、Windows 10 22H2以降が要件です。インストール後はコマンドプロンプトやPowerShellからollamaコマンドが使えます。
6. ローカルのモデルを取得し、クラウド機能を切る：OLLAMA_NO_CLOUD=1を設定し、ログにクラウド無効の表示が出ることを確かめます。
7. 文字起こしの結果をLLMに渡す：議事録の項目を決めた指示文と一緒に渡し、整えた文章を別のファイルに保存します。
8. 人が確かめて確定する：録音と元の文字を見ながら、決定事項と数字を中心に確認し、議事録として保存します。

Ollamaの本体には4GB以上、モデルの保存には数十〜数百GBの空き容量が要るとWindows版のドキュメントに書かれています。モデルの保存場所は、既定ではユーザーのフォルダの下（.ollamaのmodels）になります。会社のPCで社員ごとのフォルダ容量に制限がある場合は、OLLAMA_MODELSで保存先を変える設定も覚えておくとよいでしょう。構築の手順そのものをもっと詳しく知りたい方はローカルLLMの構築手順も読んでみてください。

ここまでの作業は、手順書どおりに進めば1人で組み上げることも出来ます。気をつけたいのは、組み上げた後のほうが手間の長く続く仕事になる点です。

構築した後に残る運用の手間

自分で組んだ文字起こしの仕組みは、作った日から保守が始まります。総務や情シスの方が先に考えておきたいのは、作り方よりも、作った後に誰が面倒を見るかのほうになります。主な手間を4つに分けて見てみましょう。

モデルとソフトの更新

OllamaはmacOSとWindowsでは更新を自動でダウンロードし、「Restart to update」を押すと適用される仕組みです。社員がそれぞれのタイミングで押すと、PCごとに版が少しずつずれていきます。faster-whisperやkotoba-whisper、pyannoteも新しい版が出るたびに、更新するかどうか、ライセンスが変わっていないかを確かめる必要が出てきます。

担当者の異動・退職による属人化

構築を1人に任せると、手順と設定がその人の頭の中だけに残りがちです。pyannoteのアクセストークンを個人のアカウントで発行していた、環境変数の設定を記録していなかった、という状態で担当者が異動すると、次の人は一から調べ直すことになってしまいます。構築した手順と設定は、担当者が替わっても再現できる形で文書に残しておきましょう。

端末ごとの環境の差

GPUのあるPCとないPC、WindowsとMacが混ざると、同じ手順では動かない場面が出てきます。Windows版のOllamaはNVIDIAのGPUを使う場合にドライバ551.61以降が要件で、faster-whisperをGPUで動かすにはCUDA 12用の部品が要ります。PCの入れ替えのたびに動作を確かめ直す作業も、運用の手間に含まれます。

問い合わせ窓口

オープンソースの道具には、製品のようなサポート窓口がありません。文字起こしが途中で止まった、急に精度が落ちた、という相談は社内の担当者に集まります。その担当者が本来の仕事と兼務している会社では、相談が重なるほど本業の時間が削られてしまいます。誰が問い合わせを受け、どこまで対応するかを決めておかないと、使う人が増えたところで回らなくなるでしょう。

こうして並べてみると、ローカルの文字起こしで手間がかかるのは仕組みを作るところより、それを社内で使い続けるところだと分かります。担当者を置けるかどうかが、自社で組むかどうかの分かれ目になります。

自社構築・既製アプリ・クラウド型サービスとの比較（判断表）

選び方の軸は、録音をどこまで社外に出せるかと、運用を担う人を社内に置けるかの2つです。会議の録音を文字にする方法は、自社で構築する、既製のローカル文字起こしアプリを入れる、法人向けのクラウドサービスを使う、の3つに分けられます。担当者の作業と保守、社内の審査、費用の出方で並べると、次の表のとおりです。

表のとおり、自社で構築する場合だけ、更新と問い合わせの受け手が社内の担当者になります。既製のローカルアプリはその手間を提供元に移せますが、社内で使うPCに入れる以上、提供元の会社や通信の有無を確かめる審査は避けられません。クラウドサービスは録音を外に出す代わりに、保守の手間がほぼなくなる選択肢となります。

3つのうち1つに絞る必要もありません。人事面談のように録音を外に出したくない会議だけを自社の仕組みで文字にし、それ以外の会議はクラウドのサービスに任せる、という分け方も考えられます。会議の分け方は、後の節で詳しく見ていきます。

試すときは、1種類の会議と1台のPCから

どの方法を選ぶにしても、いきなり全社に広げず、1種類の会議と1台のPCで試してみるのが確かです。例えば、毎週の部署の定例を1か月ほど対象にして、これまで人が書いていた議事録と、文字起こしから整えた議事録を並べてみます。見比べるのは、決定事項と宿題の漏れ、固有名詞の誤り、確認にかかった手間の3つで足りるでしょう。試した結果を記録に残せば、自社で組むか、既製のアプリやサービスにするかを決めるときの材料として使えます。

簡単に使える既製のローカル文字起こしアプリを選ぶときの確認点

Whisper系のモデルを画面から使えるようにした、構築不要のローカル文字起こしアプリもいくつか出ています。コマンドを打たずに使える点は、総務の方が扱うには大きな利点です。選ぶときは、宣伝の言葉よりも次の点を提供元に確かめてみてください。

• 録音と文字起こしの結果が、本当にPCの外に送られないか。送られる場面（更新確認、ライセンス認証など）はあるか
• 中で使っている音声認識のモデルと、そのライセンス
• 話者分離や要約の機能は、ローカルで動くのか、外部のサービスにつなぐのか
• 会社で複数台に入れる場合のライセンスの数え方
• 提供元のサポート窓口と、更新が続く見込み

話者分離：pyannoteで誰の発言かを分けるには

Whisperで文字にしただけでは、発言者ごとに分けた議事録にはなりません。議事録で発言者を分けたい場合は、話者分離という別の道具を組み合わせることになります。ローカルで使える代表的な道具が、オープンソースのpyannoteです。pyannote.audio本体と、話者分離のモデルspeaker-diarization-3.1は、どちらもMITライセンスで公開されています。

ここで見落としやすいのが、モデルを手に入れるまでの手続きです。pyannoteのモデルは、Hugging Faceで利用条件に同意し、アクセストークンを発行しないと使えません。同意の際には連絡先の共有も求められます。会社として使うなら、誰のアカウントで同意し、トークンを誰が管理するのかを決めておく必要があるでしょう。担当者の個人アカウントで済ませてしまうと、その人が異動したときにモデルを取り直せなくなってしまいます。

入力する音声は16kHzのモノラルが前提で、ほかの形式の音声は自動でまとめたり変換したりする、とモデルカードにあります。新しい版のspeaker-diarization-community-1はCC-BY-4.0という別のライセンスになっており、商用版のpyannoteAIも案内されています。版を替えるときは、ライセンスの表示も一緒に確かめてください。

もう1つ知っておきたいのは、話者分離で分かるのは「声の違う人が何人いて、どこで入れ替わったか」までという点です。誰が田中さんで誰が佐藤さんかという名前は、人が当てはめることになります。会議室のマイク1本で離れた席の声を拾った録音や、声の似た人が多い会議では、分け方が崩れることもあります。発言者を正確に残したい会議では、参加者ごとにマイクを分ける、オンライン会議の録音を使うといった録り方の工夫も合わせて考えてみましょう。

ローカルでも残るリスクと確認の工程

ローカルで処理すれば、録音が提供元のサーバーに渡る心配はなくなりますが、それで安全が完成するわけではありません。録音と文字起こしの結果は、処理したPCの中に残り続けます。そのPCを社外に持ち出して紛失したり、盗まれたりすれば、クラウドに出さなかった意味が薄れてしまいます。

次に気をつけたいのが、ファイルの広がり方です。文字起こしの結果を共有フォルダに置いたり、USBメモリで別のPCに移したり、チャットに貼り付けたりするたびに、内容を読める人と場所が増えていきます。録音を外に出さない仕組みを作っても、出来上がった文字の扱いが決まっていなければ、同じ内容が別の経路で広がることになります。

3つ目は、LLMによる補正で発言の意味が変わる危険です。誤変換を直させたつもりが、言っていない言葉を足したり、否定の言い回しを肯定に変えたりすることがあります。議事録に残す決定事項と数字は、必ず元の文字起こしと突き合わせてから確定させてください。

確認の工程は、次のように決めておくと回しやすいでしょう。

• 整えた議事録と、整える前の文字起こしを2つとも保存する
• 決定事項、金額、日付、担当者名は、元の文字と1つずつ照らし合わせる
• 元の文字でも聞き取れていない箇所は、録音を聞き直すか、会議の参加者に確かめる
• 確認した人の名前と日付を議事録に残す

確認を会議の進行役が担うのか、記録係が担うのかも、最初に決めておくと漏れにくくなります。AIの出力を人が確かめる工程は、クラウドを使う場合と変わりません。

ローカルのつもりで、外から届く状態になっていないか

複数人で1台の仕組みを使おうとしたときにも、注意が要ります。LM Studioは「Serve on Local Network」を有効にすると同じネットワークの他の機器から使えるようになりますが、公式ドキュメントには、既定ではAPIの要求に認証を求めない、との記載があります。127.0.0.1以外で待ち受けるとPCの外に開くことになるため、認証を有効にするよう同社も勧めています。Ollamaの公式FAQにある公開の手順にも、使う人を確かめる設定の説明は見当たりません。録音を文字にした内容を社内で共有したいときは、仕組みそのものを開くのではなく、確定した議事録だけを決めた保存先に置く形にしてみてください。

会議の録音と個人情報の考え方

誰の発言か分かる録音は、個人情報として扱うものと考えておくのが無難です。個人情報保護委員会のQ&Aには、会議の録音を名指しした問いはありませんが、通話の録音についての考え方は示されています。

Q&AのQ1-10では、通話内容から特定の個人を識別できる場合は個人情報に該当するという整理になります。その場合、原則として利用目的を通知または公表する義務を負うものの、録音していること自体を相手に伝える義務までは負わないという説明です。Q1-11は、特定の個人を識別できない録音は基本的には個人情報に該当しないとしつつ、ほかの情報と容易に照合して識別できれば個人情報になるとしています。声から本人を確かめるためのデータに変換したものは、個人識別符号にあたるとも書かれており、声を本人確認に使う場合は別の注意が要ることになります。

会議の録音も、参加者の名前や発言者が分かる形で残すなら、この通話録音の考え方に沿って扱うのが安全でしょう。話者分離で発言者に名前を当てはめた議事録は、まさに誰の発言かが分かる形になります。法律上の義務とは別に、社内の会議でも録音を始める前に参加者へ伝え、何に使うかを説明しておけば、後のもめごとを防ぎやすいでしょう。

※個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」に関するQ&A（https://www.ppc.go.jp/personalinfo/faq/APPI_QA/）のQ1-10・Q1-11を2026年10月6日に確認しました。個別の判断は、社内の法務担当や専門家にご相談ください。

録音データの社内ルールのひな形

ローカルで文字起こしを始める前に、録音と文字の扱いを1枚のルールにまとめておきましょう。次のチェックリストは、そのまま社内の規程のたたき台に使えるように並べたものです。各項目の期間や担当は、自社の事情に合わせて書き換えてください。

• 録音してよい会議と、録音を伝える方法録音してよい会議の種類を決め、開始前に参加者へ口頭や招待文で伝える。録音の目的（議事録の作成など）も合わせて伝える。
• 録音ファイルの保存場所文字起こしをするPCの決めたフォルダか、アクセスできる人を絞った社内の保存先に限る。個人のデスクトップや私物の端末には置かない。
• 録音ファイルの保存期間と削除のタイミング議事録を確定させた後、何日以内に録音を削除するかを決める。確認のために残す場合も上限の日数を決めておく。
• 削除する人と記録削除の担当者を決め、いつ何を消したかを簡単な表に残す。担当者の不在時に誰が代わるかも決める。
• 文字起こしの結果と議事録の共有範囲確定した議事録は参加者と関係者に共有し、整える前の逐語の文字は確認担当だけが見られるようにする。
• 持ち出しの禁止録音と逐語の文字は、USBメモリ、私物のPC、個人のクラウドストレージ、個人のチャットに移さない。社外へのPCの持ち出し時は暗号化を条件にする。
• 使ってよい道具と版文字起こしと整形に使うソフト、モデル、版を決めて記録する。更新は担当者が確かめてから全社に広げる。
• クラウド機能と公開設定の確認Ollamaのクラウド機能を止める設定と、ネットワークに公開していないことを定期的に確かめる。
• 確認の工程決定事項と数字を元の文字と照らし合わせる人を決め、確認した人と日付を議事録に残す。
• 担当者の交代時の引き継ぎ構築の手順書、設定の記録、アクセストークンの管理を、後任に引き継ぐ手順として決めておく。

Zoomなどの会議ツール側で録音や文字起こしを残している場合は、そちらの保存期間もそろえておく必要があります。Zoomには、管理者が文字起こしを決めた日数の後に削除する設定もヘルプで案内されています。ローカルの側だけ削除の決まりを守っても、会議ツールの側に元の録音が残っていれば、ルールの意味が半分になってしまいます。

AIの利用全体の社内ルールと合わせて作るなら、生成AIの社内ガイドラインの作り方の項目とつなげて、規程を1本にまとめるのがおすすめです。

どの会議ならローカル向きか、の線引き

すべての会議をローカルで文字にする必要はなく、録音に何が入るかで分けるのが現実的です。会議ごとに、録音の中身と、聞いてよい人の範囲を考えると線が引きやすくなります。

ローカルで処理したい会議には、たとえば次のようなものがあります。

• 人事面談や評価会議：個人の評価や健康、家庭の事情などが話題になる
• 経営会議：公表前の数字、取引条件、組織の変更などを話し合う
• 顧客との打合せで、顧客の個人情報や機密を扱うもの
• 取引先との契約で、外部への委託や持ち出しに制限がかかっている案件の会議

一方で、クラウドのサービスでも差し支えの少ない会議も多いでしょう。公開済みの情報を扱う社内勉強会、部署の定例の進捗確認、社外にも出す説明会の練習などがその例です。これらの会議まで自社の仕組みで処理しようとすると、担当者の手間ばかりが増えてしまいます。

線を引くときは、録音に個人の評価や健康、顧客の個人情報が含まれるか、取引先との契約や社内の規程で外部への持ち出しが制限されているか、録音を聞いてよい人が参加者以外にいない会議か、の3つを順に確かめてみてください。1つでも当てはまる会議はローカルで、どれも当てはまらない会議はクラウドのサービスも選択肢に入れる、という分け方が始めやすいでしょう。

この線引きを先に決めておくと、ローカルの仕組みで扱う会議の数が見えてきます。月に数回の人事面談だけなら、1台のPCと手順書で回せるかもしれません。反対に、ほとんどの会議がローカル向きだと分かったなら、担当者を置く前提で仕組みを考え直すことになります。

線引きは一度決めて終わりではありません。新しい種類の会議を録音したくなったときや、取引先との契約が変わったときに見直す、と社内ルールに一行足しておきましょう。迷う会議が出たときに誰が判断するかも、あわせて決めておくと運用が止まりにくくなります。

よくある質問

まとめ

ローカルLLMでの文字起こしは、Whisper系のモデルで録音を文字にし、ローカルLLMで手直しと要約をする2段構成で組むことになります。faster-whisperならGPUのないPCでも試せ、日本語が中心ならkotoba-whisperも候補に入ります。話者分離にはpyannoteが使えますが、Hugging Faceでの同意とトークンの管理が要ります。

録音を社外に出さずに済む一方で、モデルの更新、担当者の交代、端末ごとの差、問い合わせの受け手といった運用の手間は社内に残ります。PCの紛失やファイルのコピー、LLMの補正で意味が変わる危険も、ローカルだからといって消えるものではありません。録音の保存場所と削除、持ち出しのルールを決め、決定事項と数字を元の文字と突き合わせる工程を入れてから使い始めてください。

どの会議をローカルで扱うかを先に線引きすると、自社で組むか、既製のアプリや法人向けのサービスに任せるかの判断もしやすくなるでしょう。法人のAI活用に関するほかの記事はAI活用コラム一覧にまとめています。