サマリー

打ち合わせ中に議事録を取り続けるのが大変だったので、要配慮情報を外部へ送信しないローカル文字起こし環境を試した。
Ubuntu上でWhisperを動かし、オフライン環境でも使える構成を小さく検証している。
医療・業務系の制約環境でも運用できるよう、低コストかつ現場で回しやすい方法を模索した記録。

1）困っていること、課題は何か。

日々の会議や打ち合わせ後の要点整理や社内でのテキストベースでの共有に時間がかかっていた。特にPCを打ちながらだと、話し合いに集中できない。（相手にとっても、キーボードのカタカタ音は聞いててしんどいかも）
情報共有までに時間差や、そもそも打ち間違いによる記録違いを発生していた。
ボイスレコーダーで録音したらいけるかと思ったが、打ち合わせの全体から、必要な情報を取得するのに、音声情報音声を聞くだけだと昔懐かしいテープレコーダーを巻き戻し・再生・早送りで頭だしの作業をしているみたい。
Googleドキュメントなどの文字起こし機能や携帯の音声入力による文字起こしを試したが、多人数は想定されておらず、文字を開い切れない。特に音声入力　→　文字起こしを同時に行うので、処理に1秒程度の遅延が見られた。
teamsを疑似的に開催して文字起こし機能を使ったが、それぞれマイクが必要で機材準備が大変。というか、目の前のPCでそれぞれteamsをしながら、面と向かって打ち合わせしているという不思議な絵面（絵面は本質の問題ではない）

2）問題の本質は何か

「議事録作成が面倒」の中身は、

情報共有の遅延
手作業による抜け漏れ
手作業による人的コスト増
そもそも打ち合わせに集中できない。PCを打ちながら打ち合わせって、１つの脳みそ（しかも私の脳みそは非力）でダブルワークしている感じで無理。

3）では、どうするか。

オープンソースの whisper を利用したローカル文字起こしを検討した。
- なぜなら、要配慮情報も入る可能性のある打ち合わせ内容を、WAN側へ送信するのをためらった。
- なぜなら、議事録継続的な利用コストが発生する（月額サービスの場合は、使わない月においても発生する）を防ぎたかった。
whisperは、Windowsローカルマシンではなく、仮想環境上のubuntu serverに構築することにした。
- なぜなら、whisperの共同利用を想定すると、ローカルマシンは非力な端末が多いため、最終的にサーバサイドで稼働させたかった。
Windows端末からubuntu側に簡単に音声ファイルを投入できるよう、sambaで共有フォルダを作成することにした。
- なぜなら、SCP / SFTP（SSH経由）はコマンド操作の工数が増えるので、面倒であった。WinSCPも便利そうだと思ったので、

4）では、どうしたか。

Windows　※標準アプリサウンドレコーダー　←　録音
↓ (SMB共有)
仮想環境上のUbuntu Server
├─ /srv/share/audio ← 音声置き場
├─ /srv/share/text ← 文字起こし結果
├─ Whisper実行スクリプト
└─ Samba
のような構成で組み立ててみる。

試作

①Virtualbox上にUbuntu 24 Serverを建てる。

メモリは11GB程度にした。（結構適当）
hyper-vでもいいと思う。

VirtualboxにUbuntu 24 serverをマウント
ここでは省略
Ubuntu更新
sudo apt update && sudo apt upgrade -y
Python環境の構築。Ubutnu24はsystem Python保護があるらしいので、venv推奨らしい。
sudo apt install -y python3 python3-venv python3-pip ffmpeg

②Whisperを導入する。

- 作業ディレクトリ

mkdir -p ~/whisper
cd ~/whisper

- 仮想環境

python3 -m venv venv
source venv/bin/activate

- インストール

pip install --upgrade pip
pip install faster-whisper

スクリプト作成
vi ~/whisper/transcribe.py

Python

from faster_whisper import WhisperModel
import sys
from pathlib import Path

if len(sys.argv) < 2:
    print("Usage: python transcribe.py <audiofile>")
    sys.exit(1)

audio_path = Path(sys.argv[1])

model = WhisperModel("large-v3", device="cpu")

segments, info = model.transcribe(
    str(audio_path),
    beam_size=5,
    language="ja"
)

output_path = Path("/srv/share/text") / (audio_path.stem + ".txt")

with open(output_path, "w", encoding="utf-8") as f:
    for segment in segments:
        f.write(segment.text + "\n")

print(f"Saved: {output_path}")

③Samba準備

Sambaインストール
sudo apt install -y samba

コンフィグいじる前にバックアップ
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

smb.confの最下段に共有フォルダ設定の追加
sudo vi /etc/samba/smb.conf
:::message
※Windowsが共有フォルダへのゲストログイン拒否することで、接続できないことあるので、Sambaユーザーを作る方向で対応する。
:::

INI

[share]
   path = /srv/share
   browseable = yes
   writable = yes
   valid users = sambauser
   create mask = 0664
   directory mask = 0775

ユーザー作成
sudo adduser sambauser
Sambaパスワード
sudo smbpasswd -a sambauser

できたらSambaサービスの再起動も忘れずにする。
sudo systemctl restart smbd

