SETチーム3年間の歩み。Playwright導入からAI自動化の到達へ

はじめに

技術本部 Quality Assurance Engineering Unitの杉本です。SETチームが発足したのは2023年6月。あれから3年が経ちました。最初の成果については以前SETチーム始動 Playwrightで実現した最初の成果 - Sansan Tech Blogで紹介しているので、本記事ではそこから先、この3年で積み上げてきたものと、直面した難しさ、そしてこれからの展望について書いてみようと思います。

3年というのは、振り返ってみると短いようで長い時間でした。フレームワークの選定から始まり、社内への展開、そしてAIエージェントによる自動運用に至るまで、技術の話だけでなく組織や制度、QAという職能の意味合いまで考え続けた3年でもありました。少し長くなりますが、お付き合いいただけるとうれしいです。

この3年でやってきたこと

1. 始まりはBill Oneビジネスカードから

詳しくは前述の記事に譲りますが、ざっくり振り返ると、2人体制でスタートしたSETチームは最初の四半期でBill OneビジネスカードのE2Eテスト自動化を完了させ、2人で半日から1日かかっていたリグレッションテストを15分まで短縮することができました。E2EテストフレームワークにはPlaywrightを選定し、Page Object Model（POM）を採用。「プロダクトエンジニアもE2Eテストを書く」という思想を軸に据えた、最初の小さな成功体験でした。

Bill Oneビジネスカードを最初の対象に選んだのは、当時リリースされたばかりのサービスだったからです。今後機能がどんどん追加されていくフェーズで、リグレッションテストの負荷もこれから急増していくことが見えていました。自動化の投資対効果が一番高いプロダクトを狙った、という言い方もできます。

2. プロダクトへの横展開

Bill Oneビジネスカードでの成果を皮切りに、当社の主要プロダクトへPlaywrightを広げていきました。順序としてはまずBill One全体に波及させ、続いてSansan、Contract One、Eightの順で展開しました。主要4プロダクトすべてにPlaywrightが入っている状態を、3年かけてつくることができました。

プロダクトごとに使用言語も文化も異なる中で、ひとつのフレームワークでここまで横断できているのは、社内でもあまり例を見ないことだと思います。とはいえ、横断するうえで一番の壁は技術ではなく文化でした。「テストにどれだけコストをかけてよいのか」という考え方が、プロダクトによって本当に違うのです。リリース速度を最優先するプロダクト、自動テストへ手厚く投資したいプロダクト、業務委託の方による手動テストを中心に回しているプロダクト。それぞれに事情があり、それぞれに正しさがあります。

加えて、各プロダクトはエンジニアの人数も業務委託の方の人数も多く、役割分担も異なるため、ステークホルダーが非常に多くなりがちです。誰がE2Eテストを書き、誰がメンテし、誰がレビューし、誰が壊れたときに直すのか。こうした役割を、プロダクトごとに改めて握り直す必要がありました。技術的にPlaywrightを入れるよりも、この合意形成のラウンドを回すことのほうが時間も気力も使った、というのが正直なところです。

さらに、主要4プロダクトに加え、Sansan Labs、Auth One、デジタル名刺メーカーといった周辺プロダクトにもPlaywrightが入っていきました。SETはレビューや初期セットアップの支援といった形で関わり、結果として社内でPlaywrightが使われる範囲はじわじわと広がっていきました。

3. プロジェクト型Jump!という仕組み・人の課題に向き合う

ここまで書くと拡張が順調に進んだように聞こえますが、横展開を進めるうえで一番の壁はやはり人の問題でした。SETチームに入りたいという人は決して多くなく、採用も簡単ではありません。そこで、期間限定で他部門からSETに移動し、もとのプロダクトに戻っていく仕組みを導入しました。当初は「留学制度」と呼んでいた仕組みですが、その後社内で整備が進み、現在は「プロジェクト型Jump!」という名称になっています。

プロジェクト型Jump!は4カ月という期間で、これまでにContract Oneから1名が参加してくれました。Jump!参加者がContract Oneに戻ってからは、同プロダクトに自らPlaywrightを導入・運用するというサイクルが生まれ、SETチームが直接書かなくてもPlaywrightが広がっていく動線をつくることができました。体験談の記事もどうぞ。Jump into puddles〜SETエンジニアに転生してみた件〜 - Sansan Tech Blog

