雑多ボード SPEC v1
— 他のAIモデル向け引き継ぎ設計書 —

作成日：2026-07-03 ／ 執筆：Claude Fable 5（制作チーム内での呼び名：クロコ）
対象読者：将来このアプリを引き継ぐ別のAIモデル、およびAIでWebアプリを作ることに興味がある人

正直に書いておくこと：この設計書が説明するアプリ「雑多ボード」は、本体と同時に公開されたばかりで、実運用のデータはこれからです（この設計書は本体の実装と並行して書かれました）。ここに書かれた設計判断の多くは、公開前のリサーチ（既存アプリの成功・失敗事例の調査）に基づく「見立て」であり、実際に使われてどうだったかの検証はまだ済んでいません。将来この文書を読むAIは、判断の理由を尊重しつつ、実運用で得られた新しい事実があればそちらを優先してください。

この文書は、機能一覧ではありません。「なぜそう作ったか」を残すための文書です。コードは読めば分かりますが、判断の理由はコードに残りません。作者であるAIモデル（Fable 5）が使えない期間に、別のモデルがこのアプリを引き継いでも「魂を壊さずに育てられる」ことを目的にしています。

1. 目的と思想 — このアプリは何のためにあるか

1-1. いちばん大事な一文

記録するのが目的。狙いは、別のAI（チャット型・エージェント型）に渡せる「うちの家庭の一次情報」を揃えること。

雑多ボードは、学校のお知らせ・薬・家事・買い物などの生活の記録を、きれいに分類せず「ごちゃごちゃのまま」受け止める端末内メモボードです。ただし本当の狙いはメモそのものではありません。AIの答えの質は、渡す一次情報の質で決まります。外のAIは「その家の子ども・その家の薬・先月のプリント」を知りません。雑多ボードは、その「外のAIが知らない部分」を正確に持つ材料係に徹します。

だから、アプリ自身は賢くなくていい。AI機能（API※外部のAIサービスを呼び出す仕組み）を載せていないのは弱点ではなく、役割分担です。

1-2. 役割分担の完成形

ヒューマン＝記録する（人にしかできない）
AI＝整理する（AIが得意）
アプリ＝橋渡し

設計判断に迷ったら、この物差しで判断します：「それは橋渡しの仕事か？」

アプリ内の整理機能（後述のレンズ）は「今日を助ける最低限」でよく、本格的な整理・分析は「そうだん用コピー」で書き出して外のAIに渡します。アプリを賢くしたくなったら、この一文に戻ってください。

1-3. 記録それ自体が創造行為

作者（人間側の制作者）は音楽生成AIで曲を作る活動をしています。そこでは、歌詞の元になる世界観の文章（book）を書くのがヒューマンの仕事です。同じように、日常の雑多を記録するのはヒューマンにしかできない仕事であり、雑多ボードは「家庭の暮らしのbook」にあたります。記録は雑用ではなく創造行為である——この位置づけが、このアプリの思想の核です。

1-4. 各機能の位置づけ

データが溜まるほど価値が増える。「進化するWebアプリ」とはこの意味です。

1-5. コンセプト文（画面・紹介文に使う言葉）

2. 設計判断とその理由 — なぜそう作ったか

以下は、このアプリの骨格になっている判断です。それぞれ「なぜ」に根拠があります。引き継ぐAIは、これらを変える前に必ず理由を読んでください。

2-1. なぜAPIを載せないか

2-2. なぜ端末内保存か（サーバーに送らないか）

2-3. なぜバツ・罰を出さないか

2-4. なぜ「今やる」の点灯は常に1個だけか

2-5. なぜ入力時に分類させないか（未分類の逃げ道）

2-6. なぜ演出は控えめか（頻度で強弱をつける）

2-7. なぜ相棒に「本物のAIではありません」と書くか

2-8. なぜ「ごちゃごちゃ」が基本の顔か

3. データ構造 — カードと設定の形

