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

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

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

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

• 実装は「12. 実装タスク」の順に進める。フェーズを飛ばさない。
• 各タスクの括弧内は要件ID。着手前に該当章を読むこと。
• 仕様がここに書かれていない場合は、推測で実装せず質問する。
• スコープ外（3章 Won't have）は、思いついても実装しない。
• 「デモだから」を理由に品質を落とす判断はしない。
• この領域だけの特別ルール：紙より速いことを常に確認する。 点検表の電子化は、1項目あたりのタップ数と所要秒数が紙を上回った瞬間に使われなくなる。機能を足すときは必ず「タップ数が増えないか」を確認すること（1章）。

姉妹プロジェクトとの関係 HIREBASE（求人）／ RELATE（顧客管理）／ CASTA（動画配信）／ FIELDPIN（位置情報）／ KANADE（音楽）／ MIWAKE（画像認識）／ KAMIWAZA（美容室予約）／ KURA（在庫管理）／ TOKIWA（勤怠・シフト）／ HIBI（日報）に続くシリーズ。並べて「同じテンプレ」と思われた時点で失敗。 特に FIELDPIN / HIBI との差別化に注意。 FIELDPIN＝地図全画面・16px大型UI・屋外向け（現場で使わせる）／ HIBI＝1カラム・広い余白・15px本文（読み書きさせる）／ TENKEN＝1画面1項目の超大型UI。判定ボタンが画面の半分を占める。手袋・片手・薄暗い場所で、見ずに押せる。（黒地に近い高コントラスト＋安全色） FIELDPIN より更に大きく、更に少ない。 TENKEN は1画面に1つのことしかさせない。8章参照。

目次

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

1. プロジェクト概要

背景と目的

「点検表を電子化したい」という相談の背景は、ほぼ次のいずれか。

• 紙の点検表が段ボールで積み上がっている。過去の記録を探せない
• 転記作業が地獄。現場で紙に書いて、事務所でExcelに打ち直している
• 不備が見つかっても、いつからそうだったのか分からない
• 法令で保存義務があるのに、紙が濡れる・破れる・なくなる

そして、この領域には他のテーマにない厳しさが3つある。

厳しさ①：紙より遅くなった瞬間に、使われなくなる

紙の点検表は驚くほど速い。チェック欄に鉛筆でレ点を入れるのに1秒もかからない。

これに対してアプリが「項目をタップ → セレクトを開く → 選択肢を選ぶ → 閉じる」だと、1項目に3〜4秒かかる。30項目あれば紙30秒 vs アプリ2分。 現場は紙に戻る。

点検表の電子化の成否は、機能ではなく「1項目あたりのタップ数」で決まる。 目標は 1項目1タップ。これを超えたら、その項目設計は失敗している。

だから TENKEN は1画面1項目の超大型UIを採用する。画面の半分を判定ボタンが占め、手袋のまま、見ずに、片手で押せる。

厳しさ②：点検は「記録」ではなく「異常の発見と是正」のプロセス

点検表を「記録を残すシステム」と考えると失敗する。点検の目的は異常を見つけて直すこと。

点検 → 異常あり → 誰かが直す → 直ったことを確認 → 次の点検
        ↑                                      │
        └──────────────────────────────────────┘
                  ここが繋がっていないと、
              「異常あり」が記録されるだけで放置される

紙の点検表の最大の欠点はここ。 異常を書いても、それが是正されたかどうかを追う仕組みがない。電子化の価値は「記録が楽になる」ことではなく、「異常が追跡される」ことにある。

TENKEN は異常（NG判定）を必ず是正タスクに変換し、完了まで追跡する。

厳しさ③：点検表は法令・取引先要求で形式が決まっていることが多い

日報や顧客管理と違い、点検表は自由に設計できないことが多い。

だから「既存の紙の点検表をそのまま再現できるか」が要件の出発点になる。 ゼロから項目を設計する案件は少ない。

そして保存義務がある。 記録の改ざん防止と、指定期間の保存が求められる。

TENKEN はこの3つの厳しさを前提に設計する。

プロダクト定義

プロダクトコンセプト

「1項目、1タップ、0.8秒。」

TENKEN は点検の所要時間を計測し、紙との比較を表示する。1画面1項目、画面の半分を占める判定ボタン、スワイプで次へ。手袋のまま、画面を見ずに押せることを設計の中心に置く。そして押された「NG」は、必ず誰かのタスクになる。

デモとしての成功条件

1. 速いことが分かる — 30項目の点検を通しで実施でき、所要時間とタップ数が表示される
2. 1項目1タップである — OK判定はボタン1つ。セレクトを開かせない
3. NGが追跡される — NG判定すると是正タスクが自動生成され、完了まで追える
4. オフラインで完結する — 機内モードでも点検を最初から最後まで実施できる
5. 紙の帳票が出る — 既存の紙と同じレイアウトのPDFが実際にダウンロードできる
6. 改ざんできないことが分かる — 記録の修正が履歴として残り、元の値が消えない
7. リセットできる — 誰が触った後でも初期状態に戻せる

2. アーキテクチャ方針

基本方針

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

なぜこの構成にするか

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

オフラインファーストの原則（最重要の設計判断）

点検現場は電波が入らない。 機械室、地下、屋上、山間部、工場内、冷蔵倉庫——点検すべき場所ほど電波がない。

だから TENKEN は「オフライン対応」ではなく**「オフラインが既定」**として設計する。

[ 起動 ]        Service Worker からアプリを起動（通信不要）
    ↓
[ 点検表の取得 ] 事前にダウンロード済みのものを IndexedDB から読む
    ↓
[ 点検の実施 ]  すべてローカル。1項目1タップ。写真も端末内
    ↓
[ 完了 ]        ローカルに確定保存。★ この時点で記録は成立している
    ↓
[ 同期 ]        通信が回復したときに送信。★ 同期は「後片付け」であって、点検の一部ではない

OFF-02 が最も重要。 「同期できないと完了にならない」設計にすると、現場で作業が止まる。記録の成立とデータの送信は別物。

1項目1タップの原則（厳しさ①への回答）

記録の改ざん防止（厳しさ③への回答）

点検記録には保存義務があり、改ざん防止が求められる。

差し替え可能性の担保

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

[ コンポーネント ]
        ↓  呼ぶのはこの層だけ
