🏠 概要

アクションと主要 KPI のスナップショット。詳細は左メニューから各タブへ。

🚨 今やるべきこと — アクションが必要か？

📊 スナップショット

💰 ビジネス

本リリース前なので現状の数値はテストデータです。ここではシナリオ計算 (preset = 悲観 / 標準 / 楽観) で計画値を確認します。
現状の実績は技術 / コストタブで参照できます。

🎯 ファネル EV シミュレータ — Trial1 (14日) → Paywall → Trial2 (14日) → 自動課金

新フロー (Free プランなし): install → Trial 1 (14日無料・CC不要) → Paywall → Trial 2 (14日無料・CCあり) → 自動課金 → 月次 churn で減衰
恒久無料ユーザーは存在しない。Trial 1 のコストは全 install 分を自社負担。
レバー: 価格設計 (月額 / 年額比率 / 年額割引) × Organic 比率 × Funnel 品質 × ステージ別 CAC/install。

Paywall 承認率 10%

Trial2→課金転換率 55%

月額 churn 7%

C_premium / 日 ¥3.0

💰 価格設計

月額価格 ¥490

年額プラン比率 0%

年額割引 17%

年額 churn 3.0%

📣 獲得構成

Organic 比率 0%

平均購読月数

1 paying user / 月営業利益

LTV (paying)

自社負担 Trial コスト / install

EV per Paywall 承認

EV per install (CAC 前)

↓ CAC / install は次のステージ別パネルで設定

🛤 ステージタイムライン — Pre-Seed 6ヶ月 → Seed 6ヶ月 → Series-A 24ヶ月 (合計 36ヶ月)

🌱 Pre-Seed 0-6 ヶ月

X (Promoted) + PR + organic / PMF 検証

CAC / install ¥150

月間 install 200

月予算 ¥30,000

🌿 Seed 6-12 ヶ月

Meta + X + 小規模インフル / Unit economics

CAC / install ¥300

月間 install 3,000

月予算 ¥900,000

🌳 Series-A 12-36 ヶ月

Meta + Google + TikTok + インフル年契 / シェア取り

CAC / install ¥600

月間 install 15,000

月予算 ¥9,000,000

📊 ステージ別メトリクス — 同じ funnel 品質で、ステージ毎の経済性

ステージ	CAC	install/月	実効 CAC / paying	LTV / CAC	Payback	新規 paying / 月	定常月次 OP

📈 36ヶ月収益シミュレーション — ステージ遷移付き。何ヶ月で黒字化？

月次営業利益 (¥/month)

悲観標準楽観 ★ 現在 break-even (¥0)

累積営業利益 (¥)

悲観標準楽観 ★ 現在

36 ヶ月後の到達点

前提: ステージごとに install / CAC が切り替わる。Trial1 (14日全員) + Trial2 (14日 acceptors) の翌月から課金開始。月次 churn で active が減衰。

🚀 プロダクト

ユーザーの増減、定着、AI 精度、フィードバックの集約。

🚀 成長 — ユーザーは増え、定着しているか？

📅 直近14日の新規登録

🔁 リテンション (Day1/7/30)

コホート	サンプル数	残存	残存率

N 日前に登録した人のうち、今も活動している割合。サンプル数が少ないと数値はノイズが多い。

🔥 製品 KPI — AI 精度・コスト最適化はどうか？

📊 LLM 呼び出し caller 比率 (30d)

⚠️ カロリー誤り報告 — ユーザーが「これおかしい」と感じた meal

時刻	ユーザー	料理名	登録 kcal	lookup_key / meal_id

💬 ユーザーフィードバック — ユーザーは何を求めている？

時刻	ユーザー	内容

⚙️ 技術 / コスト

レイテンシ、エラー、コスト内訳。

🩺 技術 health — ユーザーは何秒待たされているか？エラーは？

🎯 1次応答レイテンシ (マイク離す → 吹き出し表示)

🎯 カロリー反映レイテンシ (履歴に最終kcal表示まで)

📊 1次応答の内訳: どこに時間がかかっているか (7d平均)

⏱ 補助: caller 別 LLM 単体レイテンシ (7d, OpenRouter API 部分のみ)

caller	n	p50	p95	p99

🐛 直近のエラー (7d, 最大20件)

時刻	caller	error

💸 コスト詳細 — どこに金がかかっている？

📈 日次コスト推移 (30d, OpenRouter のみ)

👤 コスト上位ユーザー (30d)

user	plan	calls	cost

📞 caller × model 別 (30d)

caller	model	calls	cost

🎤 Soniox 日次 (30d, /v1/usage-logs から)

日付	回数	音声秒	コスト

📋 LP α版テスト Waitlist

メアド登録、流入元、配信停止状態、個別/一括メール送信。

	時刻 (JST)	Email	Source	状態	送信履歴	Referrer

🏗 アーキテクチャレビュー

7 観点で shiwake の現状を整理する設計リファレンス。
各セクションは「📐 現状 / ✅ 強み / ⚠️ 懸念 / 📝 TODO」の 4 サブ構造で統一。更新は admin/index.html の data-tab="architecture" セクション。

🗺 1. システム全体マップ 🌊 2. 主要 user flow 💾 3. データモデル 🔐 4. セキュリティ・認証 ⚡ 5. パフォーマンス & コスト 🌐 6. 外部依存リスク 🧪 7. 技術負債 & TODO

🗺 1. システム全体マップ — 1 枚で頭に入るか？

📐 現状

