2026.11.15 Webシステム

画面設計書の書き方：記載項目と記入例、発注者がレビューで見る観点

画面設計書は、システムの各画面に何を表示し、利用者が何を入力でき、ボタンを押すと何が起きるかを、発注者と開発会社のあいだで文書として確定させるための設計書です。この記事では、IPA（情報処理推進機構）のガイドが定める6つの成果物に沿って、画面設計書に書く項目と会員登録画面の記入例を示します。入力チェックとエラーメッセージの書き方、発注者がレビューで承認を止めるべき欠落、画面設計書を省いてよい場面まで、外部設計を発注する側の目線で整理しました。

まとめ：画面設計書は6つの成果物で書き、発注者は遷移から順に確認する

画面設計書は1枚の図ではありません。画面一覧、画面遷移、画面レイアウト、画面入出力項目一覧、画面アクション明細、画面遷移・レイアウト共通ルールの6つを組み合わせて、画面の見た目・入力・振る舞いを決めます。

書く順序は、共通ルールを先に決めてから一覧と遷移、最後に1画面ずつのレイアウトと項目です。共通ルールでエラー表示や部品の使い方を決めておけば、個々の画面では差分だけを書けば足ります。

発注者のレビューは、業務の流れに沿った画面遷移から入り、桁数や配色は後に回します。承認前に必ず確かめるのは、異常系の遷移、権限ごとの表示、既存データが収まる桁数、エラー時の文言、未決事項の期限の5つです。

画面設計書とは：基本設計で作る画面の文書と仕様書・ワイヤーフレームとの違い

画面設計書の位置づけ：外部設計で発注者と開発者が合意する画面の外部仕様

画面設計書は、外部設計（会社によっては基本設計と呼ぶ工程）で作る成果物です。利用者から見える画面の外側の仕様を決める文書で、プログラムの内部構造やテーブル設計は含みません。

IPAの機能要件の合意形成ガイド分冊3 画面編（2010年3月31日）は、外部設計工程の終了までに発注者と開発者が機能要件を齟齬なく合意するための資料です。画面編はWebアプリケーションの画面を想定しつつ、レイアウトだけでなく「利用者がどう操作でき、操作で何が起こるか」まで明確にする対象に含めています。外部設計の成果物全体と画面設計書の関係は外部設計とは？内部設計との違いと成果物、発注者が承認すべき観点、工程名の揺れは基本設計とは？どこまで決めるか・成果物一覧と要件定義・詳細設計との違いで扱っています。

ワイヤーフレーム・画面遷移図・仕様書との違いと作る順序の前後関係

似た言葉が多いので、何を決める文書かで区別してください。

文書	決めること	主な工程
ワイヤーフレーム	情報の配置と優先順位	要件定義〜外部設計の初期
画面遷移図	画面のつながりと遷移の条件	要件定義〜外部設計
画面設計書	表示・入力・振る舞いの外部仕様	外部設計
仕様書	システム全体で何を作るかの合意	要件定義〜外部設計

線画で配置を固めるワイヤーフレームの作り方とデザインカンプとの違いが先にあり、画面設計書はそれを項目と動作の単位まで詰めた文書です。画面遷移図は画面設計書を構成する一部で、要件定義段階で作る図の種類は要件定義と設計で作る図の一覧にまとめています。仕様書という総称との関係は仕様書とは？設計書・要件定義書との違いを参照してください。

画面設計書の記載項目：IPA画面編が定める6つの成果物とそれぞれに書く内容

画面一覧と画面遷移：1行1画面の一覧と1業務1ページで描く遷移図

画面一覧は、システムにある画面をすべて並べた表です。画面ID、画面名、分類（メニュー・入力フォーム・検索結果一覧など）、機能ID、概要を1行に1画面で記載する形式です。IPAのガイドは「一行＝一画面」で書くこと、1から昇順の番号を振って画面の総数をすぐ数えられるようにすることを勧めています。この一覧で、開発範囲と画面数を発注者と開発者が合意します。

画面遷移は、画面と画面を矢印でつなぎ、遷移のきっかけになる操作（検索ボタン、戻るなど）と分岐の条件を書いた図です。ガイドの書き方のコツは、印刷1ページに受注や発注のような完結した業務を1つ描く、上から下・左から右へ流す、正常系と異常系を書き分ける、の3つです。条件は「在庫なしの場合」のように業務の言葉で書き、プログラムの用語を使いません。

