導入・受入の準備学習記事全11節Verify
受入確認を、確認できたもの・演習で確かめたもの・未確認のものに分けて記録する
この記事で身につくこと開発側の検証と、実際の業務担当者による受入確認の違いと、不合格条件を先に決める理由を説明できる。
記事内目次（19項目）
この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。この記事の時点では実際に動く画面がまだ無く、業務担当者による受入確認そのものは行えません。この記事では、現在の実装範囲で実際に観測できたことだけを「演習上の確認」として記録し、観測できないものは「未確認」として残します。設計文書を読み返して「設計どおりだから合格」とはしません（第3.2節）。確認者は実装者と同じAI（Claude Code）です（第8.1節）。
この記事は何の話か。02-04で整理した受入条件のうち、画面や操作に関わるため09-02（記事B）のテストでは確認していない5件（AC-005、006、007、009、011）について、「今の実装で本当に観測できるもの」と「観測する対象がまだ無いもの」を分け、受入確認記録に正直に書く話です。
なぜ必要か。09-02までの確認はコードの動きを確認するものでした。実際に画面を操作する立場（依頼者、承認者）から見て使えるかどうかは、別に確認する必要があります。
この記事を読むとできるようになること。
- 開発側の検証と、実際の業務担当者による受入確認の違いを説明できる
- 受入条件ごとに、実際に観測できたこと・演習で確かめたこと・未確認のことを分けて受入確認記録に書ける
- 受入確認で見つかった問題（未実装の確認を含む）を、修正・運用対応・受入条件の見直しのどれで扱うかを判断できる
- 「実際の受入確認」と「机上の演習」の違いを言い、演習で確かめたことを受入合格と混同せずに次工程へ渡せる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（開発側の検証と受入確認の違い、実際の受入確認と机上演習の違い）→第4節（判断すること）→第5.1節（今の実装で観測できる範囲）→第6節の受入確認記録の表→第9節。コードを読まなくても、5件の受入条件がなぜ「合格0件・演習1件・未確認4件」になるかが分かります。
- 作って確かめる：上に加えて第5.2節（不合格条件）→第5.3節（演習コード）→第6節の実行結果→第7節（確かめたこと・確かめていないこと）。
- 設計判断を深める：上に加えて第8節（見つかった問題の扱い方、「設計した」と「そのとおりに動く」の違い）。
1. 今回の業務課題と完成するもの
この記事でやることは、02-04で整理した受入条件のうち、09-02（記事B）のテストでは確認していない5件（AC-005、006、007、009、011）について、確認手順と不合格条件を先に決め、現在の実装範囲で観測できるものだけを依頼者役の操作に相当する形で実際に確かめ、観測できないものは未確認として受入確認記録に書くことです。
09-02では機械的なテストでコードの動きを確認しましたが、画面を操作する立場からの確認はまだ行っていませんでした。この記事では、その確認の記録の付け方を扱います。ただし画面がまだ無いため、この記事で「受入確認済み」にできる受入条件はありません。
この記事を読み終えると、次のものが手元にできます。
- 受入確認記録（確認者の役割、受入条件、操作、結果、確認の種別、合否、不合格条件、対処）
- AC-005の観測できる部分を確かめる演習コードと実行記録（
examples/10-01-acceptance-record/）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
受入確認
一言でいうと、実際にその業務を行う立場の人（またはその役を演じる人）が、業務として使えるかどうかを確認することです。開発側の検証（テスト）とは見る立場が違います。
不合格条件
一言でいうと、「これが起きたら受け入れられない」という基準を、確認する前に決めておくものです。確認した後で基準を決めると、都合よく合格にしてしまう可能性があります。
これがないと、コードが正しく動くことは確認できても、実際の業務の立場から見て分かりにくい、使いにくいといった問題に気づけません。
読む順路：受入条件は02-04（記事AのAC-001〜010）、機械的なテストは記事B（09-02）、レビュー記録は09-04、画面設計は04-02・04-04が該当します。この記事の受入確認記録は、10-04（利用開始の可否を判断する）で判定区分を決める材料になります。
3. 理解する：開発側の検証と受入確認の違い
3.1 見る立場の違い
09-02のテストは、コードが要件どおりに動くかを確認するものです。この記事の受入確認は、依頼者・承認者という業務上の立場から見て、操作結果が分かりやすいか、期待どおりかを確認するものです。同じ受入条件でも、確認する立場が違います。
3.2 よくある誤解
「テストに合格したら、受入確認は形だけでよい」。02-04で整理したとおり、AC-005、006、007、009、011は09-02のテストでは確認していません（画面や操作を伴うため）。テストの合格は、受入確認の代わりにはなりません。
「設計文書に書いてあれば、確認したことになる」。04-02・04-04の設計に「必須項目が欠けたら拒否する」と書いてあっても、それは「そう作る予定」であって「そう動いた」ではありません。受入確認は、動いたものを見て初めて成立します。観測する対象が無いのに合格を付けると、10-04の利用開始判定が誤った材料の上に立ってしまいます。
「確認しながら合否の基準を決めればよい」。基準を先に決めずに確認すると、細かい問題を見逃したり、逆に些細な問題で合格にしないなど、判断がぶれます。この記事では、確認する前に不合格条件を決めます（第5.2節）。
「演習で拒否を確かめたのだから、AC-005は合格」。演習で確かめたのは、保存処理を直接呼んだときの作成時のチェックです。AC-005が求める「提出したら拒否され、足りない項目が示される」は、画面と提出時のチェックが無いため観測できていません。演習は受入確認の代わりにはなりません（第3.3節）。
3.3 実際の受入確認と机上演習の違い
結論から言うと、受入確認とは「業務の立場の人が、実際に動く画面を操作して、期待どおりかを観測する」ことで、この記事の演習はそのどれでもありません。
| 観点 | 実際の受入確認（この教材では未実施） | この記事の演習 |
|---|---|---|
| 誰が | 業務担当者（依頼者役・承認者役の人）。実装者以外 | 実装者と同じAI（Claude Code） |
| 何を操作するか | 実際に動く画面 | 保存処理の関数を直接呼ぶコード |
| 何を観測するか | 画面の表示、操作の結果、業務として分かりやすいか | 関数の戻り値と保存先の中身 |
| 何が言えるか | 「この受入条件は業務として受け入れられる」 | 「今の実装範囲で、この部分はこう動く」 |
| 受入記録での種別 | 観測 | 演習 |
| この記事での件数 | 0件 | 1件（AC-005の作成時チェックのみ） |
演習が無意味なのではありません。演習で「作成時のチェックは働く」「提出時のチェックは無い」と分かったことは、10-04の未解決問題として使われています。無意味になるのは、演習の結果を「観測」の欄に書いたときです。
4. 判断すること
受入確認を設計するときに人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 何を証明したいか（どの受入条件を、誰の立場で確かめるか） | 09-02のテストが見ていない5件（AC-005・006・007・009・011）を、業務の立場で見るのがこの記事の目的 | 不可。対象の受入条件を記事Aから引き、追加しない | テストで済んだ条件を二重に確かめ、画面を要する条件が抜ける |
| 期待値（期待結果）は誰が決めるか | 受入条件の期待結果は記事Aで業務の言葉で決まっている。実装や設計文書から決め直さない | 不可 | 設計文書の「そう作る予定」が期待結果になり、動いていないものが合格になる |
| 何を合格条件にするか（不合格条件を先に決める） | 確認の後に基準を決めると、都合よく合格にできる（第3.2節） | 不可。第5.2節のとおり先に決める | 些細な問題で不合格にしたり、重大な問題を見逃したりして判断がぶれる |
| 今の実装で観測できる範囲はどこまでか | 観測する対象（画面・処理）が無い受入条件は、確認できない。できないものを「できた」ことにしない | 可（観測できる部分だけを演習にし、残りを未確認とする） | 未実装の画面について合格を付け、10-04の判定が誤った材料の上に立つ |
| 未確認をどう扱うか（合格でも不合格でもなく） | 未確認は「判定できない」であり、不合格条件に「該当なし」でもない | 不可。未確認は未確認と書き、確認できる段階（画面完成後）と担当を添える | 未確認が「問題なし」と読まれ、限定試行に進む |
勝手に決めてはいけないこと：観測していないことを「確認済み」「合格」と書きません。設計文書の記述は、動作の観測の代わりにしません。この記事の確認者は実装者と同じAI（Claude Code）です。実装者以外の人が確認したかのように書きません（第8.1節）。02-04で整理した受入条件（AC-005、006、007、009、011）以外を、この記事で新たに追加しません。演習の結果を「観測」に格上げしません。
AIに任せる範囲：観測できる部分を確かめる演習コードの下書き、実行して出力をそのまま返すこと、受入確認記録の形への整理はAIに任せられます。任せてはいけないのは、不合格条件を決めること、演習と観測を区別すること、未確認をどう扱うかの判断、そして実際の受入確認そのもの（業務担当者が画面を操作して見ること）です。AIは画面を操作する業務担当者の代わりにはなれません。
5. 作って確かめる：受入確認の手順を作る
5.1 確認対象と、今の実装で観測できる範囲
02-04で「人が見る受入確認」に振り分けられた5件を対象にします。先に、現在の実装範囲（08-01の判定関数、08-02の保存処理、08-03の提出の連携）で、それぞれの受入条件の「操作」を実際に起こせるかを整理します。
| 受入条件 | 前提 | 操作 | 期待結果 | 今の実装で観測できるか |
|---|---|---|---|---|
| AC-005 | 佐藤の下書きで件名が空 | 佐藤が提出する | 拒否され、足りない項目が示される。下書きのまま | 一部だけ。08-02の保存処理は「件名が空の依頼を作る」段階で拒否するので、その拒否は観測できる。「件名が空の下書きを提出する」操作と、画面に足りない項目が示されることは、画面と提出時のチェックが無いため観測できない |
| AC-006 | 提出済みの依頼 | 鈴木が理由を空欄で差戻す | 拒否され、提出済みのまま | 観測できない（差戻しの処理・画面が未実装） |
| AC-007 | 佐藤と、他人（田中）の依頼 | 佐藤が田中の依頼を開こうとする | 表示されない、または権限がない旨が示される | 観測できない（一覧・閲覧の画面が未実装。08-03で観測した「他人の依頼を提出できない」は提出の権限であり、閲覧の権限ではない） |
| AC-009 | 佐藤の提出済み依頼と下書きの依頼がある | 佐藤が一覧を開き、下書きの件名を編集して保存する | 2件は異なるIDで表示され、編集後も同じIDのまま追える。もう一方には変更が及ばない | 観測できない（一覧・編集の画面が未実装） |
| AC-011 | 件名なしで差戻された依頼（差戻し中） | 佐藤が件名を書いて再提出する | 状態が提出済みに変わり、履歴に「再提出・佐藤・時刻」が1件追加される。前回の差戻しの履歴は残る | 観測できない（差戻し・再提出の処理が未実装） |
5.2 不合格条件（確認前に決める）
- 必須項目のチェックが働かず、空欄のまま提出・差戻しが完了してしまう（AC-005、006に対応）
- 権限のない依頼の内容（件名・内容など）が、画面に表示されてしまう（AC-007に対応）
- 一覧の編集によって、別の依頼のIDや内容が変わってしまう（AC-009に対応）
- 再提出によって、それ以前の履歴（差戻しの記録）が消えてしまう（AC-011に対応）
不合格条件は「観測して初めて該当・非該当が決まる」ものです。観測していない受入条件については、該当なしではなく「判定できない」と記録します。
5.3 観測できる部分を演習で確かめる（AC-005の一部）
AC-005のうち観測できる部分（件名が空の依頼が拒否されること）を、依頼者役（佐藤）の操作に相当する呼び出しで確かめます。画面が無いので、これは業務担当者による受入確認ではなく演習上の確認です。08-02の保存処理のコピー（storage.js）と、次のコード（examples/10-01-acceptance-record/run_ac005.js）を使います。
// 教材演習用：受入条件 AC-005（件名が空の依頼は提出できない：REQ-004）のうち、
// 現在の実装範囲（08-02の保存処理）で観測できる部分だけを、依頼者役の操作に相当する呼び出しで確かめる。
// 画面はまだ無いので、これは「受入確認」ではなく「演習上の確認」である（記事 第5.2節）。
const fs = require("node:fs");
const { createRequest, loadDb, DB_FILE } = require("./storage.js");
if (fs.existsSync(DB_FILE)) fs.unlinkSync(DB_FILE); // 演習用データを初期化
console.log("=== AC-005 演習上の確認（依頼者役：佐藤）===");
console.log("観測できる部分：件名が空の依頼を保存しようとしたときに拒否されるか（作成時の必須項目チェック）");
console.log("--- 操作1：件名を空にして依頼を作る ---");
let rejected = false;
try {
createRequest({ id: "REQ-0001", requester: "佐藤", title: "", content: "会議室の予約", approver: "鈴木" });
} catch (e) {
rejected = true;
console.log("拒否されました: " + e.message);
}
const after1 = loadDb();
console.log(`保存された依頼の件数: ${after1.requests.length}（期待: 0）`);
console.log("--- 操作2：件名を入れて依頼を作る（比較用） ---");
createRequest({ id: "REQ-0001", requester: "佐藤", title: "会議室の予約", content: "9/25 10時から", approver: "鈴木" });
const after2 = loadDb();
console.log(`保存された依頼の件数: ${after2.requests.length}（期待: 1）、状態: ${after2.requests[0].state}（期待: 下書き）`);
const ok = rejected && after1.requests.length === 0 && after2.requests.length === 1 && after2.requests[0].state === "下書き";
console.log("");
console.log(`観測結果: ${ok ? "期待どおり（作成時の必須項目チェックは働く）" : "期待と異なる"}`);
console.log("未確認のまま残る部分: 件名が空の下書きを「提出」したときの拒否、画面に足りない項目が示されること（画面と提出時のチェックは未実装）");
process.exit(ok ? 0 : 1);「入力→判断・処理→出力→失敗時」の対応：
| 段階 | 内容 |
|---|---|
| 入力 | 依頼者役（佐藤）の2つの操作：件名を空にした依頼の作成、件名を入れた依頼の作成 |
| 判断・処理 | 08-02の createRequest が必須項目（件名・内容・承認者）を確認する。保存先を読み直して件数と状態を見る |
| 出力 | 操作ごとの結果と、観測結果（期待どおりか）。終了コードは期待どおりなら 0 |
| 失敗時 | 期待と異なれば終了コード 1。あわせて、このコードでは確かめられない部分（提出時の拒否、画面表示）を必ず表示する |
6. 実行結果（受入確認記録）
演習コードを examples/10-01-acceptance-record/ で実行した stdout です（整形・省略なし。stderr への出力はありませんでした）。
$ node run_ac005.js
=== AC-005 演習上の確認（依頼者役：佐藤）===
観測できる部分：件名が空の依頼を保存しようとしたときに拒否されるか（作成時の必須項目チェック）
--- 操作1：件名を空にして依頼を作る ---
拒否されました: 必須項目が不足しています（件名・内容・承認者）
保存された依頼の件数: 0（期待: 0）
--- 操作2：件名を入れて依頼を作る（比較用） ---
保存された依頼の件数: 1（期待: 1）、状態: 下書き（期待: 下書き）
観測結果: 期待どおり（作成時の必須項目チェックは働く）
未確認のまま残る部分: 件名が空の下書きを「提出」したときの拒否、画面に足りない項目が示されること（画面と提出時のチェックは未実装）
終了コード: 0この結果を受入確認記録にまとめます。確認の種別は「観測（画面を使った受入確認）」「演習（コードの呼び出しによる確認）」「未確認（観測する対象が無い）」の3つです。この記事の時点で「観測」に入る行はありません。
| 受入条件 | 確認者の役割 | 操作 | 結果 | 確認の種別 | 合否 | 不合格条件への該当 |
|---|---|---|---|---|---|---|
| AC-005 | 依頼者役（佐藤。実施はClaude Code） | 件名を空にして依頼を作る／件名を入れて依頼を作る | 空の依頼は拒否され保存されない。件名があれば下書きとして保存される（第6節の実行結果） | 演習（作成時のチェックのみ） | 判定保留（提出時の拒否と画面表示が未確認） | 作成時については該当なし。提出時については判定できない |
| AC-006 | 承認者役（鈴木） | 差戻し理由を空欄のまま差戻す | 実施していない（差戻しの処理・画面が無い） | 未確認 | 判定できない | 判定できない |
| AC-007 | 依頼者役（佐藤） | 他人（田中）の依頼を開く | 実施していない（一覧・閲覧の画面が無い） | 未確認 | 判定できない | 判定できない |
| AC-009 | 依頼者役（佐藤） | 一覧で下書きの件名を編集して保存する | 実施していない（一覧・編集の画面が無い） | 未確認 | 判定できない | 判定できない |
| AC-011 | 依頼者役（佐藤） | 差戻された依頼に件名を書いて再提出する | 実施していない（差戻し・再提出の処理が無い） | 未確認 | 判定できない | 判定できない |
見つかった事項（対処先は第8.1節）：
| 事項 | 種類 | 対処先 |
|---|---|---|
08-02の保存処理は作成時に必須項目を確認するが、提出時（submitRequest）には確認しない。AC-005の「下書きを提出したときに拒否される」は今の実装では保証されない | 設計どおりに実装されていない可能性（提出時の確認は04-04・02-04の想定） | 08-02へ戻して修正を検討する。または画面側の実装時に提出前チェックとして扱う |
| AC-006・007・009・011は観測する対象（差戻し・再提出・一覧・閲覧・編集の処理と画面）が無い | 実装の未完了（問題ではなく、確認の前提が整っていない） | 画面ができた段階で、この記事と同じ手順で確認する。10-04には「未確認」として渡す |
7. 確認結果
実行環境：macOS 26.6.2、Node.js v24.18.0（node:fs・node:path のみ使用）、2026-09-20に実行。実行場所は examples/10-01-acceptance-record/。stdout・stderr・終了コードをそのまま記録した実行記録は第9節の run_log.md にあります。受入確認記録の作成日：2026-09-20。
| 手順 | 期待結果 | 実際の結果 | 一致 |
|---|---|---|---|
node run_ac005.js 操作1（件名が空） | 拒否され、保存された依頼は0件 | 拒否されました: 必須項目が不足しています（件名・内容・承認者）、件数0 | 一致 |
| 同 操作2（件名あり） | 下書きとして1件保存される | 件数1、状態「下書き」 | 一致 |
| 終了コード | 0 | 0 | 一致 |
完了条件との照合：
| 完了条件 | 確認結果 |
|---|---|
| 各受入条件に確認者の役割と結果がある | 第6節の表に記載。結果が「実施していない」の行も、その理由とともに記載 |
| 不合格条件が事前に書かれている | 第5.2節に記載（確認前に決定） |
| 問題の対処先が決まっている | 第6節の「見つかった事項」と第8.1節に記載 |
残る制限：この記事で受入確認済み（合格）にできた受入条件はありません。AC-005は作成時のチェックだけを演習で確かめたもので、提出時の拒否と画面表示は未確認です。AC-006・007・009・011は未確認です。確認者は実装者と同じAI（Claude Code）であり、実装者以外の人（業務担当者役を含む）による確認は行っていません。実際に画面が完成した後で、業務担当者がこの記事と同じ手順で確認する必要があります。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 見つかった問題を、修正・運用対応・受入条件の見直しのどれで扱うか
| 問題の種類 | 扱い方 |
|---|---|
| 設計どおりに実装されていない（実装の誤り・未完了） | 修正（該当する記事の実装に戻す）。今回：提出時の必須項目チェックが無い件は08-02へ |
| 設計どおりだが、業務上使いにくい（設計の不備） | 受入条件の見直し、または該当する設計記事（04系）に戻す |
| 設計・実装は問題ないが、運用でカバーすべき事項 | 運用対応（10-03の利用手順書、12系の運用記事で扱う） |
| 観測する対象が無く、判定できない | 問題として扱わず「未確認」のまま10-04へ渡す。画面ができた段階で再確認する |
この記事の確認者は、実装した本人と同じAI（Claude Code）です。09-04で確認したとおり、同じAIによる確認は独立した保証になりません。演習で観測した事実（拒否された、件数が0だった）は誰が見ても同じですが、「その観測で十分か」「業務として使えるか」の判断は、実装者以外の人（業務担当者）が行う必要があります。
8.2 「設計した」と「そのとおりに動く」は別
初版のこの記事は、設計文書（04-02、04-04）を読み返して5件すべてに「合格」を付けていました。それは受入確認ではなく、設計文書の自己照合です。「配置できた」と「使える」が別であるのと同じく、「設計した」と「そのとおりに動く」は別のことです。観測する対象が無いなら、合格でも不合格でもなく「未確認」と書く。それが、10-04で誤った利用開始判定をしないための前提になります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 受入確認記録ひな形（確認者の役割、受入条件、操作、結果、確認の種別、合否、不合格条件、対処） | templates/10-01-acceptance-record_template.md | templates/10-01-acceptance-record_example.md |
| AC-005の演習コード（08-02の保存処理のコピーを含む） | examples/10-01-acceptance-record/（run_ac005.js、storage.js） | 同上 |
| 実行記録（stdout・stderr・終了コード、整形なし） | — | evidence_public/remediation1-2026-09-20/10-01/run_log.md |
自分の業務に使うときの手順は次のとおりです。
- 機械的なテストで確認していない受入条件を洗い出す
- 依頼者役・承認者役などの立場を決め、不合格条件を確認前に決める
- 受入条件ごとに、今の実装で操作を実際に起こせるかを整理する
- 起こせるものは実際に操作して結果を記録し、起こせないものは「未確認」と書く（設計文書の記述を結果の代わりにしない）
- 見つかった問題を、修正・運用対応・受入条件の見直しのどれで扱うか判断する
10. 次工程への受渡し
次へ渡すもの：受入確認記録（合格0件、演習による判定保留1件、未確認4件）、見つかった事項（提出時の必須項目チェックが無い件）。
次工程での使われ方：10-04（利用開始の可否を判断する）では、この記録を判定材料の1つとして使います。合格が0件・未確認が4件である事実は、10-04の判定区分（演習成功。限定試行は延期条件付き）に直接影響しています。
前工程へ戻る条件：受入条件そのものの見直しが必要な場合は、02-04に戻して確認します。提出時の必須項目チェックが無い件は08-02へ戻します（08-02では提出前のガードで対象の存在と状態を確かめる形にしましたが、件名が空の下書きを提出したときの拒否は、この記事の時点では未確認のままです）。
11. 根拠と更新情報
- この記事の会社・人物・データはすべて架空の設定です。
- 確認対象の受入条件（AC-005、006、007、009、011）とその振り分けは、02-04・記事A第5.5節に基づきます。
- 画面設計の参照先は04-02（画面の原型）・04-04（例外時の画面・表示ルール）です。ただし、設計文書の記述は確認結果の根拠にしていません。
- 制作の来歴：本文はClaude Codeが作成しました。第5.3節・第6節の演習コードは
examples/10-01-acceptance-record/を正本とし、2026-09-20にmacOS 26.6.2・Node.js v24.18.0の環境で実際に実行して、stdout・stderr・終了コードをevidence_public/remediation1-2026-09-20/10-01/run_log.mdに記録しています。受入確認記録の確認者は実装者と同じAI（Claude Code）です。人（ユーザー）による実読・内容確認、実装者以外の人による受入確認は未実施です。 - 2026-09-20（Remediation Phase 1）：受入監査で「設計文書を読み返して5件すべてを合格とした受入確認は、受入確認の実体がない」と指摘された。観測できる部分（AC-005の作成時チェック）だけを演習コードで実際に確かめ、残りを未確認とする記録に作り直した。受入条件・不合格条件は変えていない。
- 2026-09-20（Phase 5B-2B）：読む順路（3つの深さ）、第3.2節の「演習で確かめたから合格」の誤解、第3.3節「実際の受入確認と机上演習の違い」、第4節の判断項目、POINT、CHECKLIST、記事間の参照を追加した。受入確認記録（合格0件・演習1件・未確認4件）・不合格条件・演習コード・実行結果・実行記録（Remediation Phase 1）は変えていない。
- 未確認事項：AC-005の提出時の拒否と画面表示、AC-006・007・009・011の全部は、この記事の時点では確認していません。実装者以外の人による確認も行っていません。