テスト・レビュー学習記事全11節Verify
承認処理の修正差分を、実装者以外の観点でレビューする
この記事で身につくこと実装者自身の確認と別の観点の確認を区別する理由と、AIの再確認が独立した保証にならないことを説明できる。
記事内目次（19項目）
この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。本文のレビューは、08-04で実際に作成した修正差分を対象に行った記録です（第7節）。ただし、このレビューを行ったのも実装者と同じAI（Claude Code）であり、実装者以外の人による確認ではありません（第8.1節）。
この記事は何の話か。承認処理の修正差分（08-04）を対象に、要件との対応・権限・履歴・秘密情報の混入という観点でレビューを行い、指摘と対応をレビュー記録に、未対応を残課題一覧にまとめる話です。
なぜ必要か。実装した本人（またはAI）だけの確認では、見落としに気づきにくい場合があります。別の観点からの確認を記録に残すことで、見落としを減らし、対応状況を追跡できるようにします。ただし、この教材では実装者以外の人によるレビューを再現できていません。この記事のレビューは実装者と同じAIによる自己レビューであり、その限界を隠さずに書くことも、この記事の目的です。
この記事を読むとできるようになること。
- 実装者自身の確認と別の観点の確認を区別する理由を説明できる
- 修正差分について、複数のレビュー観点で指摘と対応をレビュー記録にまとめられる
- レビューに人を割く範囲を、変更の影響の大きさと費用から判断できる
- 自己レビューでできることと独立レビューでしか補えないことを分け、実務で誰にどう依頼して独立性を確保するかを言える
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（実装者自身の確認と別の観点、自己レビューと独立レビューの違い）→第4節（判断すること）→第6節のレビュー記録と残課題→第9節。ここまでで、レビュー記録の形と、「同じAIによる確認」がどこまで有効かが分かります。
- 作って確かめる：上に加えて第5節（対象差分・観点・AIにレビューを頼む場合の限界）→第7節（確認結果と、この記事が再現できていないこと）。
- 設計判断を深める：上に加えて第8節（独立性の確保、人を割く範囲の判断）。
1. 今回の業務課題と完成するもの
この記事でやることは、08-04で作成した承認処理の修正差分（部分失敗の扱いの修正）について、要件との対応・権限・履歴・秘密情報の混入という4つの観点でレビューを行い、指摘と対応をレビュー記録に、未対応を残課題一覧にまとめることです。
記事B（09-02）・09-03では実装者自身が動かして確認する検証を行いましたが、別の観点からの確認はまだ扱っていませんでした。この記事では、それを扱います。ただし、この教材の制作体制では実装者以外の人がいないため、実際に行えるのは「同じAIが、決めた観点で自己レビューする」ところまでです（第3.3節）。
この記事を読み終えると、次のものが手元にできます。
- レビュー記録・残課題一覧（対象差分、観点、指摘、対応、確認者、残課題、影響、対処予定）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
レビュー
一言でいうと、実装した本人以外の視点で、成果物を確認することです。
変更の影響
一言でいうと、その変更によって、どこまでの範囲が変わりうるかということです。たとえば、08-04の修正は、承認処理の戻り値の形（successの意味）を変えたため、その戻り値を使う画面側にも影響します。
残るリスク
一言でいうと、レビューで指摘したが、その場では対応しなかった（対応を先送りにした）事項です。
これがないと、実装した本人の確認だけで「問題ない」と判断してしまい、別の視点からなら気づけたはずの見落としを残したまま次の工程に進んでしまいます。
読む順路：検証は記事B（09-02）・09-03、変更履歴は06-03、レビュー対象の修正は08-04が該当します。この記事のレビュー記録は、10-01（受入確認）、10-04（利用開始の可否を判断する）で使います。
3. 理解する：実装者自身の確認と別の観点の確認
3.1 なぜ実装者以外の確認が必要か
実装した本人（人でもAIでも）は、自分が想定した使い方の範囲では正しく動くことを確認できますが、想定していなかった使い方や、別の要件との整合性には気づきにくいことがあります。別の観点からの確認は、この見落としを減らすためのものです。
3.2 よくある誤解
「AIにもう一度確認させれば、レビューをしたことになる」。実装したAIに再度確認させても、同じ前提・同じ見落としを繰り返す可能性があります。これは独立した保証にはなりません（第8.1節）。この記事のレビューも、実装者と同じAI（Claude Code）が行ったものであり、この限界の具体例です。
「レビューで指摘がなければ、問題がないということ」。レビューは、決めた観点の範囲でしか確認していません。観点に含めなかった問題は見つかりません（第8.2節）。
「別のAIサービスに聞けば独立レビューになる」。渡す資料と指示が同じなら、別のモデルでも同じ前提を引き継ぎます。独立性は「誰が」だけでなく「何を前提にしているか」で決まります（第3.3節）。
3.3 自己レビューと独立レビューは別のもの
結論から言うと、レビューの価値は「見る人が違うこと」ではなく「前提が違うこと」から生まれます。同じ前提で見直しても、前提の中の見落としは見つかりません。
みらい業務サービスの例で言うと、08-04の修正を書いたAIは「履歴の書き込み失敗を伝える」ことを目的に実装しました。同じAIが同じ資料でレビューすると、「伝えているか」は確かめられますが、「伝えたとしても状態だけ変わったデータが残る」という、目的の外にある問題には気づきにくくなります。第6節でその指摘が出ているのは、観点に「不変条件」を入れたからで、観点を決めた時点で見落とす可能性は残っています。
| 観点 | 自己レビュー（実装者と同じ人・AI） | 独立レビュー（実装者以外の人、または別の前提） |
|---|---|---|
| できること | 決めた観点との照合、記述漏れ・矛盾の発見、実行結果の再確認 | 実装者が想定しなかった使い方・要件との不整合・前提そのものの誤りの発見 |
| できないこと | 前提の中の見落とし。「そう作った理由」を疑うこと | — |
| 独立と言える条件 | — | 実装者と別の人であること。渡される資料が「実装の説明」ではなく「要件・設計」であること。実装者の結論を先に見ないこと |
| AIに頼む場合 | 同じ会話（コンテキスト）・同じモデル・同じ作成者の指示なら自己レビュー | 別の人が、要件・設計だけを渡して「この実装は要件を満たすか」を問う形なら、独立性に近づく。ただしAIは業務の責任を持てないため、最終判断は人 |
| この教材で再現できるか | できる（この記事） | できない。実装者以外の人がいない |
| 実務では誰に依頼するか | — | 業務の責任者（要件を決めた人）、別の開発者、テスト担当。権限・承認・履歴に関わる変更は必ず人（第8.2節） |
「AIにもう一度確認させた」は、同じ会話・同じモデル・同じ作成者である限り、自己レビューです。それは無意味ではありませんが（この記事の第6節が示すとおり、観点を決めれば指摘は出ます）、独立レビューの代わりにはなりません。
4. 判断すること
レビューを設計するときに人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 何をレビュー対象にするか（差分の範囲） | 範囲が曖昧だと、見ていない部分まで「レビュー済み」になる | 不可。対象差分を明記する | 08-04以外の変更（08-02のガードなど）が未レビューのまま「済み」扱いになる |
| どの観点で見るか | 観点に無い問題は見つからない（第3.2節）。要件・権限・履歴・秘密情報に加え、不変条件を入れるかで結果が変わる | 可（この記事は5観点。変更の性質で足す） | 「伝えているか」だけを見て、不変条件が破れたデータが残ることを見落とす |
| 誰がレビューするか（自己か独立か） | 独立性の有無で、レビューが保証するものが変わる（第3.3節） | 不可。誰が行ったかを記録に書き、独立でないなら独立でないと書く | 同じAIの再確認が「第三者レビュー済み」として次工程へ渡る |
| 指摘を「対応」するか「残課題」にするか | 残課題にする場合、影響と対処予定が要る。放置と区別する | 可（影響が中以下で、対処先が決まっていれば残課題にできる） | 残課題が対処先で回収されず消える（第6節の引き継ぎ先の確認） |
| 独立レビューを、この教材で再現するか、未実施と書くか | 実装者以外の人がいない教材では再現できない。捏造は最悪の選択 | 不可。未実施は未実施と書く | 架空の第三者レビューが「実施済み」として10-04の判定材料になる |
勝手に決めてはいけないこと：このレビューを、実装者以外の人によるレビューであるかのように書きません。指摘した残課題を、対応済みであるかのように書きません。実装者以外のレビューを、この記事で「行った」ことにしません。
AIに任せる範囲：差分の要約、観点ごとの照合の下書き、レビュー記録の形への整理はAIに任せられます。しかし、レビュー観点を決めること、指摘を対応するか残課題にするかの判断、そして「このレビューは独立か」の判断は人が行います。AIにレビューを頼む場合の限界は第5.3節に書きます。
5. 作って確かめる：修正差分をレビューする
5.1 対象差分
08-04で作成した修正差分を対象にします。
| 項目 | 修正前（storage_v1.js） | 修正後（storage_v2.js） |
|---|---|---|
| 履歴の書き込みが失敗した場合の戻り値 | { success: true, state: "提出済み" } | { success: false, state: "提出済み", partial: true, error: "..." } |
| 失敗の記録 | なし | 失敗ログ（対象ID・操作者・時刻・エラー種別・状況の説明） |
| 保存先の状態と履歴 | 状態「提出済み」・履歴なし | 同じ（状態「提出済み」・履歴なし） |
対象は08-04の storage_v1.js → storage_v2.js の差分だけです。08-02の保存処理・ガード、08-03の連携は、この記事のレビュー対象ではありません。
5.2 レビュー観点
- 要件との対応：REQ-005〜007（部分失敗を正常完了として扱わない）を満たしているか
- 権限：修正によって、権限のない操作が新たに許可される変化がないか
- 履歴：失敗時にも、原因調査に必要な情報が記録として残るか
- 秘密情報の混入：失敗ログに、パスワードなど残してはいけない情報が含まれていないか
- 不変条件：修正後の保存先が、記事Aの不変条件（承認済みには承認履歴が必ず1件以上ある）を満たしているか
5.3 AIにレビューを頼む場合の限界
この記事のレビューは、08-04を実装したのと同じAI（Claude Code）が、同じ作業の流れの中で行いました。これは第3.3節の「自己レビュー」に当たります。AIにレビューを頼むこと自体は有効ですが、次の3つが同じである限り、独立レビューにはなりません。
| 同じもの | なぜ独立でないか | 独立性に近づけるには |
|---|---|---|
| 同じ会話（コンテキスト） | 実装の意図・「そう作った理由」をAIが既に持っており、その前提で見る | 実装の説明を渡さず、要件・設計・差分だけを新しい会話で渡す |
| 同じモデル | 同じ傾向の見落としを繰り返す可能性がある | 別のモデルでも、渡す資料が同じなら前提は同じ。資料の独立性のほうが重要 |
| 同じ作成者（指示を書く人） | 指示に実装者の想定が入り、観点がその範囲に閉じる | 要件を決めた人（業務の責任者）が観点と指示を書く |
この教材では、いずれも同じままです。したがってこの記事は「自己レビューの記録」であり、実装者以外の人によるレビューは未実施として次工程へ渡します（第7節・第8.1節）。
6. 実行結果（レビュー記録・残課題一覧）
確認者はすべて「Claude Code（実装者と同一。自己レビュー。第3.3節・第5.3節）」です。
| 対象差分 | 観点 | 指摘 | 対応 | 確認者 |
|---|---|---|---|---|
| 08-04 storage_v1.js→v2.js | 要件との対応 | 履歴の書き込み失敗時にsuccess: falseを返すようになっており、REQ-007の「片方だけの結果を正常完了として扱わない」という報告の条件は満たす。ただし保存先には状態だけ変わった依頼が残る（不変条件の行を参照） | 報告については対応不要。保存先については未対応（残課題2） | Claude Code（自己レビュー） |
| 同上 | 権限 | 修正前後で、権限判定（canApproveなど）自体は変更しておらず、新たに許可される操作はない | 対応不要 | 同上 |
| 同上 | 履歴 | 失敗時に対象ID・操作者・時刻・エラー種別・状況の説明を失敗ログに残しており、原因調査に必要な最低限の情報がある | 対応不要 | 同上 |
| 同上 | 秘密情報の混入 | 失敗ログの記録項目（requestId、actor、at、errorType、note）にパスワード等の秘密情報は含まれていない | 対応不要 | 同上 |
| 同上 | 不変条件（状態のロールバック） | 履歴の書き込みが失敗しても、状態（state）は「提出済み」のまま変更されない。記事Aの不変条件「承認済みには承認履歴が必ずある」に照らすと、修正後も破れたまま。状態を元に戻す（ロールバックする）処理は実装していない | 未対応（残課題2） | 同上 |
残課題一覧：
| 番号 | 残課題 | 影響 | 対処予定と、実際に回収している記事 |
|---|---|---|---|
| 1 | 実装者以外の人による確認が行われていない | 見落としがあっても、この記事の時点では気づけない可能性がある。影響：中（利用開始前に人による確認が必要） | 10-01の受入確認も確認者は同じAIであり、実装者以外の人による確認は未実施のまま。10-04で「延期（画面完成後、業務担当者による受入確認とあわせて行う）」として扱われている。この教材の範囲では回収されない |
| 2 | 履歴の書き込み失敗時に状態をロールバックしない設計（不変条件の違反） | 状態と履歴が不整合なデータが残る。影響：中（頻度は低いが、発生した場合は運用対応が必要） | 設計としての解決は記事B（トランザクション。T6で途中失敗時に状態も履歴も元に戻ることを確認）。この題材アプリ（JSONファイル保存）への適用は未決。10-04では「演習の範囲では受容。限定試行へ進む前に扱いを決める（12-02）」とされているが、12-02の本文はこの時点（2026-09-20）でこの残課題を扱っておらず、未回収。2026-09-21 追記：その後 12-02 が更新され、12-02第8.3節で「初動（見え方・確認・暫定対応・影響範囲・切戻しの要否）」は回収、「不整合データの直し方」と「トランザクション設計の題材アプリへの適用」は未決と整理された |
残課題2の引き継ぎ先について：初版のこの記事は「12-02で検討する」としていましたが、12-02の本文を確認したところ、この残課題は扱われていません。引き継ぎ先を書くだけでは回収されない、という例として残します。2026-09-21 追記：その後 12-02 が更新され、初動の範囲は回収されました。データの扱いと設計の適用は12-02の時点でも未決です（12-02第8.3節）。この記事の時点で回収の見込みがあるのは、記事Bのトランザクション設計を題材アプリへ適用する判断だけです。
7. 確認結果
実行環境：本節は文書によるレビューであり、コードの実行は伴いません。レビューの実施日：2026-09-20。レビューの種別：自己レビュー（実装者と同じAI、同じ会話、同じ作成者。第5.3節）。
完了条件との照合：
| 完了条件 | 確認結果 |
|---|---|
| 実装者以外の確認者（または別観点）が明記されている | 実装者以外の確認者はいない（未実施）。別観点（要件・権限・履歴・秘密情報・不変条件の5観点）を第5.2節に明記し、第6節の「確認者」欄に自己レビューであることを明記 |
| 指摘ごとに対応状況がある | 第6節の表の「対応」欄に記載 |
| 残課題に影響の大きさが書かれている | 第6節の残課題一覧の「影響」欄に記載 |
残る制限：このレビューは、実装したAI（Claude Code）自身が、同じ会話・同じ資料で行った自己レビューであり、実装者以外の人による確認ではありません。この教材の制作体制では独立レビューを再現できず、未実施のまま次工程へ渡します。この教材で確かめたこと：決めた5観点との照合で、指摘4件（対応不要）と1件（未対応）が出ること。確かめていないこと：観点の外にある問題、実装者以外の前提で見たときに出る指摘。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 AIの再確認が独立した保証にならない理由と、独立性の確保
このレビューは、08-04を実装したのと同じAI（Claude Code）が行いました。同じ前提や見落としを、レビューでも引き継いでしまう可能性があるため、これは実装者以外の視点による確認とは言えません（第3.3節・第5.3節）。
実務で独立性を確保するには、次の順で考えます。
| 手段 | 独立性 | 費用 | この題材での適用 |
|---|---|---|---|
| 要件を決めた人（業務の責任者）が、要件との対応を見る | 高い（実装の前提を持たない） | 責任者の時間 | 総務課長（架空）による受入確認。画面が無いため未実施（10-01） |
| 別の開発者・テスト担当が、要件・設計・差分だけを見て指摘する | 高い | 別の担当者が要る | この教材の体制には存在しない |
| AIに、実装の説明を渡さず要件・設計・差分だけを新しい会話で渡す | 中（資料の独立性はあるが、責任は持てない） | 小さい | 未実施。行う場合も「独立レビューに近づける工夫」であり、人のレビューの代わりではない |
| 同じAIが同じ会話で再確認する（この記事） | 低い（自己レビュー） | 最小 | 実施済み。観点との照合としては有効 |
この教材では最下段までしか行えていません。実装者以外の人による確認は、10-04の「限定試行へ進む条件」に含まれており、それまでは未実施として扱います。
8.2 レビューに人を割く範囲を判断する
| 変更の種類 | 例 | 人によるレビューの要否 |
|---|---|---|
| 権限・承認・履歴に関わる変更 | 08-04のような部分失敗の扱いの変更 | 必ず人が見る（影響が大きく、見落としの影響も大きいため） |
| 表示文言だけの変更 | エラーメッセージの言い回しの変更 | 必ずしも人が見なくてよい（影響が小さいため） |
この記事の教材演習では、権限・承認・履歴に関わる変更（08-04）を、必ず人が見る変更の基準としています。ただし「必ず人が見る」と決めた変更を、この教材では人が見ていません。基準と実施状況を分けて記録することが、次工程（10-04）の判定を誤らせないために必要です。表示文言だけの変更のような、影響が小さい変更まで一律に人のレビューを必須にすると、確認の費用が増え、重要な変更の確認が手薄になる可能性があります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| レビュー記録・残課題一覧ひな形（対象差分、観点、指摘、対応、確認者、残課題、影響、対処予定） | templates/09-04-review-record_template.md | templates/09-04-review-record_example.md |
自分の業務に使うときの手順は次のとおりです。
- レビューの対象差分を決める
- レビュー観点（要件との対応、権限、履歴、秘密情報の混入など）を決める
- 観点ごとに指摘と対応をレビュー記録に書き、確認者を明記する
- 未対応の指摘を残課題一覧にまとめ、影響の大きさと対処予定を書く
- レビューが自己レビューか独立レビューかを記録し、独立レビューが未実施なら未実施と書く
- 残課題の引き継ぎ先が、実際にその課題を扱っているかを確認する
10. 次工程への受渡し
次へ渡すもの：レビュー記録・残課題一覧。
次工程での使われ方：10-01（受入確認）では、この残課題一覧を踏まえて受入確認を行いますが、確認者は同じAIであり、実装者以外の確認はそこでも未実施です。10-04（利用開始の可否を判断する）では、この記録（自己レビューであること、残課題2件）を判定材料の1つとして使い、独立した確認が無いことを判定区分を下げる材料にしています。
前工程へ戻る条件：レビューで見つかった指摘が08-04の実装そのものの誤りである場合は、08-04に戻って修正します。残課題2（不変条件）を題材アプリで解決すると決めた場合は、記事Bの設計を08-02へ適用する作業に戻ります。
11. 根拠と更新情報
- この記事の会社・人物・データはすべて架空の設定です。
- レビュー対象の差分は08-04に基づきます。
- 制作の来歴：本文はClaude Codeが作成しました。第5〜7節のレビューは、2026-09-20にClaude Codeが08-04の差分を確認して記録したものです。ただし、これは実装者と同じAIによる確認であり、人（ユーザー）による実読・内容確認、および実装者以外の人によるレビューは未実施です（第8.1節）。
- 自己レビューと独立レビューの区別、「同じAIの再確認は独立した保証にならない」という原則は、
docs/content/LEARNING_UNIT_SPEC_V1.md第1節・第6節と、記事Bに基づきます。 - 2026-09-20（Phase 5B-2B）：受入監査で「実装者以外の視点がテーマなのに、実際には同じAIがレビューしている」と指摘された。第3.3節「自己レビューと独立レビューは別のもの」、第5.3節「AIにレビューを頼む場合の限界」、第8.1節の独立性の確保の表を追加し、第6節の確認者欄と第7節を自己レビューであると明記した。要件との対応の指摘を、不変条件の観点で「報告は満たすが保存先は満たさない」に修正した。残課題2の引き継ぎ先（12-02）が実際には扱っていないことを確認して記載し、解決の見込みを記事Bのトランザクションに改めた。残課題1の引き継ぎ先（10-01）も同じAIによる確認であることを明記した。読む順路、第4節の判断項目、POINT、CHECKLIST、記事間の参照を追加した。
- 2026-09-21（Final Content Audit）：第6節の残課題2の引き継ぎ先について「12-02 は扱っていない」と書いていたが、その後 12-02（Phase 5B-2C1）が初動の範囲を回収したため、追記で回収状況を示した。当時の記述は事実として残している。
- 未確認事項：実装者以外の人による確認は、この記事の時点でも、10-01の時点でも行っていません。10-04の「限定試行へ進む条件」として延期されています。