[ lib/repo/*.ts ]   ← 全メソッドを async にしておく
        ↓
[ lib/inspection/ ] ← 判定・是正生成・完了判定（純粋関数）
[ lib/report/ ]     ← 帳票レイアウト（純粋関数）
[ lib/metrics/ ]    ← タップ数・所要時間（純粋関数 + タイマー）
[ lib/store/*.ts ]  ← Zustand + persist（localStorage / IndexedDB）
        ↓
[ lib/seed/*.ts ]   ← 初期データ

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

記事への組み込み

記事内で見せるのは「1項目1タップで、どれだけ速いか」だけに絞る。 これが厳しさ①そのものであり、スクロール中に体験できる唯一のことになる。

永続化の範囲

擬似ディレイ は 150〜400ms。ただし判定タップ・次項目への遷移・途中保存は擬似ディレイを入れず、100ms以下とする（点検のテンポが崩れるのは、このアプリで最も致命的）。

3. スコープ定義

点検を実施する（現場担当）

是正を追跡する（厳しさ②への回答）

管理する（管理者）

共通・基盤

対象外（Won't have）

スコープリスク： 点検表は「既存の紙をそのまま再現したい」が絶対条件になる領域。そして紙のレイアウトは驚くほど自由。 罫線の結合、縦書き、備考欄の位置、押印欄——帳票の再現度が要件の8割を占めることがある。 後付けは大改修になるため、要件定義の最初に「現物の紙を全種類集める」ことが必須。資料PDFの「点検表ヒアリングシート」はこのために作る。

4. ロールとデモ切替

ロール定義

データスコープと権限の要点

SCP-05 が重要。 「管理者なら履歴なしで直せる」設計にすると、改ざん防止が成立しない。権限は「できるか」を決めるが、「履歴を残すか」は決めない。

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

1. 現場担当が点検を実施し、1項目をNGにする → 責任者に切替 → 是正タスクが自動生成されており、未対応として並んでいる
2. 責任者が是正タスクを担当者に割り当てる → 現場担当に切替 → 自分のタスクに現れている
3. 現場担当が是正を実施して完了報告 → 責任者に切替 → 承認待ちに出る。承認するまで「完了」にならない
4. 責任者が点検記録を修正する → 現場担当に切替 → 修正後の値が見え、「修正あり」のバッジと元の値が確認できる
5. 管理者が点検表に項目を5つ追加 → 現場担当に切替 → 項目が増え、平均タップ数の警告が管理画面に出ている
6. 同じ設備の同じ項目を3回連続でNGにする → 管理者に切替 → 再発として検出され、強調表示されている
7. 機内モードにして点検を最初から最後まで実施 → 完了できる → オンラインに戻す → 自動同期される

1番と7番が、このデモの核心。 厳しさ②（異常追跡）と、オフラインファーストが体験として成立する瞬間。

デモ切替バー（F-S01）

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

• 現在のロールと氏名・拠点の表示、3ロールの切替
• 現場担当ロール時：2拠点から選択
• オフライン状態と未同期件数（常時表示。OFF-04, OFF-05）
• デモ内の現在日時
• 「デモをリセット」ボタン（確認ダイアログ付き）
• 元記事へ戻るリンク
• 「これはデモです。点検記録は送信されません」の明示

デザイン上の扱い： 点検画面が黒地に近い高コントラストなので、切替バーは明るいグレーの帯にして区別する（他プロジェクトと逆）。

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

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

点検を実施する（現場担当）

是正を追跡する（責任者）

管理する（管理者）

主要フロー

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

SEO記事を読んでいる
   ↓
記事内の埋め込み（SC-900）
┌──────────────────────────────────────────────────────┐
│  1号機 日常点検                            3 / 5     │
│  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  │
│                                                      │
│         油漏れの有無                                 │
│                                                      │
│         前回：異常なし（8/19）                        │
│                                                      │
│  ┌────────────────────┐  ┌────────────────────┐     │
│  │                    │  │                    │     │
│  │        OK          │  │        NG          │     │
│  │      異常なし       │  │      異常あり       │     │
│  │                    │  │                    │     │
│  └────────────────────┘  └────────────────────┘     │
│                                                      │
│  [ 該当なし ]                            [ 戻る ]    │
└──────────────────────────────────────────────────────┘
   ↓
「OK」を押す
   ↓  ★ 判定と同時に、自動で次の項目に進む（TAP-03）
   ★ ボタンを押した位置から次の項目がスライドしてくる
   ↓
5項目を通しで判定（うち1つをNGにしてみる）
   ↓  ★ NG を押すと、その場で症状の選択と写真の欄が開く（SC-013）
完了
   ↓
┌──────────────────────────────────────────────────────┐
│  点検を完了しました                                   │
│                                                      │
│      所要時間  4.6秒        タップ  6回              │
│                                                      │
│      1項目あたり  0.9秒 / 1.2タップ                   │
│                                                      │
│  紙の点検表（レ点を書く場合）の目安：1項目あたり 1.5秒  │
│  → 電子化しても遅くなっていません                     │
│                                                      │
│  異常 1件 → 是正タスクを作成しました                  │
│                                                      │
│  [ 全画面で30項目の点検を試す ]                        │
└──────────────────────────────────────────────────────┘
   ↓
「全画面で試す」→ 別タブ
   ↓
SC-012 で30項目の点検を通しで実施 ── ★ テンポが崩れないことを体感
   ↓
SC-017 完了結果 ── ★ 30項目でも所要時間が出る
   ↓
ロール切替「責任者」→ SC-100 是正タスク一覧
   ↓  ★ たった今のNGが是正タスクとして並んでいる
SC-230 帳票PDF出力 ── ★ 紙と同じレイアウトのPDFが実際にダウンロードできる
   ↓
資料ダウンロード or 元記事に戻る

フローB：NGが是正完了まで追跡される（厳しさ②の実装を見せる）

【現場担当】SC-012 点検の実施
  「ベルトの張り」→ NG
   ↓  ★ その場で詳細入力が開く（SC-013）
  症状：「摩耗」を選択 → 写真1枚 → コメント「亀裂あり、交換要」
   ↓
点検完了
   ↓  ★ NG判定から是正タスクが自動生成される（F-C01）
     タスク：「1号機 ベルトの張り：摩耗（亀裂あり、交換要）」
     状態：未対応 / 期限：未設定
   ↓
【責任者】SC-100 是正タスク一覧
  ★ 未対応として並んでいる。点検記録へのリンク付き
   ↓
SC-102 担当者の割当
  担当：田中 / 期限：3日後 → 通知プレビューを確認して割当
   ↓
【現場担当（田中）】SC-030 自分の是正タスク
  ★ 割り当てられたタスクが現れている
   ↓
SC-031 是正の実施
  対応内容：「ベルト交換（品番 XX-1234）」
  ★ 対応前の写真（点検時のもの）が自動で表示される
  対応後の写真を撮影 → 完了報告
   ↓
【責任者】SC-101 是正タスクの詳細
  ★ 承認待ちに出る。対応前／対応後の写真が並んで表示される
  ★ 承認するまで「完了」にならない
   ↓
承認
   ↓
【次回の点検】SC-012
  ★ 「ベルトの張り」の項目に、前回の是正内容が表示される
    「前回：NG（摩耗）→ ベルト交換済（8/22）」
   ↓
★ ここで伝わること：
  「NGを記録するだけでは意味がない。是正されて、次の点検で確認されて初めて閉じる」

フローC：オフラインで点検を完結する（現場の現実）

【現場担当】機械室に入る（電波なし）
   ↓
アプリを起動
   ↓  ★ Service Worker から起動。通信なしで立ち上がる（OFF-01）
   ★ 上部に「オフライン（点検は通常どおり行えます）」
     ※ 警告色ではない。これが正常な状態だから（OFF-04）
   ↓
SC-010 設備の選択 ── ★ 事前にダウンロード済みの設備・点検表が並ぶ
   ↓
SC-012 点検の実施 ── 30項目を判定
  ★ 写真も撮れる（IndexedDB に保存。OFF-03）
  ★ 途中でアプリが落ちても、SC-012 を開き直せば中断地点から再開（F-I08）
   ↓
SC-016 署名 → 完了
   ↓  ★ この時点で点検記録は成立している（OFF-02）
   ★ 「未同期 1件」のバッジが付く
   ↓
機械室を出る（電波が戻る）
   ↓  ★ 自動で同期開始。「同期中 1/1」→「同期しました」
   ★ 未同期バッジが消える
   ↓
【責任者】SC-110 点検実施状況
  ★ グリッドが「実施済」に変わっている
   ↓
★ ここで伝わること：
  「点検すべき場所ほど電波がない。だからオフラインは対応ではなく、既定でなければならない」

6. 機能要件

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

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

6.2 写真・署名

6.3 オフラインと同期

6.4 是正の追跡（厳しさ②への回答）

6.5 記録の完全性（厳しさ③への回答）

6.6 点検表テンプレートと帳票

6.7 スケジュールと実施管理

6.8 分析

6.9 デモ基盤

7. データ設計

型定義（lib/types/）

// ---- 組織・設備 ----
type Site = { id: string; name: string; address: string }        // 拠点
type Member = {
  id: string
  name: string                  // ★ 架空
  siteIds: string[]             // 担当拠点。スコープ判定の起点
  role: 'inspector' | 'supervisor' | 'admin'
  avatarUrl: string
  isActive: boolean
}

type Equipment = {
  id: string
  code: string                  // 管理番号
  name: string                  // ★ 架空（「1号機 空調機」等）
  siteId: string
  location: string              // 設置場所（「B1 機械室」）
  model: string
  manufacturer: string
  installedAt: string
  sheetIds: string[]            // 紐づく点検表
  qrToken: string               // QRコードの値
  isActive: boolean
}

// ---- ★★★ 点検表テンプレート ★★★ ----
type JudgeType =
  | 'ok_ng'            // 良否（2値）★ 1タップ
  | 'three_state'      // 良/要注意/不良（3値）★ 1タップ
  | 'number'           // 数値
  | 'select'           // 単一選択
  | 'multiselect'      // 複数選択
  | 'text'             // テキスト
  | 'photo_only'       // 写真のみ

type SheetItem = {
  id: string
  sectionId: string
  label: string
  labelKana?: string            // ★ ふりがな（FR-118）
  judgeType: JudgeType
  // --- 判定の設定 ---
  options?: string[]            // select / multiselect
  numberConfig?: { unit: string; min?: number; max?: number; decimals: number; warnDiffFromPrev?: number }
  symptomOptions?: string[]     // ★ NG時の症状（ボタンで選ばせる。FR-108）
  // --- 入力の要件 ---
  isRequired: boolean
  photoRule: 'none' | 'optional' | 'required' | 'required_on_ng'
  allowNa: boolean
  showPreviousValue: boolean    // ★ 前回値の表示（FR-106）
  helpText?: string
  criteria?: string             // 判定基準（「油量が下限線以上」）
  sortOrder: number
  // ★ タップ数の算出に使う（FR-605）
  estimatedTaps: number
  estimatedSeconds: number
}

type SheetSection = { id: string; name: string; sortOrder: number }

type InspectionSheet = {
  id: string
  version: number               // ★ 過去の記録は当時の構造で表示（FR-614）
  name: string
  sections: SheetSection[]
  items: SheetItem[]
  requireSignature: boolean
  effectiveFrom: string
  // --- 帳票レイアウト（FR-609, FR-610）---
  layout: ReportLayout
  // --- 算出値（保存しない）：itemCount, avgTaps, estimatedTotalSeconds
}

type ReportLayout = {
  template: 'horizontal_checklist' | 'vertical_form' | 'matrix'
  header: { showEquipmentName: boolean; showCode: boolean; showLocation: boolean; showModel: boolean }
  showStampBox: boolean         // 押印欄
  stampBoxLabels: string[]      // 「実施者」「確認者」「承認者」
  remarksPosition: 'bottom' | 'right' | 'none'
  includePhotoPages: boolean
  paperSize: 'A4' | 'A3'
  orientation: 'portrait' | 'landscape'
}

// ---- ★★★ 点検記録（確定後は値を上書きしない）★★★ ----
type InspectionStatus = 'in_progress' | 'completed' | 'voided'

type Inspection = {
  id: string
  equipmentId: string
  sheetId: string
  sheetVersion: number          // ★ 当時の構造で表示（FR-614）
  scheduledDate?: string        // 予定日（スケジュールから生成された場合）
  status: InspectionStatus
  // --- 結果 ---
  results: InspectionResult[]
  // --- 実施情報（REC-04）---
  inspectorId: string
  startedAt: string
  completedAt?: string
  device: 'mobile' | 'tablet' | 'pc'
  coord?: { lat: number; lng: number }   // 設定時のみ
  signatureImageId?: string     // IndexedDB のキー
  // --- 完全性（REC-06）---
  contentHash?: string
  // --- 無効化（REC-05。削除はしない）---
  voidedAt?: string
  voidedBy?: string
  voidReason?: string
  // --- ★ 計測（TAP-06）---
  metrics: {
    activeSeconds: number
    totalTaps: number
    itemSeconds: Record<string, number>   // itemId → 秒数
    interruptionCount: number             // 中断回数
  }
  // --- 同期 ---
  syncState: 'local' | 'synced'
  createdAt: string
}

type InspectionResult = {
  itemId: string
  // --- 判定値 ---
  judgment?: 'ok' | 'ng' | 'good' | 'caution' | 'bad' | 'na'
  numberValue?: number
  selectedOptions?: string[]
  textValue?: string
  // --- NG時の詳細（FR-107）---
  symptoms?: string[]
  comment?: string
  // --- 添付 ---
  photoIds: string[]            // IndexedDB のキー
  // --- N/A の理由 ---
  naReason?: string
  // --- 計測 ---
  taps: number
  seconds: number
  recordedAt: string
  // --- ★ 修正履歴（REC-01）。値は上書きしない ---
  revisions: ResultRevision[]
}

// ★ 確定後の修正は、必ずこのレコードで表現する
type ResultRevision = {
  id: string
  revisedBy: string
  revisedAt: string
  reason: string                // ★ 必須（REC-02）
  before: Partial<InspectionResult>   // ★ 元の値（REC-03）
  after: Partial<InspectionResult>
}

// ---- ★ 是正タスク（NGから必ず生成される）----
type CorrectionStatus = 'open' | 'in_progress' | 'pending_approval' | 'completed' | 'not_required'

type Correction = {
  id: string
  // --- 発生元（FR-402）---
  inspectionId: string
  itemId: string
  equipmentId: string
  itemLabel: string
  symptoms: string[]
  comment: string
  beforePhotoIds: string[]      // ★ 点検時の写真（FR-407）
  detectedAt: string
  detectedBy: string
  // --- 割当 ---
  assigneeId?: string
  dueDate?: string
  priority: 'low' | 'normal' | 'high'
  // --- 対応（FR-406）---
  status: CorrectionStatus
  actionTaken?: string
  partsUsed?: string
  afterPhotoIds: string[]
  reportedBy?: string
  reportedAt?: string
  // --- 承認（FR-408）---
  approvedBy?: string
  approvedAt?: string
  rejectReason?: string
  // --- 対応不要（FR-404）---
  notRequiredReason?: string
  // --- 算出値：daysOpen, isOverdue
}

// ---- スケジュール ----
type Schedule = {
  id: string
  equipmentId: string
  sheetId: string
  frequency: 'daily' | 'weekly' | 'monthly' | 'quarterly' | 'yearly'
  weekdays?: number[]           // weekly
  dayOfMonth?: number           // monthly
  months?: number[]             // quarterly / yearly
  assigneeId?: string
  dueOffsetDays: number         // 予定日から何日以内に実施すべきか
  isActive: boolean
}

// ---- 算出値（ストアに保存しない）----
type SheetMetrics = {            // FR-605〜607
  sheetId: string
  itemCount: number
  avgTapsPerItem: number         // ★ 1.2超で警告（FR-606）
  estimatedTotalSeconds: number
  hasWarning: boolean
  warningReasons: string[]       // 「選択項目が多い」「必須テキストが3つある」
}
type DurationStats = {           // FR-806
  sheetId: string
  sheetName: string
  itemCount: number
  avgSecondsPerItem: number
  avgTapsPerItem: number
  paperBaselineSecondsPerItem: number   // ★ 紙の目安（既定1.5秒）
  isFasterThanPaper: boolean
  // ★ 個人別は含めない（FR-809）
}
type RecurringNg = {             // FR-411
  equipmentId: string
  itemId: string
  itemLabel: string
  ngCount: number
  recentCount: number            // 直近N回中
  lastNgAt: string
  openCorrectionId?: string
}
type LeadTimeStats = { scope: string; avgDays: number; medianDays: number; overdueCount: number }
type ComplianceStats = { plannedCount: number; completedCount: number; completionRate: number; overdueCount: number }

// ---- 監査・通知 ----
type AuditLog = {
  id: string
  actorId: string
  action: 'revise_result' | 'void_inspection' | 'approve_correction' | 'reject_correction'
        | 'update_sheet' | 'update_schedule' | 'export_pdf'
  targetType: string
  targetId: string
  reason?: string               // ★ 修正・無効化は理由必須
  changes: { field: string; before: unknown; after: unknown }[]
  createdAt: string
}
type Notification = {
  id: string
  targetMemberId: string
  kind: 'scheduled_today' | 'not_performed' | 'correction_assigned' | 'correction_overdue'
      | 'correction_approved' | 'correction_rejected' | 'recurring_ng'
  title: string
  body: string
  link: string
  previewMessage?: { channel: 'email' | 'chat'; subject?: string; body: string }  // ★ 送信しない
  readAt?: string
  createdAt: string
}

タップ数と所要時間の算出（7章の中核）

// lib/metrics/taps.ts — 判定種別ごとの最小タップ数（FR-605）
const MIN_TAPS: Record<JudgeType, number> = {
  ok_ng: 1,          // ★ 1タップ
  three_state: 1,    // ★ 1タップ（3つ並べる）
  select: 1,         // ★ 選択肢3つ以下ならボタンで1タップ（TAP-05）
  multiselect: 2,    // 選択 + 確定
  number: 3,         // テンキー入力の平均
  text: 4,           // キーボード入力の平均（重い）
  photo_only: 2,     // 撮影 + 確定
}

export function calcSheetMetrics(sheet: InspectionSheet): SheetMetrics {
  const items = sheet.items
  const totalTaps = items.reduce((sum, it) => {
    let taps = MIN_TAPS[it.judgeType]
    // 選択肢が4つ以上ある select は、セレクトを開く分のタップが増える
    if (it.judgeType === 'select' && (it.options?.length ?? 0) > 3) taps += 1
    // 写真必須は撮影分が乗る
    if (it.photoRule === 'required') taps += 2
    return sum + taps
  }, 0)

  const avgTaps = items.length ? totalTaps / items.length : 0
  const warnings: string[] = []
  // ★ 1.2 を超えたら警告（TAP-07, FR-606）
  if (avgTaps > 1.2) warnings.push(`1項目あたり ${avgTaps.toFixed(1)} タップ。紙より遅くなる可能性があります`)
  const textCount = items.filter(i => i.judgeType === 'text' && i.isRequired).length
  if (textCount >= 3) warnings.push(`必須のテキスト項目が ${textCount} 件あります。選択式に変えられませんか`)
  const wideSelects = items.filter(i => i.judgeType === 'select' && (i.options?.length ?? 0) > 3).length
  if (wideSelects > 0) warnings.push(`選択肢が4つ以上の項目が ${wideSelects} 件あります。3つ以下にすると1タップで済みます`)

  return {
    sheetId: sheet.id,
    itemCount: items.length,
    avgTapsPerItem: avgTaps,
    estimatedTotalSeconds: items.reduce((s, i) => s + i.estimatedSeconds, 0),
    hasWarning: warnings.length > 0,
    warningReasons: warnings,
  }
}

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

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

• 実在企業名・実在製品名を使わない。 架空の設備名・型式で構成する
• 設備名・項目名を「設備A」「項目1」のようなダミーにしない。 実在しそうなものにする（「1号機 空調機（AHU-01）」「Vベルトの張り・摩耗」）。点検表のデモは項目名のリアリティがそのまま説得力になる
• 判定基準（criteria）を具体的に書く。「油量が下限線以上であること」「異音・異臭がないこと」。ここが空だと点検表として嘘に見える
• 所要時間・タップ数の実データを持たせる。 1項目あたり 0.7〜2.5秒の分布。テキスト項目が多い点検表は明確に遅く（FR-806 が意味を持つように）
• NG率を項目ごとに変える。 特定の項目（消耗品系）にNGを集中させる。FR-803 の「NGが多い項目ランキング」に意味のあるパターンが出ること
• 再発している組み合わせを2〜3件作る（同一設備・同一項目で直近5回中3回以上NG）(FR-411 の実演用)
• 未是正のまま長期放置されているタスクを数件作る（期限超過30日超を1件含める）
• 是正リードタイムに幅を持たせる（即日〜3週間）。担当者によって差が出るようにする
• 修正ありの記録を数件作る（理由付き。「数値の入力誤りを訂正」等）
• 無効化された記録を1件作る（「誤った設備で開始したため」）
• 未実施の点検を作る。 特に特定の設備が繰り返し未実施になっている状態（FR-703 のグリッドで見えるように）
• 平均タップ数が1.2を超える点検表を1つ作る（テキスト必須が4件、選択肢6つの項目が3件など）。FR-606 の警告が実際に出ること
• 日付は現在日時からの相対で生成する。固定日付を埋め込まない
• 点検記録はスケジュールの予定日に対応して存在すること（年次点検が毎日並んでいると嘘に見える）

ストアとリポジトリ

lib/
├── types/  seed/
├── inspection/                 # ★ 純粋関数のみ
│   ├── flow.ts                 # 次の項目の決定、未判定の抽出、完了判定
│   ├── validate.ts             # 必須・写真必須・数値範囲の検証
│   ├── correction.ts           # ★ NG → 是正タスクの生成（FR-401）
│   ├── recurring.ts            # ★ 再発の検出（FR-411）
│   ├── revision.ts             # ★ 修正履歴の適用（REC-01）
│   └── hash.ts                 # 記録のハッシュ算出（REC-06）
├── metrics/                    # ★ 純粋関数 + タイマー
│   ├── session-timer.ts        # 所要時間・タップ数の計測（TAP-06）
│   ├── taps.ts                 # ★ 点検表の平均タップ数（7章のコード）
│   ├── duration.ts             # 所要時間の集計、紙との比較（FR-806）
│   ├── compliance.ts           # 実施率（FR-705）
│   └── leadtime.ts             # 是正リードタイム（FR-414）
├── report/                     # ★ 帳票。純粋関数
│   ├── layout.ts               # レイアウトの解決（3テンプレート）
│   └── pdf.tsx                 # PDF生成（@react-pdf/renderer）
├── offline/
│   ├── queue.ts                # 同期キュー（OFF-05, OFF-06）
│   └── cache.ts                # 点検表定義のキャッシュ
├── storage/                    # IndexedDB（写真・署名）
├── query/                      # 絞り込み・検索
├── store/  { session, data, draft, sync, ui }
└── repo/                       # ★ コンポーネントが触るのはここだけ
    ├── _delay.ts
    ├── _scope.ts               # ★ データスコープ（SCP-01）
    ├── inspections.ts  results.ts  revisions.ts
    ├── corrections.ts  schedules.ts  equipments.ts
    ├── sheets.ts  reports.ts  metrics.ts  members.ts  logs.ts

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

• 全メソッドを async で定義する。中身が同期でも例外なく
• 戻り値は { ok: true; data: T } | { ok: false; error: string } に統一する
• コンポーネントから Zustand ストアを直接参照しない。 読み取りも書き込みもリポジトリ経由
• 確定した点検結果の値を上書きするコードを書かない（REC-01）。修正は revisions への追加のみ
• 記録を削除するコードを書かない（REC-05）。無効化は status: 'voided' + 理由
• NG判定から是正タスクを生成する処理を、lib/inspection/correction.ts に集約する（FR-401）
• スコープ適用（_scope.ts）を全メソッドが必ず通す
• lib/inspection/ lib/metrics/ lib/report/layout.ts は純粋関数のみ。 ストア・DOM に依存させず、new Date() を内部で呼ばない
• 派生値（平均タップ数・実施率・リードタイム・再発）はストアに保存せず算出する
• 判定タップ・次項目への遷移・途中保存に擬似ディレイを入れない（FR-117）
• 通信状態を見て操作をブロックするコードを書かない（OFF-01, FR-302）

// lib/inspection/correction.ts — NGから是正タスクを必ず生成する（FR-401）
export function buildCorrections(inspection: Inspection, sheet: InspectionSheet): Correction[] {
  return inspection.results
    .filter(r => r.judgment === 'ng' || r.judgment === 'bad')   // ★ 例外なく生成
    .map(r => {
      const item = sheet.items.find(i => i.id === r.itemId)!
      return {
        id: newId(),
        inspectionId: inspection.id,
        itemId: r.itemId,
        equipmentId: inspection.equipmentId,
        itemLabel: item.label,
        symptoms: r.symptoms ?? [],
        comment: r.comment ?? '',
        beforePhotoIds: r.photoIds,        // ★ 点検時の写真を引き継ぐ（FR-407）
        detectedAt: inspection.completedAt!,
        detectedBy: inspection.inspectorId,
        status: 'open',
        priority: 'normal',
        afterPhotoIds: [],
      }
    })
}

8. デザイン要件

アートディレクション

「手袋のまま、見ずに押せる」

TENKEN が使われるのは、機械室、屋上、暗い地下、騒音の中、雨天の屋外。手袋をしていて、片手がふさがっていて、画面をじっと見る余裕がない。

だから TENKEN は1画面に1つのことしかさせない。判定ボタンは画面の40%以上を占め、指の位置を覚えれば画面を見ずに押せる。姉妹プロジェクトの中で、情報量が最も少なく、要素が最も大きい。

• 1画面1項目。 一覧は「切替」で提供する。既定は1項目
• 判定ボタンが主役。 画面の40%以上。OK と NG を左右に大きく
• 高コントラスト。 直射日光でも、暗い機械室でも読める。濃い地に明るい文字
• 安全色を使う。 現場の人が身体で覚えている色（緑=良、黄=注意、赤=不良）

姉妹プロジェクトとの差別化（最重要） FIELDPIN も屋外向けの大型UIだが、FIELDPIN は地図が全画面で明るい背景。 TENKEN は濃い地（#14171C 系）に大きな判定ボタン。地図もリストもない。1画面に1項目だけ。 HIBI は「読み書きする1カラム・明るい・15px本文」。TENKEN は「押すだけ・濃い地・28px以上の文字」。 10本並べたとき、TENKEN だけが「濃い地に巨大なボタン2つ」であることが一目で分かること。

カラートークン

:root {
  /* ★ 濃い地。直射日光でも暗所でも読める高コントラスト */
  --bg:          #14171C;   /* 点検画面の背景 */
  --bg-raised:   #1E232B;   /* カード・パネル */
  --bg-overlay:  #29303A;   /* モーダル・詳細入力 */

  --fg-high:     #F5F7FA;   /* 主要テキスト（項目名・ボタンラベル） */
  --fg-mid:      #A7B0BC;   /* 補助テキスト（前回値・基準） */
  --fg-low:      #6B7480;   /* 非活性 */
  --line:        #333B45;

  /* ★ 安全色。現場が身体で覚えている色を使う */
  --ok:          #1E8E4A;   /* 良・OK（緑） */
  --ok-press:    #166F39;
  --caution:     #C48A0E;   /* 要注意（黄） */
  --caution-press:#9C6E0B;
  --ng:          #C0392B;   /* 不良・NG（赤） */
  --ng-press:    #9A2E23;
  --na:          #4A5560;   /* 該当なし（無彩色） */

  /* 状態 */
  --st-done:     #1E8E4A;
  --st-pending:  #C48A0E;
  --st-overdue:  #C0392B;
  --st-void:     #6B7480;

  /* オフライン（★ 警告色にしない。OFF-04） */
  --offline-bg:  #29303A;
  --offline-fg:  #A7B0BC;
  --sync-pending:#C48A0E;

  /* 管理画面（PC）は明るい地に切り替える */
  --admin-bg:    #F4F5F7;
  --admin-panel: #FFFFFF;
  --admin-ink:   #14171C;
  --admin-line:  #DCDFE4;
}