画面レイアウト：部品の配置と識別IDで項目一覧・アクション明細とつなぐ

画面レイアウトは、1画面ごとの見た目を図で示すものです。ボタン、テキストボックス、ラベル、表などの部品を配置し、各部品に識別IDを振ります。この識別IDが、後述の画面入出力項目一覧と画面アクション明細の行を指す番号になります。

レイアウトが図だけで終わると、仕様の抜けが残りがちです。ガイドの確認のコツ（03C301）は、部品の配置とボタン押下時の簡単な動作だけで止めず、入力情報や制約条件まで書き込むよう求めています。既存システムの改修では、新規・変更・既存の画面を色分けすると、どこをレビューすればよいかが一目で分かります。

画面入出力項目一覧：桁数・データ型・必須・入力制約を決める15の列

画面入出力項目一覧は、レイアウト上の入出力項目を1行ずつ表にしたもので、画面設計書の中で最も量が多くなる部分です。ガイドの構成要素2.1〜2.15は次の15列です。

列	書く内容
識別ID・表示用のラベル・部品の種類	図との対応、画面上の名称、テキストボックスなど
有効・入力	○常に可／△条件つき／×不可の記号
表示桁数・入力桁数	見える幅と入力できる最大桁数
データ型・文字種	文字列か数値か、全角か半角か
入力制約	値の範囲や入力できる文字の制約
初期表示有無・初期表示内容	画面を開いた時点の値
出力仕様	計算方法・丸め・表示形式・文字揃え
必須・補足	○常に必須／△条件つき必須、その他の説明

入力制約に書くのは、単一項目の外部仕様までです。「開始日は終了日より前」のような項目をまたぐチェックは画面アクション明細に回し、テーブルとの対応は内部設計に回します。この線を引かないと、同じ制約が2か所に書かれて食い違います。

画面アクション明細と共通ルール：ボタン押下時の処理とエラー表示の定義

画面アクション明細は、ボタンを押したときにシステムが何をするかを文章で書いたものです。「①入力チェック ②顧客情報を検索 ③-1 該当なしなら登録して完了画面へ ③-2 該当ありならエラーメッセージを表示」のように、処理の概要と詳細を分け、条件分岐を階層で整理します。画面遷移図のイベント名と明細のイベント名を一致させておくと、遷移図にある操作の処理が明細に無い、という漏れを突き合わせで見つけられます。

画面遷移・レイアウト共通ルールは、全画面に共通する約束事です。ヘッダー・メニュー・フッターの配置、ボタンの形状、使える色とフォント、エラーメッセージの表示位置と文言の型、権限による遷移先の切り替えをここで決めます。制約は「文字を大きめに」ではなく「本文16px以上」のように、できる限り数値で書いてください。

画面設計書の書き方：会員登録画面を例にした作成手順と項目定義の記入例

作成手順：共通ルールを先に決め、一覧・遷移・レイアウト・項目の順に書く

書く順序を誤ると、レイアウトを描き直す手戻りが増えます。次の順で進めます。

画面遷移・レイアウト共通ルールを決める（画面の分類、ページの構成要素、エラー表示の型）
要件定義の機能一覧から画面一覧を作り、画面IDを振る
業務ごとに画面遷移を描き、正常系と異常系の流れを決める
1画面ずつ画面レイアウトを描き、部品に識別IDを振る
画面入出力項目一覧と画面アクション明細を書く
レイアウトと項目一覧に同じ記入例を入れ、突き合わせて確認する

手順1の共通ルールを後回しにすると、画面ごとにエラー表示の位置やボタンの並びがばらつき、レビューで同じ指摘が画面の数だけ出ます。手順6の「同じ記入例」は、ガイドのコツ03D703にある方法で、レイアウト上の見本値と項目一覧の桁数が合っているかを目で確かめられます。

画面入出力項目一覧の記入例：会員登録画面の氏名・メール・電話番号の行

会員登録画面の一部を、15列のうち主要な列で書いた例です。

ID	ラベル	部品	入力桁数	文字種	入力制約	必須
1	氏名（姓）	テキストボックス	20	全角	なし	○
2	氏名（名）	テキストボックス	20	全角	なし	○
3	メールアドレス	テキストボックス	254	半角	メール形式	○
4	電話番号	テキストボックス	13	半角	数字とハイフンのみ	△
5	登録	ボタン	－	－	－	－

