HIBI — 要件定義書 兼 Claude Code 実装指示書

版数 1.0（DBレス構成 / 記事埋め込み型デモ）／ 作成日 2026-08-24 ／ 発行 ソウゾウ合同会社 用途 SEO記事「【デモで試せる】Claude Codeで日報アプリを自作する方法と費用｜動画つき資料【2026年】」に組み込む実演デモ

このドキュメントの使い方（Claude Code へ）

これ1枚が、規約・仕様・タスクのすべて。リポジトリ直下に CLAUDE.md として置き、毎回読み込むこと。

• 実装は「12. 実装タスク」の順に進める。フェーズを飛ばさない。
• 各タスクの括弧内は要件ID。着手前に該当章を読むこと。
• 仕様がここに書かれていない場合は、推測で実装せず質問する。
• スコープ外（3章 Won't have）は、思いついても実装しない。
• 「デモだから」を理由に品質を落とす判断はしない。
• この領域だけの特別ルール：入力を増やす機能を提案しない。 日報アプリの失敗はすべて「書くのが面倒」から始まる。機能追加を思いついたら、まず「入力項目を増やさずに実現できるか」を考えること（1章）。

姉妹プロジェクトとの関係 HIREBASE（求人）／ RELATE（顧客管理）／ CASTA（動画配信）／ FIELDPIN（位置情報）／ KANADE（音楽）／ MIWAKE（画像認識）／ KAMIWAZA（美容室予約）／ KURA（在庫管理）／ TOKIWA（勤怠・シフト）に続くシリーズ。並べて「同じテンプレ」と思われた時点で失敗。 **RELATE / KURA / TOKIWA との差別化に注意。**4本とも「業務システム」だが、 RELATE＝罫線と等幅数字で表を読ませる（藍・高密度）／ KURA＝各行に在庫の水位バー（ティール＋アンバー・縦長数字）／ TOKIWA＝各行に24時間帯（インディゴ＋コーラル・大きな時刻）／ HIBI＝1画面1カラムの縦書き文章。テキストが主役。余白が広く、密度は最も低い。（墨＋若草） HIBI だけは「読み書きするアプリ」であり、表を読ませない。 8章参照。

目次

1. プロジェクト概要
2. アーキテクチャ方針
3. スコープ定義
4. ロールとデモ切替
5. 画面一覧とユーザーフロー
6. 機能要件
7. データ設計
8. デザイン要件
9. 技術要件・ディレクトリ構成
10. 非機能要件
11. 費用設計
12. 実装タスク
13. 受入基準

1. プロジェクト概要

背景と目的

「日報アプリを作りたい」という相談は、実装が最も簡単で、失敗率が最も高いという珍しい組み合わせを持つ。

作るのは簡単だ。フォームがあって、保存されて、一覧で見られればいい。1週間で作れる。

しかし3ヶ月後、誰も書いていない。

この領域には、最初に共有すべき事実が3つある。

事実①：日報アプリは「作れないから失敗する」のではない。続かないから失敗する

失敗の原因は技術ではなく、次の3つに集約される。

日報アプリの要件定義で最初に決めるべきは、画面でも項目でもない。 「誰が、何のために読むのか」である。 読み手が決まらなければ、書く項目も決まらない。

事実②：「日報」は3つの別の目的が混ざっている

多くの日報が破綻するのは、目的の違う情報を1つのフォームに詰め込むから。

①を毎日、③を週次、②は発生時——本来はこの粒度が違う。 すべてを毎日書かせると、③が形骸化して「特になし」が並ぶ。

HIBI はこの3つを構造として分け、①は最小の手数で、②は目立つように、③は無理をさせない設計にする。

事実③：入力を減らす機能だけが、日報を生き残らせる

だから HIBI の機能はすべて「入力を減らす」か「読まれるようにする」のどちらかに寄与しなければならない。

入力項目を増やす機能は、原則として採用しない。 これがこのプロジェクトの設計方針であり、記事の主張でもある。

プロダクト定義

プロダクトコンセプト

「書く時間を、90秒に。」

HIBI は日報の入力時間を計測し、画面に表示する。テンプレート、前日のコピー、選択式項目、サジェスト——すべてはその秒数を縮めるためにある。そして書かれた日報には必ず読み手の痕跡（既読・コメント）が残る。書くのが速く、読まれるなら、日報は続く。

デモとしての成功条件

1. 入力時間が見える — 日報を書くと「入力 1分12秒」と表示され、平均と比較される
2. 手数が減る体験ができる — 「前日をコピー」を押すと、大半が埋まった状態から始まる
3. 3つの目的が分かれている — 報告・相談・蓄積が別のブロックとして構造化されている
4. 読まれた痕跡が残る — 既読者のアバター、コメント、リアクションが日報に付く
5. 運用が測れる — 提出率・返信率・平均入力時間がダッシュボードに出る
6. ロールで見え方が変わる — メンバーは自分とチーム、管理者は全社。個人の評価情報は分離
7. リセットできる — 誰が触った後でも初期状態に戻せる

2. アーキテクチャ方針

基本方針

バックエンドとデータベースを持たない。すべてブラウザ内で完結させる。

なぜこの構成にするか

• LPデモとして最適 — 訪問者は登録もログインもせずに、全機能を即座に触れる
• 書いた内容が外に出ない — 日報は業務の機密。データを預からないことが訴求になる
• 開発速度 — 認証・APIの実装が不要になり、入力体験と読まれる仕組みの作り込みに全時間を投下できる
• 運用コストゼロ — Vercel の静的配信のみ

入力時間の計測（このプロジェクト固有の中核）

「書く時間を90秒に」を主張するなら、それを測らなければならない。

入力セッションの計測
  開始：新規作成 or 編集画面を開いた瞬間
  一時停止：タブが非表示になった／30秒以上操作がない
  再開：操作が再開された
  終了：提出 or 離脱
  → activeSeconds（実際に手を動かしていた秒数）を記録

MEA-04 は重要。 入力時間を個人評価に使えるようにすると、日報アプリが監視ツールになり、事実①の「監視のために書かされている感覚」を強化してしまう。測るのは運用改善のためであり、人を測るためではない。

週次まとめの自動生成（入力を減らす機能の核）

事実②で「③蓄積は週次でよい」と書いた。だが週報を別途書かせると入力が増える。だから日報から自動で組み立てる。

週次まとめの生成（ルールベース。AIを使わない）
  ① その週の日報を収集
  ② 「実施内容」から、同じタグ・案件のものをグループ化
  ③ 「進捗」の数値項目を合算
  ④ 「課題・相談」を未解決のものだけ抽出
  ⑤ 「気づき」をそのまま列挙
  ⑥ 未提出日を明示
  → 下書きとして提示し、本人が追記・修正して提出

差し替え可能性の担保

データアクセスは必ず lib/repo/ のリポジトリ層を経由すること。 コンポーネントからストアを直接触らない。

[ コンポーネント ]
        ↓  呼ぶのはこの層だけ
