UCHIZU ホワイトペーパー

0. この文書について

本書は、審査員、自治体、開発協力者が、UCHIZUの価値と現在地を同じ基準で確認するための技術・サービス説明です。構想を魅力的に見せることより、実装済み、限定対応、遠隔検証済み、公開版未検証、将来構想を混同しないことを優先します。

1. 要約

UCHIZUは、家の中の場所とモノを記録し、家庭の事実と地域の公式情報から「次に何をするか」へつなぐ家庭向けデジタルツインです。

家の事実
  + モノの事実
  + 設定地域の公式情報
  = 家庭ごとの次の行動

単なる在庫台帳ではなく、探す、補充する、手入れする、修理する、買い替える、売る・譲る、正しく捨てるまでを一つのライフサイクルとして扱います。

2. 解こうとしている課題

暮らしの情報は存在していても、「わが家の場合はどうするか」へ変換するためには複数の断片をつなぐ必要があります。

• モノの正式名称や型番が分からない
• 家のどこに置いたか、残数がいくつか分からない
• 期限、保証、手入れ時期が別々に管理されている
• 自治体ごとに分別、収集、申込、回収拠点の形式が違う
• 買い替え候補と現在品の条件が分離している
• 家族の誰かが対応したか分からない
• 公式ページへ到達しても、必要な条件と手順を読み直す必要がある

既存のメモ、カレンダー、EC、行政サイトはそれぞれ役立ちますが、家庭固有の場所・モノ・履歴を共通の文脈として持ちません。UCHIZUは、その接続部分をプロダクトの中心に置きます。

3. プロダクト原則

3.1 Home × Things × Action

Homeはメニューではなく、家庭の判断を始める入口です。場所とモノの記録を行動に接続できない機能は、優先しません。

3.2 Local first

クラウド、AI、商品Providerが未設定でも、ゲスト利用、手入力、検索、ローカル保存を残します。外部サービスの障害を、家庭の基本台帳の停止へ波及させません。

3.3 AI is suggestion, official data is evidence

AIは候補と文章化を支援します。自治体の分別、収集日、料金、安全性は作りません。公式情報が不足する場合は、unsupportedとして原典確認へ戻します。

3.4 3D before valueではなく、value before 3D

立体表示そのものを目的にしません。まず手入力と写真で、登録の負担が減るか、探せるか、行動につながるかを確認します。その後、写真上の位置、認識支援、AR、3Dへ段階的に進みます。

4. 主要な利用体験

4.1 初回利用

1. サンプルの家を見て、サービスの使い方を理解する
2. ゲストのまま試すか、クラウド利用を選ぶ
3. 自分の家、地域、必要な場所だけを登録する
4. 写真、JAN、URL、型番、手入力から最初のモノを登録する

初回から家全体の入力や3Dスキャンを要求しません。一つのモノ、一つの置き場所から価値を確認できることを優先します。

4.2 探す

Homeから名称を検索するか、部屋から置き場所をたどります。場所、数量、期限を同時に見せ、買い物中にも「あるか」「何個か」を確認できる状態を目指します。

4.3 登録する

複数の入口を共通確認フォームへ集約し、認識結果を修正できます。保存されるのはAIの回答ではなく、利用者が確認した家庭の事実です。

4.4 維持する

数量、期限、保証、手入れ、修理をモノ単位で更新します。カレンダーと通知は、一般的な予定ではなく家庭の行動を扱います。

4.5 手放す

売却、譲渡、回収、自治体収集の選択肢を整理し、公式条件がある場合は確認質問、判定、順番、注意、原典を提示します。

5. 情報モデル

5.1 場所階層

Profile
  └─ Household membership
       └─ Home
            └─ Room
                 └─ Furniture / Storage location
                      └─ Item

モノは必ずしも家具の中にあるとは限らないため、部屋を必須とし、家具・収納は任意にできるモデルです。画面では「部屋 → 置き場所 → モノ」を短くたどり、内部モデルの柔軟性を保ちます。

