イントロダクション：なぜ今、「固定シナリオ」からの脱却が必要なのか
「またテストが落ちている……」
朝一番、CI/CDパイプラインの通知を見てため息をついた経験は、プロダクト開発に関わる方なら一度や二度ではないはずです。ログを確認してみれば、単にボタンのclass名が変わっただけだったり、ページの読み込みが数ミリ秒遅れただけのタイムアウトだったり。本質的なバグではない修正に追われ、本来やるべき「ユーザー体験の向上」に時間が割けない。
これは、多くの開発現場が抱える「テスト自動化のジレンマ」です。
これまでのテスト自動化、特にE2E（End-to-End）テストは、SeleniumやPlaywrightなどを用いて「人間が記述した手順」を忠実に再現するものでした。「ログイン画面を開く」→「IDを入力」→「パスワードを入力」→「ボタン押下」といった具合です。これは回帰テスト（リグレッションテスト）として、機能が壊れていないかを確認するには非常に有効です。
しかし、この手法には決定的な弱点があります。
それは、「人間が想定した通りの操作しか検証できない」という点です。
実際のユーザーは、想定通りには動きません。迷ってブラウザバックしたり、予期せぬ順番でタブを開いたり、意味のない連打をしたりします。こうした「予測不能な行動」の先にこそ、クリティカルなバグや、離脱を招くUXの欠陥が潜んでいるものです。
テスト自動化の限界点とLLMの可能性
ここで登場するのが、LLM（大規模言語モデル）をベースにした「自律型AIエージェント」によるテストです。あらかじめ決められた手順をなぞるのではなく、AIに「このECサイトで、予算5000円以内のギフトを探して購入せよ」というゴールだけを与えます。AIエージェントは画面のDOM（文書オブジェクトモデル）を解析し、自分で考え、リンクをクリックし、フォームに入力してゴールを目指します。
これはもはや「テストスクリプト」ではなく、「バーチャルユーザー」のシミュレーションです。
ゲスト紹介：AI品質保証の最前線に立つエキスパート
とはいえ、確率的に挙動が変わるAIを、厳密性が求められる品質保証（QA）の現場にどう組み込むのか。「AIがバグだと言っているが、本当にバグなのか」という信頼性の問題はどう解決するのか。
今回は、こうした疑問を解消すべく、AIを活用した品質保証プロセスの構築支援を行うアーキテクト、高橋直人氏にお話を伺いました。高橋氏は大規模なSaaS開発現場でのQAマネジメント経験を経て、現在はAIエージェント導入の技術顧問として広く活躍されています。
現場のリアリティを知る高橋氏と共に、AIエージェントが変えるテストの未来について、論理的かつ体系的に深掘りしていきましょう。
Q1. 概念の転換：AIエージェントは「テスト」をどう変えるのか
鈴木： 高橋さん、本日はよろしくお願いします。最近、プロジェクトマネジメントの現場でも「AIエージェントでテストを自動化したい」という声が増えてきました。ただ、多くの人が従来の「Seleniumなどの置き換え」として捉えている節があります。まずは、この認識の違いについてお話しいただけますか。
高橋： よろしくお願いします。そうですね、そこが一番の誤解ポイントであり、同時に最大のチャンスでもあります。従来の自動テストツールとAIエージェントは、「地図を見て進む」か「目的地だけ聞いて進む」かというくらい違います。
「手順の再現」から「目的の達成」へ
高橋： 従来の手法は、カーナビに「この交差点を右、次は左」と全てのルートをプログラムすることに似ています。道（UI）が少しでも変われば、プログラムはエラーになります。一方、AIエージェントは「東京駅に行って」というゴールだけを与えられたタクシードライバーのようなものです。道が工事中なら迂回するし、新しい道ができればそこを通るかもしれません。
鈴木： なるほど。UIの些細な変更に強い、いわゆる「セルフヒーリング（自己修復）」的な側面だけでなく、ルート選択自体をAIに委ねるわけですね。
高橋： その通りです。これにより、開発者が「想定していなかったルート」での検証が可能になります。例えば、SaaSの解約フローのテスト事例で、AIエージェントが「ヘルプページから解約リンクが見つからないので、チャットボットに『解約したい』と連投し始めた」ということがありました。これは機能的なバグではありませんが、UXとしては重大な欠陥を発見できた例です。
人間らしい「揺らぎ」と「エラー」のシミュレーション
鈴木： それは興味深いですね。従来のテストなら「リンクがない＝Fail」で終わるか、そもそもテストケースに含まれていないかです。
高橋： ええ。AIエージェント、特にLLMベースのものは、ある程度の「人間らしい揺らぎ」を持たせることができます。プロンプト（指示）によってペルソナを設定できるのが強みです。
例えば、「せっかちな若者」というペルソナには、画面が表示されきる前にボタンを連打させたり、説明文を読まずに進ませたりします。逆に「慎重な高齢者」なら、利用規約のページを長時間滞在させたり、入力ミスをして修正する挙動をシミュレーションさせます。
鈴木： 単なる機能テストではなく、ユーザビリティテストに近い領域まで踏み込めるということですね。
高橋： まさにそうです。これまでは人間が手動で行っていた「探索的テスト（Exploratory Testing）」の一部を、AIが肩代わりしてくれるイメージです。24時間365日、文句も言わずに何百通りもの「迷い方」を試してくれるテスターがいると考えてください。
Q2. 精度の壁：AIの「行動」をどう評価し、信頼するのか
鈴木： 非常に魅力的なお話ですが、ここでプロジェクトマネージャーとして気になるのが「信頼性」です。LLMは確率的に単語を紡ぐ仕組みですから、同じ指示でも毎回違う挙動をしますよね。テストにおいて「再現性がない」というのは致命的ではないでしょうか。
シミュレーション結果の妥当性検証（Ground Truth）
高橋： 鋭い指摘です。そこが導入の最大のハードルになります。従来のテストは Expected: A, Actual: A ならPass、Actual: B ならFailという明確な二元論でした。しかしAIエージェントの場合、結果はもっとグラデーションになります。
実務の現場では、「成功率（Success Rate）」と「効率性スコア（Efficiency Score）」という指標を導入することが推奨されています。
例えば「商品購入」というゴールに対して、AIエージェントを100回走らせます。100回中95回購入できれば、機能としては安定していると言えます。しかし、残りの5回で何が起きたのか。そこでログを分析します。もしAIが「ボタンの色が背景と同化していて認識できなかった」のであれば、それはAIのハルシネーション（幻覚）ではなく、UIのコントラストの問題である可能性が高いのです。
鈴木： 1回のFailで即アウト判定するのではなく、統計的に見るわけですね。
高橋： はい。そして、AIが報告してきた「バグ」が本当にバグなのかを判定するために、検証用の「Ground Truth（正解データ）」を用意する場合もありますが、最近は「セルフベリフィケーション（自己検証）」という手法も使われます。
AIエージェントに操作を行わせた後、別の監視用AIエージェント（Observer）にログを読ませて、「このユーザーはゴールを達成したか」「不自然な行動はなかったか」を判定させるのです。いわゆる「AIをAIが監査する」構成です。
ハルシネーションと「予期せぬ挙動」の区別
鈴木： AI同士のダブルチェックですね。ただ、それでもAIが勝手に存在しないメニューをクリックしようとしてエラーになるような、純粋なハルシネーションも起きませんか。
高橋： 起きます。ですから、AIエージェントには「画面上のDOM要素にしかアクセスできない」という制約を厳密にかける必要があります。視覚情報（スクリーンショット）とコード情報（HTML）の両方を入力して、物理的にクリック可能な要素だけを認識させる技術（マルチモーダルなグラウンディング）が進化しており、この種のエラーはかなり減ってきています。
重要なのは、「AIの誤操作」をノイズとして切り捨てるか、UIの分かりにくさへのシグナルとして捉えるかの判断です。人間も誤操作しますから、AIが高い頻度で誤操作する箇所は、人間にとっても使いにくいUIである可能性が非常に高いのです。
Q3. 比較検討の視点：導入すべきフェーズとツールの選び方
鈴木： 概念と精度の話が見えてきました。では、実践的な導入戦略について伺います。ROI（投資対効果）を最大化する観点から、全てのテストをAIエージェントに置き換えるべきでしょうか。
高橋： 全てを置き換えるのは推奨されません。コストの観点でも、品質担保の観点でも、現実的な選択とは言えないからです。
ルールベース vs AIエージェントの使い分け
高橋： テストには明確な適材適所が存在します。一般的に「守りのテスト」と「攻めのテスト」に分けて考えるアプローチが現場ではよく採用されます。
守りのテスト（回帰テスト）
- 対象: ログイン、決済、コア機能の正常系シナリオ。
- 手法: 従来の固定シナリオベースの自動化（SeleniumやCypressなど）。
- 理由: 100%の再現性と高速な実行が絶対条件となる領域です。ここで「AIが確率的に異なる挙動を示して失敗した」という事態は許容されません。
攻めのテスト（探索的テスト・UX検証）
- 対象: 新機能、複雑な検索フロー、多言語対応、異常系処理。
- 手法: AIエージェント（推論強化型の最新モデル）。
- 理由: 事前に網羅しきれないエッジケースや、ユーザーの予期せぬ行動を検証するためです。特に最新のモデルを活用すれば、複雑な論理推論を伴う検索フローや、多言語環境特有の表示崩れ、エラー時の異常系対応といった高度な検証を任せられます。
鈴木： 明快な基準ですね。クリティカルパスは従来通り強固なルールベースで固め、その周辺に広がる「ユーザーが迷い込みそうな森」をAIに探索させるイメージですね。
コスト対効果が見合う境界線
鈴木： コスト面はどう評価すべきでしょうか。LLMのAPI利用料やコンピューティングリソースは、プロジェクト運営において決して無視できない要素です。
高橋： その通りです。特に複雑な画面遷移を繰り返すようなテストでは、1回の実行で相応のトークンを消費します。毎日すべてのテストケースで高度なAIを走らせれば、たちまち予算を圧迫するでしょう。
ここで考慮すべきなのが、最新のAIモデル動向を踏まえた戦略的な使い分けです。OpenAIの公式情報によると、2026年2月13日をもってChatGPTのUIからGPT-4o、GPT-4.1、o4-mini、GPT-5、GPT-5.1といった旧モデルが完全に引退し、デフォルトモデルはGPT-5.2へと一本化されました。
現在のGPT-5.2は、要件に応じてInstant、Thinking、Auto、Proの4つのモードを切り替えられる体制になっています。たとえば、100万トークン級の膨大なコンテキスト処理や、複雑な検索フローの検証には、推論を深める「Thinkingモード」が適しています。一方で、API経由であればGPT-4oの特性を活かした処理も一部継続可能ですが、公式には新規開発でのGPT-5.2移行が推奨されています。テストの難易度に合わせて適切なモード（高速なInstantか、深慮するThinkingか）を選択することが、コスト最適化の鍵を握ります。
運用面で推奨されるアプローチは、「ナイトリービルドでの部分的な実行」や「リリース直前の集中的なスモークテスト」に絞り込むことです。また、PMF（プロダクト・マーケット・フィット）到達前の、UIが頻繁に変更されるフェーズには適していません。仕様自体が流動的な状態でAIを走らせても、正誤の評価基準が定まらないからです。
逆に、プロダクトがある程度成熟し、「特定条件下でのみ発生するレアなバグ」や「アクセシビリティの微妙な不具合」を洗い出したいフェーズに入ると、AIエージェントは圧倒的に高い投資対効果（ROI）を発揮し始めます。
鈴木： 自社開発でエージェントを構築するか、SaaSを導入するかという点では、どのような判断基準を持つべきですか。
高橋： 現在は、AutifyやMagicPodといった既存のテスト自動化SaaSも強力なAI機能を統合していますし、AIエージェントに特化した新しいツールも続々と登場しています。まずはSaaSが提供するAI機能を試用し、自社の課題にフィットするか検証するのが最も現実的な選択肢です。
自前でLangChainなどのフレームワークを用いて独自のエージェントを構築するアプローチは、AIエンジニアのリソースが潤沢に確保できる組織以外には推奨しません。
LangChainは安定版に到達し、APIの記述も以前より洗練されましたが、セキュリティ要件への対応や、LLM側の頻繁なアップデートへの追従といった保守コストは依然として高いのが実情です。本来の目的であるプロダクトの品質向上よりも、テストツール自体のメンテナンスに多大な時間を奪われてしまっては、本末転倒と言わざるを得ません。
Q4. 未来への示唆：QAとUXリサーチャーの役割はどう変わるか
鈴木： 最後に、これからのQAチームやプロジェクトマネージャーの役割についてお聞かせください。AIが「バーチャルユーザー」としてテストを行うようになると、人間の仕事はどう変わるのでしょうか。
「バグを見つける」から「体験を設計する」へ
高橋： QAエンジニアの仕事は、「テストケースを書くこと」から「エージェントを監督・教育すること」にシフトします。これまでは「ボタンAを押したら画面Bに行くこと」を確認するのが仕事でしたが、これからは「こういうペルソナのエージェントを放ったとき、彼らがストレスなくゴールできるか」を設計する仕事になります。
鈴木： それはもう、QAというよりUXリサーチャーに近いですね。
高橋： その通りです。QAとUXリサーチの境界線はどんどん溶けていくでしょう。バグがないことは当たり前（それは固定テストで担保する）。その上で、「使いやすいか」「分かりやすいか」を定量的に評価する役割が求められます。
AIエージェントとの協働モデル
鈴木： プロジェクトマネージャーとしても、仕様書を書くときに「この機能は、こういう性格のAIエージェントで検証してほしい」という要件定義をする必要が出てきそうですね。
高橋： そうなります。そして、最終的な「価値判断」は人間がやらなければなりません。AIが「ここは使いにくい」と報告してきたとき、それを「仕様だから」と無視するのか、「改善すべき摩擦」と捉えるのか。その意思決定こそが、プロダクトの質を決定づけます。
AIは強力なパートナーですが、プロダクトへの「愛」や「こだわり」までは持ち合わせていません。そこを補うのが、人間の役割であり続けるはずです。
編集後記：不確実性を味方につける品質保証戦略
今回の高橋氏との対話を通じて、AIエージェントによるテストの本質は「自動化」ではなく「拡張」にあることが明確になりました。開発現場でこれまで見落とされがちだったユーザーの多様な行動パターンを、AIが可視化してくれるのです。
固定シナリオテストが「線」の検証だとすれば、AIエージェントテストは「面」の検証です。AIはあくまで手段ですが、適切に活用することでプロダクトの品質とROIを飛躍的に高めることが可能です。
明日からできる第一歩として、以下の3つを提案します。
- 現状のテスト負債の棚卸し: メンテナンスに時間がかかりすぎているFlakyなテストケースを特定する。
- 「迷い」の許容: テスト環境で、あえてゴールまでのルートを固定しない探索的な操作を（手動でもいいので）試してみる。
- スモールスタート: ログインなどのコア機能ではなく、「検索」や「回遊」といった、正解ルートが複数ある機能でAIツールのパイロット運用を検討する。
不確実なユーザー行動を恐れるのではなく、それをシミュレーションに取り込み、味方につける。それが、これからの時代に求められる品質保証のあり方ではないでしょうか。
コメント