業務・画面の設計学習記事全11節Design
入力項目・一覧・詳細・操作ボタンの原型を作る
この記事で身につくこと入力項目・一覧・詳細・操作ボタンと情報の優先順位の考え方を説明し、3画面の原型と項目定義を作れる。画面側で操作を隠すことと処理側で拒否することの違いを説明できる。
記事内目次（26項目）
この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。04-01で描いたシナリオをもとに、依頼作成・一覧・詳細という3つの画面の原型と、それぞれの項目・操作ボタンを作る話です。
なぜ必要か。画面の項目や操作ボタンを思いつきで並べると、必須項目が抜けたり、承認者だけが押せるはずのボタンが誰でも押せる見た目になったりします。
この記事を読むとできるようになること。
- 入力項目・一覧・詳細・操作ボタンと、情報の優先順位の考え方を説明できる
- 依頼作成・一覧・詳細の3画面の原型と、項目定義（必須・型・表示条件）を作れる
- 画面側で操作を隠すことと、処理側で拒否することの違いを説明し、画面制御だけに頼らない理由を書ける
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「3画面それぞれに何を置くか」が分かり、ひな形を埋め始められます。
- 作って確かめる：上に加えて第6節（失敗例と直し方）→第7節。
- 設計判断を深める：上に加えて第8節（画面制御だけに頼らない理由、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、04-01で描いた役割別シナリオをもとに、依頼作成・一覧・詳細という3つの画面の原型を作り、それぞれの項目・必須・型・表示条件・操作ボタンを定義することです。
シナリオで「誰が、どの状態で、何を操作するか」は決まりましたが、「画面に何を、どう並べるか」はまだ決まっていません。この記事では、それを画面の原型として作ります。
この記事を読み終えると、次のものが手元にできます。
- 画面の原型（画面名、項目、必須、型、表示条件、操作ボタンと役割）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
入力項目
一言でいうと、利用者が画面に入力する項目です。たとえば、依頼作成画面の「件名」「内容」「承認者」です。
これがないと、何を入力すればよいか利用者に伝わらず、依頼の内容がばらばらになります。
一覧・詳細
一言でいうと、複数の依頼をまとめて見る画面（一覧）と、1件の依頼を詳しく見る画面（詳細）です。
必須・型・表示条件
一言でいうと、その項目を必ず入力しないといけないか（必須）、どんな種類の値か（型：文字、日付など）、どういう時にその項目・ボタンが表示されるか（表示条件）です。たとえば、「承認・差戻しボタンは、承認者が詳細画面を開いたときだけ表示される」というのが表示条件です。
情報の優先順位
一言でいうと、画面の中で、利用者が最初に見るべき情報を目立たせる考え方です。一覧画面であれば、依頼の状態（提出済み・差戻しなど）を目立たせることで、承認者がすぐに対応すべき依頼を見つけられます。
読む順路：役割別シナリオは04-01が該当します。次工程のデータ項目表は05-01が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。
3. 理解する：画面に何を、どう並べるか
3.1 3画面とシナリオの対応
| 画面 | 対応するシナリオ（04-01） |
|---|---|
| 依頼作成画面 | 依頼者が依頼を作成し、提出する |
| 一覧画面 | 承認者・運用管理者が依頼の状態を確認する |
| 詳細画面 | 承認者が内容を確認し、承認・差戻しする |
3.2 情報の優先順位の考え方
一覧画面では、件数が多くなるほど、どれから見ればよいか分かりにくくなります。04-01のシナリオでは、承認者は「提出済み」の依頼にまず対応する必要があるため、状態を目立たせ、絞り込めるようにします。
詳細画面では、承認者が判断に必要な情報（依頼の内容）を先に見せ、操作ボタン（承認・差戻し）はその後に置きます。
3.3 よくある誤解
「項目は多いほど親切」。項目が多いと、依頼者が何を入力すればよいか迷います。02-02の機能一覧・04-01のシナリオにある情報だけを項目にします。
「ボタンを画面に表示しなければ、操作できないので安全」。画面にボタンを表示しないだけでは、直接操作された場合に防げません。処理する側でも権限を確認する必要があります（第8節）。
「原型は本物の画面のように作り込む必要がある」。この記事の原型は手描き・文字ベースで十分です。項目と表示条件が分かることを優先します。
「AIに画面を作らせればよい」。AIは一般的な画面構成の案を提示できますが、この業務のどの項目が必須か、どのボタンを誰に見せるかは、04-01のシナリオに基づいて人が確認します（第4.3節）。
4. 判断すること
4.1 何を確認すればよいか
| 確認すること | この記事での扱い |
|---|---|
| 作成・一覧・詳細の3画面があるか | 第5.2節で確認する |
| 項目定義に必須・表示条件があるか | 第5.2節で確認する |
| 操作ボタンごとに、操作可能な役割が決まっているか | 第5.2節で確認する |
4.2 勝手に決めてはいけないこと
- 04-01のシナリオにない項目・操作ボタンを、この記事で新たに作りません。
- 承認・差戻しボタンを、承認者以外にも操作できるようにしません（REQ-002・REQ-003に基づく役割の区別）。
- 画面にボタンを表示しないことだけで、権限の確認を済ませたことにしません（第8節）。
4.3 AIに任せる範囲
画面構成の一般的な案（項目の並び順など）の提示はAIに任せられます。しかし、どの項目が必須か、どのボタンを誰に見せるかは、04-01のシナリオに基づいて人が確認します。
5. 作って確かめる：画面の原型を作る
5.1 準備
04-01の役割別シナリオを用意します。
5.2 画面の原型
| 画面名 | 項目 | 必須 | 型 | 表示条件 | 操作ボタンと役割 |
|---|---|---|---|---|---|
| 依頼作成画面 | 件名 | 必須 | 文字 | 常に表示 | 「提出」ボタン：依頼者のみ |
| 依頼作成画面 | 内容 | 必須 | 文字（複数行） | 常に表示 | 同上 |
| 依頼作成画面 | 承認者 | 必須 | 選択（承認者一覧から選ぶ） | 常に表示 | 同上 |
| 一覧画面 | 件名 | — | 文字 | 常に表示 | — |
| 一覧画面 | 状態（下書き・提出済み・差戻し・承認済み） | — | 選択 | 常に表示。状態で絞り込みできる | — |
| 一覧画面 | 提出日 | — | 日付 | 提出済み以降のみ表示 | — |
| 詳細画面 | 件名・内容・承認者 | — | （作成画面と同じ） | 常に表示 | — |
| 詳細画面 | 差戻し理由 | — | 文字（複数行） | 状態が「差戻し」のときだけ表示 | — |
| 詳細画面 | （操作） | — | — | 状態が「提出済み」のときだけ表示 | 「承認」「差戻し」ボタン：承認者のみ |
| 詳細画面 | （操作） | — | — | 状態が「差戻し」のときだけ表示 | 「再提出」ボタン：依頼者のみ |
5.3 手描き原型（文字ベース）
【依頼作成画面】
件名：［__________］（必須）
内容：［__________］（必須・複数行）
承認者：［選択▼］（必須）
[提出]
【一覧画面】
状態で絞込：［すべて▼］
件名 状態 提出日
----------------------------------
○○の件 提出済み 2026-09-18
△△の件 差戻し 2026-09-15
【詳細画面（承認者が開いた場合・状態＝提出済み）】
件名：○○の件
内容：（本文）
承認者：（自分）
[承認] [差戻し]5.4 AIに原型の下書きを頼む
各画面の一般的な項目案をAIに提示させ、下書きを作らせます。
依頼・承認管理アプリの画面原型を作りたいです。04-01のシナリオ（依頼者が作成・提出、承認者が承認・差戻し、依頼者が再提出）を渡します。
依頼：
1. 依頼作成・一覧・詳細の3画面について、項目・必須・型・表示条件を表にしてください。
2. 操作ボタンごとに、操作できる役割を明記してください。
してはいけないこと：
- シナリオにない項目・ボタンを追加しないでください。
- 承認・差戻しボタンを承認者以外が操作できるようにしないでください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 詳細画面の「承認」「差戻し」ボタンに、操作できる役割が書かれていなかった（誰でも押せるように見える）
- 一覧画面に「削除」ボタンが追加されていた（04-01のシナリオにも02-02の機能一覧にもない操作）
6.2 見つけ方と直し方
- 操作可能な役割が書かれていない：完了条件「ボタンごとに操作可能な役割」を満たしません。「承認者のみ」を明記します。
- シナリオにない操作が追加されている：04-01のシナリオ・02-02の機能一覧にありません。一覧画面から「削除」ボタンを外すという判断をします。
指摘：
1. 「承認」「差戻し」ボタンに、操作できる役割（承認者のみ）を明記してください。
2. 「削除」ボタンはシナリオにありません。削除してください。
変えないこと：
- 04-01の内容そのものは変更しないでください。6.3 修正後の原型
7. 確認結果
第5.2節の原型を、完了条件と照合します。
| 完了条件 | 確認結果 |
|---|---|
| 作成・一覧・詳細の3画面がある | 依頼作成・一覧・詳細の3画面を定義 |
| 項目定義に必須と表示条件がある | 全項目に必須・表示条件の列を記載 |
| ボタンごとに操作可能な役割がある | 「提出」「承認」「差戻し」「再提出」すべてに操作可能な役割を明記 |
残る制限：この原型は架空の業務に基づく一例であり、文字ベースの簡易な表現です。実際の画面デザイン（配置、色など）はこの記事の範囲外です。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 画面側で隠すことと、処理側で拒否することの違い
| 対策 | 内容 | 防げること | 防げないこと |
|---|---|---|---|
| 画面側で隠す（この記事の範囲） | 承認者以外には「承認」「差戻し」ボタンを表示しない | 誤って押してしまうことを防げる | 直接その操作を実行する通信が送られた場合は防げない |
| 処理側で拒否する（この記事の範囲外、実装段階で対応） | 承認・差戻しの処理を実行する前に、操作した人が承認者かどうかを確認する | 直接操作された場合でも拒否できる | — |
この記事では画面側の原型（表示条件）までを扱い、処理側での確認は03-04の開発計画にある実装作業（依頼作成〜提出〜承認の一連の処理を実装する）で対応します。画面側の表示条件だけに頼ると、REQ-002・REQ-003の権限に関する要件を実際には満たせていない、という状態になり得ます。
8.2 適用限界
この記事の原型は、架空企業「みらい業務サービス」の3画面・4状態を前提にしています。画面数や状態が増える場合は、原型を作り直す必要があります。また、この記事は文字ベースの原型であり、実際の見た目の使いやすさ（配置、文字の大きさなど）は確認していません。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 画面の原型ひな形（画面名、項目、必須、型、表示条件、操作ボタンと役割） | templates/04-02-screen-prototype_template.md | templates/04-02-screen-prototype_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（04-01の役割別シナリオ）を用意する
- シナリオに登場する画面を洗い出す（作成・一覧・詳細など）
- 各画面の項目に、必須・型・表示条件を書く
- 操作ボタンごとに、操作できる役割を書く
10. 次工程への受渡し
次へ渡すもの：画面の原型（画面名、項目、必須、型、表示条件、操作ボタンと役割）。
次工程での使われ方：05-01（データ項目表）では、この画面の項目をもとに、保存するデータの項目を定義します。
前工程へ戻る条件：原型を作る中で04-01のシナリオにない操作が必要だと分かったら、04-01に戻ってシナリオを見直します。
11. 根拠と更新情報
- この記事の会社・人物・画面例はすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 画面側で隠すことと処理側で拒否することの違いは、一般的なアクセス制御の考え方に基づく説明であり、特定の製品・実装方式を前提にしていません。
- 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 未確認事項：実際の画面デザイン（配置、見やすさなど）は確認しておらず、文字ベースの原型のみで進めている。