画面設計書の書き方｜項目一覧・テンプレート・記入例まとめ

画面設計書とは、システムの画面ごとに「何を表示し、何を入力でき、操作すると何が起きるか」を決めて書き残す文書です。 画面定義書とも呼ばれ、作る人・テストする人・確認する人が同じ画面を思い浮かべられるようにするのが目的です。

画面設計書は1枚の資料ではなく、画面一覧・画面遷移図・画面レイアウト・項目定義・イベント定義・メッセージ一覧・権限の7つの書類の組み合わせとして考えると、書く順番も抜けも整理できます。この記事では、それぞれの目的を表にまとめたうえで、コピペで使えるMarkdownテンプレートと、架空の会員管理機能（会員一覧・会員登録・会員詳細）の記入例を載せます。画面遷移図は mermaid-cli 12.0.0 で実際に描画を確認したMermaidコードです。最後に、エラー時・0件のとき・権限がないときの表示漏れを見つけるレビュー用チェックリストもまとめました。

画面設計書を構成する7つの書類の早見表

書く順番は「画面一覧 → 画面遷移図 → 画面レイアウト → 項目定義 → イベント定義 → メッセージ一覧 → 権限」がおすすめです。先に全体（一覧と遷移）を固めると、あとの細かい定義で「この画面はどこから来るのか」に迷わなくなります。

画面一覧の書き方（テンプレートと記入例）

画面一覧は、画面設計書全体の目次です。画面IDを振っておくと、遷移図・項目定義・メッセージ・テスト仕様書から同じIDで参照できます。

コピペ用テンプレートです。

| 画面ID | 画面名 | 概要 | 利用者（ロール） | URL | 種別 | 備考 |
|---|---|---|---|---|---|---|
| SCR-xxx | | | | | 一覧/登録/詳細/確認/ダイアログ | |

記入例（会員管理機能）です。

画面IDは「SCR-010」のように番号を10刻みにしておくと、あとで画面が増えても間に挿入できます。 ダイアログ（確認ダイアログなど）も画面として数えるか、イベント定義に書くかを最初に決めておくと、一覧の粒度がそろいます。

画面遷移図をMermaidで書く

画面遷移図は、画面どうしのつながりと「どの操作で、どんな条件のときに移動するか」を示す図です。Mermaid（テキストで図を書く記法）で書くと、Gitで差分を確認でき、Markdownの中にそのまま置けます。

flowchart LR
    MENU["SCR-000 メニュー"] -->|会員管理| LIST["SCR-010 会員一覧"]
    LIST -->|新規登録ボタン| REG["SCR-020 会員登録"]
    LIST -->|行のリンク| DTL["SCR-030 会員詳細"]
    REG -->|確認ボタン 入力チェックOK| CONF["SCR-021 登録確認"]
    REG -->|入力チェックNG| REG
    CONF -->|戻るボタン 入力値を保持| REG
    CONF -->|登録ボタン 成功| DTL
    CONF -->|登録ボタン メール重複| REG
    DTL -->|一覧へ戻る 検索条件を保持| LIST
    DTL -->|削除ボタン 確認ダイアログOK| LIST

矢印のラベルに「ボタン名＋条件」を書くのがポイントです。「登録ボタン 成功」と「登録ボタン メール重複」のように、同じボタンでも結果で行き先が変わる分岐を図に残せます。「戻る」で入力値や検索条件を保持するかどうかも、遷移図に書いておくと実装とテストで解釈がそろいます。

mermaid-cliで描画を確認する

GitHubやエディタのプレビューで表示が崩れないか、コマンドで事前に確認できます（Node.js 22.22、@mermaid-js/mermaid-cli 12.0.0 で確認）。

npm i -D @mermaid-js/mermaid-cli
# flow.mmd に上のコードを保存して実行
npx mmdc -i flow.mmd -o flow.svg

Generating single mermaid chart

出力された flow.svg には、5つの画面（SCR-000、SCR-010、SCR-020、SCR-021、SCR-030）のノードがすべて描画されていました。

