この記事はNTTドコモソリューションズ Advent Calendar 2025 20日目の記事です。
はじめに
NTTドコモソリューションズの東です。
私は普段、モバイルアプリ開発案件のスクラムマスターとしてチーム活動をサポートしています。
スクラムチームに効果的な支援を提供するため、「実際にアプリを一つリリースするところまで体験してみよう」と決意し、この取り組みを開始しました。
また、せっかく挑戦するならAI開発ツールを活用して実践的なスキルも同時に習得しようと考えました。そこで今回は、2025年11月に一般提供が開始されたKiro（AWSが開発したAIエージェント搭載の統合開発環境）を使い、仕様駆動開発でのアプリ開発を体験してみました。（結果的にほぼバイブコーディングのような形になりましたが。）
この記事が、Kiroでのモバイルアプリ個人開発に挑戦したい方や、アプリリリースまでの流れを知りたい方の参考になれば幸いです。
リリースしたアプリ
今回リリースしたアプリは、日々の習慣を記録し、カレンダー形式で確認できる習慣管理アプリ「習慣チェック Habit Tracker Calendar」です。
習慣を登録して毎日チェックを付けることで、継続状況を一目で把握できます。また、リマインダー機能により、習慣を忘れずに実行することができます。
データベースを使用せず、ローカルストレージのみでデータを管理することで、開発・運用の複雑さを抑えました。
特に意識したこと
モチベーション低下を避けるため、素早くリリースすることを最優先に進めました。完璧を目指さず、失敗したら最初からやり直すくらいの気持ちで取り組んでいます。
アプリの完成度を高めることやAIツールの習得よりも、MVP（Minimum Viable Product）としてリリースすることを重視しました。また、この記事の執筆期限に間に合わせたかったため、約1週間でのリリースを目標に設定しました。
その結果、モチベーションを保ったまま素早くリリースすることができ、この方針は良かったと感じています。
全体的なスケジュール
- 1日目：
- 企画
- 環境構築
- Kiroインストール・初期設定
- プロジェクト作成
- 要件定義・設計
- 初回プロンプト実行（ドキュメント作成）
- 2日目：
- 開発
- 機能実装
- 機能・バグ修正
- アプリアイコン・スプラッシュ画面用の画像作成
- プライバシーポリシーページ作成
- 開発
- 3日目：
- テスト
- ユーザーテスト・フィードバック反映
- ストア申請
- App Store申請対応・App Storeリリース
- テスト
今回のアプリのApp Store申請は、半日ほどで承認されました。なお、Androidの場合は新規アプリのリリースに12名以上が参加する14日間のクローズドテストが必須となっており、今回は断念しました。
使用したツール
- 開発環境
- Kiro（メインエディタ）
- Xcode（App Store Connectアップロード）
- GitHub（バージョン管理）
- AI関連ツール
- Claude Desktop（汎用的な相談）
- ChatGPT（ロゴ作成）
- その他
- GIMP（画像編集）
- Google Sites（プライバシーポリシーページ作成）
- TestFlight（ユーザーテスト）
ツールの習得にも時間がかかるため、使用するツールは最小限に絞ることを意識しました。
作業の詳細
１日目
企画
素早くリリースしたかったため、シンプルかつ自分が使いたいアプリを検討しました。テレワーク中心の生活で運動習慣がなくなっていたことから、習慣をトラッキングできるアプリを作ることにしました。
企画段階では、参考になりそうな既存アプリやデザインを調査し、アプリの完成イメージを固めました。また、既存アプリとの差別化要素として、ローカルプッシュ通知によるリマインダー機能を想定しました。
ここでの成果物：参考とするアプリの仕様やデザインイメージ
環境構築：Kiroインストール・初期設定
公式サイトからインストーラをダウンロードしてインストールします。
ガイドは英語ですが、VSCodeの設定インポートやダークモードなどの簡単な項目を選択するだけでインストールが完了しました。
インストール後は拡張機能を追加しますが、入れすぎても使いこなせないため、最低限必要なものだけに絞りました。
出典：「Kiro(バージョン0.7.34) 拡張機能画面」(筆者ローカル環境/スクリーンショット取得日：2025年12月11日）
ここでの成果物：拡張機能が入ったKiro
環境構築：プロジェクト作成
今回は、業務でも使用しているFlutterで開発することにしました。コマンドラインから初期プロジェクトを作成し、プロジェクト名はAIに複数の候補を提案してもらい、その中から選びました。
作成したプロジェクトをKiroで開いて、GitHubリポジトリに公開します。
ここでの成果物：Flutterの初期プロジェクト
要件定義・設計：初回プロンプト実行（ドキュメント作成）
KiroのSpecモードを起動し、検討した要件をプロンプトで指示します。また、企画段階で用意した参考のデザインイメージ画像も添付しました。
初回プロンプト
習慣チェックカレンダアプリを作成したい。
* 非常にシンプルなアプリとする
* データはローカルストレージに保持する
* 必要な機能
* 習慣の登録
* 習慣の編集・削除
* 習慣のチェック入力
* カレンダによるチェック表示
* ローカルプッシュによる習慣チェックのリマインド
* 画面構成
* メイン画面
* 習慣の登録、習慣の更新・削除はダイアログで表示
* 設定画面
* 利用規約、アプリケーション情報、ライセンス情報、プライバシーポリシー
* 参考デザインは添付ファイルを参照
上記のような簡単な要件を伝えただけで、充実したドキュメントが自動生成されました。
作成されたドキュメント
requirements.md（要件定義書）
# 要件定義書
## はじめに
習慣チェックカレンダーは、ユーザーが日々の習慣を記録し、カレンダー形式で視覚的に確認できるシンプルなモバイルアプリケーションです。ローカルストレージにデータを保存し、プッシュ通知でリマインダーを提供します。
## 用語集
- **HabitCheckApp**: 習慣チェックカレンダーアプリケーションシステム
- **Habit**: ユーザーが追跡したい習慣（例：筋トレ、読書、瞑想）
- **Check**: 特定の日に習慣を実行したことを示す記録
- **LocalStorage**: デバイス上のローカルデータストレージ
- **LocalPushNotification**: デバイス上で生成されるプッシュ通知
- **MainScreen**: 習慣リストとカレンダーを表示するメイン画面
- **SettingsScreen**: アプリ設定と情報を表示する設定画面
- **HabitDialog**: 習慣の登録・編集・削除を行うダイアログ
## 要件
### 要件 1
**ユーザーストーリー:** ユーザーとして、新しい習慣を登録したい。そうすることで、追跡したい習慣をアプリに追加できる。
#### 受入基準
1. WHEN ユーザーがメイン画面で習慣追加ボタンをタップする THEN HabitCheckApp SHALL HabitDialog を表示する
2. WHEN ユーザーが HabitDialog で習慣名を入力し追加ボタンをタップする THEN HabitCheckApp SHALL 新しい Habit を作成し LocalStorage に保存する
3. WHEN ユーザーが空の習慣名で追加を試みる THEN HabitCheckApp SHALL 追加を拒否しエラーメッセージを表示する
4. WHEN 新しい Habit が追加される THEN HabitCheckApp SHALL MainScreen の習慣リストに即座に表示する
5. WHEN HabitDialog でキャンセルボタンがタップされる THEN HabitCheckApp SHALL ダイアログを閉じ変更を破棄する
### 要件 2
**ユーザーストーリー:** ユーザーとして、既存の習慣を編集したい。そうすることで、習慣名やその他の設定を更新できる。
#### 受入基準
1. WHEN ユーザーが MainScreen で既存の Habit をタップする THEN HabitCheckApp SHALL 編集用の HabitDialog を表示する
2. WHEN ユーザーが HabitDialog で習慣名を変更し保存する THEN HabitCheckApp SHALL Habit を更新し LocalStorage に保存する
3. WHEN Habit が更新される THEN HabitCheckApp SHALL MainScreen の表示を即座に更新する
4. WHEN ユーザーが空の習慣名に変更しようとする THEN HabitCheckApp SHALL 更新を拒否しエラーメッセージを表示する
### 要件 3
**ユーザーストーリー:** ユーザーとして、不要になった習慣を削除したい。そうすることで、習慣リストを整理できる。
#### 受入基準
1. WHEN ユーザーが HabitDialog で削除ボタンをタップする THEN HabitCheckApp SHALL 確認ダイアログを表示する
2. WHEN ユーザーが削除を確認する THEN HabitCheckApp SHALL Habit とそれに関連するすべての Check を LocalStorage から削除する
3. WHEN Habit が削除される THEN HabitCheckApp SHALL MainScreen の習慣リストから即座に削除する
4. WHEN ユーザーが削除をキャンセルする THEN HabitCheckApp SHALL Habit を保持しダイアログを閉じる
### 要件 4
**ユーザーストーリー:** ユーザーとして、特定の日に習慣を実行したことをチェックしたい。そうすることで、習慣の実行を記録できる。
#### 受入基準
1. WHEN ユーザーがカレンダー上の特定の日付と Habit の交差セルをタップする THEN HabitCheckApp SHALL その日の Check を作成し LocalStorage に保存する
2. WHEN Check が作成される THEN HabitCheckApp SHALL カレンダー上にチェックマークを即座に表示する
3. WHEN ユーザーが既にチェック済みのセルをタップする THEN HabitCheckApp SHALL Check を削除し LocalStorage から削除する
4. WHEN Check が削除される THEN HabitCheckApp SHALL カレンダー上のチェックマークを即座に削除する
5. WHEN ユーザーが未来の日付をタップする THEN HabitCheckApp SHALL Check の作成を許可する
### 要件 5
**ユーザーストーリー:** ユーザーとして、カレンダー形式で習慣のチェック状況を確認したい。そうすることで、習慣の継続状況を視覚的に把握できる。
#### 受入基準
1. WHEN ユーザーが MainScreen を表示する THEN HabitCheckApp SHALL 現在の月のカレンダーを表示する
2. WHEN カレンダーが表示される THEN HabitCheckApp SHALL 各 Habit の行に対して各日付の Check 状態を表示する
3. WHEN ユーザーが月を変更する THEN HabitCheckApp SHALL 選択された月のカレンダーと Check 状態を表示する
4. WHEN Check が存在する日付 THEN HabitCheckApp SHALL チェックマークアイコンを表示する
5. WHEN Check が存在しない日付 THEN HabitCheckApp SHALL 空のセルを表示する
### 要件 6
**ユーザーストーリー:** ユーザーとして、習慣チェックのリマインダーを受け取りたい。そうすることで、習慣を忘れずに実行できる。
#### 受入基準
1. WHEN ユーザーが Habit に対してリマインダー時刻を設定する THEN HabitCheckApp SHALL LocalPushNotification をスケジュールする
2. WHEN 設定された時刻になる THEN HabitCheckApp SHALL LocalPushNotification を表示する
3. WHEN ユーザーがリマインダー時刻を変更する THEN HabitCheckApp SHALL LocalPushNotification を再スケジュールする
4. WHEN ユーザーがリマインダーを無効にする THEN HabitCheckApp SHALL LocalPushNotification をキャンセルする
5. WHEN アプリが通知権限を持たない THEN HabitCheckApp SHALL 通知権限のリクエストを表示する
### 要件 7
**ユーザーストーリー:** ユーザーとして、アプリの設定と情報にアクセスしたい。そうすることで、利用規約やプライバシーポリシーを確認できる。
#### 受入基準
1. WHEN ユーザーが MainScreen で設定ボタンをタップする THEN HabitCheckApp SHALL SettingsScreen を表示する
2. WHEN ユーザーが SettingsScreen で利用規約をタップする THEN HabitCheckApp SHALL 利用規約ページを表示する
3. WHEN ユーザーが SettingsScreen でアプリケーション情報をタップする THEN HabitCheckApp SHALL アプリケーション情報ページを表示する
4. WHEN ユーザーが SettingsScreen でライセンス情報をタップする THEN HabitCheckApp SHALL ライセンス情報ページを表示する
5. WHEN ユーザーが SettingsScreen でプライバシーポリシーをタップする THEN HabitCheckApp SHALL プライバシーポリシーページを表示する
### 要件 8
**ユーザーストーリー:** ユーザーとして、アプリのデータがローカルに保存されることを期待する。そうすることで、オフラインでもアプリを使用できる。
#### 受入基準
1. WHEN ユーザーが Habit を作成、更新、または削除する THEN HabitCheckApp SHALL LocalStorage に即座に変更を保存する
2. WHEN ユーザーが Check を作成または削除する THEN HabitCheckApp SHALL LocalStorage に即座に変更を保存する
3. WHEN アプリが起動される THEN HabitCheckApp SHALL LocalStorage からすべての Habit と Check を読み込む
4. WHEN LocalStorage への書き込みが失敗する THEN HabitCheckApp SHALL エラーメッセージを表示しユーザーに通知する
5. WHEN LocalStorage からの読み込みが失敗する THEN HabitCheckApp SHALL エラーメッセージを表示し空の状態で起動する
### 要件 9
**ユーザーストーリー:** ユーザーとして、シンプルで直感的な UI を期待する。そうすることで、ストレスなくアプリを使用できる。
#### 受入基準
1. WHEN ユーザーがアプリを起動する THEN HabitCheckApp SHALL 1 秒以内に MainScreen を表示する
2. WHEN ユーザーが UI コンポーネントをタップする THEN HabitCheckApp SHALL 100 ミリ秒以内に視覚的フィードバックを提供する
3. WHEN ユーザーがカレンダーをスクロールする THEN HabitCheckApp SHALL スムーズなスクロール体験を提供する
4. WHEN エラーが発生する THEN HabitCheckApp SHALL 明確で理解しやすいエラーメッセージを表示する
5. WHEN ユーザーが操作を実行する THEN HabitCheckApp SHALL 一貫したデザインパターンとナビゲーションを提供する
design.md（設計書）
# 設計書
## 概要
習慣チェックカレンダーは、Flutter を使用して構築されるクロスプラットフォームのモバイルアプリケーションです。アプリは、ユーザーが日々の習慣を追跡し、カレンダー形式で視覚化できるようにします。すべてのデータはローカルストレージに保存され、ローカルプッシュ通知を使用してリマインダーを提供します。
設計の主要な原則：
- **シンプルさ**: 最小限の機能で最大の価値を提供
- **オフラインファースト**: すべてのデータをローカルに保存
- **レスポンシブ**: 即座のフィードバックとスムーズなアニメーション
- **保守性**: クリーンアーキテクチャパターンの採用
## アーキテクチャ
アプリケーションは、レイヤードアーキテクチャパターンに従います：
┌─────────────────────────────────────┐
│ Presentation Layer │
│ (Widgets, Screens, Dialogs) │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Application Layer │
│ (State Management - Provider) │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Domain Layer │
│ (Models, Business Logic) │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Data Layer │
│ (Repository, Local Storage) │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Infrastructure Layer │
│ (SharedPreferences, Notifications) │
└─────────────────────────────────────┘
### アーキテクチャの決定事項
1. **状態管理**: Provider パッケージを使用
- シンプルで学習曲線が低い
- Flutter チームが推奨
- 小規模アプリに適している
2. **ローカルストレージ**: SharedPreferences + JSON シリアライゼーション
- 軽量で高速
- 構造化データの保存に適している
- Flutter の標準パッケージ
3. **通知**: flutter_local_notifications パッケージ
- クロスプラットフォーム対応
- スケジュール通知のサポート
- 広く使用されている
## コンポーネントとインターフェース
### Presentation Layer
#### MainScreen
メイン画面は、習慣リストとカレンダービューを表示します。
**責務:**
- 習慣リストの表示
- カレンダーグリッドの表示
- ユーザーインタラクションの処理
- HabitDialog の表示
**主要なウィジェット:**
- `HabitListView`: 習慣のリストを表示
- `CalendarGridView`: カレンダーグリッドを表示
- `MonthSelector`: 月の選択コントロール
- `AddHabitButton`: 習慣追加ボタン
#### HabitDialog
習慣の作成、編集、削除を行うダイアログ。
**責務:**
- 習慣名の入力フォーム
- リマインダー時刻の設定
- 習慣の保存・削除アクション
**入力:**
- `Habit?`: 編集モードの場合は既存の習慣、作成モードの場合は null
**出力:**
- `HabitDialogResult`: 保存、削除、またはキャンセルの結果
#### SettingsScreen
アプリの設定と情報を表示する画面。
**責務:**
- 利用規約、アプリ情報、ライセンス、プライバシーポリシーへのナビゲーション
- 各情報ページの表示
### Application Layer
#### HabitProvider
習慣とチェックの状態を管理する Provider。
**責務:**
- 習慣リストの管理
- チェック状態の管理
- リポジトリとの連携
- UI への状態通知
**主要なメソッド:**
dart
Future<void> loadHabits()
Future<void> addHabit(Habit habit)
Future<void> updateHabit(Habit habit)
Future<void> deleteHabit(String habitId)
Future<void> toggleCheck(String habitId, DateTime date)
bool isChecked(String habitId, DateTime date)
List<Habit> getHabits()
#### NotificationProvider
通知の管理を行う Provider。
**責務:**
- 通知のスケジューリング
- 通知のキャンセル
- 通知権限の管理
**主要なメソッド:**
dart
Future<void> scheduleNotification(Habit habit)
Future<void> cancelNotification(String habitId)
Future<void> requestPermission()
Future<bool> hasPermission()
### Domain Layer
#### Habit Model
習慣を表すドメインモデル。
**プロパティ:**
dart
class Habit {
final String id;
final String name;
final DateTime createdAt;
final TimeOfDay? reminderTime;
final bool reminderEnabled;
}
#### HabitCheck Model
習慣のチェックを表すドメインモデル。
**プロパティ:**
dart
class HabitCheck {
final String habitId;
final DateTime date;
final DateTime checkedAt;
}
### Data Layer
#### HabitRepository
習慣とチェックのデータアクセスを抽象化するリポジトリ。
**責務:**
- データの永続化
- データの取得
- データの削除
**インターフェース:**
dart
abstract class HabitRepository {
Future<List<Habit>> getAllHabits();
Future<void> saveHabit(Habit habit);
Future<void> deleteHabit(String habitId);
Future<List<HabitCheck>> getAllChecks();
Future<void> saveCheck(HabitCheck check);
Future<void> deleteCheck(String habitId, DateTime date);
}
#### LocalHabitRepository
SharedPreferences を使用した HabitRepository の実装。
**実装の詳細:**
- 習慣は JSON 配列として保存
- チェックは JSON 配列として保存
- キー: `habits`, `habit_checks`
### Infrastructure Layer
#### LocalStorageService
SharedPreferences のラッパー。
**責務:**
- キーバリューストアへのアクセス
- JSON のシリアライゼーション/デシリアライゼーション
#### NotificationService
flutter_local_notifications のラッパー。
**責務:**
- 通知の初期化
- 通知のスケジューリング
- 通知のキャンセル
## データモデル
### Habit
dart
class Habit {
final String id; // UUID
final String name; // 習慣名（1-50文字）
final DateTime createdAt; // 作成日時
final TimeOfDay? reminderTime; // リマインダー時刻（オプション）
final bool reminderEnabled; // リマインダー有効フラグ
// JSON シリアライゼーション
Map<String, dynamic> toJson();
factory Habit.fromJson(Map<String, dynamic> json);
}
**バリデーションルール:**
- `name`: 空でない、1-50 文字
- `id`: UUID v4 形式
- `createdAt`: 過去または現在の日時
### HabitCheck
dart
class HabitCheck {
final String habitId; // 習慣の ID
final DateTime date; // チェックした日付（時刻は00:00:00）
final DateTime checkedAt; // チェックした日時
// JSON シリアライゼーション
Map<String, dynamic> toJson();
factory HabitCheck.fromJson(Map<String, dynamic> json);
}
**バリデーションルール:**
- `habitId`: 有効な UUID
- `date`: 日付部分のみ（時刻は 00:00:00）
- `checkedAt`: 過去または現在の日時
### ストレージスキーマ
**SharedPreferences キー:**
- `habits`: List<Habit> の JSON 配列
- `habit_checks`: List<HabitCheck> の JSON 配列
**例:**
json
{
"habits": [
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"name": "筋トレ",
"createdAt": "2025-11-29T10:00:00.000Z",
"reminderTime": "07:00",
"reminderEnabled": true
}
],
"habit_checks": [
{
"habitId": "550e8400-e29b-41d4-a716-446655440000",
"date": "2025-11-29T00:00:00.000Z",
"checkedAt": "2025-11-29T08:30:00.000Z"
}
]
}
## 正確性プロパティ
_プロパティとは、システムのすべての有効な実行において真であるべき特性または動作です。本質的には、システムが何をすべきかについての形式的な記述です。プロパティは、人間が読める仕様と機械で検証可能な正確性保証との橋渡しとなります。_
### プロパティリフレクション
分析の結果、以下の冗長性を特定しました：
- **1.4 と 2.3、3.3**: これらはすべて「状態変更後に UI が更新される」という同じ概念をテストしています。これらを統合して「状態と UI の同期」プロパティにします。
- **4.2 と 4.4**: チェックの作成と削除後の UI 更新は、上記の統合プロパティに含まれます。
- **5.4 と 5.5**: これらは「カレンダーがチェック状態を正しく表示する」という同じ概念の表裏です。1 つのプロパティに統合します。
- **8.1、8.2、8.3**: これらはすべてシリアライゼーションのラウンドトリップをテストしています。1 つの包括的なプロパティに統合します。
### プロパティ一覧
#### プロパティ 1: 習慣の永続化ラウンドトリップ
*任意の*有効な習慣に対して、習慣を保存してから読み込むと、元の習慣と同等のオブジェクトが得られる
**検証: 要件 1.2, 8.1, 8.3**
#### プロパティ 2: 無効な習慣名の拒否
*任意の*空白のみで構成される文字列に対して、習慣の作成または更新を試みると、操作が拒否されエラーが返される
**検証: 要件 1.3, 2.4**
#### プロパティ 3: 習慣の更新の永続化
*任意の*既存の習慣と有効な新しい名前に対して、習慣を更新すると、ストレージから読み込んだ習慣が新しい名前を持つ
**検証: 要件 2.2**
#### プロパティ 4: 習慣削除時の関連チェックの削除
*任意の*習慣とそれに関連するチェックに対して、習慣を削除すると、その習慣のすべてのチェックもストレージから削除される
**検証: 要件 3.2**
#### プロパティ 5: チェックの作成と永続化
*任意の*習慣と日付に対して、チェックを作成すると、そのチェックがストレージに保存され、同じ習慣と日付で照会すると存在する
**検証: 要件 4.1**
#### プロパティ 6: チェックのトグル動作
*任意の*習慣と日付に対して、チェックを作成してから削除すると、そのチェックはストレージに存在しない
**検証: 要件 4.3**
#### プロパティ 7: チェックの永続化ラウンドトリップ
*任意の*有効なチェックに対して、チェックを保存してから読み込むと、元のチェックと同等のオブジェクトが得られる
**検証: 要件 8.2, 8.3**
#### プロパティ 8: カレンダーのチェック状態表示
*任意の*習慣、日付、チェック状態に対して、カレンダーに表示されるチェックマークの有無は、その日付にチェックが存在するかどうかと一致する
**検証: 要件 5.2, 5.4, 5.5**
#### プロパティ 9: 月変更時のデータ整合性
*任意の*月に対して、その月のカレンダーを表示すると、表示されるすべてのチェックはその月の日付に対応する
**検証: 要件 5.3**
#### プロパティ 10: リマインダーのスケジューリング
*任意の*習慣とリマインダー時刻に対して、リマインダーを設定すると、通知サービスにその時刻の通知がスケジュールされる
**検証: 要件 6.1**
#### プロパティ 11: リマインダーの再スケジューリング
*任意の*習慣と新しいリマインダー時刻に対して、リマインダー時刻を変更すると、古い通知がキャンセルされ、新しい時刻に通知がスケジュールされる
**検証: 要件 6.3**
#### プロパティ 12: リマインダーのキャンセル
*任意の*リマインダーが有効な習慣に対して、リマインダーを無効にすると、通知サービスからその通知がキャンセルされる
**検証: 要件 6.4**
#### プロパティ 13: ストレージ書き込みエラーハンドリング
*任意の*ストレージ書き込み操作に対して、操作が失敗すると、エラーが適切に処理されユーザーに通知される
**検証: 要件 8.4**
#### プロパティ 14: ストレージ読み込みエラーハンドリング
*任意の*ストレージ読み込み操作に対して、操作が失敗すると、エラーが適切に処理され、アプリは空の状態で起動する
**検証: 要件 8.5**
## エラーハンドリング
### エラーの種類
1. **バリデーションエラー**
- 空の習慣名
- 無効な日付形式
- 無効な UUID
2. **ストレージエラー**
- 書き込み失敗
- 読み込み失敗
- パース失敗
3. **通知エラー**
- 権限拒否
- スケジューリング失敗
### エラーハンドリング戦略
#### バリデーションエラー
- ユーザー入力時に即座に検証
- エラーメッセージを UI に表示
- 無効な操作を防止
#### ストレージエラー
- try-catch でラップ
- エラーをログに記録
- ユーザーにフレンドリーなメッセージを表示
- 可能な場合は再試行
#### 通知エラー
- 権限チェックを事前に実行
- 権限がない場合はリクエスト
- スケジューリング失敗時はユーザーに通知
### エラーメッセージ
すべてのエラーメッセージは以下の原則に従います：
- 日本語で表示
- 明確で理解しやすい
- 可能な場合は解決策を提示
- 技術的な詳細は避ける
**例:**
- "習慣名を入力してください"
- "データの保存に失敗しました。もう一度お試しください"
- "通知を送信するには、設定で通知を許可してください"
## テスト戦略
### デュアルテストアプローチ
アプリケーションの正確性を保証するために、ユニットテストとプロパティベーステストの両方を使用します：
- **ユニットテスト**: 特定の例、エッジケース、エラー条件を検証
- **プロパティベーステスト**: すべての入力にわたって成り立つべき普遍的なプロパティを検証
両者は補完的であり、包括的なカバレッジを提供します。ユニットテストは具体的なバグを捕捉し、プロパティテストは一般的な正確性を検証します。
### プロパティベーステスト
**使用ライブラリ**: `faker` パッケージを使用してランダムなテストデータを生成
**設定**:
- 各プロパティベーステストは最低 100 回の反復を実行
- 各テストは設計書の正確性プロパティを明示的に参照
- タグ形式: `**Feature: habit-check-calendar, Property {number}: {property_text}**`
**テスト対象**:
- データモデルのシリアライゼーション/デシリアライゼーション
- ビジネスロジックの不変条件
- 状態遷移の整合性
- エラーハンドリングの堅牢性
### ユニットテスト
**テスト対象**:
- 個別のウィジェットの動作
- Provider の状態管理
- Repository の CRUD 操作
- バリデーションロジック
- エラーハンドリング
**テストツール**:
- `flutter_test` パッケージ
- `mockito` パッケージ（モック用）
### 統合テスト
**テスト対象**:
- エンドツーエンドのユーザーフロー
- 画面間のナビゲーション
- データの永続化と復元
**テストツール**:
- `integration_test` パッケージ
### テストカバレッジ目標
- ビジネスロジック: 90%以上
- データレイヤー: 90%以上
- プレゼンテーションレイヤー: 70%以上
## 実装の考慮事項
### パフォーマンス
1. **起動時間**: SharedPreferences からの読み込みは高速（<100ms）
2. **UI レスポンス**: すべての操作は即座に UI を更新（楽観的更新）
3. **メモリ使用**: 習慣とチェックはメモリに保持（通常は数 KB）
### セキュリティ
1. **データの保護**: SharedPreferences はアプリのサンドボックス内に保存
2. **入力検証**: すべてのユーザー入力を検証
3. **エラー情報**: エラーメッセージに機密情報を含めない
### アクセシビリティ
1. **セマンティクス**: すべてのウィジェットに適切なセマンティクスラベルを設定
2. **コントラスト**: WCAG AA 基準を満たす色のコントラスト
3. **タップターゲット**: 最小 44x44 ピクセルのタップ領域
### 国際化
1. **言語**: 日本語のみをサポート（初期バージョン）
2. **日付形式**: 日本の日付形式を使用
3. **時刻形式**: 24 時間形式を使用
### 依存関係
**主要なパッケージ**:
- `provider`: ^6.0.0 - 状態管理
- `shared_preferences`: ^2.0.0 - ローカルストレージ
- `flutter_local_notifications`: ^16.0.0 - ローカル通知
- `uuid`: ^4.0.0 - UUID 生成
- `intl`: ^0.18.0 - 日付フォーマット
**開発用パッケージ**:
- `flutter_test`: SDK - テスト
- `mockito`: ^5.0.0 - モック
- `faker`: ^2.0.0 - テストデータ生成
- `integration_test`: SDK - 統合テスト
## 今後の拡張性
設計は以下の将来的な拡張を考慮しています：
1. **クラウド同期**: Repository パターンにより、クラウドバックエンドへの切り替えが容易
2. **統計とレポート**: チェックデータから統計を計算する機能の追加
3. **習慣のカテゴリ**: 習慣をカテゴリ分けする機能
4. **カスタムテーマ**: ダークモードやカスタムカラーのサポート
5. **エクスポート/インポート**: データのバックアップと復元機能
tasks.md（実装計画）
# 実装計画
- [ ] 1. プロジェクトのセットアップと依存関係の追加
- pubspec.yaml に必要なパッケージを追加（provider, shared_preferences, flutter_local_notifications, uuid, intl）
- 開発用パッケージを追加（mockito, faker）
- パッケージをインストール
- _要件: すべて_
- [ ] 2. ドメインモデルの実装
- [ ] 2.1 Habit モデルの実装
- Habit クラスを作成（id, name, createdAt, reminderTime, reminderEnabled）
- JSON シリアライゼーション（toJson, fromJson）を実装
- バリデーションロジックを実装
- _要件: 1.2, 2.2, 8.1_
- [ ] 2.2 Habit モデルのプロパティテストを作成
- **プロパティ 1: 習慣の永続化ラウンドトリップ**
- **検証: 要件 1.2, 8.1, 8.3**
- [ ] 2.3 Habit モデルのバリデーションプロパティテストを作成
- **プロパティ 2: 無効な習慣名の拒否**
- **検証: 要件 1.3, 2.4**
- [ ] 2.4 HabitCheck モデルの実装
- HabitCheck クラスを作成（habitId, date, checkedAt）
- JSON シリアライゼーション（toJson, fromJson）を実装
- バリデーションロジックを実装
- _要件: 4.1, 8.2_
- [ ] 2.5 HabitCheck モデルのプロパティテストを作成
- **プロパティ 7: チェックの永続化ラウンドトリップ**
- **検証: 要件 8.2, 8.3**
- [ ] 3. インフラストラクチャレイヤーの実装
- [ ] 3.1 LocalStorageService の実装
- SharedPreferences のラッパークラスを作成
- JSON のシリアライゼーション/デシリアライゼーションメソッドを実装
- エラーハンドリングを実装
- _要件: 8.1, 8.2, 8.3, 8.4, 8.5_
- [ ] 3.2 LocalStorageService のエラーハンドリングプロパティテストを作成
- **プロパティ 13: ストレージ書き込みエラーハンドリング**
- **検証: 要件 8.4**
- **プロパティ 14: ストレージ読み込みエラーハンドリング**
- **検証: 要件 8.5**
- [ ] 3.3 NotificationService の実装
- flutter_local_notifications のラッパークラスを作成
- 通知の初期化メソッドを実装
- 通知のスケジューリングメソッドを実装
- 通知のキャンセルメソッドを実装
- 権限チェックと要求メソッドを実装
- _要件: 6.1, 6.3, 6.4, 6.5_
- [ ] 4. データレイヤーの実装
- [ ] 4.1 HabitRepository インターフェースの定義
- 抽象クラス HabitRepository を作成
- CRUD メソッドのシグネチャを定義
- _要件: 1.2, 2.2, 3.2, 4.1, 4.3_
- [ ] 4.2 LocalHabitRepository の実装
- HabitRepository を実装
- getAllHabits, saveHabit, deleteHabit メソッドを実装
- getAllChecks, saveCheck, deleteCheck メソッドを実装
- LocalStorageService を使用してデータを永続化
- _要件: 1.2, 2.2, 3.2, 4.1, 4.3, 8.1, 8.2, 8.3_
- [ ] 4.3 LocalHabitRepository のプロパティテストを作成
- **プロパティ 3: 習慣の更新の永続化**
- **検証: 要件 2.2**
- **プロパティ 4: 習慣削除時の関連チェックの削除**
- **検証: 要件 3.2**
- **プロパティ 5: チェックの作成と永続化**
- **検証: 要件 4.1**
- **プロパティ 6: チェックのトグル動作**
- **検証: 要件 4.3**
- [ ] 5. アプリケーションレイヤーの実装
- [ ] 5.1 HabitProvider の実装
- ChangeNotifier を継承した HabitProvider クラスを作成
- 習慣リストとチェック状態を管理
- loadHabits, addHabit, updateHabit, deleteHabit メソッドを実装
- toggleCheck, isChecked, getHabits メソッドを実装
- HabitRepository を使用してデータを永続化
- _要件: 1.2, 1.4, 2.2, 2.3, 3.2, 3.3, 4.1, 4.2, 4.3, 4.4_
- [ ] 5.2 HabitProvider のユニットテストを作成
- 習慣の追加、更新、削除のテスト
- チェックのトグルのテスト
- 状態通知のテスト
- _要件: 1.2, 2.2, 3.2, 4.1, 4.3_
- [ ] 5.3 NotificationProvider の実装
- ChangeNotifier を継承した NotificationProvider クラスを作成
- scheduleNotification, cancelNotification メソッドを実装
- requestPermission, hasPermission メソッドを実装
- NotificationService を使用
- _要件: 6.1, 6.3, 6.4, 6.5_
- [ ] 5.4 NotificationProvider のプロパティテストを作成
- **プロパティ 10: リマインダーのスケジューリング**
- **検証: 要件 6.1**
- **プロパティ 11: リマインダーの再スケジューリング**
- **検証: 要件 6.3**
- **プロパティ 12: リマインダーのキャンセル**
- **検証: 要件 6.4**
- [ ] 6. プレゼンテーションレイヤー - 共通ウィジェットの実装
- [ ] 6.1 カレンダーグリッドウィジェットの実装
- CalendarGridView ウィジェットを作成
- 月の日付を表示
- 習慣ごとの行を表示
- チェック状態を表示（チェックマークアイコン）
- セルのタップイベントを処理
- _要件: 4.1, 4.2, 4.3, 4.4, 5.1, 5.2, 5.4, 5.5_
- [ ] 6.2 カレンダーグリッドのプロパティテストを作成
- **プロパティ 8: カレンダーのチェック状態表示**
- **検証: 要件 5.2, 5.4, 5.5**
- **プロパティ 9: 月変更時のデータ整合性**
- **検証: 要件 5.3**
- [ ] 6.3 月選択ウィジェットの実装
- MonthSelector ウィジェットを作成
- 現在の月を表示
- 前月/次月ボタンを実装
- _要件: 5.3_
- [ ] 6.4 習慣リストウィジェットの実装
- HabitListView ウィジェットを作成
- 習慣のリストを表示
- 習慣タップで編集ダイアログを表示
- _要件: 1.4, 2.1, 2.3, 3.3_
- [ ] 7. プレゼンテーションレイヤー - HabitDialog の実装
- [ ] 7.1 HabitDialog の基本実装
- HabitDialog ウィジェットを作成
- 習慣名入力フィールドを実装
- リマインダー時刻選択を実装
- リマインダー有効/無効トグルを実装
- 保存、削除、キャンセルボタンを実装
- _要件: 1.1, 1.2, 1.3, 1.5, 2.1, 2.2, 2.4, 3.1, 6.1, 6.3, 6.4_
- [ ] 7.2 HabitDialog のバリデーションとエラー表示
- 空の習慣名のバリデーションを実装
- エラーメッセージの表示を実装
- _要件: 1.3, 2.4_
- [ ] 7.3 HabitDialog の削除確認ダイアログ
- 削除確認ダイアログを実装
- 削除のキャンセル処理を実装
- _要件: 3.1, 3.4_
- [ ] 7.4 HabitDialog のウィジェットテストを作成
- ダイアログの表示テスト
- バリデーションのテスト
- 保存、削除、キャンセルのテスト
- _要件: 1.1, 1.3, 1.5, 2.4, 3.1, 3.4_
- [ ] 8. プレゼンテーションレイヤー - MainScreen の実装
- [ ] 8.1 MainScreen の基本レイアウト
- MainScreen ウィジェットを作成
- AppBar を実装（タイトル、設定ボタン）
- 習慣追加ボタン（FAB）を実装
- HabitListView と CalendarGridView を配置
- MonthSelector を配置
- _要件: 1.1, 5.1, 7.1_
- [ ] 8.2 MainScreen のインタラクション
- 習慣追加ボタンタップで HabitDialog を表示
- 習慣タップで編集用 HabitDialog を表示
- カレンダーセルタップでチェックをトグル
- 月選択でカレンダーを更新
- _要件: 1.1, 2.1, 4.1, 4.3, 5.3_
- [ ] 8.3 MainScreen の Provider 統合
- HabitProvider を使用して状態を管理
- データの読み込みを実装
- UI の更新を実装
- _要件: 1.4, 2.3, 3.3, 4.2, 4.4, 8.3_
- [ ] 8.4 MainScreen のウィジェットテストを作成
- 画面の表示テスト
- ボタンタップのテスト
- ダイアログ表示のテスト
- _要件: 1.1, 2.1, 5.1, 7.1_
- [ ] 9. プレゼンテーションレイヤー - SettingsScreen の実装
- [ ] 9.1 SettingsScreen の基本実装
- SettingsScreen ウィジェットを作成
- リスト形式のメニューを実装
- 利用規約、アプリケーション情報、ライセンス情報、プライバシーポリシーのメニュー項目を追加
- _要件: 7.1, 7.2, 7.3, 7.4, 7.5_
- [ ] 9.2 各情報ページの実装
- 利用規約ページを作成
- アプリケーション情報ページを作成
- ライセンス情報ページを作成（showLicensePage を使用）
- プライバシーポリシーページを作成
- _要件: 7.2, 7.3, 7.4, 7.5_
- [ ] 9.3 SettingsScreen のナビゲーション
- メニュー項目タップで各ページに遷移
- _要件: 7.2, 7.3, 7.4, 7.5_
- [ ] 9.4 SettingsScreen のウィジェットテストを作成
- 画面の表示テスト
- ナビゲーションのテスト
- _要件: 7.1, 7.2, 7.3, 7.4, 7.5_
- [ ] 10. アプリケーションのエントリーポイントとルーティング
- [ ] 10.1 main.dart の実装
- MultiProvider でアプリをラップ
- HabitProvider と NotificationProvider を提供
- MaterialApp を設定
- ルーティングを設定（MainScreen, SettingsScreen）
- _要件: すべて_
- [ ] 10.2 アプリの初期化処理
- 通知サービスの初期化
- データの読み込み
- 通知権限のチェック
- _要件: 6.5, 8.3_
- [ ] 10.3 統合テストを作成
- エンドツーエンドのユーザーフローをテスト
- 習慣の追加、編集、削除フロー
- チェックの作成、削除フロー
- 設定画面へのナビゲーション
- _要件: すべて_
- [ ] 11. チェックポイント - すべてのテストが通ることを確認
- すべてのテストが通ることを確認し、問題があればユーザーに質問する
- [ ] 12. UI の最終調整とポリッシュ
- [ ] 12.1 テーマとスタイリング
- アプリ全体のテーマを設定
- 色、フォント、スペーシングを調整
- 参考デザインに基づいてダークテーマを実装
- _要件: 9.5_
- [ ] 12.2 アニメーションとトランジション
- ダイアログのアニメーションを追加
- チェックマークのアニメーションを追加
- 画面遷移のアニメーションを調整
- _要件: 9.2, 9.3_
- [ ] 12.3 アクセシビリティの改善
- セマンティクスラベルを追加
- タップターゲットのサイズを確認
- コントラストを確認
- _要件: 9.5_
- [ ] 12.4 パフォーマンステストを実施
- 起動時間を測定
- UI レスポンスを測定
- メモリ使用量を確認
- _要件: 9.1, 9.2_
- [ ] 13. 最終チェックポイント - すべてのテストが通ることを確認
- すべてのテストが通ることを確認し、問題があればユーザーに質問する
内容を簡単にレビューし、問題なさそうだったのでコミットしました。本来、仕様駆動開発ではこのレビュー段階により時間をかけるべきですが、今回は初めての取り組みということもあり、まずはこのまま進めることにしました。
ここでの成果物：各ドキュメント（要件定義書、設計書、実装計画）
２日目
開発：機能実装
tasks.mdを開き、リストの上から順に「Start task」ボタンをクリックしてタスクを実行していきます。表示されるコマンドは基本的にすべて許可して進めました。
実装が完了すると「Task completed」と表示されるので、簡単にレビューし、問題なければコミットして次のタスクに進みます。今回は、多少の問題があっても一旦は許容し、まずはすべてのタスクを完了させることを優先しました。
後半のタスクは主にテスト実施となっており、すべてのテストが正常に通過することを確認しました。
すべてのタスクが完了した時点で、以下のようなアプリが完成しました。
メインのカレンダー画面のデザインが崩れていましたが、設定画面はほぼ想定通りの仕上がりでした。また、ローカルプッシュ通知によるリマインダー機能も動作していなかったため、これらの問題を修正していきます。
（Tips）ステアリング
Kiroにおけるステアリングとは、プロジェクト固有のルール、知識、コーディング規約などをAIに教え込む仕組みです。
機能実装を進める中で、タスク実行時のやり取りが英語になったり、実装修正後にドキュメントが更新されなくなったりする問題が発生しました。これらはステアリングに設定を追加することで解決できました。ステアリングファイル自体もKiroに作成してもらっています。
ここでの成果物：とりあえず動いているアプリ、各ステアリングファイル
開発：機能・バグ修正
崩れているデザインや動作しない機能を修正していきます。また、スプラッシュ画面、アプリアイコン、プライバシーポリシーページへのリンクも未実装だったため、これらもタスクに追加しました。
まず、プロンプトでドキュメントとタスクを更新します。
タスク追加プロンプト
動作確認をした結果、以下の追加対応を実施したいので、ドキュメントとタスクを更新して
* 画面レイアウトの変更
* スマホの縦画面での利用を想定したレイアウトに変更
* 表とチェックのデザインをモダンなデザインに変更
* ローカルプッシュによる通知が届かない事象の解消
* スプラッシュ画面の追加
* アプリアイコンの設定
* プライバシーポリシーページへの外部リンクを設定
追加されたタスク（tasks.md）
- [ ] 14. モバイル縦画面レイアウトへの変更
- [ ] 14.1 MainScreen のレイアウト変更
- 横並びレイアウトから縦並びレイアウトに変更
- HabitListView を上部に配置
- CalendarGridView を下部に配置
- 両方のビューを縦スクロール可能にする
- _要件: 10.1, 10.2_
- [ ] 14.2 CalendarGridView の横スクロール対応
- カレンダーグリッドを横スクロール可能に変更
- 日付ヘッダーを固定表示
- スクロール位置を保持
- _要件: 10.3_
- [ ] 14.3 レスポンシブデザインの調整
- タップ領域のサイズを最適化（最小 44x44 ピクセル）
- フォントサイズを調整
- スペーシングを最適化
- _要件: 10.4, 10.5_
- [ ] 15. カレンダーとチェックのデザイン改善
- [ ] 15.1 カレンダーグリッドのモダンデザイン
- グリッド線のスタイルを改善
- セルの角丸を追加
- ホバー/タップ時のアニメーションを追加
- _要件: 9.5_
- [ ] 15.2 チェックマークのデザイン改善
- チェックマークアイコンを大きく表示
- チェック時のアニメーションを追加（スケール、フェード）
- 未チェック状態の視覚的フィードバックを改善
- _要件: 9.2, 9.5_
- [ ] 16. ローカルプッシュ通知の修正
- [ ] 16.1 Android 通知設定の確認と修正
- AndroidManifest.xml の通知設定を確認
- 通知チャンネルの設定を追加
- 通知アイコンを設定
- _要件: 6.1, 6.2_
- [ ] 16.2 iOS 通知設定の確認と修正
- Info.plist の通知権限説明を追加
- 通知スケジューリングの実装を確認
- バックグラウンド実行の設定を確認
- _要件: 6.1, 6.2_
- [ ] 16.3 通知スケジューリングのデバッグ
- 通知が正しくスケジュールされているか確認
- タイムゾーンの処理を確認
- 繰り返し通知の設定を確認
- _要件: 6.1, 6.2, 6.3_
- [ ] 17. スプラッシュ画面の追加
- [ ] 17.1 スプラッシュ画面の設定
- flutter_native_splash パッケージを追加
- スプラッシュ画面の画像を作成
- pubspec.yaml にスプラッシュ設定を追加
- _要件: 11.1, 11.2_
- [ ] 17.2 スプラッシュ画面の生成
- flutter pub run flutter_native_splash:create を実行
- 各プラットフォームのスプラッシュ画面を生成
- スプラッシュ画面の表示時間を調整
- _要件: 11.3, 11.4_
- [ ] 18. アプリアイコンの設定
- [ ] 18.1 アプリアイコンの作成
- チェックマークをモチーフにしたアイコンをデザイン
- 各サイズのアイコン画像を作成（1024x1024 をベースに）
- ブランドカラーを適用
- _要件: 11.2_
- [ ] 18.2 アプリアイコンの設定
- flutter_launcher_icons パッケージを追加
- pubspec.yaml にアイコン設定を追加
- flutter pub run flutter_launcher_icons:main を実行
- 各プラットフォームのアイコンを生成
- _要件: 11.2_
- [ ] 19. プライバシーポリシーの外部リンク設定
- [ ] 19.1 url_launcher パッケージの追加
- pubspec.yaml に url_launcher を追加
- 各プラットフォームの設定を確認
- _要件: 12.1_
- [ ] 19.2 プライバシーポリシーリンクの実装
- SettingsScreen のプライバシーポリシータップ処理を変更
- 外部 URL を開く処理を実装
- エラーハンドリングを追加
- _要件: 12.1, 12.2_
- [ ] 19.3 外部リンク確認ダイアログの追加
- 外部サイトに遷移する前に確認ダイアログを表示
- ユーザーの同意を得てからブラウザを起動
- _要件: 12.2_
- [ ] 20. 最終チェックポイント - 改善版のテスト
- すべての新機能が正しく動作することを確認
- 既存のテストが通ることを確認
- 実機での動作確認を実施
タスクを追加したら、再度タスクを実行していきます。
また、カレンダ部分は適宜プロンプトで変更内容を伝えていきます。
カレンダ部分指摘プロンプト１
以下を踏まえてレイアウトと機能を更新して。必要に応じてドキュメントも更新して。
* 習慣項目はタグで表示するくらいに小さく表示する
* カレンダ部分をメインとする
* カレンダ部分の日付を多く表示する
* 各項目の幅を小さくする
* チェック前の項目は二重丸ではなく、丸とする
* カレンダ部分を横スクロールするときにヘッダー行と習慣行が動くようにする
* カレンダの日付部分の初回表示をアプリ起動日付部分を表示する
カレンダ部分指摘プロンプト２
以下を踏まえてレイアウトと機能を更新して。必要に応じてドキュメントも更新して。
* 習慣タグにリマインダーが有効になっている場合は時計アイコンをつける
* カレンダ部分の左側に習慣列を追加する
* 習慣列はスクロールで動かないようにする
* 初回表示を今日の日付で表示する場合、中央に移動できない場合の日付も考慮する
* 月末、月初の場合
基本的に画面のスクリーンショットをプロンプトに添付し、修正内容を指示することで、以下のように少しずつ改善していきました。
開発：アプリアイコン・スプラッシュ画面用の画像作成
アプリアイコンとスプラッシュ画面用の画像を作成します。
ChatGPTに以下のプロンプトを入力して生成しました。
習慣チェックカレンダーアプリのロゴを作成して。
おしゃれでモダンなデザインで、背景色は#FFFFFFにして。
できた画像
満足できる仕上がりだったため、そのままスプラッシュ画面に採用しました。アプリアイコンについては、GIMPを使って正方形に整形しました。
開発：プライバシーポリシーページ作成
iOSアプリではプライバシーポリシーを掲載したWebページが必要なため、Google Sitesで作成しました。このアプリではユーザー情報の収集を行わないので、その旨と問い合わせ先を記載したシンプルなページにしています。
ここでの成果物：なんとなく形になってきたアプリ、アプリアイコン・スプラッシュ画面用画像、プライバシーポリシーページ
３日目
テスト：ユーザーテスト・フィードバック反映
ある程度形になったので、ユーザーテストを実施しました。
XcodeからアプリをApp Store Connectにアップロードし、TestFlightで配信します。
今回は家族に試用してもらい、以下のようなフィードバックを得ました。
- 習慣リストがタグで表示されている意図が分かりにくい
- 設定ボタンが習慣追加ボタンの左横にあるのは違和感がある
- 設定画面の内容が設定らしくない
- 習慣の表示順序を変更できるようにしてほしい
これらの貴重なフィードバックを反映し、タスクに追加して修正を行いました。
修正後は以下のような画面になりました。
見た目と機能性が改善され、リリース可能な状態になりました。
ここでの成果物：リリース可能なアプリ
ストア申請：App Store申請対応・App Storeリリース
App Store Connectにアプリをアップロードし、申請に必要な項目を入力していきます。
各項目の記載内容もAIに作成してもらいました。（完結版、詳細版などのテキストが提案されました。）
AIが生成した内容のうち、使えそうな項目はそのまま採用しました。
また、審査にはスクリーンショットの提出も必要なため、iPhone用とiPad用の画像を用意しました。App Store Connect上で必要な情報をすべて入力し、審査に提出して申請完了です。
今回は特に指摘事項がなく、半日ほどで審査が通過し、無事App Storeにリリースされました。
ここでの成果物：App Storeへのアプリリリース
Kiroの使用クレジット
エージェントはAutoのみ使用し、リリースまでに385.35クレジットを使いました。
新規ユーザーには30日間有効な500ボーナスクレジットが付与されるため、今回は無料で利用できました。
まとめ
いかがだったでしょうか。
今回ご紹介した方法で、比較的簡単にアプリをリリースすることができました。次回は、仕様駆動開発をより丁寧に実践したり、デザインにこだわったアプリを作ったりしてみたいと考えています。
個人開発やAI活用において大切なことは、まず一歩を踏み出すことだと思います。また、欲張りすぎず、モチベーションを保ちながら進めることも重要だと実感しました。
この記事が、みなさんの開発活動の一助となれば幸いです。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。