# 受入確認記録ひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「受入確認を、確認できたもの・演習で確かめたもの・未確認のものに分けて記録する」（10-01）の本文で実際に確認した内容をまとめたもの。空欄版は `10-01-acceptance-record_template.md`。
この記事の時点では実際に動く画面が無いため、「観測（画面を使った受入確認）」に入る行は無い。確認者は実装者と同じAI（Claude Code）であり、実装者以外の人による確認は未実施。

## 1. 不合格条件（確認前に決める）

- 必須項目のチェックが働かず、空欄のまま提出・差戻しが完了してしまう
- 権限のない依頼の内容が、画面に表示されてしまう
- 一覧の編集によって、別の依頼のIDや内容が変わってしまう
- 再提出によって、それ以前の履歴が消えてしまう

## 2. 受入確認記録

確認の種別：観測（画面を使った受入確認）／演習（コードの呼び出しによる確認）／未確認（観測する対象が無い）

| 受入条件 | 確認者の役割 | 操作 | 結果 | 確認の種別 | 合否 | 不合格条件への該当 |
|---|---|---|---|---|---|---|
| AC-005 | 依頼者役（佐藤。実施はClaude Code） | 件名を空にして依頼を作る／件名を入れて依頼を作る | 空の依頼は拒否され保存されない。件名があれば下書きとして保存される（`examples/10-01-acceptance-record/run_ac005.js`、終了コード0） | 演習（作成時のチェックのみ） | 判定保留（提出時の拒否と画面表示が未確認） | 作成時については該当なし。提出時については判定できない |
| AC-006 | 承認者役（鈴木） | 差戻し理由を空欄のまま差戻す | 実施していない（差戻しの処理・画面が無い） | 未確認 | 判定できない | 判定できない |
| AC-007 | 依頼者役（佐藤） | 他人の依頼を開く | 実施していない（一覧・閲覧の画面が無い） | 未確認 | 判定できない | 判定できない |
| AC-009 | 依頼者役（佐藤） | 一覧で下書きの件名を編集して保存する | 実施していない（一覧・編集の画面が無い） | 未確認 | 判定できない | 判定できない |
| AC-011 | 依頼者役（佐藤） | 差戻された依頼に件名を書いて再提出する | 実施していない（差戻し・再提出の処理が無い） | 未確認 | 判定できない | 判定できない |

## 3. 見つかった事項と対処先

| 事項 | 種類 | 対処先 |
|---|---|---|
| 08-02の保存処理は作成時に必須項目を確認するが、提出時には確認しない | 設計どおりに実装されていない可能性 | 08-02へ戻して修正を検討する |
| AC-006・007・009・011は観測する対象が無い | 実装の未完了（確認の前提が整っていない） | 画面ができた段階で同じ手順で確認する。10-04には「未確認」として渡す |

## 4. 完了条件の確認

- [x] 各受入条件に確認者の役割と結果がある（「実施していない」の行も理由とともに記載）
- [x] 不合格条件が事前に書かれている
- [x] 問題の対処先が決まっている

## 5. 次工程へ渡すもの

- [x] 受入確認記録（第2節：合格0件、判定保留1件、未確認4件）と見つかった事項（第3節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い