AI文字起こしと議事録の実務｜57分の会議を原音と照合した記録とモデルの選び方

目次

• この記事の立ち位置
• 用語の整理：文字起こしと議事録は別の工程である
• AI議事録を原音と照合した
• 照合の方法
• 結果：書かれていることは正しかった
• 結果：書かれていないことがあった
• 落ちた情報には型がある
• AIが「推定しなかった」ことの評価
• なぜ要約は情報を落とすのか
• 音声品質という別の欠落
• 文字起こしモデルの選び方
• Whisper系の実装は4つある
• 日本語特化モデルという選択
• 実測したレイテンシ
• 仕様と実機は食い違う
• クラウドAPIという選択肢
• 音声を外に出すかどうか
• 落ちた6類型から作った議事録テンプレート
• 無料でどこまでできるか
• 議事録運用の取り決め
• 用途別の使い分け
• 導入前に決めておくこと
• まとめ

この記事の立ち位置

会議の議事録作成は、生成AIの用途として最も導入しやすいもののひとつである。音声を渡せば要点が返ってくるため、効果が分かりやすく、失敗しても被害が小さいように見える。

一方で、「AIが作った議事録がどこまで正しいか」を実際に測った記録は少ない。多くの紹介記事は、ツールの機能一覧と料金表で終わっている。使ってみた感想はあっても、原音と突き合わせた記録はほとんど見当たらない。

編集部では業務でAI議事録を使っており、その品質を原音と照合して確かめた記録がある。本記事は、その記録と、文字起こしを支える音声認識モデルをどう選んだかを、実測とともにまとめたものである。

結論を先に書く。書かれていることは正しかった。問題は書かれていないことだった。

なお、照合の対象になった会議は受託業務のものであるため、顧客名・参加者名・金額・事業内容・使用したサービス名はすべて除いている。残したのは、AI議事録という道具の性質と、検証の方法だけである。

用語の整理：文字起こしと議事録は別の工程である

先に用語を分けておく。混ざったまま議論すると、道具の選び方を誤る。

文字起こしとは

音声を、話された通りの文字に変換する工程である。要約も整理もしない。「えーと」も言い直しも、話者が言ったままを残す。

出力は元の音声と同じ情報量を持つ。捨てる判断が入らないのが要点である。

議事録とは

会議の内容を、後から参照できる形に整理した記録である。決定事項、保留事項、担当と期日が中心になる。

文字起こしと違い、要約と取捨選択が入る。57分の会議が1ページになるということは、情報を捨てているということである。

この違いが実務でどう効くか

多くの道具は、この2つを一続きで提供する。音声を入れると議事録が出てくる。便利だが、途中の文字起こしが残らない設定になっていると、捨てられた情報に戻れない。

編集部が検証で分かったのは、まさにこの点だった。議事録に書かれていることは正確だったが、書かれていないものがあった。文字起こしを別に持っていたから気づけた。

重要な会議では、議事録だけでなく文字起こしも残す。 これが本記事全体を通した結論である。

AI議事録を原音と照合した

対象は57分の打ち合わせである。参加者は複数、議題は複数、結論が会議の後半に集中するという、ごく普通の商談型の会議だった。

この会議について、AIが自動生成した議事録がすでに手元にあった。加えて、こちらで独立に文字起こしを作成し、2つを突き合わせた。

独立に作ったという点が要点である。AIの議事録だけを読んで「それらしいか」を判断しても、何も確かめたことにならない。もとの音声に戻れる形を別に用意して初めて、照合ができる。

照合の方法

文字起こしは、OpenAIが公開している音声認識モデルWhisperの中規模モデルをGPUで動かして作成した。モデルの詳細はWhisperの論文で公開されている。会議の音声をそのまま入力し、話された内容を時刻つきのテキストに落とした。

そのうえで、照合の方向を2つとった。