[ lib/repo/*.ts ]   ← 全メソッドを async にしておく
        ↓
[ lib/search/ ]     ← 全文検索（純粋関数）
[ lib/summary/ ]    ← 週次まとめ生成（純粋関数）
[ lib/metrics/ ]    ← 提出率・返信率・入力時間（純粋関数）
[ lib/store/*.ts ]  ← Zustand + persist（localStorage）
        ↓
[ lib/seed/*.ts ]   ← 初期データ

リポジトリの各メソッドは、中身が同期処理でも async で定義し、await で呼ぶ。実案件へ転用する際、リポジトリの実装だけをAPI呼び出しに差し替えれば、UI層は一行も変更せずに済む。

記事への組み込み

記事内で見せるのは「書くのがどれだけ速いか」だけに絞る。 これが事実③そのものであり、スクロール中に体験できる唯一のことになる。

永続化の範囲

擬似ディレイ は 150〜400ms。ただし入力・下書き保存・提出・検索は 100ms以下とし、ディレイを入れない（入力でもたつくのは、このアプリで最も致命的な体験）。

3. スコープ定義

書く（メンバー）

読む・返す（メンバー・上司）

運用を測る・整える（管理者）

共通・基盤

対象外（Won't have）

スコープリスク： 日報は「あれも書かせたい」が最も起きやすい領域。項目追加の要望は必ず来る。 そのとき「項目を1つ増やすと、入力時間が何秒増え、提出率が何%下がるか」を議論できる状態を作ることが、このプロジェクトの目的。F-A05 のテンプレート管理画面に「項目数と推定入力時間」を表示させているのはこのため。

4. ロールとデモ切替

ロール定義

データスコープと項目スコープ

SCP-04 と SCP-05 が、このデモの倫理設計。 日報アプリは容易に監視ツールになるため、データの返し方の段階で防ぐ。

ロールを跨ぐ体験（必ず動くようにする）

1. メンバーで日報を書いて提出 → 上司に切替 → タイムラインに未読として現れ、課題ありのバッジが付いている
2. 上司がコメントする → メンバーに切替 → 通知が来ており、日報に既読者とコメントが付いている
3. メンバーが「前日をコピー」で書く → 入力時間が前回より短くなり、「前回より38秒短縮」と表示される
4. 上司が返信をサボる → 管理者に切替 → 返信率ダッシュボードでそのチームの返信率が下がっている
5. 管理者がテンプレートに項目を3つ追加 → メンバーに切替 → 入力項目が増え、推定入力時間が伸びている
6. メンバーが週次まとめを生成 → その週の日報から自動で組み立てられ、根拠の日報にリンクが張られている
7. メンバーが「課題・相談」を上司のみに限定 → 別のメンバーに切替 → その部分が表示されていない

3番と5番が、このデモの核心。 事実③（入力を減らす機能だけが生き残らせる）が体験として成立する瞬間。

デモ切替バー（F-C01）

画面上部に常時表示する固定バー。埋め込みモードでは非表示。

• 現在のロールと氏名・チームの表示、3ロールの切替
• メンバーロール時：3名から操作主体を選択（毎日書く人／たまに書かない人／新人 を用意）
• デモ内の現在日時（シードが相対日付のため基準を示す）
• 「デモをリセット」ボタン（確認ダイアログ付き）
• 元記事へ戻るリンク
• 「これはデモです。書いた内容は送信されません」の明示

デザイン上の扱い： プロダクト本体が明るく余白の広い読み書きのUIなので、切替バーは濃い墨色の帯にして明確に区別する。

5. 画面一覧とユーザーフロー

全28画面。画面IDはディレクトリ構成と 1:1 で対応させる。

書く（メンバー）

読む・返す

運用を測る・整える（上司・管理者）

主要フロー

フローA：記事の読者が「書く速さ」を体験する（最重要）

SEO記事を読んでいる
   ↓
記事内の埋め込み（SC-900）
┌────────────────────────────────────────────────────────┐
│  2026-08-24（月）の日報                    ⏱ 0:00      │
│                                                        │
│  案件          [ ▼ 選択してください        ]            │
│  作業種別      [ ▼ 選択してください        ]            │
│  進捗          [ ○順調 ○やや遅れ ○遅延 ]                │
│  実施内容      [                          ]            │
│  課題・相談    [                    ] （任意）          │
│  気づき        [                    ] （任意）          │
│                                                        │
│  [ 前日をコピー ]              [ 提出する ]             │
└────────────────────────────────────────────────────────┘
   ↓
何か打ち始める
   ↓  ★ タイマーが動き出す（⏱ 0:07 …）
「前日をコピー」を押す
   ↓  ★ 案件・作業種別・実施内容の大半が埋まる
   ★ 「あと2項目で提出できます」と表示される
   ↓
残りを埋めて「提出する」
   ↓
┌────────────────────────────────────────────────────────┐
│  提出しました                                           │
│                                                        │
│      入力時間  1分12秒                                 │
│                                                        │
│  前日をコピーしなかった場合の平均：3分48秒               │
│  → 2分36秒 短縮できました                              │
│                                                        │
│  [ 全画面でチームの日報を読む ]                          │
└────────────────────────────────────────────────────────┘
   ↓
「全画面で試す」→ 別タブ
   ↓
SC-100 チームのタイムライン ── ★ 8名の日報が並び、未読が明確
   ↓
SC-101 日報の詳細 ── コメントを書いてみる
   ↓
ロール切替「管理者」→ SC-203 入力時間の分布
   ↓  ★ チーム平均 2分14秒。前日コピー利用時は 1分22秒
SC-210 テンプレート管理 ── ★ 項目を3つ追加すると推定入力時間が +45秒 と表示される
   ↓
資料ダウンロード or 元記事に戻る

フローB：書いたら読まれる（事実①の「読まれない」を潰す）

【メンバー：田中】SC-010 日報の作成
  実施内容を書く
  ★ 「課題・相談」に「A社の見積、値引き幅の判断をお願いしたいです」と書く
  ★ 公開範囲を「上司のみ」に設定（SCP-05）
   ↓
提出
   ↓
【上司】SC-100 チームのタイムライン
  ★ 田中の日報カードに「未読」と「課題あり」のバッジが付いている
  ★ 課題ありは他のカードより視覚的に前に出る
   ↓
SC-101 日報の詳細
  ★ 「課題・相談」ブロックが強調表示され、上司のみに見えている旨が表示される
   ↓
コメントを書く：「値引きは8%まで可。それ以上は要相談」
   ↓
【メンバー：別の人】SC-100 タイムライン
  ★ 田中の日報は読めるが、「課題・相談」ブロックは表示されない（SCP-05）
   ↓
【メンバー：田中】SC-001 ホーム
  ★ 通知：「上司さんがコメントしました」
   ↓
SC-021 日報の詳細
  ★ 既読者のアバターが3名分ついている
  ★ コメントが付いている
  ★ リアクション「確認した」が2件
   ↓
★ ここで伝わること：
  「書いたら、読まれた痕跡が返ってくる。だから次も書く」

フローC：運用が回っているかを測る

【管理者】SC-200 運用ダッシュボード
  提出率      87%  （先週 91% ▼）
  返信率      42%  （先週 58% ▼）★ 悪化
  平均入力時間 2分14秒
  未読率      31%  ★ 高い
   ↓
★ 「提出率は高いが、返信率が下がり未読が溜まっている」
   → 書かせているのに読んでいない状態
   ↓
SC-202 返信率
  ★ 上司別に表示
    山田（営業1課）  返信率 71% / 平均返信 4時間
    佐藤（営業2課）  返信率 18% / 平均返信 3日  ★ 赤で強調
  ★ 「返信されていない日報 24件」の一覧へ
   ↓
SC-201 提出状況 ── メンバー×日付のグリッド
  ★ 特定の曜日（金曜）に未提出が集中している
  ★ リマインド時刻が18:00だが、金曜は早く帰るため間に合っていない
   ↓
SC-220 提出ルールの設定
  ★ 金曜のリマインド時刻を16:00に変更
   ↓
SC-210 テンプレート管理
  ★ 項目数 9個／推定入力時間 3分20秒 と表示されている
  ★ 「気づき」を必須から任意に変更 → 推定 2分40秒 に
   ↓
【メンバー】★ 入力項目が減り、提出しやすくなっている
   ↓
（1週間後）SC-200 ダッシュボード
  ★ 提出率 87% → 94%、返信率 42% → 65%
   ↓
★ ここで伝わること：
  「日報アプリは作って終わりではない。運用を測って、調整して初めて回る」

6. 機能要件

各要件はテスト仕様書の項目と1:1で対応する。「〜できること」の粒度で、判定可能な形で記述している。

6.1 入力体験（このデモの心臓部）

6.2 日報の構造（3つの目的の分離）

6.3 週次まとめ（入力を減らす機能の核）

6.4 読む・返す

6.5 運用の計測（このデモの差別化要素）

6.6 テンプレート・設定

6.7 デモ基盤

7. データ設計

型定義（lib/types/）

// ---- 組織・メンバー ----
type Team = { id: string; name: string; leaderId: string; templateId: string }

type Member = {
  id: string
  name: string                  // ★ 架空
  teamId: string
  role: 'member' | 'leader' | 'admin'
  avatarUrl: string
  joinedAt: string
  isActive: boolean
}

// ---- テンプレート ----
type FieldType = 'text' | 'textarea' | 'select' | 'multiselect' | 'number' | 'date' | 'checkbox' | 'image'

type TemplateField = {
  id: string
  label: string
  type: FieldType
  block: 'report' | 'issue' | 'insight'   // ★ 3つの目的（FR-201）
  options?: string[]                       // select / multiselect
  masterKey?: 'project' | 'work_type'      // マスタから選択肢を取る
  unit?: string                            // number
  isRequired: boolean
  copyFromPrevious: boolean                // ★ 前日コピーの対象（FR-106）
  placeholder?: string
  helpText?: string
  inputMode?: 'text' | 'numeric'           // FR-114
  sortOrder: number
  // ★ 推定入力時間の算出に使う（FR-603）
  estimatedSeconds: number
}

type Template = {
  id: string
  version: number                          // ★ 過去の日報は当時の構造で表示（FR-607）
  name: string
  fields: TemplateField[]
  teamIds: string[]
  effectiveFrom: string
  // --- 算出値（保存しない）---
  // fieldCount, estimatedTotalSeconds は lib/metrics で算出
}

// ---- ★★★ 日報（このプロジェクトの中核）★★★ ----
type ReportStatus = 'draft' | 'submitted'

type Report = {
  id: string
  memberId: string
  reportDate: string            // YYYY-MM-DD
  templateId: string
  templateVersion: number       // ★ 当時の構造で表示するため（FR-607）
  status: ReportStatus
  // --- 本文（テンプレート項目のID → 値）---
  values: Record<string, FieldValue>
  // --- ★ 課題・相談の扱い（FR-204〜206）---
  issue?: {
    hasIssue: boolean
    visibility: 'team' | 'leader_only'    // ★ SCP-05
    resolutionStatus: 'open' | 'in_progress' | 'resolved'
    resolvedBy?: string
    resolvedAt?: string
  }
  // --- 添付 ---
  imageIds: string[]            // IndexedDB のキー
  // --- ★ 入力時間の計測（MEA-01, MEA-05）---
  inputMetrics: {
    activeSeconds: number       // 累積のアクティブ入力秒数
    sessionCount: number        // 何回に分けて書いたか
    usedCopyPrevious: boolean   // ★ 前日コピーを使ったか（FR-512）
    firstOpenedAt: string
    submittedAt?: string
  }
  // --- 提出 ---
  submittedAt?: string
  isLate: boolean               // 提出期限を過ぎたか
  // --- 編集履歴（FR-117）---
  editHistory: { at: string; by: string; changedFieldIds: string[] }[]
  createdAt: string
  updatedAt: string
}

type FieldValue = string | number | boolean | string[] | null

// ---- 反応（★ 「読まれた」を成立させる）----
type ReadReceipt = {
  id: string
  reportId: string
  memberId: string
  readAt: string                // ★ 3秒以上表示で記録（FR-405）
}
type Reaction = {
  id: string
  reportId: string
  memberId: string
  kind: 'confirmed' | 'good' | 'helpful'   // 確認した / いいね / 助かった
  createdAt: string
}
type Comment = {
  id: string
  reportId: string
  memberId: string
  body: string
  mentionedMemberIds: string[]
  createdAt: string
  editedAt?: string
}

// ---- 週次まとめ ----
type WeeklySummary = {
  id: string
  memberId: string
  weekStart: string             // YYYY-MM-DD
  weekEnd: string
  status: 'generated' | 'submitted'
  // --- 生成結果（SUM）---
  generated: {
    groupedActivities: { key: string; label: string; items: string[]; sourceReportIds: string[] }[]
    numericTotals: { fieldId: string; label: string; total: number; unit?: string }[]
    openIssues: { reportId: string; body: string; daysOpen: number }[]
    insights: { reportId: string; body: string }[]
    missingDates: string[]      // ★ 未提出日（SUM-04）
    notes: string[]             // ★ 生成できなかった項目の説明（SUM-04）
  }
  // --- 本人の追記・修正 ---
  edited: { retrospective: string; nextWeekPlan: string }
  submittedAt?: string
  generatedAt: string
}

// ---- 設定 ----
type SubmissionRule = {
  id: string
  teamId?: string               // 未指定なら全社
  targetWeekdays: number[]      // 提出対象の曜日
  deadlineMin: number           // 提出期限（0:00からの分数。1080 = 18:00）
  reminders: { weekday: number; atMin: number }[]   // ★ 曜日別のリマインド（FR-609）
  editableMinutes: number       // 提出後の編集可能時間（既定30）
  weekStartsOn: number
}

type MasterItem = {
  id: string
  key: 'project' | 'work_type'
  name: string
  isActive: boolean
  sortOrder: number
  // 算出値：usageCount（FR-611）
}

// ---- 通知 ----
type Notification = {
  id: string
  targetMemberId: string
  kind: 'comment' | 'mention' | 'reaction' | 'unread_reminder' | 'submit_reminder' | 'issue_stale'
  title: string
  body: string
  link: string
  previewMessage?: { channel: 'email' | 'slack' | 'line'; subject?: string; body: string }  // ★ 送信しない
  readAt?: string
  createdAt: string
}

// ---- 運用指標（★ 算出値。ストアに保存しない）----
type OpsMetrics = {
  scope: { teamId?: string; from: string; to: string }
  submissionRate: number        // FR-502
  responseRate: number          // FR-503
  unreadRate: number            // FR-504
  avgInputSeconds: number
  // --- 比較 ---
  prevSubmissionRate: number
  prevResponseRate: number
  prevUnreadRate: number
  prevAvgInputSeconds: number
}
type SubmissionGrid = {
  members: { memberId: string; name: string }[]
  dates: string[]
  cells: Record<string, 'submitted' | 'late' | 'missing' | 'not_required'>  // `${memberId}:${date}`
}
type ResponseByLeader = {
  leaderId: string
  name: string
  responseRate: number
  avgResponseHours: number
  unrespondedReportIds: string[]
}
type InputTimeDistribution = {
  teamAvgSeconds: number
  histogram: { fromSec: number; toSec: number; count: number }[]
  byTemplate: { templateId: string; name: string; avgSeconds: number; fieldCount: number }[]
  withCopyAvgSeconds: number    // ★ FR-512
  withoutCopyAvgSeconds: number
  // ★ 個人別は含めない（MEA-04, SCP-04）
}

// ---- 監査 ----
type AuditLog = {
  id: string
  actorId: string
  action: 'edit_report' | 'delete_report' | 'update_template' | 'update_rule' | 'send_reminder'
  targetType: string
  targetId: string
  changes: { field: string; before: unknown; after: unknown }[]
  createdAt: string
}

入力時間の計測（7章の中核）

// lib/metrics/input-timer.ts — コンポーネントはこのフックだけを使う（MEA-02）
const IDLE_THRESHOLD_MS = 30_000

export function createInputTimer() {
  let activeMs = 0
  let lastTick: number | null = null

  const onActivity = () => {
    const now = Date.now()
    if (lastTick !== null) {
      const delta = now - lastTick
      // ★ 30秒以上の無操作は加算しない（MEA-01）
      if (delta < IDLE_THRESHOLD_MS) activeMs += delta
    }
    lastTick = now
  }

  const onHidden = () => { lastTick = null }   // ★ タブ非表示中は加算しない
  const onVisible = () => { lastTick = Date.now() }

  return {
    onActivity, onHidden, onVisible,
    getActiveSeconds: () => Math.round(activeMs / 1000),
    // ★ 既存の累積に足し込む（複数回に分けて書くケース。MEA-05）
    merge: (prevSeconds: number) => prevSeconds + Math.round(activeMs / 1000),
  }
}

// lib/metrics/estimate.ts — テンプレートの推定入力時間（FR-603）
// 項目種別ごとの実測平均（シードの実データから算出した係数）
const SECONDS_BY_TYPE: Record<FieldType, number> = {
  select: 4, multiselect: 8, checkbox: 3, date: 6, number: 8,
  text: 15, textarea: 45, image: 20,
}

export function estimateInputSeconds(fields: TemplateField[]): number {
  return fields
    .filter(f => f.isRequired)                      // 任意項目は加算しない
    .reduce((sum, f) => sum + (f.estimatedSeconds || SECONDS_BY_TYPE[f.type]), 0)
}

シードデータ（lib/seed/）

シード作成のルール（品質を左右する）

• 実在企業名・実在人名を使わない。 架空のメンバー名・案件名で構成する
• 氏名を「メンバーA」のようなダミーにしない。 実在しそうな架空名にする
• 日報の本文を、業種の世界観を持つ実在しそうな文章にする。 「本日の業務を行いました」のようなダミーを1件も残さない。ここが手抜きだとデモ全体が死ぬ。日報アプリのデモは本文の質がそのまま説得力になる
• 本文の長さに幅を持たせる。 3行の人、10行の人、箇条書きの人が混在すること
• 入力時間の実データを持たせる。 30秒〜8分の分布。前日コピー利用時は明確に短く（FR-512 が意味を持つように）
• 課題・相談が書かれている日報を1割程度作る。 うち数件を「上司のみ」に設定（SCP-05 の実演用）
• 未対応のまま3日以上経過した課題を数件作る（FR-410 の実演用）
• 返信率に差をつける。 返信の薄い上司を1名作り、返信されていない日報を20件以上残す（フローCの実演用）
• 未読が溜まっている状態を作る（未読率30%程度）
• 未提出の日を作る。 特に金曜に未提出が集中している状態にする（フローCの実演用）
• 「気づき」が空の日報を多く作る。 任意項目が形骸化する実態を再現する（そしてそれが正常であることを示す）
• 提出が遅延した日報を混ぜる（isLate: true）
• 日付は現在日時からの相対で生成する。固定日付を埋め込まない
• 日報は提出対象曜日にのみ存在すること（土日に日報が並んでいると嘘に見える）

ストアとリポジトリ

lib/
├── types/  seed/
├── metrics/                    # ★ 純粋関数 + タイマー
│   ├── input-timer.ts          # ★ 入力時間の計測（MEA-02）
│   ├── estimate.ts             # ★ テンプレートの推定入力時間（FR-603）
│   ├── submission.ts           # 提出率（FR-502）
│   ├── response.ts             # 返信率・平均返信時間（FR-503, FR-508）
│   ├── unread.ts               # 未読率（FR-504）
│   ├── distribution.ts         # 入力時間の分布（FR-510, FR-512）
│   └── patterns.ts             # 提出が落ちる曜日・時刻の検出（FR-507）
├── summary/                    # ★ 週次まとめ生成。純粋関数のみ
│   ├── generate.ts             # SUM-05
│   ├── group.ts                # 実施内容のグループ化
│   └── totals.ts               # 数値項目の合算
├── search/                     # ★ 全文検索。純粋関数のみ
│   ├── index.ts                # 転置インデックスの構築
│   ├── query.ts                # 検索とスコアリング
│   ├── highlight.ts            # ヒット箇所のハイライト
│   └── normalize.ts            # ひらがな/カタカナ/半角全角の正規化
├── storage/                    # IndexedDB（画像）
├── query/                      # 絞り込み・ソート
├── store/  { session, data, settings, draft, sync, ui }
└── repo/                       # ★ コンポーネントが触るのはここだけ
    ├── _delay.ts
    ├── _scope.ts               # ★ データスコープ + 項目スコープ（SCP-01〜05）
    ├── reports.ts  drafts.ts  comments.ts  reactions.ts  reads.ts
    ├── weekly.ts  templates.ts  masters.ts  rules.ts
    ├── metrics.ts  search.ts  members.ts  notifications.ts  logs.ts

リポジトリ層の規約（厳守）

• 全メソッドを async で定義する。中身が同期でも例外なく
• 戻り値は { ok: true; data: T } | { ok: false; error: string } に統一する
• コンポーネントから Zustand ストアを直接参照しない。 読み取りも書き込みもリポジトリ経由
• 入力時間の計測を lib/metrics/input-timer.ts に集約する。 コンポーネントで setInterval を持たない（MEA-02）
• 週次まとめの生成を lib/summary/ に集約し、純粋関数とする（SUM-05）
• lib/metrics/ lib/summary/ lib/search/ は純粋関数のみ。 ストア・DOM に依存させず、new Date() を内部で呼ばない
• スコープ適用（_scope.ts）を全メソッドが必ず通す。 ここが実案件で権限制御に置き換わる箇所
• 個人別の入力時間を本人以外に返さない（SCP-04）
• 「上司のみ」の課題ブロックを、対象外のメンバーに返さない（SCP-05）
• 派生値（提出率・返信率・未読率・推定入力時間）はストアに保存せず算出する
• 入力・下書き保存・提出・検索に擬似ディレイを入れない（FR-119）

// lib/repo/_scope.ts — 「上司のみ」の課題を除外する（SCP-05, FR-205）
export function scopeReport(report: Report, viewer: Member): Report | null {
  // 他チームは一切返さない（SCP-03）
  if (viewer.role === 'member' && report.teamId !== viewer.teamId) return null

  const isSelf = report.memberId === viewer.id
  const isLeaderOfWriter = viewer.role !== 'member' && isInScope(viewer, report)

  // ★ 「上司のみ」の課題ブロックは、本人と上司以外には含めない
  if (report.issue?.visibility === 'leader_only' && !isSelf && !isLeaderOfWriter) {
    return { ...report, issue: undefined, values: omitIssueFields(report.values) }
  }
  // ★ 個人別の入力時間は本人以外に返さない（SCP-04）
  if (!isSelf) return { ...report, inputMetrics: undefined as never }
  return report
}

8. デザイン要件

アートディレクション

「業務システムの中で、唯一の読み書きするアプリ」

HIBI が扱うのは表ではなく文章である。日報は読まれるために書かれ、読み手は集中して読む。だから HIBI は姉妹プロジェクトの中で最も密度が低く、余白が広く、1カラムでできている。

• 1画面1カラム。 サイドバーに情報を詰めない。読むときは文章だけを見せる
• 本文が主役。 15px・行間1.9。日報の本文が読みやすいことが最優先
• 色はほぼ使わない。 例外は「課題あり」と「未読」の2つだけ
• 入力フォームに枠を描かない。 下線と余白で区切る。「書類に記入する」感覚を作らない

姉妹プロジェクトとの差別化（最重要） RELATE / KURA / TOKIWA は「表を読ませる高密度の業務システム」。HIBI は文章を読み書きさせるアプリで、密度は真逆。 4本を並べたとき、HIBI だけが余白の広い1カラムであることが一目で分かること。 配色も分ける：RELATE＝藍／ KURA＝ティール＋アンバー／ TOKIWA＝インディゴ＋コーラル／ HIBI＝墨＋若草（低彩度の緑）。

カラートークン

:root {
  /* 紙に近い、わずかに温かい白 */
  --paper:     #FAFAF8;   /* ページ背景 */
  --panel:     #FFFFFF;   /* カード・本文の地 */
  --panel-alt: #F2F2EE;   /* 区切り・引用 */
  --line:      #E5E5DF;   /* 罫線（極めて控えめに） */

  --ink-900:   #1C1D1A;   /* 本文（純黒にしない。長文を読ませるため） */
  --ink-600:   #5B5D57;   /* 補助テキスト */
  --ink-400:   #93958D;   /* ラベル・非活性 */

  --accent:    #4A6B3F;   /* 主要CTA（若草。低彩度） */
  --accent-d:  #3A5531;
  --accent-50: #EBF0E8;

  /* ★ 色を使う例外は2つだけ */
  --issue:     #A85B2B;   /* 課題あり（テラコッタ） */
  --issue-bg:  #F6EDE6;
  --unread:    #4A6B3F;   /* 未読（若草の点） */

  /* 状態（控えめに） */
  --st-draft:   #93958D;
  --st-late:    #A8892B;
  --st-missing: #A85B2B;

  /* 反応 */
  --reaction-bg: #F2F2EE;
}

