はじめに
QAエンジニア8年目です。コードは書けません。
それでも2025年秋から個人開発を始め、AIを使ってJSTQB ALTMの対策アプリをリリースしました。
リリース後に気づいたこと。AIはコードを書くだけじゃなく、QAもできる。
この記事では、AIにコードレビューを依頼して「自分では気づけなかったバグ」を発見した実体験と、QAエンジニアとしてAI開発で効いた視点を紹介します。
前提
- アプリ：JSTQB ALTM対策アプリ（iOS / Flutter製）
- 開発：Geminiを活用して開発・リリース済み
- 状況：DL数66・課金率7.4%・レビュー0のフェーズ
プロンプト① コードレビューを依頼する
何をしようとしたか
リリース後も不具合が気になっていた。でも自分ではコードを読み切れない。AIにレビューを頼んでみた。
投げたプロンプト
今のJSTQBアプリのコードをあなたにレビューしてもらいたい、可能ですか？
このあとDartの全ソースコードを貼り付けた。
結果
重要度別に問題を指摘してもらった。特に衝撃だったのはこの2つ。
🔴 購入の復元ボタンが、実際には復元せずメッセージを出すだけのバグ
課金ユーザーがアプリを再インストールしたとき、復元できない状態だった。課金機能のバグをリリース後まで気づかなかった。
🔴 Androidの広告IDがテスト用のままで収益が出ない状態
広告を実装したつもりが、テスト広告IDのまま本番リリースしていた。つまり広告収益がゼロになっていた。
どちらも「指摘されなければ気づかないまま」だったバグです。
QAエンジニアとして8年バグを見てきたのに、自分のアプリのバグを見逃していた。AIに指摘されました。
プロンプト② 分析指標を整理してもらう
何をしようとしたか
DL数と課金数しか見ていなかった。他に見るべき指標があるか知りたかった。
投げたプロンプト
アプリについて分析をしたい。
3/1から5/23までで、DL数66、課金したユーザー5。
これ以外に分析するべき項目はあるか？
結果
App Store Connectのスクリーンショットを共有したところ、具体的な分析が返ってきた。
- ページ閲覧→DLの転換率28%は優秀（平均は10〜30%）
- 課金転換率7.4%は教育アプリ平均を超えている
- インプレッション数が最大のボトルネック
つまり「見つけてもらえれば刺さるアプリ」だとわかった。課題は品質ではなく認知だった。
この分析をもとにQiita記事を書いたところ、2日後にDL数が過去最高を記録した。
QA視点：AIと開発して効いた「品質の勘所」
コードが書けない私が、それでもアプリの品質を担保できたのは、QAとしての思考が随所で活きたからだと思います。具体的に3つ紹介します。
1.「動いた」で終わらせない
AIが生成したコードが通っただけでは満足せず、「期待通りに動くか」まで確認しました。例えばレビュー依頼機能は、シミュレーターでは表示されず実機でしか確認できない仕様を事前に押さえられました。「実装＝完了ではない」というQAの基本姿勢です。
2. 修正の影響範囲（リグレッション）を意識する
テキストデータを更新したとき、すぐに「音声データや問題集にも影響するのでは？」と考えました。これはリグレッションテストの発想です。結果、用語の不統一やデータのズレを発見できました。
3. エラーは「そのまま全文」をAIに渡す
ビルドエラーやlint警告は、要約せずログをそのまま貼り付けるのが一番早く解決しました。QAが不具合報告で「再現手順とログを正確に残す」のと同じです。
まとめ
AIはコードを書くだけじゃない。AIにQAをさせることもできる。
そしてコードが書けないからこそ、AIとの対話に集中できました。「何を確認したいか」を言語化する力、修正の影響範囲を読む力——QAエンジニアとして鍛えてきたスキルが、そのまま個人開発で活きました。
さらに詳しく：全8フェーズのプロンプトをnoteで公開予定
この記事で紹介したのは一部です。noteでは、
- 残りの開発フロー（レビュー機能の実装・デバッグ・リリース手順）
- QA視点で振り返る品質の勘所5つ
- 実際に使った全プロンプト一覧
を全公開予定しています。「コードが書けないのにどうやって品質を担保したのか」に興味がある方はぜひ。
アプリはこちら
App Storeで「JSTQB ALTM」で検索してください。ALTM受験を考えている方はぜひ。
X（@QAmah_desu）でも個人開発の日常を発信しています。