「Active Coverage」のご紹介：エージェント型開発のスピードに追従する品質

本日、mablは「Active Coverage」をリリースしました。これは、2017年のmablサービス提供開始以来、最も重要な進化となります。

Active Coverageとは、自ら構築し、自ら実行し、自己修復するワークフローです。これは、すべてのエンジニアリングおよび品質管理のリーダーが今抱えている疑問「開発のスピードが、もはや後戻りできない閾値を超えた今、どうすればテストスイートを機能させ続けられるのか？」に対するmablの答えです。

新たなギャップ

過去1年間にAIコーディングツールを導入していれば、mablがここで提起している課題を実感されているかと思います。コードのリリース速度は加速し、プルリクエスト（PR）は絶え間なく作成され、その過程で、(新機能に伴う新規テストの作成や、画面変更に伴う既存テストのメンテナンスといった)テスト自動化の作業が追いつかない状態になってしまいました。これは構造的なミスマッチです。これまでのテスト自動化は、人間が人間の速度でコードを書く世界のために構築されたものであり、今日のほとんどのチームが依存しているテストインフラは、AIコーディングエージェントが動作するペースに合わせて設計されたものではありません。

私たちはこの問題を内部から熟知しています。mablは社内でエージェント型開発を採用しました。私たちは顧客と同じツールとワークフローを使ってmablを構築しており、顧客が今直面しているのと同じ結果を経験しました。プルリクエスト（PR）の数は3倍に増え、テストスイートは追いつくのに苦労し、人間の手作業によるトリアージが追い付かないほどのスピードで、失敗が積み重なっていきました。 mablのCTOは、その経験が実際にどのようなものだったかについて記事にまとめています。Active Coverageは、この問題を解決するために私たちが構築したものです。

Active Coverageが実際に意味すること

Active Coverageとは、mablの各機能が継続的に連携して機能したときに得られるものです。テストの作成、失敗の分析、テストの復旧、そしてテストの実行が、人間による引き継ぎサポートなしに、単一のループとして実行されます。AIが運用業務を担う一方で、チームは重要な事項——何を保護すべきか、アプリケーションがどう振る舞うべきか、そして実際の障害がどのようなものか——を管理し続けます。

今日、「エージェント型テスト」を謳うプラットフォームの多くは、チームに複数のエージェントの管理や引き継ぎの調整を自ら行わせるか、あるいはテスト対象のコードを生成したのと同じAIコーディングエージェントにテスト作成を委ねています。どちらのアプローチも、スケーラブルなテスト基盤として機能するものではなく、エージェント型開発のスピードに合わせてスケールすることもできません。

各機能の役割と、チームがそれを利用することで何が変化するかを以下に示します。

エージェント インストラクション

mablが提供するすべての機能は、それが動作するコンテキストによってその価値が決まります。アプリケーション（ユーザーにとって重要な点、エッジケースの扱い方、チームが従う規約など）を理解していないプラットフォームは、「大体合っているように見えるだけで」完全に信頼できないテストを生成してしまいます。


「エージェント インストラクション」機能により、チームは品質基準(テスト全体にかかわるルールや方針、独自の観点など)を一度設定するだけで済みます。個々のテストを作成するたびに、プロンプトで細かく指示を出す必要はなく、mablが作成するすべてのテスト、分析するすべての失敗、試みるすべてのリカバリに対して、その基準を「アプリケーションのコンテキスト」として自動的に適用させることができます。ここでは2つのレイヤーが連携します。 アプリケーションサマリーでは、mablが実際のテスト活動から自動的にコンテキストを構築し、エージェント インストラクションでは、チームがアプリケーションのテスト方法を明示的に記述します。これこそが、コーディングエージェントにはない、品質に特化したコンテキストなのです。コーディングエージェントは、自身が書き終えたばかりのコードというコンテキストをもとに動作しますが、mablはユーザーが期待する動作という文脈で動作します。

クラウドテスト生成

テストの作成は常にボトルネックとなってきました。1台のマシン、1つのセッション、そして作成中の待ち時間。AIコーディングエージェントが継続的にコードをデプロイし、カバレッジもそれに追いつく必要がある場合、このモデルは機能しなくなります。


クラウドテスト生成では、デスクトップアプリやローカル環境の設定を一切必要とせず、テストが完全にクラウド上で作成されます。セッションは、ブラウザ、CLI、MCP経由のIDE、またはAtlassian Rovoインテグレーションを介したJiraから直接トリガーできます。チームの誰もが、どこで作業していてもセッションを開始でき、(他の作業をした後で)戻ってくればテストが完成しています。チームが実行できるセッション数に実質的な制限はありません。mablはバックエンドでテスト作成を行い、作成依頼数が多い場合には自動的にキューに入れます。完全なセッションログには、生成中にmablが行ったすべての判断が記録されるため、チームは何が構築されたのか、その理由を理解できます。

