<!-- G-0: ビジネスモデルキャンバス + 料金プラン ワークシート（空白フォーム）— Ch.2 対応 -->
# [サービス名] ビジネスモデルキャンバス（6マス）
① 問題   — 誰が、どんな状況で、何に困っているか？
② 既存の代替手段 — 今その人たちは何を使っているか？ どこで機能しなくなるか？
③ 解決策 — 自分のサービスが提供する核心的な動作、一文で
④ 差別化ポイント — 既存の代替手段が構造的にできないこと
⑤ 収益モデル — 単発／サブスクリプション／その他 + 有料転換の核心トリガー
⑥ コスト構造 — ユーザー1人あたり毎月かかるコスト（Ch.3.4で試算）

# 料金プラン設計ワークシート
1. コアバリューを体験するために最低限必要なものは？ → Freeに入れるもの
2. ユーザーが「もっと欲しい」と感じる最初の瞬間は？ → Free/Pro の分岐点
3. Proユーザー1人あたりの月間コストは？ → 価格の下限
4. 既存の代替サービスの価格帯は？ → 価格の重力圏
5. ヘビーユーザーをどう受け入れるか？ → 上位ティアまたはBYOK


<!-- G-1: アーキテクチャリファレンス（空白フォーム） -->
# [サービス名] アーキテクチャリファレンス
最終更新: YYYY-MM-DD | このドキュメントがすべての技術的判断の基準点です。

## 1. サービスの一文説明
[誰が] [何をすると] [何を得る]

## 2. 構成要素マップ（レストランのたとえで描く）
- ホール（フロントエンド）: [技術名] — デプロイ先: [プラットフォーム]
- キッチン（バックエンド）: [技術名] — デプロイ先: [プラットフォーム]
- シェフ（AI）: [モデル系統] — 呼び出し元: [どこから]
- 冷蔵庫（DB）: [技術名]
- 入口（認証）: [サービス名]
- 洗い場（ワーカー）: [あり/なし — ありの場合は技術名]
- 決済: [サービス名]

## 3. データフロー（核心シナリオ1つ）
ユーザーが [操作] → [ホール] → [キッチン] → [シェフ/冷蔵庫] → ユーザーに [結果]

## 4. モジュール間の取り決め（インターフェース）
| 送り側 | 受け側 | やり取りするもの（形式） |
|---|---|---|
| (送り側) | (受け側) | (やり取りするもの) |

## 5. 構造的決定の記録（変更のたびに追加）
| 日付 | 決定内容 | 理由 |
|---|---|---|
| (日付) | (決定内容) | (理由) |


<!-- G-2: 進捗管理チェックリスト（空白フォーム） -->
# [サービス名] 進捗管理
現在のStage: [1/2/3] | 最終セッション: YYYY-MM-DD

## 今のStage タスク一覧
- [ ] タスク名 — 完了基準を一行で
- [ ] ...

## 本日のセッション（毎回更新 — 開始2分、終了2分）
- 前回セッションでやったこと:
- 今日やること（ひとつだけ）:
- 詰まっていること / 次のセッションに持ち越すこと:

## Freezeリスト（変更禁止 — Ch.6.3）
- [ファイル/モジュール] （Stage N 通過、YYYY-MM-DD）


<!-- G-3: ビルド指示書（空白フォーム） -->
# ビルド指示書: [作業名]
日付: YYYY-MM-DD

## 目標（一文で）

## 文脈（最初に読むこと）
- アーキテクチャリファレンス [パス/添付]
- 関連スペック: [モジュール名]
- 最新の決定事項ファイルを必ず確認すること（Ch.5.5）

## やること
1.
2.

## やらないこと（禁止事項 — 必ず記載）
- [Freezeリスト]にあるファイルは絶対に変更しないこと。変更が必要だと
  判断した場合は変更せず、私に報告すること。
- 今のステップの範囲外の機能（例: 認証、決済）は先回りして作らないこと。

## 完了基準（PASS/FAILで答えられる形式で）
- [ ]


