英語もコードもできないおっさん、iPhoneのマイクが無言で死ぬ地獄をAIと抜けた件

プログラミング経験ゼロの個人開発者が、AIに英語学習アプリを作らせるプロジェクトで、iPhone のマイク問題で丸一日が消えた。AIに役割を6つに分けた専属コーチ陣の構成は完成したが、実際にレッスン画面を開いて「Hello」と話しかけても、AI コーチは黙ったままだ。エラー表示もなく、画面には「listening」と書かれている。ここから始まった「音声疎通地獄」の原因は、実は1つではなかった。第一に、音声を処理する AudioWorklet に「出力先」が繋がっていない。入口で音が止まっていた。第二に、AirPods 接続時の iOS の動作——マイク取得時にサンプリングレートが変わるが、アプリ側が古い設定のまま読んでいた。第三に、エコーキャンセル機能が無視されていた。スピーカー経由で鳴った AI コーチの声をマイクが拾い直し、無限ループに陥っていたのだ。

AIの鬼の視点は、この解決プロセスに隠されている。コードが読めない人物が最初にやったのは「修正」ではなく「見える化」だ。マイクレベルメーター、デバッグ HUD、診断ビーコン（状態をサーバーログに流す仕組み）を先に作った。すると「メーターは動く、だが送信フレーム数はゼロ」という事実から、音声パイプライン内の問題に一点集中できた。さらに興味深いのは、最終解決策の格好悪さだ。AudioWorklet は新しく推奨されている方式だが、動かず。非推奨で「いずれ廃止」と言われている ScriptProcessorNode に戻すと、確実に動く。ここで示されたのは「推奨される方式」と「実機で動く方式」が別物である可能性だ。これは iOS Safari という特殊環境の制約を示しており、エンジニアであっても無視できない現実である。加えて「1回目が動いた」は何の保証にもならず、2回目、アプリ再起動、セッション復帰といった実際の使用シーンでこそ問題が露出するという教訓も含まれている。

中小企業にとって、この事例の本質は「スマートフォン向けブラウザ開発は特殊な世界」という認識だ。マイク、スピーカー、パーミッション、OS の仕様の組み合わせは、デスクトップとは比較にならない複雑さを持つ。非エンジニアが開発する場合、最初にやるべきは「可視化」——見えない問題を数字やメーターとして見える形にすること。次に「最小化」——複数の原因候補を切り分け、範囲を絞ること。このふたつのプリンシパルを押さえれば、AI との協働でも実機固有の問題に立ち向かえる。実装の正確さよりも、問題の見え方が、個人開発から組織開発への分岐点になる。