画面設計書フォーマットガイド（共通）

目的

• 画面設計書（ADM-* / PUB-* など）の記載粒度をそろえ、実装時の認識ズレを減らす。
• 画面の種別（管理画面 / 公開画面）に依存しない、再利用可能な共通フォーマットを定義する。

必須セクション

以下の順で記載する。

1. # 画面ID 画面名（例: ADM-10 ...、PUB-1 ...）
2. ## 概要
3. ## ワイヤーフレーム（必須）
4. ## 画面仕様
5. ## 処理連携仕様
6. ## 外部インターフェース

ワイヤーフレーム記載ルール

• すべての画面設計書で、ワイヤーフレームセクションを必須とする。
• 可能な限り React Host コンポーネント（例: <Adm10WireframeReactHost />）または画像参照を置き、画面構成を視覚的に確認できる状態にする。
• ワイヤーフレーム未作成時は「未作成」と明示し、別途作成タスクを同時に管理する。

画面仕様の書き方

• 画面表示要素はブロック一覧（ID、表示内容、初期値、ユーザー操作、アクション）で定義する。
• 表示ロジック、入力制約、UI イベント（ボタン押下、チェック ON/OFF など）を記載する。
• 画面内の表示と操作を中心に記載し、処理連携の契約詳細は「処理連携仕様」に記載する。

ブロックID（B-*）の命名

• ブロック一覧の ブロックID は B-1, B-2, … とする（Block。ハイフン＋連番。必要に応じ B-0 から開始してよい）。
• アクションID（後述の A-1, A-2, …）とは別系統とする。ブロックに単一英字（A, B, …）だけを振らず、アクションと記号が衝突しないようにする。
• 本文でブロックを指すときも同じ表記（例: `B-2`）を用いる。

処理連携仕様の書き方

• 画面操作または初期表示で呼び出す処理だけを対象に、アクションID（A-1, A-2 ...）ごとに定義する。
• アクションID は表の列ではなく、見出し（#### A-1）として記載する。
• トリガーは列で管理せず、アクション概要文に含める。
• リクエストとレスポンスは表を分離して記載する（同一表に混在させない）。
• 処理連携の契約を記載し、実装詳細そのものは別設計（REQ/API/EP）へ委譲する。

記載範囲ルール

• 画面設計書はフロントエンド観点の設計書として扱い、UI 表示・入力・イベント発火を主体に記載する。
• サーバー連携は「どの処理を呼ぶか」「何を渡すか」「何が返るか」の契約情報に限定して記載する。
• 同じ内容を重複記載しない。処理名（REQ/API/EP/SC）で相互参照する。

テンプレート（ひな形）

# 画面ID 画面名

## 概要

- [画面の目的]

## ワイヤーフレーム

[ワイヤーフレーム参照]

## 画面仕様

### ブロック一覧

| ブロックID | ブロック名 | 表示内容 | 初期値 | ユーザー操作 | アクション |
| ---------- | ---------- | -------- | ------ | ------------ | ---------- |
| `B-1`      |            |          |        |              | -          |

## 処理連携仕様

### アクション一覧

#### A-1

[処理概要（どの操作でどの処理を呼ぶか）]

**リクエスト**

| requestParam | 本画面の値（どの部品から何を送るか） |
| ------------ | ------------------------------------ |
|              |                                      |

**レスポンス**

| 項目             | 内容 |
| ---------------- | ---- |
| 成功時           |      |
| 失敗時           |      |
| 画面更新時の処理 |      |

## 外部インターフェース

### 画面 URL

| 項目 | 値                  |
| ---- | ------------------- |
| URL  |                     |
| 種別 | 管理画面 / 公開画面 |
| 権限 | （必要な場合のみ）  |