5.2 モノ

モノは名称だけでなく、次の行動に必要な事実を保持します。

種類	主な項目
識別	名称、カテゴリ、メーカー、型番、JAN、URL
場所	家、部屋、家具・収納、置き場所
在庫	数量、単位、補充目安、期限
購入・保証	購入日、購入額、店舗、保証期限、レシート
文書	説明書、保証書、修理記録
状態	使用中、保管中、手入れ必要、手放し候補など
履歴	清掃、点検、修理、交換、移動、処分

5.3 関連モデル

• 買い替え候補は現在品IDへ紐付ける
• 価格snapshotはProvider、取得時刻、demo状態を持つ
• ごみ・資源情報は自治体、原典、更新日、取得状態を持つ
• メモと予定はモノ、場所、家庭内役割、公式ルールのいずれかに関連付ける
• 写真と文書は世帯IDとモノIDを持ち、非公開Storageで扱う

6. システム構成

Expo / React Native / Expo Router
  └─ Screen and route state
       └─ App state / Repository boundary
            ├─ Local persistence for guest and offline use
            └─ Supabase
                 ├─ Auth
                 ├─ PostgreSQL + Row Level Security
                 ├─ Private Storage + signed URL
                 └─ Edge Functions
                      ├─ AI provider
                      ├─ Product provider
                      └─ Controlled external fetch

Verified official datasets
  └─ normalized records + source metadata + cache state
       └─ household-specific action result

6.1 Repository boundary

画面はモック配列やDatabaseを直接変更せず、アプリ状態とrepositoryを通します。これにより、ゲストのローカル保存からSupabaseへ移行しても、画面の責任を増やしすぎず、外部サービス停止時のfallbackを保てます。

6.2 Supabase

クラウドを選んだ世帯では、Auth、PostgreSQL、Storageを利用します。RLSはowner、editor、viewer、世帯外利用者の境界をDatabase側で制御します。クライアント表示だけで権限を隠す設計にはしません。

6.3 Edge Functions

OpenAIや商品Providerの秘密鍵、制御されたURL取得、削除など、クライアントへ置けない処理を担当します。secretは環境変数で管理し、Gitやアプリbundleへ入れません。

6.4 外部サービスの任意性

AI、価格、OAuth、Pushが失敗しても、手入力、ローカル保存、アプリ内一覧、公式原典へ戻ります。取得できなかった値を見栄えのために補完しません。

7. オープンデータを行動へ変換する

7.1 採用基準

データセットは、公開されているだけでは採用しません。

1. 設定地域または登録済みのモノで結果が変わる
2. 家庭が次に取る行動へ変換できる
3. 提供元、更新日、ライセンス、原典を保持できる
4. 不足時に安全なfallbackを定義できる

7.2 表示順

結論
  → 判定に使った条件
  → 必要な行動の順番
  → 注意事項
  → 提供元・更新日・原典

原典を隠しませんが、利用者へ最初から資料の読解を委ねません。

7.3 coverage

自治体台帳は東京都内62自治体を対象にしますが、収集日、分別、料金、拠点は別の機能です。現在の収集日判定は32自治体で直接判定、30自治体で追加条件が必要という区分を持ちます。粗大ごみ料金は公式条件を確定できる品目だけ表示します。

8. AIガバナンス

8.1 利用する場面

• 写真から品目候補を作る
• メーカー・型番候補を作る
• 公式データ検索用の一般品目語を提案する
• 文章を読みやすくする
• 売却・譲渡文の下書きを作る

8.2 利用しない場面

• 自治体ルール、収集日、料金の生成
• 施設の開設、安全、最寄りの断定
• live価格、在庫、配送の生成
• 利用者に代わる購入、出品、削除、同意

8.3 記録

AI候補は候補として扱い、利用者の修正経路を残します。公式判定と同じフィールドや表示状態へ混ぜません。

9. セキュリティとプライバシー

