mablの「テスト作成エージェント」は、本番環境で9か月稼働した後、アーキテクチャの全面的なリファクタリングを行いました。もちろん、単なる直感に基づいて『コードをきれいに見やすく整理した』といった類のものではありません。私たちは、AI搭載のレビューエージェントを用いて、2,404件の実際の顧客セッションを分析し、具体的にどこに不具合があり、何を修正すべきかを正確に把握しました。このブログでは、大規模な本番データから、実際に機能するエージェントを構築するために学んだことをご紹介します。
本番環境向けAIエージェントの構築において最も難しいのは、単にリリースすることではありません。「使用されるにつれてエージェントが賢くなっているかどうか」を理解することです。
mablでは、ほとんどのテストツールがAIをロードマップに組み込むよりずっと前の2025年春に、最初のエージェント型テスト作成システムをリリースしました。本番環境で9ヶ月運用した後、私たちはこれを一から再構築しました。システムが壊れていたわけではありません（実際、お客様は大きな成果を上げて利用していました）が、当初のアーキテクチャは次なる進化を遂げる時期に来ていたのです。
リファクタリングを行うという決定は、断片的なフィードバックや社内の直感に基づいたものではありません。AI搭載のレビューエージェントを構築し、439アカウントにわたる2,404件の実際の顧客セッションを分析しました。これにより、従来の指標では捉えきれないエージェントの振る舞いの品質(同じ失敗を繰り返すループの有無、エラー回復、アサーションの質、意思決定の一貫性など)を測定しました。データは再構築すべき箇所を正確に示し、アップデートをリリースした結果、リファクタリングが成功したことが証明されました。
第一世代(V1)のエージェントは確かに動作しました。スクリーンショットの解釈、次のステップの決定、ページ要素とのインタラクション、アサーションの生成が可能でした。お客様は毎日このエージェントを使ってテストを作成していました。
しかし、単に「動作する」ことと「大規模な環境でうまく機能する」ことは、必ずしも同じではありません。利用が増えるにつれ、特定のパターンが見られるようになりました。
「テスト保存率」のような従来の指標では、なぜこれらのパターンが発生したのか、あるいはどう修正すべきかを把握することができませんでした。本番環境での利用から得られた行動分析こそが、これらの疑問への鍵でした。
当初のエージェントは、シングルショットパターン（クライアントが状態を送信、サーバーがアクションを返す、クライアントが実行、これを繰り返す）を中心に構築されていました。すべてのAPI呼び出しは「ステートレス（状態を持たない）」でした。モデルは自身の履歴を認識できず、何を試し、何を失敗し、何を検討したかの記憶は限られていました。
これは2025年初頭においては現実的な判断でしたが、モデルの能力が向上し、本番環境での使用によってエッジケースが明らかになるにつれ、これらの制約がテストプロセスに支障をきたし始めました。モノリシックな設計のため、新しいコンテキストやツールを追加するには、複数のファイルにわたる変更が必要でした。一方、ステートレスな実行環境では、エージェントのすべての行動が『過去のコンテキストを持たない、その場限りの判断』になってしまいます。そのため、同じセッション内であっても、直前の自分自身の失敗を記憶し、そこから学習して次の行動を変えることができなかったのです。
新しいシステムでは、モノリシックな構造を、いくつかの基本原則に基づいて構築されたコンポーザブル(組み合わせ可能)なフレームワークに置き換えました。
テスト作成エージェントははるかに軽量となり、エージェントのライフサイクル全体（コンテキストの初期化、ツールの登録、プロンプトの生成、複数ラウンドにわたる関数呼び出しループを通じたモデルの起動、結果の返却）を処理する「共有ベースフレームワーク」上の薄いレイヤーとして機能します。新しいエージェントは、システムプロンプト、デフォルトの機能、およびカスタムロジックを定義するだけで済みます。それ以外のすべては継承されます。
これは単にコードがすっきりするだけではありません。未来への投資でもあります。今回(2026年2月)刷新したのは「テスト作成」を担うエージェントですが、将来的にはテストのデバッグ、メンテナンス、さらにはテスト計画の策定までもが、それぞれ専用のエージェントによって実行されるようになることを見据えているからです。このフレームワークの存在により、今後新しいエージェントを追加する際にも、巨大なモノリスをメンテナンスするのではなく、単なる設定レイヤーを追加するだけで済むようになります。
膨大に広がっていた状態(ステート)オブジェクトは、目的が明確でスキーマ検証済みの「コンテキスト部品」に置き換えられました。これらは、AIに渡すプロンプトを構成するための独立した情報です。具体的には、「作成中のテストシナリオの概要」、「ステップの実行ステータス」、「現在の画面の状態（スクリーンショット、現在のURL、開いているタブなど）」、「ワークスペースの環境設定」といった具体的なデータが、それぞれ単独で機能する情報のかたまりとして保持されています。これらの個々のコンテキスト部品は、システムプロンプトの中で「自分自身をAIにどう説明すべきか」、そして「全体の状況把握(コンテキスト)にどう役立つべきか」を自ら定義しています。
これにより、プロンプトの構築が自動化されます。新しい要素が追加・登録されるだけで、プロンプトの内容も自動的に更新されるのです。スキーマ検証により、実行時に形式の不適切なコンテキストが検出され、下流でのモデルの不可解な挙動を回避できます。
特定のLLM(Geminiなど)に対する直接的なSDK呼び出しを、「LLMプロバイダーの抽象化レイヤー」に置き換えました。各LLMプロバイダーとの接続部分は、リクエストの変換、レスポンスの生成、共通メッセージ形式への再変換という小さなインターフェースを実装するだけです。ファクトリはこれらを統合し、自動メッセージ正規化、組み込みの関数呼び出しループ、ストリーミングサポート、リトライロジックを備えた「統一されたインターフェース」として提供します。
新しいLLMプロバイダーを追加するには、わずかな関数を実装するだけで済みます。利用するLLMプロバイダーの切り替えは、ルーティング(振り分け先)の設定を変更するだけであり、コードの書き直しを必要としません。このアプローチはすでに成果を上げています。異なるモデル間で同じエージェントの挙動をテストし、特定のサブタスクに対してどのモデルが総合的なパフォーマンス(品質・処理速度・コストなど)において最適かを評価できるようになりました。
従来のシステムでは、すべてのツールがクライアント側で実行されていました。新しいアーキテクチャでは、クライアント側とサーバー側のツール実行を分離することで、大幅な機能拡張が可能になりました。
サーバーサイドのツール（利用可能なフローの取得やワークスペース内の既存テスト資産の分析など）は、クライアントとの往復通信を一切行わずに処理されます。クライアントサイドのツールは、クリック、テキスト入力、待機など、ブラウザ内で実行する必要があるアクションを処理します。この分離により、エージェントに高度な知能(インテリジェンス)を組み込み、お客様がクライアントを更新することなく、異なるエージェントタイプ間でそれを共有できるようになりました。
この分離がもたらす影響は、パフォーマンスの向上だけにとどまりません。私たちは、エージェントがmabl固有のデータやパターンをより深く認識できるようにする、内部ツールのサーバーサイドライブラリを構築しました。エージェントの知能を向上させたり、新しい機能を追加したりする場合、それらのアップグレードはサーバー上で即座に行われます。クライアントサイドでのデプロイを一切行わなくても、エージェントはより賢くなるのです。
最も重要な変更点は、エージェントが「ステートフル(状態保持可能)」となり、時間的な文脈を持つ会話履歴を保持するようになったことです。各アクションを孤立したリクエストとして扱うのではなく、モデルは「何を試したか」「何が成功したか」「何が失敗したか」を把握できるようになりました。
このアーキテクチャの転換は、本番データで見られた「行き詰まり(同じ失敗のループ)」問題を直接解決します。エージェントがページ要素をクリックしても何も起こらない場合、同じ失敗したアクションを何度も繰り返すのではなく、「このアプローチはすでに試した。別の戦略を試してみよう」と推論できるようになりました。会話そのものが、セッション内での学習を可能にする状態となるのです。
多くのベンダーは、自社のエージェントがセッション内でどのように振る舞っているかを説明できません。初期判断は適切か？エラーからの回復は効果的か？出力は高品質か？その代わりに、彼らは機能の提供を続け、せいぜい利用状況を測定するにとどまっています。
私たちにはそれ以上のものが必要でした。従来の指標では、エージェントの品質にとって実際に重要な行動パターンが見え隠れしてしまいます。私たちは、エージェントの振る舞いを大規模かつ継続的に測定・改善できるシステムを求めていました。そこで、「レビューエージェント」を構築しました。この第2のAIシステムは、人間のエキスパートが適用するのと同じ厳格さでエージェントのセッションを評価するように設計されていますが、数千のセッションを同時に処理できます。
私たちは、各テスト作成セッションを多角的に評価する構造化された分析フレームワークを設計しました。
この分析を、旧エージェントとリファクタリング後の新エージェントの両方から数百のセッションに対して実行しました。結果が実際のお客様のパターンを反映するよう、mabl社内使用分は除外しました。
データは興味深い事実を物語っていました。「クリーンセッション（同じ操作の繰り返しや操作ミスなくテストが正常に保存されたもの）」は約4.5倍に増加し、深刻な問題を抱えたセッション（失敗のループ、クリック失敗、問題のある削除が複合的に発生しているもの）は90%以上減少しました。
さらに興味深いのは、行動パターンに見られた以下の点です。
無駄な繰り返し(ループ)から抜け出し、問題から自力で回復できるようになった： 旧エージェントでは、テストが最終的に保存できたかどうかに関わらず、途中で同じ操作を無駄に繰り返してしまう割合がはほぼ同じでした。一方、リファクタリング後のエージェントでは、正常に保存されたテストにおける無駄な繰り返しが劇的に減少しました。これは、エージェントがエラーに行き詰まって足踏みするのではなく、別の手段を試して即座に回復できるようになったことを示しています。
クリック失敗からの「自己修復能力」が明確に向上した： 旧エージェントでは、テストが正常に保存できた場合でも、できなかった場合でも、同程度の頻度でクリックの失敗が発生していました。つまり、些細な操作ミス(回復可能)と致命的なエラー(回復不能)の区別がついていなかったのです。一方、リファクタリング後のエージェントでは、正常に保存されたセッションにおけるクリックの失敗が劇的に減少しました。これは、ちょっとしたインタラクションの問題であれば、エージェントが自力で軌道修正できるようになったことを示しています。
アサーションは単に減少しただけでなく、より賢くなった： セッションあたりのアサーション数は大幅に減少しましたが、アサーションの品質は割合にして数ポイントの確実な向上を見せました。エージェントの検証は、何が通用するかを見つけるためにアサーションを乱発するのではなく、より的を絞り、意味のあるものになりました。特定の種類の不適切なアサーションでは劇的な改善が見られました。エージェントがページ要素の表示テキストと実際の値を混同したエラーは80%以上減少しました。
無駄な「ステップ削除」が減り、最初から正しい判断ができるようになった： 旧エージェントは、半数以上のセッションでステップの削除を行っており、しかもその削除操作の半数以上が、かえって新たな問題を引き起こしていました。一方、リファクタリング後のエージェントでは、そもそも削除が必要となる頻度が激減しました。また、削除を行う場合でも、その大部分は「本当に削除すべき不要なステップ」だけを正確に狙ったものでした。つまり、エージェントは迷走して後からやり直すのではなく、最初から「精度の高い意思決定」を行えるようになったのです。
このレベルの行動分析は、AI開発において標準的な手法ではなく、大規模かつ構造化された評価なしには不可能です。数千回のセッションから得られた行動メトリクスのベースラインがあることで、アーキテクチャの変更が行われた際、それが機能したかどうかを推測する必要がなくなります。私たちは、本番システムを測定するのと同じ方法でエージェントの振る舞いを測定します。つまり、デモではなく、データを用いて測定するのです。
ある指標は当初、懸念材料に見えました。リファクタリング後にテストの「保存率」が低下したのです。しかし、レビューエージェントを活用することで、より完全な全体像を把握することができました。
アサーションがゼロのセッションが大幅に増加しました。これらは、アサーション段階に到達する前にユーザーが離脱した、未完了または放棄されたセッションであり、エージェントの失敗ではありませんでした。一方、アサーション段階まで進行したセッションにおいては、保存率が向上し、アサーションの品質も大幅に向上していました。
これは、行動分析がなぜ重要なのかを示す好例です。単純化された集計結果データでは、ユーザーのエンゲージメントパターンは考慮されません。完了したセッション内でエージェントがどのように動作しているかを理解することで、システムを改善するために実際に必要な手がかりが得られるのです。
レビューエージェントは、優先順位付けされたロードマップも提供してくれました。エージェントに必要なツールが不足していたセッションを分析することで、ギャップを特定し、その修正策を構築することができました。タブ切り替え機能（マルチタブワークフローを処理するため）、アクセシビリティツリーをより深く理解するためのARIAスナップショットへのアクセス、mabl LABSの実験的モデルオプションとの要素インタラクションの改善など、これらすべては実際のセッションから得られた知見に基づいています。
AIの技術的負債は従来のソフトウェアよりも早く、複利で増大する：エージェントの構築に利用できるパターンと機能は、数か月単位で進化しています。2025年春には実用的だったアーキテクチャが、2026年初頭には制約となっていました。リファクタリングを計画することは、初期設計の失敗を意味するものではありません。地盤がどれほど速く変化しているかを認識している証拠です。
エージェントの可観測性(オブザーバビリティ)は、メトリクスダッシュボード以上のものが必要：セッションレベルの成功／失敗率だけでは、実際に重要な行動パターン(エージェントが適切な初期判断を下しているか、エラーから効果的に回復しているか、高品質な出力を生成しているか)が隠れてしまいます。構造化されたAIによるレビュープロセスが、どれだけデータを集計しても表面化しないインサイトを明らかにしてくれることがわありました。
コンポーザビリティ(組み合わせ可能性)は不確実性に対するヘッジである：今後６か月で、エージェントの各サブタスクにとって最適なモデルが何になるか、あるいはどのような新機能が追加したくなるかは誰にもわかりません。リファクタリングされたアーキテクチャ(プロバイダー抽象化、コンテキスト管理システム、共有フレームワーク)により、一からの再構築をすることなく、次に来るあらゆる変化に適応できます。
結果だけでなく、振る舞いを測定する：リファクタリング後のエージェントのテスト保存率はわずかに低下しました。これだけを見れば警告サインだったでしょう。しかし、詳細なセッション分析を通じてその「理由」を理解したことで、実際のエージェントの振る舞いがあらゆる品質の側面(評価軸)において劇的に向上していることが明らかになりました。振る舞いへの影響を考慮することで、結果データの意味がより明確になったのです。
従来のソフトウェア開発において、９か月での再構築はアーキテクチャの失敗を意味します。しかし、2025年のAIエージェント開発においては、それは「規律」を意味します。
今日利用可能なモデルの機能、関数呼び出しのパターン、本番環境から得られた知見は、V1をリリースした時点では存在しませんでした。初期のAIシステムをリファクタリングしていない企業は、本番環境の利用から何も学んでいないか、あるいは進化できないアーキテクチャに縛られているかのどちらかであり、その両方が問題です。
コンポーザブルなフレームワーク、プロバイダーの抽象化、および情報をモジュール化するコンテキスト管理機能により、将来の改善は「加算的」になります。新しいエージェント、新しいツール、新しいモデルなどを、コアアーキテクチャに触れることなく追加できます。このリファクタリングによって、私たちはAI進化の次のフェーズを乗り切るためのアーキテクチャの滑走路を手に入れたのです。
さらに重要なのは、それらの改善を検証するための測定インフラストラクチャを構築できたことです。レビューエージェントフレームワークがなくなることはありません。今後も、あらゆるアーキテクチャの変更を評価するための手段であり続けます。
もしあなたがAI搭載のテストツールを評価している立場であれば、今回のリファクタリングの話はむしろ安心材料になるはずです。それは私たちが本番環境で学習し、厳密に測定し、長期的なアーキテクチャに投資する意思があることを意味しているからです。
AIテストツールのベンダーには、ぜひ以下の質問を投げかけてみてください。
mablの場合、答えはすべて「Yes」です。私たちはそれを「Yes」にするために測定システムを構築しました。
レビューエージェントフレームワークは、新しい本番セッションが発生するたびに継続的に評価を行い、行動パターンを分析してエージェントのパフォーマンスを理解します。これは、顧客データでトレーニングすることなく、私たちのアーキテクチャ上の決定に情報を提供します(私たちはテストの内容ではなく、エージェントの「振る舞い」を測定しているのです)。
コンポーザブルなアーキテクチャにより、再構築することなく、新しいモデルの機能に適応できます。これら２つの機能(厳密な測定とアーキテクチャの柔軟性)が組み合わさることで、単に「違う」だけでなく、時間とともに「測定可能なほど向上していく」AIエージェントを構築するための基盤となります。
AIエージェントの分野は非常に進化が早く、今日構築したシステムは明日には進化させる必要があります。目標は、最初の挑戦で完璧なアーキテクチャを構築することではありません。成長できるアーキテクチャを構築し、加えた変更が実際に機能しているかどうかを知るための可観測性(オブザーバビリティ)を持つことです。mablのテスト作成エージェントにおいて、コンポーザブルなアーキテクチャとAI搭載の行動分析の組み合わせは、私たちにその両方をもたらしてくれました。