配色ルール

• 点検画面は濃い地、管理画面は明るい地。 使う場所と使う人が違うので、意図的に分ける
• 判定の色は安全色から動かさない。 OK=緑、要注意=黄、NG=赤。デザインの都合で変えない
• オフラインを警告色にしない（OFF-04）。オフラインは正常な状態。未同期件数だけを --sync-pending で示す
• N/A を無彩色にする。 判定ではないことを色で示す
• 押下時に必ず色が変わること（--*-press）。手袋だと触覚のフィードバックが弱いので、視覚で補う

タイポグラフィ

点検画面の最小文字サイズは 15px。 それ以下を使わない。管理画面は13pxの高密度でよいが、点検画面と混ぜない。

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

主要コンポーネント仕様

インタラクション要件（現場UIの肝）

モーション

prefers-reduced-motion: reduce 時は、遷移を即時にし、カウントアップを停止する。 ただし押下時の色変化は残す（フィードバックとして必要）。

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

ライティング規約

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

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

上記以外のライブラリを入れる前に必ず提案し、承認を得ること。特に、点検画面に重いライブラリ（フォームライブラリ・UIキット・アニメーションライブラリ）を持ち込むことは禁止。

点検画面を軽く保つ理由： 判定タップから次項目までを100ms以下に保つ（FR-117）ため、点検画面のバンドルを最小にする。管理画面の重いライブラリ（Recharts / TanStack Table / react-pdf）はすべて動的import で分離し、点検画面に載せない。