第1の方向は、書かれていることが正しいかである。 AIの議事録に書かれている主張を1件ずつ取り出し、対応する発言が原音の文字起こしにあるかを探した。あれば、その発言を時刻つきで引用して記録した。

第2の方向は、書かれるべきことが書かれているかである。 文字起こしを通して読み、業務上重要だと判断できる発言を拾い出し、それがAIの議事録に現れているかを確かめた。

この2方向をとったことが、この検証で一番効いた。第1の方向だけを見ていたら、「すべて裏付けが取れた。品質は高い」で終わっていた。実際、第1の方向だけの結果はそう読める。

照合を1件ずつ記録に残す

照合の結果は、表の形で残した。左にAIの議事録の主張、中央に原音での裏付け（時刻と発言の引用）、右に判定を置いた。

この形にした理由は、後から誰かが検算できるようにするためである。「だいたい合っていた」という感想は引き継げないが、時刻つきの引用があれば、疑う人が原音に戻って確かめられる。

結果：書かれていることは正しかった

AIの議事録に書かれていた主要な主張は8項目あった。そのすべてについて、原音で裏付けが取れた。

内訳を性質で分けると、次のようになる。

ひとつは、ほぼ逐語で一致したものである。相手が述べた要望が、言い回しまで含めてほぼそのまま議事録に残っていた。この種の項目については、AIの議事録をそのまま引用資料として使ってよい水準にあった。

もうひとつは、複数の発言をまとめて1つの主張にしていたものである。会議の中で何度も繰り返された論点が、1行に集約されていた。この集約自体は妥当で、元の発言をすべて辿っても矛盾はなかった。

さらに、会議の中で明確に否定された話題について、「対象外」と正しく記録していたものもあった。否定形の情報は落ちやすいと予想していたが、この件では残っていた。

つまり、AIの議事録が「嘘を書く」という失敗は、この検証では1件も起きなかった。ハルシネーションを心配して導入をためらっている場合、少なくとも議事録という用途については、心配の方向が違う可能性がある。

結果：書かれていないことがあった

一方で、原音にあるのにAIの議事録から落ちていた重要な事実が6件あった。

「重要」の基準は、業務上の判断に影響するかどうかとした。その発言を知らずに次の資料を作ると、方向を誤る、あるいは作り直しになる、というものを重要とした。

6件のうち最も影響が大きかったものは、結論として提示された数字に至るまでの計算の道筋だった。議事録には結論の数字が残っていた。しかし、その数字がどの項目を差し引いた結果なのか、なぜその差し引きが妥当なのかという過程は、記録されていなかった。

会議の中では、相手自身がその引き算を口に出していた。つまり、会議の中心的な論点に対する答えが原音には存在していて、議事録には現れていなかった。

この1件だけで、検証をした価値があった。議事録だけを読んで次の資料を作っていたら、答えがすでに出ている問いを、もう一度検討し直すことになっていた。

落ちた情報には型がある

6件を並べて眺めると、落ちたものには共通の性質があった。いずれも、決定そのものではなく、決定の理由と条件だった。

型に分けると、次の6つになる。

型1：結論に至る計算の過程

結論の数字は残るが、そこへ至る足し引きが落ちる。後から「なぜこの数字なのか」を説明できなくなる。社内で承認を取る段階で必ず聞かれるのはこちらである。

型2：費目や枠組みの建付け

「どの予算から出るか」「どういう名目なら通るか」といった、金額そのものではなく金額の置き場に関する情報。金額は議事録に載るが、置き場は載らない。

型3：相手側の内部事情

相手の組織の中で、この件がどう見られているかという話。多くは会話の合間に漏らされるもので、議題として立っていない。しかし提案の書き方を左右する。

型4：相手にとっての刺さり所

こちらの提案のどの側面が相手の関心に合致し、どの側面が合わないか。相手が「これはあまり刺さらないが、こちらなら」と述べた選別の情報。提案の優先順位を決める材料そのものである。