配色ルール

• 色を使う箇所を2つに限定する：「課題あり」と「未読」。 それ以外は無彩色 + 若草のアクセントのみ
• 提出済み・未提出をバッジの色で塗り分けない。 テキストと位置で示す（一覧が色だらけになるのを防ぐ）
• 入力時間の表示に色を使わない。 数字を大きくするだけ。速い/遅いを色で評価しない（MEA-04 の精神）
• チーム・メンバーに固有色を割り当てない。アバターで識別する

タイポグラフィ

本文15px・行間1.9 が HIBI の視覚的な指紋。 RELATE / KURA / TOKIWA はすべて13px の高密度。HIBI だけが「読ませるための組版」を持つ。

レイアウトとスペーシング

主要コンポーネント仕様

インタラクション要件

モーション

prefers-reduced-motion: reduce 時は全アニメーションを無効化する。

アクセシビリティ（WCAG 2.1 AA）

ライティング規約

9. 技術要件・ディレクトリ構成

技術スタック（固定・勝手に変更しない）

上記以外のライブラリを入れる前に必ず提案し、承認を得ること。特に全文検索ライブラリ、リッチテキストエディタ、AI SDK の導入は禁止。

リッチテキストエディタを入れない理由： 日報に装飾は不要であり、エディタを入れるとバンドルが数百KB増え、入力の反応が落ちる。プレーンテキスト + 改行 + 箇条書き（- 記法の表示側変換）で足りる。IX-01（入力の反応100ms以下）を守るための判断。