ディレクトリ構成

/
├── CLAUDE.md
├── app/
│   ├── layout.tsx                  # ロール別シェル + デモ切替バー
│   ├── page.tsx                    # SC-001 ホーム / SC-900（?embed=1）
│   ├── inspect/                    # SC-010〜017（★ 点検画面。軽さを最優先）
│   ├── history/  records/          # SC-020, 021
│   ├── corrections/                # SC-030, 031（現場）/ SC-100〜103（責任者）
│   ├── notifications/              # SC-040
│   ├── status/  equipments/        # SC-110, 113
│   ├── admin/                      # SC-200〜251
│   └── dev/components/
├── components/
│   ├── judge/                      # ★ 最重要。点検画面の中核
│   │   ├── JudgeButtons.tsx        # ★ 画面40%以上を占める判定ボタン
│   │   ├── ItemLabel.tsx           # 28px の項目名 + 基準 + 前回値
│   │   ├── ProgressHeader.tsx      # 進捗バー + 12/30
│   │   ├── NgDetailSheet.tsx       # NG時の詳細（下から）
│   │   ├── NumberPad.tsx           # ★ 自前テンキー（64px以上のキー）
│   │   ├── SignaturePad.tsx        # Canvas
│   │   └── useInspectionFlow.ts    # 次項目の決定・即座のローカル保存
│   ├── correction/                 # CorrectionCard, BeforeAfterPhotos, ApprovalPanel
│   ├── record/                     # RevisionHistory, ResultTable
│   ├── admin/                      # StatusGrid, SheetEditor, TapWarning, LayoutEditor
│   ├── offline/                    # OfflineBar, SyncBadge, SyncProgress
│   ├── demo/                       # RoleSwitcher, ResetButton, GuideTour, BackToArticle
│   └── layout/
├── lib/
│   ├── types/ seed/ store/ repo/
│   ├── inspection/                 # ★ 純粋関数
│   ├── metrics/                    # ★ 純粋関数 + タイマー
│   ├── report/                     # ★ 帳票（layout は純粋関数、pdf は動的import）
│   ├── offline/ storage/ query/ validation/ utils/
├── docs/
│   └── inspection-checklist.md      # 資料PDFの元原稿（点検表ヒアリングシート）
├── e2e/
└── public/

