はじめに

こんにちは、QAエンジニアの青柳です。
ウォンテッドリーの全プロダクトを横断して支えるQAチームでは、Claude Skills や Devin を、QAプロセスに組み込む取り組みを続けています。今回は直近で進んだプロセス面のアップデートを紹介します。

本記事で伝えたいのは、 AI に任せる範囲の広さではなく、QAチームがその範囲をどう見極めているかです。この見極めは、最初から意図して決めていたことだけでは成り立っていません。最初から設計として引いた線、試してみて現場の反応から引き直した線、 AI の能力上そもそも引けない線という、性質の異なる3種類が混ざり合っています。

この「やらせる」「やらせない」「やれない」を見極め続けるという発想は、VPoE の要による全社の AI 活用に関する記事 (全社員がAIを使う組織へ、全社員がデータ分析できる環境へ) でも語られています。QAチームは全社方針を後追いしたわけではなく、独自に育ててきた仕組みが結果として同じ設計思想にたどり着きました。この見極めこそが、 AI 活用を属人的な便利ツールから組織として運用できる仕組みへ変える鍵だと考えています。

見極めるべき対象が増えた、QAプロセスの現在地

QAチームが AI を組み込んでいる工程は、既存のテスト設計を支援する仕組みに加えて、次の4つに広がりました。

• 仕様書を Issue へ変換する仕組み (仕様の整理)
• ハッピーパス (ユーザーがもっとも多く通る正常系の操作フロー) を確認する仕組み
• テスト設計を振り返る仕組み (設計の改善)
• バグ報告を整形する仕組み (報告の整理)

この4つの仕組みによって、AI は仕様からリリース後の振り返りまで、QAプロセスのほぼ全工程に関わるようになりました。仕様書を Issue へ変換する仕組みが必要になったのは、テスト設計をはじめ他の仕組みがいずれも Issue を起点に動くため、実装前で仕様書しかない段階でも先に Issue 化しておく必要があったためです。上に挙げた4つの仕組みは、この工程全体を埋める形で追加されてきました。

このラインナップ自体は、以前から少しずつ揃っていたものです。直近で起きた変化はラインナップの増加ではなく、それぞれの仕組みが「実運用に耐えるかどうか」を問い直すプロセス改善が一気に進んだことでした。次の2つのセクションで紹介するエピソードが、その改善の中身にあたります。

最初から引いていた線 ─ 設計として決めていたこと

QAチームが AI に任せる範囲を決めるとき、最初から一貫して守っている設計思想があります。AIに「作らせる」ことはあっても、「決めさせない」ということです。

バグ報告を整形する仕組みは、ドメイン知識も実装コードも読まないことを最初から明示的なルールにしています。テスターから報告された内容を整形することに徹し、原因の推測や実装コードの参照はしません。ドメイン知識や実装から得た情報を Issue に書き加えると、テスターが実際には確認していない内容が報告に混ざり込んでしまうためです。

もう一つの共通ルールが、人間の承認を必須にするワークフローです。仕様の Issue 化、バグ報告の整形、テスト設計の振り返りは、いずれも Issue やプルリクエストを作成する前に、タイトル・ラベル・本文案を提示してユーザーの承認を得るステップを必須にしています。 AI が下書きを作ることと、それを採用するかどうかを決めることは、明確に分けられています。

この2つのルールに共通しているのは、 AI に任せる範囲を「作業」に限定し、「判断」は人に残すという考え方です。この設計思想は、 AI 活用の範囲が広がった今も最初のバージョンから一貫しています。

試して、学んで引き直した線 ─ 一次調査を外した理由

すべての線引きが、最初から設計として決まっていたわけではありません。試してみたうえで、現場の反応から引き直した線もあります。バグ報告を整形する仕組みにまつわる、あるエピソードがその代表例です。

この仕組みはもともと、テスターの負担を減らすために作られたものです。初期バージョンでは、その延長として Devin に一次調査、つまり不具合の原因を推測する作業まで任せていました。エンジニアの負担も併せて減らせるのではないか、という期待からの拡張です。ところがトライアルに協力したエンジニアからは「認知負荷が上がる」「ノイズになる」というフィードバックが寄せられ、 AI が提示する原因の推測が、かえって調査を妨げていることが分かりました。

このフィードバックを受けて、バグ報告を整形する仕組みは、原因カテゴリを尋ねることも書くこともしないルールへ変更されました。原因の判断には、コードとプロダクトの両方を理解しているエンジニアの調査が必要であり、テスターだけでは決められないという理由からです。

このエピソードが示しているのは、「最初から役割を絞っていた」のではなく、「一度範囲を広げてみて、現場の反応から絞った」という経緯です。QAチームの設計思想は、机上ではなく実際に使ってみたフィードバックによって磨かれています。テスト設計を振り返る仕組みも、 AI の初回ドラフトと人間の最終修正の差分から、見落としていた観点や新しいドメインルールを抽出しており、線引きの引き直しそのものを継続的なプロセスとして構造化しています。

そもそも引けない線 ─ AIが自分の限界を申告してきた話

QAチームのドキュメントには、テスト環境のセットアップ手順のように、実際に手を動かして確認しないと正しさを保証できない手順書があります。こうした手順書には「最終確認 : 2026-08」のように、人間が実際に試して動作を確認した年月を記録する運用があり、この運用ルールには少し変わった生まれ方をした背景があります。

もともとは Devin にドキュメントのドラフトを作らせていたところ、 Devin 自身がこの一文を書き加えてきました。「AIエージェントは認証が必要なテスト環境に入って手順を実行できないため、この日付を更新しない」という内容です。人間が指摘する前に、 Devin 自身が自分にはできないことを申告してきたことになります。

AI活用をめぐる議論では、 AI が自信満々に間違った情報を出すことを心配する文脈のほうが多く語られます。今回のケースは逆で、聞かれる前から自分にはできないことを申告してきた珍しい事例です。QAチームはこの提案をそのまま採用し、 CLAUDE.md に正式なルールとして明記しました。

このエピソードから読み取れるのは、「AIにやらせない」という線引きが、常に人間の側からの管理や制約だけで成り立っているわけではないということです。 AI 自身が自分の限界を自己申告できる状態を作っておくことも、見極めを続けるうえでの一つの手段になり得ます。

おわりに

QAチームの AI 活用は、何でも任せるという方向には進んでいません。「やらせる」「やらせない」「やれない」を都度見極め、その境界を明文化し続けるプロセスだと考えています。この見極めは一度で完結するものではなく、新しいスキルやエージェントを迎えるたびに繰り返し問われ続けます。

この見極めは、 AI が参照するドキュメントの表記や運用ルールを地道に整えておくといった、地味な下支えがあって初めて機能します。 AI が読むドキュメントは、記述が壊れてもエラーにはならず、気づかないまま品質が落ちる形でしか問題が表面化しないためです。派手さはありませんが、こうした地道な整備の積み重ねが、 AI に任せる範囲の見極めを機能させ続けています。

本記事で紹介した内容は、QAチームが今の時点で正しいと考えている見極めにすぎず、確証があるわけではありません。 AI の進化は速く、数か月後には別のやり方に変わっている可能性もあります。同じように AI との役割分担に迷っている方にとって、何か気づきを得るきっかけになれば幸いです。