← 一覧に戻る

ダッシュボード構築 Phase 0: 調査報告書

2026年4月16日 08:06 更新
MD から自動変換されたページです。内容について質問があれば右下の ? ボタンからどうぞ。

§1 meshi-tero リポジトリ調査結果

1.1 リポジトリ概要（実ファイル確認済み）

1.2 ディレクトリ構造（2階層、抜粋）

meshi-tero/
├── app/                      # expo-router のファイルベースルーティング
│   ├── _layout.tsx           # SQLiteProvider 初期化 + DB マイグレーション
│   ├── onboarding.tsx
│   └── (tabs)/               # ホーム/履歴/設定の3タブ
├── components/               # React Native コンポーネント (FoodInput.tsx 等)
├── hooks/                    # useMeals / useFoodSearch / useScanner 等
├── lib/                      # 純粋ロジック層 <- ★ダッシュボード組込みで狙う層
│   ├── db.ts                 # SQLite CRUD (18KB)
│   ├── gemini.ts             # Gemini API クライアント (25KB)
│   ├── nutrition.ts          # BMR/TDEE 計算
│   ├── off.ts                # Open Food Facts API
│   └── ocr-validation.ts     # OCR バリデーション
├── data/                     # 食品マスタ (シード)
│   ├── seed-foods.json       # 35KB, 156品
│   ├── mext-foods.json       # 572KB, 文科省食品成分表
│   ├── off-japan-foods.json  # 5.5MB, Open Food Facts 日本版
│   └── cvs-foods.json        # 253KB, コンビニ3社スクレイピング
├── scripts/                  # 食品マスタ生成スクリプト (独立 package.json)
├── types/index.ts            # 型定義
└── __tests__/                # Jest 168件

1.3 食事データ構造（スキーマ引用）

SQLite スキーマ（app/_layout.tsx:62-113）:

CREATE TABLE foods (
  id TEXT PRIMARY KEY,
  name TEXT, brand TEXT,
  calories REAL, protein REAL, fat REAL, carbs REAL,
  source TEXT DEFAULT 'seed',
  barcode TEXT
);

CREATE TABLE meals (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  date TEXT,                                       -- "YYYY-MM-DD"
  meal_type TEXT CHECK (meal_type IN ('breakfast','lunch','dinner','snack')),
  food_id TEXT,
  custom_name TEXT,
  calories REAL, protein REAL, fat REAL, carbs REAL,
  followed_command INTEGER DEFAULT 0,              -- AI命令に従ったか
  created_at TEXT DEFAULT (datetime('now'))
);

TypeScript 型（types/index.ts）:

export type MealRecord = {
  id: number;
  date: string;                                     // "YYYY-MM-DD"
  mealType: 'breakfast' | 'lunch' | 'dinner' | 'snack';
  foodId?: string;
  customName?: string;
  calories: number;
  protein: number;
  fat: number;
  carbs: number;
  followedCommand: boolean;
  createdAt: string;
};

実データサンプル（data/seed-foods.json:1-30）:

[
  {
    "id": "seven-salad-chicken-plain",
    "name": "サラダチキン プレーン",
    "brand": "セブンイレブン",
    "calories": 114,
    "protein": 24.1,
    "fat": 1.2,
    "carbs": 1.0,
    "source": "seed"
  }
]

1.4 流用可能な資産の表

