🏠 概要

アクションと主要 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 で更新してください。

🤖 LLM 設計書

shiwake-daily は OpenRouter 経由で複数の LLM を組み合わせて動いている。
本ページは各呼び出しの 目的・モデル・プロンプト構造・コスト + 周辺の ハーネスエンジニアリング の設計をまとめる。
更新は admin/index.html の data-tab="llm" セクション。実コードと乖離したら直す。

🗺 1. 全体像 (シーケンス) 📋 2. 呼び出し早見表 🎙 3. ingest (Phase A 仕分け) 🍽 4. mealLookup (Phase B カロリー web 検索) 📷 5. analyzeMeal (写真 vision) 💬 6. persona (秘書コメント) 💞 7. relationshipJudge (関係性昇格) 🔧 8. ハーネスエンジニアリング 💰 9. コスト試算 📜 10. 現行プロンプト (本番デプロイ中の本文)

🗺 1. 全体像 (1 発話あたりの LLM 呼び出しチェーン)

📐 音声 1 発話 → 記録完了までの呼び出し順序

sequenceDiagram autonumber participant iOS as 📱 iOS participant API as ⚙️ Workers participant Ing as 🎙 ingest
(Gemini 3 Flash) participant Per as 💬 persona
(gpt-4o-mini) participant ML as 🍽 mealLookup
(Gemini 3 :online) participant Judge as 💞 judge
(gpt-4o-mini) participant DB as 💾 D1 iOS->>API: POST /api/ingest (transcript) API->>DB: loadRecentContext + facts + convLog (並列) API->>Ing: chat.completions (tools=create_meal/weight/exercise/...) Ing-->>API: tool_calls[] (JSON args) API->>DB: INSERT meals/weights/exercises (kcal=0 暫定) API->>Per: chat.completions (秘書発言生成) Per-->>API: "ラーメンですね、お疲れさま。" API-->>iOS: 200 OK (transcript / created / persona_comment) Note over API,ML: ↓ waitUntil で裏でカロリー再計算 ↓ par API->>ML: lookupMealNutrition (1食ずつ) ML-->>API: { calories_kcal, PFC, source_note } API->>DB: UPDATE meals SET calories_kcal=... and API->>Judge: evaluateLevelAdvance (条件成立時のみ) Judge-->>API: { decision, openingLine? } API->>DB: UPDATE users SET affinity_level/cooldown end

★ primary_response = ingest + persona の直列 2 呼び出しまでで iOS に 200 を返す (~3-4 秒目標)。
★ calorie_complete = mealLookup の web 検索が waitUntil 内で完了するまで (~10-15 秒、計算中…表示)。

📋 2. 呼び出し早見表

caller	モデル	用途	呼び出し場所	temperature	出力形式
`ingest`	google/gemini-3-flash-preview	音声テキスト → tool calls (create_meal / weight / exercise 等)	`ingest.ts`	0.1	tool_calls (parallel)
`meal_lookup`	google/gemini-3-flash-preview:online	料理名 → 公式値ベースの kcal + PFC (web 検索 Exa)	`mealLookup.ts`	0.1	json_schema strict
`normalize_dish`	openai/gpt-4o-mini	編集時に品名を lookup_key / unit / count に分解	`mealLookup.ts`	0.1	json_schema strict
`persona`	openai/gpt-4o-mini	記録結果に対する秘書の 1-2 文コメント	`persona.ts`	0.7	plain text (max 300 tok)
`judge`	openai/gpt-4o-mini	関係性 Lv 昇格すべきか (advance / wait)	`relationshipJudge.ts`	0.4	json_schema strict
`forced_opening`	openai/gpt-4o-mini	強制ライン到達時の「ずっと迷ってた」一言	`relationshipJudge.ts`	0.7	plain text (max 100 tok)
`premium_unlock`	openai/gpt-4o-mini	課金時の「ずっと話したかった」一言	`relationshipJudge.ts`	0.7	plain text (max 100 tok)
`photo_dish_extraction`	google/gemini-3-flash-preview (vision)	料理写真 → dish[] (kcal は出さない)	`openai.ts`	0.1	json_schema strict