<!-- G-3.5: スペックドキュメント（空白フォーム）— V2を崩壊させたあのドキュメント -->
# スペック: [モジュール名]
最終更新: YYYY-MM-DD | このモジュールとデータをやり取りするすべての作業は、このドキュメントが基準です。

## 一文での役割
このモジュールは [何] を受け取り、[何] をして、[何] を出力する。

## 入力
| 項目 | 形式 | 例 | なければ？ |
|---|---|---|---|
| (項目) | (形式) | (例) | (拒否 / デフォルト値使用 / 空値許容) |

## 処理（概念レベル — 非エンジニアの言葉で）
1.
2.

## 出力
| 項目 | 形式 | 例 |
|---|---|---|
| (項目) | (形式) | (例) |

## 失敗時の動作（無音の失敗禁止 — Ch.12）
- 失敗したら: [エラーを返す / N回リトライ / 通知]
- 失敗を私はどうやって知るか: [ログ / 通知チャネル]

## このモジュールと取り決めている相手
- [モジュール名] — やり取りするもの:


<!-- G-4: Stageゲート検証（空白フォーム） -->
# ゲート検証: Stage [N] → [N+1]
検証日: YYYY-MM-DD | ルール: 全項目PASSで通過。「だいたいPASS」はFAILです。

## ゲート1（Core → SaaS）基本項目
- [ ] 核心処理、入力を変えて5回連続成功
- [ ] 成果物の品質: 自分ならお金を払うか
- [ ] 処理1件あたりのコストを数字で把握している（→ 付録 D③に入力）
- [ ] モジュール間の入出力がドキュメントと実装で一致している
- [ ] 次のStageのFreezeリスト作成完了

## ゲート2（SaaS → Monetization）基本項目
- [ ] 他の人が案内なしで登録〜コア機能の完走ができた
- [ ] ユーザー間のデータ分離確認（AのデータがBに見えない）
- [ ] デプロイ環境で全体フローが動作している
- [ ] エラー時にユーザーに見える画面を確認した
- [ ] API Freeze宣言完了

## プロジェクト固有の項目（自分で追加）
- [ ]

## 判定: PASS / FAIL → FAILの項目と対処:


<!-- G-5: クロスレビューチェックリスト（PASS/FAIL形式 — Ch.5.6） -->
# クロスレビュー: [対象機能/画面/設計]
検証日: YYYY-MM-DD

## 役割1 — バックエンドエンジニアの視点
問い: この構造は安定しているか？ ユーザーが増えたらどこから先に崩れるか？
- 指摘事項:
- 対処: [反映 / 保留+理由]

## 役割2 — UI/UXデザイナーの視点
問い: 初めて来たユーザーが迷うポイントはどこか？
- 指摘事項:
- 対処:

## 役割3 — セキュリティレビュアーの視点（Ch.14）
問い: すべてを疑い、すべてを確認する。とくに権限・入力・デフォルト値。
- 指摘事項:
- 対処:

## 役割4 — コスト管理者の視点
問い: API呼び出しが過剰な箇所、コストが漏れている構造はないか？
- 指摘事項:
- 対処:

## 機能検証（失敗パスを中心に — AIに生成させて追加）
- [ ] 正常パス: ___ (PASS/FAIL)
- [ ] 失敗パス: ___ (PASS/FAIL)
- [ ] 失敗パス: ___ (PASS/FAIL)

## 総合判定 + 次回確認日（3:1ルール — Ch.16）:


<!-- G-5: クロスレビューチェックリスト（PASS/FAIL形式 — Ch.5.6） -->
# 障害ポストモーテム: [一行タイトル]
発生: YYYY-MM-DD HH:MM 〜 HH:MM（合計 N分/時間）

- 何が起きたか（ユーザー視点）:
- なぜ起きたか（根本原因）:
- どうやって気づいたか: [アラート / 自分で発見 / ユーザー報告] ← ユーザー報告だったらモニタリングの穴
- どうやって復旧したか: [ロールバック / 再起動 / 設定修正]
- 再発防止（以下のうち一つ以上）: [アラート追加 / チェックリスト追加 / 自動化追加]
- 開発ルールドキュメントに追加する一行（Ch.14の教訓）: