はじめに：コードを1行も書かない開発
「AIにコードを書かせる」という話は今や珍しくない。しかし**「コードを1行も自分で書かず、1行も読まずにアプリをリリースする」**という体験はまだ少ないのではないだろうか。
本記事では、私が2025年12月7日〜11日の5日間で実施した「純AIコーディング」プロジェクトの生産性データを公開し、AI駆動開発の現実的な生産力を検証する。
プロジェクト概要
| 項目 | 値 |
|---|---|
| アプリ | LayerPlayer（フォルダ再生特化の音楽プレイヤー） |
| フレームワーク | Flutter 3.x / Dart 3.x |
| 開発期間 | 5日間（12/7〜12/11） |
| 初版リリース | 初日（12/7） |
| AIツール | GitHub Copilot + Gemini 3 Pro |
| 開発者の役割 | 要件定義・動作確認のみ |
📊 生産性データの全貌
最終成果物
総コード量: 15,331 行（Dartのみ）
総ファイル数: 55 ファイル
総コミット数: 43 コミット
ビルド成功数: 20+ 回
日別の進捗
| 日付 | コミット数 | 推定挿入行 | 主な実装内容 |
|---|---|---|---|
| 12/7（Day1） | 6 | ~7,700 | プロジェクト初期化、基本UI、再生エンジン |
| 12/8（Day2） | 12 | ~13,900 | 音声操作AI、クラウド連携（GDrive/OneDrive） |
| 12/9（Day3） | 11 | ~3,100 | 歌詞生成AI、Dropbox対応、イコライザー |
| 12/10（Day4） | 14 | ~5,000 | ホームウィジェット、広告、課金、細かな修正 |
| 12/11（Day5） | 3+ | ~3,600 | プレイリスト機能、最終調整、リリース準備 |
注: 挿入行には設定ファイル・生成ファイルを含む。Dartコードのみでは約15,000行。
機能別のコード分布
providers/（状態管理）: 3,923 行（25.6%） ← 最大の複雑性
screens/（画面UI）: 3,812 行（24.9%）
widgets/（UI部品）: 2,692 行（17.6%）
l10n/（多言語対応）: 1,966 行（12.8%） ← 自動生成含む
services/（外部連携）: 1,469 行（9.6%）
utils/（ユーティリティ）: 314 行（2.0%）
models/（データ構造）: 188 行（1.2%）
main.dart: 967 行（6.3%）
ファイル規模TOP5
| ファイル | 行数 | 機能 |
|---|---|---|
player_provider.dart |
2,201 | 再生状態・シャッフル・リピート管理 |
voice_control_provider.dart |
1,000 | AI音声認識・コマンド解析 |
settings_screen.dart |
943 | 設定画面UI |
player_screen.dart |
818 | メイン再生画面 |
app_localizations.dart |
516 | 多言語リソース |
🔢 生産性指標の計算
基本指標
1日あたりのコード量: 15,331 ÷ 5 = 3,066 行/日
1コミットあたりの規模: 15,331 ÷ 43 = 357 行/コミット
1時間あたり（実質2h/日）: 3,066 ÷ 2 = 1,533 行/時間
注: 本業の合間に作業したため、1日の実作業時間は約2時間程度。
従来開発との比較（私見）
10年前、私はJavaでAndroidアプリを個人開発していた。当時の体感値との比較：
| 指標 | 10年前（手書き） | 今回（純AI） | 倍率 |
|---|---|---|---|
| 1日のコード量 | 200〜400行 | 3,000行 | 7.5〜15倍 |
| 新技術の学習期間 | 2週間〜1ヶ月 | 0日 | ∞ |
| 初回ビルド成功まで | 数時間〜1日 | 30分以内 | 5〜10倍 |
| ドキュメント参照 | 頻繁 | ほぼゼロ | - |
🎯 実装された機能一覧
5日間で実装した機能を列挙する。これが「純AIコーディング」で達成可能な規模感である。
コア機能
- ✅ フォルダベースの楽曲ブラウジング
- ✅ バックグラウンド再生（audio_service連携）
- ✅ シャッフル・リピート（1曲/全曲/フォルダ）
- ✅ プログレスバー・シークバー
- ✅ プレイリスト作成・管理
AI機能
- ✅ 音声コマンド操作（「次の曲」「30秒戻して」等）
- ✅ 歌詞自動生成（Gemini API連携）
- ✅ インテリジェントな曲検索
クラウド連携
- ✅ Google Drive認証・ファイルブラウズ・ストリーミング
- ✅ OneDrive認証・ファイルブラウズ・ストリーミング
- ✅ Dropbox認証・ファイルブラウズ・ストリーミング
UI/UX
- ✅ イコライザー（ビジュアライザー付き）
- ✅ ホームウィジェット（Android）
- ✅ 日本語/英語対応
- ✅ 背景画像カスタマイズ
マネタイズ
- ✅ Google AdMob広告
- ✅ アプリ内課金（広告削除）
💡 「純AIコーディング」の方法論
私のワークフロー
1. 機能を日本語で説明する
└→ 「フォルダ内の楽曲を再生順序を保ってリスト表示して」
2. AIが生成したコードをそのままコミット
└→ コードは読まない
3. ビルドして動作確認
└→ 動かなければ症状をAIに伝える
4. 修正案をAIに生成させる
└→ 再びコードは読まない
5. 繰り返し
効果的なプロンプトの例
❌ NG例：「シャッフル機能を追加して」
→ 曖昧すぎて期待と違う実装になる
✅ OK例：「シャッフルボタンを押すと、現在のフォルダ内の
全楽曲をランダムな順序で再生キューに追加し、
現在再生中の曲はそのまま継続、
シャッフル状態は画面を閉じても保持」
→ 要件が明確なので期待通りの実装になりやすい
なぜコードを読まないか
- 読んでも理解に時間がかかる（新フレームワーク）
- 修正してもAIの文脈が壊れる
- 動作確認のほうが確実
結果的に「コードの品質」より「動作の正しさ」に集中できた。
⚠️ AIの限界：状態管理の複雑性
最大の難所
5日間で最も時間を食ったのは状態管理のバグだった。
// player_provider.dart が2,201行に膨れた理由
- 再生状態（playing/paused/stopped）
- シャッフル状態（on/off + 履歴）
- リピート状態（off/one/all/folder）
- 現在位置（曲・フォルダ・プレイリスト）
- バッファリング状態
- エラー状態
- これらの組み合わせ...
AIは「単一機能の実装」は得意だが、複数の状態が絡み合う場面では矛盾したコードを生成しやすい。
具体例：歌詞同期のバグ
症状：曲を切り替えると、前の曲の歌詞が一瞬表示される
原因：StateNotifierの更新タイミングが曲切り替えより遅い
解決：4回のプロンプト修正で解消（約1時間）
このような「暗黙的な依存関係」をAIが正しく把握するのは難しい。
💰 コスト効率：Gemini 3 Proを選んだ理由
AIモデルの選択
GitHub Copilotでは複数のモデルが選択可能。私がGemini 3 Proを選んだ理由：
| モデル | コスト倍率 | 選択理由 |
|---|---|---|
| Claude | x3.0 | 高品質だがコスト高 |
| GPT-4o | x1.0 | バランス型 |
| Gemini 3 Pro | x1.0 | Google製品との親和性 |
特にこのプロジェクトでは：
- Google Drive API連携
- Gemini API（歌詞生成）
- Firebase（Analytics/AdMob）
- Android + Flutter（いずれもGoogle製）
というGoogle製品が多く、Gemini 3 Proは同じGoogle製品群のAPIドキュメントやベストプラクティスに精通していると推測した。
推定コスト
GitHub Copilot Individual: $10/月
5日間の開発で消費したクレジット: 約$30相当（x3.0モデル使用時と比較して$60節約）
📈 生産性向上の本質
AIが効いたポイント
- ボイラープレート生成: Providerの定型コード、State管理のテンプレート
- API連携コード: OAuth認証フロー、REST API呼び出し
- UI構築: FlutterのWidget組み立て
- 多言語対応: 翻訳テキストの一括生成
AIが効かなかったポイント
- 複雑な状態遷移の設計
- パフォーマンスチューニング
- プラットフォーム固有の問題（Androidのバックグラウンド制限等）
🔍 コード品質の現実：リファクタなし・テストなしの状態
今回のプロジェクトはリファクタリング期間を設けず、テストも意識的に書いていない。純AIコーディングで「とりあえず動く」を目指した結果の品質指標を正直に公開する。
品質指標サマリー
総行数（空行除く）: 14,095 行
ファイル数: 55 ファイル
平均行数/ファイル: 295.3 行
コメント率: 8.6%（1,214行）
TODO/FIXME: 12 箇所
デバッグprint文残骸: 0 箇所
テストファイル数: 1 ファイル（ほぼ未着手）
500行超の「神ファイル」候補
| ファイル | 行数 | 問題点 |
|---|---|---|
player_provider.dart |
2,262 | 再生・シャッフル・リピート・キュー管理が1ファイルに集中 |
voice_control_provider.dart |
1,043 | 音声認識＋コマンド解析＋AI連携が混在 |
settings_screen.dart |
988 | 設定項目が増えるたびに肥大化 |
player_screen.dart |
858 | UI＋ロジックの分離が不十分 |
app_localizations.dart |
603 | 自動生成ファイル（問題なし） |
playlist_list_screen.dart |
509 | 新機能追加で急成長 |
品質評価
| 観点 | 評価 | コメント |
|---|---|---|
| 動作安定性 | ⭐⭐⭐⭐☆ | 致命的バグなく動作 |
| コード可読性 | ⭐⭐⭐☆☆ | AIが生成したままで整理されていない |
| 保守性 | ⭐⭐☆☆☆ | 神ファイルの分割が必要 |
| テストカバレッジ | ⭐☆☆☆☆ | ほぼゼロ |
| 技術的負債 | 中〜高 | 今後のリファクタで解消予定 |
なぜテストを書かなかったか
- 5日間という期限: 機能実装を優先
- 純AIコーディングの検証: 「動作確認のみ」という縛り
- 個人開発の割り切り: まずリリース、品質は後から
注: これは推奨ではない。チーム開発や長期保守が必要なプロジェクトでは、AIにテストも書かせるべき。
技術的負債の内訳（TODO/FIXMEの内容）
- TODO: エラーハンドリングの改善（3箇所）
- TODO: キャッシュ戦略の最適化（2箇所）
- TODO: アクセシビリティ対応（2箇所）
- FIXME: 特定条件での再生位置ズレ（1箇所）
- その他軽微な改善（4箇所）
品質 vs スピードのトレードオフ
純AI開発の現実:
┌─────────────────────────────────────────┐
│ 速度 ████████████████████ 100% │
│ 機能 ██████████████████ 90% │
│ 動作 ████████████████ 80% │
│ 品質 ██████████ 50% │
│ 保守 ████████ 40% │
└─────────────────────────────────────────┘
結論: 純AIコーディングは「動くものを早く作る」には最適だが、「きれいなコードを作る」には向いていない。リリース後のリファクタリングフェーズを別途設けることを推奨する。
生産性の方程式
純AI生産性 = (AIが得意な領域の比率) × (プロンプト精度) × (反復速度)
このプロジェクトでは：
- AIが得意な領域: 70%（UI・API連携が多い）
- プロンプト精度: 向上（具体的な要件記述を心がけた）
- 反復速度: 高速（ビルド→確認→修正のサイクルが5分以内）
🎓 結論：AIコーディングは「使える」のか
数字が示す事実
| 従来比 | 評価 |
|---|---|
| コード生成速度 | 10倍以上 |
| 学習コスト | ほぼゼロ |
| 品質 | 80点レベル（磨き込みは人間が必要） |
| 複雑な問題 | 苦手（状態管理、パフォーマンス） |
向いているプロジェクト
- ✅ 新技術のプロトタイピング
- ✅ 個人開発・MVP開発
- ✅ 定型的なCRUDアプリ
- ✅ 既存パターンの組み合わせ
向いていないプロジェクト
- ❌ 複雑な状態管理が必要なシステム
- ❌ パフォーマンスクリティカルな処理
- ❌ 独自アルゴリズムの実装
- ❌ レガシーコードの保守
おわりに
5日間・15,000行・43コミット。
この数字は、「純AIコーディング」が実用段階に入ったことを示している。コードを1行も書かず、1行も読まなくても、アプリはリリースできる。
ただし、AIは「優秀なジュニアエンジニア」に近い。明確な指示には従うが、複雑な設計判断は苦手。シニアエンジニアの役割は「何を作るか」の判断と「動作の検証」に移りつつある。
作ったアプリ
LayerPlayer - フォルダ再生に特化した音楽プレイヤー
関連記事
追伸: この記事も、生産性・品質の評価データ収集から執筆まで、AIで5分で書きました。概ね実態通りです。