電話番号の必須が△なのは、「連絡方法で電話を選んだ場合だけ必須」という条件つきの例です。△を付けたら、補足列に条件を必ず書きます。メール形式や数字とハイフンのみといった入力パターンは、共通ルールに一度定義して名前で参照すると、全画面の表記がそろいます。

入力チェックとエラーメッセージ：WCAG 2.2の達成基準を仕様の文に落とす

エラー時の振る舞いは、画面設計書で最も書き漏れやすい部分です。Webアクセシビリティの国際基準であるWCAG 2.2（W3C勧告・2024年12月12日版）の入力に関する達成基準は、そのまま画面設計書の仕様の文に置き換えられます。

3.3.1 エラーの特定（レベルA）：誤りのある項目を特定し、誤りの内容をテキストで示す → 「エラーは該当項目の直下に文言で表示し、色だけで示さない」
3.3.2 ラベル又は説明（レベルA）：入力が必要な項目にラベルか説明を付ける → 「入力例と桁数を項目の近くに表示する」
3.3.3 エラー修正の提案（レベルAA）：修正方法が分かる場合は提示する → 「メール形式誤りは『@が含まれていません』のように原因を示す」
3.3.7 冗長な入力（レベルA）：同じ手続きで入力済みの情報を再入力させない → 「確認画面から戻ったとき入力値を保持する」
2.5.8 ターゲットのサイズ（レベルAA）：押せる部品は原則24×24 CSSピクセル以上 → 共通ルールのボタン寸法に書く

官公庁や大手企業向けのシステムでは、発注仕様にアクセシビリティ対応が入ることがあります。その場合でも、達成基準の番号を書くだけでは開発側の解釈が割れます。上の矢印の右側のように、画面上で何が起きるかの文に直して共通ルールに載せてください。

画面設計書の作成ツール：ExcelとFigmaの使い分けと正本の決め方

Excelの項目定義とFigmaのデザインを併用するときに正本を1つに決める理由

画面入出力項目一覧のような表はExcelやスプレッドシートが書きやすく、レイアウトはFigmaのようなデザインツールの方が描きやすいため、両方を併用する現場は珍しくありません。問題は、桁数やラベルが両方に書かれ、片方だけ更新されることです。

併用するなら、項目ごとに正本を決めるのが前提です。見た目（配置・色・寸法）はFigma、項目の桁数・必須・入力制約はExcel、と分けて、もう一方には値を書かずに参照だけを置きます。版管理は、表紙に版数と改訂日、変更履歴の表を設け、承認済みの版をPDFで固定して共有フォルダに残すと、どの版で合意したかが後から追えます。

発注者が画面設計書のレビューで見る観点と、承認を止めるべき5つの欠落

レビューの順序：業務の流れと画面遷移を先に見て、桁数や配色は後に回す

ベンダーから画面設計書一式を受け取ると、1画面目のレイアウトから読み始めがちです。IPAのガイドは逆の順序を勧めています。業務の流れと画面遷移のレビューを先に行い（03R302）、全体を確認してから各画面の桁数や入力規則に進みます（03R104）。

理由は手戻りの大きさです。遷移の誤りは複数の画面に波及しますが、桁数の誤りはその項目だけで直ります。レビュー会では、発注者が実際に触れる試作画面を用意してもらうと（03R202）、紙の図では気づかない操作の順序の違和感を早く拾えます。

承認を止める5つの欠落：異常系の遷移・権限別の表示・既存データの桁数

次の5つのどれかが欠けていたら、承認を保留して追記を求めてください。重い順に並べています。

異常系の遷移：エラー、該当なし、タイムアウト、二重送信のときにどの画面へ進むかが遷移図にない
権限別の表示：管理者と一般利用者で見える項目やボタンが変わるのに、レイアウトが1パターンしかない（03R402・03R408）
既存データの桁数：移行する既存データの最長値が入力桁数・表示桁数に収まるか確かめていない（03R405）
エラー時の文言：エラーメッセージが「入力エラー」だけで、項目と原因が書かれていない（03R205）
未決事項の期限：検討中の箇所に、決める人と期限が書かれていない（03R105）

1と2は、テスト工程に入ってから見つかると画面の作り直しになります。3は、旧システムの顧客名が想定より長く画面で切れる、という形で本番稼働の直前に表面化します。桁数の妥当性は発注者側でしか確かめられないので、既存データの最長値は発注者が調べて伝えてください。

社内にレビューできる人がいないときの外部の上流支援への任せ方と範囲

