Devin にE2Eテストの実装を任せる

こんにちは。メルペイ Payment & Customer Platform / Client EM の@anzaiです。
この記事は、Merpay & Mercoin Tech Openness Month 2025 10日目の記事です。
E2E テスト実装におけるDevin活用の現状について紹介します。

はじめに

モバイルアプリケーション開発において、テスト自動化の重要性は言うまでもありません。特に、メルカリアプリのような大規模かつ複雑なプロダクトでは、品質保証の観点からリグレッションテストは欠かせないプロセスであり、その自動化は非常に重要な課題となっています。

本記事では、AIソフトウェアエンジニアである「Devin」を活用してE2E（End-to-End）テスト実装の課題に取り組んだ事例を紹介します。テスト自動化の効率化やAI技術の導入に関心のある開発者の方々の参考になれば幸いです。

メルカリのE2Eテスト実装における課題

メルカリのリグレッションテストとして実施しているE2Eテストは、お客さま体験を保証しつつ毎週行っているリリースを担保する上で欠かせない要素^1ですが、その実装には以下のような課題があります。

• コンテキストスイッチの負荷: 通常の開発業務からE2Eテストの実装に切り替える際に、大きな負担が発生します。
• 実装・実行時間の長さ: E2Eテストを正確に実装するには時間がかかり、テストケースが増えるにつれて実行時間も長くなる傾向があります。
• コードリーディングの困難性: メルカリアプリのリグレッションテストとしてのE2Eテスト実装では、アプリの機能を横断的に理解する必要があります。メルペイには非常に多くのコードが存在するため、エンジニアは自分の担当ドメイン外のコードも読み解く必要がありました。これには多くの時間と、コードの実装意図や仕様の理解が困難な時に担当のチームに確認するコミュニケーションコストがかかります。
• テストケース判断の複雑性: テストケースで書かれている手順や期待値はどのように実装すれば満たしたといえるのか、といった判断には詳細なコード解析や事例の確認が必要になり、多くの時間がかかります。

これらの課題により、開発者の時間が圧迫され、本来注力すべき機能開発に遅れが生じる可能性があります。

AIソフトウェアエンジニア「Devin」によるアプローチ

このような背景から、私たちはDevinに注目しました。

Devinとは何か

Devinは、完全自律型AIソフトウェアエンジニアです。従来のコード補完ツール（GitHub Copilotなど）とは大きく異なり、自然言語による指示だけで、ソフトウェアの設計からコーディング、デバッグ、デプロイまで、開発プロセス全体を自律的に実行できます。

なぜDevinがE2Eテスト実装に適していると考えたのか

今回のE2Eテスト実装において、Devinが特に有効だと考えた理由は以下の通りです：

1. パターン化された実装環境
メルカリアプリのE2Eテストは「ページオブジェクトモデル^2」で実装されており、ある程度決まった形で書けるようになっています。また、すでに十分な量の参考テストケースが存在していたため、Devinが学習しやすい環境が整っていました。

2. コード理解の負担軽減
前述のコードリーディングの困難性でお話しした通り、リグレッションテストとしてのE2Eテストの場合、様々なドメインを横断的に理解する必要があります。
しかし、DevinならACU（計算リソース）が許す限り、どこまでも深くコードを読み続けることも可能です。人間のように疲れることがないのは大きなメリットでした。

eKYC画面におけるE2Eテスト実装事例

具体的な検証として、メルペイのeKYC（オンライン本人確認）機能のリグレッションテストのE2Eテスト化のタスクをDevinに任せてみました。

実施方法

メルカリのテストケースはTestRailで管理されています。そのため、以下のフローでDevinにタスクを渡すフローを構築しました。

① Cursor上からREST APIでTestRailのテストケースを取得
② 取得したテストケースから実装可能なようにタスクを詳細化
TestRail上の情報は人間が直接操作して実行する前提で記載されていますが、Devinが処理可能なフォーマットに変換する必要があり、それにはアカウントのコード上における作成方法や操作手順が重要になります。
③ 公式のAtlassian MCP Server経由でJIRAチケットを作成
④ そのJIRAチケットをDevin が読み、実装作業を開始

TestRailからJIRA、Devinへのデータフロー構成

このフローにした理由は以下の通りです：