型5：新しい関係者や紹介のリード

会話の終盤に出てくる「そういえば別件で」の類。次の商談の起点になり得るが、当日の議題ではないため議事録の構造に入る場所がない。

型6：細かい追加要望

「それも入れておいて」の一言。単独では小さいが、納品時に指摘されると差し戻しになる。

型に共通するもの

6つの型に共通するのは、会話の途中で一度だけ言われ、結論として宣言されなかったという点である。

議事録を作るAIは、会議の構造を推定して要点を抽出する。決定事項・課題・次のアクションという枠に沿って整理するため、枠に入らない情報は行き場を失う。理由や条件は、決定の枠にも課題の枠にも入らない。

AIが「推定しなかった」ことの評価

この検証で、もうひとつ記録に値することが起きた。

会議の中で、ある数値が話題になったが、具体的な額は最後まで口に出されなかった。AIの議事録は、その項目について「確認できていない」と明記し、値を推定しなかった。

照合した結果、原音にもその数値は存在しなかった。つまり、AIの判断は正しかった。

これは軽く扱ってよい結果ではない。生成AIの失敗として最も警戒されるのは、確認できないことをもっともらしく埋めてしまう挙動である。ハルシネーションに関する研究でも、根拠のない生成は主要な課題として扱われている。

議事録という用途では、「わからない」と書く選択が正しく取られるかどうかが、実用性を大きく分ける。埋めない判断ができているかは、導入前に確かめる価値のある観点である。

根拠のない生成をどう扱うかはハルシネーション対策の実務で体系的に扱っている。

確かめ方は単純で、意図的に情報を欠いた短い音声を渡し、その項目について何と書くかを見ればよい。埋めてくるなら、その道具は会議に使えない。

なぜ要約は情報を落とすのか

「AIの議事録は間違っている」という話ではない。書かれている内容の正確さは高かった。問題は書かれていないことにある。

要約とは、情報を捨てる作業である。 何を残して何を捨てるかの判断が必ず入る。そして、その判断が業務上の重要度と一致する保証はない。

AIは会議の構造から重要度を推定する。繰り返された話題、結論として述べられた内容、明示的に「決定」と言われたものは残りやすい。一方で、一度だけ、それも会話の合間に出た情報は、構造上の重みが小さい。

しかし業務においては、一度しか言われなかったことのほうが重い場合がある。相手が本音を漏らすのはたいてい一度きりで、繰り返されない。

長い入力の中央部分で情報が扱われにくくなる傾向は、長文脈における性能低下の研究でも報告されている。57分の会議は、多くのモデルにとって短い入力ではない。

対策は「拾ってほしい軸」を先に渡すこと

この性質への対処は、モデルを変えることではなく、何を拾ってほしいかを先に指示することである。

編集部では、議事録を生成させる前に次の軸を渡すようにした。決定事項、保留事項、金額に関する発言、反対意見、相手が述べた前提条件、次回までの宿題。

軸を渡すと、枠に入らなかった情報が拾われる確率が上がる。完全ではないが、何も指示しない場合よりは明確に改善する。

音声品質という別の欠落

照合を進める中で、AI議事録とは別の問題が見つかった。こちらで作った文字起こしにも欠落があった。

57分のうち、序盤と中盤の合計で約8分が、音声品質の問題で文字に起こせていなかった。マイクから遠い位置での発言、複数人の発言の重なり、環境音が原因である。

ここが実務上、最も注意を要する点である。AIの議事録が落としたのか、そもそも音が取れていなかったのかは、区別しなければならない。

区別せずに「AIが落とした」と結論すると、対策の方向が変わってしまう。モデルを変えたりプロンプトを工夫したりしても、音が無い区間からは何も出てこない。この場合に必要なのは、マイクの配置を変えることである。

照合に使う側の欠落を先に確かめる