ラベルに括弧を入れたときのエラーと直し方

画面名に括弧を入れると、そのままでは構文エラーになります。

flowchart LR
    LIST[SCR-010 会員一覧] -->|新規登録| REG[SCR-020 会員登録(入力)]

Error: Parse error on line 2:
...登録| REG[SCR-020 会員登録(入力)]
-----------------------^
Expecting 'SQE', 'DOUBLECIRCLEEND', 'PE', '-)', 'STADIUMEND', 'SUBROUTINEEND', 'PIPE', 'CYLINDEREND', 'DIAMOND_STOP', 'TAGEND', 'TRAPEND', 'INVTRAPEND', 'UNICODE_TEXT', 'TEXT', 'TAGSTART', got 'PS'

Mermaidでは ( が「角の丸い四角」の記号として読まれるためです。ラベルを " で囲むと描画できます。

flowchart LR
    LIST["SCR-010 会員一覧"] -->|新規登録| REG["SCR-020 会員登録(入力)"]

画面名は最初から " で囲んでおくと、括弧や記号を含む名前でも安心です。 Mermaidの図の種類ごとの書き方は「Mermaid記法一覧｜全図種のコピペ用コードと描画結果まとめ」の記事にまとめています。

画面レイアウトの書き方

画面レイアウトは、画面をいくつかの領域に分け、どこに何を置くかを示すものです。細かい見た目はFigmaなどのデザインツールに任せ、設計書には「領域」と「部品の並び」を書くと、変更に強くなります。テキストで書く場合の例です。

SCR-010 会員一覧
+--------------------------------------------------------------+
| [A] ヘッダー：サービス名 / ログインユーザー名 / ログアウト     |
+--------------------------------------------------------------+
| [B] 検索条件：氏名 [________]  会員種別 [すべて v]  [検索]     |
+--------------------------------------------------------------+
| [C] 操作：                                    [新規登録]       |
+--------------------------------------------------------------+
| [D] 一覧：会員番号 | 氏名 | メールアドレス | 会員種別 | 登録日  |
|      M000123     | 山田 太郎 | taro@example.com | 一般 | 2026/10/01 |
+--------------------------------------------------------------+
| [E] ページ送り：< 前へ  1 / 5  次へ >   全98件                |
+--------------------------------------------------------------+

共通ヘッダーやページ送りのように複数の画面で使う部品は「共通部品」として1回だけ定義し、各画面からは参照すると、修正が1か所で済みます。

項目定義の書き方（テンプレートと記入例）

項目定義は、画面にある1つ1つの項目の仕様を表にしたもので、画面設計書の中でいちばん実装とテストに直結する部分です。列の意味は次のとおりです。

コピペ用テンプレートです。

### SCR-xxx 画面名 項目定義

| No | 項目名 | I/O | 型 | 桁 | 必須 | 初期値 | 入力チェック | 表示条件 | 備考 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | | | | | | | | | |

記入例1：SCR-020 会員登録

記入例2：SCR-010 会員一覧

記入例3：SCR-030 会員詳細

「表示条件」の列を空けずに埋めることが、表示漏れを防ぐいちばんの近道です。一覧画面なら「1件以上のとき」「0件のとき」、ボタンなら「どのロールに表示するか」を必ず書きます。また、「桁」は全角・半角をどう数えるかまで決めておくと、実装とDBの桁数がずれにくくなります。

イベント（アクション）定義の書き方

イベント定義は、ボタンを押す・画面を開くといった操作のきっかけごとに、処理と結果を書く表です。画面を開いたとき（初期表示）もイベントとして書くのがポイントです。

| イベントID | きっかけ | 処理内容 | 成功時 | 失敗時 |
|---|---|---|---|---|
| EVT-xxx-01 | | | | |

記入例（会員登録と会員詳細）です。

「処理中はボタンを押せなくする」のような二重送信への備えも、イベント定義に1行書いておくと実装で漏れにくくなります。

メッセージ一覧の書き方

メッセージ一覧は、画面に出す文言をIDで管理する表です。同じ意味の文言が画面ごとに少しずつ違う、という状態を防げます。

{0} のような差し込み部分を使うと、似た文言を1つにまとめられます。 エラーの文言は「何が起きたか」と「どうすればよいか」をセットにすると、利用者が次の操作に進みやすくなります。

権限（ロール別の表示と操作）の書き方

権限の表は、ロールを列、画面と操作を行にした表にすると、表示条件と照らし合わせやすくなります。

「ボタンを隠す」だけでなく、URLを直接開いたときの動きまで書くのがポイントです。画面で隠しても、サーバー側でも同じ権限を確認する前提で設計しておくと安心です。

状態別の表示を決める（空・エラー・権限なし・読み込み中）

画面は「データがそろっている状態」だけを設計しがちです。状態ごとの表示を1つの表にしておくと、表示漏れを見つけやすくなります。 会員一覧の例です。

何で書くか：Figma・Excel・Markdown・HTMLモックの選び方

画面設計書を書く道具に正解は1つではありません。「見た目を決めたいのか」「仕様を正確に残したいのか」で使い分けると選びやすくなります。

よく使われる組み合わせは「見た目はFigma（またはHTMLモック）、仕様はMarkdownかExcelの表」です。レイアウト図の画像に仕様を書き込むより、仕様を表に分けておくほうが、変更の差分を追いやすくなります。

基本設計書・詳細設計書との関係

画面設計書は、多くの場合基本設計書の一部として書かれます。画面一覧・画面遷移図・画面レイアウト・項目定義・メッセージは利用者にも見える約束なので基本設計で決め、内部の処理（どのテーブルをどう更新するか、どのAPIを呼ぶか）は詳細設計書に書く、という分け方が一般的です。

全体の書き分けは「基本設計書の書き方｜項目・記入例とレビューの観点」「詳細設計書の書き方｜基本設計との違いと記入例」の記事で解説しています。画面設計書の「備考」列に、対応するAPIやテーブルの項目名を書いておくと、ほかの設計書とのつながりを追いやすくなります。

画面設計書のレビュー用チェックリスト

よくある質問

Q. 画面設計書と画面定義書は違うものですか？ A. 組織によって呼び方が違うだけで、ほぼ同じものを指すことが多いです。画面レイアウトや遷移を含む全体を「画面設計書」、項目の仕様の表を「画面定義書（項目定義書）」と呼び分ける場合もあるので、最初に用語をそろえておくと混乱しません。

Q. 画面レイアウトはどこまで細かく書けばよいですか？ A. 設計書には「領域」と「部品の並び」までを書き、色・余白などの見た目はFigmaなどのデザインやスタイルガイドに任せるのがおすすめです。見た目の細部を設計書に書くと、デザインを直すたびに設計書も直す必要が出てきます。

Q. アジャイル開発でも画面設計書は必要ですか？ A. すべてを最初に書き切る必要はありませんが、項目定義・メッセージ・権限のように実装とテストで参照する情報は、短い表でも残しておくと役立ちます。作る画面の分だけ、この記事のテンプレートを埋めていく使い方ができます。

まとめ

• 画面設計書は、画面一覧・遷移図・レイアウト・項目定義・イベント定義・メッセージ一覧・権限の7つで考える
• 書く順番は全体（一覧・遷移）から細部（項目・イベント・メッセージ）へ
• 遷移図はMermaidで「ボタン名＋条件」をラベルに。画面名は " で囲むと括弧があっても描画できる
• 項目定義はI/O・型・桁・必須・初期値・入力チェック・表示条件を空欄なく埋める
• 0件・エラー・権限なし・読み込み中の表示を状態別の表にすると、表示漏れが見つかる
• 道具は見た目はFigmaやHTMLモック、仕様はMarkdownやExcelの表と役割で分ける
• レビューはチェックリストで、遷移の出入りと表示条件を中心に確認する

株式会社RJCでは、画面設計書の書き方を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。