ビル状態管理ポータルの開発をAIの力を借りながら進めてきた記録です。個人開発初学者として、どんな流れで何をやってきたかをまとめます。
Contents
このアプリは何を作っているのか
ビルの「今の状態」をリアルタイムで共有し、AIが次に起きることを予測するWebアプリです。
あるビル管理会社では、設備・清掃・インシデント・入退館の状態を社員と入居者が共有できる仕組みが必要でした。さらに過去の履歴データをもとに、LLM（大規模言語モデル）が「次に何が起きそうか」を予測・アドバイスする機能を目指しています。
技術スタック（使っているもの）
| 技術 | 役割 |
|---|---|
| Next.js 16 + React 19 + TypeScript | フロントエンド（画面） |
| Supabase（PostgreSQL） | データベース ＋ リアルタイム同期 |
| Tailwind CSS v4 | スタイル（デザイン） |
| Anthropic API（Claude） | LLM予測機能（Phase 3で実装予定） |
| Vercel | フロントエンドのホスティング予定 |
| Render + FastAPI | バックエンドのホスティング予定 |
開発の流れ（ここまでの時系列）
🟢 Phase 0：構想・設計（Claudeチャットで）
まずスマホのClaudeチャットで「何を作るか」を言語化しました。
- クライアント企業のAI活用方針の整理
- 技術スタックの選定（Next.js / Supabase / FastAPI / ローカルLLM）
requirements.md（要件定義書）の作成
ポイント： いきなりコードを書かず、まず「何を作るか」を文書にしました。この要件定義書がこの後の全作業の羅針盤になっています。
🔵 Phase 1-A：プロジェクト初期セットアップ
MacBook AirのCursorで、Claude Codeに指示を出してプロジェクトを作成しました。
create-next-app で以下の設定で作成：
・TypeScript
・Tailwind CSS
・App Router（Next.jsの現在の標準）
なぜこの3つか： TypeScriptは型安全でAIが補完しやすい、TailwindはスマホUIが素早く作れる、App RouterはNext.jsの現在の標準構成だからです。
作成されたファイル構成：
tenssho-portal/
├── src/app/
│ ├── globals.css
│ ├── layout.tsx
│ └── page.tsx
├── next.config.ts
├── requirements.md ← 要件定義書
└── CLAUDE.md ← Claude Code用メモ
🔵 Phase 1-B：Supabaseのセットアップ
データベースをコードより先に作りました。理由は「DBがないと画面を作っても動作確認できない」からです。
やったこと：
- Supabaseアカウント作成（GitHub連携・無料）
- プロジェクト作成（リージョン：Tokyo）
.env.localに接続情報を設定@supabase/supabase-jsをインストール- SQLエディタで3つのテーブルを作成・サンプルデータ投入
作成したテーブル：
| テーブル | 内容 |
|---|---|
buildings | ビルマスタ（3棟のサンプルデータ） |
statuses | 各ビルの現在の状態（カテゴリ・正常/異常/対応中） |
status_history | 状態変化の履歴（LLMへのコンテキストに使う） |
Realtimeも両テーブルで有効化しています（リアルタイム同期のため）。
🔵 Phase 1-C：型定義とSupabase接続コード
Claude Codeが生成した型定義が品質高く完成しました。
type StatusValue = '正常' | '異常' | '対応中'
type Category = '設備系' | '清掃系' | 'インシデント系' | '入退館系'
type Building = { id: string; name: string }
type Status = { id: string; building_id: string; category: Category; ... }
type StatusHistory = { ... }
🔵 Phase 1-D：社員向けトップ画面の実装
ビル一覧を表示するトップページ（/）が完成しました。
実装内容：
- Server ComponentでSupabaseからビル一覧を直接取得（APIルート不要）
- ビルをカード形式で表示（アイコン・名前・カテゴリバッジ）
- カードをクリックで
/buildings/[id]へ遷移 grid-cols-1 sm:grid-cols-2 lg:grid-cols-3でスマホ対応
現在の状況（実装済み・未実装）
✅ 完成済み
src/app/page.tsx— ビル一覧トップ画面src/app/layout.tsx— ルートレイアウトsrc/lib/supabase.ts— Supabaseクライアント（型付き）src/types/index.ts— 全テーブルの型定義supabase/schema.sql— DBスキーマ＋サンプルデータ（投入済み）.env.local— Supabase接続情報設定済み
❌ 未実装
/buildings/[id]— ビル詳細画面（状態一覧・更新・履歴・LLM予測）/resident— 入居者向けトップ/resident/buildings/[id]— 入居者向け状態表示（読み取り専用）- LLM予測機能（「予測を見る」ボタン → FastAPI → Claude）
開発フェーズ全体像
Phase 1（状態共有ポータル） ← 今ここ
└── トップ画面のみ完成。ビル詳細が次の課題
Phase 2（履歴管理）
└── DBスキーマ完成・UI未実装
Phase 3（LLM予測エージェント）
└── 未着手。FastAPI + Claude APIで実装予定
開発で使ったAIツールたち
| ツール | 用途 |
|---|---|
| Claudeチャット（このアプリ） | 構想・設計・技術選定・進め方の相談 |
| Cursor + Claude Code | 実際のコード生成・ファイル操作 |
| Cowork（デスクトップ） | ファイルをまたいだ複合作業（今後活用予定） |
学んだこと・気づき
要件定義書を最初に作ることが全体の精度を上げる。 Claude Codeはプロジェクト内の requirements.md を読んで作業するため、仕様が文書化されているほど、生成コードの方向性がズレない。
DBは画面より先に作る。 接続情報がないと .env.local が設定できず、画面を作っても動作確認ができない。「動くものが見える状態」を早く作ることがモチベーション維持につながる。
LLMはローカルでも展示用なら十分。 Anthropic APIは従量課金だが、MacBook AirのOllama（ローカルLLM）で展示用なら追加コストゼロで動かせる。本番運用時に切り替えればいい。
次のステップ
/buildings/[id]（ビル詳細画面）の実装。これが完成すれば「動くデモ」として見せられる状態になります。
開発環境：MacBook Air / Cursor / Claude Code / Supabase / Next.js 16