ディレクトリ構成

/
├── CLAUDE.md
├── app/
│   ├── layout.tsx                  # 1カラムシェル（ヘッダー + タブナビ + デモ切替バー）
│   ├── page.tsx                    # SC-001 ホーム / SC-900（?embed=1）
│   ├── reports/                    # SC-010〜021
│   ├── weekly/                     # SC-030, 031
│   ├── notifications/              # SC-040
│   ├── team/                       # SC-100〜103
│   ├── search/  export/            # SC-110, 120
│   ├── admin/                      # SC-200〜240
│   └── dev/components/
├── components/
│   ├── editor/                     # ★ 最重要
│   │   ├── ReportForm.tsx          # 1カラムの入力フォーム
│   │   ├── FieldRenderer.tsx        # 項目種別ごとの描画
│   │   ├── ChipSelect.tsx          # 選択式（セレクトを使わない）
│   │   ├── AutoTextarea.tsx        # 自動高さ調整
│   │   ├── InputTimerBadge.tsx     # ★ 控えめなタイマー（MEA-03）
│   │   ├── CopyPreviousButton.tsx  # ★ 前日コピー
│   │   ├── MissingFieldsHint.tsx   # ★ 残り項目（FR-113）
│   │   ├── SubmitResultModal.tsx   # ★ 入力時間の結果
│   │   └── useDraftAutosave.ts
│   ├── report/                     # ReportCard, IssueBlock, ReadReceipts, ReactionBar, CommentList
│   ├── weekly/                     # SummaryDraft, SourceReportLinks
│   ├── ops/                        # MetricCard, SubmissionGrid, ResponseTable, InputTimeHistogram
│   ├── template/                   # FieldList, EstimateBadge（★ 項目数と推定時間）
│   ├── demo/                       # RoleSwitcher, ResetButton, GuideTour, BackToArticle
│   └── layout/
├── lib/
│   ├── types/ seed/ store/ repo/
│   ├── metrics/                    # ★ 計測。純粋関数 + タイマー
│   ├── summary/                    # ★ 週次まとめ生成。純粋関数
│   ├── search/                     # ★ 全文検索。純粋関数
│   ├── storage/ query/ validation/ utils/
├── docs/
│   └── daily-report-checklist.md   # 資料PDFの元原稿（日報の目的整理シート）
├── e2e/
└── public/

