17 KiB
17 KiB
今後の開発構想 - 2026年版
作成日: 2026-02-23 ステータス: 日本酒アプリ完成記念 - 次のフェーズへ 対象: Maita + Eiji(共同開発者) + AI協力者(Claude, Antigravity, Gemini)
🎉 現状: 最初の完成品達成
日本酒アプリ - 配布準備完了
ビルド完了日時: 2026-02-23
出力先: build/apk_releases/2026-02-23_13-17-01/
配布ファイル一覧:
├── ponshu_room_lite_maita.apk (90MB) - Maita用 Lite版
├── ponshu_room_lite_eiji.apk (90MB) - Eiji用 Lite版
├── ponshu_room_pro_maita.apk (90MB) - Maita用 Pro版
└── ponshu_room_pro_eiji.apk (90MB) - Eiji用 Pro版
重要な達成:
- ✅ 初の「完成品」として配布可能状態
- ✅ 2ユーザー × 2バージョン = 4種類のビルド自動化
- ✅ 各APIキーが正しく埋め込まれている
- ✅ Pro/Liteの判定ロジック実装済み
🧭 基本方針: Antigravity + Claudeの合意事項
両AIが強く推奨する原則:
1. 完成品1個 > プロトタイプ10個
過去の反省:
- 「中途半端なプロジェクト」が量産されてきた
- 原因: 新ツールに飛びつき、完成前に次へ移行
今後の鉄則:
- 並行開発の禁止 - 一度に1プロジェクトのみ
- 80%で出荷 - 完璧主義からの脱却
- 明確な完成定義 - 「配布可能」「収益化可能」を基準
2. 新ツール導入の判断基準
追加しない:
- 「便利そう」「流行っている」だけのツール
- 学習コストに見合わないもの
- 既存ツールで代替可能なもの
追加する:
- 「これがないと進まない」明確な理由がある
- ROI(投資対効果)が証明できる
- 具体的なユースケースが存在する
3. AI活用の最適化
| ツール | 用途 | 優先度 | 月額コスト |
|---|---|---|---|
| Claude Code | コード実装、リファクタリング | 🔴 継続 | $20 |
| Antigravity | 自律開発、インフラ構築 | 🔴 継続 | 実績あり |
| Cursor | IDE、デバッグ | 🔴 継続 | $20 |
| Gemini Pro | 設計レビュー、壁打ち | 🟡 活用 | $0-20 |
| Lovable/Bolt.new | プロトタイプ | 🔵 保留 | 必要時 |
| Dify | AIワークフロー | 🔵 保留 | 未定 |
合計月額: $40-60 (現状維持)
📂 プロジェクト構造の最適化
現状の課題
C:\Users\maita\posimai-project\
├── ponshu_room_lite/ # 日本酒アプリ(Lite版)
├── mai_quick_scan/ # スキャンアプリ
├── m-ai-dashboard/ # ダッシュボード試作
├── article-keeper/ # 記事管理?
├── package_ar_info/ # 不明
└── _conoha/ # インフラ関連
問題点:
- 「どれが現役か」が不明確
- 共通ロジック(AI解析/OCR)が重複
- PCのディスク/メモリを圧迫
推奨構造 (Synology + ローカルの二層構成)
Synology側 (/volume1/projects/posimai/)
/volume1/projects/posimai/
├── 00_core/ # 共通資産
│ ├── ai_analysis/ # AI解析(Gemini API wrapper)
│ ├── ocr_engine/ # OCRロジック
│ ├── stripe_integration/ # Stripe決済
│ └── ui_design_system/ # Flutterの共通UIコンポーネント
│
├── 01_active/ # 現在開発中(1つのみ!)
│ └── (次のプロジェクト)
│
├── 02_archive/ # 完成品・参照用資産
│ ├── ponshu_room_lite/ # ✅ 日本酒アプリ(完成)
│ ├── mai_quick_scan/ # スキャンロジック参照用
│ └── m-ai-dashboard/ # ダッシュボードUI参照用
│
├── 03_infrastructure/ # インフラコード
│ ├── docker/
│ │ ├── postgres.yml # PostgreSQL
│ │ └── n8n.yml # n8n(必要時)
│ ├── backup_scripts/
│ └── tailscale_config/
│
└── .ai_context/ # AI向けドキュメント
├── architecture.md # 全体設計
├── coding_standards.md # コーディング規約
└── project_history.md # 各プロジェクトの経緯
ローカルPC側 (C:\Users\maita\posimai-project)
C:\Users\maita\posimai-project\
└── current_project/ # 現在開発中の1つだけ
└── (Synologyの 01_active とSMB/SFTP同期)
運用方法:
- 開発中: ローカルPCで作業
- 完成時: Synologyの
02_archive/へ移動 - 次のプロジェクト:
01_active/に新規作成→ローカルに同期
メリット:
- PCの負荷削減(現役プロジェクトのみ)
- 過去プロジェクトはSynologyで保全
- Tailscale経由でどこからでもアクセス可能
🎯 今後12週間のロードマップ
Week 1-2: 日本酒アプリのフィードバック収集
アクション:
- ✅ EijiへAPK配布 (完了)
- ⏳ 実際に使用してもらい、フィードバック収集
- ⏳ バグや使いにくい点の洗い出し
成功基準:
- 「これは使える」という肯定的評価
- 致命的なバグがないこと
- 次バージョンの優先機能が明確化
Week 3-4: Synology環境の最小構築
Phase 1: PostgreSQL + pgAdmin (推定4-6時間)
手順:
# SynologyにSSH接続
ssh admin@synology.local
# プロジェクトディレクトリ作成
mkdir -p /volume1/projects/posimai/03_infrastructure/docker
cd /volume1/projects/posimai/03_infrastructure/docker
# docker-compose.ymlを作成 (以下の内容)
version: '3.8'
services:
postgres:
image: postgres:16-alpine
container_name: posimai_db
environment:
POSTGRES_DB: posimai_brain
POSTGRES_USER: ${DB_USER:-admin}
POSTGRES_PASSWORD: ${DB_PASSWORD}
volumes:
- postgres_data:/var/lib/postgresql/data
ports:
- "5432:5432"
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${DB_USER:-admin}"]
interval: 10s
timeout: 5s
retries: 5
pgadmin:
image: dpage/pgadmin4:latest
container_name: posimai_pgadmin
environment:
PGADMIN_DEFAULT_EMAIL: ${ADMIN_EMAIL:-admin@posimai.local}
PGADMIN_DEFAULT_PASSWORD: ${ADMIN_PASSWORD}
ports:
- "5050:80"
depends_on:
- postgres
restart: unless-stopped
volumes:
postgres_data:
# .envファイル作成
cat > .env << 'EOF'
DB_USER=admin
DB_PASSWORD=YOUR_SECURE_PASSWORD_HERE
ADMIN_EMAIL=admin@posimai.local
ADMIN_PASSWORD=YOUR_ADMIN_PASSWORD_HERE
EOF
# 起動
docker-compose up -d
# 動作確認
docker-compose ps
検証:
- Tailscale経由で
http://synology:5050にアクセス - pgAdminで
posimai_brainデータベースが見えること
この時点では、まだ何もデータは入れない
Week 5-8: 共通資産の抽出
目的: 過去プロジェクトから再利用可能なロジックを抽出
対象プロジェクト:
mai_quick_scan→ AI解析・OCRロジックm-ai-dashboard→ ダッシュボードUI- (RFM分析) → データ分析ロジック
作業内容:
# Synology上で
cd /volume1/projects/posimai/00_core
# スキャンアプリからAI解析部分を抽出
mkdir -p ai_analysis
# Antigravityに「mai_quick_scanからGemini API呼び出し部分を抽出してai_analysis/に配置して」と指示
# OCR部分を抽出
mkdir -p ocr_engine
# 同様に抽出
# ダッシュボードUI を抽出
mkdir -p ui_design_system
# 共通化可能なFlutterウィジェットを抽出
成功基準:
- 次のプロジェクトで
importして使える状態 - ドキュメント化されている(README.md)
- サンプルコードがある
Week 9-12: 次のプロジェクト選定と開発
候補(優先度順):
A. 専用ダッシュボード (Geminiが推奨、要件明確化が必要)
前提条件:
- Week 1-2のフィードバックで「こういうデータが欲しい」が明確
- PostgreSQLにデータソースが準備済み
要件定義必須項目:
- 誰が使う? (社長 / Maita / Eiji / 全員?)
- 何を表示? (日本酒の統計? 業務データ? AIツール管理?)
- どこで見る? (PC / スマホ / 両方?)
- 更新頻度? (リアルタイム / 日次 / 週次?)
技術スタック:
- フロント: Flutter Web or React(Lovable生成 → カスタマイズ)
- バックエンド: Synology PostgreSQL
- 自動更新: n8n (この時点で初めて導入)
B. 香道アプリ (日本酒アプリの技術流用)
メリット:
- 既存の
00_core/をフル活用 - 開発速度が速い(AI解析ロジック流用)
- 日本酒アプリのノウハウがそのまま使える
差分:
- データモデル:
SakeItem→KohItem - 解析プロンプト: 日本酒 → 香木
- UI: ほぼ流用可能
C. kintoneプラグイン(収益化案件)
条件付き:
- 具体的な顧客要望がある場合のみ
- 収益化の見込みが立っている
💡 Gemini提案への対応方針
採用するもの
| Gemini提案 | 採用理由 | 実施時期 |
|---|---|---|
| SynologyをマスターDBに | クラウド依存排除、正しい | Week 3-4 |
| kintone主軸から外す | ロックイン回避、賢明 | 既に実施 |
| 共通ライブラリ化 | コード再利用、正解 | Week 5-8 |
| PostgreSQL採用 | 拡張性高い、妥当 | Week 3-4 |
保留・慎重に検討するもの
| Gemini提案 | 懸念点 | 対応方針 |
|---|---|---|
| Lovable/Bolt.new | プロトタイプ止まり、コスト | 要件明確後に検討 |
| Dify | ユースケース不明 | 具体的な必要性まで保留 |
| ダッシュボード最優先 | 要件が曖昧 | フィードバック後に判断 |
| ツール大量導入 | 学習コスト・月額費用 | 必要性が証明されてから |
却下するもの
| Gemini提案 | 却下理由 |
|---|---|
| 「爆速で数分で完成」 | 現実離れ、プロトタイプ≠完成品 |
| Antigravity誤認 | AntigravityはGoogleではなく既に使用中 |
| 並行開発 | 過去の失敗パターンの繰り返し |
🔧 技術スタックの固定
採用技術(変更しない)
フロントエンド:
- Flutter (モバイルアプリ)
- React (Web、必要時のみ)
バックエンド:
- Synology PostgreSQL (データストア)
- n8n (必要になってから導入)
インフラ:
- Synology NAS (自宅サーバー)
- Tailscale (VPN)
- Docker (コンテナ管理)
AI:
- Gemini API (AI解析)
- Claude Code (コード生成)
- Antigravity (自律開発)
- Cursor (IDE)
決済・連携 (収益化時):
- Stripe (決済)
- Mailgun (メール送信)
導入検討中(必要性が明確になってから)
- Lovable/Bolt.new (Webプロトタイプ)
- Supabase (セルフホスト、Auth機能が必要な場合)
- Firebase (マルチデバイス同期が必要な場合)
📊 成功指標 (KPI)
完成品の定義
以下を全て満たすものを「完成品」とする:
- 配布可能: APK/Webが一般ユーザーに渡せる
- 致命的バグなし: クラッシュしない、データ損失しない
- ドキュメント化: README + ユーザーガイド存在
- バックアップ済み: Synologyに保存、Gitで管理
- 次へ進める: フィードバック収集して次のタスクへ
12週間後の達成目標
- ✅ 日本酒アプリ: 配布完了、フィードバック反映、v2.0リリース
- ✅ Synology環境: PostgreSQL稼働、バックアップ体制確立
- ✅ 共通資産化: AI解析・OCRロジックが
00_core/で再利用可能 - ✅ 次のプロジェクト: 要件定義完了、開発開始 or 初期プロトタイプ完成
🚫 やらないことリスト
Antigravity + Claudeの合意事項:
- 並行開発禁止 - 一度に複数プロジェクトを動かさない
- 新ツール衝動買い禁止 - 「便利そう」だけで導入しない
- 完璧主義禁止 - 80%完成で出荷、フィードバックで改善
- ツールコレクター化禁止 - 学習コストを軽視しない
- クラウド依存禁止 - Synologyで自己管理できるものは自前で
🤝 AI協力体制
役割分担
| AI | 主な役割 | 使用タイミング |
|---|---|---|
| Claude Code | コード実装、リファクタリング、レビュー | 開発全般 |
| Antigravity | 自律開発、インフラ構築、複雑タスク | 環境構築、大規模変更 |
| Cursor | IDE統合、デバッグ、コード補完 | 日常的な開発 |
| Gemini Pro | 設計レビュー、壁打ち相手、批判的思考 | 方針決定時 |
協議プロセス
重要な判断時:
- Geminiに構想を投げて壁打ち
- Claude/Antigravityで批判的レビュー
- Maitaが最終判断
- Eijiと共有、合意形成
📝 次のアクション(今すぐ)
Week 1 (今週中)
- Eijiに4つのAPKを配布 - Google DriveまたはSynology File Station
- README作成 - インストール方法、使い方
- フィードバックフォーム - Google FormsまたはNotionで簡易作成
- .cursorrules作成 - AI向けの開発ガイドライン
.cursorrules の例
# Posimai Project - AI開発ガイドライン
あなたはposimaiの専属開発パートナーです。
## 基本原則
- 一度に一つのプロジェクトに集中してください
- 新しいツール提案より、既存コードの完成を優先してください
- Synology・Flutter・kintone(収益案件のみ)が技術スタックです
- 「完成品1個 > プロトタイプ10個」を常に意識してください
## 技術スタック
- フロント: Flutter (主力), React (Web必要時)
- バックエンド: PostgreSQL (Synology)
- AI: Gemini API
- インフラ: Synology NAS + Tailscale
- 決済: Stripe (収益化時)
## コーディング規約
- Dartは`flutter_riverpod`でstate管理
- 共通ロジックは`00_core/`に配置
- 新機能追加前に、既存の`00_core/`で代用できないか確認
- `// TODO:`ではなく、PROJECT_TODO.mdに記載
## 禁止事項
- 並行開発の提案
- 学習コストが高い新ツールの安易な推奨
- 完璧主義による実装遅延
- クラウド依存の安易な導入
## 完成の定義
- 配布可能なAPK/Web
- 致命的バグなし
- README + ドキュメント存在
- Gitコミット + Synologyバックアップ
🔮 長期ビジョン(6ヶ月後)
「Posimai Core Platform」構想
複数のアプリが共通基盤を使う状態:
Posimai Core Platform (00_core/)
├── AI Analysis Engine
├── OCR Engine
├── Stripe Integration
├── UI Design System
└── User Auth Module
↓ 活用する各アプリ
- Ponshu Room (日本酒) ✅ 完成
- Koh Room (香道) 🚧 開発予定
- Mai Quick Scan (汎用スキャン) 🔄 リファクタ
- Analytics Dashboard (データ分析) 💡 構想中
- (kintoneプラグイン) 💰 収益化案件のみ
目標:
- 新アプリ開発が2-3週間で可能
- コアロジックは1度書けば全アプリで使える
- 収益化の選択肢が複数ある
🎓 学んだ教訓
成功パターン
- 明確な完成定義 - 「配布可能」というゴール設定
- 段階的構築 - 一度に全てやらない
- AI活用の分業 - 各AIの得意分野を活かす
- 既存投資の活用 - 有料ツール($40/月)を使い倒す
失敗パターン(繰り返さない)
- 新ツール衝動買い - 学習コストで時間浪費
- 並行開発 - 全て中途半端に
- 完璧主義 - いつまでも出荷できない
- 要件不明確 - 「何となく作る」で詰まる
📌 まとめ
現在地
✅ 日本酒アプリ完成 - 初の「完成品」として配布可能
次の3ヶ月
- フィードバック収集 → 改善
- Synology環境構築 → データ基盤確立
- 共通資産化 → 次への土台
- 次のプロジェクト開始 → 2つ目の完成品へ
AI活用方針
- Claude Code + Antigravity + Cursor = 既存継続($40/月)
- Gemini = 壁打ち相手(Pro範囲内)
- 新ツールは必要性が証明されてから
成功の鍵
「一つずつ完成させる」 「80%で出荷、フィードバックで改善」 「完成品1個 > プロトタイプ10個」
次回レビュー: 2026-03-23 (1ヶ月後) レビュー項目:
- 日本酒アプリのフィードバック状況
- Synology PostgreSQL稼働状況
- 共通資産化の進捗
- 次のプロジェクト選定結果