mlx-whisperでMac音声入力を自作｜ローカル環境で使う方法

Macでローカル音声入力ツールを自作して、日常的に使っています。

やっていることはシンプルです。

• 右Shiftを押している間だけ録音する。
• 指を離したらWhisperで文字起こしする。
• 認識結果を辞書で補正し、今開いている入力欄へそのまま貼り付ける。
• 失敗したときは「ボツ」と言えば、貼り付けずに捨てられる。

ブログの下書き、読書メモ、考えごとの整理に使っていますが、これが手放せなくなりました。

キーボードを打つより先に声が出る。
そういう感覚が身についてくると、テキスト入力に対する構えがずいぶん変わります。

動作環境はMacのローカルです。
モデルをMacに置いたあとは、推論時に音声を外部APIへ送らない構成にしています。

自分の音声データを外部サーバーに送りたくないから、ローカルで処理できることにこだわりました。（＞音声入力アプリは危険？声データをサーバーに送る前に知っておきたいリスクと安全な使い分け）

この記事はコード全文を配布するものではありません。

Pythonのバージョン、マイク名、Macの権限設定、使うWhisperモデル、貼り付け先アプリによって実装は変わります。
コピペ用のコードよりも、実際に使える道具にするための設計判断を中心に残します。

Whisperは、動かすだけならそれほど難しくありません。

なお、この話は3本目の記事として書かれています。
先に全体の流れを知りたい方は、[Macでローカル音声入力を自作するまでの話] を読んでください。
WhisperやMLX、4bit量子化の違いを先に整理したい方は、[Whisper・Turbo・4bit・MLXの違いを整理した記事] が参考になります。

---

作ったもの

現在の構成を大まかにまとめると、次のようになります。

項目	採用している方針	理由
実行環境	Macのローカル環境	推論時に音声を外部APIへ送らないため
音声認識	Whisper系モデル	日本語の長めの発話でも使いやすいため
実行まわり	MLX、mlx-whisper	Apple SiliconのMacで動かしやすいため
モデル	large-v3系の4bitモデル	精度と速度のバランスを取りたいため
起動	.commandファイル	毎回ターミナルでコマンドを打たないため
Python環境	venv	動いている環境を固定するため
録音操作	右Shiftを押している間だけ録音	余計な音を拾わないため
マイク	Shureマイクを名前で自動検出	デバイス番号の変化に振り回されないため
音声処理	できるだけメモリ上で処理	音声ファイルを残さないため
出力	クリップボード経由で貼り付け	入力先アプリを選ばないため
補正	初期プロンプト、辞書置換、破棄ルール	自分の用途に合わせるため
失敗対策	「ボツ」「入力破棄」で貼り付け停止	言い間違いをすぐ捨てるため
無音対策	短すぎる録音や定型の幻覚出力を捨てる	変な文章が貼られるのを防ぐため

最初は普通にWhisperをPythonから動かすところから始め、faster-whisperや軽量化も試しました。
最終的にはMLXとmlx-whisperの構成が、自分のMacには一番しっくりきました。

ただ、この表を眺めていると、モデルやライブラリの選択はむしろ一部でしかないことがわかります。

• 録音をどう始めるか。
• マイクをどう選ぶか。
• 貼り付けをどう通すか。
• 失敗をどう捨てるか。

音声入力は、こういう「認識の前後」の設計で、使えるツールになるかどうかが決まります。

---

基本の流れ

できたツールを使うときの手順を書いておきます。

.commandファイルからツールを起動すると、venvが有効になり、音声入力用スクリプトが立ち上がります。
接続されている入力デバイスからShureマイクを探し、見つかればそれを使い、見つからなければデフォルトマイクで代用します。

あとは、入力したい場所にカーソルを置いて、右Shiftを押している間だけ録音します。

WordPressでもObsidianでもブラウザの入力欄でも、カーソルさえあれば同じです。
右Shiftを離したら録音が止まり、短すぎる録音や無音に近いものはその場で捨てます。

Whisperで文字起こしされ、初期プロンプトと辞書で表記を補正したあと、「ボツ」「入力破棄」などの破棄コマンドがなければ、クリップボードに入れて現在の入力欄へ貼り付けます。

この流れを作ると、音声入力が「文字起こし」ではなく「入力手段」になります。

---

非エンジニアでも、AIとターミナルで作れた

私はエンジニアではありません。

Pythonを普段から書いているわけでもなく、ターミナルにも最初から慣れていたわけでもありません。
それでも、AIに相談しながら少しずつ作ることはできました。

