nobetsuを作った──日本語音声入力が止まらないためのIME迂回と差分注入【開発記】

1. 結論：日本語で「のべつ幕なし」に話せる音声入力を作った

nobetsu（のべつ）は、macOS 26以降のApple Silicon Macで動く、日本語専用の音声入力アプリである。⌘を0.5秒押して離す。すると手をキーボードから放したまま、話した端から、いまカーソルがあるアプリへ文字が入っていく。もう一度⌘を軽く叩くかESCで止まる。

先に境界線を引いておく。日本語を話しながらカーソル位置へ直接入力すること、起動後にキーを押し続けなくてよいこと、無料で使えることは、macOS標準の音声入力ですでにできる。 Apple Silicon Macでは音声入力中もキーボードを併用でき、30秒の無音で自動停止するものの、話し続けているセッションに固定の分数上限は案内されていない。^[11] nobetsuは、この基本体験を発明したアプリではない。

それでも別に作った理由は、日本語の長文で詰まりの原因になったIME／ライブ変換の経路を通さず、変換済みの未確定文を自前の差分アルゴリズムで対象アプリへ入れるためである。さらに、その迂回路、差分修正、安全停止の実装と計測を、読めるソースとしてすべて公開した。ここがnobetsuの新規性であり、この記事の中心である。

押している間だけ録音するプッシュ・トゥ・トークではない。停止後に全文をまとめて貼るボイスメモでもない。話し続けている最中に、変換済みの日本語が対象アプリへ入り続ける。アプリ側に時間制限は設けていない。 音声認識は端末内で完結し、アカウントも外部APIキーも要らない。コードはMITライセンスでGitHubに公開した。^[1]

名前は「のべつ幕なし」から取った。芝居で幕を下ろさず演じ続けること、転じて絶え間なく続くこと。欲しかった体験を、そのまま名前にした。

このプロジェクトで面白いのは、音声認識モデルを一から作ったことではない。AppleがmacOS 26で開放した部品を使いながら、日本語入力の詰まりやすい経路だけを外し、未確定文字を安全に他アプリへ同期する小さな機械を組んだことにある。

2. なぜ作ったのか：欲しかったのは「録音」ではなく、思考の通り道だった

長いプロンプトや設計メモをAIエージェントへ渡すとき、頭の中ではもう次の文ができているのに、指が追いつかない。音声なら速い。しかし既存の体験には、どこか一つ引っかかりがあった。

• macOS標準の日本語音声入力では、長く話すほど認識結果とライブ変換が同じ未確定文を更新し続け、変換表示が追いつかず詰まる現象を実際に経験した。
• 多くのAIアプリ内マイクは、一回の入力時間や無音判定に区切りがある。
• 海外の音声入力アプリには、キーを押している間だけ録音し、離した後に全文を貼る設計が多い。
• 長文用のハンズフリーがあっても、停止するまで入力欄には届かない製品がある。

これらは不具合というより、目的が違う。録音をきれいな文章へ整えてから貼るなら、停止後の一括処理は合理的である。会議の文字起こしなら、対象アプリへ一文字ずつ入れる必要もない。

欲しかったのは、もっと地味で、もっと直接的な道具だった。ひらめいた順に話し、その場の入力欄へ文章を育て、必要なら途中でEnterを押して送信し、そのまま続きを話す。 売るために機能を増やすのではなく、自分が毎日使う摩擦だけを削った。

文章を作るための通常ウィンドウやDockアイコンは持たず、待機中はメニューバーの波形アイコンに収まる。ただし「画面要素が何もない」わけではない。認識中は小さなカプセル型の目印が浮かび、赤い脈動と声量バーでマイクの状態を示す。そこから一時停止、マイクによる再開、設定、終了を操作でき、目印はドラッグして移動できる。必要な人は、認識中の文字を画面下部へ流すオーバーレイも有効にできるが、入力先と重なりやすいため既定では切ってある。設定全体はメニューバーから開く。依存ライブラリはゼロで、SwiftとOS標準フレームワークだけに絞った。

3. 類似アプリは世界にいくつあるのか：固定の総数より「方式」を数える

音声入力アプリには公的な製品台帳がない。App Store外の配布、GitHubの個人開発、会議文字起こしとの兼用、改名や終了があるため、「世界に何個、日本に何個」と固定値を断言するのは不正確だ。

そこで2026年8月23日、macOSでカーソル位置へ音声入力できることを公式情報で確認できた代表的な第三者製品9件を調べた。海外発7件（Superwhisper、Wispr Flow、Willow、Aqua Voice、VoiceInk、MacWhisper、TypeWhisper）、日本発2件（KoeType、いきなりAI 音声タイピング）である。これは市場総数ではなく、方式の違いを見るための標本だ。Apple標準音声入力は別に基準として置いた。^{[2][3][4][5][6][7][8][9][10]}