ただし、この仕組みで一番難しいのは技術ではなく評価の部分です。本人が一時的に所属している部門から外れるため、誰と・どのように評価を握るのかをあらかじめ決めておかなくてはなりません。さらに、4カ月間で何を達成できたら成功と言えるのかというゴール設定も、事前に合意しておく必要があります。これらを曖昧にしたまま走り出すと、本人が一番苦しむことになります。仕組みとして整備された今も、ここは毎回丁寧に握る必要があると感じています。

4. 少人数で広げきったこと

人の話でもう一点、誇りに思っていることがあります。この3年、SETチームは業務委託の方に入っていただく時期もありましたが、コアメンバーは入れ替わりを繰り返しつつも基本的に3人前後で推移してきました。3人前後で主要4プロダクトと周辺プロダクトをカバーし、さらにプロジェクト型Jump!を展開し、後述するAIエージェント群まで構築できたことは、素直に誇れる成果だと思っています。

少人数だからこそ、自分たちだけで継続することを早々に諦め、留学制度やAIへと思想を寄せられたとも言えます。3人ですべてのプロダクトの手を動かそうとした瞬間に破綻するので、必然的に「自分たちで書かない仕組み」をつくる方向に振り切ることができました。

5. ジョブディスクリプションを作り続けたこと

ここはあまり外に出してこなかった部分ですが、SETでは3年の中で「自分たちはどうあるべきか」というジョブディスクリプションをメンバーと何度も協議し、アップデートし続けてきました。バージョン1、2、3、3.1、3.2と、合計5回作り直しています。

メンバーの入れ替わりがあり、横断するプロダクトが変わり、AIという前提が登場し、走りながら考えが変わる部分もある。だからその都度メンバーと話し、「何をやるべきか」「何をやらないべきか」を必ず再定義して進めてきました。SETの根本にあるのは「技術で品質を保証する」というシンプルな思想で、その品質がいかにエンジニアに届き、会社のバリューとして外に出ていくのか。そこを常に問い直してきました。

技術選定や成果物よりも、このジョブディスクリプションを5回書き直してきたことこそが、3年で一番大事な営みだったと、いま振り返って思います。

6. AIによる自動生成と自動修復

そして、直近の大きな進展がAIの活用です。

きっかけ

正直に書くと、AIに踏み切ったきっかけは綺麗な話ばかりではありません。ひとつには、業務委託に依存している部分のリソースコストを最適化したい、という現実的な事情がありました。もうひとつは、QAがボトルネックと言われがちな構造があり、本当にボトルネックだったかどうかは別として、そう言わせない状態をつくる必要があった、ということです。速度を上げるための自動化、その自動化を回し続けるためのAI、という順序です。

開発中に、PlaywrightからAgent機能が公式リリースされました。世界中で同じ方向に走っている人がいるとわかり、自分たちの方向性は間違っていなかったと確信できた瞬間でもありました。Playwright Agentsについては別記事で詳しく書いていますので、興味のある方はそちらもご覧ください。Playwright AgentsでE2Eテストの民主化を実現する - SEED構想の提案 - Sansan Tech Blog

仕組みの全体像

日々のメンテナンスのため定期実行を回し、結果はGitHub ActionsでSlackとNotionに連携、Notionにスタックされていく仕組みを構築しました。そのうえで、Generator系とOperation系という2系統のエージェントを実装しています。

Generator・テストコードを書くエージェント

Generatorの役割は、Notionのテスト仕様DBに書かれたテストケースから、実際に動くPlaywrightのテストコードを生成し、PRとして上げるところまでを一貫して行うことです。具体的には次のような流れになります。

仕様取得 → 新規ブランチ作成 → コーディング（UIコンポーネントの扱い、要素特定、テストデータ生成・識別などのSkillsを参照）→ 検証ループ（実際にPlaywrightで走らせる）→ 静的解析 → コードレビュー → PR作成。

ポイントは、コード生成をワンショットで終わらせていないことです。生成→実行→エラー→修正、を内部で何度も回し、最終的に全テストが通った状態のものだけがPRに上がるように設計しています。さらに、UIコンポーネントの扱い方や要素特定の作法、データ生成・データ識別といったテスト固有のノウハウを「Skill」としてMarkdownで切り出し、エージェントが必要に応じて読み込む構造にしています。プロダクト固有の構造情報（Page Objectやアーキテクチャ）も別途定義してあり、テスト技法とプロダクト知識を分離するという設計思想を取っています。

