こんにちは！
キャディ株式会社のCADDi Quote開発チームでQAエンジニアをしているnacoです✌️
2026年1月15日にオンラインイベント「【AI時代の開発戦略】開発スピードと品質の両立に向けて ー 3社エンジニアの事例から学ぶ」が開催されました。
そこで登壇の機会をいただきました。やったー！
本記事では、その際にお話しした「QAがGeminiで分身して、受け入れ基準(AC)レビューを自動化し、開発スピードに追いつくための取り組み」をブログ向けに整理してまとめまーす。
当日のスライドはこちら👇
🍥はじめに：この記事でいう「ACレビュー」の定義を明確にします
ここでのACレビューは、受け入れ基準（Acceptance Criteria）を書き出して合意するレビュー活動を指しています。適用範囲は「ストーリー着手前に、ACを明文化する場面」です。（スライドP.4）
この段階で期待値が揃っていると、手戻りが減りテストも作りやすくなります。一方で、ここが曖昧なままだと、後工程にズレが持ち越されやすくなります。
🍥背景：開発は速くなっているのに、リリースが速くならない
わたしの所属するチームでは、開発生産性向上のためにAI活用やSREによる運用改善などに取り組んでいました。つまり「作る速度」も「守る仕組み」もつよつよにしにいってる状態です。
QAもその中で、開発スピード向上の一環としてACレビューを実施していました。取り組みの狙いはシンプルで、着手前に期待値を揃え、後工程の手戻りを減らすことです。
でも実際には、ACレビュー自体は価値がある一方で、想像以上に工数が大きくなりました。増えていたのは、チェックそのものというより、レビューに必要な情報を集めて理解する時間でした。（スライドP.10）
結果として、ACレビューの工数増大により作業が詰まると、実装着手が遅れたり、ACレビューが間に合わず認識ズレが後ろに持ち越されたりして、遅れ方がもりもり増えてしまいます。
それにより、QAが本来投資したい品質基盤やプロセス改善の時間が取れず、「やることは増えてるのに改善が進まない」状態になっていました。
🍥課題の絞り込み：投資対効果が出やすいところから着手する
QA業務の効率化を狙うにあたり、リターンが大きくコストが低いソリューションに限定して、短期で成果を出すことにフォーカスしました。（スライドP.11）
ここを攻略できると、時間が生まれ、他の改善にも手が出せると考えました。
そこで今回選んだのが、「AIによるACレビュー自動化」です。ポイントは「AIが全部やる」ではなく、「QAの分身🥷」として働いてもらうことでした。人の判断は残しつつ、下準備をAIに寄せる狙いです。
🍥Key Success Factor：AIを分身として仲間にするための成立条件🥷
AIをQAの分身として活用するには、次の3点が必要だと整理しました。
- QAの考えを型にする（判断の一貫性を担保する）
- 正しいデータと文脈を渡す（QA - AI間の前提ズレによる手戻りを減らす）
- 人とAIの役割分担を明確にする（過信・軽視の両方を防ぐ）
逆にここが曖昧だと、AIの指摘が揺れたり、誤った前提で筋のよいことを言ってしまったりして、運用として成立しにくくなります。
🍥ACレビュー自動化：具体的にやったこと
ここでは、KSFを実装に落とすためにやったことを3つに分けて紹介します。
①レビュー観点の型化（QAの判断を、AIに渡せる形へ）
まず、ACレビュー観点を「型」にしました。イメージとしては、QAの頭の中にある判断基準を、AIが参照できる形に落とす取り組みです。
具体的には、普段の判断をMarkdownのプロンプト観点図にし、観点図はPlantUMLファイルとして管理しました。PlantUMLにした理由は次の通りです。
- AIが構造として読み取りやすい
- 人も図としてすぐプレビューできる
- テキストなので差分管理でき、観点を資産として育てやすい（AIにも人にも同じソースを見せられる）
- マインドマップがMermaidより見やすいと感じた
狙いは、判断の一貫性と属人化の低減です。
②文脈・データの接続（前提ズレを減らす）
AIは前提が1つズレるだけで、それっぽいが外しているレビューになりやすいです。そうなると、人間 - AI間のレビューの手戻りが増えます。
そこで、AIが参照すべき情報にあたりに行ける状態を整えました。少なくとも、仕様・設計・実装にアクセスできないとレビューが成立しにくいからです。入力の品質を上げ、参照できる情報を増やすほど、出力の品質が安定します。
③人が最終チェックする運用（過信も軽視も避ける）
AIは下書き・提案を行い、最終判断は人が行う運用にしました。
役割分担を曖昧にすると、次の2つが起きやすいと考えています。
- 「AIがOKと言ったからOK」という過信
- 「AIの指摘だから軽く扱う」という軽視
どちらも品質の観点では危険です。 そこで、AIが一次レビュー → 人が妥当性を見て採否判断 → その結果を改善に回すというサイクルで回しています。
🍥Before / After：QAの業務範囲を絞る
スライドでは、Before/Afterとして業務範囲（青枠）の変化を示しています。変化の本質は、QAが特に時間を使っていた 「情報収集」と「理解のための下準備」 をAIに寄せられた点です。（スライドP.16）
これにより、ACレビューの「追いつかなさ」や「ばらつき」は解消方向に進みました。QAの役割も「情報を探す人」から「判断する人」へ寄せやすくなりました。
🍥これからの取り組み：短期ROIの維持と、中長期リターンへの再投資
ACレビューはROIが高いので、低コストで継続していく予定です。
そのうえで今後は、中長期的なリターンが大きい「プロセス改善」に取り組みます。単発の改善ではなく、定義して、運用して、改善が回る状態を目指します。
また、QAチームのAI活用はACレビューに留まらず、テストケース作成の半自動化や、不具合分析にも広がりつつあります。こちらも、より使いやすい形に進化させていきたいです。
🍥まとめ
- 開発スピードが上がっても、リリースが速くならないことがあります。
- 課題の一つが、上流工程であるACのレビューが追いつかないことでした。
- 対策として、QAがAIを使って分身し、ACレビューの下準備を自動化して開発スピードに追いつくアプローチを取りました。
- KSFは、観点の型化／文脈データの接続／人とAIの役割分担の明確化の3点です。
まだ試行錯誤中ですが、現状は「AIで置き換える」より「AIに任せるところを決めて、運用として回す」のが使いやすいと感じています。
おしまい！