コーディング規約

• TypeScript strict。any 禁止。やむを得ない場合は unknown + 型ガード
• ファイル名は kebab-case、コンポーネントは PascalCase
• コンポーネントから Zustand ストアを直接参照しない。必ず lib/repo/ 経由
• 確定した点検結果の値を上書きするコードを書かない（REC-01）。修正は revisions への追加のみ
• 記録を削除するコードを書かない（REC-05）
• 通信状態を見て操作をブロックするコードを書かない（OFF-01）
• 判定ごとに即座にローカル保存する（IX-07）。デバウンスしない
• 点検画面に重いライブラリを import しない。 管理画面用のライブラリは必ず動的import
• lib/inspection/ lib/metrics/ lib/report/layout.ts は純粋関数のみ。 ストア・DOM に依存させず、new Date() を内部で呼ばない
• 派生値（平均タップ数・実施率・リードタイム・再発）をストアに保存しない
• 時刻は分数または ISO 文字列で扱い、文字列の切り貼りをしない
• 機能を追加するとき、1項目あたりのタップ数が増えないことを確認する（TAP-08）
• 高さは 100dvh を使う。100vh を使わない
• コミットは1タスクごと。メッセージに要件IDを含める 例：feat(judge): 判定後の自動遷移とスライド方向を実装 (FR-103)

10. 非機能要件・法令

性能要件

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

法令・保存要件に関する取り扱い（この領域固有）

点検表は法令や取引先要求で形式・保存期間が決まっていることが多い。 本デモは実装例であり、法令適合の保証をするものではない。

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

① 分野ごとに記録要件が違う。 消防設備、電気設備、建設機械、車両、食品衛生——それぞれ根拠法令と保存期間が異なる。「点検表アプリ」として汎用に作るのではなく、対象分野の要件を先に確定させる

② 電子化そのものの可否を確認する必要がある。 分野によって、電子的な記録の保存が認められる条件（見読性・完全性・保存性）が定められている場合がある

③ 紙の帳票の再現度が要件の大半を占めることがある。 取引先監査で提出する帳票は、フォーマットが指定されていることが多い。現物の紙を全種類集めることが要件定義の第一歩

④ 改ざん防止は「上書きしない設計」で始まる。 本デモの ResultRevision（REC-01）がその実装例。実案件ではさらに、サーバー側での署名・タイムスタンプ・アクセス制御が必要になる

⑤ 手書き署名画像は、法的な電子署名ではない。 電子署名法に基づく効力が必要な場合は、専用サービスの利用が前提になる

⑥ 保存義務のある記録は、システム更新・事業者変更のときにデータ移行の責任が生じる。 出力可能な形式（PDF・CSV）を常に持たせておくことが、事業継続の観点で重要

本デモはデータをサーバーに送信しないため、①〜⑥の義務は発生しない。「デモである」旨と LAW-01 の注記を画面上に常時明示する

11. 費用設計

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

点検表の電子化だけの特殊事情：帳票の再現度が費用を決める

③を見積もらずに始めると、「アプリはできたが取引先に出せる帳票が出ない」になる。

③の分岐：帳票をどこまで再現するか（最大の費用要因）

「取引先に提出する帳票」がある場合、ほぼCになる。 そして点検表の種類が10種類あればC×10。

本デモはA+B（3種のテンプレート + 設定による調整）で実装している（FR-610）。Cが必要かどうかは、現物の紙を見なければ判断できない。

記事に書くべき一文： 「点検表の電子化で最初にやるべきは、現物の紙を全種類コピーして並べることです。」 それを見ないと、見積もりができない。

②の分岐：見落とされやすい「点検表の棚卸し」

電子化の依頼者自身が、点検表が何種類あるか把握していないことが多い。

• 部署ごとに独自の点検表がある
• 同じ設備なのに拠点で様式が違う
• 使われていない項目が残っている
• 法令要求と社内独自項目が混在している（分けないと簡略化できない）

この棚卸しをせずに電子化すると、紙の非効率をそのままアプリに移すことになる。 そして項目が多い点検表は、紙より遅くなって使われなくなる（1章 厳しさ①）。

TENKEN がテンプレート管理画面に「平均タップ数の警告と改善提案」を出しているのは、この棚卸しの会議で使うためにある（FR-605, FR-606）。資料PDFの「点検表ヒアリングシート」も、この工数を前倒しするために作る。

①の分岐：既製サービスがあるのに、なぜ自作するのか

点検・現場帳票の電子化サービスは充実している。この問いに答えられない案件は、受けるべきではない。

