SIerの生成AIによるコードレビュー｜5つの品質ゲート

はじめに

再委託先から届いたプルリクエストに、AIのレビューコメントが付いている。重大な問題はないと書かれ、テストも通っている。では、元請けの担当者はそのまま検収してよいのだろうか。

答えは否だ。顧客のソースコードをどの環境へ渡したか。AIの指摘を誰が採否判断したか。障害が起きたとき、誰が顧客へ説明するか。コードの一般的な確認方法だけでは、この三つに答えられない。

AIによるコードレビューの7つの確認点では、仕様適合、影響範囲、境界値、権限、復旧、証跡、承認という実務の基礎を整理した。SIerにおける生成AIのコードレビューには、そこへ契約と組織の境界を重ねる必要がある。顧客、元請け、再委託先、AIサービス提供者の四者をつなぐ、五つの品質ゲートで考えてみたい。

SIerにおける生成AIのコードレビューは責任分界から始める

GitLabが2026年に1,528人を対象に行った調査では、85%が「AIによってボトルネックはコード作成からレビューと検証へ移った」と答えた。さらに、43%は自社コード内でAI生成部分と人が書いた部分を確実に区別できないとしている。

SIerでは、この追跡性の欠如が検収問題になる。成果物の品質責任は、AIを使った会社やツール名だけでは決まらない。契約、案件計画、再委託承認、受け入れ条件に結び付けて初めて動く。

AIは一次検査を担える。GitHub Copilotの公式説明でも、コード変更に関連するリポジトリやプルリクエストの文脈を使って指摘する仕組みが示されている。一方、GitHubの責任ある利用に関する説明は、見逃しや誤検知があり得るため、人による確認を求めている。つまり「AIがレビューした」は作業記録であり、検収者の署名ではない。

1. 顧客コードをAIへ渡せる条件を確定する

最初のゲートは技術ではなく契約である。顧客から預かったコード、設計書、障害ログを外部の生成AIへ送ってよいかを確認する。NDAがあるだけでは十分とは限らない。再委託、国外移転、学習利用、保存期間、データ処理地域の条項が関わるからだ。

案件開始時に、情報を四区分へ分けると判断しやすい。

• 公開情報とOSSコード
• 匿名化したサンプル、型、疑似データ
• 顧客固有のソースコードと設計情報
• 個人情報、秘密鍵、本番ログ、未公開の脆弱性情報

各区分に、利用可能な環境、送信禁止項目、匿名化方法、承認者を付ける。「会社が契約したAIなら利用可」では粗すぎる。同じ製品でも個人向け画面、法人テナント、APIで条件が違う。

通過判定を行うのは、案件責任者と情報セキュリティ責任者だ。入力資料は顧客契約、データ分類表、利用サービスの契約条件。顧客固有コードを扱う場合は、顧客の同意または契約上の根拠を証跡として残す。判断できなければ、コード本体を渡さず、最小化した疑似コードで試す。

2. 四者の責任を成果物ごとに割り当てる

次に、顧客、元請け、再委託先、AIサービス提供者の役割を決める。「最終責任は人間」とだけ書いても、その人がどの会社の誰か分からなければ機能しない。

成果物ごとにRACIを置く。再委託先が実装し、AIで一次レビューするなら、作成責任は再委託先にある。元請けはレビュー基準を提示し、検収判断を担う。顧客は業務上の受け入れ条件を承認する。AIサービス提供者は機能を提供するが、個別案件の品質承認者にはならない。

特に決めたいのは、AIの重大指摘を誰が再現するか、誤検知を誰が却下するか、修正後の再レビューを誰が依頼するかである。プルリクエスト上の担当者名まで落とす。「開発チーム」「品質部門」といった組織名だけなら差し戻す。

通過判定者は元請けの開発責任者。証跡は成果物別RACI、再委託先の利用ルール確認、顧客への説明条件である。SIerの生成AIガイドラインと同じく、責任分界を案件作業へ落とすことが肝になる。

3. 検収仕様からレビュー条件を作る

一般的な「バグ、性能、可読性を見て」という依頼では、顧客の検収条件に届かない。レビュー条件は、要件ID、設計判断、受け入れ条件、禁止条件から作る。

