ABEMAがAIエージェントを用いてA/Bテスト文化を促進する取り組み

ABEMA の Data Science チームで、2025 年 9 月から半年間、ミッション型インターンに参加した田名部智也と申します。

東京大学電子情報工学科の 4 年生で、大学では音声情報処理の研究を行っています。

インターンでは、ABEMA のプロダクト上で行われる A/B テスト（A/B テスト）の分析や、A/B テスト分析基盤の機能改善、LLM（大規模言語モデル）を活用した分析レポート要約の PoC など、さまざまな業務に取り組みました。本記事では、その中でも「マルチエージェントシステムによる過去の施策の検索と示唆出し」についてお話しします。

Data Science チームの現状

ABEMA では、データに基づいた意思決定を行うために、A/B テストの結果を踏まえて判断する文化の醸成に注力してきました。A/B テストの流れは下図の通りです。

検証設計：検証したい施策について、元になった仮説や背景、そしてそれを検証するための評価指標や適用判断の軸などを施策実行者が設計して文書にまとめます。

A/B テスト：検証設計書に基づいて、A/B テストを実行します。施策によりますが、検証期間はおよそ 1〜2 週間です。

データの分析：A/B テストの結果を分析します。A/B テスト文化をスケールさせるために、A/B テスト分析基盤である stargazer を開発しており、分析の大部分をシステム化しています。

施策の適用判断：検証設計書と分析結果を照らし合わせて、データサイエンティストが施策の適用可否を判断します。

次施策の提案：分析結果から得られた示唆をもとに、施策関係者が新しい施策を立案します。

直接的な原因として、分析が結果の確認に留まっている点が挙げられます。深掘りや示唆出しまで踏み込めていないため、A/B テストが施策の評価で完結してしまっています。そのため、次の施策創出や構造的な学習につながっていません。加えて、施策の知見が属人化してしまっています。

さらに背景を深掘りすると、根本要因は 2 つあります。1 つ目は、施策数の増加に対して、分析側のリソース・時間が相対的に不足していることです。2 つ目は、過去施策の設計・結果・得られた示唆が分散していることです。そのため、検索・再利用しづらい状態になっています。

上記課題を解決するために、過去に行われた施策を横断的に検索し、結果を要約して参照できるようにすることを考えました。さらに、A/B テストから示唆を抽出して次の施策に生かすための機能も必要だと考え、これらを実装することにしました。具体的には、以下の 3 点です。

過去施策を自然言語で横断検索できるようにする。

検索結果の要点を要約し、A/B テストの結果から示唆を抽出できるようにする。

抽出した示唆に基づいて、追加の深掘り観点や次の打ち手を提案できるようにする。

ただし、上で列挙した機能はそれぞれ性質が異なる処理を必要とします。そのため、単一の処理フローにまとめると、拡張や改善が難しくなります。そこで、役割ごとにエージェントを分けて協調させる方針にしました。これにより、一連の作業を統合的に実行できる「マルチエージェント」アプローチを採用しました。

上記の課題を踏まえて開発した「過去施策検索・示唆出しエージェント」の仕組みを説明します。本章ではまず、技術選定を整理した上で、マルチエージェントのワークフローとクラウドアーキテクチャの2つの観点から全体像を紹介します。

過去の施策の検索には、Google が提供する Vertex AI Search を利用しました。Vertex AI Search は、キーワードマッチングとセマンティック検索に基づいて、関連性の高いドキュメントやドキュメントの一部を検索します。セマンティック検索とは、エンベディング（embedding）を使用した検索で、ユーザの検索意図や言葉の意味を理解して関連する情報を提示する技術です。

マルチエージェントとは、自律的に思考・行動する複数の AI エージェントが、互いに協調し役割分担しながら複雑なタスクを実行する仕組みです。今回の実装では、Google が提供する Agent Development Kit（ADK）を利用しました。Google ADK は、エージェントを効率的に構築・管理・評価・デプロイするためのオープンソースフレームワークです。コミュニティはまだ成熟途上ではあるものの、Vertex AI Search をはじめとする Google Cloud サービスとの親和性が高い点が採用理由です。

マルチエージェントのワークフロー

ユーザの入力を起点に、Root Agent が全体の進行を制御し、複数のエージェントを組み合わせて「過去施策の検索」と「要約・示唆出し」までを行います。以下は、各エージェントの説明です。

Root Agent: ユーザが直接相互にやり取りするエージェントで、以降のエージェント呼び出しと結果の統合を担当します。

Parallel Agents Design Doc Agent: 検証設計書を検索し、施策の意図や前提条件を押さえるための候補を集めます。

Result Doc Agent: 分析結果レポートを検索し、結果・指標・差分が載っている文書候補を集めます。

Proposal Agent: 次に取るべきアクション案（深掘り方針や新施策）を提案します。

Sequential Agents PDF Search Agent: ユーザの要求に応じて、必要としている分析結果レポートを探索し候補を提示します。