やったことは地味です。

• 専用フォルダを作る。
• venvを作る。
• 必要なライブラリを入れる。
• AIが提案したコードを試す。
• エラーが出たら、そのエラー文をそのままAIに見せて修正してもらい、もう一度試す。
• 動いた状態を安定版として残す。

この繰り返しで、少しずつ形になりました。

今のAI時代は、非エンジニアでも「作りたいもの」をかなり具体的に形にできます。

コードの中身が完全にわからなくても作れる、というのは本当です。
でも、それだけに「動いている環境を壊さない」という感覚が重要でした。

特に意識していたのは三つです。

• 今どのフォルダで作業しているか必ず確認すること。
• 新しい構成は別のvenvや別フォルダで試すこと。
• 動いている環境にはむやみに手を入れないこと。

コードを読む力が十分でなくても、安定している状態を守る意識だけは必要でした。

難しく聞こえるかもしれませんが、Gemini2.5Proの時代でも作れました。今の最新のモデルに「Macでmlx-whisperを使って音声入力したいんだけれど、どうしたらいい？」と質問していけば、私の頃よりもっと簡単に作れるはずです。

---

.commandで起動する形にした

最初に改善したのは起動方法です。

毎回ターミナルを開いて、フォルダへ移動して、仮想環境を有効にして、Pythonスクリプトを実行する。

手順を書き出すと大したことに見えません。
でも、これを毎日やるとなると話が変わります。

音声入力は、使いたいと思った瞬間に立ち上がっていないと意味がない。
起動に手間がかかるだけで、使う気がなくなります。

そこで、.commandファイルから起動する形にしました。

.command側がやることはシンプルです。
自作ツールのフォルダへ移動し、そのフォルダ内のvenvを使い、音声入力用のPythonスクリプトを起動するだけです。

ダブルクリック一つで立ち上がるようにしてしまえば、起動という行為が意識から消えます。

音声入力ツールは、性能より先に「すぐ使えること」が大事です。
どれだけ認識精度が高くても、起動が面倒なら使わなくなります。

自分にとって自然に使えるかどうかを、ツールの入口から設計する必要がありました。

本当はオートメーターを使ってアプリ化しようとしたのですが、なかなか上手くいかなかったため、.commandで起動するようになりました。繰り返しになりますが、Gemini2.5Proの時代に作っているため、今やればもっといい起動方法があるかもです。
まぁ、.commandのファイルをダブルクリックで起動すればいいだけなんで、これでいいかなっと。

---

venvで環境を固定する

Pythonまわりは、環境が崩れると一気に面倒になります。

• 昨日まで動いていたのにライブラリを更新したら動かなくなる。
• 別の環境と混ざってどこに何が入っているかわからなくなる。
• エラーが出てもコードの問題なのか環境の問題なのか判断できない。

こうなると、原因の特定だけで消耗します。
非エンジニアにとっては、ここが一番つらい部分かもしれません。

そこで、音声入力ツール専用のvenvを作り、その中に必要なライブラリを閉じ込める形にしました。

venvはツール専用の小さな作業部屋のようなものです。
その中で動かす限り、外の環境とは干渉しにくくなります。

さらに、安定して動いている状態はむやみに触らないようにしました。

新しいライブラリを試したいなら、別のvenvで試す。
本番に入れるのは、改善されたと確認できてからにする。

毎日使う道具では、最新であることより安定して動き続けることのほうがずっと重要です。

更新によって何かが壊れたとき、その日から道具が使えなくなる。
そのコストを考えると、慎重さは合理的な選択です。

---

右Shiftを押している間だけ録音する

録音操作は、右Shiftを押している間だけ録音する方式にしました。

いわゆるPush-to-Talkです。

常時聞き取り型も考えましたが、自分の用途には合いませんでした。

ブログの下書きやメモでは、考えながら小さく独り言を言うことがあります。
ぼそっとつぶやいた言葉が勝手にテキストになっていたら、困ります。

書くという行為には、言語化の途中経過がたくさんあります。
音声入力ツールには、それを拾いすぎない設計が必要でした。

右Shift方式にすると、録音したいときだけ録音できます。

• 独り言や環境音を拾わない。
• 言い間違えたら、離してすぐやり直せる。
• マウスを使わず、キーボードから手を離さずに操作できる。

これらはどれも、文章を書きながら使うという文脈で効いてきます。

