【ITニュース解説】Let the AI click. Don't let it grade.

ソフトウェア開発において、アプリケーションが期待通りに動作するかを確認するテストは非常に重要である。中でも「エンドツーエンドテスト（e2eテスト）」は、ユーザーがアプリケーションを実際に使うのと同じように、一連の操作を通じてシステム全体が機能するかを検証する。近年、このe2eテストに人工知能（AI）を活用するツールが登場し、その有効な活用方法が注目されている。

「e2e」という新しいテストツールは、ウェブアプリケーションだけでなく、iOSやAndroidアプリのテストにも対応しており、GoogleのPlaywrightというテストフレームワークを基盤としている。このツールを使ったテストでは、主に三つの種類のステップを組み合わせて利用する。一つはagent.actで、「TODOを一つ追加する」といった具体的な目標をAIに英語で指示し、AIがアプリケーションを操作してその目標を達成しようとする。二つ目はagent.assertで、AIが画面に表示されている内容を判断し、それが期待通りの状態であるかを検証する。そして三つ目はscreenとexpectで、これらは従来のテストコードのように、特定のボタンやテキストボックスといった画面上の要素（これを「ロケーター」と呼ぶ）を直接指定し、その状態を検証する。

AIに操作を任せるagent.actステップには大きな利点がある。アプリケーションのユーザーインターフェース（UI）がデザイン変更などで変わったとしても、AIは目標達成のために柔軟に操作を試みることができる。さらに、このツールには「リプレイキャッシュ」という仕組みがある。一度agent.actステップが成功し、その結果が従来のコードによる検証で確認されると、AIが行った操作の内容（どのコントロールを操作し、その結果画面がどうなったかなど）が記録される。次回以降のテスト実行時には、AIモデルを呼び出すことなく、この記録を「再生（リプレイ）」するだけで同じ操作が再現されるため、テストの実行が高速になり、AIモデルの利用にかかるコストも削減できる。筆者の実験では、初回実行でAIを一度呼び出した後は、何度も同じテストを実行してもAIの呼び出しは発生しなかったという。これはUIが大きく変更されない限り、非常に効率的だ。

しかし、AIに判断を任せるagent.assertステップには注意が必要である。agent.assertはリプレイキャッシュの対象とならないため、テストが実行されるたびに毎回AIモデルが呼び出されることになる。これは、テストスイート（一連のテストのまとまり）に多くのagent.assertステップが含まれている場合、テストの実行ごとにかなりのコストが発生することを意味する。例えば、40個のAIによる操作と40個のAIによる判断を含むテストスイートでは、操作ステップがすべてキャッシュでリプレイできたとしても、判断ステップは毎回コストがかかり続ける。

さらに問題なのは、AIによる判断の信頼性だ。筆者の経験では、意図的に「Add」ボタンを壊したテストを行った際、agent.actステップは「成功した」と報告した。AIが自身の作業を自己評価する際に、問題がないと判断してしまったのだ。しかし、その直後に記述されていた従来のコードによるexpectステップ、具体的には画面に「1 open」というステータスが表示されることを期待する検証が、「0 open」という実際の表示を検出し、そこで初めてテストが失敗した。この「AIの判断とコードによる検証の間のわずかなギャップ」が、AIをどこまで信頼し、どこからコードで厳密に確認すべきかという、AIを活用したe2eテストの設計における重要な問いを投げかけている。AIは「クリック」のような操作は得意だが、「正しく動作したか」という「グレーディング（採点・判断）」を完全に任せるべきではない、という筆者の主張の根拠がここにある。

テストの失敗は常にアプリケーションのバグだけが原因ではない。このツールでは、テストの失敗を三つの異なる終了コードで区別している。一つは「製品のバグ」（ASSERTION_FAILED）で、筆者の壊れたボタンの例のように、アプリケーションが期待通りに動作しない場合に発生する。二つ目は「AIモデルの接続障害」（MODEL_PROVIDER_FAILED）で、これはAIモデルを提供するサービスへの接続に問題があった場合だ。この場合、テストの失敗はアプリケーションのバグではなく、インフラの問題として明確に切り分けられるため、CI/CD（継続的インテグレーション/継続的デリバリー）環境での問題特定に役立つ。そして三つ目は「記録の陳腐化」（REPLAY_STALE）で、これはUIの要素（例えばボタンの名前）が変更され、キャッシュされていた操作記録が古くなり、再利用できなくなった場合に発生する。この「記録の陳腐化」は、--strict-cacheというオプションを使わないと、AIが古い記録で操作を試みた後に、発見できなかった要素をAIモデルが自動で探しに行ってしまうため、テストは成功するものの、実行に時間がかかり、問題が見過ごされる可能性があるため、CI環境ではこのオプションを有効にすることが推奨される。

CI/CD環境でこのツールを利用する際には、さらにいくつかの注意点がある。デフォルト設定では、AIの操作記録を保存するキャッシュフォルダはバージョン管理システム（Gitなど）の管理対象外となっている。このため、CI環境でテストを実行するたびに、過去の記録が利用できず、agent.actステップが毎回AIモデルを呼び出すことになり、余計なコストが発生してしまう。開発チームは、このキャッシュフォルダを意図的にバージョン管理対象に含める設定変更が必要となる。また、テストが一度失敗した際に自動で再試行する設定がデフォルトで有効になっている場合、その再試行もキャッシュを使わずAIモデルを呼び出すため、コストが二重にかかることになる。

これらの経験と考察を踏まえ、筆者はAIをe2eテストに導入する際の明確なルールを提示する。まず、agent.actは、サインインやウィザードの入力など、テスト対象の画面に到達するまでの「操作」に使うべきである。そして、全てのagent.actステップの直後には、従来のexpectを用いたコードによる検証を必ず記述する。これにより、AIが自己評価で「成功」と誤認するのを防ぎ、同時に操作記録の有効性を保証する。agent.assertは、具体的な文字列や数値では表現できない「意味」の判断（例：チャットボットの返答が質問に適切に答えているか）が必要な場合にのみ、そのコストを理解した上で意図的に利用する。そして、CI環境では必ず--strict-cacheオプションを有効にし、キャッシュフォルダもバージョン管理対象に含めるべきである。

最終的に、AIテストツールを導入するシステムエンジニアは、「どの検証をAIでなければできないのか」そして「どの検証を単なる習慣でAIに任せているのか」を常に自問自答し、AIとコードの役割を賢く使い分けることが重要だ。