ロードマップ

UCHIZUのロードマップは、派手な技術を先に実装する順番ではありません。家庭が実際に登録でき、探せて、次の行動へ進めることを確認しながら、入力負担と空間表現を段階的に改善します。

審査時点の区分
写真・JAN・URL・メーカー型番・手入力から共通フォームへ進む基盤は現行機能です。写真上の場所、複数物体認識、AR、3Dは将来構想であり、提供済みとは表現しません。

進化の考え方

手入力で正しい家庭データを作れる
  → 写真で入力を短くする
  → 写真上の位置で探しやすくする
  → 認識候補で登録数を増やす
  → ARで現実空間に重ねる
  → 必要な家庭だけ3Dを選べる

手入力は古い方式として捨てるのではなく、AIが誤った時、端末が非対応の時、ネットワークがない時にも正しいデータを確定できる基礎として残します。

Track A: 登録と日常利用

A1. 共通登録基盤

状態: 現行機能・調整継続

• 写真、JAN、商品URL、メーカー・型番、手入力から開始
• 候補を共通の編集可能な確認画面へ集約
• 場所、数量、期限、購入日、購入額、保証期限を必要に応じて追加
• AIやProviderが失敗しても手入力へ戻る
• 一つのモノとして保存し、検索、在庫、保証、履歴へ反映

次の判定条件: 初回利用者が一つ目のモノを迷わず登録し、Home検索と場所一覧の両方から見つけられること。

A2. 継続更新を短くする

状態: 実装済み機能の改善領域

• 数量を一覧・詳細から更新
• 期限、保証、手入れ、収集日を家庭の予定へ反映
• 家族の更新と重複作業を減らす
• 買い物完了と在庫更新を明確につなぐ

次の判定条件: 登録後に再利用され、探す、補充、手入れ、手放しのいずれかを完了できること。

Track B: 写真から空間へ

B1. 部屋写真を「場所」として保存

状態: 構想

利用者が部屋や収納の写真を登録し、写真そのものへ名前、部屋、説明を付けます。まずは認識や3Dを使わず、利用者が正しい写真を選び、家庭の場所として保存できることを確認します。

B2. 写真上の任意位置へホットスポットを置く

状態: UI・体験構想

写真をタップし、その位置へ棚、引き出し、箱、モノの入口を登録します。タップした点から、名称、数量、期限、説明書、保証、手放しなどの情報へ進みます。

狙い: リストの正確さを保ちながら、「見た場所」から直感的に探せるようにすること。

B3. 複数物体の候補提示

状態: 構想

一枚の写真または短いスキャンから、複数のモノ候補と輪郭候補を提示します。

• 「この候補ですか」を一件ずつ確認できる
• 誤った候補を削除・訂正できる
• 検出できないモノは、その位置から手入力できる
• AI結果を自動保存しない
• 一度にすべてを登録させず、価値のあるモノから選べる

実装判断: 認識精度だけでなく、訂正にかかる時間が手入力より短いかで評価します。

B4. AR表示

状態: 構想

カメラ越しに、置き場所、モノ、期限、手入れ状態を重ねます。登録を強制するためではなく、探す時と作業する時の補助として使います。

実装判断: 対応端末、位置ずれ、暗所、家具移動、プライバシー、電池消費を実家庭で検証します。

B5. 3Dスキャンと立体管理

状態: 長期構想

対応端末の深度センサー、写真測量、端末内推定などを比較し、部屋とモノを立体的に確認する選択肢を検討します。

• 3Dスキャンを初回利用の必須条件にしない
• スキャンできない端末でも一覧と写真を使えるようにする
• 家全体ではなく、必要な部屋・収納だけを対象にできるようにする
• 生の室内データを外部へ送る範囲と保存期間を明示する
• 端末内処理、クラウド処理、精度、費用を比較する
• 有料機能にするかを含め、料金体系は利用価値と運用費を確認してから決める

3Dはインパクトを作るための装飾ではなく、写真や一覧より「探す・更新する・共有する」が明確に良くなる場合だけ採用します。

Track C: 本番品質と家族共有

C1. 物理端末検証

状態: 未検証項目あり

• iPhone・Androidのカメラ、写真、文書
• 権限の許可・拒否・再設定
• 端末カレンダーと通知deep link
• 小型・大型画面、Dynamic Type、VoiceOver、TalkBack

C2. 複数端末とRealtime

状態: Database境界は遠隔検証済み、端末間体験は未検証

• owner、editor、viewerの実アカウント運用
• 同時編集と競合回復
• offlineからの復帰
• foreground復帰時の更新
• 招待、所有権移譲、member削除

C3. Push・OAuth・削除

状態: 公開前release gate

• APNs・FCMの資格情報と物理端末2台でPushを確認
• Google Calendar OAuthの接続、取消、失敗回復を確認
• アカウント削除でAuth、Database、Storage、token、外部認可を回収
• 公開ビルドと検証記録を同じ対象へ結び付ける

Track D: 自治体データ運用

D1. 機能別coverage

状態: 継続整備

62自治体という対象数だけで完全対応を表現せず、分別、収集日、料金、拠点、備えを別々に管理します。現在の収集日判定は32自治体で直接判定、30自治体で追加条件が必要です。

D2. 更新監視

状態: 運用設計・継続実装

• 原典URL、更新日、ライセンス、取得時刻を保持
• ETag、Last-Modified、hashなどで変更を検知
• 取得失敗と更新停止を検知
• 条件が変わった自治体を再確認
• 変更が安全に反映できない間はcacheまたはunsupportedに戻す

D3. 家庭アクションへの正規化

状態: 実装済み基盤・対象拡張

公式文章をそのまま転載するのではなく、条件、結論、順番、注意、原典へ正規化します。AIは一般品目語や文章化を補助できますが、公式条件を生成しません。

Track E: 利用者検証

E1. 初回登録

確認するのは機能数ではなく、最初の一件を登録して見つけられるかです。入力時間、迷った箇所、修正回数を、同意を得たテストで確認します。

E2. 一周の完了

次のいずれかを最初から最後まで完了できるかを確認します。

• 在庫を見て補充する
• 保証や説明書を見て修理する
• 現在品と候補を比べる
• 地域の公式条件を確認して手放す
• 家族が同じ更新を確認する

E3. 継続性

モノを登録した日ではなく、後日もう一度探す、更新する、行動する理由があるかを確認します。利用実績や効果は、実測できるまでは数値として公表しません。

実装順を進める条件

次の段階	進める条件
写真ホットスポット	写真登録が一覧登録より負担を下げ、位置が後から理解できる
複数物体認識	訂正込みの所要時間が手入力より短い
AR	探す・作業する場面で位置ずれより便益が大きい
3D	対応端末、費用、プライバシーを含めても継続価値がある
本番公開	実機、複数端末、Push、削除、法務、公開ドメインのrelease gateを満たす

約束しないこと

• 3Dを実装日付きで約束しない
• 対応端末と費用を確認せず無料・有料を決めない
• AI認識率や利用者数を測定前に公表しない
• 62自治体のすべての機能が同じ深さで使えるとは表現しない
• 開発環境で動いたことを、本番・実機検証済みとは表現しない

現在の機能は機能と体験、最新の状態区分は実装状況をご覧ください。