右Shiftにしたのは、普段の文章入力で使う機会がほとんどなく、片手で自然に押せるからです。
左Shiftだと、文字入力と操作が干渉する場面が出てきます。

ただし、Macでグローバルにキー入力を監視する場合、アクセシビリティや入力監視の権限が必要になります。
pynputのようなライブラリを使う場合は特にそうです。

また、パスワード入力欄などでSecure Inputが働いていると、キーイベントを拾えない場合もあります。
これはMacの仕様なので、割り切る必要があります。

右Shiftキーの設定も、AIに頼んだらコードを書いてくれます。

---

使っているマイクを自動検出する

マイク選択も、使い勝手に影響しました。

Macには内蔵マイクも外付けマイクもあり、USBハブを変えると入力デバイスの番号が変わることもあります。

最初はマイク番号を直接指定していました。
でも、ある日突然番号が変わって、気づかないまま内蔵マイクで録音していた、ということが起きました。

認識精度がなんとなく落ちた気がする。
でも原因がわからない。

マイクの問題だと気づくまでに少し時間がかかりました。

それ以来、入力デバイスの一覧から名前にShure（私が使っているマイク）が含まれるものを探して自動で選ぶようにしました。

番号ではなく、名前で選ぶ。
それだけで、デバイス構成が変わっても正しいマイクが使われ続けます。

見つからない場合はデフォルトマイクへ落とす設計にしていますが、本当はここで警告を出す方が安全です。

知らないうちに内蔵マイクへ切り替わると、認識精度が見えないところで悪化します。

モデルの性能をいくら上げても、入力が悪ければ結果は悪い。
良いマイクを確実に使い続ける仕組みは、精度改善そのものです。

これもマイクを指定したいってAIに頼めばコードを書いてくれます。

---

音声ファイルをできるだけ残さない

音声入力では、個人的な内容を話すことがあります。

• 読書メモ。
• ブログの下書き。
• まだ言葉になっていないアイデア。
• 人に見せる前の考えごと。

そういうものが音声ファイルとして自動的に蓄積されていくのは、あまり気持ちよくありません。

そこで、録音データはできるだけメモリ上で扱い、明示的な音声ファイルとして保存しない方針にしました。

認識が終われば、音声データはファイルとして残らない。
この設計は、運用面でも気分的にもすっきりします。

ただし、「音声ファイルを残さない」と「完全に何も残らない」は別のことです。

認識後のテキストはクリップボードに入り、貼り付け先のアプリにも渡ります。
クリップボード履歴アプリを使っていれば、そこに残る可能性もあります。
デバッグ用のログを有効にしていれば、文字起こし結果がファイルに記録されることもあります。

ローカル推論は、クラウドに送らないという点で大きなメリットがあります。
ただし、ローカルで動かしているからといって、すべての痕跡が消えるわけではありません。

私の方針は、少なくとも自作ツール側で不要な音声ファイルを増やさないことです。

必要がないなら音声そのものは保存しない。
残すとしても、認識後のテキストだけにする。

完全な秘密保持ではないけれど、できる範囲でデータを最小化する。
そのくらいの割り切りが、自分用の道具としてはちょうどよかったです。

メモリ上で扱うことで、SSDの書き込みによる劣化も防げるんじゃないかと思ってこの方法にしています。

---

文字起こし結果をすぐ貼り付ける

Whisperの結果をターミナルに表示するだけでは、音声入力としては不十分です。

ツールを作り始めた当初、まずそこで止まっていました。

文字起こしはできている。
でも、それを実際の入力欄に移すには、コピーして、切り替えて、貼り付けるという手間がかかる。

本当に欲しいのは、今書いている場所にそのまま文章が入ることです。

WordPress、Obsidian、メモアプリ、ブラウザの入力欄、メール。
どこでも同じように使いたい。

そこで、認識結果をクリップボードに入れ、AppleScriptでcommand + vを実行して貼り付ける形にしました。

テキスト入力欄にカーソルがあれば、アプリを問わず同じ仕組みで貼り付けられます。

注意点もあります。

• クリップボードを上書きするので、貼り付け前に何かコピーしていた場合は失われます。
• 貼り付け先にカーソルがなければ失敗します。
• アプリによっては自動貼り付けが制限される場合もあります。
• AppleScriptや自動操作にはアクセシビリティ権限が必要です。

これらはすべて許容できる制約だと判断して、使っています。

これもAIに頼んだらコードを書いてくれます。

---

音声入力の開始と終わりに効果音をつける

細かい話ですが、効果音の扱いも大事だなと思いました。