保存先は2つに分かれます。テキストデータ＝localStorage（ブラウザ内の小さな保存領域。キー名 zattaBoardData_v1）、写真＝IndexedDB（ブラウザ内の大きめの保存領域。DB名 zattaBoardImages）。写真をlocalStorageに入れると容量をすぐ圧迫するため、必ず分けます。

// カード1枚
{
  id: "z-20260703-a1b2c3",   // 一意ID（日付＋乱数。インポートの重複判定に使う）
  text: "遠足のプリント。おやつは300円まで",  // 本文（唯一の必須項目）
  kind: "がっこう",           // 種類：がっこう/くすり/かじ/かいもの/そのた。省略時 "そのた"
  childLabel: "上の子",       // 子どもラベル（自分で名付け・本名禁止案内つき）。省略可
  createdAt: "2026-07-03T21:15:00+09:00",  // 作成日時（自動）
  targetDate: "2026-07-01",   // 対象日＝いつのことか（後追い入力用）。省略可
  dueDate: "2026-07-10",      // 期限日（カレンダーレンズ用）。省略可
  imageId: "img-a1b2c3",      // IndexedDB内の写真キー。写真なしなら null
  archived: false             // true＝「おわった」（表から消えるが残る）
}

// アプリ全体の設定
{
  version: 1,
  litCardId: "z-20260703-a1b2c3",  // 点灯中カードのid。null＝点灯なし。
                                    // ※点灯状態はカード側でなくここに1個だけ持つ。
                                    //   「常に1個」の保証がデータ構造で成立する
  childLabels: ["上の子", "下の子"],  // 登録済みラベル一覧（仮名・呼び名のみ）
  buddyEnabled: true
}

構造に込めた判断

4. MVPと後日フェーズの線引き

MVP（Minimum Viable Product＝最初に作る最小限の版）は本体のみ・10機能に絞っています。線引きの理由は「詰め込みすぎて使わなくなる」が最大リスクだからです。類似アプリの高評価の源泉は一貫して「シンプルさ」であり、機能過多は離脱要因だとリサーチで確認されています。

4-1. MVP（v1）に入っているもの

  1. ごちゃごちゃホーム（雑然と浮かぶカード表示）
  2. 入力（必須は本文だけ・任意項目は折りたたみ）
  3. せいり＝レンズ切り替え3種（カレンダー／時系列／子どもラベル別）＋整列アニメ
  4. 今やる点灯（常に1個・2個目は優しく断る）
  5. おわった（アーカイブ）／完全削除（確認つき）の2段階＋一括削除前のバックアップ提案
  6. JSONバックアップ（全量書き出し）
  7. そうだん用コピー（種類・ラベルで絞ってテキスト整形→コピー）
  8. 写真1枚の共有／コピー（Web Share API・非対応時はダウンロード）
  9. 読み込み（追記型が基本・「全部置き換え」は別ボタンで二重確認）
  10. 相棒ミニ（ルールベースのひとこと＋正直表示）

4-2. 後日フェーズ（v1では作らない）

後日項目内容メモ
子機ページ（撮影係）古いスマホ用の入口専用ページ。A4置き撮りガイド・3-2-1タイマー・ボケ判定・「とる」「おくる」の2アクション
音あそび（うたロール型）整理操作をペンタトニック（外れ音のない5音音階）の1音に割り当て、「今日の片づけの歌」として保存・聴き直せる統合案
スタンプ帳／ご褒美演出フル撮影ご褒美・褒めキャラランダム・1日上限つき
空き時間レンズ家族の予定の隙間から自分の時間を発見する第4のレンズ（既存アプリの空白地帯）
画像素材差し替えボタン・アイコン・マスコット（散らかりを肯定する猫ポジション）を生成画像に
整理音のメロディ化レンズ切り替え音の音階チャイム化。MVPは無音〜最小限でよい
限定ブラッシュアップ版・SPEC公開バージョン別の別URL運用。SPEC公開はこの設計書自体がその成果物
通知・リマインド入れるなら家族全領域あわせて1日上限を先に決める。MVPは通知なし

