冷蔵庫の中身を管理して、毎日の献立を提案するアプリ。
- 冷蔵庫に何が入っているか把握できていない
- 賞味期限・消費期限切れに気づかず捨ててしまう
- 毎日「今日何作ろう」と考えるのがしんどい
- 食品の登録・更新・削除（CRUD）
- 期限の自動設定（食品マスタの
default_expiry_daysから計算） - 期限が近い食品（当日・翌日）のアプリ内表示
- 在庫をもとにレシピを3件提案
- 同じレシピが3日間連続で提案されないよう制御
- 食品単位の集約表示 + ロット単位の詳細表示
| 分類 | 技術 |
|---|---|
| フレームワーク | Next.js 16 (App Router) + TypeScript |
| スタイリング | Tailwind CSS v4 |
| バックエンド | Supabase (PostgreSQL) |
| テスト | Vitest |
- Node.js 20+
- pnpm
- Supabase アカウント
# 1. リポジトリをクローン
git clone https://github.com/Yu-da-1/mealflow.git
cd mealflow
# 2. 依存パッケージをインストール
pnpm install
# 3. 環境変数を設定
cp .env.local.example .env.local
# .env.local に各値を記入（Supabase の URL・anon key、Anthropic API key）
# 4. Supabase にスキーマとシードデータを投入
# Supabase Dashboard > SQL Editor で以下を実行:
# - docs/schema.md のSQL（テーブル作成）
# - supabase/seed.sql（食品マスタ・レシピデータ）
# 5. 開発サーバー起動
pnpm devSUPABASE_URL=your_supabase_url
SUPABASE_ANON_KEY=your_supabase_anon_key
ANTHROPIC_API_KEY=your_anthropic_api_key
mealflow/
├── CLAUDE.md # Claude Code への指示（アーキテクチャルール等）
├── docs/
│ ├── design.md # 全体仕様（MVPスコープ・画面・ドメインロジック）
│ ├── schema.md # DBスキーマ（SQL）
│ ├── api.md # APIエンドポイント仕様
│ ├── conventions.md # コーディング規約
│ └── decisions/ # 設計判断の記録（ADR）
├── supabase/
│ └── seed.sql # 食品マスタ・レシピのシードデータ
├── tasks/
│ ├── current.md # 進行中のタスク
│ └── backlog.md # 未着手タスク
└── src/
├── features/ # UI層（画面・コンポーネント）
├── domain/ # ドメイン層（純粋関数のみ）
├── server/repositories/ # インフラ層（Supabase アクセス）
└── app/
├── api/ # API層（Route Handlers）
└── (frontend)/ # ページ（App Router）
UI層 src/features/
API層 src/app/api/
Domain層 src/domain/ ← 純粋関数のみ。外部依存禁止
Infra層 src/server/repositories/
依存方向: UI → API → Domain ← Repository
supabase の呼び出しを repositories/ に閉じることで、DB変更時の影響範囲を最小化している。Domain層を純粋関数に保つことでテストが書きやすく、将来的な Mobile（React Native）対応でも共通化できる。
pnpm dev # 開発サーバー起動
pnpm prettier --write . # フォーマット
pnpm eslint . --fix # lint 自動修正
pnpm tsc --noEmit # 型チェック（実行前に rm -rf .next が必要）
pnpm vitest run # テスト実行このプロジェクトは Claude Code を活用して開発しています。
Claude Code がセッション開始時に必ず読むファイル。以下を集約しています。
- レイヤー構成と依存ルール（どの層が何をして良いか）
- 絶対に守るルール（
main直接プッシュ禁止・supabaseの呼び出し場所など） - 実装時に参照すべきドキュメントへのポインタ
- 迷ったときの判断基準
詳細な仕様はすべて docs/ に分離し、CLAUDE.md 自体は短く保つ設計にしています。Claude Code はコンテキストウィンドウに限りがあるため、CLAUDE.md が長大になると毎回のコストが上がるためです。
Claude Code に「今何をやるか」を明確に伝えるためのファイル群です。
tasks/
├── current.md # 現在進行中のフェーズのタスク一覧（実装中はここだけ見る）
└── backlog.md # 全フェーズの未着手タスクをPhaseごとに積み上げたもの
運用ルール
current.mdが空のとき →backlog.mdの先頭の未完了グループをcurrent.mdに移して作業開始- 作業中は
current.mdのみ参照（backlog.mdは読まない） - タスク完了時に
- [ ]→- [x]に更新 - グループ全タスクが
[x]になったらcurrent.mdを空にして次のグループへ
なぜ GitHub Issues ではなくファイルで管理するか
Claude Code がローカルファイルとして直接読み書きできるため、外部 API を挟まずシンプルに動きます。完了マーク（[x]）の更新も Edit ツールで完結します。
/コマンド名 で呼び出せる定型ワークフローです。
実装作業の標準フローを定義したコマンド。以下のステップを順番に強制します。
0. 準備 ブランチを main から切る
↓
Explore 実装前に仕様・既存コードを読む（ここで理解してから書く）
↓
Plan tasks/current.md にplanを追記する（影響ファイル・実装順・懸念点）
↓
Implement planの順番通りに実装する
↓
Verify quality-checker サブエージェントに委譲（lint・型・テスト）
↓
Record current.md / backlog.md の [x] を更新する
↓
PR code-reviewer サブエージェント → gh pr create
Plan を書かずに実装を始めないことが重要で、tasks/current.md に plan を書かせることで人間がレビューできる中間成果物が生まれます。
アーキテクチャ・コード品質・仕様との照合を手動で実行するコマンド。/implement の PR ステップでも自動的に呼ばれます。報告だけで終わらず修正まで行う設計です。
docs/schema.md の SQL を読んで Supabase にマイグレーションを実行する手順を定義したコマンド。ファイル名の命名規則（YYYYMMDDHHMMSS_説明.sql）を明示することで、Claude Code が自己判断で変な名前をつけるのを防いでいます。
セキュリティ観点でコードを審査するコマンド。OWASP Top 10 や Supabase の RLS 設定漏れ、API キーの露出などを確認します。問題があれば修正まで行います。
/security-review で検出した問題を修正するコマンド。修正後に再度 security-review を実行して問題がなくなったことを確認します。
docs/roadmap.md の内容をもとに次のフェーズを選び、tasks/backlog.md に追記するコマンド。実装は行わず、roadmap → backlog の移動だけを担います。
長期的な方向性を議論し、docs/roadmap.md に記録するコマンド。実装・backlog への追記は行わず、長期計画の議論と記録のためだけに使います。backlog への移動は /plan-next で行います。
競合アプリの機能比較・ユーザーニーズ・ギャップ分析を行い、docs/competitive-analysis/index.md に保存するコマンド。実装は行いません。
Claude Code は1つのセッションが長くなるとコンテキストが圧縮（auto-compact）され精度が落ちます。サブエージェントに委譲すると独立したコンテキストで動くため、メインセッションへの影響を防げます。
lint・型チェック・テストをすべてグリーンにする担当。/implement の Verify ステップで呼び出されます。
pnpm prettier→eslint --fix→tsc --noEmit→eslint --max-warnings 0→vitest runの順で実行- エラーが出たら修正して再実行を繰り返す
@ts-ignore/eslint-disable/ テスト削除は禁止- 同じエラーが3回続いたら停止して報告（無限ループ防止）
アーキテクチャ・コード品質・仕様との照合を確認し、問題があれば修正まで行う担当。PR 作成前に呼び出されます。チェック観点は /review コマンドと同一です。
ワークフロー自体の不備を修正する担当。quality-checker のループ検出・git 操作エラー・手順の不備・想定外のハマりが発生したとき、またはユーザーからフィードバックを受けたときに呼び出されます。/implement などのコマンドファイルや settings.json を直接修正します。