これは検証の設計の問題でもある。比較の基準に使う側が完全である保証がないなら、まず基準の欠落を測る。

今回の検証では、文字起こしの側に時刻が入っていたため、どの区間が取れていないかを特定できた。時刻のない文字起こしを基準にしていたら、欠落に気づかないまま「AIが6件落とした」と報告していた可能性がある。実際の欠落はもっと多かったかもしれず、その差は測れないままになっていた。

「AIの精度が低い」と判断する前に、測定に使った側が届いていたかを確かめる。 これは議事録に限らず、AIの品質を評価するときに共通して要る手順である。

録音の質を上げるほうが安い

対策の費用対効果で言えば、モデルを変えるより録音環境を整えるほうが安い。

会議室の中央にマイクを1本置く構成では、遠い席の発言が落ちる。参加者ごとにマイクを分ける、オンライン会議なら各自のヘッドセットを使う、という変更のほうが効果が大きい。

発話区間の検出にはsilero-vadのような軽量なモデルが使える。無音区間を除いてから認識に回すと、処理量が減り、誤認識も減る。

文字起こしモデルの選び方

ここからは、議事録の前段にあたる文字起こしそのものの話である。

編集部では、議事録の照合とは別に、音声で対話するシステムを構築している。こちらは会議の記録とは要件が異なり、話し終わってから応答が返るまでの時間を詰める必要がある。そのためにモデルを比較して選定した記録があるので、その内容を共有する。

会議の記録とリアルタイム対話では最適な選択が変わるが、選択の軸は共通している。精度・速度・モデルの大きさ・日本語への適合・音声を外に出すかどうかの5つである。

Whisper系の実装は4つある

日本語の文字起こしで実務的な選択肢の中心は、Whisper系のモデルである。ただし「Whisper」と呼ばれるものには、少なくとも4つの実装があり、性格が違う。

1. OpenAI公式実装

openai/whisperが本家である。PyTorchで書かれており、最も素直に動く。一方で速度は出ない。試すには良いが、量を処理する用途には向かない。

2. faster-whisper

faster-whisperは、CTranslate2という推論エンジンでWhisperを書き直したものである。同じモデルの重みを使いながら、速度とメモリ使用量が大きく改善する。GPUがある環境で量を処理するなら、まずこれを検討することになる。

編集部の音声対話システムでも、この実装を使っている。

3. whisper.cpp

whisper.cppはC/C++で書かれた実装で、GPUがなくても動く。ノートPCの上で完結させたい場合や、機材を増やせない現場で使える。量子化したモデルを使えば必要なメモリも小さい。

4. WhisperX

WhisperXは、単語単位の時刻づけと話者の分離を足した派生である。議事録の用途では、この話者分離が効く。

誰が何を言ったかが分かれば、「相手が述べた前提条件」と「こちらが提示した案」を区別できる。今回の照合でも、発言者の区別ができたことが判断に効いた場面があった。

日本語特化モデルという選択

モデルの重み自体にも選択肢がある。

Whisperのlarge-v3は多言語モデルで、精度は高いがサイズが大きい。faster-whisper形式に変換されたlarge-v3で約2.9GBある。

これに対して、日本語に特化して追加学習されたモデルがある。編集部の音声対話システムで既定にしているのはkotoba-whisper-v2.0-fasterで、サイズは約1.5GBとlarge-v3の半分程度である。配布元の説明では、large-v3と比べて5〜6倍速いとされている。

既定と退避先を両方用意する

編集部の構成では、日本語特化モデルを既定にし、large-v3系を精度側の退避先として切り替えられるようにしている。環境変数を1つ変えるだけで入れ替わる。

この形にした理由は、速度と精度のどちらが要るかが用途で変わるためである。リアルタイムの対話では速度が優先されるが、後から読み返す記録では精度が優先される。

会議の議事録は後者である。 一度処理すれば済むものに、リアルタイム向けの速い設定を使う理由はない。時間をかけて精度の高いモデルを回すほうが合理的である。