たとえば「代理承認を追加する」という変更なら、金額上限、経過時間、代理者の資格、本人への割り当て禁止、監査ログを仕様にする。AIには、差分と各条件の対応を示し、「満たす」「満たさない」「判断材料不足」で返させる。人は、判断材料不足を推測で埋めず、仕様へ戻す。

ここで重要なのは、AIが実装とテストを同じ前提で作った可能性だ。Sonarの2026年調査では、1,100人超の開発者のうち96%がAI生成コードを完全には信頼していない一方、常にコミット前検証を行う人は48%だった。受け入れ条件から別工程でテスト観点を作り、AIが書いたテストと突き合わせる。

通過判定者は顧客側の業務責任者と元請けの品質責任者。入力資料は承認済み仕様と検収基準。証跡は要件ID、該当コード、テスト、レビュー結果の対応表である。検収条件から追えない指摘が大量に出るなら、AIへの入力を増やす前に変更単位を小さくする。

4. AIレビューの実行権限と監査記録を限定する

レビューBotをCIへ入れると、プルリクエスト本文、コメント、差分がAIの入力になる。OWASPのSecure Coding with AI Cheat Sheetは、これらが間接プロンプトインジェクションの入口になり得ると指摘する。レビューBotが組織の秘密情報や書き込み権限を持てば、悪意ある入力から権限を利用される危険もある。

原則は読み取り専用だ。修正コミットの作成、CI設定の変更、本番資格情報へのアクセスは別の承認へ分ける。外部コントリビューターや再委託先の差分は隔離環境で処理し、ネットワーク送信とツール呼び出しを記録する。

ただし、会話ログを無期限に保存するのも危険である。残すのは、プルリクエストID、コミットSHA、利用したレビュー設定、実行日時、重大指摘の処置、承認者など、説明に必要な最小限とする。プロンプト本文を保存するなら、機密情報のマスキングと閲覧権限を決める。

通過判定者はCI管理者とセキュリティ責任者。証跡は権限設定、データ送信先、監査ログ、保存・削除方針である。NISTのSSDFが示す組織準備、ソフトウェア保護、安全な開発、脆弱性対応へつなぎ、AIコメントだけを孤立させない。

5. 案件横断の標準と例外を版管理する

案件AのAIレビュー設定を案件Bへコピーすると、顧客固有の規約や権限が混ざる。反対に、案件ごとにゼロから作れば、同じ失敗を繰り返す。共通標準と案件固有部分を分ける。

共通標準には、重大度、指摘の出力形式、最低限のCI、証跡項目、禁止権限を置く。案件プロファイルには、顧客のデータ分類、受け入れ条件、利用可能なAI環境、追加検査を書く。省略した統制には理由、補完策、承認者、失効日を付ける。期限のない例外は、標準変更と同じである。

SIer向けAIエージェントの開発標準で扱ったように、標準は文書ではなく通過条件と証拠の組み合わせである。月次では、AI指摘の採用率、誤検知率、検収差し戻し、リリース後不具合、例外の残数を見る。コメント数は成果指標にしない。

通過判定者は組織の開発標準オーナー。証跡は適用した標準版、案件プロファイル、例外ID、改定履歴である。モデルやツールを替えても、責任と検収の問いは残る。

二週間の試行で責任の詰まりを測る

最初から全案件へ展開せず、低〜中リスクの一案件で二週間試す。測るのは、レビュー開始までの時間、検収までの時間、判断材料不足の件数、AI指摘の採用率、例外承認の待ち時間だ。

時間が縮まらないとき、モデルの性能だけを疑わない。顧客同意が毎回必要なのか、元請けの承認者が一人に集中しているのか、受け入れ条件がコードまで追えないのかを見る。SIerにおける生成AIのコードレビューは、指摘を自動化する施策であると同時に、曖昧だった責任分界を可視化する施策でもある。

Atsumellでは、AI業務整理ツール「Kakusill」を使い、業務要件を構造化し、受け入れ条件、レビュー観点、テスト、証跡を同じ仕様から追える開発フローを設計している。顧客・元請け・再委託先の間でAI利用の判断が止まっているなら、五つのゲートを一緒に棚卸ししたい。お問い合わせから相談してほしい。