「合格・不合格」が通じない相手を測る──Tricentisが、AIエージェントを確率で採点し『出荷可否』を返す試作を出した
書く速度が上がるほど、テストが追いつかない。Tricentisがカンファレンスで公開した3つの試作は、スクリプト不要の自律テスト『Aida』と、非決定的なエージェントを確率で採点し出荷可否を返す『AgentScore』が軸。コードを書くAIを、誰がどう見極めるか。
コーディングエージェントが実装を肩代わりし始めた結果、開発のボトルネックは「書く」から「確かめる」へ移りつつあります。書く速度が上がるほど、テストとレビューが追いつかない。ここに正面から手を入れたのが、テスト自動化大手のTricentisです。同社は8月20日、米ダラスで開いた年次カンファレンス「Tricentis Transform」で、品質保証(QA)そのものをエージェント化する3つの試作機能を公開しました。いずれも早期アクセスの実験プログラム「Tricentis Labs」経由での提供で、同社は「開発中の機能であり、将来の商用提供を確約するものではない」と但し書きを添えています。
なぜ「テストする側」までAIに寄せるのか
従来のテストは、人がテストケースを書き、期待値を決め、合否を判定する「決定的」な作業でした。入力が同じなら結果も同じ、という前提が土台にあります。ところがエージェントが生成するコードや、エージェント自身のふるまいは、毎回まったく同じ結果になるとは限りません。この「非決定的」な相手に、従来の○×判定はそのままでは噛み合わなくなります。Tricentisの答えは、テスト工程そのものにエージェントを置き、判定の仕方も作り替えることでした。
公開された3つの試作機能
スクリプトなしでアプリを歩き回る「Aida」
Aidaは、WebアプリケーションとWindowsデスクトップアプリケーションを自律的に探索するエージェントです。特徴は、あらかじめ用意したテストスクリプトや初期設定を必要としない点にあります。人が書いたテスト資産がない領域でも、アプリを自分で操作して回り、不具合やテストの抜け(カバレッジのギャップ)を洗い出し、アプリの健全性を評価します。既存のテストが手薄な画面や、新規開発の初期段階での探索的テストが想定される使いどころです。
エージェントを「確率」で採点する「AgentScore」
今回もっとも新しい発想がこれです。AgentScoreは、AIエージェントを実際のワークフローの中で観察し、そのふるまいを評価します。決定的な合否ではなく、確率的な評価へと軸足を移し、複合的な品質スコアを算出したうえで、「review(要確認)・block(差し止め)・ship(出荷)」のいずれかを推奨として返します。何を測るべきかの提案まで含めて、非決定的なエージェントに「出してよいか」の判断材料を与える仕組みです。コードを書くエージェントが増えるほど、それを世に出す前に誰がどう見極めるのか、という問いへの一つの回答と言えます。
リリース単位で穴を洗い出す「Release Risk Intelligence」
これはリリース管理者や品質エンジニアリングの責任者に向けた機能です。特定のリリースに範囲を絞ってカバレッジのギャップを可視化し、リスクを深刻度で並べ替え、次に取るべき行動をAIが助言します。限られた時間の中で、どこを重点的に確かめるかの優先順位づけを支援します。
文脈を握るための布石──Tabnine買収
これらの背景には、7月末に発表されたAIコーディング補助の草分けTabnineの買収があります。狙いは、Tabnineの「Enterprise Context Engine」をテストエージェントに組み込むことです。この技術は、コードリポジトリ・ドキュメント・チケット・API・インフラのメタデータから、実体・依存関係・アーキテクチャのパターンを抽出し、その企業固有の知識グラフを継続的に更新します。テストエージェントに「自社の文脈」を持たせることで、汎用のAIより的確に振る舞わせる狙いです。Tricentisは顧客報告値として、このコンテキストエンジン導入でAIの精度が最大2倍、トークン消費が最大8割減、複雑なタスクの解決が最大5割速くなった例を挙げています(いずれもコンテキストエンジン単体の数字で、今回の新機能の性能ではない点に注意が必要です)。
開発現場とビジネスへの影響
Claude CodeやCodexのような「書くエージェント」が普及するほど、テストとレビューのスループットが相対的な制約になります。テストの生成・実行・リスク判定までをエージェントに寄せられれば、ソフトウェア開発の一連の流れ(SDLC)をエージェントで通す構図が見えてきます。実運用の入り口としては、まずLabs経由の早期アクセスで、既存テスト資産のない領域の探索的テストや、社内で動かすエージェントの出荷可否の判定に限定して試すのが現実的でしょう。
過信への歯止めも要る
一方で、確率的な採点は「合格保証」ではありません。review/block/shipはあくまで推奨であり、最終的な出荷判断とその責任は人に残ります。今回の機能はいずれも「開発中・商用化未確約」の段階にあり、前のめりな本番導入は禁物です。さらに、エージェントを評価するエージェントの妥当性を誰がどう担保するのか、という「番人を誰が見張るか」の問題もあります。評価基準の透明性や監査のしやすさが伴わなければ、自動テストへの過信でかえって人の目が抜け落ちるリスクも指摘できます。便利さの裏で、こうした懸念にも目を配りながら段階的に取り入れる姿勢が求められます。
参照: Tricentis 公式ブログ / Yahoo Finance / VKTR / DEVOPSdigest / Tricentis(Tabnine買収)