PDF Summarize Agent: 検索された候補のうち、どれを要約対象にするかをユーザが選び、選択された分析結果レポートの PDF 内容を根拠として、要点整理と示唆出しを行います。

今回開発したマルチエージェントシステムは、Data Science チームで運用している A/B テスト分析基盤 stargazer 上の機能として導入しました。以下は、主要なコンポーネントの説明です。

Cloud Run（Multi-Agent）: サービス本体は Cloud Run 上で稼働します。

Vertex AI ドキュメント検索は Vertex AI Search Engine が担当し、検索対象のインデックスは Data Store で管理されます。

Cloud Storage 検索対象となる検証設計書や分析結果レポート等のデータは Cloud Storage に置かれ、Data Store 側で同期・インデックス化されます。

開発を進める中で最初に大きな壁になったのは、Vertex AI Search は検索精度が高い一方で、要約精度にばらつきがある点でした。Vertex AI Search は検索に加えて要約機能も提供しています。しかし、この要約機能をそのまま使うと、要約や示唆出しの段階でハルシネーション（幻覚・虚偽生成）が発生したり、別施策の内容が混在したりしました。その結果、実務で使える品質になりませんでした。

そこで、まずは検索機能だけを用いて施策候補を絞り込みます。そのうえで、ユーザが望む施策を自ら選択し、その施策の分析結果レポートは全体を LLM（大規模言語モデル）に要約させる形式にしました。このように、プロセスの重要箇所や判断に人間が介在し、監督する仕組みは Human in the loop（人間のループ内化・人的監視）と呼びます。これにより、要約の根拠がより確実になりました。あわせて、文脈の取り違えや抜け漏れを減らす方向で改善しました。

開発したエージェントが実務で使えるかどうかを判断するために、評価は大きく 2 つに分けて実施しました。1 つ目は、ユーザの質問から目的の施策に辿り着けるかという「検索の評価」です。2 つ目は、見つかった文書を根拠に、誤りなく要点をまとめられるかという「要約の評価」です。

検証設計書については、ユーザが自然言語で施策概要を尋ねたときに、該当施策を正しく引用して要約できるかを確認しました。10 施策それぞれについて、キーワードが直接含まれる「低難易度」と、状況説明から施策を特定させる「高難易度」の 2 段階の評価用プロンプトを用意しました。

採点は、各プロンプトに対して以下のルールで 0〜2 点（基本点）を付与しました。

0 点：求めていた施策が引用されていない（別施策が出てくる、施策を特定できていない）

1 点：求めていた施策は引用されているが、概要のまとめが不正確（主要な前提や目的がズレている、誤りが目立つ）

2 点：求めていた施策が引用され、検証設計書の内容に沿って正確に概要をまとめられている

また、基本点とは別に、関連性の高い施策を複数提示し、それらも正確に説明できた場合は、加点枠として 1 点の追加点を付与しました。

検証設計書検索の評価結果は以下の通りです。

今回開発したマルチエージェントシステムは、Data Science チームで運用している A/B テスト分析基盤 stargazer 上の機能として導入しました。以下は、主要なコンポーネントの説明です。

Cloud Run（Multi-Agent） サービス本体は Cloud Run 上で稼働します。

Vertex AI ドキュメント検索は Vertex AI Search Engine が担当し、検索対象のインデックスは Data Store で管理されます。

Cloud Storage に保存された検証設計書や分析結果レポートなどの検索対象データは、Data Store 側で同期されインデックス化されます。

分析結果については、目的の施策に対応する分析結果レポートが検索上位に表示されるかを評価しました。これも低難易度と高難易度の 2 段階のプロンプトを用いて確認を行いました。

採点は、各プロンプトに対して以下のルールに基づき 0〜2 点を付与しました。

0 点：検索上位の候補に目的の PDF が含まれていない

1 点：検索上位の候補に目的の PDF が含まれている

2 点：目的の PDF が検索結果の最上位にある

分析結果レポート検索の評価結果は以下の通りです。

結果として、キーワードが明確な質問では高い精度で上位にヒットしましたが、抽象的な質問では精度が低下しやすい傾向が見られました。検索候補を提示し、ユーザーに正しい PDF を選択してもらう設計の必要性も、ここでも確認されました。

要約や示唆出しについては、複数の観点を満たして初めて実務利用に耐えるため、評価軸を事前に設計してから開発を進めました。10 の施策を対象に、Data Science チーム内の複数名が評価者となり、各施策を複数人で採点する形でレビューを行いました。

具体的には、正確性・網羅性・中立性の 3 点です。提案の質については事例ベースで補足します。Data Science チームとして「実務で使える」「次の検討につながる」と判断できるアウトプットが得られたことを報告します。

正確性：元の PDF レポートの事実や数値と整合しているか（数値の取り違え、指標名の誤り、p 値の不用意な言及などを減点対象とする）

