AI生成コードのレビューは、どこを読んで、どこを読まないか

AI生成コードのレビュー範囲とは、AIが出したコードのうち、人が必ず読む場所と、テストの結果で判断する場所を、実装前に分けておくことです。全部読むことを前提にすると、レビューは形だけになり、どこも深く読まれません。ここで言うレビューは、実装の正しさではなく、発注側が「出してよい」と判断するための範囲です。

AI生成コードのレビュー範囲とは

AI生成コードのレビュー範囲とは、人が今日読む場所を、影響の大きさで先に切っておくことです。読む技術ではなく、読む場所の決め方です。誰が引き受けるのかで挙げた三つの決めごとのうち、合格条件の一部です。

エンジニア向けの記事が扱うのは、差分の見方、命名、テストの書き方です。発注側が決めるのは、それとは別です。今日、人が時間を使う場所はどこか。テストが通ったことを、出してよい根拠にしてよいか。この二つが決まっていないと、レビューの会議は開かれても、判断は残りません。

両方必要です。片方だけでは足りません。この記事は発注側の範囲だけを扱います。実装者向けの読み方の手順は扱いません。

全部読めない、という前提

人が一日に深く読める量には限りがあります。AIが一日に出す量は、その限りを超えます。全部読む、と決めた瞬間に、一件あたりの読み込みは浅くなります。浅くなったレビューは、通ったことにだけ使われ、止まる根拠にはなりません。

「全部読む」は、責任を取っているように見えます。実際には、読む場所を決めていない状態です。会議の時間は消化されます。出してよいかの判断は、翌日に持ち越されます。

前提を逆にします。全部は読めない。だから、今日読む場所を先に切る。切った外側は、捨てるのではありません。テストの結果で見る、と決めるだけです。

読む場所と、読まない場所

分ける軸は、影響の大きさです。壊れたときに外へ出る範囲が広いほど、人が読みます。壊れたときに内側で済むほど、テストの結果で見ます。

必ず読む

外に出る入出力、金額、個人情報、他システムとの境目です。ここがずれると、利用者や他社のシステムに影響が届きます。テストが全部通っていても、人が読んでいないことを、出してよい理由にはしません。

テストで見る

表示の文言が少し変わる、内部の補助処理が足される、といった、壊れても外へ出にくい部分です。入力の形が決まっていて、正しいか誤りかを機械的に判定できるなら、テストの結果で見ます。人が差分を一行ずつ追う時間は、必ず読む側へ回します。

今は読まない

読まない、は捨てるではありません。今日の合格判断に使わない、と決めることです。後から範囲に入れることはあります。今日の会議で開かない、と先に言っておくと、読む側が迷いません。

三つとも、実装が始まる前に決まっていることが条件です。実装が進んでから切ると、実装の形に合わせて範囲が動きます。後出しの範囲は、物差しになりません。

合格条件と、線引きとの関係

レビュー範囲は、合格条件の一部です。受け入れ条件とテスト方針が先に無いと、読む場所を切れません。何を確かめれば合格かで書いた三つ（受け入れ条件、テスト方針、レビュー範囲）のうち、この記事は三つ目だけを取り出しています。

受け入れ条件が発注側の言葉で書けていないと、「何ができていればよいか」が無いので、読む場所も切れません。仕様が大きな塊のままだと、条件そのものが一文になりません。人向けの要件定義を、AIに渡せる粒度まで割る方法で書いた分割の単位が、ここでの「必ず読む」単位と重なります。

AIに渡してよい情報の線引きが無いと、「AIが書いた部分」と「人が書いた部分」の境目も曖昧です。この案件でAIに何を渡してよいかで切った範囲が、レビュー範囲の外側にも効きます。渡してはいけない情報を含む処理は、必ず読む側へ寄せます。

範囲を決めていないと起きること

範囲を決めずにレビューを始めると、次が起きます。時間は使います。判断は残りません。

情シスが承認できない、という止まり方は、コードの善し悪しより先に起きます。人が読んだ場所が文書に無いと、承認する側は根拠を持てません。当社が実装前にレビュー範囲を固めるのは、この止まり方を先に潰すためです。実装を当社が担当しない案件でも、範囲の切り方だけをお受けしています。

書式は、この記事では出さない

チェックリストや記入欄の見本は、この記事では出しません。案件ごとに、必ず読む場所の中身は違います。金額を扱わない案件も、個人情報を扱わない案件もあります。共通なのは、三つに分けることと、実装前に分けることだけです。

書けるのは、何が決まっていないと止まるかまでです。決まっていないと、レビューは形だけになり、承認の根拠が残りません。書式そのものは、案件に入ってから書き起こします。

レビュー範囲だけを、先に切る

読む場所の切り方だけでも相談できます。合格条件の残り二つ（受け入れ条件、テスト方針）は、合格の物差しの側で扱います。内製チームがすでに動いている場合は、途中から合流して、今日読む場所だけを一緒に切ることもできます。考え方はAboutに、相談はお問い合わせに窓口を置いています。

よくある質問

AI生成コードのレビュー範囲とは何ですか

AIが出したコードのうち、人が必ず読む場所と、テストの結果で判断する場所を、実装前に分けておくことです。読む技術ではなく、読む場所の決め方です。

全部読むべきではないですか

全部読むことを前提にすると、量が多く、実際にはどこも深く読まれません。影響の大きい部分を先に決めて、そこは必ず読みます。

エンジニアのコードレビューと同じですか

違います。エンジニアの読み方は実装の正しさを見ます。ここで言う範囲は、発注側が出してよいと判断するための場所です。

必ず読む場所はどこですか

外部に出る入出力、金額、個人情報、他のシステムと連携する処理です。案件によって中身は違います。共通なのは、壊れたときに外へ出る範囲が広い場所を、人が読む側へ寄せることです。

読まない、とは捨てるということですか

捨てません。今日の合格判断に使わない、と決めることです。後から範囲に入れることはあります。

実装が始まってからでも決められますか

決められますが、実装の形に合わせた後出しの範囲になります。実装前に切ると、範囲が実装から独立します。

雛形やチェックリストは公開していますか

この記事では出していません。何が決まっていないと止まるかまでを書いています。書式は案件ごとに書き起こします。

テストで見る、とはテストが通れば読まなくてよいのですか

必ず読む側は、テストが通っていても人が読みます。テストで見る側は、テストの結果を見て、差分を一行ずつは追わない、という分担です。

誰が決めるのですか

発注側です。実装する側が「ここは読まなくてよい」と決めると、読む場所が実装の都合に寄ります。

実装を頼まなくても、この部分だけ相談できますか

できます。読む場所の切り方だけをお受けしています。内製が動いている途中からでも同じです。

合格条件の記事と、この記事の違いは何ですか

合格条件の記事は、受け入れ条件、テスト方針、レビュー範囲の三つを並べます。この記事は、三つ目のレビュー範囲だけを取り出して、読む場所と読まない場所の分け方を書いています。

個人情報も金額も扱わない案件でも、この分け方は要りますか

要ります。外部に出る入出力と、他システムとの境目は残ります。中身は案件ごとに書き換えて、三つに分けること自体は残します。