Windows接続
※IPは、ubuntu server側でip aで確認する。
\\192.168.***.***\share

ログインは、
ユーザー: sambauser
パスワード: 作ったやつ

検証

①Windows標準のサウンドレコーダーで音声入力する。

テストの入力文章が一切思いつかないので、AIさんに考えてもらう。
「マイクテスト。マイクテスト。本日は晴天なり」しか思いつかなかった私とは雲泥の差で、AIさんがいつも優秀すぎて驚き。

②録音したファイルをwindowsからubuntuへ移動する。

レコーディング（２）　1分12秒かかった。

レコーディングしたファイルは、Window標準だと下記のパスにあるみたい。
拡張子は.m4aだそう。
ちなみにファイルが日本語名になっている場合、半角英数字にリネームした方が、コマンドラインで打ちやすい。

C:\Users\ユーザ名\Documents\サウンドレコーディング

この.m4aを取り出して、さっき作ったubnuntu上samba共有のaudioフォルダに投入。

③Wisper/pythonの実行して、文字起こしテキストファイルの出力を待つ。

コマンドラインから、
cd ~/whisper
source venv/bin/activate
python transcribe.py /srv/share/audio/speechtest.m4a

実行中の変化としては、pythonのCPU使用率が一気にあがるので、しばらく待つ。
※時間をはかっておいたらよかったけど、1分12秒の音声ファイルに対して3分間くらい待った気がする。

④結果が出る

今日は、最近の業務改善について少し話したいと思います。
これまで私たちのチームでは、日々の定型作業を手作業で行っていました。しかし、作業量が増えるにつれて、確認漏れや対応遅れが発生するようになりました。

そこで現在は、できるだけ自動化を進めています。例えば、ファイル整理や通知処理、定期レポートの作成などは、スクリプトやクラウドサービスを利用して自動で実行されるようにしています。

また、最近はAIを活用した文字起こしや要約機能も試験的に導入しています。会議の録音データから自動的に議事録を作成できるため、以前よりも情報共有がスムーズになりました。

もちろん、すべてを自動化すればよいわけではありません。最終的な確認や判断については、人が責任を持って行う必要があります。ただし、単純作業を減らすことで、本来集中すべき業務に時間を使えるようになります。

今後は、セキュリティや運用ルールも含めて、より安定した仕組みを整備していきたいと考えています。

今日は最近の業務会事について少し話をしたいと思いますこれまで私たちのチームでは日々の定型作業を手な作業で行っていました
しかし作業料がツーヘルにつれ確認森や太陽遅れが発生するようになりましたそこで現在はできるだけ自動化を進めています
例えばファイル整理や通知処理定型レポートの作成などはスクリプトやクラウドサービスを利用して自動で実行されるようにしています
また最近はAIを活用した文字起こしやようやく機能も試験的に導入しています会議の録音データから自動的に技術録を作成できるため
以前よりも情報共有がスムーズになりましたもちろん全てを自動化すればよいわけではありません
最終的な確認や判断については人が責任を持って行う必要がありますただし単純作業を減らすことで本来集中すべき業務に時間を使えるようになります
今後はセキュリティや運用ルールも含めてより安定した仕組みを整備していきたいと考えます

出来上がりの制度を検証する。

私の発音のよし悪しやパソコンのマイク精度も影響するので、ふわっとした参考程度。

元原稿と比較すると、主な誤認識はこんな感じ。

正解	認識結果	種類
業務改善	業務会事	同音誤変換
手作業	手な作業	助詞崩れ
作業量が増える	作業料がツーヘル	音響崩壊
確認漏れ	確認森	同音誤変換
対応遅れ	太陽遅れ	同音誤変換
要約機能	ようやく機能	同音誤変換
議事録	技術録	類似音誤変換
考えています	考えます	語尾省略

定量的にざっくり評価

指標	推定
意味理解可能率	90〜95%
文単位可読性	85〜90%
単語認識精度	80〜88%
固有語・漢字精度	70〜80%

５）結果と振り返り

構築後、Windows 端末から共有フォルダ経由で音声ファイルを投入し、Ubuntu 側で文字起こしを実施できることを確認した。
文字起こし精度については、一部誤変換はあるものの、議事録下書き用途としては十分実用的だった。

課題に対しては下記効果を確認できた。

情報共有の遅延　→　人が文字で手打ちしての文字起こしよりも早い。
手作業による抜け漏れ　→　100点の精度ではないが、60点はある認識で、手作業よりも抜け漏れがないイメージ。特に手作業（人の作業）により人的なバイアスも入らず、機械的に記録がされる。
手作業による人的コスト増　→　作成時間の削減
そもそも打ち合わせに集中できない。　→　録音しておくだけでいいので、話に集中できる。
　　　　　　　＋
ローカル完結による情報管理性向上
最悪、録音が残っているから文字起こしもできるよねっていう安心感の醸成
CPUのみの仮想環境でも運用可能であることが分かり、低コスト構成として現実的

振り返りとしては、whisperの実行をphythonを叩くコマンドラインで実行しているため、これをCUIからGUIにする方法を考えたい。