7.1 KiB

Raw Blame History

お香アプリ展開 & インフラ構想計画書

1. 共通基盤構想: "Posimai Core"

日本酒アプリ (Ponshu Room Lite) で培った資産は、お香アプリ（仮称: Incense Room）にも80%程度流用可能です。今後のマルチアプリ展開を見据え、共通部分と個別部分を明確に分ける「プラットフォーム戦略」を提案します。

共通化できる要素 (Common Assets)

コンポーネント	日本酒 (Current)	お香 (Next)	対応方針
AI解析基盤	`GeminiService`	同サービスを使用	プロンプトのみ差し替え可能な設計にリファクタリング
カメラ/ギャラリー	`CameraScreen`	ラベル撮影	完全に共通化可能 (`CameraMode` パラメータで制御)
データ保存 (Local)	Hive (`SakeItem`)	Hive (`IncenseItem`)	共通の抽象クラス `CollectionItem` を作成し継承
ゲーミフィケーション	経験値、レベル、バッジ	全く同じ仕組み	`GamificationService` を汎用化 (例: `SakeMeter` -> `ScentMeter`判定)
設定・バックアップ	テーマ、データ移行	全く同じ仕組み	そのまま流用 (`SettingsSection` など)
UIパーツ	レーダーチャート	香りのチャート	ラベルを動的に変えられる `AttributeRadarChart` に改名して共通化

アプリ固有の要素 (App Specifics)

日本酒:
- パラメータ: 甘・辛・酸・苦・渋 (TasteStats)
- マスタデータ: 都道府県、酒米、酵母
お香:
- パラメータ: 甘味・辛味・酸味・苦味・鹹(しおから)味 (五味) またはフローラル/ウッディ等の現代的分類 (ScentStats)
- マスタデータ: 香木（白檀、沈香）、メーカー（松栄堂、日本香堂など）

技術的な移行ステップ

Core パッケージの切り出し: lib/core フォルダを作成し、汎用サービス（Gemini, Camera, DatabaseHelper, Backup）を移動。
Model の抽象化: SakeItem の親クラスとして BaseItem を定義し、ID管理や作成日などの共通フィールドを持たせる。
Flavor (Build Variants) の導入: FlutterのFlavor機能使い、1つのコードベースから Sake App と Incense App をビルドし分ける構成にするのがメンテナンス上ベストです。

2. お香アプリ (`Incense Room`) の具体的展開

AI解析の調整

お香のパッケージも日本酒ラベルと同様、OCRと画像認識で解析可能です。

Prompt設計: 「日本酒の専門家」→「お香の専門家（香司）」に変更。
抽出項目:
- 銘柄名（例: 堀川）
- メーカー（例: 松栄堂）
- 香りの系統（白檀ベース、漢薬系、モダンなど）
- 燃焼時間（パッケージにあれば）

チャートの調整

お香には古来より「六国五味（りっこくごみ）」という分類がありますが、現代人には難解です。アプリでは以下のような親しみやすいレーダーチャートを提案します：

軸案: 甘さ(Sweet) / スパイシー(Spicy) / 爽やかさ(Fresh) / 落ち着き(Calm) / 伝統(Traditional)

2.5 ゲーミフィケーション戦略: "Quiet Achiever"

「お香」のユーザーには、達成感を求める人と、静寂を求める人がいます。日本酒アプリのような派手なレベルアップ演出は逆にノイズになる可能性があります。

Selectable Mode (初回起動時に選択):
1. Collector Mode ("香道家"): バッジを集め、レベルを上げ、図鑑を埋める楽しみ。（日本酒アプリと同じ）
2. Zen Mode ("静寂"): 数値やバッジは一切隠す。記録すること自体を目的とする。
表現の工夫 (Metaphor):
- EXP: 「徳(Virtue)」や「静寂時間(Mindfulness Minutes)」として表現。
- Level Up: 派手なファンファーレではなく、ホーム画面の「香炉の煙」が少し高くなる、または「蓮の花」が開く、といった環境的な変化で表現します。

3. インフラ・環境構築のロードマップ

現在の「Direct Cloud Mode」は暫定的な正解ですが、当初の構想である「Synologyを活用した堅牢な環境」への回帰・統合も含めたロードマップを示します。

Phase 1: 現状 (Direct Cloud) - Mobile First

構成: アプリから直接 Google Gemini API へアクセス。
メリット: どこでも繋がる。設定不要。高速。
デメリット: APIキーがアプリ内に埋め込まれる（難読化はしているが）。API利用量が増えた場合のコスト管理が個人依存。
評価: スタートアップ・個人開発フェーズではこれが最適解です。まずはこれでリリースし、ユーザー体験を磨くべきです。

Phase 2: Synology Container Manager Integration - Robust & Secure

概要: Synology NASの Container Manager (Docker) を活用し、アプリのバックエンド機能を自宅でホストします。
コンテナ構成 (docker-compose):
1. posimai-db: PostgreSQL (または MariaDB)。アプリデータのマスター保存先。
2. posimai-proxy: 現在の server.py (FastAPI) をコンテナ化。APIキーをここに隠蔽。
3. cloudflared: Cloudflare Tunnel。ポート開放なしで外部から安全に上記サービスへ接続。
AI解析の場所について:
- 結論: 「Cloud (Gemini API)経由」が現状ベストです。
- 理由: Synologyで画像認識可能な高精度LLM (Llama3 Visionなど) を動かすにはGPUリソースが不足しがちで、応答速度が数秒〜数十秒かかる可能性があります。
- 役割分担:
  - スマホ: 写真撮影 & OCR前処理
  - Synology (Proxy): Geminiへのゲートウェイ（認証・ログ記録・キー隠蔽）
  - Google (Gemini): 重い解析処理 (高速)

Phase 3: Private AI Agent (Future)

構想: 将来的にSynologyのスペックが向上、または軽量高性能モデルが登場した場合。
実装: Ollama コンテナを追加し、posimai-proxy の宛先を Gemini から Ollama に切り替えるだけで移行可能です。

4. 結論 & 提案

まずはお香アプリのプロトタイプを 「Flavor機能を使った派生アプリ」 として立ち上げることをお勧めします。インフラに関しては、今のDirect Cloudで利便性を確保しつつ、次のステップとして Cloudflare Tunnel の導入を検討リストに入れておくのが良いでしょう。

この方針で進める場合、次は「お香アプリ用の要件定義（パラメータ決め）」または「コードの共通化リファクタリング」から着手できます。

7.1 KiB Raw Blame History Unescape Escape