結論から書きます。AIが書いたコードを人のレビューなしで通してよいのは、「壊れても戻せる」「影響範囲が閉じている」「機械が合否を判定できる」の3条件がそろった部分だけです。そしてモデルは1つに決め打ちせず、作業系・思考系・デザイン系・判定系という4つのタスク種別で振り分けると、品質とコストの両方が安定します。この1年で開発の進め方が変わったのは、AIが万能になったからではなく、任せる範囲を切り分ける技術が現場に広まったからです。
ここで言うコードレビューとは、書いたプログラムを別の人が読んで、間違いや危うい書き方を指摘する作業のことです。多くの開発現場では、変更を本番に反映する前の必須の関門になっています。その関門を「AIの出力なら省く」という判断をする現場が出てきた——これが今、話題になっている変化の中身です。
なぜ1年でレビューの前提が変わったのか？
変化の理由は、大きく3つに整理できます。
- エージェント型の実行環境が普及した。従来の補完ツールは「次の1行を提案する」ものでしたが、現在は指示を受けてファイルを横断して編集し、テストを走らせ、失敗したら自分で直すところまで一続きで回すツールが一般的になりました。GitHub Copilot のエージェント機能、Cursor、Claude Code、OpenAI の Codex、Google の Gemini CLI などが代表例です。
- 扱える文脈の量が増えた。コンテキストウィンドウ（AIが一度に読み込める文章量の上限）が広がり、1ファイルだけでなくリポジトリ全体の構造を踏まえた修正がしやすくなりました。「周辺を見ていないから壊す」という失敗が減ったことは、信頼の感覚に直結しています。
- 自動検証が前提になった。テストや静的解析（コードを実行せずに文法や危険な書き方を機械的に調べる仕組み）が通らなければマージできない構成になっている現場では、AIの出力も人の出力も同じ関門を通ります。人のレビューを省いても、機械のレビューは省いていない、という点が重要です。
つまり「AIを信じている」というより、「人が目視しなくても落とせる網がある場所に限って、目視を省いている」というのが実態に近い表現です。網のない場所まで省いた現場は、おそらく静かに痛い目を見ています。
レビューを省いてよい範囲はどう線を引く？
冒頭の3条件を、判断に使える形に落とすと次のようになります。
| 条件 | 確認すること | 満たさないときの扱い |
|---|---|---|
| 戻せる | デプロイを1コマンドで切り戻せるか。データの不可逆な書き換えを含まないか | 人のレビュー必須 |
| 影響が閉じている | 変更が1機能・1画面の内部で完結するか。共通ライブラリや認証、課金に触れないか | 人のレビュー必須 |
| 機械が判定できる | テストが実際にその変更の正しさを検証しているか。カバレッジだけでなく中身を見る | 人のレビュー必須 |
この線引きで言えば、テストコードの追加、ログ出力の整理、型定義の補完、文言修正、依存ライブラリの小さな更新あたりは、人の目視を省きやすい領域です。逆に、認証・権限、決済、個人情報の取り扱い、データベースのスキーマ変更、外部公開APIの仕様変更は、どれだけモデルが賢くなっても人が読む対象として残すのが無難です。失敗したときの損害が、確認コストを明らかに上回るからです。
任せる作業の切り分け方そのものは、コードに限らず業務全般で共通します。判断軸の立て方はAIエージェントに任せる作業は4軸で選ぶも合わせて読むと整理しやすいはずです。
モデルの使い分けはどう決める？
「最高性能のモデルを常用すれば良い」という考え方は、現在は現実的ではありません。理由は単純で、高性能モデルほどトークン（AIが文章を処理する単位。おおむね単語や文字の断片に相当）あたりの単価が高く、応答も遅いからです。1日に何百回も呼ぶ作業で最上位モデルを使うと、費用と待ち時間が積み上がります。
現場で広がっているのは、タスクの性質で振り分ける考え方です。分類の呼び方は現場ごとに違いますが、おおむね次の4種類に収まります。
| タスク種別 | 中身の例 | 選び方の基準 |
|---|---|---|
| 作業系 | 一括置換、定型コードの生成、フォーマット整形、テストの雛形作り | 速度と単価を優先。中位・小型モデルで十分なことが多い |
| 思考系 | 設計方針の検討、原因が読めない不具合の調査、仕様の矛盾の洗い出し | 推論を重ねるタイプの上位モデル。回数は少ないので単価より精度 |
| デザイン系 | 画面の構成案、文言のトーン調整、図やスクリーンショットの読み取り | 画像を扱えること（マルチモーダル）と、出力の自然さ |
| 判定系 | 出力の合否チェック、分類、要約が原文から外れていないかの確認 | 安定性と応答の速さ。小型でも、判定基準を明示すれば実用に足りる |
特に効くのが判定系の分離です。生成したモデルに自分で採点させると甘くなりがちなので、別のモデルに「この修正は指示の範囲を超えていないか」を判定させる構成にすると、見落としが減ります。人間のレビューを減らすなら、その分を機械の相互チェックで埋める、という発想です。
自動切り替えに任せきりでよい？
モデルの切り替えには、ツール側が質問の難易度を判断して自動で振り分ける仕組みと、担当者が明示的に選ぶ手動運用があります。どちらにも落とし穴があります。
- 自動の落とし穴：どのモデルが答えたのか記録が残らないと、品質がぶれたときに原因を追えません。ログにモデル名を残す設定を最初に確認してください。
- 手動の落とし穴：人は迷うと上位モデルを選びがちで、コストが読めなくなります。「この作業はこのモデル」という社内の既定値を、ドキュメントで1枚決めておくと安定します。
- 共通の落とし穴：モデルは予告をもって提供終了になることがあります。特定モデル前提の指示文（プロンプト）を大量に書き込んでいると、乗り換え時に総崩れになります。この備えはAI料金改定とモデル終了は5段階で確認するの手順がそのまま使えます。
また、外部のAIサービスに依存する以上、障害時に開発が止まるリスクも考えておく必要があります。生成AIが止まっても業務を止めない代替手順の作り方で触れたように、「止まったら手で書く」と決めておくだけでも、慌てずに済みます。
明日から試せる、1週間の進め方
大きく仕組みを変える前に、小さく測ることをおすすめします。たとえば次のような進め方です。
- 初日：直近1か月分のプルリクエスト（変更の反映依頼）を見返し、レビューで実際に指摘が入った箇所を数える。指摘ゼロが続いている種類の変更を洗い出す。
- 2〜3日目：洗い出した種類のうち、前述の3条件を満たすものだけを「AI出力は機械検証のみで通す」候補に置く。満たさないものは候補から外す。
- 4〜5日目：候補の作業を、作業系・思考系・デザイン系・判定系に仕分けし、それぞれに使うモデルの既定値を決める。決めた内容は1ページにまとめ、誰でも見られる場所に置く。
- 6〜7日目：2週間だけ試す期間を宣言し、終了後に「差し戻し件数」「本番での不具合件数」「AI利用料」の3つを比べる。悪化していれば元に戻す。
この「元に戻す条件を先に決める」という一手間が、現場の抵抗感をかなり下げます。検証のやり方そのものはAIの検収は自社データ100件で足りるの考え方と同じで、自社の実データで小さく確かめるのが近道です。
外部に委託している場合に確認すること
自社で開発していない場合も、他人事ではありません。委託先がAIを使って実装しているとき、次の点は確認しておくと安心です。
- AIが生成したコードについて、人のレビューをどこまで行っているか
- 社内のソースコードや仕様書を、外部のAIサービスにどの範囲まで送っているか。学習に使われない契約になっているか
- 生成物の権利関係と、第三者のライセンス（利用条件）に抵触しないかの確認手順
- 使っているモデルが提供終了になった場合の対応
AIの利用にあたって事業者が配慮すべき事項は、国内では総務省と経済産業省による「AI事業者ガイドライン」が参考になります。法的な拘束力のある規制ではありませんが、社内ルールを作るときの土台として参照しやすい文書です。契約や権利まわりの整理はAI生成物の著作権、社内で決める3点も合わせて確認してください。
まとめ
この1年の変化を一言でまとめると、「AIを信じるか否か」から「どこまで任せ、どこで止めるかを設計する」へ、論点が移ったということです。整理すると次の通りです。
- 人のレビューを省けるのは、戻せる・影響が閉じている・機械が判定できる、の3条件がそろった範囲だけ
- 認証、決済、個人情報、データ構造の変更は、人が読む対象として残す
- モデルは単一依存をやめ、作業系・思考系・デザイン系・判定系で振り分ける
- 生成と判定は別のモデルに分けると、見落としが減る
- 自動切り替えでもモデル名をログに残し、提供終了に備えた乗り換え手順を用意する
- 試すときは期間と「元に戻す条件」を先に決める
モデルの性能は今後も上がり続けますが、上がれば上がるほど「どこを任せるか」の設計が効いてきます。まずは直近1か月のレビュー記録を眺めるところから始めてみてください。自社がすでに安全に省けていた領域が、思ったより多く見つかるはずです。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