自社のGPUで言語モデルと音声認識を動かす構成、必要なVRAM、棄却した選択肢はオンプレミスでLLMを動かすにまとめている。

実測したレイテンシ

編集部の音声対話システムで測った値を挙げる。リアルタイム対話向けに構成した環境の値であり、会議の一括処理にそのまま当てはまるものではないが、GPUで日本語特化モデルを回したときの目安にはなる。

音声認識の280ミリ秒は、3秒の音声に対する値である。音声の長さに対して約10分の1の時間で処理できている計算になる。

この数字の読み方

この比率をそのまま長時間の会議に当てはめてはいけない。理由は3つある。

第1に、条件が違う。 リアルタイム対話では、音声を短い区間に切って逐次処理している。57分の音声を一括で渡す場合、メモリの制約や区間の分割方法が別の要因として効く。

第2に、GPUの性能に強く依存する。 同じモデルでも、GPUが変われば数倍の差が出る。CPUで動かせば桁が変わる。

第3に、話者の数と音質で変わる。 複数人が重なって話す会議は、一人が明瞭に話す対話より処理が重い。

数字を出すときは、測った条件を一緒に運ぶ必要がある。「3秒で280ミリ秒」だけを切り出して「57分なら5分半」と計算するのは誤りである。

仕様と実機は食い違う

構築の記録から、もうひとつ共有に値することがある。

設計書では、音声認識を特定のモデルで特定のGPU上に配置する構成になっていた。しかし実際に組んだ環境では、そのモデルはその場所になく、別のGPU上にあった共有の音声認識を使う形に変更された。記録には訂正として残っている。

これは珍しいことではない。設計書に書いてある構成と、実際に動いている構成は、放っておくと乖離する。

問題になるのは、乖離したまま性能の測定や障害の切り分けをする場合である。設計書を前提に「このモデルなら出るはずの速度が出ない」と考えると、原因を永遠に探すことになる。

動いている構成を出力させる

対策は、構成を人が書いた文書から読むのではなく、動いているシステムに出力させることである。

起動時に、実際に読み込んだモデル名・配置・バージョンをログに出す。測定結果を記録するときは、その出力を一緒に保存する。こうすると、後から見た人が「何を測ったのか」を設計書ではなく実機の記録から確認できる。

クラウドAPIという選択肢

自前でモデルを動かさず、APIに投げる選択肢もある。主要なものを挙げる。

• OpenAIの音声認識API
• Google Cloud Speech-to-Text
• Azure AI Speech
• Amazon Transcribe

日本語の議事録に特化したサービスも複数ある。Notta、CLOVA Note、Rimo Voiceなどが該当する。これらは文字起こしだけでなく、要約・話者分離・議事録の書式化までを含む。

自前とAPIの分かれ目

判断の軸は3つである。

量である。 月に数時間なら、APIのほうが安く早い。GPUの調達も構築も運用も要らない。月に数百時間を超えるあたりから、自前で動かす構成の検討に意味が出る。

機微さである。 後述する。

待ち時間である。 リアルタイムの応答が要るなら、ネットワークの往復が効いてくる。会議の記録のように後から処理するものでは、この軸は効かない。

音声を外に出すかどうか

会議の音声には、多くの場合、外に出すことを想定していない情報が含まれる。顧客名、取引金額、未公開の事業計画、人事に関する話題、社内の対立。

これらを外部サービスに送ることが問題ないかどうかは、サービスの利用規約と、自社が負っている守秘義務の両方で決まる。

確認すべき点を挙げる。

送ったデータが学習に使われるか。 多くの事業者向けプランでは使われないと明記されているが、無料プランや個人向けプランでは扱いが異なる場合がある。

保持期間はどれだけか。 処理後すぐ削除されるのか、一定期間保存されるのか。