日本語対応そのものは、もう珍しくない。Whisper系の多言語モデルや商用サービスが日本語を扱い、国内製品も現れた。何よりmacOS標準音声入力が、日本語、ハンズフリー、発話中の直接反映、無料という主要な体験をすでに満たしている。したがって、これらをnobetsu固有の新機能として数えるのは誤りである。

nobetsuが新しく作ったのは、機能一覧ではなく入力経路である。第一に、変換済みの日本語を受け取り、CGEventのUnicode入力でIMEとライブ変換を丸ごと迂回する。 第二に、確定を待たず未確定文を先に見せ、認識が過去を書き換えたら最長共通接頭辞を使って変化した末尾だけ直す。この二つを、安全停止まで含めて全ソース、テスト、実測とともに公開した。今回確認した製品の公開資料では、この組合せを実装として追える別例は見つからなかった。競合より機能が多いのではなく、標準音声入力で残った日本語固有の詰まりだけを、細く深く解いたのである。

4. 日本語だけにある難所：認識の後ろに、もう一つ「変換」がある

英語の音声認識が good morning を返せば、それはほぼそのまま入力できる。日本語では音から「きょうははしで…」のような読みを得た後、文脈を見て「今日は箸で」「今日は橋で」などを選ぶ必要がある。通常のキーボード入力では、この役目をIMEが担う。

Appleの日本語入力には、ひらがなを入力するそばから文脈に合う漢字かな交じり文へ書き換える「ライブ変換」がある。^[12] 短い入力では便利だが、長い音声入力では別の動きが重なる。音声認識も、後続の音を使って直前の推定を更新する。IMEも、伸び続ける未確定文を見て漢字や文節を組み替える。二つの“後から書き直す仕組み”を直列につなぐと、同じ未確定領域を追いかけ続ける。 nobetsuの開発環境では、この経路で変換が追いつかず、連続入力が詰まる現象を観測した。これは「標準音声入力に直接入力機能がない」という問題ではない。直接入力はできるが、日本語の変換経路が長文に耐えなかったという問題である。

認識器とIMEの両方に未確定文を持たせない。変換済みの日本語を受け取り、最後の注入だけをnobetsuが管理する。

nobetsuはIMEを速くしようとはしなかった。その工程を通らない。 macOS 26のSpeechAnalyzerへマイク音声を渡し、DictationTranscriberから漢字かな交じりの日本語を受け取る。それをCGEvent.keyboardSetUnicodeStringでUnicode文字列として対象アプリへ送る。AppleのAPIは、仮想キーから通常行われる文字変換をUnicode文字列で上書きできる。^[13][14][15]

通常の考え方
マイク → 音声認識 → 読み／未確定文 → IMEで再変換 → 対象アプリ

nobetsu
マイク → AVAudioEngine → SpeechAnalyzer + DictationTranscriber
      → 変換済み日本語 → 辞書置換 → CGEvent Unicode → 対象アプリ
                                     （IMEを通らない）

AppleはSpeechAnalyzerを長時間・遠距離音声、会議や講義にも向くオンデバイスAPIとして紹介している。未確定のvolatile resultと、後から変わらない確定結果を非同期に返せる。nobetsuはこの新しい部品を「録音の文字起こし」ではなく、「どのアプリにもつながる日本語入力装置」に組み替えた。^[13]

5. 音声から一文字が届くまで：小さな処理を順番どおりにする

開始から入力までの流れは次の通りだ。

1. CGEventTapが⌘単独の0.5秒長押しを検知する。⌘を押している間に別キー、クリック、ホイールが来たらショートカットと判断して取り消す。
2. マイクと音声認識の許可を確認し、ja-JPのDictationTranscriberを準備する。
3. AVAudioEngineの入力を、SpeechAnalyzerが求める形式へAVAudioConverterで変換し、AsyncStreamへ流す。
4. 認識器は同一区間について、変化する未確定全文と確定全文を返す。句読点、遠距離集音、頻繁な確定を有効にしている。
5. 個人辞書を長い規則から適用する。「苦労してくる」を「Cloneしてくる」のように、認識としては自然だが用途では困る語を直す。
6. 前回すでに入力した未確定全文と比較し、変わった末尾だけをBackspaceとUnicode入力で更新する。

音声の取得、端末内認識、辞書、差分注入を小さく分離する。各段階の役割を一つに混ぜないから、遅延や不具合の場所を追える。

開始音を鳴らす順番にも理由がある。先に音を鳴らしてからマイクを起こすと、人は合図と同時に話し、先頭が欠ける。そこでnobetsuはマイクが本当に動いた後、Bluetooth機器の切替を0.25秒だけ待って開始音を鳴らす。停止時は逆に、認識の後始末より先に入力の門を閉じ、マイクのtapを外し、engineをresetし、インスタンス自体を捨てる。標準音声入力とマイクを奪い合わないためである。