graph LR iOS["📱 iOS App
SwiftUI + Keychain"] Backend["⚙️ shiwake-daily-api
Hono on Workers"] D1B[("💾 D1: shiwake_daily")] R2[("🪣 R2: media")] Soniox{{"🎤 Soniox
STT realtime + async"}} OR{{"🤖 OpenRouter
Gemini 3 Flash / GPT-4o-mini"}} Apple{{"🍎 Apple
AppAttest + StoreKit 2"}} Weather{{"🌤 Open-Meteo
weather"}} LP["🌐 LP shiwake-lp(-stg)
Pages + Functions"] D1L[("💾 D1: shiwake-lp")] SMTP{{"📧 お名前.com SMTP"}} Admin["🛠 shiwake-admin
Pages SPA"] iOS -->|"Bearer access_token"| Backend iOS -.->|"WS stt-rt-v4 (temp key)"| Soniox iOS -->|"AppAttest assertion"| Backend iOS -->|"StoreKit JWS"| Backend Backend --> D1B Backend --> R2 Backend -->|"chat/completions"| OR Backend -->|"async stt"| Soniox Backend -->|"verify attest + JWS"| Apple Backend --> Weather Backend -->|"S2S notif"| Apple LP --> D1L LP -->|"SMTP 465"| SMTP Admin -->|"Basic auth"| Backend Admin -->|"Basic auth"| LP

✅ 強み

Cloudflare に寄せきった単一プラットフォーム (Workers + Pages + D1 + R2) で運用面はシンプル
iOS → 外部 API への直接呼び出しを最小化 (Soniox WS のみ、temp key 経由)
backend / lp / admin の 3 リポ的役割が明確

⚠️ 懸念

Backend 単一環境: backend は stg/prod が分かれていない (LP は分かれている)。本番デプロイで壊れたら即影響
Cloudflare 障害時の代替路なし: D1 / Workers ともに同社

📝 TODO

backend に shiwake-daily-api-stg を切る (D1 も別 instance)
D1 の定期スナップショット運用

🌊 2. 主要 user flow — フローの単純性、責務の明確さ

📐 現状: 「発話 → カロリー記録」 (主要 critical path)

sequenceDiagram participant U as User (iOS) participant SX as Soniox WS participant API as backend /api/ingest participant OR as OpenRouter participant D1 as D1 U->>API: POST /api/auth/soniox-temp-key API-->>U: temp key (短期) U->>SX: WS stt-rt-v4 (発話ストリーム) SX-->>U: transcript (逐次) U->>API: POST /api/ingest {transcript} API->>OR: Gemini 3 Flash (intent + entity) OR-->>API: structured JSON API->>D1: INSERT meals/weights/exercises API-->>U: response (即時) Note over API,OR: BG: mealLookup (web search)
→ meal_nutrition_cache に保存 API->>D1: UPDATE meals.kcal (後追い)

📐 主要フロー一覧 (本ページで定期メンテすべき)

発話 → カロリー記録 (上図)
体重記録: POST /api/weights → D1 (LLM 不要)
履歴の修正: PUT /api/meals/:id, /api/meals/:id/rename
サマリ表示: GET /api/summary/weekly (集計クエリ)
サインアップ: AppAttest challenge → 検証 → users 行作成 → access_token 返却
IAP 購読: StoreKit → JWS 抽出 → /api/iap/verify → users.subscription_status 更新

✅ 強み

1 次応答は LLM 1 回 (Gemini Flash) で帰す。カロリー数値は BG で後追い (UI は仮値表示 → kcal 確定で差し替え)
分岐の少ない sequential flow で観測しやすい

⚠️ 懸念

BG タスク失敗の可視化が弱い: mealLookup 失敗時、ユーザーには見えにくい (kcal が「—」のまま残る)
WS の接続失敗フォールバックなし: Soniox WS が落ちた時、async REST へのフォールバックは未実装

📝 TODO

各フローを 1 セクションずつ図式化 (体重/履歴編集/サマリ/IAP)
失敗パスの追加 (Soniox 切断、OpenRouter timeout)

💾 3. データモデル — 正規化と PII の局在

📐 現状

D1 = SQLite。JOIN は使うが分散は意識しない (rows-per-account が極小)。

テーブル	用途	PII?
`users`	account + profile + affinity + sub status + AppAttest signup	✓ 名前/メアド/誕生日
`meals`	食事記録 (transcript, name, kcal, lookup_key, photo_key)	✓ 食事 photo
`weights`	体重記録	✓ 体重値
`exercises`	運動記録	—
`notes`	その他メモ	—
`meal_nutrition_cache`	正規化 kcal cache (30d TTL想定)	—
`user_facts`	assistant 学習済み事実 (好み/制約)	✓
`conversation_log`	直近 N ターン (ingest context)	✓
`weather_cache`	Open-Meteo 1h cache	—
`api_usage_log`	OpenRouter/Soniox call ledger	—
`request_timing`	per-request latency milestone	—
`feedback`	音声フィードバック transcript	✓
`attest_challenges`	短期 AppAttest nonce	—
`invitations`	legacy 招待コード redeem	—
`waitlist` (lp)	α テストメアド + unsub token	✓ メアド
`email_log` (lp)	送信履歴	✓ メアド

✅ 強み

PII を users + 各ログ系に集中。物理削除 1 ユーザー = カラム削除で完結 (GDPR 想定容易)
cache 系 (meal_nutrition_cache, weather_cache) は user_id を持たないので削除影響なし

⚠️ 懸念

削除カスケード未実装: ユーザー削除時の各テーブル削除手順がコード化されていない
conversation_log の TTL なし: 無制限に伸びる可能性 → サイズ監視が必要

📝 TODO

各テーブルに保持期間ポリシー (例: meal_nutrition_cache=30d, conversation_log=最新 50 turns, request_timing=90d)
DELETE /api/me エンドポイント + 全テーブル cleanup スクリプト

🔐 4. セキュリティ・認証 — 攻撃面が把握できているか

📐 現状

レイヤ	方式	ガード
iOS → backend	`Authorization: Bearer <access_token>`	`requireUser` が D1 の `users.access_token` を直接 lookup (opaque random)
サインアップ	Apple AppAttest	`backend/src/appattest.ts`: cert chain + nonce + bundle/team 検証 (node-app-attest)
iOS → Soniox WS	backend 経由で temp key 発行	`/api/auth/soniox-temp-key` (要 user 認証)
admin /api/admin/*	HTTP Basic `admin:ADMIN_PASSWORD`	middleware over `/api/admin/*`
IAP S2S notif	JWS payload を decode	⚠️ 署名検証は未実装 (TODO)
LP /api/waitlist	無認証 (公開フォーム)	email regex + ip hash + 重複検知のみ。rate limit なし
LP /api/unsubscribe	token 経由 (RFC 8058)	16 byte ランダム token

✅ 強み

iOS サインアップに AppAttest を採用 → 偽端末からの自動アカウント大量作成を防止
access_token は opaque random (JWT 鍵漏洩リスクなし)、revoke は DB 更新 1 行
Soniox 認証情報を iOS バンドルに埋め込まない (temp key 方式)

⚠️ 懸念

IAP JWS 署名未検証 → 偽 receipt で premium 化される可能性 (致命的)
LP waitlist rate limit なし → SPAM / 嫌がらせ登録による D1 圧迫 + メアド汚染
access_token のローテーションなし → 端末紛失時に手動で DB 更新が必要
admin Basic auth がシングルパスワード → 共有事故時にローテ必須

📝 TODO

iap.ts に x5c chain 検証 + issuer/bundleId/environment 検証を入れる (現状 skeleton)
LP waitlist に Cloudflare Turnstile or IP-based rate limit
access_token に有効期限 + refresh の検討
新規エンドポイント追加時のセキュリティチェックリスト化

⚡ 5. パフォーマンス & コスト — ボトルネックは特定済みか

📐 現状: 1 次応答レイテンシ予算

step	目標 p95	備考
Soniox WS 確定 (発話終了 → 最終 transcript)	~1.5s	realtime stt-rt-v4
ingest (Gemini 3 Flash)	~1.5s	intent + entity 抽出
persona (GPT-4o-mini)	~0.8s	応答メッセージ生成
合計 (1 次応答)	~3-4s	履歴 UI に吹き出し表示
mealLookup (BG, web search)	~6-10s	UI は kcal 「—」→ 確定で差し替え

📐 現状: 1 active user / 日コスト式

10 発話/日 × 10 秒 × (Soniox $0.0025/秒 + Gemini Flash + GPT-4o-mini) × cache HIT 率 (mealLookup は HIT で 0)

= 約 ¥2-3/日 (cache HIT 60%+ 想定) / ¥4-5/日 (HIT 30% 想定)

実測は技術 / コストタブ参照。

✅ 強み

クリティカルパスは LLM 1 段 (Gemini Flash) → コスト/レイテンシ予測しやすい
mealLookup は web search を伴うので BG 化、UI を待たせない
meal_nutrition_cache で同名料理は秒で kcal 確定 (LLM コスト 0)

⚠️ 懸念

cache HIT 率がコスト構造を支配。HIT が下がると OpenRouter コストが線形に上昇
persona の応答生成が遅くなると 1 次応答が体感悪化 (現状 GPT-4o-mini が突然遅くなるリスク)
Soniox WS のネットワーク条件依存性が大 (地下鉄等)

📝 TODO

cache HIT 率の警報閾値 (e.g. 7d 平均 50% 以下で alert)
persona を Gemini Flash に統一する選択肢の評価
オフライン録音 → 後送信モード (Soniox 不安定時)

🌐 6. 外部依存リスク — 片足を抜くコストが見えるか

📐 現状

依存先	用途	ロックイン	代替	値上げ耐性
Cloudflare	Workers + Pages + D1 + R2	🔴 高 (D1 移行 = SQLite ダンプ + 再構築)	Fly.io + libSQL, AWS Lambda + DynamoDB	🟢 大
Soniox	realtime + async STT	🟡 中 (WS プロトコル + temp key API)	Deepgram, AssemblyAI, OpenAI Whisper API	🟡 中
OpenRouter	Gemini 3 Flash + GPT-4o-mini ルータ	🟢 低 (Anthropic/OpenAI/Google 直叩きに切替容易)	各 LLM ベンダー直接	🟢 大 (パススルー)
Apple AppAttest	サインアップ防御	🔴 高 (iOS の選択肢としては唯一)	なし	—
Apple StoreKit / IAP	課金	🔴 高 (iOS では必須)	なし	🟡 Apple 30% → 15% (Small Biz)
お名前.com SMTP	α 招待 / 配信停止メール	🟢 低 (Resend, SendGrid に乗り換え容易)	Resend, SES, SendGrid	🟢 大
Open-Meteo	天気	🟢 低 (オプショナル機能)	OpenWeatherMap	🟢 大

✅ 強み

LLM は OpenRouter で抽象化 → モデル変更で 1 行修正
SMTP / 天気は薄いラッパで覆われており移行容易

⚠️ 懸念

D1 ロックインが最大級。リレーション + 集計を SQL に寄せているため SQLite 互換 (Turso 等) 以外への移行はコスト大
iOS は Apple 全依存 (回避不可能、ビジネスリスクとして織り込む)

📝 TODO

D1 のスキーマ → Turso (libSQL) 移行コストを試算しておく
Soniox 障害時に Whisper API へフォールバックする経路の試作

🧪 7. 技術負債 & 既知の TODO — リファクタ優先順位

📐 現状: 一覧 (grep 由来 + レビュー時に追記)

優先度	項目	場所	備考
🔴 高	IAP JWS 署名検証	`backend/src/iap.ts:12`	x5c chain + issuer/bundleId/env 検証が未実装。本リリース前必須
🔴 高	backend stg 環境	—	shiwake-daily-api-stg を切る
🟡 中	LP waitlist の rate limit	`lp/functions/api/waitlist.ts`	SPAM 対策
🟡 中	conversation_log の TTL	backend/migrations	無制限に伸びる
🟡 中	削除カスケード (GDPR)	backend 全体	DELETE /api/me + 全テーブル cleanup
🟢 低	テンプレ URL の `XXXXXX`	`lp/functions/_lib/templates.ts:68,270`	UI から差し替え可能なのでコード変更不要
🟢 低	legacy invitation redeem	`backend/src/index.ts`	使ってなければ削除

📝 運用ルール

新規 TODO はここに追記 (該当箇所のソースコードに // TODO 残し + ここにエントリ追加)
解消時はテーブル行を削除 (履歴は git で追える)
レビュー会は四半期ごと、優先度を見直す

💡 このページは静的ドキュメントです。データソースは admin/index.html 内のハードコード。アーキテクチャに変更があったときは PR で更新してください。

📖 仕様書

iOS 全 11 画面の機能要件 (FR) / 非機能要件 (NFR) / 連携 API / データモデルを画面単位で整理。横断要件と API カタログを末尾に併載。更新は admin/index.html の data-tab="docs" セクション。

⚠️ 実装ギャップ (調査で発見)

POST /api/feedback のサーバ実装が見当たらない — iOS の FeedbackButton.swift と APIClient.submitFeedbackText は呼んでいるが backend/src/index.ts に該当ハンドラ無し。feedback 行は現状 /api/meals/:id/flag-calorie 経由でのみ作られる。
Soniox 障害時に Apple SF への自動フォールバック無し — Premium ユーザは Soniox temp key 取得失敗時にエラー文言が出るだけで録音継続不能。

① オンボーディング (4) ② 記録ループコア (3) ③ 振り返り (2) ④ 設定 / ナビ基盤 (2) ⑤ 横断要件 (8 カテゴリ) ⑥ API カタログ (37)

① オンボーディング — 初回起動から最初の 1 回の記録まで

OnboardingView ios/Sources/Views/OnboardingView.swift

ニックネーム 1 項目だけでサインアップを完了させるスプラッシュ的画面。背後で AppAttest signup (実機) / 旧 invite redeem (シミュレータ) を自動実行。

TRIGGERPrivacyConsent 通過後 & token 不在

機能要件 (FR)

FR-OB-01ニックネーム 1 フィールドのみ表示 / 空白以外を必須化
FR-OB-02「はじめる」ボタンで autoSignUp(displayName) を起動
FR-OB-03送信中は ProgressView + ボタン disabled + ラベル「登録中…」
FR-OB-04入力フィールドに 0.2s 後 auto-focus、submitLabel=done
FR-OB-05AppAttest signup (実機) → token/userId を Keychain 保存。Phase B 実装済
FR-OB-06サインアップ確定の瞬間に needsProfileSetup=true を先行セット (チラつき防止)

非機能要件 (NFR)

NFR-OB-P1サインアップは P50 < 2s (challenge + attest + signup の 3 往復)
NFR-OB-S1access_token は Keychain (kSecClassGenericPassword, service jp.newmeta.shiwake.auth) 保存
NFR-OB-A1preferredColorScheme(.dark) 固定、ボタンは 44pt 以上のタップ領域
NFR-OB-X1招待コード概念をユーザーに見せない (UI から完全排除)

API: POST /api/auth/challengePOST /api/auth/signupPOST /api/invite (DEBUG fallback)POST /api/auth/redeem (DEBUG fallback)
データ: usersattest_challengesinvitations
エッジ: 既に token 保持中は画面非表示 / シミュレータは旧フロー / 空白ニックネーム拒否

PrivacyConsentView ios/Sources/Views/PrivacyConsentView.swift

初回起動時にプライバシー要約 4 項目とカメラ初期動作の選択を提示し同意取得。

TRIGGER@AppStorage("privacy_agreed_v1") == false の起動

機能要件 (FR)

FR-PC-01取得情報 / 第三者送信 / 保存期間 / セキュリティの 4 サマリー表示
FR-PC-02カメラ起動設定をラジオで 2 択 (プライバシー優先 / 即撮影)、camera_instant_ready に保存
FR-PC-03「全文を読む」で PrivacyPolicyFullView を sheet 表示
FR-PC-04「同意してはじめる」で privacy_agreed_v1=true
FR-PC-05全文は 8 章 (取得情報, 利用目的, 第三者送信, 保存期間, ユーザー権利, セキュリティ, 変更, 連絡先)
FR-PC-06連絡先 contact_app@newmeta.co.jp を明示

非機能要件 (NFR)

NFR-PC-L1個情法/GDPR 想定で「取得項目・利用目的・第三者提供・保存期間・問合先」を必須記載
NFR-PC-L2同意フラグはバージョン付き (privacy_agreed_v1) で改定時に再同意可能
NFR-PC-A1Dynamic Type 対応 (.subheadline), fixedSize で折返し保持
NFR-PC-S1HTTPS/WSS、Keychain 保存を明文化

API: なし (端末ローカルのみ)
データ: @AppStorage("privacy_agreed_v1")@AppStorage("camera_instant_ready")
エッジ: 全リセット時は両フラグを削除して再表示

ProfileSetupView ios/Sources/Views/ProfileSetupView.swift

7 ステップウィザード (身長→体重→体脂肪→活動量→食事目標→目標体重→達成日)。音声中心 + 手入力フォールバック。

TRIGGERサインアップ直後 or auth.needsProfileSetup=true

機能要件 (FR)

FR-PS-017 ステップを progress bar で可視化
FR-PS-02マイクボタン長押し (DragGesture) で録音 → 離して送信
FR-PS-03STT 二刀流: Premium=Soniox WebSocket / Free=Apple SFSpeechRecognizer
FR-PS-04認識テキストを /api/setup/parse へ → value_double/level/goal/date_iso/skipped を抽出
FR-PS-05結果を吹き出しで「身長は 170.5cm で合ってる?」形式で再確認
FR-PS-06手入力モーダル: wheel picker / リスト / DatePicker、親指圏に大きな決定ボタン
FR-PS-07bodyFat / activity は "スキップ" 可、それ以外は再入力強制
FR-PS-08範囲バリデーション: 身長 100-220cm, 体重 20-300kg, 体脂肪 3-70%
FR-PS-09キャラクター (idle/listening/thinking) を 160pt 固定高で表示
FR-PS-10完了時に TDEE と目標カロリーを Bmr.tdee + TargetCalories.derive でクライアント算出
FR-PS-11PUT /api/me/targets で身長/体脂肪/目標体重/期日/食事目標/カロリーを一括保存
FR-PS-12同時に POST /api/weights で初期体重を 1 件記録
FR-PS-13保存成功時に全面緑チェック overlay を 1.8s 表示してから markProfileComplete()
FR-PS-14未入力項目があれば最初の未入力 step に自動で戻る

非機能要件 (NFR)

NFR-PS-P1/api/setup/parse は OpenAI strict-mode JSON 解析、P50 < 1.5s
NFR-PS-A1触覚: 録音開始 0.9 / 停止フル / 完了 success notification
NFR-PS-X1声が出せない場面のフォールバック (手入力 wheel) を全 step で提供
NFR-PS-X2音声接続失敗時は errorMessage 表示し isRecording=false に戻す

API: POST /api/auth/soniox-temp-key (Premium)POST /api/setup/parsePUT /api/me/targetsPOST /api/weights
データ: users.{height_cm,body_fat_percent,target_weight_kg,target_weight_date,target_calories_kcal,dietary_goal}weights
エッジ: token 切れ / Soniox 接続失敗 / 空 transcript / 範囲外値 / 既存値ありの dial 初期値 seed

PaywallView ios/Sources/Views/PaywallView.swift

ProfileSetup 直後に挿入される 1 ヶ月無料 → ¥490/月のサブスクリプション勧誘。Apple 規約準拠。

TRIGGERprofileSetup 完了 & subscriptionStatus != "premium_active"

機能要件 (FR)

FR-PW-01ヘッダー「Shiwake Premium / 最初の 1 ヶ月は無料」
FR-PW-024 ベネフィット (関係性深化 / 音声無制限 / 記憶 / 高精度カロリー) を icon+desc で訴求
FR-PW-03価格カード: ¥0/最初の 1 ヶ月 + その後 displayPrice 自動更新
FR-PW-04CTA「1 ヶ月無料ではじめる」→ StoreKitManager.purchase() → JWS を /api/iap/verify
FR-PW-05「購入を復元」で StoreKit.restore() + refreshProfile + Premium 確認時 onContinue
FR-PW-06規約 3 項目を caption で明示 (解約方法 / 24h 前 / Apple ID 共有)
FR-PW-07product 未ロード or 購入処理中はボタン disable
FR-PW-08購入失敗 (userCancelled 除く) は store.lastError をテキスト表示

非機能要件 (NFR)

NFR-PW-L1App Store 規約: 価格・課金頻度・自動更新・解約方法・規約リンクを必須掲載
NFR-PW-S1レシート検証は端末でなく必ず /api/iap/verify (サーバ側 JWS 検証)
NFR-PW-X1StoreKit 未ロード時は ¥490/月のフォールバック表記

API: POST /api/iap/verifyGET /api/me
データ: users.subscription_statususers.trial_ends_at
エッジ: 購入キャンセル / 復元時 Premium 反映待ち / オフライン

② 記録ループ (コアバリュー) — 起動即記録の差別化区間

CaptureView ios/Sources/Views/CaptureView.swift

メイン画面。カメラ常時起動 + 左下マイク長押し + 右下カメラタップ + アシスタント吹き出し + 直近 6 件ピル。

TRIGGER通常起動 (認証済 & profileSetup 完了)

機能要件 (FR)

FR-CAP-01全画面 CameraPreview を常時稼働、上部 34% 白角丸、下半分は左右 50:50 のマイク/カメラ判定エリア
FR-CAP-02cameraInstantReady=false ならカメラに UltraThinMaterial overlay、1 タップで解除 → ロックオン 4 隅ブラケット、2 タップ目で capturePhoto()
FR-CAP-03左マイクエリア DragGesture: 長押し → startCapture → 離して stop → /api/ingest へ transcript
FR-CAP-04STT 二刀流: useApple=!isPremium で Apple SF / Soniox を切替
FR-CAP-05上部キャラクター (idle/listening/thinking) + 吹き出し + 尻尾、録音中は尻尾を隠す
FR-CAP-06吹き出しテキストはランダム抽選プール (時間帯 × 親密度 × 状態で 50+ パターン)
FR-CAP-07時間帯別挨拶 (朝/午前/昼/午後/夕/夜/深夜) を Lv1-2=さん / Lv3+=くんで抽選
FR-CAP-08上スワイプ (> 40px) でキャラ/吹き出しを折りたたみ、pullDownTab で復帰
FR-CAP-09直近 6 件の meal/weight をピル (料理名+kcal / 体重+kg) で右側縦並び、今日/昨日/一昨日ラベル付き
FR-CAP-10計算中 meal が含まれる間は 3s 間隔で reloadRecentMeals を polling
FR-CAP-11capturePhoto: AVCapturePhoto を /api/meals (multipart) に POST
FR-CAP-12/api/ingest の advance_event レスポンスで AdvanceEventModal を sheet 表示
FR-CAP-13persona_comment があれば優先、無く count=0 なら "記録なし"、count>0 なら "N 件記録した"
FR-CAP-14記録成功時は success haptic + .shiwakeDataChanged を 0/4/8/15s で複数回 post
FR-CAP-15初回起動のみ 0.6s 遅延して CaptureTutorialOverlay 表示 (hasSeenCaptureTutorial=true で抑止)
FR-CAP-16scenePhase=.background 時に camera.stop()、復帰時 start + フロステッド再有効化 + 挨拶差替

非機能要件 (NFR)

NFR-CAP-P1ingest 1 次応答 P50 目標 (persona_comment 即返却)、mealLookup は waitUntil で非同期
NFR-CAP-P2カメラ起動から最初のフレームまで P50 < 500ms (camera.start を task で並列実行)
NFR-CAP-S1プライバシー: 起動時すりガラス、scenePhase 変化で確実に stop、ファインダー解除はセッション毎にリセット
NFR-CAP-A1触覚: 録音開始 1.0 / 停止 1.0 / 成功 .success / 失敗 .error / 雑談成立 .selectionChanged
NFR-CAP-A2ロックオン枠は cornerSize 44 / strokeWidth 5 で視認性確保
NFR-CAP-O1オフライン: token 切れは bubblePhrase(.authExpired)、送信失敗は .sendFailed
NFR-CAP-M1触覚 prepare() を onAppear / onEnded 毎に呼んでレイテンシ最小化

API: POST /api/ingestPOST /api/mealsGET /api/mealsGET /api/weightsGET /api/mePOST /api/auth/soniox-temp-key
データ: meals (raw_text, ai_result, calories_kcal, image_r2_key)weightsusers.affinity_*pending_advance_event
エッジ: シミュレータ (カメラ無し) / バックグラウンド復帰時の挨拶差替 / 計算中ピル polling 自動停止 / 雑談 reply_only / ingest 例外 / Soniox temp key 失敗

CaptureTutorialOverlay ios/Sources/Views/CaptureTutorialOverlay.swift

初回 CaptureView 表示時に出る 3 ステップ overlay (導入 / マイク / カメラ)。

TRIGGERhasSeenCaptureTutorial=false で CaptureView 表示 0.6s 後

機能要件 (FR)

FR-TUT-01黒幕 72% + 中央メッセージカード + 下部矢印で 3 ステップ案内
FR-TUT-02step1: マイク領域 (画面下 25% x) へ arrow.down + バウンスアニメ
FR-TUT-03step2: カメラ領域 (画面下 75% x) へ arrow.down
FR-TUT-04ボタン: 戻る / 次へ / (最終)始める
FR-TUT-05「始める」で hasSeenCaptureTutorial=true 保存 → 自動消去
FR-TUT-06Settings の「チュートリアルを再表示」で AppStorage を削除すれば再表示

非機能要件 (NFR)

NFR-TUT-A1暗幕タップは無視 (誤遷移防止)、ステップインジケータドット表示
NFR-TUT-A2矢印は ArrowBounce で上下 10pt 振動 (注目誘導)

API: なし
データ: @AppStorage("hasSeenCaptureTutorial")
エッジ: 設定→チュートリアル再表示時の再起動なし対応

AdvanceEventModal ios/Sources/Views/AdvanceEventModal.swift

関係性レベル昇格 (Lv N → N+1) の祝福モーダル。AI からの opening line を演出表示。

TRIGGER/api/ingest または /api/me が advance_event を返した時、AuthStore.pendingAdvanceEvent 経由

機能要件 (FR)

FR-AEM-01ハート fill (84pt) を spring(0.6, 0.55) でフェードイン + 拡大
FR-AEM-02Lv チップ遷移 "Lv N → Lv N+1" を矢印で表示
FR-AEM-03event.openingLine を pink 8% 背景 + 16pt medium で中央表示
FR-AEM-04「ありがとう」ボタン (pink グラデ Capsule) で onDismiss
FR-AEM-05sheet detents [.medium, .large]
FR-AEM-06表示後 AuthStore.pendingAdvanceEvent=nil に即クリア (二重表示防止)

非機能要件 (NFR)

NFR-AEM-X1one-shot 配信: ingest waitUntil で advance が決まったら次の /api/me で 1 回だけ届き即 NULL
NFR-AEM-A1触覚連動なし (視覚アニメで十分な演出強度)

API: 表示専用 (payload は ingest/me に同梱)
データ: users.pending_advance_event (migration 0021)
エッジ: 既に他のモーダル表示中なら上書きしない / dismiss 漏れによる再表示防止

③ 振り返り — グラフ / 履歴 / 編集の hub

SummaryView ios/Sources/Views/SummaryView.swift

グラフ (体重 / カロリー) + 7 日サークル + 日別履歴一覧。編集 / 削除 / 再計算 / カロリー誤り報告の hub。

TRIGGERメイン下部「グラフ」ボタンで fullScreenCover

機能要件 (FR)

FR-SUM-01サマリヘッダー (タイトル + 設定歯車)
FR-SUM-02todaySection: 7 日サークル (目標 vs 実績) + 摂取/消費トグル + 選択日の食事カード一覧 + カロリーバー
FR-SUM-03longTermSection: 体重/カロリーグラフのトグル、期間 day/week/month/6month/year、グラフ内タップで selectedDate 切替
FR-SUM-04体重グラフは weight_kg + body_fat_percent (dual axis 想定)
FR-SUM-05履歴セクション: meal/weight/note を時刻降順マージ、日付ラベル区切り、最大 50 件、行内ゴミ箱 (1 タップで ✓/× の 2 段階確認)
FR-SUM-06食事名のタップで editingMealSheet (rename) 起動、保存で POST /api/meals/:id/rename → mealLookup 再計算 → 楽観的更新後 polling
FR-SUM-07食事行の「!」で flag-calorie alert、「はい」で POST /api/meals/:id/flag-calorie → 下部 toast 2.5s
FR-SUM-08体重行タップで EditWeightSheetContent、保存で POST /api/weights/:id/update
FR-SUM-09削除: meal/weight/note を DELETE、楽観的に画面から消す
FR-SUM-10計算中 meal がある間は楽観値 (optimisticMeals) を保持し、サーバ計算完了まで上書きを防ぐ
FR-SUM-11.shiwakeDataChanged 通知 + refreshTimer で自動リロード
FR-SUM-12FeedbackButton をオーバーレイ表示 (× ボタン右隣)
FR-SUM-13CloseButton (左下 78pt 円) で fullScreenCover dismiss

非機能要件 (NFR)

NFR-SUM-P1/api/meals (期間指定) で 1 回取得、クライアント側で日別集計
NFR-SUM-P2編集時は processingIds に追加して「仕分け修正中…」overlay 表示
NFR-SUM-A1DynamicType、行アクセントの heart アイコンは 13pt 系
NFR-SUM-O1エラーは画面上部に err:... monospace 9pt で開発者向け表示

API: GET /api/mealsGET /api/weightsGET /api/notesGET /api/exercisesPOST /api/meals/:id/flag-caloriePOST /api/meals/:id/renamePUT /api/meals/:idDELETE /api/meals/:idDELETE /api/weights/:idPOST /api/weights/:id/updateDELETE /api/notes/:idGET /api/summary/weekly
データ: mealsweightsnotesexercisesmeal_nutrition_cache
エッジ: 計算中 meal の楽観更新衝突 / リロード中の重複 reload 抑止 / 90 日範囲取得 / dual axis グラフのデータ欠損

FeedbackButton ios/Sources/Views/FeedbackButton.swift

SummaryView の × 隣に常駐するピル。長押しで Apple SF が文字起こし、テキストを /api/feedback に送信。

TRIGGERSummaryView 内常駐 (ZStack)

機能要件 (FR)

FR-FB-01横長ピル「開発フィードバック / 長押しで送信」、長押し中は赤色 + scale 1.05
FR-FB-02LongPressGesture(0.2s) で startRecording、DragGesture.onEnded で stopRecording → upload
FR-FB-03録音中は画面中央 18% 位置に大きな transcript カード表示 (逐次更新)
FR-FB-04アップロード中は ProgressView アイコン、ピル opacity 0.5、disable
FR-FB-05結果トースト: 成功 (緑) / 聞き取れず (橙) / 失敗 (赤) を 2.5s 表示
FR-FB-06Apple Speech (LocalSpeechRecognizer) で完全オンデバイス文字起こし (コストゼロ)

非機能要件 (NFR)

NFR-FB-P1テキストのみ送信 (音声ファイル無し) で帯域・コスト削減
NFR-FB-A1触覚: 録音開始 medium 1 回
NFR-FB-O1空 transcript はトーストで知らせ送信スキップ

API: POST /api/feedback ⚠️ サーバ未実装の可能性
データ: feedback (migration 0018: id/user_id/transcript/created_at)
エッジ: バックエンド未実装の可能性 / token 切れ / 音声権限拒否

④ 設定 / ナビ基盤 — プロフィール再編集と Premium 管理

SettingsView ios/Sources/Views/SettingsView.swift

プロフィール編集 / 目標再設定 / カメラ設定 / 関係性表示 / Premium 管理 / Facts 閲覧 / 招待発行 / ログアウト・リセット。

TRIGGERSummaryView 右上の歯車から fullScreenCover

機能要件 (FR)

FR-SET-01プロフィール: ニックネーム / 身長 / 体脂肪率 / 現在体重 / BMR (算出) / 活動量 / 食事目標 / TDEE (算出)
FR-SET-02目標: 目標体重 / 達成期日 (DatePicker, 今日以降) / 目標カロリー (自動算出)
FR-SET-03カメラ設定 Toggle: camera_instant_ready を同期
FR-SET-04関係性: heart 5 段、Lv の Picker (デバッグ用)、呼び方表示、好感度 pt 表示
FR-SET-05Premium ステータス表示 + Apple サブスク管理リンク + デバッグ切替 Picker
FR-SET-06「チュートリアルを再表示」で hasSeenCaptureTutorial 削除 → dismiss
FR-SET-07アシスタントが覚えていること: user_facts を 30+ カテゴリラベルで表示、swipeActions で削除可
FR-SET-08招待コード: 自分のコード表示 + 「他人を招くコードを発行」で POST /api/invite → ShareLink
FR-SET-09ログアウト (Keychain クリア) / 初期設定をやり直す / アプリ完全リセットの 3 段階破壊操作
FR-SET-10FloatingSaveButton: 編集中 or hasUnsavedChanges の時のみ表示
FR-SET-11編集中 (focusedField != nil) は CloseButton を隠す (誤タップ防止)

非機能要件 (NFR)

NFR-SET-S1破壊操作は ConfirmationDialog で必ず確認
NFR-SET-X1値変化検知は origXxx スナップショットとの比較で hasUnsavedChanges 算出
NFR-SET-A1テキスト編集中の保存ボタン優先度を高くし、× ボタンと排他制御

API: GET /api/mePUT /api/me/targetsPUT /api/me/affinityPUT /api/me/subscriptionGET /api/me/factsDELETE /api/me/facts/:idPOST /api/inviteGET /api/weights
データ: users (全カラム)user_facts (0009)
エッジ: ログアウト後の Keychain 残骸 / リセット時のサーバデータ残存 / デバッグ Picker での Lv 強制変更時の affinity_points マッピング

RootView ios/Sources/Views/RootView.swift

ナビゲーション基盤。CaptureView を全画面に置き、下部「グラフ」ピルから SummaryView を fullScreenCover で開く。

TRIGGER認証済 & profileSetup 完了で表示

機能要件 (FR)

FR-RV-01ZStack(.bottom): CaptureView + 下部グラフボタン (ultraThinMaterial Capsule)
FR-RV-02sheet enum (settings, chart) を fullScreenCover で表示
FR-RV-03シート遷移アニメーションを transaction.disablesAnimations=true で抑制 (瞬時切替)
FR-RV-04scenePhase=.background でシートを自動 close
FR-RV-05sheet nil→non-nil 時 .shiwakeLeftCapture、逆で .shiwakeReturnedToCapture を post (カメラ stop/start 制御)
FR-RV-06CloseButton (左下 78pt) と FloatingSaveButton (右下 78pt) の 2 再利用コンポーネント提供

非機能要件 (NFR)

NFR-RV-P1設定 / サマリ遷移はアニメ無効化で「即時画面切替」体感
NFR-RV-S1バックグラウンド時のシート自動 close で意図せぬ画面残留を防止

API: なし
データ: なし
エッジ: 背景化中のシート開いたまま復帰 / グラフ→設定の連続遷移

⑤ 横断要件 — 画面横断で適用される NFR

🔐 認証 / セキュリティ

NFR-X-AUTH-01 Bearer トークン方式 (Authorization: Bearer <hex32>)、auth.ts の requireUser で SELECT id FROM users WHERE access_token=?
NFR-X-AUTH-02 access_token は iOS Keychain (kSecClassGenericPassword, service jp.newmeta.shiwake.auth)
NFR-X-AUTH-03 サインアップは AppAttest 経由 (/api/auth/challenge → DCAppAttestService → /api/auth/signup)、DEBUG ビルドのみ旧 invite redeem へフォールバック
NFR-X-AUTH-04 既ログイン時の invite URL は iOS 側で早期 return (無駄な往復回避)
NFR-X-AUTH-05 IAP は Apple JWS を /api/iap/verify でサーバ側検証 (端末側レシート検証は信用しない) — 署名 chain 検証は TODO
NFR-X-AUTH-06 Apple Server-to-Server 通知用に /api/iap/notification (no auth, 署名検証は TODO)
NFR-X-AUTH-07 AppAttest の Apple 公開鍵 + nonce 検証で偽端末の大量サインアップを防止 (Phase A 完了)
NFR-X-AUTH-08 テナント分離: 全 D1 クエリで user_id を WHERE 必須 (漏れがあれば即修正対象)

⚡ パフォーマンス

NFR-X-PERF-01 /api/ingest 1 次応答 (persona_comment) は P50 < 2s、mealLookup は ctx.waitUntil で非同期
NFR-X-PERF-02 OpenAI prompt cache を contextBundle で活用、システムプロンプトを安定化
NFR-X-PERF-03 meal_nutrition_cache (0007) で同名料理の再計算を回避
NFR-X-PERF-04 CaptureView は計算中 meal 検出時のみ 3s polling、完了で自動停止
NFR-X-PERF-05 Cloudflare Workers エッジ実行 + D1 prepared statement
NFR-X-PERF-06 weather_cache (0011) で外部 API 呼び出しを 1h ローカルキャッシュ

🛡 可用性 / 障害時挙動

NFR-X-AVAIL-01 OpenRouter/OpenAI 障害時: persona_comment はフォールバック定型文、mealLookup は notes "計算中" のまま留め置き
NFR-X-AVAIL-02 Soniox 障害時 (Premium): temp key 取得失敗 → エラー文言、Apple SF へのフォールバックは未実装 (将来課題)
NFR-X-AVAIL-03 D1 障害時: 5xx を返し iOS は bubblePhrase(.sendFailed) で再試行誘導
NFR-X-AVAIL-04 R2 障害時: image_r2_key を null で meal を作成 → 後追い再アップ未実装
NFR-X-AVAIL-05 /health エンドポイントで生存確認 ({ ok, ts })
NFR-X-AVAIL-06 /api/me が一時失敗してもクライアントは前回値を保持 (profileLoaded=false の間 splash)

📊 計測 / ログ / 監査

NFR-X-OBS-01 api_usage_log (0012): OpenRouter/OpenAI/Soniox の token・コスト・モデル別利用ログ
NFR-X-OBS-02 request_timing (0013): エンドポイント毎のレイテンシ分布
NFR-X-OBS-03 conversation_log (0014): user 発話 / assistant 返答の対話履歴 (persona 改善用)
NFR-X-OBS-04 feedback (0018): 開発者向けフィードバック文 + [calorie_flag] プレフィックスでカロリー誤り報告
NFR-X-OBS-05 Admin /api/admin/stats: OpenRouter credits / 平均日次コスト / runway 日数 / フィードバック直近一覧
NFR-X-OBS-06 Admin は Basic 認証 (app.use("/api/admin/*", basic auth))

🔒 プライバシー / 法務

NFR-X-PRIV-01 privacy_agreed_v1 同意フラグ + 全文ポリシー (8 章, 制定 2026-05-24)
NFR-X-PRIV-02 同意取得項目: ニックネーム / 身長 / 体重 / 体脂肪 / 食事 (text/voice/photo) / 利用時刻 / デバイス情報
NFR-X-PRIV-03 第三者送信: 音声認識 (Soniox) / AI 解析 (OpenAI/OpenRouter) / インフラ (Cloudflare) を明示
NFR-X-PRIV-04 削除依頼は contact_app@newmeta.co.jp、サーバ側削除は手動オペレーション (DELETE /api/me は TODO)
NFR-X-PRIV-05 カメラはバックグラウンド即 stop、起動時すりガラスを default (プライバシー優先)
NFR-X-PRIV-06 feedback アップロードはテキストのみ (音声非保存)

💸 コスト / リソース

NFR-X-COST-01 OpenRouter 月額予算は admin/stats の runway_days で監視
NFR-X-COST-02 Free ユーザは STT を Apple SF (コストゼロ) に強制、Premium のみ Soniox
NFR-X-COST-03 meal_nutrition_cache で重複料理の LLM 呼び出しを削減
NFR-X-COST-04 prompt cache 活用で OpenAI 入力トークンを 50%+ 削減狙い
NFR-X-COST-05 R2 は食事写真のみ保管 (音声は保存しない)
NFR-X-COST-06 フィードバックはテキスト化後送信 (音声ファイル送信なし)

♿ 国際化 / アクセシビリティ

NFR-X-I18N-01 日本語のみ (Locale ja_JP 固定)、Asia/Tokyo TZ で日付処理
NFR-X-A11Y-01 Dynamic Type を semantic font (.subheadline / .caption) で対応
NFR-X-A11Y-02 VoiceOver: 手入力ボタンに accessibilityLabel("手入力する")
NFR-X-A11Y-03 タップ領域 44pt 以上を意識 (CloseButton/SaveButton は 78pt 円)
NFR-X-A11Y-04 触覚フィードバック (impact/notification/selection) で視覚に依らない状態通知

🚀 配信 / リリース

NFR-X-REL-01 iOS: TestFlight → App Store Connect 経由配布 (IAP は In-App Subscription, StoreKit2)
NFR-X-REL-02 バックエンド: Cloudflare Workers (wrangler deploy), D1 マイグレーション wrangler d1 migrations apply
NFR-X-REL-03 LP: Cloudflare Pages, lp/functions/api/waitlist.ts で Edge Function
NFR-X-REL-04 Admin: Cloudflare Pages shiwake-admin.pages.dev、SPA + Basic auth lookup via backend
NFR-X-REL-05 AASA: /.well-known/apple-app-site-association で Universal Link /invite/*
NFR-X-REL-06 privacy_agreed_v1 のバージョン番号で同意の世代管理

⑥ API カタログ — バックエンド全エンドポイント (37)

認証 / 招待

METHOD	PATH	AUTH	用途
POST	/api/auth/challenge	none	AppAttest 用 nonce 発行 (5min TTL)
POST	/api/auth/signup	none	AppAttest assertion を検証 → user 作成 + access_token 返却
POST	/api/invite	none	匿名 invite code 発行 (DEBUG フォールバック / Settings 他者招待)
POST	/api/auth/redeem	none	invite code を access_token と交換 (409=消費済)
GET	/invite/:code	none	Universal Link 用、アプリ未インストール時のフォールバック
GET	/.well-known/apple-app-site-association	none	iOS Universal Link 設定

ユーザー / プロフィール

METHOD	PATH	AUTH	用途
GET	/api/me	Bearer	プロフィール + streak + subscription + trial + pending_advance_event 一括取得
PUT	/api/me/targets	Bearer	身長/体脂肪/目標体重/期日/目標カロリー/食事目標/ニックネーム一括更新
PUT	/api/me/affinity	Bearer	関係性 points 直接セット (デバッグ)
PUT	/api/me/subscription	Bearer	サブスク状態手動切替 (デバッグ)
POST	/api/setup/parse	Bearer	wizard 用音声 transcript → value/level/goal/date_iso 抽出
GET	/api/me/facts	Bearer	アシスタントが学習した user facts 一覧
DEL	/api/me/facts/:id	Bearer	fact 削除

食事 (meals / ingest)

METHOD	PATH	AUTH	用途
POST	/api/meals	Bearer	写真ベース meal 登録 (multipart: image+transcript)
GET	/api/meals	Bearer	期間指定で meal 一覧取得
DEL	/api/meals/:id	Bearer	meal 削除
PUT	/api/meals/:id	Bearer	meal 編集 (raw_text 等)
POST	/api/meals/:id/rename	Bearer	料理名変更 → mealLookup 再計算
POST	/api/meals/:id/flag-calorie	Bearer	カロリー誤り報告 → feedback テーブルに [calorie_flag] 挿入
POST	/api/ingest	Bearer	テキスト transcript で食事/体重/雑談を仕分け (persona_comment + advance_event 同梱)
POST	/api/ingest/voice	Bearer	音声バイナリ → STT → ingest 統合
POST	/api/auth/soniox-temp-key	Bearer	Premium 用 Soniox WebSocket 一時キー発行

体重 / 運動 / ノート

METHOD	PATH	AUTH	用途
POST	/api/weights	Bearer	体重記録 (kg + note + body_fat_percent)
POST	/api/weights/:id/update	Bearer	既存体重の上書き編集
GET	/api/weights	Bearer	期間指定取得
DEL	/api/weights/:id	Bearer	削除
GET	/api/exercises	Bearer	運動記録期間指定取得
DEL	/api/exercises/:id	Bearer	運動削除 (POST は ingest 経由で自動作成)
GET	/api/notes	Bearer	フリーノート一覧
DEL	/api/notes/:id	Bearer	ノート削除
GET	/api/summary/weekly	Bearer	過去 7 日の集計 (meal_count/total_kcal/avg_kcal + weights 配列)

フィードバック

METHOD	PATH	AUTH	用途
POST	/api/feedback	Bearer	テキストフィードバック送信 ⚠️ サーバ実装未確認

IAP / サブスクリプション

METHOD	PATH	AUTH	用途
POST	/api/iap/verify	Bearer	StoreKit JWS をサーバ側検証 → users.subscription_status 更新
POST	/api/iap/notification	none (署名検証)	Apple Server-to-Server 通知受信

Admin / LP / ヘルス

METHOD	PATH	AUTH	用途
GET	/api/admin/stats	Basic	OpenRouter credits / 日次コスト / runway / フィードバック直近一覧 (/api/admin/* 全体が Basic)
POST	/api/waitlist (LP)	none (IP hash)	メアド + source + UA + referrer を waitlist テーブルに保存
GET	/api/admin/waitlist (LP)	Basic	waitlist 取得 (JSON or CSV エクスポート)
GET	/	none	ルート (導線返し)
GET	/health	none	`{ ok: true, ts: now }`

💡 このページは静的ドキュメントです。データソースは admin/index.html の data-tab="docs" セクション + admin/admin.js の docFilter* 関数。画面追加・API 変更時に PR で更新してください。

🔐 Shiwake Admin

🏠 概要

🚨 今やるべきこと — アクションが必要か？

📊 スナップショット

💰 ビジネス

🎯 ファネル EV シミュレータ — Trial1 (14日) → Paywall → Trial2 (14日) → 自動課金

🛤 ステージタイムライン — Pre-Seed 6ヶ月 → Seed 6ヶ月 → Series-A 24ヶ月 (合計 36ヶ月)

📊 ステージ別 メトリクス — 同じ funnel 品質で、ステージ毎の経済性

📈 36ヶ月収益シミュレーション — ステージ遷移付き。何ヶ月で黒字化？

🚀 プロダクト

🚀 成長 — ユーザーは増え、定着しているか？

🔥 製品 KPI — AI 精度・コスト最適化はどうか？

⚠️ カロリー誤り報告 — ユーザーが「これおかしい」と感じた meal

💬 ユーザーフィードバック — ユーザーは何を求めている？

⚙️ 技術 / コスト

🩺 技術 health — ユーザーは何秒待たされているか？ エラーは？

💸 コスト詳細 — どこに金がかかっている？

📋 LP α版テスト Waitlist

📧 メール送信

🔍 メールプレビュー

🏗 アーキテクチャ レビュー

🗺 1. システム全体マップ — 1 枚で頭に入るか？

📐 現状

✅ 強み

⚠️ 懸念

📝 TODO

🌊 2. 主要 user flow — フローの単純性、責務の明確さ

📐 現状: 「発話 → カロリー記録」 (主要 critical path)

📐 主要フロー一覧 (本ページで定期メンテすべき)

✅ 強み

⚠️ 懸念

📝 TODO

💾 3. データモデル — 正規化と PII の局在

📐 現状

✅ 強み

⚠️ 懸念

📝 TODO

🔐 4. セキュリティ・認証 — 攻撃面が把握できているか

📐 現状

✅ 強み

⚠️ 懸念

📝 TODO

⚡ 5. パフォーマンス & コスト — ボトルネックは特定済みか

📐 現状: 1 次応答レイテンシ予算

📐 現状: 1 active user / 日 コスト式

✅ 強み

⚠️ 懸念

📝 TODO

🌐 6. 外部依存リスク — 片足を抜くコストが見えるか

📐 現状

✅ 強み

⚠️ 懸念

📝 TODO

🧪 7. 技術負債 & 既知の TODO — リファクタ優先順位

📐 現状: 一覧 (grep 由来 + レビュー時に追記)

📝 運用ルール

📖 仕様書

⚠️ 実装ギャップ (調査で発見)

① オンボーディング — 初回起動から最初の 1 回の記録まで

OnboardingView ios/Sources/Views/OnboardingView.swift

機能要件 (FR)

非機能要件 (NFR)

PrivacyConsentView ios/Sources/Views/PrivacyConsentView.swift

機能要件 (FR)

非機能要件 (NFR)

ProfileSetupView ios/Sources/Views/ProfileSetupView.swift

機能要件 (FR)

非機能要件 (NFR)

PaywallView ios/Sources/Views/PaywallView.swift

機能要件 (FR)

非機能要件 (NFR)

② 記録ループ (コアバリュー) — 起動即記録の差別化区間

CaptureView ios/Sources/Views/CaptureView.swift

機能要件 (FR)

非機能要件 (NFR)

CaptureTutorialOverlay ios/Sources/Views/CaptureTutorialOverlay.swift

機能要件 (FR)

非機能要件 (NFR)

AdvanceEventModal ios/Sources/Views/AdvanceEventModal.swift

機能要件 (FR)

📊 ステージ別メトリクス — 同じ funnel 品質で、ステージ毎の経済性

🩺 技術 health — ユーザーは何秒待たされているか？エラーは？

🏗 アーキテクチャレビュー

📐 現状: 1 active user / 日コスト式