AIは会議を聞き取れる。ただし名前は間違える ― 自社会議5本で測った文字起こしの弱点

会議の録音から議事録の下書きを作る——モデルとパイプラインが揃った今、これ自体はもう動きます。動かしてみて分かったのは、成否を分けるのは「動くかどうか」ではなく「どこを、どういう種類で間違えるか」を先に把握できているかどうか、でした。自社の社内会議5本（音声51.8分）で実際に測ったので、その内訳とハマりどころを技術者向けにまとめます。決済者・非エンジニア向けの要約版は 実績ページの事例（AIは会議を聞き取れる。ただし名前は間違える） にあります。

先に芯を書きます。AIは会議をかなり正確に聞き取ります。ただし人名は間違えます。自社会議5本で、専門用語の誤変換は21語中2語（9.5%）だったのに対し、人名は6人中6人（100%）が正しい表記では出ませんでした。この非対称性が、議事録づくりの設計をそのまま決めます。以下、順番を守って書きます——固有名詞はここまで間違える、だから人が確認する、という順序です。

最初に断っておくと、これは「議事録の下書き」を作るツールであって、議事録を全自動で完成させるものではありません。出力は「未確定（配布しないこと）」の状態で止まり、人が確認して確定するまで配布しません。自動で配る機能は作っていません。「AIに任せて完成」ではなく「AIに下書きさせ、確認は人が持つ」ための仕組みです。

構成 ― 音声は手元で文字化し、外に出すのは文字だけ

会議の音声は個人情報です。設計の出発点は「音声をクラウドに出さない」ことでした。工程を分け、文字起こしまでは手元のマシンで完結させ、要約・抽出だけをクラウド（AI）に投げます。

工程	使うもの	処理する場所	外に出るもの
音声 → WAV	ffmpeg（16kHz モノラル・映像は捨てる）	手元	なし
WAV → 文字起こし	whisper.cpp（whisper-cli ＋ ggml-large-v3-turbo）	手元	なし
文字起こし → 要約・抽出	Claude（構造化出力）	クラウド	文字だけ

文字起こしは手元のマシンで動かすので、この工程の費用は0円、処理時間は実時間の約10倍速でした（51.8分の録音が約5.3分、実測318.8秒）。全体構成は Laravel 13 / PHP 8.3 / SQLite で、docker が要らない小さな検証環境に収めています。話者分離は実装していません。「誰が発言したか」はこの仕組みでは分かりません。

要約・抽出の出力は4点です。①要約 ②決定事項・やること（担当者・期限つき） ③AIが判断できなかった点。この③が効きます。プロンプトでは「述べられていないことを書かない」「分からない担当者・期限は空にする」「不明点は必ず出させる」を指示し、AIに『分からなかったこと』を明示させることで、人が見るべき場所を絞れるようにしました。コストは全コールでトークンと円を記録し、月額3,000円＋1会議あたりの上限を超えたら止まる安全装置を入れています。

母数を先に、規則で固定する ― ここを人が選ぶと率が嘘になる

誤変換率を出すとき、いちばん危ないのは「どの語を数えるか」を人が選ぶことです。都合よく語を選べば、間違っていた語だけを母数に入れて「率が高い／低い」を自作できてしまいます。そこで、判定より先に母数を規則だけで機械抽出して固定しました。

// 専門用語の母数は、人にもAIにも選ばせない。規則で決めて後から動かせなくする。
//   ・カタカナ4文字以上 / 数字＋英字・カタカナ
//   ・2回以上出現した語
//   ・一般語37語（その分野で誰でも使う基本語）を除外
// 規則は TermExtractor::COMMON にすべて書いてあり、母数を後から動かせない。
php artisan minutes:terms --extract   // 規則で母数を固定
php artisan minutes:terms             // 1語ずつ人が前後の文脈つきで判定
php artisan minutes:terms --add-name  // 人名は機械で拾えないので正解表記を登録
php artisan minutes:terms --report    // 母数つきで誤変換率を出す

人名は規則では拾えないので、会議の参加者が正しい表記を登録しました。「母数を先に固定し、判定を後にする」——この順番を逆にすると率は意味を失います。他案件にも持っていける原則だと思っています。

結果（1）文字起こしはどこを間違えたか

	母数	誤変換	延べ
専門用語（規則で機械抽出）	21語	2語（9.5%）	84回中5回（6.0%）
人名（参加者が正解を登録）	6人	6人（100%）	14回中14回（100%）

専門用語の間違いは2語だけでした。1つは「ト」の脱落（エンドポイント → エンドポイトのような1文字欠け）、もう1つは英語由来の語で音そのものを取り違えたものです。一方、人名は6人全員が正しい表記で出ませんでした。内訳は、音は合っていて表記だけが違うもの（ひらがなの名前が漢字やカタカナになる）が5人、音そのものが別の名前になったものが1人です。表記だけの5人は辞書で直せますが、音が違う1人は文字起こし側の限界です。

ここは直感どおりでもあり、直感以上でもありました。専門用語は文脈で補正が効くのか9.5%に収まったのに、人名は文脈の助けが少なく、100%外した。議事録は「誰が何を言い、誰がいつまでに何をするか」を扱う資料です。つまり音声認識がいちばん弱いところを、議事録はいちばん必要とします。ここは避けて通れません。

なお、ここで出しているのは固有名詞・専門用語の誤変換率だけです。全文の正解（単語誤り率）は作っていないので、「文字起こし精度◯%」は出していません。

結果（2）AIは自分が読んでいる文字の間違いに気づく ― ただし偏る

出力の「AIが判断できなかった点」を見ると、こう並んでいました。

「◯◯」という名前は音声認識の誤りの可能性があります。「△△」「□□」といった名前も音声認識による誤変換の可能性があります。

