この記事はNTTドコモソリューションズ Advent Calendar 2025の18日目の記事です。
普段はモバイルアプリ開発をしており、Flutterでアプリ開発を実施している片山と申します。今回個人でアプリを開発してリリースまでしたのでその体験談を記事にしようと思います。
はじめに
「自分で作ったアプリをApp Storeに出したい」
そんな思いから、AIアシスタント「Claude」を使ってアプリ開発に挑戦しました。開発期間は約1ヶ月(2025/11中旬~12中旬)、作業時間は約70時間。Flutterの経験はあるものの、App Storeリリースの経験は浅い。
この記事は、最初はうまくいかなかった開発が、Claudeとの対話を工夫することで軌道に乗ったという実体験を共有するものです。
開発したアプリ
アプリ名: 猫とお掃除
開発期間: 約1ヶ月
カテゴリ: 仕事効率化
技術: Flutter + Provider + SQLite
掃除タスクを管理するシンプルなアプリです。猫のマスコットと一緒に、日々の掃除タスクを楽しく管理できます。
なぜこのアプリを作ろうと思ったのか
背景
- 自分のアプリをリリースしたかった
- 日常で使うアプリを作りたかった
- AIを活用して効率的に開発したかった
最初の方針
目標: 掃除タスク管理アプリ
期限: 1-2ヶ月でリリース
技術: Flutter（経験あり）
AI: Claude（Sonnet 3.5）
こうして、アプリの開発がスタートしました。
とりあえず動くものを作ってみた
最初のアプローチ
Claudeに対して、こんな感じで依頼しました：
私: 掃除タスク管理アプリを作りたいです。
Flutterで、タスクの追加・削除・表示ができるアプリを作ってください。
デザインはシンプルで使いやすいものでお願いします。
すると、Claudeは：
- プロジェクト全体の構成
- 40個以上のファイル
- 動くコード
を一気に生成してくれました。
驚きの速さ
Day 1: プロジェクト作成 + 基本UI
Day 2: データベース実装
Day 3: タスクCRUD機能
たった3日で動くアプリができました！
「これならすぐにリリースできるんじゃないか？」と思いましたが、そんなに上手くいくわけはなかったです。
この時点で決めていたのは：
- タスクを追加・削除できる
- カテゴリー別に分類
- シンプルなUI
決めていなかったこと:
- 繰り返し設定の詳細
- 通知の仕様
- データベーススキーマの詳細
- エラーハンドリング
- 画面遷移の流れ
フォルダ構成も「models」「views」「providers」くらいの最低限。
機能も「ざっくり動けばいい」という感じで進めていました。
バグとエラーの嵐
問題が噴出し始めた
動くプロトタイプはできたものの、機能を追加しようとすると...
問題1: 要件が曖昧でエラーが多発
私: 繰り返し設定を追加したい
Claude: RecurrenceTypeを追加します...
→ 実装されたが、既存のコードと整合性が取れずエラー
→ どこに追加すればいいか分からない
→ インポート文が不足
問題2: 部分的なコードで統合に苦労
Claude: 以下のコードを追加してください：
[20行程度のコードスニペット]
私: ...これ、どこに貼り付ければいいの？
既存のコードと衝突してる...
問題3: 段階を飛ばして実装しようとした
私: タスク追加、繰り返し設定、通知、アニメーションを
全部一気に実装したい
→ どこかでエラーが出ても原因特定が困難
→ ロールバックできない
→ 開発が停滞
開発が停滞
プロトタイプは3日でできたのに、その後の機能追加で2週間も悩むことになりました。そこで、Claudeとの対話の仕方を見直すことにしました。
Claudeとの対話を工夫した
工夫1: プロジェクト機能を使って開発全体を一つの文脈で管理
これが想像以上に便利でした。
Tips: プロジェクト機能とは
プロジェクトを作成すると、「プロジェクト知識」として「何をしたいか」を説明できる。
例：「Flutterで掃除タスク管理アプリを開発中。シンプルで使いやすいデザインを目指している。Provider + SQLiteを使用。App Storeリリースが目標。」
この知識がプロジェクト内のすべてのチャットで共有されるため、新しいチャットを作成しても、毎回プロジェクトの背景を説明する必要がない。
これにより、コンテキスト説明の時間が大幅に短縮された。
実践した使い方:
プロジェクト名：「モバイルアプリ開発」
プロジェクト知識：「Flutterで掃除タスク管理アプリを開発中。Provider + SQLiteを使用。App Storeリリースが目標。」
このプロジェクト内で、デザイン相談、データベース設計、機能実装、エラー解決など、複数のチャットを作成して開発を進めた。
効果:
私: 前に話したTaskモデルに通知機能を追加したい
Claude: はい、プロジェクト知識からTaskモデルを使った開発をされていますね。
notificationTimeフィールドを追加します...
新しいチャットでも、プロジェクト知識があるため、すぐに文脈を理解してもらえる。
工夫2: 会話の自動圧縮機能に任せる
問題意識:
開発が進むと会話が長くなり、「新しいチャットを作るべきか？」と悩む。
Tips: 会話の自動圧縮機能
Claudeは会話が長くなると自動で圧縮してくれる。重要な情報は保持されているので、引き続き同じチャットで開発を続けられる。
実践した結果:
- 1ヶ月間、1つのチャットで開発を完結
- 途中で文脈が失われることなく継続
- 新しいチャットを作る手間がゼロ
メリット:
- 過去の決定事項が自然に参照される
- 「これ前にも聞いたな」という無駄がない
- プロジェクト全体の流れが一本につながる
工夫3: 完全なファイルを要求する（基本だが重要）
Before（悪い例）:
私: 繰り返し設定を追加して
After（良い例）:
私: lib/models/task.dart を完全なファイルとして再生成してください。
追加する内容：
- recurrenceType フィールド（daily/weekly/monthly）
- recurrencePattern フィールド（曜日指定など）
- 既存のフィールドはすべて維持
全ファイルを出力してください。
効果: 統合時のエラーが1/10以下に減少
工夫4: エラーログやコードファイルをそのままアップロード
従来の方法:
私: [エラーメッセージをコピペ]
改善版:
私: [エラーログファイル全体をアップロード]
[該当するコードファイルもアップロード]
このエラーを解決してください。
Tips: ファイルアップロードの利点
効果:
- コピペミスがない
- 全体像を把握してもらえる
- 複数ファイルにまたがる問題も一度に解決
実際の例:
error_log.txt（ビルドエラー全文）とtask_provider.dart（問題のあるコード）を同時にアップロードすることで、Claudeがエラーログの50行目とコードの80行目を関連付けて、的確な修正案を提示してくれた。
工夫5: 段階的に進めるフローに変更
Before（悪い例）:
すべての機能を一度に実装 → バグだらけ
After（良い例）:
Phase 1: タスクCRUD（1-2日）
→ 動作確認
Phase 2: カテゴリー機能（2-3日）
→ 動作確認
Phase 3: 繰り返し設定（2-3日）
→ 動作確認
Phase 4: 通知機能（2-3日）
→ 動作確認
効果:
- バグの原因特定が容易
- 問題があってもロールバック可能
- モチベーション維持（動くものが見える）
工夫6: 定期的に「現状確認」を依頼
ある程度実装が進んだら、Claudeに現状を整理してもらう：
私: 現在のアプリの状態を整理してください。
実装済みの機能と、残りのタスクをリストアップしてください。
Claude: 【実装済み】
- タスクCRUD
- カテゴリー管理
- カレンダー表示
- 繰り返し設定
【未実装】
- 通知機能（部分的）
- 完了アニメーション
- App Storeアセット
【技術的負債】
- TaskProviderのエラーハンドリング
- データベースマイグレーション
効果:
- 全体像が見えてモチベーション維持
- 優先順位を付けやすい
- 技術的負債を見逃さない
工夫7: 「なぜ」を聞いて理解する
実際の対話:
私: なぜProviderを使うんですか？Riverpodの方がいいと聞きますが。
Claude: Providerを推奨する理由：
1. 学習コストが低い
2. Flutterの公式パッケージで安定
3. このアプリの規模なら十分な機能
4. ドキュメントが豊富
Riverpodは確かに強力ですが、
このアプリの規模ならProviderで十分です。
効果: 技術選定の理由を理解し、次回から自分で判断できる
これらの工夫の成果
対話を工夫してから：
| 指標 | Before | After |
|---|---|---|
| エラー解決時間 | 10-30分 | 1-5分 |
| 統合エラー | 頻発 | ほぼゼロ |
| 1日の進捗 | 機能0.5個 | 機能2-3個 |
| コンテキスト説明 | 毎回必要 | ほぼ不要 |
| ストレス | 高い | 低い |
開発が劇的に加速しました。
学んだこととまとめ
Claudeを使う上で重要なこと
Claude特有の機能を活かす
-
プロジェクト機能を使う
- 開発全体を一つの文脈で管理
- 過去の会話を自然に参照できる
-
会話の自動圧縮に任せる
- 新しいチャットを作らなくていい
- 1つのチャットで開発完結
-
ファイルアップロード機能
- エラーログやコード全体を一度に共有
- コピペミスを防ぐ
対話の工夫
-
段階的に進める
- 動くものを作ってから拡張
- 各Phaseで必ず動作確認
-
定期的に現状確認
- 実装済み・未実装を整理
- 技術的負債を見逃さない
-
「なぜ」を聞く
- 理解してから実装
- 次回から自分で判断できるように
Claudeを使った開発のメリット・デメリット
メリット:
-
長期開発に強い
- プロジェクト機能で文脈が維持される
- 会話の自動圧縮で1つのチャットで完結
-
圧倒的なスピード
- 通常の1/2-1/3の期間で開発
- エラー解決が早い（StackOverflow不要）
-
学習しながら実装できる
- 新しい技術も習得しやすい
- 「なぜ」を聞くことで理解が深まる
デメリット:
-
機能を知らないと活かせない
- プロジェクト機能を知らないと文脈が途切れる
- 会話圧縮を信頼しないと無駄にチャットを作る
-
すべてを鵜呑みにできない
- 生成されたコードは必ず動作確認が必要
- たまに古いパッケージバージョンを提案
-
過度な依存のリスク
- AIに頼りすぎると自分で考えなくなる
- 「なぜ」を聞かないと学びがない
最後に
この開発で学んだ最大の教訓は：
「AIの力を引き出すには、プロンプトの技術だけでなく、ツールの機能を理解することが同じくらい重要」
最初はうまくいかなくても、プロンプトの工夫とツールの機能理解の両輪で、Claudeは強力なパートナーになります。
この記事が、これからAIを使った開発に挑戦する方の参考になれば幸いです。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。