右Shiftを押しただけだと、音声入力が開始されたのかが分からない。

ですから音声入力の開始と終わりに効果音をつけることにしました。

これがあるのとないのとでは、やりやすさが全然違います。

開始の時の効果音と、終わりの時の効果音もちょっと音を変えています。
小さなことですが、これも音声入力のやりやすさを地味に変えてくれます。

---

初期プロンプトと辞書補正を分けて考える

Whisperの認識結果を自分の用途に寄せるには、初期プロンプトと辞書補正の両方が役に立ちます。

ただし、この2つは役割が違います。

初期プロンプトは、認識が始まる前に文脈のヒントを与える仕組みです。

ここに自分がよく話すジャンルや固有名詞を入れておくと、何も与えないよりは正しく認識されやすくなります。

ただし、初期プロンプトは魔法ではありません。

入れた単語が必ず正しく出るわけではなく、入れすぎると逆に認識が引っ張られすぎることもあります。「ヒントを渡す」程度に考えておく方が実態に合っています。

だから、確実に直したい表記は辞書補正で対応します。

• 初期プロンプトは「認識前の文脈づくり」。
• 辞書補正は「認識後の確実な修正」。

辞書補正は認識後に文字列を置換する仕組みなので、条件さえ合えば必ず置き換わります。

この2つを使い分けることで、認識精度への期待値を適切に保てるようになりました。

よく扱うジャンルで、上手く変換してくれない単語を入れています。たとえば「短鎖脂肪酸」とかね。

---

辞書補正で同じ誤変換をつぶす

実際に使っていると、同じ誤変換が繰り返し出てきます。

認識されがちな表記	直したい表記
チャットジーピーティー/ チャットGPT	ChatGPT
ジェミニ	Gemini
クロード	Claude
パープレキシティ	Perplexity
ディープシーク	DeepSeek
ギットハブ	GitHub
パイソン	Python
ライジン	RIZIN
ユーエフシー	UFC

こういうものを毎回手で直すのは、音声入力の良さを半分くらい消してしまいます。

AIに完璧を求めるのではなく、AIの癖を運用で吸収する。
辞書補正はそういう考え方です。

同じ間違いが3回出たら辞書に入れる、というくらいのペースで少しずつ育てていくと、使うほどに快適になっていきます。

句読点やカギ括弧も同じ考え方で扱えます。
「とうてん」を「、」に、「くてん」を「。」に、「かぎかっこ」を「「」に直す。

ただし、辞書補正は増やしすぎると意図しない置換が増えます。

便利にするための設定が逆に邪魔になることがあるので、本当に必要なものだけを少しずつ足す方が安全です。

---

「ボツ」で貼り付けを止める

音声入力では、話し始めたあとに失敗することがあります。

• 途中で言い間違える。
• 話す内容がまとまらない。
• やっぱりこれは入力したくないと思う。

こういうとき、キーボードなら消せばいいだけです。
でも音声入力では、一度に長い文章が入力欄に流れ込みます。

失敗した内容を簡単に捨てられないと、入力そのものが怖くなります。

「ボツ」や「入力破棄」と言ったら、その録音結果を貼り付けないようにしました。

話している途中で失敗しても、最後に「ボツ」と言えばなかったことにできる。
この仕組みを入れてから、音声入力への心理的なハードルがずいぶん下がりました。

失敗してもすぐ捨てられるとわかっているだけで、話し出しのためらいが減ります。

普段自分が絶対に使わない言葉を登録して、入力を破棄できるようにするのがいいです。私にとって「ボツ」とか「入力破棄」がそうでした。

---

無音時の幻覚出力を捨てる

Whisperを音声入力に使っていると、何も話していないのに文章が出てくることがあります。

「ご視聴ありがとうございました」
「チャンネル登録お願いします」
「次回予告」

動画字幕の学習データから来ていると思われる定型文が、無音や環境音から生成されることがあります。

文字起こし用途なら笑い話で済みます。
でも、音声入力では困ります。

何もしていないのに、入力欄に勝手に文章が貼られるからです。
これが続くと、ツールへの信頼感が根本から崩れます。

対策は何段階かに分けた方が安定します。

• まず録音時間が短すぎる場合はその場で捨てる。
• 音量が小さすぎる場合も捨てる。
• 認識後に空文字や極端に短い結果は貼り付けない。
• それでも抜けてきた幻覚フレーズは、NGワードとして登録して弾く。