保存される場所はどこか。 国外のサーバーに保存される場合、契約上の制約に触れることがある。

顧客との契約に第三者提供の制限があるか。 受託業務では、顧客の情報を自社の判断で外部サービスに渡せない場合がある。

個人情報を含む場合の扱いは、個人情報保護委員会が公開している法令と解説が基準になる。

手元で動かせば音声は外に出ない

自前でモデルを動かす構成の最大の利点は、ここにある。音声がネットワークに出ない。

代償は構築と運用の手間である。GPUを用意し、モデルを配置し、更新に追随する必要がある。whisper.cppのようにCPUで動く実装を使えばGPUは不要になるが、処理時間は伸びる。

編集部では、内容の機微さで使い分けている。社内の定例のように外に出ても影響が小さいものはサービスを使い、顧客の情報を含む会議は手元で処理する。

判断の線を毎回考えるのではなく、「この種類の会議はこちら」という対応表を先に作っておくと、運用で迷わない。

落ちた6類型から作った議事録テンプレート

一般的な議事録のテンプレートは「日時・参加者・議題・決定事項・次回予定」という形をしている。この形は、本記事で示した6つの欠落をすべて取りこぼす。

決定事項の欄はあるが、決定の理由と条件を書く欄がないからである。

照合の結果から作った欄

編集部が実際に使っている欄は次のとおりである。前半は一般的なもので、後半が照合の結果から足したものである。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
■ 基本
  日時 / 参加者 / 議題

■ 決定事項
  決めたこと（1行ずつ）

■ 保留事項
  決まらなかったこと / 次に何が分かれば決まるか

■ 数字の根拠            ← 型1
  出てきた数字と、その数字がどう算出されたか
  （「Aを引いてBになった」の引き算そのものを書く）

■ 費目・枠組み          ← 型2
  どの予算から出るか / どういう名目なら通るか

■ 相手側の事情          ← 型3
  相手の組織の中でこの件がどう見られているか

■ 刺さった点・刺さらなかった点  ← 型4
  こちらの提案のどこに反応があり、どこに無かったか

■ 新しい名前            ← 型5
  会話に出てきた人・会社・案件（当日の議題でなくても）

■ 細かい要望            ← 型6
  「それも入れておいて」の類

■ 確認できなかったこと
  会議中に答えが出なかった項目

生成AIに渡すときの指示

この欄をそのまま指示として渡す。編集部が渡している文言は次の形である。

以下の欄で議事録を作成してください。該当する発言が無い欄は「なし」と書き、推測で埋めないでください。 数字が出てきた場合は、その数字だけでなく、どう算出されたかの説明があればそれも書いてください。

「推測で埋めるな」を明示するのが要点である。これを書かないと、空欄を埋めようとして、言われていないことが入る。

本記事で示したとおり、編集部の検証ではAIは原音に無い数値を推定しなかった。正しい挙動だが、指示の書き方で変わり得る部分でもある。

全部を毎回埋めない

10欄は多い。商談や契約に関わる会議だけに使い、社内の定例では基本と決定事項だけでよい。

欄を増やすと、埋めるのが面倒になって使われなくなる。使われないテンプレートは無いのと同じである。

書式より順番が効く

表にするか箇条書きにするかは好みでよい。効くのは「数字の根拠」を決定事項の直後に置くことである。

後ろに置くと書かれない。決定と理由を隣に置くと、片方だけ書いて終わることが減る。

無料でどこまでできるか

費用をかけずに文字起こしと議事録をどこまで作れるか。編集部が実際に使っている範囲で整理する。

音声認識のモデルは無料で入手できる

本記事で挙げたモデルは、いずれも重みが公開されており、取得も利用も無償である。whisper.cppを使えばGPUが無くても動く。日本語に特化したkotoba-whisperも同様に公開されている。

つまり、手元の機械だけで文字起こしを完結させることは、費用ゼロで可能である。

