コードレビューとQAを「人に依存させない」AI活用｜Adobe Commerce開発の実践記録③

AIを使えば、コードもテストケースも以前より速く作れます。しかし作る量が増えるほど、それを確かめるレビューとQAの負荷は大きくなります。確認の観点が担当者ごとにばらつけば、品質もばらつきます。

本記事は、Adobe Commerce開発の全工程にAIを組み込んだ取り組みを紹介するシリーズの第3回です。今回は、コードレビューとQAの観点をAIで標準化し、品質を担当者の力量に依存させない仕組みをご紹介します。

AI活用の議論は、「どれだけ速く作れるか」に集まりがちです。しかし開発の成果を決めるのは、作ったものが正しく動くかどうかです。

作るスピードが上がると、確認すべきコードとテスト対象も増えます。レビューやテスト設計が人の経験に頼ったままだと、次のような問題が起きます。

• レビューの順番待ちが発生し、開発の流れが止まる
• 担当者によって見る観点が違い、見落としが生まれる
• テスト観点の作り方が人ごとに異なり、抜け漏れの有無を確かめにくい

当社では、AIで作る量が増える時代だからこそ、レビューとQAに仕組みが必要だと考えています。観点をAIと共通のルールで固定し、誰が担当しても同じ水準で確認できる状態を目指しました。

コードレビューでは、変更内容をAIが決まった観点で確認し、重大度つきの指摘を自動で投稿する仕組みをつくりました。人は、その指摘をふまえてマージしてよいかの最終判断に集中します。

1. 変更の登録を検知し、チャットで担当者に通知する
2. 変更の差分を、AIが読みやすい形に整理する
3. レビューの観点と出力形式を組み合わせて、指示を作る
4. AIが観点に沿ってコードを確認する
5. 結果を、人が読む形式と機械が読む形式の両方で出力する
6. 指摘をGitLabの該当箇所へ自動で投稿する

確認の優先順位は、セキュリティ、性能、コーディング規約・設計ルールの順に固定しています。指摘には「重大／警告／提案」の3段階の重大度を付け、対応の優先度がひと目でわかるようにしています。

実行例

7ファイルの変更に対してこの仕組みを実行したところ、重大0件、警告2件、提案6件の指摘が、実行から投稿まで約5分で返ってきました（1件の実行記録）。

• 重複していた約45行の処理を共通化した点を、良い変更として評価
• 使われていない読み込みの残りや、設計上の層の違反を指摘
• 指摘はすべて行番号つきで、どこを直せばよいかが具体的

QAチームのAI活用は、最初から整っていたわけではありません。約5ヶ月をかけて、単発の利用から、チームの標準として定着させました。

1. 基盤づくり（1〜2月）：AIの役割を決めて単発で利用。毎回、背景の説明が必要だった
2. 標準化（3〜4月）：テンプレートを統一。影響分析を「機能の一覧から考える」方法から、「システムの基盤から考える」方法へ切り替えた
3. 成熟（5月）：複雑な分析にも適用し、出力の手直しがほぼ不要に。手順を6段階のガイドにまとめた
4. 定常運用（6〜7月）：10シートのナレッジベースが完成。自動化や翻訳にも活用を広げた

活用の範囲も、テストケース設計を中心に、影響分析・見積り、不具合の原因分析、新メンバーの立ち上げ支援、不具合の分類などへ広がっています。

ナレッジベースができたことで、担当者が変わっても、AIに毎回背景を教え直す必要がなくなりました。QAの知見が個人ではなく、チームに蓄積される状態になっています。

テストケースは、いきなり作り始めません。「要件の理解」と「テスト観点の合意」を先に固めてから作成することで、作り直しを最小限にしています。

1. 情報の受領：開発者や業務担当者から、問題の内容、影響するファイル、実施した修正を受け取る
2. 原因と影響の分析：AIに原因と他の機能への影響を分析させ、結果を人が確認してから次へ進む
3. 観点の合意：テストの考え方と観点をまとめ、開発・業務担当・PMと曖昧な点を確認して合意する
4. テストケースの作成：決まったフォーマットでテストケースを作成し、Excelで出力する
5. レビューと修正：チェックリストで確認し、番号つきで修正を指示して版を更新する

この流れにより、テストケースは平均2〜3版で完成します。ある機能では、作成に入る前の観点合意の段階で、18件の曖昧な点を解消できました。

観点をそろえるための共通ルール

• 13列の共通テンプレート（観点の目的、手順、期待結果、実施結果など）
• テストケース番号の命名規則（機能単位の連番）
• 観点を6つのグループで色分け（正常系、セキュリティ、境界・例外、連携、画面表示、回帰）
• 曖昧な点には「確認要」のフラグを付け、推測で期待結果を書かない

とくに最後のルールが重要です。AIに推測で期待結果を書かせないことで、「期待結果そのものが間違ったテストケース」を未然に防いでいます。

レビューとQAの観点を仕組みで固定したことで、確認の速さと品質の安定を両立できるようになりました。

数値以上に大きいのは、品質の確認が特定の担当者に頼らなくなったことです。レビューの一次確認はAIが同じ観点で行い、テスト観点は共通のテンプレートとナレッジベースでそろいます。人は、最終判断や曖昧な点の確認といった、人にしかできない仕事に時間を使えるようになりました。

約5ヶ月の取り組みを通じて、QAチームが得た教訓は次の3つです。

1. 要件を理解する前に、テストケースを書かない：AIはすぐにテストケースを出せますが、要件の理解と観点の合意が先です。ここを飛ばすと、作り直しが増えます。
2. 影響分析は、システムの基盤から考える：機能の一覧から影響を洗い出すと、機能をまたぐ影響を見落としがちです。システムの基盤から考えることで、影響範囲を漏れなく捉えられます。
3. 曖昧な点はフラグを立て、推測しない：AIに推測させた期待結果は、もっともらしく見えても誤っていることがあります。わからない点は、わからないまま確認に回します。

どれも、AIを使う前から大切だった基本です。AIを活用するほど、こうした基本を仕組みとして守ることの重要性が増しています。

AIで作る量が増えるほど、それを確かめるレビューとQAの価値は上がります。当社は、レビューとテストの観点をAIと共通ルールで固定し、ナレッジベースで知見をチームに蓄積することで、品質を担当者の力量に依存させない仕組みをつくってきました。スピードを上げるためのAIと、品質を守るための仕組み。その両方がそろって、はじめてAI駆動開発の効果が生きると考えています。

関連リンク

• サービスページ「AI駆動開発」
• 第1回：AIに「書かせない」AI駆動開発｜Adobe Commerce開発の実践記録①
• 第2回：要件の「認識ズレ」をなくすBrSE×AI｜Adobe Commerce開発の実践記録②
• LIXIL様向け Claude Code 集中レクチャー実施レポート（お客様社内でのAI活用・内製化を支援した事例）