Operation・エラーを仕分けし、原因を追い、自動で直すエージェント群

Operation側はGeneratorよりさらに分業されていて、実際にはSorter、Tracer、Healerの3つのサブエージェントが連携して動きます。

1つ目がSorterです。定期実行で出たエラーログをNotionから拾い、既存の修正チケットとの類似性を判定します。エラーが新規なのか、過去に起きていたものの再発なのかを見極め、新規なら新規チケットを起票し、既存なら同じチケットに発生日情報を追記します。これで「いつ、何回起きているエラーなのか」が自動で蓄積されていきます。

2つ目がTracerです。エラーがLocator系やAssertion系のものであれば、フロントエンドリポジトリのGit履歴・PR・Notion上のPBI（プロダクトバックログアイテム）を辿り、対応する変更を探します。スコアリングして「仕様変更の可能性が高い／可能性あり／手動調査推奨」のいずれかを判定し、仕様変更であれば修正提案まで生成します。

3つ目がHealerです。Tracerが出した修正提案を、Git worktreeで隔離された環境に適用してPlaywrightで実行し、通ればそのままPRを作成します。失敗すればチケットに失敗理由を残します。

つまりSorterで「これは仕様変更か不具合か」を見立て、Tracerで「どのコミット・PRが原因か」を突き止め、Healerで「直してPRを上げる」までを自動でやる、ということです。仕様変更による壊れは自動で修復され、不具合の可能性があるものだけ人間にエスカレーションされる。そういう運用フローになりました。

結果として、テストコードの生成も、実行後のエラー仕分け・原因追跡・修復も、ほぼ自動化することができています。なお、このAI運用の取り組みは2026年3月のJaSST'26 Tokyoでも発表しました。生成AIで支える自動E2Eテストの継続運用 - Speaker Deck

苦労したこと

1. コスト削減というものさしのズレ

E2E自動化はどうしても、時間短縮、リソース削減という文脈で語られがちです。確かに最初の成果はそこに表れますし、わかりやすい指標でもあります。ただ実際にやってみるとわかるのですが、テストコードのメンテナンスにかかるコストは決して小さくありません。

QAの世界では、品質が良くなったことを数値で表すのが本当に難しいです。だからこそ、自動化率やテスト工数の削減といった、目に見えやすい指標が成果として持ち上げられがちで、それが本来の目的だと勘違いしてしまう人も少なくありません。結果として、とにかく自動化を進めようという案がどんどん上がってきます。けれど、その自動化したテストを誰がメンテし、何回実行し、どんな安心を担保するのか。その先の未来についてはあまり語られないのです。

なので、SETに自動化してほしいという依頼が来るたびに、同じような会話を繰り返してきました。何回実行することを想定しているのか、そのテストが壊れたとき誰が直すのか、本当に自動化すべきシナリオなのか。中にはこちらがやりたくないだけと受け止めた人もいたかもしれません。それでも、先述した通り、ジョブディスクリプションのおかげで、SETとしての方針は3年間ぶれていません。コスト削減ではなく、何度も繰り返し実行できることそのものが価値である。この強い気持ちで言い続けてきました。

繰り返し実行できることのメリットは、「いつもの仕様通りに動いている」という確認になり、担当者が代わっても安心できる土台になることです。コスト削減が結果的についてくることはあっても、それを目的に置くと、メンテコストとの綱引きで必ず破綻します。

2. 横断ゆえの限界

SETチームは各部門を横断する形で動いていますが、本来E2Eテストのコードを一番うまく書けるのは、そのプロダクトを深く知っているプロダクトエンジニアです。横断チームが3人前後で書き続けるモデルには構造的な限界があり、プロジェクト型Jump!の整備や、AIによる自動修復の構築は、この課題への現実的な回答でもありました。

3. 副産物としての発見

苦労ばかりではなく、副産物として得られたものもあります。E2Eテストのコードが、実質的に仕様書として機能する場面です。「検索した後に検索ウィンドウが表示されなくなった」というような、ドキュメントに落とし込まれておらず、人の記憶も曖昧な仕様について、E2Eテストのコードを読めば過去の挙動がわかる。これは当初想定していなかった効用でした。

3年間で自分自身に起きたこと