⑤と⑥は、現場系で最も多い動機。 既製サービスは汎用性のために画面が複雑で、現場の人が使わない。

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

損益分岐の計算式

既製サービスの年間コスト
  = 月額単価 × 人数 × 12
  + 初期設定費（点検表の登録代行）
  ( + オプション：帳票カスタマイズ・API連携・保存容量追加 )

回収年数 = （開発費 + 帳票再現費 + ハード費 + 棚卸し工数）
           ÷（既製サービス年間コスト − 自作の年間運用費 − 年間保守費）

④の分岐：端末の選択

判断の目安：

• 1人1台で持ち歩く運用 → 会社支給スマホ
• 班で共有して回る運用 → 業務用タブレット1台を持ち回り
• まず試したい → BYODで開始し、定着したら支給に切り替える

TENKEN が「1画面1項目・巨大ボタン」にしているのは、小さい画面でも成立させるため。 端末選択の自由度を、設計で確保している。

⑤の分岐：写真の保存費（見落とされやすい）

点検アプリは写真が積み上がる。 そして保存義務があるので消せない。

年間の写真容量 = 1点検あたりの写真枚数 × 1枚の平均サイズ × 年間点検回数

例：平均2枚 × 400KB × 年間12,000回 = 約 9.6GB/年
    → 5年保存なら 48GB

「写真は撮れるだけ撮らせる」設計にすると、保存費が線形に増える。 だから TENKEN は端末内で圧縮してから保存し（FR-201）、写真必須の項目を絞る設計にしている。

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

点検は、Webで足りる領域。ただしオフラインの作り込みが条件。

判断の目安： NFC を使う、または実施忘れのプッシュ通知が必須でなければ、Webで十分。通知はチャットツールやメールで代替できる。

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

「このデモを触った読者の点検速度は、1項目あたり中央値 0.9秒でした。紙にレ点を書くのと同じか、それより速い」——この一文が、どんな機能説明よりも強い。

12. 実装タスク

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

Phase 0 — 基盤と計測・判定ロジック（4日）

0-1. 初期化

• Next.js 15 / TypeScript strict / App Router / Tailwind で初期化
• ESLint / Prettier / husky（pre-commit で lint + typecheck）
• 9章のディレクトリ構成を作成
• ローカル開発をHTTPSで行えるようにする（Service Worker・カメラの検証に必須）

0-2. lib/inspection/（純粋関数）

• flow.ts：次の項目の決定、未判定の抽出、完了判定
• validate.ts：必須・写真必須・数値範囲の検証
• correction.ts：NG → 是正タスクの生成（7章のコード参照）(FR-401, FR-402, FR-407)
• recurring.ts：再発の検出（直近N回中M回以上）(FR-411)
• revision.ts：修正履歴の適用。元の値を保持したまま表示用の値を解決する（REC-01, REC-03）
• hash.ts：記録内容のハッシュ算出（REC-06）
• new Date() を内部で呼ばない。現在時刻は引数で受け取る
• 単体テストを網羅的に書く。以下を必ず含めること：
  • NG判定から是正タスクが例外なく生成されること（最重要）
  • 点検時の写真が是正タスクの「対応前」に引き継がれること
  • 修正履歴を追加しても、元の値が失われないこと（REC-01）
  • 修正が複数回あった場合、履歴が積み上がり、最新の値が解決されること
  • 再発の検出が閾値どおりに働くこと
  • 未判定項目の抽出、N/A の扱い
  • 数値の範囲外判定、前回値との差の警告

0-3. lib/metrics/（このデモの主張を支える）

• session-timer.ts：所要時間・タップ数の計測（TAP-06）
• taps.ts：点検表の平均タップ数と改善提案（7章のコード参照）(FR-605, FR-606)
• duration.ts：所要時間の集計、紙との比較（FR-806）
• compliance.ts：実施率（FR-705）
• leadtime.ts：是正リードタイム（FR-414）
• 単体テストを書く。以下を必ず含めること：
  • 判定種別ごとの最小タップ数が正しく算出されること
  • 選択肢4つ以上の select でタップ数が増えること
  • 写真必須でタップ数が増えること
  • 平均タップ数1.2超で警告が出ること、改善提案が付くこと
  • 項目の追加・削除で推定所要時間が変わること
  • 個人別の集計が返らないこと（FR-809）

0-4. 型とシード

• lib/types/ に7章の型定義をすべて実装
• lib/seed/ の全ファイル
• 設備名・項目名・判定基準を、実在しそうな架空のものにする。ダミー文を1件も残さない（最重要）
• 所要時間・タップ数の実データを持たせる。テキスト項目が多い点検表は明確に遅く
• NG率を項目ごとに変える。消耗品系にNGを集中させる
• 再発している組み合わせを2〜3件、長期放置の是正を数件、修正ありの記録を数件、無効化された記録を1件作る
• 平均タップ数1.2超の点検表を1つ作る（FR-606 の警告が実際に出ること）
• 繰り返し未実施になっている設備を作る
• 点検記録はスケジュールの予定日に対応して存在すること
• 日付は現在日時からの相対で生成する

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

• lib/store/{session,data,draft,sync,ui}.ts を Zustand + persist で実装
• lib/repo/_scope.ts を最初に実装する（SCP-01〜05）
• lib/repo/ の全モジュール。全メソッド async、Result型、スコープ適用
• 確定結果を上書きするコードを書かない。修正は revisions への追加のみ（REC-01）
• 記録を削除するコードを書かない。無効化のみ（REC-05）
• 通信状態を見て操作をブロックするコードを書かない（OFF-01）
• スコープの単体テストをこの時点で書く：
  • 現場担当が他拠点の記録を取得できないこと（SCP-03）
  • 現場担当が確定記録を修正できないこと（SCP-04）
  • 権限に関わらず修正履歴が残ること（SCP-05）
• lib/storage/：IndexedDB（写真・署名）
• 判定タップ・遷移・途中保存に擬似ディレイを入れない（FR-117）

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

• app/globals.css に2系統のトークンを定義（点検画面＝濃い地／管理画面＝明るい地）
• tailwind.config.ts を拡張。8pxベースのスペーシング、タップ領域64px を既定に
• フォント（Noto Sans JP 500/700 / Roboto Mono 600）を next/font で最適化
• 100dvh とセーフエリアの対応
• 点検画面用コンポーネントを自前実装（shadcn/ui を使わない）
• shadcn/ui は管理画面用に導入し、明るいトークンに合わせて上書き
• 共通コンポーネント：OfflineBar（警告色にしない）／SyncBadge / EmptyState（2種の出し分け）
• prefers-reduced-motion の対応（押下時の色変化は残す）
• /dev/components にコンポーネントカタログを作成

0-7. デモ基盤

• RoleSwitcher（3ロール + 現場担当の拠点選択）(FR-901)
• デモ切替バー（明るいグレーの帯）+ 「これはデモです。点検記録は送信されません」（SEC-02）
• LAW-01 の注記コンポーネント（テンプレート管理画面・帳票出力画面に常設）
• 「デモをリセット」(FR-905)／ロール権限外アクセス時の案内画面（FR-908）
• 元記事リンク・資料ダウンロード（FR-910）

Phase 0 完了チェック

• lib/inspection/ lib/metrics/ のテストが全パターン通る
• 「NGから是正タスクが例外なく生成される」がテストで検証済み
• 「修正履歴を追加しても元の値が失われない」がテストで検証済み
• 「平均タップ数1.2超で警告と改善提案が出る」がテストで検証済み
• 「現場担当が確定記録を修正できない」がテストで検証済み
• /dev/components で判定ボタンが画面40%以上を占めて表示される

Phase 1 — 点検の実施（5日・最重要フェーズ）

1-1. 判定ボタンと点検フロー

• JudgeButtons.tsx：画面下部40%以上を占める判定ボタン（TAP-02, FR-102）
• 2値／3値に対応。判定ラベル32px + 補足15px（8章）
• 押下で色変化 + 振動（対応端末）（IX-02）
• ItemLabel.tsx：項目名28px + 判定基準 + 前回値（FR-106）
• ProgressHeader.tsx：進捗バー + 12/30（Mono 20px）（FR-111）
• useInspectionFlow.ts：判定後の自動遷移（TAP-03, FR-103）
• 押したボタンの側から次項目がスライドイン（140ms、8章）
• 判定ごとに即座にローカル保存（IX-07, NFR-03）
• 判定タップから次項目表示まで100ms以下を実測（FR-117, NFR-01）
• スワイプでの移動（FR-110, IX-04）／前の項目に戻る（FR-113）
• aria-live での判定通知（A11Y-09）