コーディング規約

• TypeScript strict。any 禁止。やむを得ない場合は unknown + 型ガード
• ファイル名は kebab-case、コンポーネントは PascalCase
• 1ファイル300行を超えたら分割を検討する
• コンポーネントから Zustand ストアを直接参照しない。必ず lib/repo/ 経由
• 入力時間の計測を lib/metrics/input-timer.ts に集約する。 コンポーネントで setInterval を持たない（MEA-02）
• lib/metrics/ lib/summary/ lib/search/ は純粋関数のみ。 ストア・DOM に依存させず、new Date() を内部で呼ばない
• 入力の反応速度を最優先する。 入力中に重い処理（検索インデックス更新・集計）を走らせない。下書き保存も入力をブロックしない（IX-02）
• 個人別の入力時間を本人以外に返さない（SCP-04）。この判定をコンポーネントに書かない
• 派生値（提出率・返信率・未読率・推定入力時間）をストアに保存しない
• 入力を増やす機能を提案しない。 機能追加は「入力を減らす」か「読まれるようにする」に寄与すること（1章 事実③）
• コミットは1タスクごと。メッセージに要件IDを含める 例：feat(editor): 前日コピーで埋まった項目をハイライト (FR-106)

10. 非機能要件

セキュリティ・プライバシー

運用設計上の注意（この領域固有）

日報アプリは容易に監視ツールになる。 実装の段階でそれを防ぐ。

実案件への転用時の注意（デモ本体の要件ではない。商談で聞かれた際に説明できるよう記録）

① 日報は「導入」より「運用設計」に工数がかかる。 項目を決める会議、読む担当を決める運用、リマインドの設計。開発費より運用設計の合意形成の方が時間を食う

② 日報の内容は労務トラブルの証拠になりうる。 長時間労働の記録、ハラスメントの記述などが残る。保存期間とアクセス権限の設計が必要

③ 人事評価に使うなら、その旨を事前に明示する必要がある。 「報告のため」と言って集めた情報を評価に使うのは、運用として問題になりやすい

④ 監視色が強いと必ず形骸化する。 「特になし」が並ぶ日報に価値はない。書き手に利益がある設計（自分の記録が残る、相談が返ってくる）が持続の条件

本デモはデータをサーバーに送信しないため、②③の義務は発生しない。「デモである」旨は画面上に常時明示する

11. 費用設計

記事の主題の半分は「費用」。この章は実装要件であると同時に、記事本文の原稿素材でもある。

日報アプリだけの特殊事情：そもそも作らなくていいかもしれない

他のテーマと違い、日報には**「Excelでもチャットでもできる」**という現実がある。この記事で最初に答えるべきは「いくらか」ではなく——

「日報アプリを、そもそも作る必要があるのか」

正直にそう問うことが、結果的に信頼を生む。

まず、作らない選択肢を並べる

「まずチャットで始めて、限界が来たら考える」が最も合理的なケースが多い。 記事にはこれを明記する。

自作が正当化される5つのケース

⑤は見落とされやすいが、現場系の業種で最も多い動機。 既製サービスは汎用性のために項目が多く、現場の人が使わない。

逆に、①〜⑤のどれにも当てはまらないなら、チャットか既製サービスを使うべき。

損益分岐の計算式

既製サービスの年間コスト
  = 月額単価 × 人数 × 12
  ( + オプション：集計機能・API連携 )

回収年数 = （開発費 + 運用設計費）÷（既製サービス年間コスト − 自作の年間運用費 − 年間保守費）

最も見落とされる費用：運用設計の工数

日報アプリの導入で最も工数を食うのは、実装ではなく「何を書かせるか」の合意形成。