少しだけ個人的な振り返りをさせてください。

私はもともとプロダクト開発を長くやってきた人間です。QAというポジションに就いていなくても、品質に頭を悩ませることはずっとありました。ただ、QAとしてのポジションに移り、第三者の視点から改めて品質を問い直す機会を持てたことは、自分にとって本当に良かったと感じています。

JSTQB Foundation Levelも取得しました。正直に書くと、シラバスが直接実務で役に立つ場面はあまりありませんでした。テストケースありきでテストコードを書いてきましたし、プロダクト開発で品質に向き合ってきたため、テスト観点自体が大きく変わるということもありませんでした。

ただ、JSTQBを通じてひとつ強く理解したことがあります。テストという行為に対して、人類はかなり体系的にナレッジを積んできているということです。シラバスに記された膨大な観点・技法・用語の整理は、それ自体が知の蓄積です。そして、ここから先の話なのですが、この体系的なナレッジをAIに持たせれば、AIはテストに関してもっと賢くなれるはずだ、ということもこのタイミングで実感しました。JSTQBは、人間がテストを学ぶためのものだと最初は思っていましたが、いまでは、AIにテストを学ばせるためのものでもあると考えています。

E2Eテストを通して、ユニットテストの重要性については、3年経ってむしろ確信を深めました。E2Eテストでカバーできない粒度の品質保証、リファクタリング時の安全網、仕様としてのコードの読みやすさ、実行速度、いずれを取ってもユニットテストの果たす役割は大きいです。

AIが入ってきて、テストのやり方そのものが大きく変わっていく時代に身を置けたことは、得難い経験でした。手動テストから、Playwrightを使ったE2Eテスト、さらにAIでテストコードが生成される、このテスト手法のあり方の変遷を経験できたことは、この3年を通して一番貴重な体験だったと思います。

これからどうなっていくのか

E2E自動テストは、これからプロダクトエンジニア自身の手によって、あるいはAIの手によって、常に書かれ・修復され続けるものになっていきます。QAだから書く、SETだから書く、というポジションや概念を一度外して、誰でもE2Eテストを書き、メンテナンスできる状態にしていく。これがこれからの時代の潮流になっていくはずです。

E2Eテストの民主化が進むと、エンジニアはコードを書く段階でテストにコミットするシーンが増えていくでしょう。設計・開発・テストというサイクルの中で、テストという工程はむしろ縮小していくと想像しています。これはとても良いことです。リリースサイクルは速くなり、ドメイン知識を深く持ったエンジニアがテストを書くほうが、結果的により高い品質を担保できるはずです。時間がなくて後回しにされがちだったテストが、最初から組み込まれた状態で進むようになる。これは大きな前進です。

ではQAという職能が消えるかというと、私はそうは思っていません。

AIがコードを生成するとき、AIはどうしても「テストを通すためのコード」を書いてしまう可能性があります。あるいは逆に、「コードを通すためのテスト」を書いてしまう可能性もあります。AIを役割ごとに分けて、批判的なレビューを別エージェントに任せる、そういう工夫はしていきますが、それだけではどうしても拾いきれない領域が残るはずです。

そこで重要性を増すのが、人による探索的テストであり、第三者であることだと考えています。プロダクトの内側からは見えない違和感、仕様書にもテストケースにも書かれていない「ユーザーが本当に困るところ」を、第三者の視点で拾いに行く役割。これは、AIが進化すればするほど、むしろ希少価値が高まっていく仕事だと思っています。

ユニットテストやE2Eテストの機械的な実行はAIに任せられる時代になりました。その先で、人がやるべきテストとは何か。この問いに向き合っていくことが、これからのQAという職能の中心になっていくのだろうと思います。

ただ、SETという職能だけで活動していくのは難しいとも思っています。
AIが各職能で平均値以上の能力を出している昨今、一つの職能だけでは手が空いてしまいます。マルチな能力を求められていくのは必然と考えるべきでしょう。私はこのIT業界に身を置き、人より多少長い歴史を持っています。昔はSEとPG、インフラエンジニアぐらいの職種しかありませんでした。また、その境界も曖昧で、私もSEと言いながらもサーバールームに入って電源ボタンをポチることもありました。そして、時代が進み、分業化され、多くの職種が生まれました。それがAIによって昔のような曖昧な職種に戻っていくのかもしれません。