情報システム部門が小さい会社では、数十画面分の設計書を読み込める人が社内にいないことがあります。その状態で承認すると、設計書の誤りが受入テストまで残り、責任の所在も曖昧になります。

任せ方は2通りあります。業務の流れと画面遷移は利用部門が見て、項目一覧と共通ルールの技術的な妥当性だけを外部に確認してもらう方法と、レビュー観点の作成から指摘の取りまとめまでを任せる方法です。一創の要件定義・RFP作成・PMO支援は、要件定義の伴走やPMOとして発注者側に立つ支援です。設計書のレビューを外部に頼めるかどうかは、契約前に範囲として確かめてください。どちらの場合も、承認の判断そのものは発注者が持ちます。

画面設計書を全画面ぶん作らない判断と、省略すると失敗する画面の条件

省いてよい場面：パッケージの標準画面とプロトタイプを正本にする開発

全画面に6つの成果物を揃える必要はありません。パッケージやSaaSの標準画面をそのまま使う部分は、製品マニュアルを正本にして、変更点だけを差分として書けば足ります。

アジャイル開発で、動く試作画面を毎週レビューする進め方なら、レイアウト図は作らず試作画面を正本にしてかまいません。ただしこの場合も、画面入出力項目一覧と共通ルールは残します。桁数や必須の条件は画面を見ても分からず、テスト担当と保守担当が後から参照するのはこの2つだからです。

省くと失敗する画面：入力項目の多い登録画面と権限で表示が変わる画面

次の画面は、どの開発手法でも画面設計書を省きません。入力項目が多く条件つき必須を含む登録・申請画面、管理者と一般利用者で表示が変わる画面、金額や数量を計算して表示する画面、外部システムへデータを送る直前の確認画面です。

これらは、口頭や試作画面だけで合意すると「言った・言わない」になりやすい画面です。条件つき必須の条件、丸め方、権限ごとの表示は、文書に残っていなければ検収時に判断のよりどころがありません。省くかどうかで迷ったら、検収で揉めたときに根拠として示せる文書が残るか、で決めてください。

よくある質問

画面設計書について、発注担当者からよく寄せられる質問に答えます。

画面設計書は発注者と開発会社のどちらが作るのですか？

作成は開発会社、承認は発注者が一般的です。ただし、画面の原案となる業務の流れや必要な入力項目は、発注者が要件定義の段階で示します。IPAのガイドは、利用者層や利用環境を含めた画面操作性の標準を発注者が作って説明することを勧めています（03T001）。発注者が何も示さずに開発会社へ任せると、業務に合わない画面が上がってきて、レビューで作り直すことになります。

画面設計書は英語で何と言いますか？

決まった訳語はなく、screen design document、UI specification、screen specification などが使われます。海外の開発チームと共有するときは、呼び名をそろえるより、画面ID・画面一覧・項目一覧の列の定義を最初に共有する方が誤解が減ります。日本の画面設計書のように桁数や文字種（全角・半角）まで1項目ずつ定義する書式は、海外では一般的ではないため、列の意味を説明する凡例を付けてください。

画面設計書のテンプレートはそのまま使ってよいですか？

使ってかまいませんが、列をそのまま埋めるだけでは不十分です。テンプレートには条件つき必須の条件、項目をまたぐ入力チェック、権限ごとの表示を書く欄がないことが多く、そこが抜けたまま承認されます。テンプレートを使う場合も、画面アクション明細と共通ルールを別に用意し、本記事の承認を止める5つの欠落を確認項目として加えてください。

画面設計書と画面仕様書は違うものですか？

多くの現場では同じ文書を指します。会社によって、外部設計で作るものを画面設計書、発注者に提示する確定版を画面仕様書と呼び分けることもあります。呼び名より、その文書に画面入出力項目一覧と画面アクション明細まで含まれているかを確認してください。レイアウト図だけの文書を「画面仕様書」と呼んでいる場合は、項目と動作の定義がどこにあるかを開発会社に確かめます。

画面設計書は基本設計と詳細設計のどちらで作りますか？

基本設計（外部設計）で作ります。画面設計書は利用者から見える外部仕様を決める文書だからです。詳細設計では、画面設計書をもとに、入力チェックを実装する処理やテーブルへの書き込みなど内部の動きを設計します。発注者が承認するのは基本設計の画面設計書までで、詳細設計書は開発会社内のレビューで扱われるのが一般的です。