層 ファイル 関数 流用可否
DB lib/db.ts addMeal, getMealsByDate, searchFoods, insertOffFood, insertOcrFood OK: expo-sqlite -> better-sqlite3（既に devDependency 存在）に差し替えで Node 側で動く
AI lib/gemini.ts estimateNutrition, ocrNutritionLabel, identifyProductFromPhoto, generateCommand OK: 純関数、環境変数だけ差し替えで動作
計算 lib/nutrition.ts calcBMR, calcTDEE, calcDailyTarget, calcRemaining OK: 純関数
食品API lib/off.ts fetchOffProduct (Open Food Facts) OK: fetch 依存のみ
食品マスタ data/*.json (データ) OK: 総計 6MB 程度、静的ロードで使える
HTTP層 — — NG: 未実装（Express/Hono 無し。自作アダプタ必須）
CLI — — NG: bin フィールド無し、CLI 非公開

1.5 入力経路と保存先

1.6 ダッシュボード組込みの最小アダプタ設計

lib/ の純関数群を Node 環境から直接呼び出すのが最短ルート。具体的には:

  1. expo-sqlite 依存を better-sqlite3（既に devDependencies に存在）に差し替え
  2. lib/db.ts をそのまま Node 側 CLI から import
  3. ダッシュボードの食事入力は node meshi-tero-cli.ts add --text "おにぎり" -> 内部で estimateNutrition() -> addMeal() -> meal/YYYY-MM-DD.md に追記
  4. 型契約は types/index.ts の MealRecord をそのまま使う（追加型定義ゼロ）

⚠️ 判断ポイント: meshi-tero は SQLite 前提の設計。ダッシュボードは Markdown ファイル前提（§3 参照）。SQLite を正本にするか、Markdown を正本にするかは健人に確認必須（§6-Q1）。

§2 Apple Health ブリッジ調査結果

2.1 比較表（App Store アプリ）

アプリ 料金 送信先 Webhook POST 自動化 推奨度
Health Auto Export – JSON+CSV 無料/買切 $2.99/Premium $6.99/年 REST API, MQTT, iCloud Drive, Home Assistant OK: 完全対応（任意 URL + ヘッダー指定可） 秒〜月で自由設定（Premium 必須） ★★★
Health Assistant Link $1.99/月 Home Assistant 専用 △ HA webhook のみ Shortcuts 経由で1日3回 ★★
Health Exporter & Shortcuts $0.99 買切 Shortcuts チェーン経由で POST 可 △ アプリ内 URL 設定は無し Shortcuts オートメーション次第 ★
HealthFit $6.99 買切 Strava / TrainingPeaks 等25サービス NG 自動同期 NG（目的外）
QS Access 無料 手動 CSV エクスポート NG 無し NG（メンテ停止気味）

Health Auto Export が唯一「非エンジニアがアプリ設定画面だけで任意 URL に JSON を POST できる」製品。公式の REST API 設定ガイドも存在:

2.2 OSS 一覧表

リポジトリ スター 最終更新 ライセンス 内容 推奨度
Lybron/health-auto-export 217 2026-04-09 未記載 Health Auto Export の API 仕様ドキュメント専用リポジトリ（アプリ本体ではない、JSON スキーマの公式仕様） ★★★（仕様参照用）
gregt1993/Health_Bridge 29 2026-04-10 MIT Home Assistant カスタム統合（Python）。iOS アプリ「Health Assistant Link」とセット ★★（HA ある場合のみ）
MaximeHeckel/healthpulse 22 2017 年コード 未記載 React Native 製 iOS アプリ。HealthKit -> 任意エンドポイント POST ⚠️ 検証不十分（9年前のコード、現行 RN で動作困難）
WeaveHubHQ/healthsync-ha 1 2026-04-05 未記載 HA 統合の新興版 ⚠️ 検証不十分（スター 1）

2.3 iOS Shortcuts 単体での実現可能性

結論: 可能。ただし Health Auto Export の下位互換。

2.4 推奨順位

  1. Health Auto Export Premium（$6.99/年） — 非エンジニアが追加コードゼロで導入可。JSON フォーマットは Lybron の公式リポジトリに仕様がある
  2. iOS Shortcuts 単体（無料） — 歩数・体重・睡眠だけなら追加アプリ不要。PoC 用途に最適
  3. Health Assistant Link + Health_Bridge（$1.99/月 + HA 環境） — Home Assistant を既に運用してる人向け。健人は使ってないので対象外

§3 案A ダッシュボード実装方針

3.1 データ蓄積場所

推奨: ~/dashboard-data/（新規作成）

現状: /Users/aiharataketo/dashboard-data/ は未作成（Glob で確認済み）

代替案:

健人は Markdown + grep で運用する文化なので、Markdown ファイル + 日付1ファイルの構成が整合する。

3.2 ファイル構造

~/dashboard-data/
├── diary/
│   └── YYYY-MM-DD.md           # 日記（自由テキスト）
├── meal/
│   └── YYYY-MM-DD.md           # 食事（meshi-tero MealRecord を YAML frontmatter 化）
├── workout/
│   └── YYYY-MM-DD.md           # 筋トレ（種目・重量・レップ）
├── health/
│   └── YYYY-MM-DD.json         # Apple Health 生データ (Health Auto Export の POST を保存)
└── cache/
    └── dashboard-summary.json  # 集計済み中間データ（HTML 生成高速化用）

3.3 データ構造例（実サンプル）

meal/2026-04-11.md

---
date: 2026-04-11
total:
  calories: 1820
  protein: 95.2
  fat: 58.3
  carbs: 215.4
target_compliance: 0.78
---

## 朝 07:30
- **おにぎり（鮭）** セブンイレブン
  - 180 kcal / P4.5 / F1.2 / C38.0
  - source: seed

## 昼 12:15
- **サラダチキン プレーン** セブンイレブン
  - 114 kcal / P24.1 / F1.2 / C1.0
  - source: seed
- **ブランパン 2個入** ローソン
  - 120 kcal / P10.6 / F4.4 / C11.4

## 夜 20:00
- **麻婆豆腐定食** (AI推定)
  - 720 kcal / P28.0 / F32.0 / C75.0
  - source: ai

workout/2026-04-11.md

---
date: 2026-04-11
duration_min: 55
volume_total_kg: 8640
---

## 胸
- ベンチプレス: 60kg x 8 x 3
- インクラインダンベル: 22kg x 10 x 3

## 三頭
- ケーブルプレスダウン: 25kg x 12 x 3

diary/2026-04-11.md

---
date: 2026-04-11
mood: 7
tags: [dashboard, 調査日]
---

今日はダッシュボード構築の Phase 0 調査を走らせた。
meshi-tero の lib/ 層が想像以上にきれいで、アダプタ薄くて済みそう。

health/2026-04-11.json

{
  "source": "health-auto-export",
  "received_at": "2026-04-11T23:59:00+09:00",
  "metrics": {
    "steps": 8324,
    "weight_kg": 72.3,
    "resting_heart_rate": 58,
    "hrv_ms": 45.2,
    "sleep": {
      "total_min": 412,
      "rem_min": 88,
      "deep_min": 52,
      "light_min": 272
    },
    "active_energy_kcal": 485
  }
}

3.4 データフロー図（ASCII）

+----------+    ntfy push / POST    +--------------------+
| iPhone   |----------------------->| 秘書 (Telegram Bot)|
| (Health  |                        | or webhook 受信    |
|  Auto    |                        +---------+----------+
|  Export) |                                  |
+----------+                                  | 書込
                                               v
+----------+    自由会話             +--------------------+
| 健人     |----------------------->| Claude Code        |
| (PC/iOS) |  「おにぎり食べた」     | (dashboard skill)  |
+----------+                        +---------+----------+
                                               | Write
                                               v
                                   ~/dashboard-data/
                                   +- diary/*.md
                                   +- meal/*.md
                                   +- workout/*.md
                                   +- health/*.json
                                               |
                                   convert-dashboard.sh (集計)
                                               v
                                   ~/plan-viewer/dashboard.html
                                               |
                                   Tailscale Funnel (HTTPS)
                                               v
                                   +--------------------+
                                   | スマホ PWA ホーム  |
                                   +--------------------+

3.5 HTML レイアウト案（dashboard.html）

既存 ~/plan-viewer/index.html の Zenn 風ダークテーマ（背景 #0d223a）を踏襲。

+-----------------------------------------+
| ダッシュボード              2026-04-11  |  <- ヘッダ
+-----------------------------------------+
| [icon] 今日の栄養          [編集]       |
|   1820 / 2200 kcal    ########.. 82%    |
|   P 95g  F 58g  C 215g                  |
+-----------------------------------------+
| [icon] 筋トレ              [編集]       |
|   55分  総重量 8.6t  (胸/三頭)          |
+-----------------------------------------+
| [icon] Apple Health        [同期]       |
|   歩数 8324  HRV 45ms                   |
|   睡眠 6h52m (REM 1h28m / Deep 52m)     |
+-----------------------------------------+
| [icon] 今日の日記          [編集]       |
|   今日はダッシュボード構築...           |
+-----------------------------------------+
| [icon] 最近の記事 (plan-viewer 統合)    |
|  ・2026-04-11 転職PJ dispatch計画       |
|  ・2026-04-11 ファクトチェック...       |
|  ・2026-04-10 ...                       |
|                             [全件表示]  |
+-----------------------------------------+

3.6 集計スクリプト

3.7 動線図

iPhone ホーム画面 (PWA アイコン)
        v タップ
Tailscale Funnel URL (https://<machine>.<tailnet>.ts.net/dashboard.html)
        v
dashboard.html (サマリー表示)
        v 下スクロール
plan-viewer 記事リスト (最新5件) -> [全件表示] -> index.html

§4 skill 化案

4.1 参考にした既存 skill（実ファイル確認済み）

~/.claude/skills/tmux/:

tmux/
├── SKILL.md
├── scripts/tmux.py          # 17KB, 主実装
└── references/tmux-gotchas.md

SKILL.md の frontmatter 抜粋:

name: tmux
description: |
  tmux でヘッドレスセッションを管理する。...
  Triggers: "tmux", "tmuxで", "tmuxでテスト", "tmuxで検証", ...

~/.claude/skills/work-log/: frontmatter + Bash コマンド実行手順のみのシンプル構成。

~/plan-viewer-plugin/skills/plan-viewer/ (plugin 実体):

plan-viewer-plugin/skills/plan-viewer/
├── SKILL.md                 # トリガー・発火条件・書き込み先
└── references/
    ├── page-template.md     # HTML テンプレート
    └── writing-guide.md     # 文体ルール

パターン抽出:

4.2 dashboard skill のディレクトリ構造案

~/.claude/skills/dashboard/
├── SKILL.md                    # トリガー・発火条件・分岐ルール
├── references/
│   ├── meal-template.md        # meal/*.md のテンプレート
│   ├── workout-template.md     # workout/*.md のテンプレート
│   ├── diary-template.md       # diary/*.md のテンプレート
│   ├── intent-patterns.md      # 意図検出の正規表現/キーワード集
│   └── convert-guide.md        # convert-dashboard.sh の使い方
└── scripts/
    ├── add-meal.ts             # 食事追加 (meshi-tero lib/ を import)
    ├── add-workout.sh          # 筋トレ追加
    ├── add-diary.sh            # 日記追加
    └── convert-dashboard.sh    # HTML 再生成

4.3 SKILL.md 骨子案

---
name: dashboard
description: |
  健人の日次ダッシュボード（日記/食事/筋トレ/Apple Health）に自由会話で記録を追加する。
  Triggers on:
    - 食事: 「〇〇食べた」「朝ごはん」「昼食」「夕飯」「おやつ」「カロリー」
    - 筋トレ: 「ベンチ」「スクワット」「デッド」「〇kg」「〇レップ」「〇セット」「筋トレ」
    - 日記: 「今日は」「〇〇だった」「気分」「日記」
    - Apple Health: 「歩数」「体重」「睡眠」
    - 集計: 「ダッシュボード見せて」「今日のまとめ」「dashboard.html 再生成」
  Do NOT use for:
    - plan-viewer の記事作成 (-> plan-viewer skill)
    - Obsidian への長文メモ (-> work-log skill)
---

4.4 自由会話の意図検出パターン（3つ以上）

パターン1: 食事追加（meal）

入力例:

検出ロジック:

  1. 食品名 or 食べ物系名詞（「食べた」「食った」「食事」「朝/昼/夕/おやつ」）を含む
  2. -> meshi-tero の lib/gemini.ts:estimateNutrition() を呼んで栄養推定
  3. -> ~/dashboard-data/meal/$(date +%F).md に追記
  4. -> convert-dashboard.sh で HTML 再生成

出力（Claude が返すべき確認メッセージ）:

食事を記録したわ：
- おにぎり（鮭）180kcal / P4.5 / F1.2 / C38.0
  -> ~/dashboard-data/meal/2026-04-11.md

今日の累計: 1820 / 2200 kcal (82%)

パターン2: 筋トレ追加（workout）

入力例:

検出ロジック:

  1. 正規表現（「種目名 + 重量 + レップ x セット」）で抽出
  2. 複数種目は区切り文字（「と」「、」改行）でパース
  3. -> ~/dashboard-data/workout/$(date +%F).md に追記
  4. -> convert-dashboard.sh で HTML 再生成

出力:

筋トレ記録したわ：
- ベンチプレス: 60kg x 8 x 3 (volume 1440kg)
  -> ~/dashboard-data/workout/2026-04-11.md

パターン3: 日記追加（diary）

入力例:

検出ロジック:

  1. 「今日は」「今日の日記」「気分」「メンタル」で始まる自由文
  2. 食事・筋トレパターンに該当しない任意の感情・出来事
  3. -> ~/dashboard-data/diary/$(date +%F).md に追記（既存ファイルがあれば末尾追記、frontmatter の mood は最新値で更新）

出力:

日記に追記したわ：
- 今日は疲れた
  -> ~/dashboard-data/diary/2026-04-11.md

パターン4: 集計・再生成（convert）

入力例:

検出ロジック:

  1. convert-dashboard.sh を実行
  2. 結果を要約して返す（Tailscale Funnel URL も併記）

4.5 秘書セッション以外での起動可否

可能。skill は ~/.claude/skills/ 直下に配置するため、main/desktop セッションの Claude Code からも同じトリガー語で起動する。

⚠️ 秘書セッションは Telegram 送信ルール（太字記法の制約、MarkdownV2 ヘルパー必須）に従う必要がある。

§5 実装ロードマップ

方針: 小さく動かして即確認。各ステップで dashboard.html が1歩進化する設計。

Step 1: データ土台の準備

Step 2: 集計スクリプトと初期 HTML

Step 3: dashboard skill のスケルトン

Step 4: meshi-tero ブリッジ（食事入力の本実装）

Step 5: Apple Health 連携

Step 6: PWA ホーム追加と最終調整

Step 7: 筋トレ・日記の肉付け

優先度判断

§6 未解決事項（健人に判断仰ぎたい点）

Q1: meshi-tero とダッシュボードのデータ正本をどちらにするか

選択肢:

推奨度: 案A ★★★（grep 可能・git diff 可能・YAGNI 原則）、案B ★、案C NG

Q2: Apple Health の Premium $6.99/年 を払うか

選択肢:

推奨度: 案A ★★★（非エンジニアの健人が設定画面だけで完結、年 $6.99 は十分安い）

Q3: Gemini API キーの共有

meshi-tero は EXPO_PUBLIC_GEMINI_API_KEY を使ってる。ダッシュボード側でも同じキーを流用するか、別キーを切るか。

選択肢:

推奨度: 案A ★★（最短）

Q4: Tailscale Funnel の配信パス

現状 ~/plan-viewer/ 全体が Tailscale Funnel で配信されてる想定だが、配信ルートに dashboard.html を追加するだけでいいか、別の手続きが必要か。

-> 既存の index.html と同じディレクトリに置けばそのまま配信される見込みだが、ポート番号・サーバー起動方法の確認必須（plan-viewer-plugin/scripts/server.py があるので、これを使う場合は要確認）。

Q5: 秘書経由の記録と PC 直接記録の衝突

同じ日に秘書セッションと PC セッションから同時に meal/2026-04-11.md に追記した場合、ファイルロックや競合処理はどうするか。

選択肢:

推奨度: 案B ★★★（健人1人の運用、同時書き込みの確率は低い）

Q6: skill の具体的な発火境界（誤検出回避）

「今日は疲れた」は diary だが、「今日はベンチ 60kg 調子良かった」は workout + diary のハイブリッド。パターン優先度をどう決めるか。

選択肢:

推奨度: 案A ★★★（確定的ルール、パフォーマンス良い）+ 曖昧な場合のみ案C にフォールバック

付録: 主要ソース URL 一覧

Apple Health

meshi-tero 参照ファイル（ローカル）

plan-viewer 参照ファイル（ローカル）

調査員からの一言: 案A は筋が良いわ。meshi-tero の lib/ がきれいに純関数で切れてるから、アダプタ薄くて済む。最大のリスクは Apple Health で、Health Auto Export の Premium を払えば解決するけど、それを待たずに Step 1〜3 は先行で進められる設計にしてある。健人が §6 の Q1/Q2 に即答できれば、翌日には dashboard.html の MVP が立ち上がるはずよ。

§7 UX 設計論に基づく動線設計

このセクションは §3 の実装方針を UX（User Experience = 使い心地）理論で検証し、「作った後に使われない」リスクを事前に潰すための分析。4つの古典的フレームワークを適用し、日記 / 食事記録 / 筋トレ記録 / plan-viewer ホーム画面 の4動線に対して 4 × 4 = 16 セルで網羅的に検討する。

7.1 適用する4フレームワーク（理論概要は最小限）

F1. JTBD（Jobs To Be Done）

出典: Clayton Christensen（ハーバードビジネススクール教授、『イノベーションのジレンマ』著者）, 2003年頃から体系化。

要点: 人はプロダクトを機能 (tool) ではなく、片付けたい仕事 (progress) のために「雇う」。ダッシュボードを「データを見る場所」ではなく「健康的な生活に向けた前進を確認する手段」として定義する必要がある。

F2. B=MAT（Behavior = Motivation × Ability × Trigger）

出典: BJ Fogg（スタンフォード大学行動デザイン研究所所長、『Tiny Habits』著者）。

要点: 行動は 動機 (Motivation) × 実行容易性 (Ability) × きっかけ (Trigger) の3要素の積。どれか1つが 0 なら行動は起きない。記録が続かないのは3つのどこかがゼロだから。

F3. Forcing Function（強制機能）

出典: Don Norman（認知科学者、『誰のためのデザイン？ (The Design of Everyday Things)』著者、Apple 元 UX 責任者）。

要点: 使い手のミスや忘却を物理構造で物理的に不可能にする設計。代表例は「ガソリンスタンドのノズルを戻さないと車が動かない」設計。Constraint Design（制約設計）と Mapping（対応付け）の2原則で構成される。

F4. Cognitive Load Theory（認知負荷理論）

出典: John Sweller（ニューサウスウェールズ大学教授）、1988年。

要点: 人間のワーキングメモリは 4 ± 1 個の情報チャンク (chunk = 意味のまとまり) しか保持できない。ダッシュボード起動 5 秒で見えるべき情報は 4 チャンク以下に絞る。それ以上は認知負荷超過で離脱する。

7.2 動線1: 日記（diary）

JTBD

健人は日記を 「今日の自分の状態を未来の自分に引き継ぐため」 に雇う。tool = Markdown 追記機能、progress = 過去の自分と対話して行動パターンを発見すること。

B=MAT 現状評価

要素 スコア 根拠
Motivation 2 / 5 日記は即座の報酬が薄い。書いた瞬間の達成感は低く、価値は数ヶ月後の見返しで初めて生まれる
Ability 4 / 5 「今日は疲れた」の1文でも記録完了する skill 設計なら摩擦は極小
Trigger 1 / 5 健人に「今日日記書こう」という固定 trigger が現状無い。就寝前の習慣が未確立

ボトルネック: Trigger が 1。ここを 3 以上に上げないと日記動線は死ぬ。

Forcing Function 具体案

Cognitive Load 最小化

ダッシュボードの日記カードに表示する情報を 3 チャンク以下 に絞る:

  1. 過去 7 日の mood 棒グラフ（7本のバーのみ、数値ラベルなし）
  2. 今日の最新 1 行（冒頭 40 文字まで、続きは展開）
  3. [編集] ボタン

それ以上の情報（月次サマリー、タグ集計等）は展開操作で初めて出す。

7.3 動線2: 食事記録（meal）

JTBD

健人は食事記録を 「コンビニ飯中心の生活でも PFC バランスが崩れてないことを確認して、罪悪感を減らすため」 に雇う。tool = カロリー計算、progress = 「今日の夜に何を足せば良いか」の判断。

B=MAT 現状評価

要素 スコア 根拠
Motivation 4 / 5 健康管理への関心は強い（meshi-tero を自作するほど）。即座の報酬として「累計 kcal が見える」がある
Ability 3 / 5 「おにぎり食べた」の1行で記録できるのは強いが、AI 推定の待ち時間（Gemini API で数秒）が発生
Trigger 2 / 5 食事の時刻は毎日あるが、食後に記録する習慣が固定化されていない

ボトルネック: Trigger が 2。Ability も 3 で、AI 待ち時間がボトルネック。

Forcing Function 具体案

Cognitive Load 最小化

食事カードに表示する情報を 4 チャンク以下 に絞る:

  1. 今日の累計 kcal / 目標 kcal（進捗バー 1本）
  2. PFC の3数値（グラム単位、色分けなし、単純な数字）
  3. 残り kcal で食べられるコンビニ食品の推奨1品（meshi-tero の generateCommand() を流用）
  4. [記録] ボタン

グラフ系の詳細（時間帯別推移、source 別内訳）は展開操作で初めて出す。

7.4 動線3: 筋トレ記録（workout）

JTBD

健人は筋トレ記録を 「前回の自分を超えたかを確認し、progressive overload (漸進性過負荷) のエビデンスを残すため」 に雇う。tool = 重量記録、progress = 「前回より伸びた」という自己肯定。

B=MAT 現状評価

要素 スコア 根拠
Motivation 4 / 5 筋トレ自体の動機が強い健人にとって、記録は筋トレの一部と認識されやすい
Ability 4 / 5 「ベンチ 60kg 8x3」の構文が簡潔。正規表現パースで meshi-tero の栄養 AI 呼出しが不要な分、即時完了
Trigger 3 / 5 ジム入館が物理 trigger として機能する。ただしジムに行かない日は trigger 消失

ボトルネック: 全体的にスコア高いが、休養日に trigger が消えるのが唯一の弱点。

Forcing Function 具体案

Cognitive Load 最小化

筋トレカードに表示する情報を 3 チャンク以下 に絞る:

  1. 今日の総 volume（重量 × レップ × セットの総和、1つの数字）
  2. 今日やった部位タグ（「胸 / 三頭」のチップ表示）
  3. 最新種目の PR 差分（「ベンチ 60kg +2.5kg」の1行）

過去履歴グラフやセット詳細は展開操作で初めて出す。

7.5 動線4: plan-viewer ホーム画面

JTBD

健人は plan-viewer ホームを 「過去に自分が考えたことを外部記憶として呼び出し、今の意思決定に再利用するため」 に雇う。tool = HTML 一覧、progress = 「あれ、前にこれ考えたな」→ 即座にアクセス。

B=MAT 現状評価

要素 スコア 根拠
Motivation 5 / 5 既に 127 件の記事が蓄積されている実績が動機の強さを示す
Ability 4 / 5 HTML クリックで開くだけ、非常に軽い。検索機能の有無が次の改善点
Trigger 2 / 5 能動的に「前の記事を見る」という trigger が発生しにくい。受動的な呼出しが主

ボトルネック: Trigger が 2。能動的に見に行く機会が少ない。

Forcing Function 具体案

Cognitive Load 最小化

plan-viewer 統合カードに表示する情報を 4 チャンク以下 に絞る:

  1. 最新 5 件のタイトルのみ（日付プレフィックス付き、本文抜粋なし）
  2. 「📅 過去の今日」セクション（該当記事があるときだけ表示、無ければこのチャンクは消える）
  3. 総記事数（127 のような単純な数字で蓄積感を演出）
  4. [全件表示] ボタン（既存 index.html へジャンプ）

タグ検索・全文検索は展開操作で初めて出す（§3.7 の動線図の Step 2 以降）。

7.6 16 セル分析サマリー表

日記 食事記録 筋トレ記録 plan-viewer
JTBD 未来の自分への引継ぎ コンビニ飯の罪悪感低減 progressive overload の証跡 外部記憶の再利用
B=MAT M 2 (報酬遅延) 4 (健康関心) 4 (筋トレ動機) 5 (蓄積実績)
B=MAT A 4 (1行で完了) 3 (AI 待ち) 4 (構文簡潔) 4 (クリックのみ)
B=MAT T 1 (習慣未確立) 2 (時刻 trigger 弱) 3 (ジム入館) 2 (能動 trigger 薄)
Forcing Function 就寝時刻 ntfy + 秘書 1行質問 時刻 trigger + 未記録バナー 位置情報 trigger + PR 差分表示 ダッシュボード統合 + 過去の今日
Cognitive Load 3 chunk (mood 棒/最新1行/編集) 4 chunk (kcal/PFC/推奨/記録) 3 chunk (volume/部位/PR 差分) 4 chunk (最新5件/過去今日/総数/全件)
最重要ボトルネック Trigger=1 Trigger=2 + Ability=3 休養日の Trigger 消失 Trigger=2

7.7 §3 実装方針への具体的な反映

§7 の分析結果から、§3 の実装方針に対して以下 5 点の変更・追加を提案する。

反映1: ダッシュボード画面構造の最上段配置ルール

§3.5 の HTML レイアウト案を以下の優先順位で並び替え（Cognitive Load × ボトルネック分析の結論）:

  1. 最上段: アラート系（「昨日の昼食未記録」「最終筋トレから 3 日」「📅 1年前の今日」のいずれか、該当する場合のみ表示）
  2. 栄養カード（Motivation 最高、日次で最も参照される）
  3. 筋トレカード（Motivation 高、PR 差分がモチベ維持要素）
  4. Apple Health カード（受動データ、自動更新）
  5. 日記カード（Motivation 低、深いエンゲージメント用）
  6. plan-viewer 統合（Trigger 弱、下部に置くことで受動的に遭遇させる）

理由: Cognitive Load Theory に基づき、5 秒で見える上位 3 枚は「Motivation が高く、即座の報酬がある」ものに限定する。日記は Motivation が低いため上位に置くと認知負荷の無駄遣いになる。

反映2: ntfy 通知トリガーの設計（3種類の trigger）

§3 のデータフロー図に ntfy トピック aihara-64d1132d60c2 を使った3種類の trigger を追加:

trigger 名 発火条件 目的 対応動線
meal-timer 過去 meal データから学習した食事時刻 + 30 分 食事記録の Trigger=2 → 4 へ改善 食事
workout-geo ジム位置情報離脱 + 30 分（iOS Shortcuts 経由） 筋トレ記録の即時性担保 筋トレ
diary-bedtime Apple Health の sleep schedule 開始時刻 日記の Trigger=1 → 3 へ改善 日記

全 trigger は 1日1回まで発火（嫌がらせ防止の Forcing Function 的制約）。ユーザーが dismiss した場合はその日は再送しない。

反映3: 記録ボタンの配置と誤タップ防止構造（Forcing Function の Constraint Design）

§3.5 のカード内 [編集] ボタンに対する制約設計:

反映4: 「過去の今日」セクションの自動生成ロジック

§3.6 の convert-dashboard.sh に以下を追加:

対応する JTBD: plan-viewer の「外部記憶の再利用」を能動的な呼出しから受動的な再会に転換する。

反映5: §5 実装ロードマップへの Step 追加提案

§5 の Step 2 と Step 3 の間に Step 2.5「ボトルネック検証」 を追加:

理由: B=MAT で Trigger が最重要ボトルネックと判明したため、実装直後に定量検証できる仕組みを入れる。これを後回しにすると「作ったけど使われない」リスクが現実化する。

§7 の結論: 日記と plan-viewer は Trigger 不足で放置される構造、食事は AI 待ち時間が Ability を削る構造、筋トレは休養日 trigger 消失が唯一の弱点。ntfy の3種 trigger と「過去の今日」セクションが、4動線中 3 動線のボトルネックを同時に解決する打ち手になる。§3.5 のレイアウト並び替え（Motivation 高のカードを上段）と Step 2.5 のボトルネック検証を §5 に組み込めば、Phase 0 の MVP は「作られた後に使われる」ダッシュボードとして立ち上がるはずよ。

📝 質問モード — テキストを選択してね
✓ 質問を送信しました