このユニットの結論
コードレビューは、誤字や書き方の好みを直す場ではありません。
「頼んだ変更が、頼んだ範囲で、正しく行われ、ほかを壊していないか」を、変更の差分（変わった部分）を見て人が確かめる工程です。
AIが書いたコードでも、この確認は省けません。
1. 何の話か
このユニットは、プログラムの変更を確かめるコードレビューの話です。
コードレビューでは、変更した人とは別の人が、変更の差分（変更前と変更後で違う部分）を読み、問題がないかを確かめます。
2. なぜ必要か
プログラムの変更は、少しの書き間違いでも、
- 計算の結果が変わる
- 見てはいけない人がデータを見られるようになる
- 別の画面や連携が動かなくなる
といった影響を生みます。変更した本人は、自分の思い込みに気づきにくいものです。
自動テストも大切ですが、テストは「用意したことを確かめる」ものです。テストが用意していない問題は、テストが全部合格していても見つかりません。
3. このユニットで分かること
- レビューで見る観点
- 差分の大きさとレビューの関係
- AIが書いたコードをレビューするときの注意
4. レビューで見る観点
一般的には、次の観点で見ます。
- 目的：頼んだ変更の目的と、実際の変更が合っているか
- 範囲：頼んでいない場所まで変えていないか
- 正しさ：条件の抜け、計算の誤り、例外のときの動きはどうか
- 影響：ほかの画面・処理・連携に影響しないか
- 安全：権限の確認、個人情報の扱い、ログの残し方
- 確かめ方：変更に合わせたテストがあるか
差分が大きすぎると、人は細部を読み飛ばします。変更を小さく分けることも、レビューの質を保つ方法の一つです。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の開発に関係する記載
- 約120人規模のプロジェクト
- システムに SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェントがある
- AIは意思決定責任者ではなく、人間が管理する作業実行・支援手段とする
- AIへ最終委任しないことに「設計承認」「本番移行承認」がある
- P-013 木村 亮 — AIガバナンス責任者
アステリア案件のレビューの規則（誰が、どの変更を、何人でレビューするか）は、正本に記載がありません。未確定
5. THINK — 「軽い修正です」
変更の説明には「画面の表示の文言を直す軽い修正です」と書かれていました。差分を開くと、文言の変更に加えて、権限を確かめる処理の条件が1行変わっていました。
問題
説明どおり「軽い修正」として承認してよいでしょうか。
判断例を開く
判断
承認しません。
確認すること:
- 権限の条件の変更は、頼まれた変更に含まれていたか
- 変更によって、誰が何を見られるようになったか
- この変更を確かめるテストがあるか
- 変更した理由を、変更した人（またはAI）の説明ではなく、差分と要件で確かめたか
説明文ではなく、差分そのものを見るのがレビューです。
6. よくある失敗
- 変更の説明文だけを読んで承認する
- 大きな差分を、時間がないからと流し読みする
- テストが合格していることを、正しさの証明とみなす
- レビューで見つけた指摘を記録せず、同じ誤りを繰り返す
7. 成果物との接続
- DEV-002 開発・レビュー標準：レビューの観点と進め方を決める
- AI-003 AI変更実行記録：AIが行った変更の記録
- AI-004 AI変更承認チェックリスト：AIの変更を承認する前に確かめる項目
危機演習 CR11 では、AIによる変更をどう確かめるかを体験します（学習上の接続です。正式な対応関係ではありません）。
8. AI WORKFLOW — レビューの下読みをさせる
AIは、大きな差分の下読みに役立ちます。
指示例:
「次の差分を読み、変更された箇所を『頼まれた変更に関係するもの』『関係が判断できないもの』に分け、それぞれ差分の該当箇所を示してください。安全に関わる変更（権限・個人情報・ログ）があれば必ず挙げてください。問題がないとは結論づけないでください。」
9. REVIEW — AIの下読みを確認する
- AIが示した箇所を、人が差分で開いて確かめたか
- 「関係する」と分類された変更も、本当に必要か
- 変更したのがAIの場合、そのAIの説明を証拠として扱っていないか
AIの下読みは、レビューの代わりではなく、見る場所の目印です。
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 観点の階層と、変更の大きさ
上から順に見る
レビューの観点には順番があります。1 つ目は正しさ（仕様どおりに動くか、境目の条件はどうか）。2 つ目は安全（権限の確認、個人情報の扱い、外から来る値の検査）。3 つ目は性能（データが 10 倍になっても大丈夫か）。4 つ目は保守（読めるか、テストがあるか、名前が意味を表しているか）。5 つ目は運用（記録が残るか、設定で変えられるか、戻せるか）。書式の指摘は道具に任せ、人は上の 3 つに時間を使います。
変更は小さく、目的は 1 つ
大きな変更ほど、見落としが増えます。1 回の変更を小さく（目安として数百行まで）、目的を 1 つにします。「ついでに直した」が混ざると、レビューする人はどこを重点的に見ればよいか分からなくなります。
承認までの時間を見る
承認までの時間が極端に短い変更は、読まれていない可能性があります。レビューの記録から、変更の大きさと承認までの時間を並べて見ると、形だけのレビューが見つかります。
AI が書いた変更の追加の観点
頼んだ範囲の外が変わっていないか。「動作確認済み」という説明に根拠（テストの結果）があるか。誰が頼み、どの指示で生成されたかの記録が残っているか。AI の説明は証拠ではないので、人がコードを読みます（09-05）。
現場で確かめる問い
- レビューの指摘のうち、書式の指摘が何割を占めるか。道具に任せられるものはないか
- 1 回の変更の大きさの目安があるか。目安を超える変更はどう扱っているか
- 承認までの時間が極端に短い変更を、記録から拾ったことがあるか
- AI が書いた変更について、頼んだ範囲の外が変わっていないかを確かめる手順があるか
アステリア案件のレビューの人数、観点、承認までの時間は、正本に記録がありません。記録なし
10. 人間が判断すること
- 変更を承認するか、差し戻すか
- 頼まれていない変更を残すか、取り消すか
- 追加のテストが必要か
11. 判断演習
あなたは、差分が非常に大きい変更のレビューを頼まれました。期限は今日です。
あなたなら、どうしますか。
- 変更を小さく分けてもらう
- 安全に関わる箇所から優先して見る
- 見きれない部分を、見ていないと明示する
- 期限を延ばすよう相談する
「全部見たことにして承認する」は選びません。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
コードレビューは、差分を見て、頼んだ変更が頼んだ範囲で正しく行われたかを確かめる工程です。
説明文やテストの合格だけで、承認しません。