AIが書いたコードをAIが検証する！自律的なモバイルアプリ開発の実現
高品質な生成AIの登場によって、開発をAIに全て任せる開発手法「Vibe Coding」が登場しました。これは「 人間がコードを一切書かずに、AIに要件を伝えるだけでアプリを開発する 」というものです。
しかしこの「Vibe Coding」には大きな課題があると考えています。それはAIが生成したコードを人間がレビューしないため、 変更が予期せぬ不具合(デグレ)を起こす可能性が高い ことです。
この問題を解決するために「 AIが書いたコードをAIが動かして確認する 」という方法を試してみました。Vibe Codingで開発した読書記録アプリ「Tsundoku」の開発を通じて、紹介してみます。
Tsundoku - 読書記録アプリ
今回Vibe Codingで開発したのはシンプルな読書記録アプリ「Tsundoku」です。iOSで動作するアプリです。
Tsundokuは以下の機能をサポートしています。
Tsundoku機能一覧
📚 書籍管理機能
- 書籍の追加 - タイトル、著者、カテゴリ、購入日、カバー画像URL、ステータスを設定して登録
- 書籍の一覧表示 - 登録した書籍をカード形式で表示
- ステータス管理 - 未読、読書中、読了、一時停止の4つのステータスで管理
- 検索機能 - タイトル、著者、カテゴリで書籍を検索
- フィルタリング - ステータス別に書籍を絞り込み表示
- ピン留め機能 - 重要な書籍をピン留めして優先表示
📖 読書進捗管理
- 進捗率の記録 - 0〜100%のスライダーで読書進捗を記録
- 進捗更新 - 書籍詳細画面から進捗とメモを更新
- 自動ステータス更新 - 進捗100%で自動的に「読了」に変更
- 進捗リング表示 - 視覚的な円形プログレスインジケーター
- 読書ログ履歴 - 各書籍の進捗更新履歴を時系列で表示
🏠 ホーム画面
- 読書サマリー - 未読・読書中・読了の冊数を集計表示
- ピン留め書籍カルーセル - 「今週読む本」として横スクロール表示
- 最近の更新 - 直近10件の進捗更新をタイムライン表示
📊 読了ログ機能
- 月次サマリー - 月ごとの読了冊数、平均進捗、更新冊数、更新回数を集計
- 月別ナビゲーション - 前月・次月への移動
- タイムライン表示 - 全ての進捗更新を月別グループで時系列表示
- 書籍リンク - ログから該当書籍の詳細画面へ直接遷移
Vibe Codingで利用したツール
今回Vibe Codingで主に利用したツールはCodex CLIです。基本的に全てのコードをCodex CLIで生成し、XcodeでビルドしてできたiOSアプリの検証は自作ツールであるiscをMCPとしてCodex CLIから利用しました。
こうすることで結果的に、 Codex CLIで生成したコードを、iscを使ってCodex CLIが自律的にiOS Simulatorで動作確認できる ようなります。isc自体については以下の記事をご参照ください。
ちなみに今回Codex CLIのカスタムコマンドも使ってみました。差分ごとに影響範囲を特定し動作確認項目を作ってもらい、動作確認をしてもらっています。~/.codex/prompts/ios_ui_test.md を作成し、以下記述しました。
現在の差分を確認し、影響範囲において動作確認項目を作成してください。
作成した動作確認項目を isc を利用して iPhone 16 Pro(iOS 18.2) を起動し確認してください。
WDA pathには '/your/path/WebDriverAgent' を利用してください。
画面を操作する際には必ずiscのelements sourceを利用して、画面要素を確認して、操作にはできる限りelements clickを利用してください。
動作確認実施時は必ず画面を録画してください。
フェーズ1: プロジェクト基盤構築
ここからは実際にVibe Codingで行ったフェーズごとに、実際にどんな検証をしたのかを録画した動画を交えながら紹介していきます。
まずはプロジェクト基盤構築です。このフェーズではXcodeプロジェクトの作成を行いました。
実際にはこのフェーズのみCodex CLIを利用せずに、Xcodeを立ち上げてからのプロジェクトを作成しただけです。なので検証の録画などもありません。
フェーズ2: デザインシステムとナビゲーション骨格
このフェーズからCodex CLIを利用してVibe Codingを始めました。
内容としては以下です。
-
実施内容: カラーパレット・タイポグラフィなど共通スタイルを定義。タブバー（ホーム/蔵書/読了ログ/設定）と各画面のプレースホルダーを作成し、ホーム・蔵書タブに
＋ボタンを配置。 - 完了条件: アプリ起動後に全タブへ遷移でき、各タブでプレースホルダー UI が表示される。
Codex CLIで実装を行い、xcodebuildが完了した段階でカスタムコマンドである /ios_ui_test を実行した結果が以下の検証動画です。
各タブが問題なく動作することや、本の追加を行うプラスボタンが機能するかなどを問題なく検証できています。いい感じですね。
フェーズ3: 書籍登録フローと蔵書一覧
ここでは以下の内容を実施しました。
-
実施内容: 書籍登録モーダルを実装し、タイトル・著者・カテゴリ・購入日・ステータス・カバー画像 URL/選択を入力して Core Data に保存。
NSFetchedResultsControllerを用いた蔵書一覧（検索バー、ステータスチップフィルタ込み）を構築。 -
完了条件:
＋ボタンから書籍を登録すると蔵書タブに新しいカードが表示され、ステータスフィルタを切り替えても表示が更新される。
再度実装を行い、xcodebuildが完了した段階で /ios_ui_test を実行した結果が以下の検証動画です。
本の追加が問題なく行えること、フィルターが機能していることなどを検証できています。一部検索が検証できていない気もしますが、まぁ検索に間違った文言を入れてちゃんと表示されないことは検証できたのでいいとしましょう、
フェーズ4: 書籍詳細画面と進捗更新
ここでは以下の内容を実施しました。
-
実施内容: 書籍カードから遷移する詳細画面を実装し、カバー画像・メタ情報・ステータスピッカー・進捗リングを表示。進捗更新シートでスライダー入力、メモ、ステータス変更を行い
ReadingLogに履歴を保存。 - 完了条件: 蔵書またはホームから詳細画面を開き進捗を更新すると、進捗率とステータスが即時反映され、履歴リストにも新しいログが追加される。
実装とxcodebuild後、/ios_ui_test を実行した結果が以下の検証動画です。
ここで問題が発生しました。本の詳細画面に遷移しようとすると、アプリがクラッシュします。クラッシュしたことをCodex CLIも認識し、提案として実装の再確認を促してきました。
そこで実際のエラーログをCodex CLIに渡した上で再度修正を行ってもらい、再検証しました。
今回は本の詳細画面に遷移することができました！が、進捗を更新して保存しようとするとまたアプリがクラッシュしてしまいます。ちなみにこの段階で、AIがコーディングしているのをただ見守っている自分は、この 進捗を更新する画面の存在に気づいていませんでした 。なので恐らく手動で動作確認をしていた場合は、この不具合に気づいていない可能性が高いです 。
今回も先ほど同様、エラーログと一緒に再度修正を行ってもらい、再検証しました。
今度こそ本の詳細画面への遷移と進捗の更新の保存ができるようになりました！
フェーズ5: ホームダッシュボード
ここでは以下の内容を実施しました。
-
実施内容: 未読/読書中/読了冊数サマリーカード、「今週読む本」カルーセル（
pinnedAt付き書籍）、最近の更新タイムライン（最新ReadingLog）を実装。ピン留め操作を蔵書一覧の長押しアクションとして実装。 - 完了条件: 書籍をピン留めするとホームのカルーセルに表示され、進捗更新後にサマリーカードと最近の更新が最新状態になる。
実装とxcodebuild後、/ios_ui_test を実行した結果が以下の検証動画です。
ホーム画面にちゃんとサマリーが表示されていて良さそうですね。こういった画面遷移を伴わない変更でも、AIの場合画面内の要素を取得してしっかりと要素が表示されているかをみてくれるため、確実な確認が行えます。
ちなみにピン留めする方法がロングタップが必要な操作方法だったため、今回iscではロングタップがうまく動かないため検証できませんでした。この点はツール側の改善が必要ですね。
フェーズ6: 読了ログタブ
ここでは以下の内容を実施しました。
-
実施内容: 月次サマリー（読了冊数・進捗平均など）と、
ReadingLogをloggedAt降順で表示するタイムラインリストを実装。リストから書籍詳細への遷移を追加。 - 完了条件: 書籍を読了ステータスにすると読了ログタブに新しい項目が追加され、該当月のサマリーが更新される。
実装とxcodebuild後、/ios_ui_test を実行した結果が以下の検証動画です。
一見するとしっかり動いていそうですが、ここで不具合が発見されました。 ホーム画面のサマリーの表示が間違っていることと、全ての本が「不明な書籍」というタイトルでログに表示されてしまう という不具合です。
本来であれば読書中が1で、書籍のタイトルはちゃんと表示されるのが正しいです。
これについても普通に動いていたので見逃してしまいそうですが、AIの場合は画面要素を確認して見逃さずにしっかりとキャッチしてくれました。ちなみに本当であればフェーズ5ですでにバグっていたので、そこでキャッチして欲しかったですね。
修正点を伝えて再修正後、/ios_ui_test を実行した結果が以下の検証動画です。
正しく表示がされるようになりました。良さそうです。
ラストフェーズ: 最終確認
最後に全体を通した確認を行ってみました。
確認としては差分ではなく全体のコードを見たうえで、動作確認項目を作成してもらいました。
プロンプトとしては以下です。
アプリの内容と現在のUI実装とを確認し、できる限りユーザーストーリーにそう形での動作確認項目をまとめてください。
まとめた動作確認項目を isc を利用して iPhone 16 Pro(iOS 18.2) を
起動し確認してください。
WDA pathには '/your/path/WebDriverAgent' を利用してください。
画面を操作する際には必ずiscのelements sourceを利用して、画面要素を確認して、操作
にはできる限りelements clickを利用してください。
動作確認実施時は必ず画面を録画してください。
検証動画が以下です。
なんということでしょう。最後の最後に再度クラッシュが再現してしまいました 。発生箇所としては進捗を更新して保存する箇所です。
恐らくフェーズ6の最後の変更でデグレってしまったのだと思います。本来であればフェーズ6の検証で発見されて欲しかったですが、最後の最後になってしまいました。変にリアル感ありますね。
エラー内容を伝えて修正後、最後は手動で動くことを確認してTsundokuは完成です。お疲れ様でした。
まとめ: AIによる動作確認も万能ではないが有用である
ここまでの検証から、AIによる動作確認も万能ではないですが、一定以上有用ではあることがわかりました。
特にVibe Codingにおいて見落としそうになる「 そんな画面実装されてたの！？ 」という場面において、AIは実際のコードから動作確認項目を立案するため、余すことなく確認をしてくれます。人間の場合はこれは確実に見落としてバグが放置される原因になると思われます。
ただ手放しに賞賛できる現状ではないことは確かです。例えば今回検証動画を公開していますが、これは編集などをして最低限見れる状態にしています。現実では かなりの時間AIによる動作確認が行われています 。その時間に人間が見た方が早いのでは？という当たり前の感想が出てくるくらい遅いです。
この点に関しては利用するツールを変えたり、動作確認項目立案は高品質な生成AIモデルで、実行自体は応答速度が高速な生成AIモデルを利用する、などの改善が考えられます。そもそもモデル自体の進化が激しいので、 来年にはもう問題にならないくらい高速化 してる可能性もあります。
現実的には、継続的に開発運用するアプリの場合は素直にテストコード自体を生成AIに書いてもらい、確実な方法でテストをした方が現状良さそうです。ただVibe Codingの場合はあくまでも一時的な確認になりがちなため、今回行った動作確認でも十分な可能性があります。また今回の行ったような、頻出するバグの箇所のみテストを書いて担保する 、などの方法もあるかなと思います。
みなさんも是非興味があればVibe CodingでAIによる動作確認を試してみてください。
さいごに
この記事と同じ内容を以下のイベントで発表するので良ければオンラインで視聴してください。
Discussion