• 項目を決める会議（関係者が増えるほど項目が増える）
• 「誰が読むか」を決める（ここが決まらないと項目が決まらない）
• リマインドと督促の運用を決める
• 既存の日報（紙・Excel・メール）からの移行

そして導入後、必ず項目を増やしたくなる。 そのとき「項目を1つ増やすと入力時間が何秒増え、提出率が何%下がるか」を議論できないと、日報は肥大化して死ぬ。

HIBI がテンプレート管理画面に「項目数と推定入力時間」を常時表示しているのは、この会議のためにある（FR-602）。資料PDFの「日報の目的整理シート」も、この工数を前倒しするために作る。

AI連携は「あとで足す」でよい

「AIで日報を要約したい」「AIが添削してほしい」は必ず出る要望。だが——

AI要約の月額 = 1件あたりの単価 × 人数 × 月間営業日数
例：50名 × 20日 = 1,000件/月

まずルールベースで作り、必要になったらAIを足す。 この順序が費用とリスクの両面で合理的。そしてルールベースでも「根拠の日報にリンクが張られる」という、AIにはない透明性がある（SUM-03）。

Webで足りるか、ネイティブが必要か

日報は、Webで足りる領域。

判断の目安： リマインドのプッシュ通知を重視するなら、LINE公式アカウントやチャットツールへの通知が現実的な代替（アプリ開発より圧倒的に安い）。日報アプリのためにネイティブアプリを作る必要はほぼない。

デモ自体の運用コストを実測して記事に載せる

「このデモを触った読者の入力時間の中央値は 1分34秒でした」——この一文が、どんな機能説明よりも強い。

12. 実装タスク

この順に進める。フェーズを飛ばさない。 完了時は [x] に更新する。

Phase 0 — 基盤と計測エンジン（4日）

0-1. 初期化

• Next.js 15 / TypeScript strict / App Router / Tailwind で初期化
• ESLint / Prettier / husky（pre-commit で lint + typecheck）
• 9章のディレクトリ構成を作成

0-2. lib/metrics/（このプロジェクトの心臓部）

• input-timer.ts：入力時間の計測（7章のコード参照）(MEA-01, MEA-02)
• estimate.ts：テンプレートの推定入力時間（FR-603）
• submission.ts：提出率（対象曜日・在籍期間を考慮）(FR-502)
• response.ts：返信率・平均返信時間（FR-503, FR-508）
• unread.ts：未読率（FR-504）
• distribution.ts：入力時間の分布、前日コピーあり/なしの比較（FR-510, FR-512）
• patterns.ts：提出が落ちる曜日・時刻の検出（FR-507）
• new Date() を内部で呼ばない。現在時刻は引数で受け取る
• 単体テストを網羅的に書く。以下を必ず含めること：
  • タブ非表示中の時間が入力時間に加算されないこと（最重要）
  • 30秒以上の無操作が加算されないこと
  • 複数セッションに分けた場合、累積されること（MEA-05）
  • 推定入力時間が、項目の追加・削除で正しく変わること
  • 任意項目が推定入力時間に加算されないこと
  • 提出率が対象曜日と在籍期間を正しく考慮すること
  • 返信率がコメントとリアクションの両方を数えること
  • 前日コピーあり/なしの入力時間差が正しく算出されること

0-3. lib/search/（自前実装。記事の技術パートの見せ場）

• normalize.ts：ひらがな／カタカナ／半角全角の正規化
• index.ts：転置インデックスの構築（非同期・入力をブロックしない）
• query.ts：検索とスコアリング
• highlight.ts：ヒット箇所のハイライト
• 単体テストを書く。表記ゆれが吸収されること
• 日報1,500件 + コメント620件で検索が 100ms以下をベンチマークで確認（NFR-04）

0-4. lib/summary/（週次まとめ生成。純粋関数）

• group.ts：実施内容のグループ化（タグ・案件で束ねる）
• totals.ts：数値項目の合算
• generate.ts：週次まとめの生成（SUM-01〜05, FR-303）
• 未解決の課題だけを抽出すること／未提出日を明示すること／生成できなかった項目を明示すること
• 根拠の日報IDを必ず含めること（SUM-03）
• 単体テストを書く。日報が0件の週でも壊れないこと

0-5. 型とシード

• lib/types/ に7章の型定義をすべて実装
• lib/seed/ の全ファイル
• 日報の本文を、業種の世界観を持つ実在しそうな文章にする。ダミー文を1件も残さない（最重要）
• 入力時間の実データを持たせる。前日コピー利用時は明確に短く
• 課題・相談を1割程度、うち数件を「上司のみ」に設定
• 未対応3日以上の課題、返信の薄い上司、未読の溜まり、金曜の未提出集中を作る
• 「気づき」が空の日報を多く作る（任意項目の実態を再現）
• テンプレートのバージョンを2つ持つものを1つ作る（FR-607 の実演用）
• 日報は提出対象曜日にのみ存在すること（土日に並べない）
• 日付は現在日時からの相対で生成する

0-6. ストアとリポジトリ

• lib/store/{session,data,settings,draft,sync,ui}.ts を Zustand + persist で実装
• lib/repo/_scope.ts を最初に実装する（7章のコード参照）(SCP-01〜05)
• lib/repo/ の全モジュール。全メソッド async、Result型、スコープ適用
• スコープの単体テストをこの時点で書く：
  • メンバーが他チームの日報を取得できないこと（SCP-03）
  • 個人別の入力時間が本人以外に返らないこと（SCP-04, SEC-06）
  • 「上司のみ」の課題ブロックが、対象外のメンバーに返らないこと（SCP-05）
• 入力・下書き保存・提出・検索に擬似ディレイを入れない（FR-119）

0-7. デザインシステム

• app/globals.css にカラートークンを CSS 変数で定義（色を使うのは「課題あり」と「未読」の2つだけ）
• tailwind.config.ts から CSS 変数を参照するよう theme を拡張
• フォント（Noto Sans JP / Roboto Mono）を next/font で最適化
• 本文 15px・行間1.9・最大幅680px のタイポグラフィを定義（8章）
• 1カラムのアプリシェル（ヘッダー + タブナビ。サイドバーを持たない）
• shadcn/ui を導入し、トークンに合わせて上書き
• 共通コンポーネント：AutoTextarea（自動高さ、アニメーションなし）／ChipSelect（セレクトを使わない）／EmptyState（2種の出し分け）／Skeleton（本文3行分の高さを確保）
• prefers-reduced-motion の対応
• /dev/components にコンポーネントカタログを作成

0-8. デモ基盤

• RoleSwitcher（3ロール + メンバーの3ペルソナ選択）(FR-701)
• デモ切替バー（濃い墨色の帯）+ 「これはデモです。書いた内容は送信されません」（SEC-02）
• 「デモをリセット」(FR-706)／ロール権限外アクセス時の案内画面（FR-709）
• 元記事リンク・資料ダウンロード（FR-711）

Phase 0 完了チェック

• lib/metrics/ のテストが全パターン通る
• 「タブを離れた時間・30秒無操作が入力時間に入らない」がテストで検証済み
• 「個人別の入力時間が本人以外に返らない」がテストで検証済み
• 「上司のみの課題が対象外メンバーに返らない」がテストで検証済み
• 検索が100ms以下
• /dev/components で本文の組版（15px・行間1.9・680px）が正しく表示される

Phase 1 — 入力体験（4日・最重要フェーズ）

1-1. 入力フォーム

• ReportForm.tsx：1カラム、項目間32px、枠で囲まない（8章）
• FieldRenderer.tsx：8種の項目種別に対応（FR-207）
• ChipSelect.tsx：選択式をチップのタップで完了（セレクトを開かせない）(IX-04)
• AutoTextarea.tsx：自動高さ調整。伸長をアニメーションさせない（IX-05）
• 数値項目は inputMode="numeric"（FR-114）
• 3ブロック（報告／課題・相談／気づき）の構造（FR-201）
• 「気づき」に「空のままでも提出できます」を明示（FR-203）
• 課題ブロックに公開範囲のセレクトを併置（FR-204）
• ブラウザの音声入力を妨げないこと（独自キーハンドラを被せない）(FR-116)

