05. フィードバックを改善タスクにして次のビルドを配る

テスターから貴重なフィードバックや不具合の報告が集まってきました。

ここからが、バイブコーディングが真価を発揮する瞬間です。従来の受託開発や大企業では数週間〜数ヶ月かかる「フィードバック分析 → 設計修正 → コーディング → テスト → 再配布」のサイクルを、AIエージェントと一緒にわずか数時間〜1日で回し切ることができます。

この記事では、集まったフィードバックの優先度トリアージ、AIへの改修プロンプト、バージョン管理、そして次の改善ビルド（v0.2.0）をテスターに届けるまでの実践手順を詳しく解説します。

---

この記事のサブコンテンツ

1. フィードバックの優先度仕分け（P0/P1/P2トリアージ基準）
2. AIエージェントにフィードバックを解析・タスク化させるプロンプト
3. AIと連携した迅速なバグ修正・UI改善の対話サイクル
4. バージョン番号とビルド番号のインクリメント規則
5. 次期ビルド（v0.2.0）の再配布とテスターへの感謝報告
6. フィードバック編の総まとめと次のフェーズへの橋渡し

---

1. フィードバックの優先度仕分け（P0/P1/P2トリアージ基準）

すべてのフィードバックをそのまま鵜呑みにして実装しようとすると、リサーチ編で決めたアプリのコンセプトが崩壊し、再び機能肥大化に陥ります。

届いた声を以下の3段階に厳格に分類します。

優先度	区分	具体例	アクション
P0（最優先）	アプリが落ちる・進行不能バグ	「空文字で登録するとクラッシュする」「ボタンが押せない」「データが消えた」	即座に修正（最優先でパッチビルド）
P1（高）	明らかなUIの不都合・使いにくさ	「文字が切れて読めない」「チェックした感触が薄い」「誤タップしやすい」	次のビルド（v0.2.0）で必ず改修
P2（中・低）	新機能の要望・個人の好み	「ダークモードが欲しい」「通知が欲しい」「友達と共有したい」	将来のロードマップ（Out of Scope）として記録

「何をやらないか」を決める勇気が、アプリを完成に導きます。

なお、テスターの「声」だけでは判断がつかないこともあります（「使いにくい」と言われたが、実際にどこで詰まっているかが分からない等）。そうした場合は、PostHog のようなプロダクトアナリティクスを入れて、どの画面で離脱しているかを数字で見るという手もあります。Expo向けのSDK（posthog-react-native）が提供されており、EASのインテグレーションからも接続できます。

---

2. AIエージェントにフィードバックを解析・タスク化させるプロンプト

テスターから集まった生の声をそのままAIに渡し、整理させます。

【タスク: テスターフィードバックの整理と改修タスクの生成】

以下は、Firebase App Distribution経由のテスターから集まったフィードバック一覧です。
プロジェクトルートの `SPEC.md` および `DESIGN.md` の方針と照らし合わせ、改修タスクを整理してください。

### テスターからの報告一覧:
1. 「空欄のまま登録ボタンを押したらアプリが真っ白になって落ちた（Android）」
2. 「文字が小さくて、画面の明るい屋外だと達成率が見づらい（iPhone 13）」
3. 「クラウドで友達と習慣を共有できるようにしてほしい」
4. 「削除ボタンがなくて、間違えて作った習慣を消せない」
5. 「背景色をピンクにしたい」

### 出力フォーマット:
- 各項目の優先度判定（P0 / P1 / P2）とその理由
- 今回の次期ビルド（v0.2.0）で修正すべき具体的な実装指示タスク
- Out of Scope（今回は見送るべき理由と、テスターへの丁寧な回答案）

---

3. AIと連携した迅速なバグ修正・UI改善の対話サイクル

タスクが明確になったら、AIエージェントに直接コードを修正させます。

指示の例

【指示: バリデーションと削除機能の追加】
`components/AddHabitModal.tsx` および `hooks/useHabits.ts` を修正してください。
1. 空文字または空白のみの場合は登録ボタンを非活性（disabled）にし、「習慣名を入力してください」という警告を表示すること。
2. 各HabitCardにスワイプまたは長押しで「削除確認ダイアログ」を表示し、習慣を削除できるようにすること。
3. `DESIGN.md` のフォントサイズ基準に基づき、達成率のテキストを 14px から 16px（太字）へ拡大すること。

指示から数十秒で、型安全かつUI規約に従った修正パッチが適用されます。実機（Expo Go）ですぐに動作確認し、問題がなければコミットします。

---

4. バージョン番号とビルド番号のインクリメント規則

新しいビルドを作成する際は、app.json 内のバージョン番号を更新します。これを怠ると、テスターの端末で「更新」として認識されません。

{
  "expo": {
    "name": "HabitFlow",
    "slug": "habit-flow",
    "version": "0.2.0",
    "ios": {
      "buildNumber": "2"
    },
    "android": {
      "versionCode": 2
    }
  }
}

• version (セマンティックバージョニング): 0.1.0 → 0.2.0（機能改善やバグ修正のまとまり）。ユーザーに見える表記。
• buildNumber（iOS）/ versionCode（Android）: ビルドごとに必ず1ずつ増やす内部管理用の連番整数。

---

5. 次期ビルド（v0.2.0）の再配布とテスターへの感謝報告

修正内容をGitにコミットし、再び EAS Build を実行します。

git commit -am "fix: バリデーション追加、削除機能実装、視認性改善 (v0.2.0)"
eas build --platform all --profile preview

ビルドが完了したら、Firebase App Distributionにアップロードし、リリースノートにテスターへの感謝を明記して配信します。

【HabitFlow v0.2.0 配布開始！】
テスターの皆様、ご報告ありがとうございました！いただいた声をもとに改善しました。
- 🛠 空文字でのクラッシュを修正
- 🗑 習慣の長押し削除機能を追加
- 👀 屋外での文字の見やすさを向上
ぜひ最新版にアップデートしてお試しください！

テスターは「自分の意見がすぐに反映された！」と感じ、より熱心なファン・協力者になってくれます。

---

6. フィードバック編の総まとめと次のフェーズへの橋渡し

フィードバック編（Phase05）のサイクルを回すことで、アプリの品質は見違えるほど強固になりました。

1. 全体像の理解: 01. Firebase App Distributionでテスト配布する流れを知る で審査なしの配布フローを把握。
2. バイナリ作成: 02. EAS Buildでテスター配布用ビルドを作る で実機インストール用のAPK/IPAを生成。
3. 配信設定: 03. Firebase App Distributionにアプリをアップロードする で配信パイプラインを開通。
4. グループ運用: 04. テスターグループを作ってフィードバックを集める で良質なフィードバックを集める体制を構築。
5. 改善イテレーション: 05. フィードバックを改善タスクにして次のビルドを配る（この記事）で、迅速な改修と再配布を達成。

次のフェーズ：公開＆マネタイズ編へ

テスターによる実機検証をパスし、洗練されたあなたのアプリは、いよいよ全世界のユーザーに向けてリリースされる準備が整いました。

次の「Phase06：公開＆マネタイズ編」では、App StoreおよびGoogle Playの審査ガイドラインをクリアし、AIを活用した魅力的なストア掲載情報（ASO）を作り、広告やアプリ内課金による収益化基盤を組み込んで公開する手順を完全網羅します。

さっそく「01. Expoアプリ公開と収益化のロードマップ」へ進みましょう！