ただし利用条件はモデルごとに異なる。業務で使う前に、配布元のライセンス表記を確認する。

無料の代償は3つ

時間がかかる。 CPUで動かすと、音声の長さの数倍かかることがある。GPUがあれば短縮されるが、その機材は無料ではない。

構築の手間がかかる。 導入、モデルの取得、動作確認。1回で済むが、慣れていなければ半日かかる。

話者の分離が別途必要になる。 誰が何を言ったかを分けるには、追加の仕組みが要る。

会議サービスに付いている機能

普段使っている会議サービスに、文字起こしの機能が含まれている場合がある。Microsoft TeamsとZoomはいずれも提供しており、契約しているプランに含まれていれば追加費用はかからない。

すでに払っているものに含まれていないかを、最初に確認する。 別の道具を探す前にやることである。

使い分けの目安

無料の範囲で始めて、足りない部分だけ払う

最初から有料のサービスを選ぶ必要はない。会議サービスの機能で足りるかを試し、足りない部分が何かを特定してから、そこだけに払う。

編集部の場合、足りなかったのは議事録の欄の設計であって、文字起こしの精度ではなかった。道具を変えても解決しない種類の問題だった。

議事録運用の取り決め

照合の結果を受けて、編集部では運用を次のように変えた。

1. 重要な会議は原音を残す

AIの議事録だけを残すと、落ちた情報は永久に失われる。

議事録は要約であり、要約からは元に戻れない。音声または時刻つきの文字起こしを保管しておけば、後から「あの話はどうなっていたか」を確かめられる。

保管の期間と場所は、含まれる情報の性質に応じて決める。すべての会議の音声を無期限に残すのは現実的ではないので、金額・契約・方針の決定を含む会議に絞るのが実務的である。

2. 金額と期日は原音で確認する

議事録に書かれていても、書かれていなくても、この2つは原音に当たる。

全文を照合するのは手間がかかるが、誤ると影響の大きい項目に絞れば、確認は数分で済む。時刻つきの文字起こしがあれば、数字を検索して該当箇所だけ聞き直せばよい。

3. 拾ってほしい観点を先に指示する

前述のとおり、決定事項・保留事項・金額に関する発言・反対意見・前提条件・宿題、といった軸を先に渡す。

4. 「確認できていない」項目を残させる

議事録の末尾に、会議中に明確な答えが出なかった項目を列挙させる。

これは落ちた情報を拾う仕組みではないが、次に何を確認すべきかが残るという効果がある。今回の検証で、AIが値を推定せず「確認できていない」と書いたことが正しかったのと同じ理屈である。

5. 参加者の1人が当日中に目を通す

会議に出ていた人間が読めば、落ちている情報に気づける可能性がある。時間が経つほど気づけなくなるので、当日中に行う。

AIの議事録を「清書された議事録」ではなく「たたき台」として扱う。 これが最も費用の小さい対策である。

用途別の使い分け

ここまでの内容を、用途ごとに整理する。

すべてを1つの構成で賄おうとしない

導入の失敗でよくあるのは、すべての会議に同じ道具を当てようとして、どの用途にも中途半端になることである。

商談に必要な精度を社内定例にも適用すると手間が過剰になり、社内定例に十分な手軽さを商談に適用すると情報の扱いで問題が出る。

最初に分類を作り、分類ごとに道具を決める。 分類は3つ程度で足りる。

導入前に決めておくこと

音声を外に出してよい会議とそうでない会議の線

会議の種類で決める。参加者に社外の人がいるか、金額の話が出るか、顧客の情報を含むか。この3つで分ければ、ほとんどの会議は振り分けられる。

原音を残す会議と残さない会議の線

残す場合は、保管場所・保管期間・アクセスできる人を決める。決めずに残すと、それ自体が情報管理の問題になる。

誰が確認するか

