05. 最初の動く版を作ってGitHubに保存する

UIコンポーネントが揃い、いよいよコーディング編（Phase04）のクライマックスです。

アプリが単なる「静的な画面のモック」から、「ユーザーが実際にデータを入力し、アプリを再起動してもデータが消えない、本物のMVP（実用最小限の製品）」へと進化する瞬間を迎えます。

この記事では、AsyncStorageを使ったローカル永続化の実装、実機での入念な動作テスト、コード品質のチェック、そして開発の確固たるマイルストーンとしてGitHubへ最初のバージョンを安全に保存する手順を詳しく解説します。

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

MVPの要件：ローカルストレージ（AsyncStorage）でのデータ永続化
Spec Kitの3周目：データ永続化を実装する
実機でのシナリオテストチェックリスト
コードのクリーンアップとTypeScript型チェック
GitコミットとGitHubへの安全な保存（v0.1.0タグ付け）
コーディング編の総まとめと次のフェーズへの橋渡し

1. MVPの要件：ローカルストレージ（AsyncStorage）でのデータ永続化

リサーチ編の SPEC.md で定めた通り、最初のMVPでは複雑なクラウドDBやユーザー認証は作らず、端末内保存（AsyncStorage）で完結させます。

まずは必要なライブラリをインストールします。

npx expo install @react-native-async-storage/async-storage

Expoの公式コマンドである npx expo install を使うことで、現在のExpo SDKバージョンに最も互換性のある安定バージョンが自動でインストールされます。

2. Spec Kitの3周目：データ永続化を実装する

これまでと同じ順序で、データの取得・保存・更新を行うカスタムフック（useHabits）を作らせます。

手順1：/speckit.specify で保存機能の仕様を書く

Spec Kit サイクルの3周目です。今回の機能は「データが消えないこと」です。

/speckit.specify

習慣データを端末内に保存し、アプリを再起動しても復元できるようにする。

`hooks/useHabits.ts` を作成し、以下の要件を満たすカスタムフックを実装してください。

1. データ型定義:
   interface Habit {
     id: string;
     title: string;
     streakDays: number;
     isCompletedToday: boolean;
     lastCompletedDate?: string; // YYYY-MM-DD
   }

2. 提供する関数・状態:
   - `habits: Habit[]`: 登録されている習慣一覧
   - `isLoading: boolean`: ストレージからの読み込み中フラグ
   - `addHabit(title: string): Promise<void>`: 新しい習慣の追加
   - `toggleHabit(id: string): Promise<void>`: 今日の完了状態の切り替え
   - `deleteHabit(id: string): Promise<void>`: 習慣の削除

3. エラーハンドリングと安全性:
   - AsyncStorage の読み書き時に try-catch でエラーハンドリングを行うこと。
   - アプリ起動時に日付をチェックし、日付が変わっていれば `isCompletedToday` をリセットするロジックを含めること。

4. 画面への接続:
   - このフックを `app/(tabs)/index.tsx` に繋ぎ込み、習慣リストの描画、
     チェックボタンの `onToggle`、削除ハンドラーに接続すること。
   - 前の機能で作った `HabitCard` / `ProgressBar` / `FloatingAddButton` を使うこと。

手順2：計画・タスク・実装

/speckit.plan

- 保存には `@react-native-async-storage/async-storage` を使う。
  導入コマンド `npx expo install @react-native-async-storage/async-storage` を
  タスクに含めること。
- 保存キーは `@habit_flow_data` の1つにまとめ、JSON文字列として読み書きする。
- 日付の比較は端末のローカルタイムゾーンで行い、`YYYY-MM-DD` の文字列で保持する。
- 読み込み中は `isLoading` を true にし、画面側でちらつきを防げるようにすること。

/speckit.tasks

/speckit.implement

3. 実機でのシナリオテストチェックリスト

実装が完了したら、スマートフォン実機（Expo Go）を手に持ち、以下のシナリオテストを実際に操作して検証します。

追加テスト: 「読書をする」と入力して追加し、リストに新しいカードが表示されるか
バリデーションテスト: 空文字のまま追加しようとしたとき、エラーが表示されて追加を阻止できるか
トグルテスト: チェックボタンをタップし、完了状態（緑の背景・チェックアイコン）に切り替わるか
再トグルテスト: もう一度タップして、未完了に戻せるか
削除テスト: 習慣カードを長押しまたは削除ボタンを押して、リストから消去できるか
永続化テスト: アプリ（Expo Go）をタスクキルして完全に終了し、再起動してもデータが残っているか
進捗連動テスト: チェックの増減に合わせて、上部の達成率プログレスバーがリアルタイムに連動するか

