個人開発のアプリテストはAIに任せられる？メトロノームでの検証結果

個人でアプリを開発していると、テストに十分な時間を確保するのは簡単ではありません。実装、動作確認、結果の記録、不具合の調査を、一人で進める必要があるからです。

メトロノームアプリの開発でAIを活用した結果、私は個人開発なら、AIをテストの主担当にできると評価しています。

人が見逃した不具合を発見できただけでなく、リズムの正確さを計算と録音解析で確かめるところまで進められました。ただし、仕様書や結果の最終確認、公開の判断は人が行っています。

AIに任せた範囲と、人が確認した範囲

今回の開発では、次の段階でテストを実施しました。

この記事でいう「AIを活用したテスト」には、AIによる端末操作のほか、自動テストや解析処理を使った検証も含みます。すべてをAIの画面操作や目視判定だけで確認したわけではありません。

テスト観点の洗い出し、Excel形式の仕様書作成、端末操作、合否判定、スクリーンショット取得、不具合の再現確認は、ほぼAIに任せました。

基本的な流れは次のとおりです。

1. AIがテスト観点を洗い出し、Excel形式のテスト仕様書を作成する
2. AIレビュー後、人が仕様書の最終版を確認する
3. AIが検証端末でテストを実行し、結果とスクリーンショットを記録する
4. テスト結果とエビデンスを照合し、AIレビュー後、人が最終確認する

エビデンスには、テスト実行時に検証端末で取得したスクリーンショットを使用します。生成AIによる画像の生成・加工は行いません。

描画については、AIの補助を受けながら人が確認しました。AIが実行を担当し、人が仕様・結果・見え方の要所を確認する分担です。

人が見逃した不具合を発見

AIが発見した不具合の一つに、特定の操作をすると、破棄したはずの画面へ遷移できてしまう問題がありました。

具体的な操作や画面構成は伏せますが、本来は到達できない画面へ戻れてしまう不整合です。確認した範囲ではユーザーへの実害はありませんでしたが、画面の状態管理に問題があり、修正が必要だと判断しました。

この問題は、人が行ったテストでは見逃していました。

AIは再現手順まで特定しました。その内容をもとに修正し、AIによる再テストのあと、人が最終確認しています。

過去の検証では、10〜12拍のボタン表示が改行される問題や、通知が入力・確定操作を覆うUIの問題も発見し、修正しました。

自分で実装した機能は、想定した操作を中心に確認しがちです。今回の結果から、AIは作業を代行するだけでなく、自分の確認から漏れた問題を拾う役割も担えると感じました。

リズムの正確さを、計算と録音で検証

メトロノームの核となるのは、設定したテンポで正確にリズムを刻めることです。そこで、計算上の発音位置と、実際に出た音の間隔を、それぞれ確認しました。

内部時計の計算を確認

音を生成する内部時計について、期待する発音位置を実装とは別の計算方法で求め、結果を比較しました。同じ計算ミスを期待値にも引き継がないためです。

過去の内部時計テストでは、次の条件を検証しています。

この範囲で、期待する発音位置との誤差が1サンプル以内であり、予定された発音位置に重複がないことを確認しました。

「10分相当」「30分相当」は計算上の検証範囲です。同じ時間だけ実機で音を出し続けて測定した結果ではありません。

スピーカーから出た音を録音して確認

内部計算に加え、96 BPMで約1分間、実際のスピーカー音をマイクで録音して解析しました。

録音の前後を除いた区間から88拍を検出し、次の結果を得ました。

今回の条件では、平均テンポが約96 BPMであることを確認できました。 解析区間では、拍の欠落を示す長い間隔も検出されませんでした。

ただし、95.998 BPMは解析上の推定値であり、その桁数までの測定精度を保証するものではありません。検出は2 ms刻みで、録音・解析系の誤差も含むため、観測されたばらつきすべてがアプリ由来とは言えません。

また、今回の出力音の測定は96 BPMで約1分間です。ほかのテンポでの出力音や、長時間再生による累積ずれは未検証です。

耳で聴いて「問題なさそう」と判断するだけでなく、数値で確かめられたことは、特に有用でした。AIの支援で測定や解析まで進められたことが、確認の深さにつながっています。

本番ビルドで確認したこと

今回の本番ビルドでは、自動テスト109件が合格しました。これとは別に、端末上で次の動作を確認しています。

• テンポ変更
• 画面消灯中の再生動作
• 通知からの停止
• 再起動後の設定保持

消灯中も音声トラックが動作し、取得時点でそのトラックのバッファ不足が0であることも確認しました。この取得結果は、再生期間全体に音切れがなかったことまで保証するものではありません。

テスト件数だけで品質は判断できませんが、自動テスト、端末操作、出力音の解析を組み合わせることで、異なる角度から確認できました。

任せるうえで残る課題

実行環境の準備と維持が必要

複数のエミュレーターを同時に動かす場合、PCのCPUやメモリなどが制約になります。実機では接続方法や操作ツールの対応状況、クラウドの端末環境では費用も検討対象です。

また、最初の環境構築に加え、画面や仕様の変更に合わせてテストを更新する手間もあります。

期待結果と描画は、人も確認する

期待結果そのものが間違っていれば、多くのテストを実行しても正しく評価できません。開発とテストを同じAIに任せる場合、同じ仕様解釈を引き継ぐ可能性にも注意が必要です。

そのため、仕様書と結果の最終確認は人が行っています。実行できなかった項目や判断できなかった項目を、合格に紛れ込ませないことも重要です。

描画の不具合や操作中の違和感には、静止画だけでは判断しにくいものもあります。公開前に実機を触って確かめる工程は残します。

仕様書や画面も、外部に渡す情報になる

AIサービスに渡す仕様書やスクリーンショットから、未公開機能や業務内容が伝わる場合があります。受託案件や利用者のデータを扱う場合は、特に注意が必要です。

「学習に使われるか」「どれくらい保存されるか」「誰がアクセスできるか」は別々に確認し、利用する契約や設定が案件の条件に合うかを判断します。ダミーデータやテスト用アカウントの使用も、導入時に決めておきたい点です。

個人開発では、AIを主担当にできる

「個人事業主レベルなら、アプリのテストはAIだけでOKか？」

今回の経験を踏まえた私の答えは、テスト作業の大部分は任せられる。ただし、最終確認と公開判断は人が持つ、です。

少なくとも、私が一人で行っていた動作確認を上回る成果は出ました。見逃していた不具合が見つかり、内部計算から実際の出力音まで検証できたためです。

これは、一般的なエンジニアやQAエンジニアとの優劣を示すものではありません。私自身のテストの甘さや、一人で開発と確認を兼ねる限界を、AIで補えたという経験です。

個人事業では、限られた時間の中で複数の役割を担う必要があります。AIにも準備や確認は必要ですが、繰り返しの実行、記録、不具合調査を任せることで、自分は重要な判断に時間を使えます。

一人の作業量を拡張し、これまで届かなかった確認まで進められること。 メトロノーム開発で感じた、AIによるテストの一番の価値です。