受入条件が要件をもれなく確認できているかを点検する

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

管理項目	内容
記事ID	02-04
主な中カテゴリ	02-04 例外と完成条件を決める
関連中カテゴリ	02-01、02-02、02-03、09-02、10-01
関連要件ID	REQ-001〜008
先に読むと理解しやすい記事	記事A（02-01）・02-02・02-03を読んでいると理解しやすい。未読でも本文で必要な内容は説明する
到達目標	受入条件が全要件（REQ-001〜008）をもれなく確認できているかを点検し、抜けを見つけ、どれを人が見る受入確認で・どれを機械的なテストで確かめるかを振り分けられる
3層の配置	理解する＝第3〜4節／作って確かめる＝第5〜7節／設計を判断する＝第8節
成果物パス	templates/02-04-acceptance-criteria_template.md、templates/02-04-acceptance-criteria_example.md
出典	第11節参照
対象ツール・バージョン	特定ツールに依存しない
検証状況	本文・ひな形・記入例はClaude Codeが作成。人による実読・内容確認は未実施
残課題	第11節参照
最終更新日	2026-09-20（新規作成）。2026-09-21（Final Content Audit：読む順路の「本文は今後制作予定」（全項目に本文がある現在は誤り）を削除。本文は不変）

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

この記事は何の話か。記事A（02-01）で作った受入条件が、全部の要件を本当にもれなく確認できているかを点検する話です。抜けがあれば補い、どれを人が見て確かめ、どれを機械的なテストで確かめるかを決めます。

なぜ必要か。受入条件を思いつくままに作ると、正常な場合ばかりに目が行き、「差戻された依頼を直して出し直す」「途中で保存に失敗する」といった、起きたら困る場面の確認が抜け落ちることがあります。抜けたまま次の工程に進むと、確認していない場面で不具合が見つかります。

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

• 要件ごとに受入条件が対応しているかを一覧で点検できる
• 正常・権限なし・入力不足・状態外・重複・途中失敗・再実行の観点で抜けを見つけられる
• どの受入条件を人が見て確かめ（受入確認）、どれを機械的なテストで確かめるかを振り分けられる

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

• 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「点検の観点」と「対応表の形」が分かり、ひな形を埋め始められます。
• 作って確かめる：上に加えて第5.3節（新しい受入条件の作成）→第6節（失敗例と直し方）→第7節。
• 設計判断を深める：上に加えて第8節（振り分けの判断、適用限界）。

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

この記事でやることは、記事A（02-01）が作った受入条件一覧を、全要件（REQ-001〜008）と照らして点検し、抜けを補い、確認場面（人が見るか、機械的なテストで確かめるか）を決めることです。

記事Aはすでに10件の受入条件（AC-001〜AC-010）を作りました。しかし記事Aの時点では、まだ「差戻された依頼を直して出し直す」場面（再実行）の受入条件がありません。また、10件それぞれをどこで確かめるか（09-02の記事Bのテストか、10-01の受入確認か）は、まだ整理されていません。

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

• 全要件（REQ-001〜008）と受入条件の対応表
• 「再実行」の観点で補った新しい受入条件
• 各受入条件をどこで確かめるかの振り分け

2. 前提知識と読む順路

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

確認場面（人が見る／機械的なテスト）

一言でいうと、その受入条件を、人が画面や記録を見て確かめるのか、プログラムが自動的に確かめるのかの区別です。

たとえば、「割当外の承認者が承認しようとすると拒否される」は、承認処理の中身の話なのでプログラムのテストで確かめやすい条件です。一方、「一覧に自分の依頼だけが表示される」は、実際の画面ができてから人が見て確かめる方が向いています。

これがないと、まだ存在しない画面の確認を「テストで確かめる」つもりになっていたり、逆にプログラムで確かめられることを「後で人が見る」に先送りしたりして、確認の計画がずれます。

再実行

一言でいうと、一度差戻された依頼を直して、もう一度提出することです。

たとえば、「件名が空のまま提出しようとして拒否された」あと、「件名を書いて出し直したら受け付けられる」までを確認して初めて、この場面を確かめたことになります。

これがないと、「最初の1回だけ確かめて終わり」になり、直してからの2回目がうまくいくかどうかが分かりません。

読む順路：受入条件のもとになる要件一覧・機能一覧・品質条件は02-01〜02-03が該当します。受入条件をテストの期待結果にする工程は09-02（記事B）、人が見て確かめる受入確認は10-01が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。

3. 理解する：なぜ「作ってから確認」ではなく「先に点検」するのか

3.1 受入条件は思いつきでは抜けが出る

記事Aの受入条件10件は、次の観点で書かれています。

• 正常（AC-001、AC-009）
• 権限なし（AC-002、AC-003、AC-007）
• 状態外（AC-004）
• 入力不足（AC-005、AC-006）
• 重複（AC-008）
• 途中失敗（AC-010）

これらは記事Aの時点で「思いつく限り」書かれたものです。しかし、依頼の状態（下書き→提出済み→差戻し→提出済み→承認済み）を見直すと、「差戻しから出し直す」という再実行の場面がまだ確認されていないことに気づきます。

思いついた順に受入条件を作ると、目立つ場面（正常、権限なし）は手厚くなり、地味な場面（やり直し）は忘れられがちです。この記事では、要件一覧・状態遷移という「もれなく数えられる基準」から抜けを探します。

3.2 よくある誤解

「受入条件は多いほど安心」。数を増やすことが目的ではありません。各要件に最低1件、正常時・例外時・やり直しの観点で抜けがないことが目的です。