1. セッション管理の最適化: 一つのセッションが大きくなりすぎるとDevinの能力が低下してしまうため、テストケース単位で作業を分割することで品質を保つ
2. 実装タイミングの制御: 開発チームのスケジュールに合わせて、実装開始のタイミングをコントロールできる
3. 継続的な改善: 試験的な取り組みだったため、Cursor上で作成したJIRAチケットのフォーマットや内容をみながら逐次JIRAチケット生成プロンプトを改善したい

Devinにテスト実装を任せる際、特に意識した情報は以下の2つです：

前提条件の詳細化

メルペイではさまざまなアカウント状態（年齢、本人確認ステータス、銀行接続状況など）が存在します。そのため、各テストに必要なテストアカウントの作成方法やセットアップ手順について詳しく記載しました。
例）
eKYC未実施の状態 -> XXX() という関数を呼び出してアカウントを生成してください
eKYC実施済みかつ銀行口座接続済みの状態　-> YYY() という関数を呼び出してアカウントを生成してください

完了条件（assertion）のパターン化

テストの操作内容は多様でしたが、完了条件については一定のパターンがありました。そこで以下のような内容を事前に詳しく記載しました：

• 「画面遷移が成功したかどうかの判定方法」
• 「エラーメッセージが正しく表示されているかの確認方法」
• 「各UI要素が期待通りに表示されているかの検証方法」

これらの情報はTestRailsに記載されているテストケースには記載がないため、Cursor上でJIRAチケットに情報を追加するプロンプトを設定しています。

JIRA チケット作成プロンプト一部抜粋

結果

DevinはJIRAチケットの内容に対応するテストコードを含むPull Requestを自動生成しました。生成されたコードを人間がレビューしたところ、以下のような品質でした：

• コード品質: 参考にできる水準で、実装内容も妥当
• テストロジック: 期待していた通りの流れで実装されていた
• ページオブジェクトパターンの適用: 既存のコードスタイルに合致した実装

特に印象的だったのは、複雑な前提条件についてもしっかりと理解し、適切なテストアカウントのセットアップコードを生成できていた点です。現状はシンプルなテストケースの依頼のみですが、試したほとんどのテストケースについて人間の修正なく実装ができました。

さらに、GitHub上で行われたレビューコメントに対して、Devinが自動でコードを修正するといった挙動も確認できました。これは、開発プロセスにおけるコミュニケーションコスト削減への寄与も期待させるものです。

Devinがcommentを確認し、リアクションをつけている

Devin活用の評価：メリットと今後の課題

今回の検証を通じて、Devinを活用するメリットをまとめました。

メリット

• コンテキストスイッチの軽減: E2Eテスト実装にかかる細切れの作業時間を大幅に削減できました。例えば、「業務開始時にDevinに実装タスクを指示し、夕方にレビュー、翌日に結果確認と再レビュー」といった効率的なワークフローを作ることができます。これにより、開発者は他の重要なタスクに集中しやすくなります。
• 反復的な作業の委譲: Devinは、人間なら多大な集中力が必要なコードの追跡や全体像の把握といったタスクを、粘り強く実行してくれます（ACUというリソース制限は存在します）。このような作業をDevinに任せることで、開発者はより創造的な問題解決に時間を使うことができます。

今後の展望

今回は開発者が手元のCursorでタスク生成を行いながらフローを構築しましたが、今後はより完全な自動化を目指しています。

具体的には、以下のような仕組みを検討しています：

1. TestRailのMCPサーバー構築: TestRailの変更を監視して自動的にJIRAチケットを生成
2. JIRAチケット監視機能: チケットの更新を検知して、自動的にDevinのセッションを開始
3. 完全な無人運用: 人間の介入なしに、TestRailの更新からテストコード実装まで自動実行

これにより、テストケースの追加や変更があった際に、開発者が意識することなく自動的にE2Eテストが実装される環境を実現したいと考えています。

まとめ

Devinを使ったE2Eテスト実装の取り組みは、開発効率向上の可能性を示してくれました。特に、コンテキストスイッチの削減や、定型的で負荷の高い作業の自動化は、開発者の生産性向上に貢献する重要なポイントです。

AI技術はまだ発展途上で、Devinも例外ではありません。しかし、その可能性は非常に大きく、今後の技術進歩に期待が持てます。

本記事が、開発現場におけるE2Eテストの課題解決や、AI技術活用の検討に役立てば幸いです。Devinのような新しい技術を効果的に取り入れ、より良い開発プロセスの実現を目指していきたいと思います。

次の記事は @Tさんの「SRE2.0: LLMサービスの信頼性を測る新しい評価指標の紹介」です。引き続きお楽しみください。

参考資料