これらがすべてパスすれば、あなたの手の中に「実際に使える本物のスマホアプリ」が誕生したことになります！

4. コードのクリーンアップとTypeScript型チェック

/speckit.analyze で仕様と実装のズレを洗い出す

コミットの前に、書いた仕様どおりに実装されているかをSpec Kit自身に点検させます。

/speckit.analyze

仕様・計画・タスクと実際のコードを突き合わせ、抜けている実装や、仕様に無いのに勝手に足された処理を報告してくれます。積み残しが見つかったら、/speckit.converge で新しいタスクとして追加してから実装させます。

型チェックを通す

不要なデバッグ用 console.log や型エラーがないかをチェックします。

ターミナルで以下を実行します。

# TypeScriptの型チェックを一括実行
npx tsc --noEmit

エラーが表示された場合は、エラー文をそのままコピーしてAIエージェントに貼り付けます。

「npx tsc --noEmit で以下の型エラーが出ました。原因を特定して修正してください。[エラー内容]」

数秒で完璧な修正コードが返ってきます。

また、不要なファイルがGit追跡対象に入らないよう、.gitignore に .expo/ や node_modules/ が含まれていることを確認します。なお .specify/ と specs/ はコミットに含めてください。仕様と計画がコードと一緒に残ることが、仕様駆動開発の最大の資産です。

5. GitコミットとGitHubへの安全な保存（v0.1.0タグ付け）

動く最初のバージョンを、未来の自分のために確実に保存します。

手順1：GitHubにリポジトリを作る

まだリモートリポジトリを作っていない場合は、先に用意します。GitHubのWeb画面から「New repository」で作っても構いませんが、GitHub CLI を入れておくとターミナルだけで完結します。

# GitHub CLI でログイン（初回のみ）
gh auth login

# 非公開リポジトリを作り、リモート（origin）として登録する
gh repo create habit-flow --private --source=. --remote=origin

Web画面で作った場合は、表示されるURLを使ってリモートを登録します。

git remote add origin https://github.com/<あなたのユーザー名>/habit-flow.git

手順2：コミットしてタグを打つ

Spec Kitの作業中は機能ブランチにいる場合があります。まず現在のブランチを確認し、完成したコードがあるブランチを保存します。main に統合する場合は、別途プルリクエストなどで差分を確認してから行ってください。

# 変更状態の確認
git status
git branch --show-current

# 全ての変更をステージング
git add .
git diff --cached

# わかりやすいコミットメッセージでコミット
git commit -m "feat: MVP初版完成（習慣の登録・トグル・削除・AsyncStorage永続化を実装）"

# セマンティックバージョニングでリリース用タグを打つ
git tag -a v0.1.0 -m "Release v0.1.0: First working MVP"

# 現在のブランチと、このリリースのタグをプッシュ
git push -u origin HEAD
git push origin v0.1.0

GitHubのリポジトリページを開き、「Releases」または「Tags」に v0.1.0 が表示されているのを確認します。

6. コーディング編の総まとめと次のフェーズへの橋渡し

おめでとうございます！これでコーディング編（Phase04）の全ステップが完了しました。

環境構築: 01. GitHub Spec Kitで開発環境のベースを作るで specify を導入し、プロジェクトの憲法を定めました。
プロジェクト起動: 02. Expoプロジェクトを作成して実機で起動するで実機プレビューを立ち上げました。
骨格生成: 03. Spec Kitでアプリの画面骨格とルーティングを生成するで仕様駆動サイクルを一周させ、Expo Routerの画面遷移を組みました。
UI実装: 04. Spec KitでStitchのデザインをUIコンポーネントに実装するで美しいデザインパーツを再現しました。
MVP完成: 05. 最初の動く版を作ってGitHubに保存する（この記事）で、永続化とGitHub保存を達成しました。

次のフェーズ：フィードバック編へ

自分の手元で動くようになったアプリですが、開発者自身の目線だけでは気づけないバグや、操作性の違和感が必ず存在します。

次の「Phase05：フィードバック編」では、EAS BuildとFirebase App Distributionを活用し、家族や友人、ベータテスターの端末に安全にテストアプリを配布して改善サイクルを回す方法を学びます。

さっそく「01. Firebase App Distributionでテスト配布する流れを知る」へ進みましょう！