AIBTest、MCPネイティブなA/Bテストフローを発表——エージェントがドメイン検証、SDKのデプロイ、効果測定を自律実行

AIBTestは、従来は人間が操作していたA/Bテストのダッシュボードを、AI agentが直接利用できるMCPネイティブな実験基盤へと転換しようとしている。公開ページに記載されたフローは、DNS TXTまたはHTTPSファイルによるドメイン管理権限の検証から始まる。続いてローカルCLIが秘密鍵を保存し、短期のscoped tokenを取得する。その後、ブラウザSDKでsticky A/B assignmentを行い、最後にエージェントがMCPからインプレッションとコンバージョンの結果を読み取る。

この設計の技術的な要点は、単に実験用パネルを増やすことではなく、管理プレーン、実行プレーン、クレデンシャル境界を分離することにある。AIBTestのdiscoveryドキュメントには、MCP URL、バージョン管理されたSDK URL、Linux amd64向けCLIのダウンロード、およびskill URLが記載されている。一方、skillドキュメントでは、エージェントがcredential storeを読み取ったり出力したりしないことを求め、ローカルのloopback proxyを介してclient assertionとリモートaccess tokenを管理する。つまり、モデルが扱うのはツールとレポートであり、秘密鍵やbearer tokenにはアクセスすべきではない。

実験の実行面では、初期版におけるDOMの変更対象をtextContent、className、styleに限定している。トラフィックは1%から100%まで調整でき、selectorの存在を確認した後にのみrunning状態へ移行することが求められる。ドキュメントでは、表示コンテンツを対象とする実験でanti-flicker patternを使用し、SDKの読み込み前後に画面がちらつくことを防ぐよう注意も促している。こうした制約により、これはフロントエンドを任意に書き換えるリモートスクリプトシステムというより、エージェント向けの安全な操作インターフェースに近いものとなっている。

留意すべき点として、AIBTestの現在の公開ドキュメントを見る限り、レポートはインプレッション、コンバージョン、コンバージョン率などの記述統計的な指標が中心であり、conversion rateだけを根拠に統計的有意性を主張しないよう明確に注意を促している。現段階では、agentic web developmentにおける実験のクローズドループ型プロトタイプと捉えるのが適切だ。エージェントは仮説を提示し、実験を作成し、SDKをデプロイし、結果を観察してトラフィックを調整できるが、本格的な推論基準、サンプルサイズ設計、プロダクト上の意思決定については、引き続きエンジニアリングチームとプロダクトチームが共同で精査する必要がある。