前回は、返事を確かめる話でした。今日は、頼み方そのものを変えた話です。
最初の計画は、ささやかだった
やりたかったことは、ささやかでした。Mac には、キーを二度押しすると音声入力が立ち上がる仕組みがあります。あれを、手元のボタンから起こしたい。デッキに「音声入力」ボタンを置いて、押したら Mac がマイクを開いて、あとは話すだけ ── そういう計画です。
STIL.HUB はキー操作を Mac に送れるので、その「二度押し」を送ればいい。簡単なはず、でした。
Mac は、聞いてくれない
送ってみると、何も起きません。ログの上では、キーは届いて、実行されている。でも、音声入力は立ち上がらない。
調べると、修飾キー(control など)を単体で送るには、通常のキー操作とは別の、専用の送り方が要ると分かりました。そこを直して、たしかにキーは正しく届くようになった。それでも、立ち上がらない。今度は、二度押しの検出そのものが、どうやら物理のキーボードの層で行われているらしく、ソフトウェアで合成したキーには反応しないのです。
さらに悪いことに、実機では「音声入力を有効にしますか」という確認の窓が、押すたびに何度も出てくる状態になりました。立ち上がりはしないのに、確認だけが積み上がっていく。こじ開けようとするほど、泥沼になっていく手応えがありました。
頼むのを、やめた
そこで、前提を疑うことにしました。そもそも、なぜ Mac に聞かせようとしているのか。
マイクなら、手元の iPhone にも付いています。それも、いつも口元の近くにある。声を文字にする仕組みも、iPhone は端末の中に持っています。だったら、Mac の音声入力を遠隔でこじ開けるのではなく、iPhone が聞いて、文字にして、その文字を Mac に打ち込めばいい。
Mac 側から見れば、届くのはただの文字入力です。特別な許可も、こじ開ける対象も、確認の窓もない。キー操作を送る道は最初からあるのだから、その道に、音声認識の結果を流すだけ。方針を変えてからは、驚くほどまっすぐに進みました。文字はクリップボードを経由せずに打ち込むので、Mac 側のコピー履歴も汚しません。日本語の文章を打ち込んで、保存して、読み戻して一字も違わないことを確かめました。
もうひとつの回り道
実は、この機能にはもうひとつ小さな回り道があります。最初は、iPhone のキーボードに付いているマイク(音声入力キー)を使ってもらう設計でした。ところが、キーボードの音声入力は、認識する言語がキーボードの言語に引きずられて、日本語と英語のキーボードを併用していると、日本語のつもりが英語で認識されることがある。
なので、アプリの中に音声認識を持たせました。端末の言語で、端末の中で認識する。ボタンを押して、話して、送る。ここで使っているのは、声のアプリ NOTE と同じ、iPhone の中の音声認識です。家族の中で、技術が合流した瞬間でした。
土俵を、変える
この一件で覚えたことは、こうまとめられます。相手の仕組みをこじ開けられないときは、土俵を変える。「Mac の機能を遠隔で起こすには」という問いに粘っていましたが、答えは「起こさなくていい」でした。
マイクは口元にあるほうがいい。認識は端末の中でやればいい。Mac には、結果の文字だけ渡せばいい。いま STIL.HUB でいちばん気に入っている機能は、諦めた計画の跡地に建っています。
次回
こんどは、コードの外の話です。App Store に提出したら、サブタイトルの「iPhone を、」という言葉が使えないと指摘されました。言葉を差し替えて回った話をします。
STIL.HUB は App Store で公開しています。
