指定したコード差分を、利用可能なテスト結果と承認済みのスキャン結果に照らし、該当行を示した指摘案としてまとめます。マージ前の判断はエンジニアが行います。
- 変更内容とリポジトリの文脈を読む
- 設定済みのチェックを実行する
- 不具合、リスク、テスト不足を確認する
コードへのアクセス権、ブランチ保護、テスト証跡、レビュー責任者が定まっているリポジトリとレビュー種別を一つ選びます。
このワークフローでできること
不具合、セキュリティ、テスト、保守性を確認し、マージ判断は開発者が行います。
まずは、対象リポジトリと内容が明確なプルリクエスト種別を一つ選び、コーディング規約、テスト証跡、レビュアー、マージ条件を定めます。セキュリティ上の指摘、アーキテクチャ変更、本番影響のあるコード、例外承認、最終マージ判断は、適切な技術者が担います。
ワークフローの流れ
変更内容とリポジトリの文脈を読む
PRの差分、関連ファイル、レビュー規則、テスト結果、参照可能なリポジトリ情報を読み込みます。
設定済みのチェックを実行する
承認されたlinter、スキャナー、プロジェクト規則を使い、ツール出力とモデルによる指摘を区別します。
不具合、リスク、テスト不足を確認する
参照可能な範囲で、ロジック不具合、セキュリティ上の懸念、回帰、保守性、テスト不足を調べます。
優先順位付きの指摘をまとめる
該当コードを示し、判断根拠と不確実性を説明したうえで、具体的な確認方法や修正案を提示します。
エンジニアが確認して判断を残す
有資格のエンジニアが指摘を検証し、例外や意見の相違を処理し、最終的なマージ判断を行います。
導入前に定める統制
| 統制領域 | エージェントが担うこと | チームが管理すること |
|---|---|---|
| 評価指標 | 採用された指摘、誤検知、後から判明した見落とし、一次レビューまでの時間を記録します。 | リポジトリ、言語、ルールセット、リスク区分ごとに修正傾向を確認します。 |
| レビュー | 指定した差分、テスト結果、承認済みのスキャン結果から、該当行を示した指摘案を作成します。 | セキュリティ、設計、本番影響、例外受入れ、マージの判断は有資格のエンジニアが行います。 |
| 例外 | 差分、テスト、生成コードの範囲、スキャン結果が欠けているか矛盾する場合は、レビュー未完了と明示します。 | セキュリティに関わる指摘や判断が難しい事項は、適切なコードオーナーへ回します。 |
| 証跡 | コミット、変更行、ルールまたはスキャンの出典、指摘理由、不確実な点を記録します。 | レビュー担当者の修正、対応区分、例外承認、最終的なマージまたは修正判断を保持します。 |
| 復旧 | リポジトリやスキャナーとの連携が失敗した場合は問題なしと判定せず、未実施の検査を明示します。 | 失敗した検査を復旧し、抜けた範囲を人が確認したうえで同じコミットを再検査します。 |
パイロットの前後に行うこと
導入前
導入前に、対象リポジトリと内容が明確なプルリクエスト種別を一つ選び、コーディング規約、テスト証跡、レビュアー、マージ条件を定めます。
導入後
導入後は、リポジトリとリスク区分ごとに、採用された指摘、誤検知、後から判明した見落とし、一次レビューまでの時間を評価します。
OpenMaxでワークフローを連携する
OpenMaxで一次レビューの根拠と修正案を整理し、セキュリティ、設計、マージの判断はエンジニアに委ねます。
よくある質問
AIコードレビューツールのパイロットはどこから始めるべきですか?
まずは、対象リポジトリと内容が明確なプルリクエスト種別を一つ選び、コーディング規約、テスト証跡、レビュアー、マージ条件を定めます。
どの判断を人が担うべきですか?
セキュリティ上の指摘、アーキテクチャ変更、本番影響のあるコード、例外承認、最終マージ判断は、適切な技術者が担います。
パイロットはどのように評価しますか?
リポジトリとリスク区分ごとに、採用された指摘、誤検知、後から判明した見落とし、一次レビューまでの時間を評価します。