文字起こしAIの誤変換には、2種類ある — Mac標準の yap で、1時間の録音が30秒だった話
※ 本稿は2026年8月時点の情報です。yap は macOS 26 以降が必要です。なお macOS 27 では Apple 純正の fm コマンドが標準搭載される予定で、このあたりの選択肢はまた変わりそうです。
はじめに
先日、某オンライン説明会に参加し録音する機会があった。前職ではTeams会議がほとんどでそこで文字起こしはやってもらっていたが、これからこういう機会はどうしようかなとMacで録音の文字起こしをするにはどうするのが良いのかと、AIとやり取りしてみた。
GeminiはWhisperというツールがあると言うので、Whisperやほかのツールを少し調べつつ、Claudeにも同じことを投げ掛けて結局、Whisperは入れなかった。
macOS 26 以降には、Apple の新しい音声認識エンジン（SpeechAnalyzer）が標準で入っていて、それをコマンドラインから叩けるようにした yap というツールがあると知って、先にそちらを試したら、それで足りてしまった。
yap については速度も精度も試した範囲では十分活用できると分かったし、この手の文字起こしには変わらず間違い方に規則性があるのを改めて感じた。内容によってはオンデバイスで完結させたい場合もあるだろう。今回はそこをまとめておこうと思う。
手順は3行で終わる
yap の導入は簡単で、ターミナルを立ち上げて以下のコマンドを実行すれば良い。
brew install yap
yap transcribe -l ja-JP -m 300 -o out.txt recording.m4aこれだけ。モデルのダウンロードは要らない。APIキーも要らない。料金もかからない。yap自身が外部の文字起こしAPIを利用するのではなく、オンデバイスで処理されるので、音声が外に出ない。ライセンスも CC0（パブリックドメイン）になっている。
-l ja-JP：日本語の音声であることを指定する。既定はシステムの言語設定が使われるようで、音声から判定されるわけではないので、日本語の録音なら明示しておくほうが確実だと思う。
- -m 300：「1文あたり何文字で区切るか」の指定で、既定値は40。字幕用としては妥当な値なんだろうが、議事録として読む文章には短すぎるだろう。日本語の文は40文字を超えるのが一般的だと思うので、既定のままだと文が途中でぶつ切りになる。あとでAIに要約させるつもりなら、ここは広げておいたほうがよさそう。
- out.txt：出力するファイル名
- recording.m4a：文字起こしして欲しい元ファイル名。ターミナルのウィンドウに Drag&Drop すればパスを入力する必要もなく便利だと思う。
なお、ファイルの文字起こしについては追加の権限は要らない。後述するリアルタイム系のモードだけ、画面収録やマイクの許可が必要になる。
自分の環境（MacBook Air (13-inch, M3, 2024)/24GB）では、約1時間15分の音声が29.2秒で終わった。実時間比では約150倍になる。ターミナルが返した値で、手元の時計で測ってもほぼ同じだった。
参考までに、34分の動画が45秒（実時間の約45倍）で処理されたという計測もある。同じ計測の中で Whisper の large-v3-turbo が1分41秒、large-v2 が3分55秒だったそうだ。
自分の結果はそれより3倍以上速いことになるが、条件がかなり違う。こちらは話者ひとりのオンライン録音で雑音が少ない。向こうは4K動画のポッドキャスト収録で、話し手も一人ではない。音源の素性でこれだけ動くということでもあると思う。
いずれにせよ、1時間超が30秒で終わるなら「待つ」という感覚がほぼ無くなる。ここは体感として大きい。
誤変換には2種類あった
文字起こしの結果にざっと目を通してみたところ、問題なく読める精度で出てきたが、今回の結果を見ていると、誤り方には大きく2つの型があるように思えた。
ひとつは、音で崩れるもの。
「3トン」が「半トン」になっていた。さん→はん。音としては近い。厄介なのは、これが数字だったこと。文章の意味は通ってしまうので、読んでいても違和感がない。前後を照らし合わせて初めて、同じ数字を指しているはずの箇所が食い違っていることに気づいた。
もうひとつは、意味で崩れるもの。
「要件」が「用件」に、「SaaS」が「サース」になっていた。どのツールを使っててもよくあることだとは思う。こちらは読めばすぐ変だと分かる。ただし専門用語なので、その分野を知らない人が見ても直せない場合もあるかもしれない。
この2つは、直し方が違う。
音で崩れた数字は、一括置換では直らない。前後の文脈を追って復元するしかないし、そもそも気づくのが難しい場合もあるだろう。一方、意味で崩れた用語は、気づくのは簡単だが数が多い。こちらは一覧を作って一括置換するのが早そうだ。
つまり、確認作業は2周する必要がある。用語をざっと置換する周と、数字だけを拾って前後で検算する周。同じ「誤変換のチェック」でも、やっていることが違う。
「AIの出力は検証が必要」とはよく言われること。ただ、その言い方だとどこをどう見ればいいのか分からない。誤りの出方に型があるなら、確認の手順も型にできるはずだ、というのが今回あらためて感じたことだ。
話者分離はできない
現時点では、yapのオプション一覧にそれらしきものが見当たらないので、話者分離（diarization）の機能はないようだ。一人の講演やインタビューなら問題ないと思うが、複数人の会議で「誰が言ったか」が要るなら、別のツールを組み合わせることになる。
もうひとつ、対面の会議で録音中のリアルタイム認識を使う場合は、マイクの位置や部屋の反響など、音声を拾う条件そのものが認識精度に影響する。録ってからファイルを渡すほうが、結果は明確に良い。
ただしオンライン会議は事情が違う。
自分は試していないが、yap には listen（システム音声）と listen-and-dictate（システム音声＋マイク）というモードがあって、こちらはMacから再生されているシステム音声をそのまま文字起こしできる。マイクでスピーカーの音を拾う場合と違って、部屋の反響や話者との距離の影響を受けにくい。対面とオンラインで、選ぶモードが変わるということだと思う。なお listen には画面収録の許可、dictate にはマイクの許可が要る。
文字起こしと要約を、ひと続きにする
yap --help を眺めていて、目に留まったサブコマンドがあった。
mcp Start an MCP server for speech transcription.yap は MCP サーバとしても動く。つまり Claude Code や Claude Desktop など普段利用しているAIにMCPサーバとして登録しておけば、「この録音を文字起こしして、要点をまとめて」と一度頼むだけで済む。AI が自分で yap を呼び、出てきたテキストをそのまま要約に回してくれる。
これは地味なようで、実際にやってみると差が大きい。ターミナルで文字起こし → ファイルを開く → 中身をコピー → AI に貼り付ける、という一連の手作業が丸ごと消えるからだ。手間そのものより、この往復があると「面倒だから後でいいか」となりがちなのが問題で、そこが無くなる意味は大きいと思う。
個人的に良いなと思ったのは、これが新しいツールを増やす話ではないところ。すでに使っている流れに、機能を1つ足しているだけだ。
AI の活用について、役割ごとにツールを分けた構成図をよく見かける。自分もやってみようかと考えたことがあったが、あれは複数の人間が関わる組織だから意味を持つ形だと気がついてやめた。担当の分離、進捗の可視化、同期。一人でやっているとそのコストは発生しないのに、形だけ真似ると自分が文脈の運び屋になるだけになりかねない。
あらたにツールや手間を増やすのではなく、つなぐ。MCP はそういう道具なんだろう。
オンデバイスで完結させる意味
yap のもう一つの特徴は、文字起こし処理そのものを端末の中で完結できることだ。音声を外部サービスへ送る必要がない。
これは単なる技術的な性質ではなく、使える場面を決める条件にもなる。顧客との打ち合わせ、社内の機微な会議、個人情報を含むヒアリング。「外部のサービスに音声を送ってよいか」を確認しないと使えない場面は、実務ではかなり多い。
ここで気をつけたいのは、「全部ローカルにする」と「どこまでをローカルにするか」は別の話だということ。
自分は今のところ、文字起こしはローカル、要約はクラウド、という切り分けにしている。今回の説明会は公開の場のもので機微な情報ではなかったので、要約は普通にクラウドの AI に投げた。逆に顧客の録音であれば、要約もローカルで動かすモデルに寄せることになる。
現時点では、ローカルで動かせるモデルの日本語の要約は、クラウドの最新モデルには及ばないだろう。手元の 32GB クラスのマシンで動くモデルにできるのは、分類・抽出・一次要約あたりまでだと思っている。判断が要る仕事や、そのまま顧客に出す文章は、まだクラウドに残るのではないか。
だからこそ、線をどこに引くかを先に決めておく話になる。全部を守ろうとすると使えなくなり、何も考えないと出してはいけないものが出ていく。文字起こしのように「ローカルで完結でき、しかも無料で、精度も実用的」という部分が増えていくのは、その線を引きやすくするという意味でもありがたい。
気になっていること
速度ですらこれだけ振れるのだから、精度はなおさら条件次第のはずだ。
そう思って調べてみたが、Appleの新しい音声認識エンジンについて、日本語音声を対象にした十分な公開データやベンチマークは、自分が探した範囲では見つけられなかった。
英語であれば、Whisperとの比較計測がいくつか出てくるが、日本語となると、短いクリップでの検証か、「十分実用的でした」という感想で止まっているものがほとんどだ。Apple も対応言語として日本語を挙げてはいるが、精度の数字は出していない。
無料で、OSに最初から入っていて、それなりに動く。だとすれば、これから使う人は増えるはずだ。にもかかわらず、どの程度の誤りが、どういう場面で出るのかを共有する土台がない。もったいない気がする。
だから今回、自分の体験をまとめておくことにした。誰かが同じことをやったときに、比べられる材料にはなるだろう。個別の失敗談で終わるか、共有できる知見になるかは、たぶんそこで分かれるのだと思う。
参考
いいなと思ったら応援しよう！
お役に立てるようなことがあれば、応援お願いします。
いただいたチップは、CoreStudioの活動に役立つことに利用させていただきます。