網羅性：施策概要、primary metrics（主要指標）、guardrail metrics（ガードレール指標）、secondary metrics（二次指標）の結果、最終結論が抜けなく含まれているか

中立性：感情的・断定的な表現が混ざらず、事実記述として読めるか

要約の評価結果は以下の通りです。

評価の結果、正確性と中立性は高い水準を達成できた一方、網羅性が相対的に弱いことが確認されました。具体的には、施策の介入前後で指標に変化は見られなかったものの、文脈上重要な結果を報告しないケースが見受けられました。ただし、今回は 1 ターンでどの程度の情報を返せるかを評価しているため、実運用では複数ターンにわたって情報を聞き出すことで網羅性を補える可能性があります。

本来は、「示唆出し」「新施策提案」「深掘り分析提案」といった次のアクションにつながる提案の質も定量的に評価して示したいと考えていました。しかしこれらは、施策や状況に依存して「何が正解か」を一意に定義することが難しく、採点基準を固定すると現場の納得感とズレるリスクがありました。そこで今回は、事例ベースでデータサイエンティストが妥当と納得できる提案が得られることを確認しました。

以下に具体例を示します。コンテンツ推薦機能で「ユーザが既に視聴したコンテンツを除外し、未視聴コンテンツのみを推薦する」施策を検証しました。結果、総視聴時間は変化しなかったが、推薦機能経由の視聴時間は減少していることが確認されました。

この結果を受け、マルチエージェントシステムは「既存の視聴経路が別の経路に置き換わった可能性」を示唆しました。さらに、下図のように、検索画面やジャンル一覧など視聴時間が増加している可能性のある経路を候補として提示し、深掘り分析を提案しました。

提案に従って検証したところ、実際に「視聴中の作品」画面を経由した視聴時間が増加していることが確認され、経路置換の仮説が支持されました。加えて、この示唆を踏まえ、繰り返し視聴されやすいコンテンツと一度きりの視聴に留まりやすいコンテンツで推薦ロジックを切り替えるといった新たな施策案も提案できました。

Cloud Run や周辺リソースを、後から再現・変更できる形で管理する重要性を学びました。特に、CI/CD（継続的インテグレーション/継続的デリバリー）のワークフローとIaC（Infrastructure as Code：コードとしてのインフラ構築）がどのように接続されると「組織として運用できる状態」になるかの理解が深まりました。個人開発だと後回しになりがちな、環境差分の吸収、変更のレビュー、デプロイの手順化といった観点が、大規模な組織での運用には欠かせないということを実感しました。

ADK を用いたマルチエージェント開発

単体の LLM（大規模言語モデル）呼び出しではなく、検索・候補提示・選択・要約という一連の流れをエージェントとして分割し、責務を明確にすることで改善が回しやすくなると実感しました。ワークフローも、sequential（依存関係が強い処理の直列化）、parallel（探索や候補列挙などの並列化）、loop（ユーザ選択や追加質問を含む反復）を使い分けることで、流れをコントロールできることが分かりました。

先に評価軸を決めることで実装の迷いが減り、改善の議論を具体化でき、PDCA ループ（Plan-Do-Check-Act：計画・実行・評価・改善のサイクル）をより高速に回せました。

試行錯誤の過程、判断の根拠、評価結果を都度ドキュメントに残すことで、後からの振り返りやチーム内共有がスムーズになりました。ドキュメンテーションから先に入ることで、やるべき細かいタスクが分解され、自分自身の次の行動が明確になります。結果として「次に何をするか」で迷う時間が減り、作業の切り替えコストも下げられることを学びました。

人を巻き込むことの重要性と難しさ

アウトプットの品質を上げるには、早い段階から関係者を巻き込み、フィードバックループ（改善のための循環プロセス）を回すことが不可欠だと学びました。具体的には、Data Science チーム内のメンバーに評価を依頼して観点のズレを早期に潰すことができました。加えて、開発チームに分析結果を報告し、次に提案する施策の妥当性について議論しました。さらに、社内で技術的に近い事例に取り組んでいる方と学びを共有したりもしました。

とはいえ、実際に関係者を巻き込むのは容易ではありませんでした。関係者のスケジュールや優先順位が異なるため、タイミングを合わせるだけでも手間がかかります。さらに、立場や専門性が違うと観点や期待値にズレが生じやすく、その差を埋めながら議論を前に進めることは難しいと感じました。

年に一度、サイバーエージェント全体で開催される AI Fes にて、Data Science チームを代表して、上記の取り組みについてポスター発表を行う機会をいただきました。サイバーエージェントの事業は非常に幅広く、AI Lab の研究から各事業部の AI 活用事例まで、さまざまな取り組みに触れられて大きな刺激を受けました。当日は足を止めて真剣に聞いてくださる方が多く、議論やフィードバックもいただけてありがたかったです。少しでも知見の共有を通じて、社内コミュニティに還元できていたら嬉しいなと思います。