6. 確定を待たない：楽観的に入力し、変わった末尾だけ直す

SpeechAnalyzerの未確定結果は、追記だけではない。後続の音を聞いて過去の語を修正する。たとえば同じ区間が次のように届く。

1回目  今日は音声にゅう
2回目  今日は音声入力を
3回目  今日は音声入力を試します。

毎回全文を貼れば重複する。毎回全文を消して打ち直せば、ちらつき、打鍵渋滞、誤削除が起きる。そこで前回と今回の最長共通接頭辞を求める。

前回: 今日は音声にゅう
今回: 今日は音声入力を
共通: 今日は音声

操作: 末尾「にゅう」だけ3文字削除 → 「入力を」だけ挿入

認識結果は毎秒4〜5回ほど届くため、反映は0.25秒に一度へ絞る。SwiftのCharacter単位で差分を数えるので、絵文字や結合文字をバイト数と取り違えて余分に消さない。一方、CGEventへ送るときはUTF-16へ変換し、一イベント16単位に分割する。長すぎるイベントを取りこぼすアプリがあるためだ。

全文をやり直さず、安定した前半は触らない。変化した末尾だけを最小限に交換するから、未確定でも文字を先に見せられる。

この方式はデータベースの楽観的更新に近い。「いま見えている推定を先に出し、前提が変わった場所だけ直す」。確定を待つより速く、全置換より穏やかである。

7. 本当に難しかったのは認識ではなく「人の文章を壊さない」こと

差分計算だけなら短い。しかし対象は自分のテキスト領域ではなく、Slack、ブラウザ、エディタなど他アプリの入力欄である。利用者は音声入力中にもEnter、Shift+Enter、クリック、手入力をする。そこへ古い差分を当てると、人が書いた文字までBackspaceで消してしまう。

nobetsuは、次のように安全側へ倒す。

• 手入力・クリックを検知したら基準を捨てる。 次の未確定全文が直前の文章で始まる場合だけ、続きを重複なく再開する。つながらなければ、その区間は諦める。
• Enterは0.12秒預かる。 nobetsuが直前に投げた1〜2文字を先に到着させてからEnterを再送し、送信後の空欄に「。」だけ残る競合を防ぐ。
• 送信済み文章は“画面にはない仮想接頭辞”として守る。 認識器が後から過去を書き換えても、送信済みの場所へBackspaceしない。
• Shift+Enterは改行として区間を切らない。 チャットの送信と文章内改行を分ける。
• 停止後の遅い確定結果は捨てる。 すでに見えている文章を二重入力しない。
• 入力先から離れたら既定で停止する。 別アプリへ移った後の独り言が、同僚宛ての欄へ流れる事故を防ぐ。

速く入れるだけでは道具にならない。送信、人の割り込み、フォーカス移動、停止後の遅延結果を別々の門で止める。

フォーカス監視も通知任せではない。Electronアプリは入力欄をAccessibilityへ公開しないことがあり、通知はアプリごとに挙動が違う。0.4秒ごとに別キューから確認し、「文字入力できない場所」が2回続いたときだけ離脱と判定する。分からない状態は停止理由にしない。この実装は、認識精度のベンチマークには出ないが、日用品としての信頼を決める部分である。

8. 実測して選び、約3,000行まで削って公開した

エンジンは名前で選ばず、同じMacで測った。MacBook Air M4、macOS 26.5.2、日本語の自然発話80〜105秒で、3構成を比較した結果がこれである。

SpeechTranscriberは精度で大敗したわけではない。しかしこの環境では初回表示が11.79秒かかり、確定も最大8.34秒遅れた。「話しながら入力欄を見る」用途には、DictationTranscriberの方が合った。未確定を先に出す設計も、感覚ではなくこの差から決めた。

公開している本体はSwift 12ファイル、約2,965行。ビルドスクリプトはswiftcでコンパイルし、辞書を同梱し、署名して/Applications/nobetsu.appへ置く。Xcodeプロジェクトも外部依存もない。テストは、間違えると文章を壊し、しかも純粋関数として検証できる「辞書の置換」「差分計算」「送信済み接頭辞の保護」に絞った。

完成品は万能ではない。macOS 26とApple Siliconが必要で、UIも認識言語も日本語だけ。CGEventのUnicodeを独自解釈するアプリでは入力できない可能性があり、合成キーイベントを送るため権限も要る。それでも、狭い条件の中で欲しかった体験はできた。

新しいモデルを発明しなくても、OSの新しい能力と、現場で起きた小さな失敗を丁寧につなぐと、今までなかった道具になる。 nobetsuは販売商品ではなく、自分の「ここだけ直れば」を最後まで掘った結果である。役に立ちそうなら、コードも動画も設計理由もGitHubに置いてある。自由に試し、読み、必要なら自分向けに変えてほしい。^[1]