1-2. 入力時間の計測と表示

• InputTimerBadge.tsx：画面右上に控えめに表示。大きくしない、色を付けない（MEA-03, FR-103）
• useDraftAutosave.ts：入力停止から2秒後に保存。入力をブロックしない（FR-108, IX-02）
• 保存状態の表示、aria-live での控えめな通知（A11Y-09）
• アプリを閉じて再訪しても下書きが復元されること（FR-109）
• 入力時間の累積（複数セッション）(FR-105)

1-3. 前日コピーと残り項目

• CopyPreviousButton.tsx：前回内容の引き継ぎ（FR-106）
• 埋まった項目に若草の背景が一度だけ走るアニメーション（400ms）
• MissingFieldsHint.tsx：提出ボタン直上に「あと N項目：〜」（FR-107, FR-113）
• aria-live="polite" での通知（A11Y-08）
• ChipSelect へのサジェスト（過去の入力から候補）(FR-111)

1-4. 提出

• 提出はワンタップ。確認ダイアログなし（FR-112, IX-03）
• ⌘Enter で提出、Esc で下書き保存して閉じる（IX-06）
• SubmitResultModal.tsx：入力時間（30px Mono）+ 平均との比較（FR-104）
• 短縮できた場合は伝え、遅い場合は何も言わない（ライティング規約）
• 提出後30分の編集可能（FR-117）／編集履歴（FR-117）
• SC-013 下書き一覧／SC-001 ホーム
• 画像添付（Canvas で圧縮、IndexedDB）(FR-115)

1-5. 埋め込みモード

• SC-900 埋め込みモード：入力フォーム + タイマー + 前日コピー（FR-713, 2章）
• 実際に入力でき、入力時間が計測され、提出後に秒数が表示されること（EMB-04）
• 前日コピーで「あと2項目」が出ること（EMB-05）
• 提出はできるがアプリ内遷移をしない。「全画面で続きを見る」を target="_blank"（EMB-06）
• カメラ・位置情報を呼ばない（EMB-07）
• 初期バンドル 60KB以下を実測（NFR-13）

Phase 1 完了チェック

• フローAが完走する（埋め込みで書く → 前日コピー → 提出 → 入力時間が出る）
• 文字入力が1フレームも落ちない（NFR-01）
• 下書き保存が入力をブロックしない（IX-02）
• 前日コピーで入力時間が明確に短くなる
• タブを離れて戻っても入力時間が正しい

Phase 2 — 読む・返す（4日）

2-1. タイムライン

• SC-100 チームのタイムライン：日付順カード、1カラム760px（FR-401）
• ReportCard.tsx：未読は左端に若草の点／課題ありは細い帯 + バッジ（FR-403, A11Y-05）
• フィルタ（メンバー／案件／課題あり／未読のみ／期間）(FR-402)
• 仮想スクロール、60fps（NFR-09）
• キーボード操作（↑↓ Enter R）(IX-07)

2-2. 詳細と反応

• SC-101 / SC-021 日報の詳細（本文680px、行間1.9）
• IssueBlock.tsx：課題ブロックの強調 + 対応状態のセレクト + 「上司のみ」の鍵表示（FR-206）
• ReadReceipts.tsx：既読者のアバターを重ねて表示。書き手側にも出す（FR-404）
• 既読は3秒以上表示で記録（FR-405, IX-08）
• ReactionBar.tsx：3種のチップ。コメントより先に、押しやすい位置（FR-408）
• CommentList.tsx：折りたたまない。投稿ボタンは常時表示（FR-406）
• メンション（FR-407）／楽観的更新（IX-09）
• SC-040 通知センター（通知はプレビュー表示）

2-3. 課題と検索

• SC-102 課題の一覧：対応状態と経過日数（FR-409）
• 未対応3日以上の強調（FR-410）
• SC-103 メンバーのタイムライン（FR-411）
• SC-110 検索：ハイライト表示、300msデバウンス、100ms以下（FR-412〜414, IX-10）
• 絞り込みのURLクエリ反映（FR-413）
• SC-120 エクスポート（CSV／Markdown）(FR-415)

Phase 2 完了チェック

• フローBが完走する（課題を書く → 上司が読む → コメント → 書き手に既読とコメントが見える）
• 4章「ロールを跨ぐ体験」の1・2・7が動作する
• 「上司のみ」の課題が、対象外メンバーの画面に表示されない
• 検索が100ms以下でハイライト付きで返る

Phase 3 — 週次まとめ（2日）

• SC-030 週次まとめの生成画面
• 生成された下書きをセクションごとに表示（実施内容／数値合計／未解決の課題／気づき／未提出日）
• SourceReportLinks.tsx：根拠の日報へのリンク（日付チップ）（SUM-03, FR-305）
• 生成できなかった項目を --ink-400 で明示（SUM-04, FR-306）
• 本人の追記欄（振り返り／来週の予定）
• 必ず下書き。自動提出しない（SUM-02, FR-304）
• SC-031 週次まとめ一覧
• 週次まとめへの既読・コメント（FR-309）
• 週の起算曜日の設定（FR-308）

Phase 3 完了チェック

• 4章「ロールを跨ぐ体験」の6が動作する
• 日報が0件の週でも生成が壊れない
• 根拠の日報にリンクが張られている

Phase 4 — 運用の計測とテンプレート管理（4日）

4-1. 運用ダッシュボード

• SC-200 4指標カード（提出率・返信率・平均入力時間・未読率）+ 前週比（FR-501）
• 悪化した指標のみ符号を色付け（8章）
• SC-201 提出状況グリッド：メンバー×日付、記号で区別（FR-505, A11Y-04）
• リマインド送信（プレビュー表示）（FR-506）
• 提出が落ちる曜日・時刻の検出と提示（FR-507）
• 「これは評価画面ではなく運用画面です」の旨を明記（ETH-03）
• SC-202 返信率：上司別、平均返信時間、返信されていない日報の抽出（FR-508, FR-509）
• SC-203 入力時間の分布：チーム平均、ヒストグラム、テンプレート別、前日コピー比較（FR-510, FR-512）
• 個人別ランキングを作らない。表としても読めるようにする（FR-511, A11Y-12）
• SC-230 数値集計レポート（FR-513）

4-2. テンプレートと設定

• SC-210 テンプレート管理：項目の追加・削除・D&D並び替え + キーボード操作（FR-601, A11Y-03）
• EstimateBadge.tsx：画面上部に「項目数 N／推定入力時間 M分S秒」を常時表示（FR-602）
• 項目を追加・削除すると即座に更新されること（FR-604）
• SC-211 書き手視点のプレビュー（FR-605）
• チーム別のテンプレート割当（FR-606）
• テンプレート変更後も、過去の日報が当時の構造で表示されること（FR-607）
• SC-220 提出ルール：期限・対象曜日・曜日別リマインド時刻・編集可能時間（FR-608, FR-609）
• SC-221 チーム・メンバー管理（FR-610）
• SC-222 案件・作業種別マスタ（使用件数と未使用の検出）(FR-611)
• SC-223 通知文面の設定（FR-612）
• SC-240 操作ログ（FR-613）

Phase 4 完了チェック

• フローCが完走する（返信率の悪化に気づく → 未提出の曜日集中を発見 → リマインド時刻とテンプレートを調整）
• 4章「ロールを跨ぐ体験」の4と5が動作する
• テンプレートに項目を追加すると推定入力時間が伸びる
• 個人別の入力時間ランキングがどこにも存在しない

Phase 5 — オフライン・記事統合・仕上げ（3日）

5-1. オフライン

• Service Worker / PWA マニフェスト／オフライン検知とバナー
• オフラインでの作成・下書き保存・提出と未同期バッジ（FR-118）
• オンライン復帰時の自動同期
• localStorage 上限時の圧縮処理（NFR-17）