テスト生成の品質は、mablチームが継続的に注力してきた分野です。今年初め、チームはテスト生成エージェントをゼロから再構築しました  — そのプロセスについては、リードエンジニアがこちらのブログで解説しています。4月のリリースはその基盤の上に構築されています。エージェントは現在、生成後にテストを再生して、保存前にテストが成功することを検証し、その過程で自己修正を行います。他のAIシステムと同様に、エージェントはより多くのコンテキスト（エージェントへの指示、アプリケーションの概要、既存のテスト資産など）を得ることで強化されますが、新規セットアップから本番環境対応のテストまでのギャップは、かつてないほど小さくなっています。

実行時リカバリ

すべてのテストの失敗が、実際の失敗であるとは限りません。特定顧客向けのクーポンの表示や、初心者向けのガイド機能といった、特定タイミングで表示されるモーダル、前回使用した絞り込み条件の自動適用、クリック可能にもかかわらず、準備が整っていないと何も実行されないボタン……こうした環境要因がテストを中断させ、ノイズを発生させます。実際に何が、なぜ壊れたのかを突き止めるには、誰かが調査を行う必要があります。

ランタイムリカバリーは、実行中にこれらの障害を自動的に処理します。mablが「あるべきでない事態」を検証している場合、リカバリーを試みません。テストの意図が対応を決定します。すべてのアクションがログに記録されるため、チームは何が変更されたかを常に把握できます。デフォルトモードは「リスクゼロ」です。mablはリカバリを試み、すべてをログに記録しますが、チームがさらに信頼する判断を下すまでは、テストは依然として失敗としてマークされます。チームが自律的なリカバリの準備が整った場合、そのオプションを設定可能です。

対話型の結果分析

mablは常に失敗を自動的にトリアージし、実行ごとに根本原因の分析と推奨事項を表示してきました。この基本機能は、もはや必須の要件となっています。今変わるのは、初期分析の後に何が起こるかです。

結果の確認体験は、今や「対話」を中心に構築されています。障害が発生すると、チームは個々のテストやテストスイート全体に対して詳細を確認するための質問や、人間の視点からの提案を投げかけることができ、mablは対話が進むにつれて仮説を立て、エビデンスを収集することで、掘り下げながら調査を進めていくことができます。「前回のデプロイでは動作していたのに、今回は何が壊れたのか？」や「これは一時的な不具合か、それとも真のリグレッションか？」といった質問に直接回答が得られ、分析には裏付けとなるチャートやスクリーンショットも含まれます。完全なレポートをエクスポートして共有することも容易なため、リリース決定が行われる際に、関係者が状況を把握できます。

Atlassian Rovo との統合

多くの品質ワークフローでは、依然として作業を行っているツールを離れ、別の場所で情報を探し、手動で持ち帰る、といったように複数のツール間を渡り歩かなければなりません。特にリリース決定においては、その手間が積み重なります。

mablのテストインテリジェンスは、Atlassian Rovoを通じて、JiraやConfluence内で直接利用できるようになりました。チームはAtlassianのツールを離れることなく、テストの実行をトリガーし、失敗の原因を調査し、カバレッジを確認し、リリースの準備状況を評価できます。チケットから実行をトリガーし、コンテキストに沿った根本原因を特定し、結果を自動的にフィードバックするまでのワークフロー全体が、Jira内でエンドツーエンドで完結します。

8年にわたるAIネイティブ開発からのインサイトを反映

これら5つの機能は、2017年からAIネイティブへの投資を積み重ねてきたプラットフォームの一部であり、1月以降にmablがリリースした20以上の追加機能と共に提供されます。mablと、最近AIレイヤーを追加した他社プラットフォームを比較してみてください。AIがあらゆる意思決定にどれほど深く統合されているかに違いが現れています。要素間の相互作用、アサーションロジック、障害のトリアージ、リカバリ動作——これらは、テストランナーの上に重ねられた単なる機能追加ではありません。それらがまさにテストランナーそのものなのです。

この分野の他のプラットフォームは、既存の自動化インフラの上にAI管理レイヤーを後付けしているに過ぎず、結果のオーケストレーションや調整や依然としてチームに丸投げされています。一見すると似たような機能に見えるかもしれませんが、それらはユーザー自身が試行錯誤しながら環境を構築し、終わりのないメンテナンスを背負い続けることを前提としています。一方、AIネイティブなmablであれば、すぐに使える状態で機能が提供されているだけでなく、そのインテリジェンスがチームに代わって複雑な処理を担い、今後も継続的に進化し続けます。

「Active Coverage」が本日リリースされました

本日リリースされるすべての機能は、エージェント型開発のあらゆる段階にあるチームのために構築されています。拡大するテストスイートの管理、手に負えなくなったメンテナンスの負担への対処、あるいは人間のチームが手動で検証できる速度を超えてプルリクエストがマージされるワークフローの運用など、どのような状況でも対応可能です。

エンジニアリングリーダーは、パイプラインに合わせて自動的にスケールする検証レイヤーを手に入れます。品質保証チームは、インフラストラクチャ構築に費やす時間を減らし、実際に判断力を必要とする作業により多くの時間を割くことができます。

すでにmablをご利用の方は、ログインしてプラットフォーム全体の新機能をご確認ください。導入を検討中の方は、mablの営業にご相談ください 。