AIの議事録を誰も読まない運用は、議事録を作っていないのと同じである。会議の参加者のうち1人を決めておく。

落ちても構わない情報は何か

これを決めておくと、確認の範囲が狭まる。すべてを確認しようとすると、議事録を自動化した意味がなくなる。

失敗したときにどう気づくか

議事録に落ちがあったことに、後から気づく仕組みがあるか。たとえば、資料を作る段階で「この数字の根拠は議事録のどこか」を辿る習慣があれば、落ちていることに気づける。

まとめ

編集部が57分の会議でAIの議事録を原音と照合した結果は、次のとおりである。

書かれていた主要な主張8項目は、すべて原音で裏付けが取れた。 誤りは1件も見つからなかった。ほぼ逐語で一致するものもあった。

一方で、原音にあるのに落ちていた重要な事実が6件あった。 そのうち最も影響が大きかったのは、結論の数字に至る計算の道筋である。会議の中心的な問いに対する答えが原音には存在していて、議事録には現れていなかった。

落ちたものには型がある。 いずれも、決定そのものではなく、決定の理由と条件だった。会話の途中で一度だけ言われ、結論として宣言されなかった情報である。

AIは、原音にない数値を推定しなかった。 これは正しい判断だった。埋めない選択が取れるかは、導入前に確かめる価値がある。

照合に使った側にも欠落があった。 57分のうち約8分が音声品質の問題で取れていなかった。AIが落としたのか音が無かったのかは、区別しなければならない。

モデルの選択は、精度・速度・大きさ・日本語適合・音声を外に出すかの5軸で決まる。 会議の記録は、リアルタイム対話と違って速度を優先する理由がない。時間をかけて精度を取るほうが合理的である。

設計書の構成と実機の構成は乖離する。 測定するときは、動いているシステムに構成を出力させる。

明日から試せる3つ

1つ目は、直近の会議1件について、AIの議事録と原音を照合してみることである。全文でなくてよい。金額と期日の2項目だけを確かめる。所要時間は10分程度で、自社の会議で何が落ちるかが分かる。

2つ目は、議事録を作らせる前に拾ってほしい軸を6つ渡すことである。決定事項、保留事項、金額に関する発言、反対意見、前提条件、宿題。指示を1行足すだけで結果が変わる。

3つ目は、会議を3種類に分類し、それぞれで音声を外に出してよいかを決めることである。毎回判断するのをやめると、運用が続く。

編集部では、AIの導入支援と、導入後の品質確認の仕組みづくりを行っている。議事録や文字起こしを入れたが精度の確かめ方が分からない、という段階の相談については、サービス案内を参照してほしい。

参考にした一次資料

• Whisperの論文（Robust Speech Recognition via Large-Scale Weak Supervision） — 本記事で扱った音声認識モデルの元論文
• openai/whisper — OpenAIによる公式実装
• faster-whisper — CTranslate2による高速化実装
• whisper.cpp — CPUで動作するC/C++実装
• WhisperX — 単語単位の時刻づけと話者分離を加えた派生
• whisper-large-v3 — 多言語の大規模モデル
• faster-whisper-large-v3 — 上記をfaster-whisper形式に変換したもの
• kotoba-whisper-v2.0-faster — 日本語に特化した軽量モデル
• silero-vad — 発話区間の検出に使う軽量モデル
• OpenAI 音声認識API — クラウドで処理する選択肢
• Google Cloud Speech-to-Text — 同上
• Azure AI Speech — 同上
• Amazon Transcribe — 同上
• Notta — 日本語の議事録サービス
• CLOVA Note — 同上
• Rimo Voice — 同上
• 個人情報保護委員会 法令・ガイドライン — 音声に個人情報が含まれる場合の基準
• ハルシネーションに関するサーベイ論文 — 根拠のない生成をどう扱うか
• 長文脈における性能低下の研究（Lost in the Middle） — 長い入力の中央部分が扱われにくくなる傾向