1-2. 各判定種別

• NumberPad.tsx：自前テンキー（各キー64px以上）（TAP-04, FR-105）
• 範囲外を入力時点で警告。aria-live="assertive"（FR-105, A11Y-11）
• 前回値との差の警告（FR-106）
• 選択肢3つ以下はボタンで並べる（TAP-05, FR-104）
• 選択肢4つ以上のみリスト表示（タップ数が増えることを管理画面で警告）
• テキスト入力（必須は最小限にする設計であることをテンプレート側で警告）
• N/A の1タップ設定と理由選択（FR-109）

1-3. NG詳細・写真・署名

• NgDetailSheet.tsx：NG押下で下から展開。OK時には出さない（FR-107）
• 症状はボタンで並べる（FR-108）
• 写真撮影：Canvas で圧縮（長辺1600px・品質80）→ IndexedDB（FR-201, FR-202）
• 複数枚（3枚まで）、削除（FR-204）
• 写真必須ルール（none / optional / required / required_on_ng）(FR-203)
• 写真の圧縮中も次の項目に進めること（NFR-04）
• SignaturePad.tsx：Canvas での手書き署名（FR-207）
• 署名必須の設定（FR-208）

1-4. 中断・完了

• 点検の途中状態を保存し、中断地点から再開（FR-311, F-I08）
• 中断中の点検一覧と破棄（FR-312）
• SC-015 未判定項目の確認、「まとめてN/A」(FR-112)
• SC-016 署名と完了
• SC-017 完了結果：所要時間・タップ数・1項目あたり・紙との比較（FR-116）
• 完了時に是正タスクを生成（FR-401）
• 記録内容のハッシュ算出（FR-506）
• SC-014 一覧モードへの切替（FR-114）
• SC-010 設備の選択 / SC-011 点検表の選択 / SC-001 ホーム（本日の予定を大きく）(FR-702)

1-5. 埋め込みモード

• SC-900 埋め込みモード：5項目の点検を実際に完了できる（FR-912, EMB-04）
• 完了時にタップ数・所要時間・紙との比較を表示（EMB-05）
• カメラ・位置情報を呼ばない（EMB-06）／アプリ内遷移をしない（EMB-07）
• 初期バンドル 55KB以下を実測（NFR-06）

Phase 1 完了チェック

• フローAが完走する（5項目 → 完了 → タップ数と秒数が出る → 全画面で30項目）
• 1項目1タップで判定できる。セレクトが1つも開かない
• 判定タップから次項目まで100ms以下
• 点検画面のバンドルが90KB以下（NFR-05）
• 画面を消しても点検が失われず、中断地点から再開できる
• 30項目を10回連続実施してもメモリが単調増加しない

Phase 2 — オフラインと同期（3日）

• Service Worker / PWA マニフェスト。オフラインでアプリが起動すること（FR-304, OFF-01）
• 設備・点検表定義の事前キャッシュ（FR-305）
• OfflineBar：常時表示、警告色にしない、「点検は通常どおり行えます」（FR-306, OFF-04）
• SyncBadge：未同期件数の常時表示（FR-307, OFF-05）
• lib/offline/queue.ts：同期キュー
• オンライン復帰時の自動同期 + 手動同期（FR-308）
• 同期失敗時に記録を失わない。キューに残して再試行（FR-309, OFF-06）
• 点検中に強制リロードを起こさない。更新は次回起動時に適用（FR-310, OFF-07, IX-08）
• 通信状態で操作をブロックしないことを、コードレビューで確認（FR-302）
• IndexedDB 容量上限の警告（記録本体は消さず、同期済み写真の削除を促す）(NFR-17)
• Service Worker のキャッシュに点検記録を含めないこと（SEC-07）

Phase 2 完了チェック

• フローCが完走する（機内モードで点検を開始から完了まで → オンライン復帰で自動同期）
• 機内モードでアプリが起動する
• オフライン表示が警告色になっていない
• 同期を失敗させても記録が消えない

Phase 3 — 是正の追跡（3日）

• SC-100 是正タスク一覧（未対応／対応中／承認待ち／完了）(FR-403)
• 期限超過・放置日数超の強調表示と通知（FR-410, F-C06）
• SC-102 担当者の割当・期限設定・通知プレビュー（FR-405）
• SC-030 自分の是正タスク（現場担当）
• SC-031 是正の実施：対応内容・部品・対応前/対応後の写真（FR-406）
• 点検時の写真が「対応前」に自動表示されること（FR-407）
• BeforeAfterPhotos.tsx：左右に並べてラベルを明示
• SC-101 是正タスクの詳細：承認／差戻し（理由必須）（FR-408, FR-409）
• 連続処理（A 承認／R 差戻し／→ 次）（IX-09）
• 「対応不要」の理由必須（FR-404）
• SC-103 再発の検出一覧（FR-411）
• 次回点検時に前回の是正内容を表示（FR-412, フローB）
• SC-113 設備の点検・是正履歴（FR-413）
• SC-020 自分の点検履歴 / SC-021 点検記録の詳細
• RevisionHistory.tsx：修正ありのバッジと、元の値 → 修正後 + 理由 + 修正者（FR-503）

Phase 3 完了チェック

• フローBが完走する（NG → 是正タスク自動生成 → 割当 → 実施 → 承認 → 次回点検で表示）
• 4章「ロールを跨ぐ体験」の1・2・3・6が動作する
• 承認するまで「完了」にならない
• 再発が検出され、強調表示される

Phase 4 — テンプレート・帳票・スケジュール（4日）

4-1. テンプレート管理

• SC-210 点検表テンプレート管理：セクション + 項目、D&D並び替え + キーボード操作（FR-601, FR-604, A11Y-07）
• SC-211 項目の編集（判定種別・必須・写真ルール・N/A・前回値・数値範囲）(FR-602, FR-603)
• TapWarning.tsx：平均タップ数を常時表示。1.2超で警告 + 改善提案（FR-605, FR-606）
• 項目の追加・削除で推定所要時間が即座に更新されること（FR-607）
• SC-213 現場視点のプレビュー（FR-608）
• テンプレート変更後も、過去の記録が当時の構造で表示されること（FR-614）
• 項目名にふりがな（FR-118, A11Y-13）

4-2. 帳票

• SC-212 帳票レイアウト設定（セクション順・列構成・押印欄・備考欄・ヘッダー）(FR-609)
• 3種のレイアウトテンプレート（横型チェックリスト／縦型帳票／マトリクス型）(FR-610)
• lib/report/layout.ts：レイアウトの解決（純粋関数）
• lib/report/pdf.tsx：@react-pdf/renderer で生成（動的import）
• SC-230 帳票PDF出力。期間・設備でまとめて出力。実際にダウンロードできること（FR-611）
• 写真の添付ページ（FR-612）
• 帳票に「修正あり」を明示（FR-613, REC-03）
• LAW-01 の注記が帳票出力画面に常設されていること
• PDF生成が3秒以下、進捗表示（NFR-08）

4-3. スケジュールと設備

• SC-220 点検スケジュール（日次／週次／月次／四半期／年次、担当者、期限）(FR-701)
• SC-110 点検実施状況グリッド（設備×日付、記号で区別）（FR-703, A11Y-05）
• リマインド送信（プレビュー表示）(FR-704)
• 実施率の算出（FR-705）
• SC-221 設備マスタ（FR-708）／QRコード発行・印刷（FR-615）
• QRコード読取（カメラは任意、キー入力を既定）(FR-616)
• SC-111 点検記録の一覧・絞り込み・全文検索（FR-706, FR-707）
• SC-112 点検記録の修正：上書きせず修正履歴を作る。理由必須（FR-501, FR-502）
• 記録の無効化（理由必須。削除は実装しない）(FR-505)
• SC-251 操作ログ（FR-508）

Phase 4 完了チェック

• 4章「ロールを跨ぐ体験」の4と5が動作する
• 帳票PDFが実際にダウンロードでき、押印欄・備考欄が含まれている
• 平均タップ数1.2超の点検表で警告と改善提案が出る
• 記録を修正しても元の値が残り、帳票に「修正あり」が出る

Phase 5 — 分析・記事統合・仕上げ（3日）

5-1. 分析

• SC-200 ダッシュボード（実施率／未是正／期限超過／再発／平均所要時間）(FR-801)
• SC-240 NG発生率と、NGが多い項目のランキング（FR-802, FR-803）
• SC-241 是正リードタイム（担当者別・設備別）（FR-804）
• SC-103 再発一覧（FR-805）
• SC-242 所要時間分析：点検表別の平均秒数・タップ数、紙との比較（FR-806）
• 個人別ランキングを作らないこと（FR-809）
• 期間指定（FR-807）／CSVエクスポート（FR-808）
• SC-250 担当者・チーム管理