完璧には防げませんが、よく出るパターンを押さえるだけで、ストレスは大きく減ります。

音声入力では、「何を正しく認識するか」と同じくらい、「何を貼り付けないか」が重要です。

出力を管理する、という視点が抜けると、ツールとして信頼できなくなります。

---

Macの権限設定はつまずきやすい

自作音声入力ツールでは、Macの権限設定でつまずきやすいです。

• マイク録音にはマイクの許可が必要です。
• 右Shiftの検出にはアクセシビリティと入力監視の許可が必要です。
• AppleScriptで他のアプリを操作するにもアクセシビリティの許可が必要です。

これらは独立していて、一つを通してもほかがなければ動きません。

さらに厄介なのは、.commandファイルから起動する場合、そのファイルを実行するターミナルアプリに権限が与えられている必要があるという点です。

iTermなどを使っている場合は、そのアプリ自体に権限を設定しなければなりません。

「コードは正しいはずなのに動かない」という状況の多くは、権限の問題です。

「右Shiftが反応しない」
「録音はできるのに貼り付けだけ失敗する」
「ターミナルから実行すると動くのに.commandだと挙動が違う」

こういう症状が出たときは、まずシステム環境設定の権限まわりを確認する。
これがトラブルシューティングの出発点になります。

---

安定運用を優先する

MLXやmlx-whisperは更新されます。

• 速くなるかもしれない。
• 不具合が直るかもしれない。
• 新しいモデルに対応するかもしれない。

それは魅力的です。
でも、毎日使う道具に対して「最新を追いかける」のは必ずしも正解ではありません。

このツールは多くの部品で動いています。

Python、venv、mlx-whisper、MLX、sounddevice、pynput、pyperclip、AppleScript、マイク、Whisperモデル、初期プロンプト、辞書補正、破棄ルール。

どこか一つが変わるだけで、別の何かが動かなくなる可能性があります。

更新は、それ自体がリスクです。

だから、今動いている環境をなるべく長く保ちます。

• 安定して動いているフォルダは残す。
• 新しいライブラリは別のvenvで先に試す。
• モデルを変えるときも元の設定を残しておく。
• 辞書補正は少しずつ追加する。
• 大きな変更をした日は、すぐ本番として使わない。
• 調子が悪くなったら、最後に変えた場所から遡る。

音声入力ツールは、毎日使うほど「壊れないこと」の価値が上がります。

今日も昨日と同じように使える。
それだけで、道具として十分機能しています。

最新化より、安定運用です。

WhisperのLarge V4とかのさらに進化したモデルが出ない限りは、アップデートはしないつもりです。

---

よくあるトラブルと見る場所

自作していると、だいたい同じような問題が出ます。
メモとして残しておきます。

症状	見る場所
右Shiftが反応しない	アクセシビリティ、入力監視、Secure Input
録音されない	マイク権限、入力デバイス名、デフォルト入力
Shureマイクが選ばれない	デバイス名の表記、USB接続、ハブの構成
認識精度が急に落ちた	内蔵マイクに切り替わっていないか
貼り付けされない	入力欄にカーソルがあるか、AppleScript権限
変な定型文が出る	無音判定の閾値、録音時間、NGフレーズの設定
句読点がおかしい	辞書置換の順序、表記ゆれ
「ボツ」が誤爆する	破棄コマンドの条件の厳密さ
更新後に壊れた	ライブラリのバージョン、モデルの互換性、venv

こういうチェック表を自分用に残しておくだけで、トラブル時に落ち着いて対処できます。

「動かない」という状態は焦りを生みます。
でも、見る場所が整理されていれば、たいていは一つずつ潰せます。

---

使ってわかったこと

実際に使ってみて大事だったのは、モデル選びでだけではありませんでした。

もちろん、Whisperのモデルは大事です。
MLXで動くことも、4bitモデルで現実的な速度にすることも大事です。

でも、それらは「音声入力が動く」という意味での大事さであって、「毎日使いたいと思う」という意味での大事さとは少し違います。

毎日使いたいと思えるようになったのは、もっと手前の設計が整ってからでした。

• 右Shiftで自然に録音できること。
• 使いたいマイクが自動で選ばれること。
• 話した内容が今書いている場所にすぐ入ること。
• 自分の言葉づかいに寄せられること。
• 失敗してもすぐ捨てられること。
• 変な出力が勝手に貼り付かないこと。
• 使うたびに道具が壊れていないこと。

Whisperはあくまで音声認識エンジンです。
それを日常の入力手段にするには、操作の入口から出口まで、全体の流れを設計する必要がありました。