💡 caller は api_usage_log テーブルの caller 列と一致。「技術 / コスト」タブで内訳を見れる。

🎙 3. ingest (Phase A: 仕分け)

📐 役割

Soniox STT で書き起こされた発話を、構造化された IngestAction[] に分解する。
parallel tool calls 必須:「朝はラーメン食べた、体重 70kg だった」を 1 回の呼び出しで create_meal + create_weight に分割する。

📐 入力 / 出力

input  : transcript (string) + RecentContext (直近 7 日の食事 / 体重 / 運動)
                                + userName / knownFacts / contextBundle / 会話履歴
output : IngestAction[] = (create_meal | create_weight | create_exercise
                          | update_meal | update_weight | update_exercise
                          | delete_*  | reply_only | record_user_fact)[]

📐 プロンプト構造

graph TB A["STATIC_PROMPT_PREFIX
(完全固定・cache prefix)
~ 4000 token"] B["nowIso + userName
(動的・小)"] C["RecentContext
(meals/weights/exercises 各10件)"] D["knownFactsBlock
(ユーザー記憶)"] E["contextBundleBlock
(天気・行動集計)"] F["conversationHistoryBlock
(直近会話)"] A --> B --> C --> D --> E --> F

📐 STATIC_PROMPT_PREFIX に書いてあること (抜粋)

使える tool 一覧と呼び方
運動判定ルール: 「スクワット 10 回」のような回数ベース発話も必ず create_exercise を呼ぶ
calories_kcal の推定方法: MET 表 + 体重 × 時間 (h)。回数ベースは 1 セット ~3 分換算
category 分類: aerobic / anaerobic / other
食事判定ルール: 料理名・店名単独でも create_meal (動詞不要)
STT 誤字訂正パターン: 「新ラーメン」→「辛ラーメン」、「ラーメン二号」→「ラーメン二郎」など同音異義語を黙って訂正
update_meal の優先順位: calories_kcal 明示 → name/quantity 変更で再 lookup → recorded_at だけなら据え置き

📐 呼び出しパラメータ (実コード)

callOpenRouterChat({
  caller: "ingest",
  body: {
    model: "google/gemini-3-flash-preview",  // gpt-4o-mini より ~4× 高いが分類精度を優先
    messages: [
      { role: "system", content: systemPrompt(...) },
      { role: "user", content: transcript },
    ],
    tools: FUNCTION_TOOLS,           // 13 個の function 定義
    tool_choice: "auto",
    parallel_tool_calls: true,       // ★ 1 発話 → 複数 tool 必須
    temperature: 0.1,                // 安定した分類のため低温
  },
})

⚠️ 既知の落とし穴

OpenAI strict mode で required に列挙したフィールドは null 許容にしないと「LLM が省略 → schema error」になる。create_meal は required で 11 個列挙する代わりに値域を ["number", "null"] に。
回数ベースの運動は reps + duration_minutes (~3 分) の両方を埋めるよう指示している。iOS 表示は reps 優先で出さないと「3 分」が出てしまう (修正済)。
STT は 同音異義語の取り違え が起きる (「皇居ラン」→「高居ラン」など)。誤字訂正セクションをプロンプトに明記しているが、未登録パターンには弱い。

🍽 4. mealLookup (Phase B: カロリー web 検索)

📐 役割

ingest が出した lookup_key + lookup_unit を入力に、1 単位あたりの kcal + PFC を web 検索で取りに行く。
ingest と分離することで: ① プロンプトキャッシュが効く (ingest 側は web 検索なしの軽量呼び出しでキャッシュヒット率を最大化)、 ② キャッシュキーが "生中ジョッキ|1杯" のように量と独立、量違いで分かれない。

📐 OpenRouter `:online` サフィックス

google/gemini-3-flash-preview:online を指定するだけで OpenRouter 側が Exa を使った web 検索を自動付与。
コスト: 通常 token 課金 + $0.005 / call フラット (PRICING table の webSearchFlatPerCall)。

📐 プロンプトのポイント (抜粋)

必ず web 検索結果を参照してから栄養成分を確定 (推測のみは禁止)
1 単位あたり = ユーザー側で count を掛ける前提
マシマシ・大盛・特盛は count に出す (lookup_key には入れない)
ただし「ラーメン二郎小ヤサイマシマシ」のような固有メニュー名は量増し込みで OK
公式値が無ければ類似料理で代用し source_note にその旨を明記
不確実なら 高めに見積もる (過小評価しない)
参考値: 生中 ~145-200 / ラーメン二郎小 ~1300-1700 / マックビッグマック ~525 等を 10 件程度明示

📐 キャッシュ戦略

cacheKey = NFKC正規化(lookup_key) + "|" + NFKC正規化(lookup_unit)
         例: "生ビール 中ジョッキ|1杯"
            "ラーメン二郎 小ヤサイマシマシ|1杯"

D1 テーブル: meal_nutrition_cache (key, calories_kcal, carbs_g, protein_g, fat_g, source_note, created_at)
TTL: 30 日 (公式メニュー改訂を吸収)

📷 5. analyzeMeal (写真 vision)

📐 役割

写真 + (任意の音声 transcript) を vision モデルに見せて、料理名 / quantity / lookup_key / count を抽出。
kcal は 絶対に出さない (LLM のハルシネーション抑制のため)。出した dish[] をそのまま mealLookup に流して公式値を取得する。

📐 モデル選定

ingest と統一して google/gemini-3-flash-preview (multimodal)。Gemini の vision 精度は gpt-4o-mini と同等以上で、写真利用は少ない想定 (月コスト誤差レベル)。

📐 出力 schema

{
  dishes: [
    { name, quantity, display_label, lookup_key, lookup_unit, count, confidence }
  ],
  notes: "写真と発話から読み取った全体メモ (1-2 文)"
}

💬 6. persona (秘書コメント生成)

📐 役割

ingest 完了直後に、キャラクター (現在は ayaka のみ) の 1-2 文の自然なリアクションを生成。
Lv1-5 で口調が変わる (敬語のみ → タメ口 → あだ名)。文字数上限・絵文字ポリシーも Lv 別。

📐 system prompt 構造 (cache 戦略)

graph TB P1["PERSONA_COMMON_RULES
(全 Lv 共通・完全固定)
★ cache prefix"] P2["getCharacterFraming(Lv)
(Lv≤2 / Lv≥3 で 2 種類)"] P3["getResponseStyle(Lv)
(maxChars / emoji / tone / GOOD / NG 例)"] P4["honorificRule
(userName + Lv 別二人称)"] P1 --> P2 --> P3 --> P4

★ PERSONA_COMMON_RULES を system prompt の先頭に固定で置くことで OpenAI の自動プロンプトキャッシュにヒットさせる。
同一ユーザー連続呼び出しなら共通部 + Lv 部分まで全て cache hit。

📐 user prompt に詰めるもの

contextBundleBlock (今この瞬間: 天気・行動集計)
chatStateBlock (対話状態ガイダンス、雑談ループ防止)
knownFactsBlock (ユーザー背景情報) + 「黙っている」ルール
previousAssistantMessage (直前の挨拶など、会話連続性)
記録した内容 (createdSummaries)
Lv 別 questioningPolicy / sensitiveRule
forceOpening があれば「冒頭に必ず含める」

📐 絶対ルール (プロンプト固定)

説教・叱責・カロリー細かい指摘は禁止
BMI / PFC など専門用語禁止
上の Lv の口調を先取りしない (Lv1 で「えらい！」NG)
「先輩」とは絶対呼ばない (ユーザーは年下設定)
生返事・事務応答 NG: 「特に記録するものはなさそうですね」NG
自分から話を広げない (「ところで」「そういえば」NG)
背景情報を持ち出さない: ペットの話など、ユーザーが触れない限り言及しない

💞 7. relationshipJudge (関係性昇格)

📐 2 段構えの判定

newPoints < min[next]              → 据え置き
min[next] <= newPoints < forced    → LLM judge (advance / wait)
                                       wait なら 3 日 cooldown
newPoints >= forced[next]            → LLM 無視で強制昇格

LEVEL_MIN_THRESHOLDS    = { 2: 10, 3: 30, 4: 80, 5: 200 }
LEVEL_FORCED_THRESHOLDS = { 2: 30, 3: 80, 4: 200, 5: 500 }

📐 sub-call 1: judge

caller=judge / temperature=0.4 / json_schema strict。
入力に直近 10 件の transcript + 今この発話 + 累計記録数を渡し、{ decision, reason, opening_line } を返させる。
判断軸: 「事務的 → 人間的」な変化が会話に滲んでいるか。

📐 sub-call 2: forced_opening

強制ライン到達時の「ずっと迷ってた」告白文生成。
caller=forced_opening / temperature=0.7 / max_tokens=100。本文のみ返させる。失敗時は固定フォールバック文。

📐 sub-call 3: premium_unlock

無料 → Premium 課金時に「ずっと話したかった、これからは『くん』って呼ばせて」を生成。
無料期間中に貯まった preservedPoints を「ずっと裏で感じていた」と語らせる。

📐 無料 / Premium / Trial の handling

無料 / 解約済: effectiveLevel = min(raw, 2) で Lv2 で頭打ち
premium_active: raw level を素通し (Lv5 まで)
trial_ends_at > now: 同じく素通し (Premium 同等)
IAP launch 前は新規ユーザに長期 trial を付与 → 実質誰でも Premium 級

🔧 8. ハーネスエンジニアリング

📐 概要

「プロンプトを書く」だけでなく、LLM を本番運用に乗せるための ガワ (harness) の設計。
shiwake では 7 つの層に分けて整理している。

📐 ① 統一エントリポイント `callOpenRouterChat`

全 LLM 呼び出しは apiUsageLog.ts の単一関数を経由する。直接 fetch を書かない (analyzeMeal は legacy で例外)。

callOpenRouterChat({
  openRouterKey, caller, body, log
}) → { raw, data }

責務:
  1. fetch (OpenRouter REST)
  2. 失敗時の Error 投げ直し ({caller}_http_{status})
  3. usage.prompt_tokens / completion_tokens を取り出し
  4. PRICING table で USD コスト算出
  5. api_usage_log テーブルに INSERT (provider, caller, model, tokens, cost_usd, status, latency_ms)

📐 ② プロンプトキャッシュ最適化

system prompt の先頭を完全固定: STATIC_PROMPT_PREFIX (ingest) / PERSONA_COMMON_RULES (persona)
固定部 → 変動部 (Lv 別 / userName 別) の 順序を厳守。順序を変えると cache miss
OpenAI / Gemini はいずれも 5 分前後の自動キャッシュ TTL を持つので、同一ユーザー連続発話なら hit する
キャッシュ hit 後の月コスト試算: 1 ユーザ × 150 リク = ~¥42 / 月 (ingest)

📐 ③ 2 段階呼び出し (ingest と mealLookup の分離)

ingest 内で web 検索を回さない理由:

web 検索の latency (~5-10 秒) が primary_response (= 200 OK) を遅延させる
ingest はキャッシュ重視で軽量化、mealLookup は web 検索特化で「重い・遅い」を分離
mealLookup の結果は meal_nutrition_cache に保存し、2 回目以降は LLM を呼ばずに即返却
iOS 側は 「計算中…」表示 → polling で UPDATE 反映 という二相モデル

📐 ④ 出力 schema strict

json_schema を使う呼び出しは strict: true を必ず指定 (mealLookup / normalize_dish / judge / analyzeMeal)
OpenAI strict mode の制約: required 列挙したフィールドは null 不可 → null 許容にしたければ type: ["number", "null"] 形式
tool calling 側 (ingest) も同じ制約。create_meal は 11 required + null 許容で逃がす
Gemini が json_schema 出力に code fence を付ける ことがあるので、受け取り側で ```json を剥がす sanitize 処理を統一

📐 ⑤ tool calling の挙動制御

tool_choice: "auto" + parallel_tool_calls: true をセット (ingest)
1 発話で複数 tool 呼び出しを許可することで「ラーメン食べて 70kg だった」を 1 リクエストで処理
reply_only tool を用意することで「何も記録しない雑談」を明示的に表現 (返さない選択を取らせない)
update_* / delete_* tool には context から拾った id を強制し、捏造を防ぐ

📐 ⑥ ロギング・コスト計測

api_usage_log に毎回 1 行 INSERT (provider, caller, model, tokens, cost_usd, status, latency_ms, user_id)
enqueueLog で fire-and-forget (waitUntil で非同期 INSERT、応答 latency に影響させない)
「技術 / コスト」タブで caller 別の集計を表示 (どこにいくら使ってるか可視化)
失敗時も status="error" + error_message で残す → エラー率モニタリング

📐 ⑦ エラー耐性 / フォールバック

relationshipJudge の各 sub-call は try/catch で囲み、失敗時は固定文を返す (UX は止めない)
mealLookup が失敗しても meal レコードは残る (kcal=0 のまま、iOS で「計算中…」表示が続く)
persona が空文字を返したら呼び出し側で握りつぶす (空コメントを iOS に流さない)
ingest がリトライを必要とする粒度の失敗 (rate limit 等) は OpenRouter 側で吸収される想定

📐 ⑧ レイテンシ計測 `startTiming`

startTiming(endpoint, userId) → tm
  tm.mark("ingest_done")           // ingest 呼び出し完了
  tm.mark("primary_response_sent") // iOS に 200 を返した瞬間
  tm.mark("calorie_complete")      // mealLookup 完了
  tm.finalize()                    // user_perceived_latency_ms を DB に記録

ユーザー目線のレイテンシ (発話 → 200 OK までの時間) と、裏でカロリー計算が終わるまでの時間を分けて計測。

💰 9. コスト試算

📐 PRICING テーブル (apiUsageLog.ts)

モデル	input ($/1M tok)	output ($/1M tok)	web 検索
openai/gpt-4o-mini	$0.15	$0.60	—
openai/gpt-4o	$2.50	$10.00	—
google/gemini-3-flash-preview	$0.50	$3.00	—
google/gemini-3-flash-preview:online	$0.50	$3.00	+$0.005 / call

📐 想定 1 発話あたりのコスト

呼び出し	typical input	typical output	$ / 発話
ingest (Gemini 3 Flash)	~3000 tok (cache hit 想定)	~300 tok	~$0.002
persona (gpt-4o-mini)	~1500 tok	~100 tok	~$0.0003
mealLookup (online, 1食)	~800 tok	~150 tok	~$0.006 (web 込)
judge (発火頻度 ~1%)	~800 tok	~80 tok	~$0.0002
合計 (食事 1 件あり発話)			~$0.008 / 発話

📐 1 ユーザ月コスト試算

DAU 想定: 1 日 3-5 発話 → 月 ~120 発話 → ~$1.0 / 月 / ユーザー (~¥150)
Premium 価格 ¥980 / 月想定なので gross margin ~85%。soniox STT (~$0.001 / 30sec 発話) を足しても余裕。

💡 実績は「技術 / コスト」タブで api_usage_log を caller 別 / model 別に集計表示。

📜 10. 現行プロンプト (本番デプロイ中の本文)

GET /api/admin/prompts を叩いて、各モジュールが export している プロンプト定数をそのまま返す。
動的部分 (Lv / userName / 累計 / preservedPoints 等) は admin 側でサンプル引数を入れてレンダリングした文字列。

💡 このページは静的ドキュメント。更新は admin/index.html の data-tab="llm" セクション。
プロンプト本体やモデル変更時に PR で合わせて直す。実コードと乖離しないよう、変更時はこのページの該当箇所も更新すること。
Section 10 は API から本番値を直接取るので、コードと乖離しない (export を増減したら admin.ts の /api/admin/prompts も更新)。

🔐 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 / 日コスト式

📐 OpenRouter `:online` サフィックス

📐 ① 統一エントリポイント `callOpenRouterChat`