こんにちは。UbieでQAエンジニアをしているMayです。
私はこれまでのキャリアで、多くの自動テストの運用・保守やローコードツールを使った自動テストの導入に携わった経験はあったものの、複雑なシステムを相手に、ゼロから一人でテストツールを開発するスキルは、正直なところありませんでした。
しかし、AI開発エージェントと一緒なら、私にもテストツールが作れました！
今回は、AIと一緒に、無限のテストパターンをランダムに実行するツールを作ってバグをたくさん見つけた話を書いていきます。
はじめに
Ubieでは現在、生活者向けwebアプリ「ユビー」の中心である「症状チェック」機能のエンジンを、新しいものに移行する計画が進んでいます。私もそのプロジェクトに携わっています。
症状チェックは、複数のマイクロサービスと連携しながら一問一答を進め、最終的に結果画面を表示します。表示内容はフロントエンド側で組み立てており、ブラウザ上で保持される状態情報も活用しています。APIを直接叩くだけでは、こうした実際のユーザー環境での挙動を再現できません。
ユーザーの回答に応じて質問のパターンが動的に変わるため組み合わせは無限大であり、人手での網羅的な確認は不可能です。当初のテスト計画では、重要なパターンに絞ってテストを行ったうえで、本番環境でモニタリングしながら不具合をあぶり出す作戦を立てていました。
「全数テストは不可能」と割り切りつつも、不安はつきません。プロジェクトチーム内では、「なんとか機械的に、リリース前に品質を保証できないか」という声がずっと上がっていました。
しかし、実装やテストといった現在の計画を遂行するだけでも手一杯の状況でした。「もしかしたら、AIに要件を伝えたら作ってくれるかもしれない」と考え、AI開発エージェントに、相談してみることにしました。
AIに「要求」を伝えてみた
私がAIに伝えたのは、具体的な実装方法ではなく、課題の背景と目的でした。
「症状チェックの新しいエンジンを開発している。エンジンだけが変わるので、ユーザーに見える内容は新旧で変わらないことを想定している。これを検証するために、あらゆるパターンで、新旧エンジンで同じ操作を実行して、表示されている内容を抽出し、差分を比較したい。」
私はあくまで「要求」を伝え、AIがどう「実装」を提案してくるか、その振る舞いを見ることに徹しました。
すると、AIはこんなアイデアを提案してくれました。
「各質問の文面をハッシュ化して、それをシードに回答をランダムに選ぶ方法はいかがでしょうか？」
正直なところ、この「ハッシュ化」というアイデアを聞いても、私はすぐにはピンときませんでした。「それをやると、本当に同じ質問には必ず同じ回答をしてくれるようになるの？」と、AIに質問を重ねた記憶があります。
道筋がはっきり見えたわけではありませんでしたが、AIが「できます」と答えるので、まずはこの方針でツールを作ってもらうことにしました。今回の目的は、あくまで移行プロジェクトを安全に進めるための一時的なテストツールです。完璧な設計でなくとも、まず動くものを作って、私たちが得たい結果が得られるかが何より重要だと考えたのです。
「ぶんまわしくん」の誕生と最初の発見
AIにサポートしてもらいながら、最初のバージョンのツール、通称「ぶんまわしくん」が完成しました。
このツールは、新旧それぞれのエンジンに対して、シナリオに書かれたパターンの数だけ以下の手順を繰り返します。
- トップページから問診を開始する
- 表示された質問文からハッシュ値を生成する
- ハッシュ値 + シード値を組み合わせて、選択肢のインデックスを決定論的に計算する
- 計算されたインデックスに対応する選択肢を選んで回答する
- 最終画面に到達するまで2〜4を繰り返す
- 最終画面に表示されたテキスト情報をすべて抽出し、新旧で差分がないか比較する
実際にツールを動かしてみると、予想していた以上の差分が検出されました。検出されたのは、例えば以下のような、大小さまざまな「違い」でした。
- 特定の質問文のわずかな違い
- 選択肢の表現や順序の違い
- 特定の画面におけるスキップボタンの有無
- 同じ回答でも、新旧で表示される質問や結果が異なるケース
これらは、人手でテストしていたら見逃してしまったかもしれない、細かいけれど重要な違いです。特に「同じ条件でも表示される質問が異なる」といった挙動は、重要ながら条件がニッチ過ぎて見つけるのが難しいものでした。
改善サイクルの始まり
パターンは無限にあるので、毎晩「ぶんまわしくん」を実行することにしました。一晩に100パターン以上、眠らずに実行してくれます。
そうすると今度は、結果を一つひとつ確認するのが大変になってきます。そこで、検出結果を一覧で確認しやすいように、HTML形式のレポートを出力する機能を追加しました。
自分で作ったツールを自分が使いやすいように改善していく、というサイクルが生まれました。
比較対象の拡張もしていきました。チームにリクエストを呼びかけたところ、たくさんの要望が集まりました。
「結果画面のソリューション提案に差異がないか確認したい」
「ブラウザに保存されている状態情報にズレがないか確認したい」
「送信されているログ情報も比較したい」
AI開発エージェントに相談しながら機能を追加していき、検証できる範囲を広げていきました。
当初はテキストの差分比較だけでしたが、今では内部的な動作まで検証できるようになっています。今も毎日実行しながら、機能拡張を続けています。
エンジニア内での共有
このツールについて、社内のエンジニア定例（TechMTG）で共有したところ、たくさんの反響をもらいました。
自分で作ったツールがチームの課題解決に貢献し、「すごい」と認めてもらえたことは、素直に嬉しかったです。
実装に関するツッコミもいただきました。
これは完全に私のスキル不足。永続的に使うことになるようであれば、エンジニアの協力も得ながらリアーキしようと思います！
AIと働く、ちょっとしたコツ
今回の経験を通して、AIに「正解」を教えてもらうのではなく、AIを「壁打ち相手」や「相談役」だと思うことが大事なのだと感じました。
-
「How（どう作るか）」より「Why（なぜ）」と「What（何がしたいか）」を伝える
私が伝えたのは「こういうツールが欲しい」という要求だけでした。具体的な実装方法を決め打ちせず、背景や目的を丁寧に伝えることで、自分では思いつかなかった「ハッシュ化」のようなアイデアを引き出すことができました。 -
最初から完璧な100点を求めない
AIの提案の確からしさを検証するよりも、まずは60点でいいから動くものを作ってもらい、そこから対話を重ねて100点に近づけていく。この「まず作ってみる」という進め方が、結果的に近道になりました。 -
最後は、自分の「こうしたい」を大切にする
AIはあくまでツールです。最終的に「どうしたいか」を決めるのは自分自身。AIの提案に違和感があれば「なぜそう思うの？」と問いかけ、自分の考えを伝える。その対話のプロセスが、ツールをより良いものにしてくれたと感じています。
おわりに
「ぶんまわしくん」の開発を皮切りに、テスト用のデータを投入するデータ駆動ツールも開発しました。AIのおかげで私の「できること」が格段に増えたことを実感しています。そして「ぶんまわしくん」はSREのメンバーから「本番環境の正常性監視にも使えないか」という声が上がるなど、当初の目的を超えてチームの資産になりつつあります。
AIとの協業が当たり前になった今、私たちの役割は、AIに「何をさせるか」を指示するだけでなく、AIと共に、「何を達成すべきか」という目的そのものをデザインすることに移っているのかもしれません。
一方、AIが提案する「どう作るか（How）」に対しても、より深く思考し、最適な方法を自分で選べるようになることも大切です。
AIというパートナーと一緒に、これからもたくさん学び、試行錯誤していきたいです。
おまけ
これを使って図解してもらった。AI開発発アゼント、惜しい👀
Discussion