【ITニュース解説】Building an Autonomous A/B Testing Agent on Docker Cloud Sandboxes

この解説では、AIエージェントを活用してウェブサイトのA/Bテストを自動的に行うシステムについて説明する。A/Bテストとは、ウェブサイトやアプリケーションの異なる2つ以上のバージョン（AとBなど）を用意し、どちらがより良い結果をもたらすかを比較検証する手法である。例えば、新しい機能やデザインの改善を試す際に、ユーザーの行動データに基づいて最適な選択を行うために使われる。通常、このテストには人の手による設計、実装、評価が伴うが、このプロジェクトではAIがそのプロセスを自律的に実行することを目指している。

システム開発の例として、商品を目的通りに見つけにくいオンラインショップを改善するシナリオを考える。この問題に対し、どのようにショップを改善すれば良いか、AIエージェントが自ら仮説を立て、コードを書き、テストし、最終的に最も効果的な改善策を見つけ出す。具体的には、まずオリジナルのショップを「Docker Cloud Sandboxes」という隔離された環境（サンドボックス）にデプロイする。次に、買い物客の役割を担うAIエージェントがショップを訪れて使いやすさを評価し、その結果を報告する。この報告を受け、アナリストの役割を担う別のAIエージェントが、改善のための具体的な修正案をいくつか提案する。その後、ビルダーの役割を担うAIエージェントが、提案された各修正案を実際のコードとして実装し、それぞれを新しいサンドボックスにデプロイする。再び買い物客エージェントが、修正された各バージョンのショップをテストし、最も高い評価を得たバージョンのコードが選ばれて開発者の手元に戻されるという流れだ。

この一連のプロセスで「Docker Cloud Sandboxes」という技術が重要な役割を果たす。サンドボックスは、クラウド上に用意される、隔離された使い捨ての仮想環境（マイクロVM）である。ビルダーエージェントがコードを自動生成し、それが人のチェックを受けずに実行される場合、セキュリティ上のリスクが伴う可能性がある。しかし、サンドボックスを使うことで、仮にエージェントが問題のあるコードを生成しても、影響はサンドボックス内に限定され、開発者のローカル環境や他のシステムに被害が及ぶ心配がない。これが「安全性」の確保である。また、提案された複数の改善策を並行してテストする際、それぞれの修正版が互いに干渉しないように、個別のサンドボックスで独立して実行されるため、「分離性」が保たれる。さらに、各サンドボックスには公開されるHTTPSのURLが割り当てられるため、テスト中の各バージョンをブラウザで実際に開いて確認することも可能だ。重要な点は、OpenAIのAPIキーのような機密情報はサンドボックス内に直接置かれず、Dockerの秘密管理機能によって安全に保管され、サンドボックスから外部APIが呼び出される際にのみ安全に利用される。これにより、エージェントがキーに直接アクセスするリスクを防ぐことができる。

このシステムでは、主に三種類のAIエージェントが連携して動作する。これらは全て「Codex」という基盤となるAIモデルを使用し、与えられた指示（プロンプト）によって異なる役割を果たす。 一つ目の「買い物客」エージェントは、学生やエンジニアなど特定のペルソナ（人物像）と購入目標を与えられ、ウェブサイト内を模倣的に操作してその使いやすさを評価する。例えば、「予算20ドルの学生で、開発者向けの20ドル以下のギフトを探す」といった具体的な指示を受け、実際にサイトを巡回する。その結果は、完了状況、ステップ数、1から10のスコア、そして使いにくかった点などの情報を含むJSON形式で報告される。このスコアが高いほど、タスクが簡単に達成できたことを意味する。 二つ目の「アナリスト」エージェントは、買い物客エージェントのレポートを全て読み込み、ウェブサイトの改善点を分析し、具体的な修正案を複数提案する。このエージェントには、「修正は小規模であること」「既存のHTML、CSS、JavaScriptファイルのみを編集すること」「新しいライブラリやバックエンドの変更は行わないこと」といった厳格なルールが与えられ、異なるアイデアに基づく修正案をJSON形式で出力する。 三つ目の「ビルダー」エージェントは、アナリストエージェントが提案した具体的な修正案（例えば「価格でソートする機能の追加」など）を受け取り、それを実現するためのコードを自動生成する。このエージェントも、「特定のファイルのみを編集すること」「サーバーを再起動しないこと」「ページが正しくロードされるか確認すること」などのルールに従う。これにより、各修正版が統一された基準で作成される。