AIと一緒に作っていくと、非エンジニアでも痒い所に手が届くツールに仕上げられるので、すごい時代になったなーと。

---

同じようなものを作るなら

同じようなツールを作りたいなら、最初はAIにこう聞くと進めやすいです。

MacのApple Silicon環境でmlx-whisperを使い、右Shiftを押している間だけ録音し、指を離したら日本語で文字起こしして、結果をクリップボードに入れて現在の入力欄へ貼り付けるPythonツールを作りたいです。venvで環境を分け、マイクは名前にShureを含む入力デバイスを優先して選びたいです。さらに、初期プロンプト、辞書補正、「ボツ」による入力破棄、無音時の不要出力対策も入れたいです。Macの権限設定で必要な項目も含めて、段階的に手順を教えてください。

ただし、一気に完成版を作ろうとしない方がいいです。

• まずマイクで録音する。
• 次にWhisperで認識する。
• 次にクリップボードへ入れる。
• 次に貼り付ける。
• その後で右Shift、辞書補正、破棄コマンド、無音対策を足していく。

一つ動くたびに確認して、安定していることを確かめてから次へ進む。
小さく動かして、少しずつ育てる方が、結果的に速く完成します。

---

まとめ

MacでWhisperを動かすこと自体は、今ではそれほど特別なことではありません。
でも、動かすだけでは、快適な音声入力ツールにはなりません。

大事なのは周辺の設計です。

• 録音をどう始めるか。
• マイクをどう選ぶか。
• 音声ファイルをどう扱うか。
• 結果をどこへ通すか。
• 表記をどう補正するか。
• 失敗をどう捨てるか。
• 変な出力をどう弾くか。
• 動いている環境をどう守るか。

ここまで整えて、はじめて「毎日使える道具」になります。

私にとって、この自作音声入力ツールは単なる文字起こしソフトではありません。

ブログ執筆や読書メモを支える、自分専用の入力環境です。

非エンジニアでも、AIに相談しながらターミナルでここまで作れました。

全部を理解しているわけではないし、エラーも出るし、遠回りもしました。
それでも、作りたいものを言葉にして、AIに手順を出してもらい、試して、エラーを戻して、また直す。

この繰り返しで、自分用の道具は作れます。

Whisperをローカルで動かすだけで満足せず、自分の使い方に合わせてどう録音し、どう貼り付け、どう補正し、どう捨てるかまで設計する。

そこまでやると、ローカル音声入力は一気に実用的になります。

参考までに。それでは！

---

追記：CodexアプリでもMac全体の音声入力が使えるようになった

なんとMac版Codexアプリの設定から、デスクトップ上のどこでも使える音声入力を有効にできることに気づきました。

Codexアプリ内だけではなく、Mac上の任意の入力欄にカーソルを置いて音声入力できます。しかも、辞書機能や履歴機能も用意されています。すごすぎる。

正直、普通にMacで高精度な音声入力を使いたいだけなら、まずCodexアプリの音声入力を試すのが一番楽だと思います。Python環境を作ったり、MLXやmlx-whisperを設定したりする必要がないからです。

一方で、私の環境では、M4 iMac上でMLX Whisperをローカル処理している自作ツールの方が、体感では少し速く感じる場面もあります。また、Codexアプリの音声入力はサーバー側で処理している可能性があるため、時間帯によって処理速度が変わるようにも感じます。

それと、サーバー処理なので音声データを外部に送る可能性がある点は注意が必要です。ただ、OpenAIのサービス内で処理されると考えるなら、出どころのよくわからない音声入力アプリに音声を渡すよりは、安心感があるとも感じています。

こりゃ、音声入力でお金とってるサービス駆逐されるな(((( ;ﾟдﾟ)))ｱﾜﾜﾜﾜ

---

参考リンク

OpenAI Whisper
https://openai.com/research/whisper/

Apple MLX GitHub
https://github.com/ml-explore/mlx

Apple MLX Documentation
https://ml-explore.github.io/mlx/

mlx-whisper｜PyPI
https://pypi.org/project/mlx-whisper/

mlx-community/whisper-large-v3-mlx-4bit｜Hugging Face
https://huggingface.co/mlx-community/whisper-large-v3-mlx-4bit

sounddevice｜Python package
https://python-sounddevice.readthedocs.io/

pynput｜Python package
https://pynput.readthedocs.io/

pyperclip｜Python package
https://pyperclip.readthedocs.io/