AIコードレビューの体制、制作会社は「誰が何を見るか」を先に決める──書いた人・確かめる人・承認する人の役割分担と、レビュー工数を月の予定に確保する計算例
この記事は、AIが書いたコードを、制作会社の中で誰が、何を、どれだけの時間をかけて見るかという、AIコードレビューの体制を扱います。
「レビュー待ち」の変更が、毎週たまっていく
AIのコーディング支援を入れてから、実装は目に見えて速くなりました。
ところが、技術責任者の机の前には、確認待ちの変更が毎週たまっていきます。
結局、確認は金曜の夕方にまとめて流し見になり、月曜に不具合の連絡が来ます。
速くなったのは書く工程だけで、確かめる工程の体制は、AIを入れる前のままだったのです。
AIコードレビューの体制とは、AIが書いた変更を「誰が・何を・どれだけの時間で」確かめるかを、役割と予定に落とした社内の仕組みである
黒字化の外科医です。AIで増えた変更の量に、レビューの体制を追いつかせる方法を解剖します。
体制を先に決めるべき理由は、三つあります。
第一に、AIで増えるのは、書く量だけではなく、確かめる量でもあるから。
1日に上がる変更が2倍になれば、確認の仕事も2倍になります。確認する人の時間が同じなら、そこが渋滞します。
第二に、「全員がなんとなく見る」は、誰も責任を持たないのと同じだから。
書いた人は「レビューで見てくれる」と思い、レビューする人は「書いた人が動作を確かめた」と思う。この思い込みの隙間から、不具合が出ます。
第三に、レビューの時間は、予定に入れない限り、急ぎの作業に負けるから。
レビューは売上に直結して見えないため、締め切りが近い案件に、いつも後回しにされます。
セキュリティの観点で何を確かめるかは、別の記事で扱いました。この記事は、その観点を「誰が、いつ」回すかの話です。
▶ AI生成コードのセキュリティ、「動いたから納品」をやめる社内ルール──人が確かめる5つの観点、実在しないパッケージの確認、記録の型
誰が何を見るか：3つの役割と、見る範囲
AIを使ったかどうかで役割を変えず、1件の変更に3つの役割を置きます。
【書いた人（AIを使った人）】
・AIの出力を、自分で読んで説明できる状態にする
・動作を確かめ、確かめた手順を変更の説明に書く
・AIに書かせた範囲と、追加した外部のパッケージを書く
【確かめる人（レビュアー）】
・仕様（チケット・見積もりの範囲）と一致しているか
・読めるか、直せるか（命名、重複、不要なコード）
・テストと確認の手順が、変更の重さに見合っているか
・セキュリティの観点（重い変更・中くらいの変更）
【承認する人（技術責任者・案件の責任者）】
・重い変更の本番反映を、承認する
・レビューで判断が割れたときに、決める
・月に1回、指摘の傾向を見て、社内の決まりを直す要点は、書いた人の仕事を軽くしないことです。
「説明できないコードは、レビューに出さない」。この一行が、レビュアーの負担を一番減らします。
今すぐ試せる：自社のレビュー体制の案を作るプロンプト
私はWeb制作会社の経営者です。AIのコーディング支援を使う社内で、コードレビューの体制を決めたいです。
（顧客名や秘密情報は入力しません）
【前提】
・エンジニアの人数と経験年数：〔記載〕
・レビューできる人の人数：〔記載〕
・1か月に上がる変更の件数（だいたい）：〔記載〕
・変更の種類（ページ追加、フォーム、会員機能、決済など）：〔記載〕
・今のレビューの決まり：〔有無と中身〕
1. 「書いた人・確かめる人・承認する人」の役割と、それぞれが見る範囲を表にする。
2. 変更を「重い・中くらい・軽い」に分ける基準を、自社の変更の種類で書く。
3. 重さごとのレビューの時間の目安を、〔 〕で埋められる形で示す。
4. レビューが渋滞したときの、優先順位の決め方を書く。
精神論ではなく、記録と確認ができる形で書くこと。レビュー工数工場：月の予定に「確かめる時間」を確保する
計算式
月のレビュー時間 ＝ Σ（重さごとの件数 × 1件あたりのレビュー時間）
レビュアーの時間の占有率 ＝ 月のレビュー時間 ÷ レビュアーの月の勤務時間1件あたりの時間は、相場ではなく、自社の記録から出します。最初の1か月は、全員が「レビューにかかった時間」を変更ごとに記録してください。
例（数字はすべて例）
重い変更：5件 × 2時間 ＝ 10時間
中くらい：15件 × 1時間 ＝ 15時間
軽い変更：20件 × 0.25時間 ＝ 5時間
月のレビュー時間：10 ＋ 15 ＋ 5 ＝ 30時間
レビュアー1人の月の勤務時間：160時間
占有率：30 ÷ 160 ＝ 18.75%この例では、レビュアーの勤務時間の約2割を、最初からレビューの枠として予定に入れておきます。
枠を入れずに案件を割り振ると、その2割は、残業か流し見のどちらかになります。
渋滞させないための決まり
□ 1件の変更を小さく保つ（目安は自社で決め、超えたら分けて出す）
□ レビュー待ちは、重い変更から順に処理する
□ レビュー待ちが〔 〕件を超えたら、新しい実装を止めてレビューを先にする
□ 毎日〔 〕時〜〔 〕時を、レビューの時間として予定に固定する
□ 指摘と修正を記録し、月に1回、同じ指摘が続く点を社内の決まりに足す3つ目の「実装を止める」決まりが、いちばん効きます。書く速さが確かめる速さを超えたら、書く側を止めるしかありません。
レビューの時間を見積もりにどう残すかは、AI時代の単価の決め方とあわせて考えます。
▶ Web制作のAI時代の単価は「減った工数の何割を価格に返すか」で決める──成果物と範囲で値付けする手順、価値の根拠の示し方、還元率の計算例
構造的なリスク
逆説を指摘しておきます。
レビューの体制を厳しくするほど、書いた人は「レビューで見てもらえる」と考えて、自分で確かめる手を抜きやすくなります。
レビューが、品質の責任を一人に集める仕組みになってしまうのです。
だから、レビューで差し戻した理由のうち、「書いた人が自分で確かめれば分かったもの」の割合を、月に1回見てください。
その割合が高いなら、増やすべきはレビュアーではなく、書いた人の確認の手順です。
よくあるQ&A
Q. レビューできる人が、社長しかいない。
まず重い変更だけを社長が見て、中くらいと軽い変更は、エンジニア同士で見合う形にします。社長がすべてを見る体制は、案件が増えた時点で止まります。
Q. 外注先が書いたコードも、同じ体制で見るのか？
同じ役割を当てはめます。外注先には「書いた人」の仕事（説明と確認の記録）を、発注の条件として求めてください。
Q. AIにレビューさせれば、人の時間は減らせるのでは？
見落としの候補を探すのには役立ちます。ただし、合否を決め、記録に責任を持つのは人です。AIの指摘を読む時間も、レビューの時間に含めて計算してください。
最後に
AIで速くなるのは、書く工程です。確かめる工程は、体制と予定に入れない限り速くなりません。
誰が何を見るかを決め、レビューの時間を月の予定に先に確保した会社だけが、AIの速さを品質を落とさずに利益へ変えられるのです。
レビューを終えたあと、納品の前に何を確かめるかは、チェックリストの形でまとめました。
これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。
#Web制作会社 #コードレビュー #AI駆動開発 #AI生成コード #品質管理 #開発体制 #制作会社経営 #中小企業 #生成AI #工数管理
