入力ミス・差戻し・空の一覧・通信失敗の画面を、実装前に決める

原稿の管理表（13項目：記事ID・カテゴリ・要件ID・先に読むと理解しやすい記事・成果物パス・対象ツール・検証状況・最終更新日など）

管理項目	内容
記事ID	04-04
主な中カテゴリ	04-04 例外と使いやすさを設計する
関連中カテゴリ	04-03、02-04、08-04、09-03
関連要件ID	REQ-004
先に読むと理解しやすい記事	04-03（正常時の流れを確認する）を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	入力ミス、差戻し、空の一覧、通信失敗、キーボード操作、読める表示を設計対象として扱う理由を説明できる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/04-04-exceptions-ui_template.md、templates/04-04-exceptions-ui_example.md
出典	第11節参照
対象ツール・バージョン	特定ツールに依存しない
検証状況	本文・ひな形・記入例はClaude Codeが作成。第5.4節の指示文と第6節の初稿は説明用の例であり、実際にAIへ送信・観測した記録ではない。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成。同日、Phase 5B-2A：読む順路・第4節の判断項目・第5.4節「AIに表示文の下書きを頼む」（渡す情報・指示文）・第6節のレビュー観点・記事間の参照を追加。例外画面・表示ルール・完了条件は不変）

この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。

この記事は何の話か。04-03で確認した正常な流れの他に、必須項目が欠けた提出、理由のない差戻し、依頼が0件の一覧、保存中の通信失敗という4つの場面で、画面に何を表示し、利用者が次に何をできるかを決める話です。

なぜ必要か。正常な流れだけを想定して作ると、少しでも想定と違う操作や状況が起きたときに、利用者が何をすればよいか分からなくなったり、内部の仕組みに関する情報が意図せず表示されてしまったりします。

この記事を読むとできるようになること。

• 入力ミス、差戻し、空の一覧、通信失敗などを設計対象として扱う理由を説明できる
• 4つの例外場面について、表示内容と次に取れる操作を書ける
• エラー表示に何を出し何を出さないかを、使いやすさと安全性から判断できる

読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。

• 基本だけ理解する：第1節→第3節（4つの例外場面と誤解）→第4節（判断すること）→第5.2〜5.3節（例外時の画面と、出さない情報）→第9節。ここまでで、例外場面ごとに「表示文・次の操作・出さない情報」を決める形が分かります。AIへの依頼は出てきません。
• 作って確かめる：上に加えて第5.4節（AIに表示文の下書きを頼む）→第6節（初稿に混ざる内部情報の露出の見つけ方）→第7節。
• 設計判断を深める：上に加えて第8節（使いやすさと安全性のバランス、適用限界）。

1. 今回の業務課題と完成するもの

この記事でやることは、04-03で確認した正常な流れに加えて、入力不備・差戻し・空の一覧・通信失敗という4つの場面について、画面の表示内容と、利用者が次に取れる操作を決めることです。

04-03までで「想定どおりに進んだ場合」の流れは確認できましたが、実際の利用では、入力を間違えたり、通信が一時的に失敗したりすることがあります。この記事では、それらの場面を先に設計しておきます。

この記事を読み終えると、次のものが手元にできます。

• 例外時の画面・表示ルール（場面、表示文、次の操作、出さない情報、関連要件ID）

2. 前提知識と読む順路

この記事で使う言葉を先に説明します。

例外

一言でいうと、想定どおりではない操作や状況のことです。たとえば、必須項目を入力せずに提出しようとすることが例外にあたります。

キーボード操作

一言でいうと、マウスを使わずにキーボードだけで操作できることです。たとえば、Tabキーで次の入力欄に移動できることです。

読める表示

一言でいうと、文字の大きさや色などが、誰にとっても読みやすい表示のことです。

これがないと、正常系だけを想定した画面では、少し違う状況になっただけで利用者が操作に迷ったり、一部の利用者が読みにくい画面になったりします。

読む順路：正常系の確認は04-03が該当します。受入条件は02-04（記事AのAC-005・006が入力不備と差戻しに対応）が該当します。この記事の例外画面は、08-04（エラー処理と保守しやすさを整える）、09-03（例外・権限・同時操作・負荷を確認する）で使います。

3. 理解する：なぜ例外を設計対象にするか

3.1 4つの例外場面

3.2 よくある誤解

「例外は実装のときに考えればよい」。例外時の表示や操作を決めずに実装すると、開発者ごとにばらばらな表示になったり、内部のエラーメッセージがそのまま利用者に見えてしまったりします。

「エラーは詳しく表示するほど親切」。詳しすぎるエラー表示は、内部の仕組み（保存先の種類など）に関する情報を意図せず外部に見せてしまうことがあります（第4.2節）。

「空の一覧は特別な対応をしなくてよい」。依頼が0件の状態を何も考慮しないと、利用者は「動いていないのでは」と誤解することがあります。

「AIに例外の一覧を作らせればよい」。AIは一般的な例外の型を提示できますが、この業務でどこまで表示し、何を出さないかは、要件（REQ-004）に基づいて人が判断します（第4.3節）。

4. 判断すること

例外時の画面を決めるときに人が判断することは、次の4つです。

勝手に決めてはいけないこと：04-02・04-03にない画面や項目を、この記事で新しく作りません。例外時の表示に限定します。内部の仕組み（保存先の種類、処理の内部エラーコードなど）を、そのまま利用者に見せる表示にしません。