5-2. 記事統合

• 記事側の埋め込みコードを作成し、実際の記事ページで動作確認（EMB-01〜07）
• 埋め込みで5項目の点検が完了でき、秒数とタップ数が出ることを複数ブラウザで確認
• 記事の Core Web Vitals を埋め込み前後で比較検証
• 「全画面で試す」カードの設置
• 資料PDF（点検表ヒアリングシート・損益分岐計算シート）の作成とダウンロード導線
• 元記事リンク・問い合わせ導線
• GA4 イベント設定。seconds_per_item taps_per_item offline_used を必ず含める（EMB-08, EMB-09）
• GA4 に点検記録の内容・設備名を送っていないことを確認（EMB-10, SEC-03）
• ?embed=1 を noindex に、デモ本体の title / description / OGP（EMB-11）
• 記事内に LAW-02 の注記を明示

5-3. 体験の総点検

• 4章「ロールを跨ぐ体験」の7パターンをすべて手動で確認
• 全30画面を開き、空の画面が1つもないことを確認
• 設備名・項目名・判定基準にダミー文が1件も残っていないことを確認
• 実機（手袋をした状態）で判定ボタンが押せることを確認
• 薄暗い場所と直射日光下での視認性を実機で確認
• ガイドツアーを実装（FR-911）

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

• axe-core を全画面に実行し、Critical / Serious を0件に
• 判定ボタンのラベルのコントラスト比が7:1以上であることを実測（A11Y-01）
• 点検画面に15px未満の文字が存在しないことを確認（A11Y-02）
• タップ領域64px以上を全画面で確認（A11Y-03）
• 判定・実施状況が色のみで伝えられていないことを確認（A11Y-04, A11Y-05）
• キーボードのみで点検・承認・テンプレート管理を完遂（A11Y-06, A11Y-07）
• スクリーンリーダーで判定の記録が読み上げられることを確認（A11Y-09）
• フォントサイズ200%での確認（A11Y-14）

5-5. パフォーマンス

• 管理画面用ライブラリ（Recharts / TanStack Table / react-pdf / zxing）を動的import に分離
• 点検画面のバンドルが90KB以下、埋め込みが55KB以下を実測（NFR-05, NFR-06）
• 判定タップから次項目まで100ms以下を実測（NFR-01）
• オフライン起動が1.0秒以下を実測（NFR-02）
• 帳票PDF生成3秒以下、記録検索150ms以下を実測（NFR-08, NFR-09）
• 30項目×10回連続でメモリが単調増加しないことを計測（NFR-16）
• Lighthouse で Performance 95 / Accessibility 95（NFR-14）

5-6. 公開と記録

• Playwright で フローA・B・C の E2E（オフラインは Playwright の offline モードで）
• Vitest：lib/inspection lib/metrics lib/report/layout _scope のカバレッジ85%以上
• /dev/components を本番で非公開に
• Vercel へデプロイ（HTTPS必須）
• seconds_per_item taps_per_item の分布と offline_used の記録を開始（COST-01〜03）
• 解説動画（3分）の収録：30項目を通しで点検（テンポの速さ）→ NGで是正タスク生成 → 機内モードで点検完了 → 帳票PDF出力 → 平均タップ数の警告
• 各フェーズのキャプチャを整理し、記事の「方法」パートの素材にまとめる

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

工数配分の意図： Phase 1（点検の実施）に5日を割いているのは、このアプリの価値が「1項目1タップ・100ms以下」に集約されているから。判定ボタンのサイズ、自動遷移、即座のローカル保存、テンキー、NG詳細の展開——どれ1つ欠けても「紙の方が速い」に戻る。 Phase 4（テンプレート・帳票）に4日を割いているのは、帳票の再現が要件の大半を占める領域だから（11章）。3種のレイアウトテンプレートと設定による調整までを、この工数で作る。

13. 受入基準

1. 6章の優先度 P1 の要件がすべて実装され、テストで合格していること
2. 5章の主要フローA・B・Cが、エンドツーエンドで完走すること
3. 4章「ロールを跨ぐ体験」の7パターンがすべて動作すること
4. 2値・3値判定が1タップで完了し、セレクトボックスが1つも使われていないこと
5. 判定ボタンが画面高の40%以上を占めていること
6. 判定タップから次項目の表示までが100ms以下で、擬似ディレイが入っていないこと
7. 判定後に自動で次の項目に進むこと（設定でOFFにできること）
8. 完了時に所要時間・タップ数・1項目あたりの値・紙との比較が表示されること
9. テンプレート管理に平均タップ数が常時表示され、1.2超で警告と改善提案が出ること
10. 点検の開始から完了まで、通信を一切必要としないこと。通信状態で操作がブロックされないこと
11. オフラインでアプリが起動でき、機内モードで点検を完了できること
12. 点検完了がローカル保存の時点で成立し、「同期中」が完了条件になっていないこと
13. オフライン表示が警告色になっていないこと
14. 同期に失敗しても記録が失われないこと
15. 画面を消しても点検が失われず、中断地点から再開できること
16. NG判定から是正タスクが例外なく生成され、点検時の写真が「対応前」に引き継がれること
17. 是正が完了報告 → 承認の2段階であり、承認するまで完了にならないこと
18. 次回点検時に、その項目の前回の是正内容が表示されること
19. 再発（同一設備・同一項目の繰り返しNG）が検出され、強調表示されること
20. 確定した点検結果の値が上書きされておらず、修正が履歴として保持され、元の値が参照できること
21. 修正時に理由が必須であり、権限に関わらず履歴が残ること
22. 記録の削除が実装されておらず、無効化（理由必須）のみであること
23. 現場担当が確定記録を修正できず、他拠点の記録を取得できないこと
24. 帳票PDFが実際にダウンロードでき、押印欄・備考欄・「修正あり」の表示が含まれること
25. テンプレート変更後も、過去の記録が当時の構造で表示・出力されること
26. 点検画面のJSバンドルが90KB以下、埋め込みが55KB以下であること
27. 点検画面に15px未満の文字が存在せず、タップ領域が64px以上であること
28. 判定ボタンのラベルのコントラスト比が7:1以上であること
29. 判定・実施状況が色のみで伝えられていないこと
30. 所要時間・タップ数の個人別ランキングが、どの画面にも存在しないこと
31. LAW-01 の注記が、テンプレート管理画面と帳票出力画面に常設されていること
32. 設備名・項目名・判定基準にダミー文が1件も存在しないこと
33. 点検記録・写真・設備名が外部に一切送信されていないこと（DevTools と GA4 のイベントで確認）
34. 全30画面のいずれにも空の状態がなく、リアルなデータが表示されていること
35. 30項目×10回連続実施でメモリが単調増加しないこと
36. axe-core で Critical / Serious の指摘が0件であること
37. データアクセスがすべて lib/repo/ を経由していること
38. 姉妹プロジェクトと並べたときに、明確に別のプロダクトとして見えること。特に FIELDPIN と混同されないこと

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

1. 仕様がこの文書にない場合は、実装せずに質問する。 推測で作らない
2. 紙より速いことを常に確認する。 機能を足すとき、1項目あたりのタップ数が増えるなら実装しない。これがこのプロジェクトで最も重要なルール
3. セレクトボックスを点検画面で使わない。 選択肢は並べる
4. 判定ボタンを小さくしない。 画面の40%以上。手袋・片手・見ずに押せること
5. 通信状態で操作をブロックしない。 オフラインは正常な状態。警告色にしない
6. 点検完了をローカル保存で成立させる。 「同期中」を完了条件にしない
7. 確定した結果を上書きしない。 修正は履歴として追加する。権限で履歴の有無が変わらない
8. 記録を削除しない。 無効化（理由必須）のみ
9. NGから是正タスクを必ず生成する。 例外を作らない。記録するだけで放置される仕組みにしない
10. 是正は承認まで完了にしない。 完了報告と承認を分ける
11. 点検画面に重いライブラリを持ち込まない。 管理画面用は必ず動的import
12. 所要時間・タップ数で人を評価させない。 個人別ランキングを作らない
13. 法令適合を断定しない。 LAW-01 の注記を削らない
14. 設備名・項目名・判定基準にダミー文を残さない。 点検表のデモは項目名のリアリティが説得力になる
15. スコープ外（3章 Won't have）は実装しない。特に帳票の自由レイアウトエディタ・IoT連携・AI判定は範囲外
16. 「デモだから」を理由に品質を落とす判断はしない
17. FIELDPIN のトークン・コンポーネントをコピーしない。 TENKEN は濃い地・1画面1項目・巨大ボタン