AIやCodexを使ってWebアプリを作っていると、
「コード上では問題ないはずなのに、実機では動かない」
ということがあります。
読者
YuLab
今回、自分が作っていた幼児向けWebアプリでも、その問題にぶつかりました。
コード上のテストではPASS。
ところが、iPhone Safariの実機で確認すると、画面をタップしても音声が出ませんでした。
最終的にはWeb Speech APIを使い続けるのではなく、MP3の音声ファイルを用意して再生する方式へ変更。
すると、iPhone実機でも問題なく音が出るようになりました。
今回感じたのは、AIが提案した一つの方法にこだわり続けるより、動かないなら別の手段を出してもらうことも大切ということです。
コード上のテストはPASS。でもiPhoneでは何も起きなかった
今回問題が起きたのは、幼児向けWebアプリに音声を付けていたときでした。
タップすると、その対象の名前を音声で読み上げる機能です。
コード上ではテストを通っていました。
そのため、最初は普通に動くものだと思っていました。
しかし、iPhone Safariで実際に確認してみると、タップしても何も起きない。
音がまったく出ませんでした。
この時点で、「コード上でテストが通っている＝実際の端末でも動く」とは限らないことを改めて実感しました。
最初に疑ったのはWeb Speech API
音声にはWeb Speech APIを使っていました。
ブラウザ側で音声を生成し、読み上げてもらう仕組みです。
今回の症状を見たときは、「Web Speech APIがうまく呼び出せていないのでは」「iPhone Safari上では音声生成がうまくいっていないのでは」と考えました。
ただ、ここで一つ問題がありました。
原因を細かく追っていけば、さらに修正方法が見つかった可能性はあります。
一方で、自分がやりたかったことは、Web Speech APIを使うことではなく、タップしたら音声が出るアプリを完成させることでした。
そこで、同じ方法を追い続けるのではなく、別の方法へ切り替えることにしました。
MP3ファイルを使う方式へ変更した
次に試したのはシンプルです。
必要な音声をMP3ファイルとして用意し、それをアプリから再生する方式へ変更しました。
つまり、ブラウザにその場で音声を作ってもらうのではなく、あらかじめ用意した音声ファイルを再生するという形です。
変更後、iPhone実機で確認すると問題なく再生されました。
ここでは、Web Speech APIの原因を完全に特定したわけではありません。
今回の環境では、Web Speech APIを使った方法では実機で音が出ず、MP3方式へ切り替えたことで目的を達成できたという結果です。
Web Speech APIが悪いわけではない
今回の経験だけで、「Web Speech APIは使わない方がいい」とは思っていません。
むしろ、最初に試す方法としては十分ありだと思っています。
理由は、AIを使って何かを作るときに、できるだけ自分の手を動かさずに完成させられるというメリットがあるからです。
音声ファイルを一つずつ準備しなくても、Web上の仕組みだけで読み上げが成立するなら、その方が手間は少なくなります。
AIを使って制作する人の多くは、「どれだけ楽に作れるか」「どこまでAIに任せられるか」という部分にも価値を感じていると思います。
そのため、自分なら今後もまずはAIだけで完結しやすい方法から試します。
ただし、そこで長時間詰まるなら話は別です。
AIができる範囲が広いほど、一つの方法にとらわれやすい
AIやCodexはかなり多くのことができます。
こちらが「Webだけで実装してほしい」と条件を付ければ、その条件の中で何とか解決しようとしてくれます。
これは便利です。
ただ、その方法が必ず最適とは限りません。
今回のように、Web Speech APIで解決しようとするより、MP3ファイルを使った方が早く安定して動くという場合もあります。
AIができる範囲が広いからこそ、AIが今出している解決策だけが選択肢だと思わないことが大切だと感じました。
同じ不具合にハマったら、AIに別手段を出してもらう
今回から、自分は次のように考えるようになりました。
まずは、一つの方法で試してみる。
それで問題なく動けば、そのまま進める。
しかし、何度か試しても解決しない、あるいは同じ不具合に長時間ハマっている場合は、「この方法を直して」だけではなく、「他にどんな実装方法がある？」とAIに聞く。
そして、出てきた候補を比較します。
- 実装にかかる時間
- 安定して動くか
- 自分の作業がどれだけ必要か
- 今後の保守が大変ではないか
その中から優先度の高いものを順番に試していく。
この方が、一つの不具合に延々と時間を使うより、結果として完成まで早く進められる場合があります。
原因究明と「まず動かす」は別
もちろん、原因を細かく調べることにも価値があります。
技術的な理解を深めたいなら、「なぜiPhone Safariでは動かなかったのか」まで追うことも大切です。
ただ、個人開発ではそれが必ず最優先とは限りません。
自分の場合、まず優先したいのは、作ったものを動く状態まで持っていくことです。
一つの不具合に対して、同じ方法で何時間も使うより、別の方法で一度動くものを完成させる。
必要なら、その後に原因を調べる。
この順番でもいいと思っています。
今回も結果論ではありますが、MP3方式へ切り替えたことで、実装完了までのスピードは早くなったと感じています。
AIを使うなら「別の方法を考えさせる」ことも使い方の一つ
AIを使った開発というと、コードを書いてもらう、エラーを直してもらう、という使い方を想像しやすいと思います。
でも今回感じたのは、AIに別の選択肢を考えてもらうことも重要な使い方だということです。
同じ不具合で詰まっているなら、「このエラーを直して」だけではなく、「この機能を実現する別の方法をいくつか出して」と聞いてみる。
その上で、人間側が「今回はどれを使うか」を判断する。
AIにすべて任せるのではなく、AIに選択肢を増やしてもらい、人間が目的に合う方法を選ぶという形の方が、うまくいく場面も多そうです。
まとめ
今回の経験では、コード上のテストはPASSしていたものの、iPhone Safari実機では音声が再生されませんでした。
そこで、Web Speech APIの原因追及を続けるのではなく、MP3ファイルを使う方式へ変更。
結果として、iPhoneでも問題なく音声を再生できました。
今回一番学んだのは、一つの方法に長時間ハマったら、AIに別手段を出してもらうという選択肢を持っておくことです。
最初はできるだけAIだけで完結する方法を試す。
それでダメなら、別のツールやファイル、別方式を比較する。
そして何より、まずは動くものを出すことを優先する。
これからもAIを使いながら、こうした「どの方法を選ぶか」という判断も含めて改善していきたいと思います。
AIを使った制作環境で試行錯誤が増えた別の実例として、Netlify無料枠のクレジットを使い切った原因と対策も紹介しています。
今回のアプリはこちら
今回、音声まわりの不具合を確認して、MP3方式へ切り替えたのがこのアプリです。
くだものポン！
くだものポン！を試してみる
実際にiPhoneでも確認しながら、音声や操作感を調整しました。
ほかの幼児向けWebアプリはこちらです。
幼児向けWebアプリ一覧
ほかの幼児向けアプリを見る
コメント