JUSTWIT WORKS

はじめに

ここ数ヶ月、ポモドーロタイマーや幽霊会員検出などの複数のモバイルアプリを、生成AI（主に Claude Code）を開発パートナーにして企画からストア公開まで持っていきました。結論から言うと、生成AIに「アプリを作って」と丸投げしても完成しません。効いたのは、工程ごとに生成AIの役割を絞り、人間が判断すべき点を先に決めておく運用でした。

本記事では、実際に回したワークフローを工程順に解説します。

全体像

工程	生成AIの役割	人間の役割
企画	競合調査の壁打ち・機能の取捨選択の相談相手	コンセプト決定・「作らないもの」の決定
設計	画面遷移・状態設計のたたき台生成	データの持ち方と課金/権限方針の決定
実装	Widget・ロジックのコード生成、リファクタリング	レビュー・アーキテクチャの一貫性維持
テスト	Widgetテスト・ゴールデンテストの量産	テスト観点の列挙・境界値の指定
リリース	ストア文言・審査ドキュメントのドラフト	実装と記述の整合確認・最終責任

企画: 「作らない機能」を決めるための壁打ち

個人開発・小規模開発では、機能を足すより削る判断のほうが難しいものです。生成AIには「この機能を入れた場合の実装コスト・審査リスク・保守負担」を列挙させ、削る根拠を作らせると意思決定が速くなります。

たとえばタイマーアプリでアカウント機能を検討した際は、次のような整理をさせました。

アカウントを持つ → サーバー・認証・退会処理・プライバシーポリシーの複雑化
持たない → 端末内完結、審査フォームがほぼ「収集なし」で通せる、実装コスト大幅減

「収集する個人情報をゼロにする」という設計判断は、後述するストア審査の工数を劇的に減らします。この判断を企画段階で下せたのは、影響範囲を一覧化させたおかげです。

設計: 状態設計はたたき台を出させて、修正で学ばせる

Flutter の場合、状態管理の設計（Riverpod / Bloc / Provider のどれで、どの粒度で状態を切るか）が後々の保守性を決めます。生成AIには次の形式で依頼します。

- 画面一覧と各画面の状態（ephemeral / app state の区別付き）を表で
- 状態遷移が複雑なもの（タイマーの実行中/一時停止/休憩など）は Mermaid の状態遷移図で
- 採用ライブラリは Riverpod。Provider の粒度案を 2 案、トレードオフ付きで

ポイントは 2案以上＋トレードオフを要求することです。1案だけ出させると、もっともらしい構成をそのまま採用してしまい、後から「なぜこの設計か」を説明できなくなります。

実装: 「1指示1ファイル」を守ると事故が減る

実装フェーズで学んだ運用ルールです。

1回の指示で触らせるのは原則1ファイル（多くて3ファイル）。広範囲を一括変更させると、レビューが追いつかず劣化が混入します
const コンストラクタと StatelessWidget 優先などのプロジェクト規約を、最初にルールファイルへ書いておく。毎回指示しなくても規約準拠のコードが出るようになります
BuildContext を跨ぐ非同期処理は必ず context.mounted チェック。生成AIが書き忘れやすい代表格なので、レビュー観点として固定します
ビルドエラーはエラーメッセージをそのまま貼って修正させる。要約すると誤修正されます

テスト: 観点は人間、量産はAI

テストは生成AIがもっとも輝く工程です。ただし「テストを書いて」ではなく、観点リストを渡して量産させる形にします。

対象: TimerController
観点:
- 25分経過で work → break に遷移する
- 一時停止中に経過時間が進まない
- バックグラウンド復帰時に残り時間が壁時計基準で補正される
- 0秒到達時の通知発火は1回のみ（重複発火しない）
時間は fake_async で制御。実時間 sleep 禁止。

時計・通知・振動などのプラットフォーム依存はモック境界を先に切っておくと、生成されるテストの品質が安定します。

リリース: 審査ドキュメントは「実装からの逆引き」で書かせる

ストア審査で使うプライバシー関連の記述は、想像で書くと実装と食い違って審査リジェクトの原因になります。依存パッケージ一覧と権限一覧を渡し、「このアプリが技術的に収集し得る情報」を列挙させてから文書化する手順が安全でした。詳細は別記事で扱います。

効果と限界

体感の効果は次のとおりです。

実装速度: 単純な Widget 実装で 2〜3 倍。設計済みの機能追加が特に速い
テスト: カバレッジ 80% 到達までの工数が従来の半分以下
ドキュメント: ストア審査関連の作成時間が数日 → 半日

一方で、アーキテクチャの一貫性維持・課金設計・パフォーマンスの最終調整は人間の仕事として残ります。生成AIは「速い実装者」であって「プロダクトオーナー」にはなれない、という前提で工程を設計するのが現実解です。

まとめ

生成AIは工程ごとに役割を絞ると定着する。丸投げは破綻する
企画段階の「作らない判断」に影響範囲の列挙が効く
実装は 1指示1ファイル + 規約のルールファイル化
テストは観点を人間が出し、量産をAIに任せる
審査ドキュメントは実装からの逆引きで書かせる

次回以降、テスト量産と審査ドキュメントの工程をそれぞれ深掘りします。

Flutterアプリ開発に生成AIを組み込む実践ワークフロー