UbieでQAエンジニアをしているMayです。
Ubieでは、「テクノロジーで人々を適切な医療に案内する」というミッションの実現に向け、症状検索エンジン「ユビー」などのプロダクトを開発しています。事業が急成長するなかで、開発の質とスピードの両立は欠かせません。AI活用が当たり前になっていく中、Ubieでも「AI主導開発」を掲げ取り組んでいます。今回は「AI主導開発」の一角をなす、「自律テスト」についてお話します。
AI-native Engineeringの到来とUbieの戦略
最近、AIを使ったソフトウェア開発が、いよいよ現実的になってきました。AnthropicとCursorのエンジニアは「2027年までにほぼ100%のコードがAIによって書かれる」と予測し[1]、AnthropicによるClaude4の紹介では、AIエージェントが7時間自律駆動してタスクを完了したという楽天の実績も報告されています[2]。
Ubieでもこの流れは不可逆なものだと考え、「AI主導開発」という名前で、AIを前提とした開発プロセスへの変革を進めています。
今回は、その取り組みの一つである「自律テスト」について、私たちが開発しているAIテストエージェント "TestAgent" のアーキテクチャと、直面している技術的な課題を紹介します。
AI主導開発を支えるエージェント・エコシステム
私たちが目指す「AI主導開発」は、単一の万能なAIエージェントがいるわけではなく、それぞれが特化した役割を持つ複数のAIエージェントが連携するエコシステムで成り立っています。このエコシステムの全体像は、Ubieのエンジニアであるyukuの発表資料でも詳しく解説されています。
その中心にいるのが、Ubieが内製している実装AIエージェント「Uvin」です。Uvinは、PBI（プロダクトバックログアイテム）に記述された要件を解釈し、実際のコードを生成する役割を担います。
Uvinによる開発が活発化すると、次に問題になるのがテスト環境の奪い合いです。これまでは共有のQA環境を使っていましたが、複数の開発が同時に進む中でコンフリクトが発生し、開発のボトルネックになりかねません。この問題を解決するため、UbieではPR（プルリクエスト）ごとに独立したプレビュー環境を自動で払い出す仕組みを構築しました。これにより、各変更が他の開発に影響を与えることなく、独立して検証できる基盤が整いました。
そして、このプレビュー環境上で、Uvinが生成したコードの品質を保証するために登場するのが、テストを担うAIエージェント「TestAgent」です。
こんなふうに、「Uvin（実装）」→「プレビュー環境（実行基盤）」→「TestAgent（テスト）」という流れで、AI主導開発のサイクルが回り始めています。
テストを担う"TestAgent"のアーキテクチャ
TestAgentは、このエコシステムの中で「テスト」を担うエージェントです。テストにはいくつかのテストレベルがありますが、今回はE2Eテストを対象としました。E2Eテスト（システムを完全につないだ状態でのテスト）には、開発によって既存プロダクトが壊れていないかを確認するリグレッションテストと、変更や新しい機能に対して「今回はどこを重点的に見るべきか？」を確認するテストがあります。今回のTestAgentがスコープにするのは、後者の「毎回発生する差分に対して、テストを考える・設計する」という、これまで人間が暗黙的に行っていた思考プロセスをAIに任せ、さらに実行もしてもらうというアプローチです。
TestAgentはGitHub Actionsのワークフローとして実装しており、そのプロセスは以下の通りです。
- インプット: PRごとに自動生成されたプレビュー環境のURLがコメントされると、TestAgentが起動します。インプットとして、PRの情報、ソースコード、そしてAIの知識ベースとなるリポジトリ内の「テスト戦略ドキュメント」を読み込みます。このドキュメントには、プロダクトの品質目標やテストピラミッドの定義が記述されています。
- テスト分析・計画・設計: 受け取った情報をもとに、E2Eテストの計画を立てます。どのようなテストの観点が必要かもリストアップします。
- テスト手順生成: テスト計画とソースコードを分析し、E2Eテストの具体的な実行手順を記述した「テスト実行ガイド」を内部的に生成します。
- テスト実行・報告: 生成されたテストガイドに従って、Playwright MCP（Multi-turn Conversation Protocol）が提供するツール群（クリック、テキスト入力、アサーションなど）をAIが選択・実行し、ブラウザを操作します。最終的に、実行結果とスクリーンショットをまとめたレポートをPRにコメントします。
"TestAgent"の思考プロセスの例
「特定のページにアクセスしたユーザーを、外部サイトへリダイレクトさせる」という機能に対してTestAgentがどのように活動したのか、実際に生成されたレポートをもとに紹介します。
まず、TestAgentはPRの説明文と差分を解析し、変更内容を理解します。このテストで何を確認したいのかを明らかにします。
🧪 E2Eテスト分析結果
テスト対象: XXXX用リダイレクト追加
変更ファイル: src/pages/redirect/notif/[id].tsx
変更内容: redirectUrlsオブジェクトに新規エントリー追加
E2E検証範囲: 新規リダイレクトURLのブラウザ遷移動作とユーザーエクスペリエンスの確認
TestAgentは、コードの変更箇所から「新しいリダイレクト先が追加された」ことを理解し、検証すべき範囲を「ブラウザ上でのリダイレクトの遷移動作」に限定しています。
次に、この変更に対してどのようなテストが必要かをリストアップします。
🧪 E2Eテスト観点・判定基準
1. 新規リダイレクトURLへの正常遷移
期待値: /redirect/notif/new-campaign-id にアクセス時、https://partner-site.example.com/ に正常リダイレクト
2. 既存リダイレクト機能の継続動作
期待値: 既存ID（例：existing-campaign-id）が引き続き正常動作
3. 無効IDでの404エラーハンドリング
期待値: 存在しないIDでアクセス時、/404ページに遷移
TestAgentが、単一の機能追加だけでなく、既存機能への影響（リグレッションテスト）や異常系のハンドリングも考えていきます。合わせて、TestAgentは「何をテストしないか」も明示しています。
⚠️ E2Eテスト範囲外
テスト戦略ドキュメントに基づき、以下は今回のE2Eテストでは確認せず、該当するテストレベルに委任：
- イベントログ記録: イベントログテストはページレベルテスト（Vitest）で担保
- APIレスポンス検証: API呼び出しはフックテスト・ビジネスロジックテストで担保
- ...
これは、リポジトリ内の「テスト戦略ドキュメント」に定義されたテストピラミッドの原則に基づいています。しかし、この背景には「下位レベルのテストの自律的な実装がまだ追いついていない」という現状の課題も反映されています。理想的には、実装AIが生成した単体テストなどをレビューし、E2Eでは真にE2Eでしか確認できないことに絞り込むべきですが、現状ではその過渡期にあるため、やらないテストとして意図的に明記している側面もあります。
これらの分析・設計を経て、最終的にPlaywright MCPが参照するテスト手順（テスト実行ガイド）が生成され、テストが実行されます。
📝 実行結果詳細
- Preview環境接続確認: 成功 ✅
- 新規リダイレクトURL（new-campaign-id）テスト: 成功 ✅
- 既存機能レグレッションテスト（existing-campaign-id）: 成功 ✅
- エラーハンドリングテスト（無効ID）: 成功 ✅
このように、TestAgentは単なるテスト実行ツールではなく、テスト戦略に基づいて自ら思考・設計するパートナーとして機能し始めています。
最大の課題：テストの質を決定する「インプットの質」
この取り組みは、まだまだ初期段階で課題も山積みです。なかでも一番大きな課題が、テストの質を左右する「インプットの質」 です。
現状のTestAgentは、インプットの主な情報源がPRの差分情報やコメントに限られています。そのため、実装の詳細（How）に基づいたテストは可能ですが、その変更が目指す本来の目的（Why）に沿ったテストが十分にできていません。
先日、このTestAgentを社内のエンジニアが集う技術情報共有会（TechMTG）で発表し、フィードバックを募ったところ、まさにこの点について議論が白熱しました。
Q. 「このテストエージェントは何をもって『精度100%』とするのでしょう？仕様通りに動くことの検証（Verification）ですか？それとも、ユーザーの要求に合っているかの妥当性確認（Validation）ですか？」
A.「E2Eテストにおいては、妥当性（Validation）を見るべきだと考えています。そのためには、AC（受け入れ条件）など、人間が何を求めているかの情報が不可欠です。だからこそ、チケットをちゃんと書く、といった人間側のレバーが重要になります」
この課題に、私たちはエコシステム全体でアプローチしようとしています。
短期的な解決策として、まずPRのテンプレート自体を改善することを計画しています。実装AIであるUvinは既にJiraからPBI情報を取得していますが、そのアウトプットであるPR本文に、テストに必要な「なぜこの変更が必要か(Why)」や「受け入れ条件(AC)」といった情報が構造化されて含まれるようにします。これにより、TestAgentは実装がAIか人間かに関わらず、常に質の高いコンテキストをインプットとして受け取れるようになります。
また、Ubieでは、プロダクトやチームのコンテキストを深く理解した「AIパートナー」と開発者が対話しながらPBIを共創する取り組みを進めています。一部のチームでは既に精度の高いPBIを生成できるAIパートナーが生まれていますが、これを全社的な仕組みとしてスケールさせることが次の課題です。チームごとに特化したAIパートナーが当たり前に存在するようになれば、PBI自体がAIにとって非常にリッチなコンテキストを持つようになり、TestAgentはその意図を正確に汲み取って、より本質的なテストを計画できるようになるはずです。
このように、テストのインプット品質の問題は、テストプロセス単体ではなく、開発の上流からAIを組み込むことで解決していくべきだと考えています。
その他の技術的課題
「インプットの質」の他にも、解決すべき技術的な課題はいくつかあります。
テストピラミッド全体の自律化
現在のTestAgentはE2Eテストにフォーカスしていますが、品質とコストのバランスを考えれば、テストピラミッドの下位で多くのテストを担保すべきです。この課題に対し、実装AI（Uvin）が適切な単体・結合テストも生成することや、テストの不足を指摘する「レビューAI」の構築など、テストピラミッドの各層をAIによっていかに最適化していくかを考える必要があります。
テスト設計の高度化
現状のTestAgentは、探索的テストに近く、PRの差分などから動的にテスト項目を生成しています。同値分割や境界値分析といった体系的なテスト技法を用いるまでには至っておらず、「AIにどのようにして網羅的かつ効率的なテスト設計を行わせるか」は、これからの大きなテーマです。
テストデータ生成の自律化
現状のテストは、特定のテストデータを必要としない、あるいは静的なデータで完結するシナリオに限定されています。しかし、実世界の複雑なアプリケーションをテストするためには、状況に応じたテストデータを動的に生成・投入する仕組みが不可欠です。このテストデータ準備も、今後の大きな挑戦となります。
エビデンスの精緻化とレビュー体験の向上
テスト結果の信頼性を担保するためには、エビデンスの確認しやすさが重要です。TestAgentではスクリーンショットを取得していますが、手動テストであれば切り取りで取得するようなものが全画面で撮られていたりと、必要十分とは言いにくいのが現状です。また、GitHub ActionsのArtifactsにzipファイルとして保存されるため、確認に手間がかかります。レビュー体験を向上させるため、スクリーンショットを埋め込んだレポートの生成や、操作前後の差分表示といった機能改善が求められます。
おわりに：失敗を歓迎し、高速に学習する挑戦
Ubieが取り組む「自律テスト」の考え方と、その現在地を紹介してきました。「インプットの質」をはじめ、まだまだ解決すべき課題は多く、AIとの協業を前提とした新しい開発ワークフローをどう設計していくか、日々試行錯誤しています。
Ubieが掲げるValueのひとつに「All In」というものがあります。慣性を捨てゼロベースで物事を考え、コレだと思ったことには失敗を恐れずに大胆に挑戦し、誰よりも早く失敗から学び、高速に学習するというサイクルを回しています。完璧なものを目指すのではなく、まずは動くものを作り、実際に使うことで課題を洗い出し、改善していく。今回の「自律テスト」の取り組みも、まさにその精神で進めています。
私たちは、これらの課題解決に共に挑み、AI時代の新しい開発プロセスをゼロから創り上げていくことに情熱を燃やせる仲間を探しています。
もし、この記事で紹介した技術的な挑戦や、Ubieのこういった文化に興味を持ち、「自分ならこう解決する」というアイデアが浮かんだ方がいらっしゃいましたら、ぜひ一度カジュアルにお話ししませんか。気軽にお声がけください。
Discussion