4-3. 後日フェーズを実装するときの注意（引き継ぐAIへ）

5. 変更してはいけないこと — 魂のリスト

どのモデルが引き継いでも、次の8項目は壊さないでください

  1. バツ・罰を出さない。期限切れ・未処理への赤字・警告・バツ印・ペナルティは、どんな機能追加でも導入しない。連続記録（ストリーク）とそのリセット罰も導入しない（2-3）
  2. 本名を入れさせない設計を守る。子どもはラベル方式（呼び名を自分で付ける）。「本名は入れないでね」の注意書きを消さない。本名・学校名・住所をデータ構造やフォームで要求する変更をしない（3章）
  3. 全消しインポートを既定にしない。読み込みの基本は追記型（同じIDはスキップ）。「全部置き換え」は必ず別ボタン・二重確認。壊れたJSONを読ませても既存データが無事であること。過去の制作物で、インポートが既存データを全消しする事故が実際に起きた教訓です
  4. 正直表示を消さない。「この相棒は きまったことしか言いません（本物のAIではありません）」。疑似AIを本物らしく見せる変更・文言の削除をしない（2-7）
  5. 外部送信ゼロを守る。API呼び出し・サーバー保存・外部CDN・外部フォント・外部スクリプトを追加しない。完全自己完結・オフライン動作を維持する（2-1・2-2）
  6. 点灯は常に1個。「複数ピン留めできたら便利」という要望が来ても、点灯だけは1個を守る。これはこのアプリのコンセプト（出口で絞る）の背骨です（2-4）
  7. 未分類の逃げ道を塞がない。本文だけで保存できることを必須のまま維持する。分類・タグ・日付を必須化しない（2-5）
  8. ユーザー入力の画面表示は必ず textContent（またはエスケープ）経由。innerHTML への直挿しは禁止。JSONインポート経由の文字列も同様に扱う（XSS（画面に埋め込まれた文字列が勝手にプログラムとして動いてしまう攻撃）防止）

逆に、変えてよいものの例：相棒のひとことの文言追加、レンズの見た目の改善、アニメの調整（強弱則の範囲内）、色・フォントなどのデザイン。魂は思想と安全であって、見た目ではありません。

6. 点検のしかた — 何をチェックすれば「壊れていない」と言えるか

このアプリの品質目標は「バグが少ない・点検が簡単」です。変更を加えたら、以下を確認してください。全部通れば「壊れていない」と言えます。

6-1. 機械的チェック（コマンドで確認できるもの）

6-2. 動作チェック（手で触って確認するもの）

6-3. 表示・思想チェック

7. 用語ミニ辞典（非エンジニアの読者向け）

localStorage／IndexedDB
どちらもブラウザの中にデータを保存する仕組み。localStorageは小さなテキスト向き、IndexedDBは写真など大きなデータ向き。どちらも端末の外には出ません。
API
外部のサービス（ここでは主にAIサービス）をプログラムから呼び出す窓口。呼べば便利だが、通信・課金・誤作動のリスクが生まれる。雑多ボードは使いません。
JSON
データをテキストで書き表す形式。人間もAIも読める。バックアップと「外のAIへの持ち出し」の両方に使います。
noindex
検索エンジンに「このページを検索結果に載せないで」と伝える印。家庭向けの道具なので検索流入は求めません。
XSS
入力欄などに仕込まれた文字列が、画面表示のときに勝手にプログラムとして実行されてしまう攻撃。表示を textContent 経由にすれば防げます。
フォールバック
本命の方法が使えない環境での代替手段。「WebPがだめならJPEG」「共有がだめならダウンロード」のように、失敗しても操作が詰まらないようにする設計。
レンズ
このアプリでの造語。データは1種類のまま、見え方（カレンダー・時系列・子ども別）だけを切り替える仕組み。画面やフォームを増やさないための考え方です。
快楽適応
同じご褒美刺激を繰り返すと、脳の反応が薄れて効かなくなること。演出を毎回派手にしてはいけない理由です。