AIとペアプロ!Cursor AgentだけでFlutter音楽アプリ「MusicStorage」をゼロから作った話
AIとペアプロ!Cursor AgentだけでFlutter音楽アプリ「MusicStorage」をゼロから作った話
はじめに
こんにちは!
「AIがコードを書く」という話は、もはやSFの世界ではありません。
今回、私はAIコーディングツール Cursor の Agent モード (Claude-4.5-Sonnet) を使って、設計、ドキュメント作成、コーディングの全てをAIに任せるという実験的なプロジェクトに挑戦しました。
その成果物が、今回ご紹介するFlutter製のローカル音楽管理アプリ**「MusicStorage」**です。
この記事では、単なるアプリ紹介ではなく、AIを相棒にした開発がどのようなものだったか、そのリアルな過程と感想を共有します。AIコーディングに興味がある方、Cursorを使いこなしたい方の参考になれば幸いです。
なぜ、AIに全てを任せてみたのか?
このプロジェクトの目的は、AIの現在の実力を測ることにありました。
- 要件定義から技術設計まで、一貫したドキュメントを生成できるか?
- 設計書に基づいた**高品質なコード(骨格)**を自動で生成できるか?
- モダンな開発手法(クリーンアーキテクチャ、Riverpodなど)を自律的に提案・実装できるか?
人間はあくまで「プロジェクトマネージャー」や「レビューワー」の役割に徹し、AIにどこまで自律的な開発を任せられるのかを試すのが、このプロジェクトの狙いです。
開発プロセス:AIとの対話ログ
Step 1: 「音楽アプリを作りたい」とだけ伝えた
最初の指示は、非常にシンプルでした。
Human: Flutterでローカル音楽ファイルを管理・再生するアプリを作りたい。要件を定義してください。
これだけで、Cursor Agentは詳細な**「要件定義書.md」**を生成しました。
音楽ライブラリ管理、検索、プレイリスト、歌詞表示といった主要機能から、パフォーマンス要件やセキュリティ要件といった非機能要件まで、網羅的かつ具体的な内容です。
Step 2: 設計書とプロジェクト構造の生成
次に、生成された要件定義書をもとに、より具体的な設計を指示しました。
Human: この要件定義書に基づいて、技術設計書とプロジェクトのファイル構造を作成してください。
Agentは、メンテナンス性と拡張性を見据え、自らクリーンアーキテクチャの採用を提案。Presentation, Domain, Dataの3層構造を定義し、それぞれの役割や使用技術をまとめた**「技術設計書.md」**を書き上げました。
同時に、その設計思想に基づいたディレクトリ構造と、空のDartファイルを自動で生成。まさに「喋るだけでプロジェクトの土台が出来上がっていく」体験でした。
music_app/
├── lib/
│ ├── main.dart
│ ├── core/ # コア機能(定数、ユーティリティ、テーマ等)
│ ├── data/ # データレイヤー
│ │ ├── models/ # データモデル
│ │ ├── repositories/ # リポジトリ実装
│ │ └── datasources/ # データソース
│ ├── domain/ # ドメインレイヤー
│ │ ├── entities/ # エンティティ
│ │ ├── repositories/ # リポジトリインターフェース
│ │ └── usecases/ # ユースケース
│ └── presentation/ # プレゼンテーションレイヤー
│ ├── pages/ # 画面
│ ├── widgets/ # 共通ウィジェット
│ └── providers/ # 状態管理プロバイダー
...
Step 3: 基盤コードの自動実装
設計が固まったところで、いよいよコーディングです。
Human: 技術設計書に従って、各レイヤーの基盤となるコードを実装してください。状態管理はRiverpodでお願いします。
この指示で、Agentは驚くべき量の定型コードを生成し始めました。
-
sqfliteを使ったデータベースのテーブル定義と接続処理 -
Song,PlaylistなどのEntityとModelクラス -
Riverpodの各種Provider(リポジトリのDI、状態管理など) - ライト/ダークモード対応のテーマ設定
-
pubspec.yamlへの必要パッケージの追加
人間がやると数時間はかかるであろう退屈な初期実装が、わずか数分の対話で完了しました。
AIが作り上げた「MusicStorage」の現在
こうして、AIとのペアプログラミング(?)によって生み出された「MusicStorage」の基盤がこちらです。
- アーキテクチャ: クリーンアーキテクチャ
- 状態管理: Riverpod
- データベース: SQLite (sqflite)
- 音楽ファイルスキャン: on_audio_query
- 音楽再生: just_audio, audio_service
AIは、Flutterコミュニティで広く受け入れられているモダンな技術スタックを自ら選択・提案し、実装してくれました。現時点ではアプリの「骨格」が完成した段階ですが、すでに高い品質と拡張性を備えています。
AI主導開発のリアルな感想
実際にAIに開発の大部分を任せてみて、感じたメリットと課題をまとめます。
良かった点 ✨
- 圧倒的なスピード: 特に、設計書に基づいたボイラープレートコードの生成速度は驚異的です。プロジェクトの立ち上げが数倍速くなりました。
- ベストプラクティスの導入: 開発者が迷いがちなアーキテクチャ選定やライブラリの組み合わせを、AIがベストプラクティスに基づいて提案してくれます。
- ドキュメント駆動開発の徹底: 「まずドキュメントを書く」という理想的なフローを、AIが半強制的に実現してくれます。コードとドキュメントの乖離も起きにくいです。
- 思考の壁打ち相手になる: 「この機能はどう実装すべきか?」といった問いに、複数の選択肢とそれぞれのメリット・デメリットを提示してくれ、思考が整理されます。
課題と今後の付き合い方 ⚠️
- 指示の精度が全て: AIは指示されたことしかできません。曖昧な指示では、期待外れのコードが出力されます。「何をどうしてほしいのか」を明確に言語化する能力が、人間に求められます。
- レビュー能力は必須: AIが生成したコードが100%正しいとは限りません。最終的な品質を担保するのは人間の役割であり、コードを読む力と設計を評価する力が不可欠です。
- 複雑なロジックの限界: まだ、ドメイン固有の複雑なビジネスロジックや、細かなUIの調整を一発で完璧に実装するのは難しいようです。AIに大枠を作ってもらい、人間が細部を仕上げるのが現実的です。
まとめ:AIは"副操縦士"から"自動操縦システム"へ
今回のプロジェクトを通じて、AIはもはや単なる「コード補完ツール」や「検索エンジン」ではないことを痛感しました。
明確な指示さえ与えれば、設計から実装まで自律的にこなす**「開発パートナー」**になり得るポテンシャルを秘めています。
「MusicStorage」の開発はまだ始まったばかりです。これから、AIとの対話を続けながら、音楽再生機能やUIの実装を進めていきます。
この前代未聞(?)のAI駆動開発の記録、今後もzennで発信していく予定です。
AIコーディングの未来に興味がある方は、ぜひ今後の動向にご注目ください!
Discussion