7月22日、LangChainが「How Apollo Rebuilt Its AI Assistant on Deep Agents to Power the Full GTM Loop」と題した記事を公開した。営業支援プラットフォームのApolloがAIアシスタントをDeep AgentsとLangSmithで再設計し、新機能リリースまでの工数を約80〜85%削減、さらに4万以上のチームが利用するMCPサーバーを展開した実装事例だ。GTM（Go-to-Market）全体をエンドツーエンドで自動化するアーキテクチャの選択から評価フレームワークの運用まで、詳細が公開されている。
Apolloは見込み客の発掘から連絡先の情報付与、アウトリーチの自動化、商談管理、分析までをカバーするGTMプラットフォームだ。機能が充実している一方で、近年の顧客調査では「モジュールが多すぎて、ひとつのゴールを達成するために何ステップも踏まなければならない」という声が上がっていた。たとえば新規見込み客へのアウトリーチキャンペーンを開始するには、リード検索・データ補完・シーケンス作成・結果確認の各ダッシュボードを個別に操作する必要があった。
スーパーバイザー型からDeep Agentsへ：設計思想の転換
Apolloが最初に構築したマルチエージェントシステムは、LangGraphを使ったスーパーバイザー型アーキテクチャだった。メインのエージェントがタスクをルーティングし、専門化されたサブエージェントがそれぞれ個別のワークフローを担う構成だ。しかし、エンジニアリングマネージャーのAnshul Pahwa氏は次のように述べている。
「新しいユースケースが発生するたびにサブエージェントを書き、スーパーバイザーに組み込み、規定のパスを通るよう調整しなければならなかった。」
ユーザー体験としても、意図確認のプロンプトが頻発する問題があった。
Apolloはその後継としてDeep AgentsとAnthropic社のClaude Agent SDKの2つを評価した。最終的にDeep Agentsを選んだ理由はモデル中立性だ。
「Claude SDKを選べばAnthropicモデルに縛られる。それは永続的に選択肢を閉じることになる。Deep AgentsならLLMベンダーを柔軟に切り替えられる。」
新アーキテクチャでは、アシスタントはユーザーの目標に応じてスキルライブラリから動的に必要なスキルを選択して実行する。エンジニアが事前にパスを規定する必要はない。現在のスキルには、見込み客発掘、シーケンス作成、アカウント・連絡先リサーチ、到達率改善、アナリティクス、アカウントスコアリング、インテントシグナル検出などが含まれる。
効果は顕著で、レイテンシの改善と確認プロンプトの大幅な減少が確認された。さらに開発サイクルも圧縮された。スーパーバイザー型では新機能の初回精度が20〜30%程度で、リリース基準の80%に引き上げるための評価フェーズに相当な工数がかかっていた。フラットなスキルアーキテクチャへの移行後は、初期開発からリリースまでの工数が約80〜85%削減されたという。
AI Watchtower：LangSmith上に構築した6層の評価フレームワーク
観測基盤としてLangSmithを採用した背景には、独自ツールの限界がある。マルチエージェント構成では、スレッド内でどのツールがどの順序で呼ばれ、どこで失敗したかを把握するのが困難だった。LangSmithを導入してからは、エラー発生時にスレッドIDを引いて該当ステップを即座に特定できるようになった。
Apolloはこの評価体制を「AI Watchtower」と呼び、6層構造で運用している。
- 品質ディメンション： コード着手前に精度・トーン・関連性など3〜5項目の評価基準を定義（各1〜5点）。リリース前に50〜200出力を2名のレビュアーが独立評価する。評価項目を先に合意することで、後工程の手戻りを防ぐ狙いがある。
- E2E品質テスト： プロンプトやモデル設定を変更するPRとデプロイのたびに必ず実行するゴールデンシナリオ群。継続的インテグレーションの一部として組み込まれており、変更によるリグレッションを自動検知する。
- ライブトレース： LangSmithによるリクエスト単位のデバッグ。プロンプト・コンテキスト・ツール呼び出し・出力・レイテンシを全記録。新機能の初日から必須とされており、問題発生時の原因特定を大幅に高速化する。
- ライブインサイト： サンプリングトラフィックに対するLLM-as-judge（LLM自身を評価者として用いてテキスト品質を自動スコアリングする手法）スコア・拒否率・レイテンシの集計監視。スコアの大幅低下時はカテゴリ→サブカテゴリ→セグメントの3段階ドリルダウンを実施し、サンプリング率を一時的に50〜100%に引き上げる。
- 週次レポート（Pulse）： 全レイヤーを統合したスナップショット。プランティア・企業規模・業種別にコホート分析を行い、特定のユーザーセグメントで品質が劣化していないかを定期確認する。
- カスタマーフィードバック： 機能リリースと同PRでサムズアップ/サムズダウンUIをデプロイ。サムズダウンが7日間のローリングウィンドウで8%を超えると自動的にP1インシデントとして処理される。ユーザーの実体験をアラートのトリガーに直結させることで、内部指標だけでは見えない品質劣化を捉える仕組みになっている。
6層それぞれが開発・リリース・運用の異なるフェーズをカバーしており、問題を早期に発見する「前段」と、本番環境での継続監視を担う「後段」が組み合わさった多層防御の構造になっている点が特徴的だ。
ヘッドレス展開：MCPサーバーでの予想外の急成長
当初はUIに紐づいたプロダクト内チャットとして提供していたAIアシスタントだが、スキル型アーキテクチャへの移行によりUIから切り離すことが可能になった。現在はAPIおよびMCP（Model Context Protocol：AIエージェントが外部ツールやデータソースと標準化されたインターフェースで連携するためのプロトコル）サーバーとしても公開されており、Claude・ChatGPT・Perplexity上でのMCPサーバー統合にも同一のアシスタントが動いている。
VPエンジニアリングのHimanshu Gahlot氏はMCPの採用状況についてこう述べた。
「MCPがここまで爆発的に普及するとは誰も予想していなかった。実験的に試したチャネルのひとつだったが、採用ペースが相当速い。Apolloのユーザーは想定より技術的なGTMオペレーターが多いことがわかった。」
4万以上のチームがApollo MCPを利用しており、月間2億3000万件以上のAPIコールを処理するApollo APIを利用する50万チームに急速に迫っている。
次の一手：スケジュール実行と常時稼働型エージェント
今後の展開として、Apolloはスキルライブラリの深化と自律型エージェントへの投資を進める。ヘッドレスAPIを通じて、ユーザーはSlack等の外部ツールからアシスタントを操作し、毎朝ICP（理想顧客プロファイル）にマッチした上位50件のリードを自動取得するといった常時稼働型のプロセスを設定できるようになる見込みだ。
今回の事例が示すのは、スーパーバイザー型からフラットなスキルアーキテクチャへの移行が単なる実装上の選択にとどまらず、開発速度・品質管理・展開チャネルの拡張性という三つの軸に連鎖的な効果をもたらしたという点だ。MCPという新興プロトコルへの早期対応が予想外の規模で採用を呼び込んでいることも含め、AIエージェント基盤の設計指針として参照価値の高い事例といえる。
詳細はHow Apollo Rebuilt Its AI Assistant on Deep Agents to Power the Full GTM Loopを参照していただきたい。