9.1 最小送信

クラウド、AI、商品検索は利用者がその機能を選んだ時だけ送信します。カメラ、写真、通知の権限も利用場面で求めます。

9.2 世帯アクセス制御

membershipとRLSで世帯を分離し、写真・文書は非公開Storageと短時間URLで表示します。2026年8月26日の遠隔自動検証では、4つの一時利用者役割、Database、Storage、招待、削除境界を確認しました。

9.3 削除と持ち出し

JSON書き出しと再取り込みを持ち、アカウント削除ではAuth、Database、membership、招待、Storageを対象にします。遠隔検証で残留0件を確認していますが、公開ビルド、物理端末、外部認可の最終確認は残っています。

詳しくはAI・セキュリティ・プライバシーをご覧ください。

10. 開発方法

10.1 画面仕様を正本化する

一つの画面に複数の過去案を混ぜず、現在承認された画面と状態遷移を正本にします。Home、場所、登録、カレンダー、通知、メモ、処分などを画面単位で実装し、過去案との互換性のために古いUIを残しません。

10.2 小さく分離して変更する

• アプリ、公開デモ、審査資料を分離する
• 一つの変更で触る経路を限定する
• 既存の利用可能な導線を壊さない
• 外部サービスがなくても動くfallbackを同時に持つ
• サンプル、demo、cache、liveをデータと表示の両方で区別する

10.3 証拠の段階を分ける

段階	意味
仕様	文書・画面案がある
実装	コードと導線がある
ローカル検証	Web、simulator、開発環境で確認
遠隔自動検証	設定済みremote環境で一時データを用いて確認
実機検証	物理iPhone・Androidで確認
公開版検証	対象ドメイン・対象build・外部契約を含めて確認

一つ前の段階を、次の段階の証拠として表現しません。

10.4 UI確認

モバイル画面は390×844を基準に、構造、文言、操作、状態遷移、空状態、キーボード・安全領域を確認します。色だけを合わせて完成とはしません。

10.5 自動確認と人の確認

型、lint、Expo設定、単体・導線テスト、RLS・Storageの遠隔スクリプトを使います。一方、実メール、実機権限、Push、法務、自治体原典の解釈など、人と実環境が必要な確認は別のrelease gateとして残します。

11. 差別化

比較対象	UCHIZUの違い
一般的な在庫アプリ	置き場所だけでなく、保証、手入れ、買い替え、手放しまで同じモノに紐付く
メモ・カレンダー	予定やメモが家、場所、モノ、公式ルールに関連付く
EC検索	現在品、家庭の在庫、設置場所、保証を起点に候補を比較する
行政サイト	設定地域と登録済みのモノから、条件と手順を家庭向けに並べる
一般的な生成AI	継続する家庭データと公式出典を持ち、推測してはいけない境界を定義する
3Dデジタルツイン	高価なスキャンを初回条件にせず、一覧と写真から段階的に空間体験へ進む

12. 現在の限界

• 自治体ごとに公開形式、更新頻度、判定条件が異なる
• 全品目の料金や収集日をアプリ内で確定できるわけではない
• 回収拠点の当日受付、営業時間、在庫を保証しない
• AI候補は誤るため、利用者確認が必要
• 商品のlive価格は正式Provider接続時だけ利用できる
• 物理端末2台のRealtime・Push・競合回復は未検証
• Google・Apple連携、法務、ストア申告には公開前のrelease gateが残る
• 写真上の場所、AR、3Dは構想であり、現在の提供機能ではない

13. 次の段階

優先順位は、機能を増やすことより、次の一周を短く、正確に、繰り返せるようにすることです。

登録する
  → 探せる
  → 家庭の状態が分かる
  → 公式情報と照合する
  → 次の行動を完了する
  → 履歴が次回の判断に使われる

写真上の場所、認識支援、AR、3Dを含む将来計画はロードマップ、機能ごとの現在地は実装状況をご覧ください。