AIに任せる範囲：一般的なエラー表示の型や文言の候補の提示、表の形への整理はAIに任せられます。しかし、どこまで詳しく表示し、何を出さないかは、REQ-004（必須項目・差戻し理由の要件）とREQ-002（見える範囲）に基づいて人が判断します。AIの文言候補には内部のエラーメッセージがそのまま混ざることがあるため、人が「出さない情報」の表と照合します（第6節）。

5. 作って確かめる：例外時の画面・表示ルールを作る

5.1 準備

04-02の画面の原型、04-03の正常系確認記録、02-04の受入条件を用意します。

5.2 例外時の画面

5.3 出さない情報の表示ルール

5.4 AIに表示文の下書きを頼む

4場面と「出さない情報」の表が決まると、表示文の下書きをAIに頼めます。AIがするのは、場面ごとに利用者向けの文言候補を出すことです。採用する文言と、出さない情報の最終確認は人が行います。

指示文は次のとおりです。これは説明のために書いた例で、実際にAIへ送信した記録ではありません。

架空企業「みらい業務サービス」の依頼・承認管理アプリについて、次の4つの例外場面で画面に出す表示文と、利用者が次に取れる操作の下書きを作ってください。

場面：入力不備（必須項目が欠けている）、差戻し（理由なし）、空の一覧、通信失敗

条件：
- 表示文は利用者向けの言葉で、次に何をすればよいかが分かる形にしてください。
- 次の情報は表示文に含めないでください：保存先の種類、内部のエラーコードやメッセージ、他の利用者の依頼の内容、処理の順序などの内部の詳細。

してはいけないこと：
- 4場面以外の場面を追加しないでください。
- 画面や項目を新しく作らないでください。

返し方：
- 「場面・表示文・次に取れる操作」の表だけを返してください。

6. 初稿・失敗例・修正

6.1 説明用の失敗例（AIの初稿という設定）

第5.4節の指示に対して、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではなく、教えるために不備を入れた説明用の例です）。

• 通信失敗の表示文に「データベース接続エラー：connection refused」という内部のエラーメッセージをそのまま含めていた
• 空の一覧の場面で、表示文だけがあり「次に取れる操作」が書かれていなかった

6.2 見つけ方と直し方

見るところは2つです。表示文に「出さない情報」（第5.3節）が含まれていないか。各場面に「次に取れる操作」があるか。

「親切のつもりで詳しく出す」文言ほど、内部情報が混ざりやすい箇所です。詳しさではなく、利用者が次の操作を選べるかで判断します。

AIへの修正指示は次のとおりです（説明用の例）。

指摘：
1. 通信失敗の表示文から、内部のエラーメッセージ（データベース接続エラー：connection refused）を削除し、利用者向けの表現にしてください。内部の情報は表示せず、記録（ログ）に残す方針です。
2. 空の一覧の場面に、次に取れる操作を追加してください。

変えないこと：
- 4場面と表の列は変更しないでください。

6.3 修正後の画面・表示ルール

修正後の例外時の画面・表示ルールは、第5.2〜5.3節のとおりです。採用したのは表示文の「型」であり、実際の文言の分かりやすさは10-01の受入確認で利用者に確かめてもらいます（この教材の時点では画面が未実装のため未確認）。

7. 確認結果

第5.2〜5.3節の内容を、完了条件と照合します。

残る制限：この例外設計は架空の画面原型に基づく一例です。実際の表示文の分かりやすさは、利用者による確認（10-01の受入確認）で確かめる必要があります。第5.4節の指示文と第6節の初稿は説明用の例であり、実際にAIへ送信・観測した記録ではありません。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 使いやすさと安全性のバランス

内部の詳しいエラー情報は、利用者向けの画面には表示せず、必要であれば08-04で扱う記録（ログ）に残す方針とします。

8.2 適用限界

この例外設計は、架空企業「みらい業務サービス」の4場面を前提にした一例です。実際の利用では、これ以外の例外（例えば、同時に複数人が同じ依頼を編集しようとする場合）もあり、それらは05-02・09-03で扱います。

9. 持ち帰る成果物

自分の業務に使うときの手順は次のとおりです。

1. 前工程（画面の原型、正常系確認記録、受入条件）を用意する
2. 入力不備・差戻し・空一覧・通信失敗などの例外場面を挙げる
3. 各場面の表示文と、次に取れる操作を書く
4. 出さない情報の表示ルールを書く

10. 次工程への受渡し

次へ渡すもの：例外時の画面・表示ルール。

次工程での使われ方：08-04（エラー処理と保守しやすさを整える）では、この表示ルールをもとに実装します。09-03（例外・権限・同時操作・負荷を確認する）では、この例外設計が検証観点になります。10-01では、入力不備（AC-005）と差戻し（AC-006）の表示を受入条件として確認します。

前工程へ戻る条件：例外場面が04-02・04-03の画面と食い違う場合は、それぞれの記事に戻って確認します。

11. 根拠と更新情報

• この記事の会社・人物・表示文はすべて架空の設定です。
• 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
• 必須項目・差戻し理由の要件（REQ-004）は、教材設計書AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.4節に基づきます。
• 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
• 第5.4節の指示文は、この記事のために書いた指示文の例であり、実際にAIへ送信した記録ではありません。
• 2026-09-20（Phase 5B-2A）：読む順路（3つの深さ）、第4節の判断項目、第5.4節「AIに表示文の下書きを頼む」（渡す情報と指示文）、第6.2節のレビュー観点の表、記事間の参照を追加した。例外画面・表示ルール・完了条件は変えていない。
• 未確認事項：表示文の分かりやすさは、実際の利用者による確認（10-01）で確かめる必要があり、この記事の時点では行っていません。