これらのAIエージェントとサンドボックスの連携は、いくつかのステップを経て構築される。まず、Docker Sandboxes SDK（ソフトウェア開発キット）を使ってDockerアカウントにサインインし、OpenAI APIキーを安全な秘密としてDocker上に登録する。次に、launchShopという関数を通じて、指定されたキット（codexなど）を使ってサンドボックスを起動し、オリジナルのショップファイルをサンドボックス内にコピーする。コピー後、サンドボックス内でウェブサーバーを起動し、サーバーが応答するまで待機する。最後に、外部からアクセスできるよう、サンドボックスのポートに公開URLを割り当てる。これにより、クラウド上で稼働するショップの準備が整う。

AIエージェントをサンドボックス内で実行する際には、runAgentという関数が使われる。この関数は、Codexをサンドボックス内でコマンドラインから直接実行し、指定されたプロンプトに基づいてコードを生成させたり、評価を行わせたりする。Codexの出力は一時ファイルに保存され、その内容を読み取ってAIからの回答（JSON形式）を抽出する。この際、Codexが自身のサンドボックス環境を迂回するオプションを使用するが、これはすでに使い捨てのDocker Cloud Sandbox内で動作しているため安全である。

全体のA/Bテストの実行は、ab.tsというメインプログラムでオーケストレーションされる。まず、最初のステップとしてオリジナルのショップをサンドボックスに起動し、複数の買い物客エージェントが同時にテストを行う。その結果を基に、アナリストエージェントが改善計画を提案する。提案された各改善策は、それぞれ独立した新しいサンドボックスで並行して処理される。この処理には、新しいサンドボックスの起動、ビルダーエージェントによるコード修正、そして再度買い物客エージェントによるテストが含まれる。複数の修正案が同時に進行するため、どれか一つが失敗しても他のテストは影響を受けずに完了するよう、Promise.allSettledという非同期処理が使われる。全てのテストが完了すると、買い物客エージェントの平均スコアを基準に最も優れたバージョンが選ばれる。最終的に、選ばれたバージョンのコードは開発者のローカル環境にコピーされ、テスト結果の詳細をまとめたレポートも生成される。

このシステムは、npm startコマンドで実行できる。初回実行時にはDockerへのサインインが必要となる場合があるが、一度設定すれば次回以降は不要だ。テストの進行状況は、ローカルで起動するダッシュボード（http://localhost:4000）でリアルタイムに確認できる。各ショップバージョン（オリジナルと改善版）の公開URLもターミナルに表示されるため、ブラウザでアクセスして実際の変更を視覚的に確認することも可能だ。テスト完了後には、各バージョンの使いやすさ、完了率、必要なステップ数、そしてオリジナル版からの改善度を示す表がコンソールに表示される。また、勝ちバージョンのコードはresults/winner/ディレクトリに保存され、元のコードとの差分を確認することで、AIがどのような変更を加えたのかを具体的に把握できる。テスト後にサンドボックスが不要になった場合は、npm run cleanupコマンドで簡単に全て削除できる。

このプロジェクトを通じて、Docker Sandboxes SDKを使ったクラウドサンドボックスの起動、ファイル操作、サーバー実行、そして公開URLの取得といった基本的な操作を学ぶことができる。さらに、AIエージェントをサンドボックス内で実行し、その出力を活用する方法も理解できる。この仕組みは、ウェブサイトのA/Bテストに限らず、プロンプトのチューニングや設定値の最適化、異なるコンテンツの比較など、ユーザー行動をシミュレートし、その結果をスコアとして評価できる様々なシナリオに応用可能だ。安全な使い捨てのコンピューティング環境が簡単に手に入ることで、AIエージェントに「試行錯誤」を任せることのリスクが大きく軽減され、開発の可能性が広がる。