5-2. 記事統合

• 記事側の埋め込みコードを作成し、実際の記事ページで動作確認（EMB-01〜07）
• 埋め込みで「実際に書けて、秒数が出る」ことを複数ブラウザで確認
• 記事の Core Web Vitals を埋め込み前後で比較検証
• 「全画面で試す」カードの設置
• 資料PDF（日報の目的整理シート・損益分岐計算シート）の作成とダウンロード導線
• 元記事リンク・問い合わせ導線
• GA4 イベント設定。input_seconds と copy_yesterday_used を必ず含める（EMB-08, EMB-09）
• GA4 に日報の本文を送っていないことを確認（EMB-10, SEC-03）
• ?embed=1 を noindex に、デモ本体の title / description / OGP（EMB-11）

5-3. 体験の総点検

• 4章「ロールを跨ぐ体験」の7パターンをすべて手動で確認
• 全28画面を開き、空の画面が1つもないことを確認
• 日報の本文にダミー文が1件も残っていないことを確認
• 空状態（データ0件／絞り込み0件）の出し分けを確認
• ETH-01〜06 の倫理要件をすべて確認（個人別ランキングがない、評価に使えない、監視機能がない）
• ガイドツアーを実装（FR-712）

5-4. アクセシビリティ監査

• axe-core を全画面に実行し、Critical / Serious を0件に
• 本文のコントラスト比が7:1以上であることを実測（A11Y-01）
• 「課題あり」「未読」「提出状況」が色のみで伝えられていないことを確認（A11Y-04, A11Y-05）
• キーボードのみで全画面・入力・タイムライン・テンプレート管理を完遂
• スクリーンリーダーで不足項目の案内と提出完了が読み上げられることを確認
• フォントサイズ200%での確認（A11Y-14）

5-5. パフォーマンス

• グラフを動的import に切り出し、初期バンドルを180KB以下に（NFR-14）
• 文字入力で1フレームも落ちないことを実測（NFR-01）
• 提出200ms以下、検索100ms以下、週次まとめ生成300ms以下を実測（NFR-03, NFR-04, NFR-06）
• タイムラインのスクロール60fpsを実測（NFR-09）
• Lighthouse で Performance 95 / Accessibility 95（NFR-15）

5-6. 公開と記録

• Playwright で フローA・B・C の E2E
• Vitest：lib/metrics lib/summary lib/search _scope のカバレッジ85%以上
• /dev/components を本番で非公開に
• Vercel へデプロイ
• input_seconds の分布と copy_yesterday_used の利用率の記録を開始（COST-01〜03）
• 解説動画（3分）の収録：前日コピーで書く → 入力時間1分12秒 → 上司が読んでコメント → 既読が見える → テンプレートに項目追加で推定時間が伸びる → 返信率ダッシュボード
• 各フェーズのキャプチャを整理し、記事の「方法」パートの素材にまとめる

合計 21営業日（約4週間）／1名専任 + レビュー体制。

工数配分の意図： Phase 1（入力体験）に4日を割いているのは、このアプリの価値が入力の速さに集約されているから。前日コピー、チップ選択、下書き自動保存、残り項目の提示、入力時間の計測——どれ1つ欠けても「書くのが面倒」に戻る。 Phase 4（運用の計測）に4日を割いているのは、「日報アプリは作って終わりではない」という記事の主張を、機能として証明する部分だから。提出率・返信率・推定入力時間が測れることが、他の日報アプリとの差になる。

13. 受入基準

1. 6章の優先度 P1 の要件がすべて実装され、テストで合格していること
2. 5章の主要フローA・B・Cが、エンドツーエンドで完走すること
3. 4章「ロールを跨ぐ体験」の7パターンがすべて動作すること
4. 文字入力で1フレームも落ちず、下書き保存が入力をブロックしないこと
5. 入力時間が計測され、タブ非表示中と30秒以上の無操作が加算されていないこと
6. 複数回に分けて書いた場合、入力時間が累積されること
7. 「前日をコピー」で大半の項目が埋まり、「あと N項目」が明示されること
8. 提出後に入力時間が表示され、平均との比較が出ること。遅い場合に評価的な文言が出ないこと
9. 提出がワンタップで、確認ダイアログが出ないこと。不足項目が押す前に提示されること
10. 日報が「報告／課題・相談／気づき」の3ブロックで構造化されていること
11. 「気づき」が空でも提出でき、催促の文言が出ないこと
12. 「課題・相談」の公開範囲を書き手が選べ、「上司のみ」の場合に対象外メンバーへ返らないこと（リポジトリの段階で除外）
13. 既読が3秒以上の表示で記録され、書き手側にも既読者が表示されること
14. 課題ありの日報が視覚的に前に出て、未対応3日以上が強調されること
15. 週次まとめが日報から自動生成され、根拠の日報にリンクが張られ、必ず下書きであること
16. 生成できなかった項目が明示されること
17. 全文検索が100ms以下で、ヒット箇所がハイライトされること（自前実装であること）
18. 運用ダッシュボードに提出率・返信率・平均入力時間・未読率の4指標と前週比が出ること
19. テンプレート管理に「項目数と推定入力時間」が常時表示され、項目の追加・削除で即座に更新されること
20. 個人別の入力時間ランキングが、どの画面にも存在しないこと。個人別の入力時間が本人以外に返らないこと
21. 提出状況グリッドに「評価画面ではない」旨が明記されていること
22. メンバーが他チームの日報を一切取得できないこと
23. テンプレート変更後も、過去の日報が当時の構造で表示されること
24. 初期バンドルが180KB以下、Lighthouse Performance 95以上であること
25. 日報の本文にダミー文（「本日の業務を行いました」等）が1件も存在しないこと
26. 日報の本文・氏名・画像が外部に一切送信されていないこと（DevTools と GA4 のイベントで確認）
27. 全28画面のいずれにも空の状態がなく、リアルなデータが表示されていること
28. 本文のコントラスト比が7:1以上であること
29. 「課題あり」「未読」「提出状況」が色のみで伝えられていないこと
30. axe-core で Critical / Serious の指摘が0件であること
31. データアクセスがすべて lib/repo/ を経由し、入力時間の計測が lib/metrics/input-timer.ts に集約されていること
32. RELATE / KURA / TOKIWA と並べたときに、明確に別のプロダクトとして見えること（1カラム・広い余白・15px本文が効いていること）

判断に迷ったときのルール

1. 仕様がこの文書にない場合は、実装せずに質問する。 推測で作らない
2. 入力を増やす機能を提案しない。 機能追加は「入力を減らす」か「読まれるようにする」に寄与すること。これがこのプロジェクトで最も重要なルール
3. 入力の反応速度を最優先する。 入力中に重い処理を走らせない。下書き保存も入力をブロックしない
4. 入力時間で人を評価させない。 個人別ランキングを作らない。本人以外に個人別の値を返さない（ETH-01, SCP-04）
5. 提出率を評価指標として提示しない。 運用画面であることを明記する（ETH-03）
6. リマインドで責めない。 文言を厳しくしない（ETH-04）
7. 書き手の心理的安全を仕様で守る。「課題・相談」の公開範囲を書き手が選べること（ETH-05）
8. 監視機能を実装しない。 位置情報・スクリーンショット・操作の記録による書き手の監視はしない（ETH-06）
9. 週次まとめはルールベースで、必ず下書き。 AIを呼ばない、自動提出しない
10. リッチテキストエディタを入れない。 バンドルと入力速度を守る
11. 全文検索を自前で書く。 ライブラリを入れない。これが記事の技術パートの見せ場
12. 日報の本文にダミー文を残さない。 このデモは本文の質がそのまま説得力になる
13. スコープ外（3章 Won't have）は実装しない。特に承認ワークフロー・工数管理・AI添削は入力増につながる
14. 「デモだから」を理由に品質を落とす判断はしない
15. RELATE / KURA / TOKIWA のトークン・コンポーネントをコピーしない。 HIBI だけが1カラム・広い余白・15px本文