id: H-4(誌面表示: H-04) · 物理ページ: 602–603(pages=2) · category: workflow · figure_type: workflow · status: ready · evaluation_date: 2026-08-23
tagline 32/25-45何を 109/60-200どこで 84/60-200会話例 33/25-50見1 27/15-40見2 23/15-40見3 28/15-40見4 24/15-40見5 25/15-40見6 24/15-50
← H-03 バイブコーディングの流儀 目次 H-05 Scrum / Agile →
歴史
602

コードレビュー

書いた変更を人が読み、取り込む前に問題がないか確かめる工程です。
体験区分:触った 推奨読者レベル:Level 2-3

何をしてくれるか

自分以外の人が書いた変更を読み、動くかどうかだけでなく読みやすさや想定外の入力への強さ、既存の作りとの整合まで確かめます。GitHub では Pull Request の画面で指摘や修正のやり取りをしてから本流に取り込みます。

どこで出会うか

AI がコードを書いた場面でも、取り込む前に人が見るという関門は基本的に残ります。逆に AI にレビューを任せて一次チェックに使う場面も増えており、両方の使い方に出会います。

イメージ
開発フローでの位置
変更を書く
Pull Request を作る
レビューを受ける
修正して再提出する
承認してマージする
2026.08·ready
「AI が書いたコードでも、コードレビューは人の目を通しますよね。」
コードレビューの見方
603
この用語の見どころ
1
役割

変更を取り込む前に、人や AI が中身を確認する工程です。

2
うれしさ

バグや設計の乱れを取り込む前に見つけられます。

3
注意点

指摘の言い方がきついと書き手との関係がぎくしゃくします。

4
どこで役立つか

GitHub の PR 画面で日常的に使われています。

5
はじめに

まずは小さな変更から人に見てもらう習慣をつけます。

6
深掘り先

レビュー観点、チェックリスト、AI レビューツール

非エンジニアのつまずき
  • AI が書いたものを、どこまで疑えばよいか分かりません
  • 全部読む時間はないが、読まないのも怖いです
  • 誰が責任を持つのかが曖昧になります
私のコメント
  • 第一印象:負荷の重心が完全に逆転しました
  • 良い点:品質を担保する最後の砦になります
  • ダメな点:レビューする側が追いつきません
  • 誰向けか:AI に書かせている人みんな向けです
関連用語
備考

AI が書いたコードをそのまま取り込まず、人が読んで確認してから取り込む運用が多くの現場で基本とされています。

H-04·workflow
バイブコーディング図鑑