「テストで全部確かめられる」。記事B（09-02）のテストはコードの動きを確かめますが、画面の見え方や実際の操作性は、画面ができてから人が見て確かめる必要があります（記事AのAC-005、007、009は記事Bで未検証と明記されています）。

「新しい受入条件を作れば作るほどよい」。この記事で補うのは、状態遷移という既存の枠組みの中の抜け（再実行）だけです。新しい状態や役割を作って条件を増やすことはしません。

「AIに抜けを探させれば十分」。AIは要件一覧と受入条件を照合して抜けの候補を示せますが、その抜けを本当に埋める必要があるか、どこで確認するかは人が判断します（第4.3節）。

4. 判断すること

4.1 何を確認すればよいか

4.2 勝手に決めてはいけないこと

• 記事Aの受入条件10件の内容そのものは変更しません。抜けを補うだけです。
• 新しい状態・役割・要件を、この記事で作りません。
• どこまでを機械的なテストで確かめ、どこからを人が見て確かめるかは、実際にテストが書けるかどうかという技術的な事実に基づいて判断し、都合よく決めません。

4.3 AIに任せる範囲

要件一覧と受入条件の対応表の下書き、抜けの候補の提示はAIに任せられます。しかし、抜けを本当に埋める必要があるか、どこで確認するかは人が判断します。

5. 作って確かめる：対応表を作り、抜けを補う

5.1 準備

記事Aの受入条件一覧（AC-001〜AC-010、記事A第5.5節）を用意します。

5.2 要件と受入条件の対応表

5.3 抜けを補う：再実行の受入条件

5.4 確認場面の振り分け

5.5 AIに対応表の下書きを頼む

記事Aの要件一覧・受入条件一覧をAIに渡し、対応表の下書きと抜けの候補を作らせます。

記事Aの業務要件一覧（REQ-001〜005、007）と受入条件一覧（AC-001〜010）を渡します。

依頼：
1. 要件ごとに対応する受入条件を一覧にしてください。
2. 正常・権限なし・入力不足・状態外・重複・途中失敗・再実行の観点で、抜けている場面があれば指摘してください。

してはいけないこと：
- 記事Aにない新しい要件・状態・役割を作らないでください。
- REQ-008（バックアップ・復元）は、この題材（記事A・Bの範囲）には対応する受入条件がないことを前提にしてください。

6. 初稿・失敗例・修正

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

AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。

• REQ-008（バックアップ・復元）について、「依頼のバックアップを取る受入条件」を新たに作成
• 「再実行」の抜けの指摘に加えて、「依頼の一括再提出」という新しい機能を前提にした受入条件を提案

6.2 見つけ方と直し方

• REQ-008の受入条件：この記事の題材（記事A・Bの範囲）に対応する機能がありません。REQ-008は12-03（記事C）のバックアップ・復元演習で扱う要件です。削除します。
• 「一括再提出」：02-02の機能一覧にない新しい機能です。削除し、1件ずつの再提出（AC-011）だけを残します。

指摘：
1. REQ-008の受入条件は、この記事の題材にありません。削除してください。
2. 「一括再提出」は02-02の機能一覧にありません。削除し、1件ずつの再提出だけにしてください。

変えないこと：
- 記事Aの受入条件10件の内容は変更しないでください。

6.3 修正後の対応表

修正後の対応表・振り分けは、第5.2節〜第5.4節のとおりです。

7. 確認結果

完了条件と照合します。

残る制限：AC-011は架空ケースの受入条件であり、実装して確かめてはいません。振り分け（第5.4節）は記事Bの実績に基づく判断であり、実際に受入確認（10-01）が行われた結果ではありません。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。

8. 設計を判断する

8.1 振り分けの判断基準

この記事では、コードの動きに関する受入条件は機械的なテストに、画面や操作に関する受入条件は人が見る受入確認に振り分けました。ただし、画面ができた後には、AC-005〜AC-011も自動テストの対象にできる可能性があります。

8.2 適用限界

この記事の対応表は、記事A・記事Bの範囲（要件定義と最小実験コード）だけを前提にしています。画面（04-02）や保存先の詳細設計（05-01〜05-03）が決まると、受入条件の書き方や振り分けを見直す必要が出ることがあります。

9. 持ち帰る成果物

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

1. 既存の要件一覧・受入条件一覧を用意する
2. 要件ごとに対応する受入条件があるかを一覧にする
3. 正常・権限なし・入力不足・状態外・重複・途中失敗・再実行の観点で抜けを探す
4. 抜けがあれば、既存の受入条件と同じ形式で補う
5. 各受入条件を、機械的なテストと人が見る受入確認のどちらで確かめるかを決める

10. 次工程への受渡し

次へ渡すもの：要件と受入条件の対応表、新しく補った受入条件（AC-011）、確認場面の振り分け。

次工程での使われ方：09-02（記事B）では、機械的なテストに振り分けた受入条件が期待結果になります。10-01（受入確認）では、人が見る受入確認に振り分けた受入条件が確認項目になります。

前工程へ戻る条件：対応表を作る過程で要件そのものに不足が見つかったら、02-01（記事A）に戻って要件を見直します。機能に抜けが見つかったら02-02に戻ります。

11. 根拠と更新情報

• この記事の会社・人物・受入条件はすべて架空の設定です。
• 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
• AC-001〜AC-010は記事A第5.5節の受入条件をそのまま引用しています。AC-011のみこの記事で新規に作成しました。
• REQ-008（バックアップ・復元後の照合）は、教材設計書AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.4節の要件であり、12-03（記事C）の題材に対応します。この記事の題材には対応する機能がないため対象外としました。
• 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
• 未確認事項：AC-011は実装して確かめていません。確認場面の振り分け（第5.4節）は判断の一例であり、実際に受入確認が行われた結果ではありません。