人が「間違い」と確定した6人を、AIは6人とも自分から挙げていました。AIは音声を聞いていません。文字起こしのテキストだけを読み、日本語として不自然な箇所に気づいている。ここまで見ると「自己申告を検品に使えるのでは」と思いたくなります。ところが中身を見ると、気づける種類が偏っていました。

	AIが「誤りの可能性」と挙げたか
実際に間違っていた人名 6人	6人とも挙げた
実際に間違っていた専門用語 2語	0語（1つも気づかなかった）
実際は正しかった専門用語	2語を「誤りの可能性」として挙げた（＝誤検知）

理屈は通っています。人名の誤変換は日本語として不自然になるので気づける。専門用語の誤変換は不自然にならないので気づけない。そのうえ、見慣れない「正しい」専門用語のほうを「誤りかもしれない」と疑ってしまう。人名では6/6の再現率なのに、専門用語では0/2の再現率＋正しい語への誤検知、という真逆の挙動が同じ出力の中に同居していました。

したがって、AIの自己申告は「確認する場所のヒント」であって、確認そのものではありません。「AIが不明点に挙げていないから正しい」は成立しません（専門用語がまさにそう）。人名という気づきやすい層はAIの申告で当たりを付け、専門用語という気づきにくい層は人が固有名詞リストと突き合わせる——申告の偏りを知ったうえで役割を分けるのが現実的でした。

間違えた言葉を次から直す ― 日本語の語境界という地雷

人が「これは間違い」と判定した語は、そのまま用語辞書になります（判定 → 次の会議から自動補正）。ただし日本語には語の切れ目がないので、str_replace で素朴に置換すると別の語を壊します。

// 辞書を素朴に当てると、隣接する語を巻き込んで壊す
  森 → もり   なら   森林   → もり林
  真 → まこと なら   真剣   → まこと剣
  ミク → みく なら   ミクロ → みくロ

// ガード：置換位置の前後が同種の文字（漢字・カタカナ・英字）で続く場合は置換しない。
// テストで固定している。

正直に書くと、この辞書の「効果」は数字にしていません。辞書10語を、それを作った元と同じ文字起こし5本に当てれば19箇所が補正され過剰補正は0でしたが、これは「同じ会議で試せば直って当たり前」で、精度が上がった証拠ではありません。確かめているのは「一度判定した語が次から直る形になっているか」だけです。作った元と同じデータで辞書の効果を測らない——コマンドの出力にもこの注記を出しています。語境界ガードも、この5本のコーパスでは発動0回（＝この5本では素朴置換でも壊れなかった）で、将来のための保険であって実測の効果ではありません。

掲載素材の匿名化は手作業でやっていません。実名や社内用語が残ると危険なので、--anonymize（Redactor）で伏せ字と用語置き換えを行い、実名が残っていないことをテストで確認しています。テストは全体で34件（母数の固定・句読点を語に含めない・小数を切らない・辞書のガード・伏せ字の漏れ・デモの除外・保持期間の削除など）。

費用（要約・抽出のみ・実測2本）

会議の長さ	要約・抽出の費用	録音1時間あたり
23.6分（実会議1本）	7.82円	約20円
2.0分（デモ会議1本）	4.06円	約122円

抽出結果は、実会議（23.6分）で決定事項3件・やること11件・AIが判断できなかった点10件でした。この「件数」は出せる事実ですが、抽出の精度・拾い漏れ・誤抽出は測っていません（人が正解を作って突き合わせていないため）。件数だけを事実として書き、率は書きません。

測っていない・書けないこと

誇大にならないよう、この事例で出していない数字を明示します。

• 「全自動で議事録が完成」… 作っているのは下書きです。人が確認して確定するまで配布しません（自動配布機能なし）。
• 「決定事項の抽出精度◯%」「拾い漏れ◯%」… 測っていません。出せるのは出力件数（決定3件・やること11件）だけです。
• 「誰が発言したか分かります」… 話者分離は実装していません。
• 「議事録作成の工数を◯%削減」… 人が議事録を作る時間を計測していません。
• 「文字起こし精度◯%」… 全文の正解を作っていません。出せるのは固有名詞・専門用語の誤変換率だけです。
• 「用語辞書で精度が向上」… 効果を測っていません（同じ会議で試しても直って当たり前のため）。
• お客様の会議での実績 … ありません（顧客音声は使っていません）。会議数を増やしたときの傾向も、5本・51.8分の結果です。

他の案件に持っていける設計

• 母数を規則で固定してから判定する。判定より先に母数を決める。順番を逆にすると率が意味を失う。
• 音声を外に出さない構成。文字起こしを手元で行い、APIには文字だけ渡す。0円・実時間の約10倍速で回る。
• AIに「分からなかったこと」を言わせる。ただし自己申告は種類ごとに偏る（人名6/6・専門用語0/2）。検品の代わりにはしない。
• 辞書の効果を、作った元と同じデータで測らない。直って当たり前の数字を成果にしない。
• 掲載素材の匿名化をコードで行う。手作業だと消し忘れる。漏れをテストで止める。

まとめ

AIは会議を聞き取れます。専門用語は9.5%まで来ました。ただし人名は6人中6人を間違えます。議事録は固有名詞を扱う資料なので、この弱点は避けて通れず、だからこそ「下書きまでを任せて、確認を人が持つ」という順序になります。そして「どこを、どういう種類で間違えるか」を先に測っておけば、確認にかかる手間まで見積もれます。率だけでなく、間違いの中身を見に行くこと——これがいちばんの持ち帰りでした。

事例の要約（非エンジニア・決済者向け）は 実績ページ に、AI活用の他の事例は AI活用ページ にまとめています。会議記録づくりや、既存業務へのAI機能追加のご相談は お問い合わせ から。