AIセールス担当者「Alice」の脳を構築する：人間のように学習するAIセールス担当者の開発秘話

はい、承知いたしました。入力動画または入力テキストに含まれる情報を網羅的に活用し、ブログ記事を作成します。出力はブログ記事の内容のみとし、タイムスタンプは含みません。

はじめに：セールスの未来を切り拓くデジタルワーカー

技術革新の波は、あらゆる産業の境界線を押し広げ、私たちの働き方、ビジネスのあり方を根本から変えようとしています。特に、近年目覚ましい進化を遂げているAI技術は、これまで人間が担ってきた複雑な業務にも変革の兆しをもたらしています。その最たる例の一つが「デジタルワーカー」の台頭です。

今回ご紹介するのは、11x社が開発したAIセールス開発担当者（SDR）「Alice」です。Aliceは、単なる自動化ツールではありません。人間のように学習し、進化し、企業が市場参入戦略を最適化し、成長を加速させるための強力なパートナーとなることを目指して開発されました。この記事では、AIセールス担当者「Alice」がどのように構築され、どのような課題を乗り越え、そして未来のビジネスにどのような影響を与えるのかを、技術的な深掘りとビジネス的視点の両面から詳細に解説していきます。

11x社が描く「デジタルワーカー」の世界

11x社は、「デジタルワーカーカンパニー」として、市場参入（Go-to-Market）組織向けのデジタルワーカー開発に注力しています。現在、同社は二種類のデジタルワーカーを提供しており、今後さらに多くのワーカーが加わる予定です。

Alice（AI SDR）: 今回の主役であるAIセールス開発担当者。
Julian（Voice Agent）: 音声による顧客対応を担うボイスエージェント。

これらのデジタルワーカーは、企業がより効率的かつパーソナライズされた顧客体験を提供できるよう、日々の業務を支援します。特に、セールス開発担当者（SDR）は、リードの発掘、顧客へのアプローチ、そしてミーティングの設定という、営業活動の初期段階において極めて重要な役割を担います。

AIセールス担当者「Alice」の使命と課題

従来のSDRの仕事は、主に以下の3つの責任から成り立っています。

リードの発掘: 潜在顧客を見つけ出す。
接触: 発掘したリードに様々なチャネルでアプローチする。
ミーティングの設定: 潜在顧客とのミーティングを設定する。

SDRの主要な業績評価指標（KPI）は、「ポジティブな返信」と「設定されたミーティング数」です。そして、このSDRの業務の大部分は、リードに送るパーソナライズされたメールの作成に集約されます。人間SDRが1日に20〜50通のメールを送るのに対し、AI SDRであるAliceは1日に約5万通ものメールを送信可能です。現在、Aliceは300以上の異なる企業組織のキャンペーンを運営しています。

Aliceがこの役割で成功するためには、以下の2つの要件を満たす必要があります。

「売り手」を知る: 売り手の製品、サービス、ケーススタディ、課題、提供価値、理想の顧客プロファイル（ICP）などを理解すること。
「リード」を知る: リードの役割、責任、関心事、これまでのソリューション、課題、所属企業などを理解すること。

本記事では、特に「売り手を知る」という点に焦点を当てて、Aliceの開発における課題と解決策を深掘りします。

従来の「ライブラリ」機能の問題点

従来の製品では、売り手は自身のビジネスに関する文脈情報（製品、ケーススタディなど）を、手動で「ライブラリ」と呼ばれるダッシュボードに入力する必要がありました。これには、各製品やサービスの詳細な説明、関連する課題、ソリューション、提供価値などを手作業で入力する作業が含まれていました。

この「ライブラリ」機能には、以下のような問題点がありました。

手間がかかる: 各情報の手動入力は非常に面倒で、時間と労力がかかりました。
オンボーディングの障壁: ユーザーはライブラリを完全に埋めるまでキャンペーンを実行できず、製品導入の大きな障壁となっていました。
最適なメールが生成されない: 入力された情報が多すぎたり少なすぎたりすると、Aliceが生成するメールの質が低下しました。情報が少ないと関連性のない提案をしてしまい、多すぎるとLLMのコンテキストウィンドウが溢れ、Aliceの賢さが損なわれました。

これらの問題は、Aliceの能力を最大限に引き出す上で、大きなボトルネックとなっていました。

「知識ベース」による革新：人間の学習を模倣するAI

これらの課題を解決するため、私たちは発想を転換しました。これまでは売り手がAliceに情報を「プッシュ」していましたが、私たちはAliceが自ら売り手の情報を「プル」できるようにする「知識ベース（Knowledge Base）」というアイデアを思いつきました。

知識ベースは、AIが人間のように学習・理解するプロセスを模模倣したものです。人間がSDRのトレーニングを受ける際、関連するドキュメントを与えられ、それらを読み込み、時間をかけて知識を習得するのと同様に、Aliceも多様な情報源から自律的に知識を獲得し、それを活用してパーソナライズされたメールを作成します。

知識ベースの概要と特徴

知識ベースは、売り手に関する情報を一元的に管理する集中型リポジトリです。ユーザーは、PDF、ウェブサイト、通話録音など、あらゆる形式の情報を知識ベースに追加できます。Aliceは、これらの情報の中から各リードに最も関連性の高いものを抽出し、メール作成に活用します。

SDRが重視する情報源:

SDRは、以下のような多岐にわたる情報源から知識を得ています。

マーケティング資料
製品ドキュメント
セールスプレイブック
ケーススタディ
過去のセールス通話
企業ウェブサイト
技術ドキュメント
プレスリリース
バイヤーペルソナ
業界ニュース
競合情報
研修資料

これらの情報源は、大きく分けて「ドキュメント」「画像」「ウェブサイト」「音声」「動画」の5つのリソースタイプに分類されます。知識ベースは、これらの多様なリソースタイプを処理し、Aliceが利用可能な形式に変換することで、SDRの学習プロセスを再現します。

「知識ベース」のパイプライン：情報の収集から可視化まで

知識ベースの実現には、複雑な技術的プロセスが伴います。ここでは、リソースの取り込みからAIエージェントによる利用までの5つの主要なパイプラインステップを詳しく見ていきます。

1. パース（Parsing）：非テキスト情報をテキストへ

パースは、PDF、画像、音声、動画などの非テキストリソースをテキスト形式に変換するプロセスです。LLMはテキストを理解するため、このステップはAIが情報を活用する上で不可欠です。テキストに変換することで、LLMにとって「読み取り可能」な情報となります。

パースの実装:

私たちは、パースシステムをゼロから構築しないことを選択しました。その理由は以下の通りです。

多種多様なリソースタイプ: 5種類の主要なリソースタイプと、それぞれの内部に存在する多数のファイルタイプを自社で全て処理するのは困難でした。
多大な労力: あらゆるリソースタイプに対応するパースシステムを開発するには、膨大な労力が必要でした。
成果への不確実性: 特定のリソースタイプに特化したパースシステムを構築しているベンダーが存在する中、自社で全ての専門家になるのは現実的ではなく、その成果も不確実でした。

そこで、私たちは外部のベンダーと協力することにしました。多数のベンダーを評価し、以下のような要件を設定しました。

必要なリソースタイプのサポート: 5種類の主要なリソースタイプ全てに対応できること。
Markdown出力: 構造情報や書式を保持できるMarkdown形式での出力に対応できること。
Webhookサポート: パース結果をWebhookで受け取れること。

最終的に、以下のベンダーを選択しました。

ドキュメント＆画像: LlamaParse (LlamaIndexの製品)
- 多数のファイルタイプをサポートしている点。
- 迅速なカスタマーサポート。
- 11xのセールス資料（PDF）をMarkdownファイルに変換できること。
ウェブサイト: Firecrawl
- 過去のプロジェクトでの利用経験があり、馴染みがあったこと。
- もう一つの候補であったTavilyのクロールエンドポイントが開発中だったため。
- BrexのホームページのようなウェブサイトをMarkdownドキュメントに変換できること。
音声＆動画: Cloudglue
- 音声だけでなく、動画にも対応していること。
- 単なるトランスクリプトだけでなく、動画自体から情報を抽出できる能力があること。
- YouTube動画やMP4ファイルからMarkdown形式の要約とトランスクリプトを生成できること。

これらのベンダーの選定により、私たちは多様な非テキスト情報を効率的にテキスト化する基盤を確立しました。

2. チャンキング（Chunking）：テキストを論理的な「塊」に分割

全ての情報がMarkdown形式に変換された後、次のステップはチャンキングです。チャンキングとは、長いテキストの塊を、意味のある論理的な「チャンク（塊）」に分割するプロセスです。これは、LLMが効率的に情報を処理し、関連性の高い部分を迅速に検索できるようにするために推奨されます。

チャンキング戦略:

チャンキングには、さまざまな戦略があります。

nトークン後に分割: 特定のトークン数で分割する。
n文後に分割: 特定の文数で分割する。
Markdownヘッダーで分割: Markdownのヘッダー構造に基づいて分割する。
LLMによる分割: LLM自身にチャンクを分割させる。
上記の組み合わせ: 複数の戦略を組み合わせる。

チャンキング戦略の決定:

チャンキング戦略を決定する際には、以下の質問を自問自答することが重要です。

データ内の「論理的な単位」とは何か？
どの戦略がそれらを損なわずに保持できるか？
リソースタイプごとに異なる戦略を使用すべきか？
どのような種類のクエリを期待しているか？

私たちの場合は、以下の組み合わせ戦略を採用しました。

Markdownヘッダーで分割
n文後に分割
nトークン後に分割

この戦略は、長く短いドキュメントの両方にうまく機能し、論理的な単位を保持しつつ、過度に長いチャンクを防止することに成功しました。

3. ストレージ（Storage）：ベクトルデータベースへの埋め込み

チャンク化された情報を保存する場所として、私たちはベクトルデータベース（Vector DB）を選択しました。RAG（Retrieval Augmented Generation）システムは必ずしもベクトルデータベースを必要としませんが、類似性検索を実行したい場合には最適化されています。

ストレージ技術の選択:

ベクトルデータベース以外にも、RAGには以下のようなストレージ技術が利用可能です。

グラフデータベース（例：Neo4j）
ドキュメントデータベース（例：Elasticsearch）
リレーショナルデータベース（例：MySQL）
キーバリューストア（例：Redis）
オブジェクトストレージ（例：S3）

私たちは類似性検索を行う必要があったため、ベクトルデータベースが最適な選択でした。そして、数あるベクトルデータベースの中から、Pineconeを選びました。その理由は以下の通りです。

高い知名度: 市場のリーダーであり、信頼性が高かったこと。
クラウドホスト型: インフラの追加構築が不要であり、運用が容易だったこと。
手軽な開始: 優れたスタートアップガイドとSDKが提供されていたこと。
埋め込みモデルのバンドル: 埋め込みモデルがソリューションにバンドルされており、別途埋め込みモデルプロバイダーを探す必要がなかったこと。
優れたカスタマーサポート: 多くの疑問や課題に対し、迅速かつ丁寧なサポートを提供してくれたこと。

Pineconeの導入により、チャンク化された情報が効率的にベクトル化され、検索可能な状態で保存されるようになりました。

4. リトリーバル（Retrieval）：関連情報の抽出

リトリーバルは、ユーザーからのクエリに対して、知識ベースから最も関連性の高い情報を抽出するプロセスです。過去1年間で、RAGの技術は著しく進化しており、「トラディショナルRAG」から「エージェンティックRAG」、そして「Deep Research」へと発展しています。

トラディショナルRAG: 情報を取得し、LLMへのシステムプロンプトを充実させる。
エージェンティックRAG: ツール（情報取得のための機能）を導入し、LLMがそのツールを呼び出して情報を取得する。
Deep Research: LLMが計画を立て、その計画に基づいて情報を検索し、必要に応じてさらなる検索を行う。

私たちは、この「Deep Research」の概念に基づいて独自のDeep Researchエージェントを構築しました。

Deep Researchエージェント「Letta」:

私たちは「Letta」というクラウドエージェントプロバイダーを利用して、Deep Researchエージェントを構築しました。Lettaは構築が非常に容易で、以下のように機能します。

リード情報を入力として受け取る: 顧客に関する情報をエージェントに渡します。
関連する質問リストを生成: エージェントはリード情報に基づいて、関連性の高い質問を複数生成します。
Pineconeツールを使用して各質問への回答を生成: 生成された質問に対し、Pineconeを検索ツールとして利用し、知識ベースから回答を生成します。
質問と回答のリストを出力: 最終的に、質問とそれに対する回答のリストを整理された形式で出力します。

このプロセスにより、Aliceはリードに対してより深く、多角的に情報をリサーチし、その結果をメール作成に活用できるようになりました。

5. 可視化（Visualization）：Aliceの「脳」を覗く

ETL（抽出・変換・読み込み）パイプラインにおいて、可視化は一見すると異質なステップに思えるかもしれません。しかし、これは顧客の信頼を得る上で非常に重要な要素となります。

「見せること」が信頼に繋がる:

私たちの顧客は、Aliceが彼らのビジネスを適切に表現していると信頼する必要があります。Aliceが本当に製品知識を持っているのか、ケーススタディや顧客の課題について嘘をついていないのかを知りたいと思っています。そこで、私たちは「ユーザーがAliceの脳を覗き見できる」ソリューションを考案しました。

知識グラフの可視化:

私たちは、Pineconeベクトルデータベースから抽出した全てのベクトルを3次元に投影し、インタラクティブな3Dの知識グラフとして可視化しました。これにより、ユーザーはデータポイント間の関係性を視覚的に理解することができます。グラフ内の任意のノードをクリックすると、それに関連するチャンク（元のテキスト情報）を閲覧できます。

この可視化機能は、私たちのセールスチームやサポートチームがAliceの知識を顧客に説明する際に活用されており、Aliceへの信頼を高める上で大きな役割を果たしています。

結論と今後の展望

知識ベースの導入は、私たち11x社の製品、ひいてはチーム全体にとって画期的なプロジェクトでした。これにより、AIエージェントはもはや単なるメール送信機ではなく、人間のSDRと同じように、あるいはそれ以上に深い知識と理解を持つ存在へと進化しました。私たちは、コンテンツを投入するだけでAIが自律的に学習し、それに基づいてパーソナライズされたアウトリーチを行う、真の人間のようなオンボーディング体験をエミュレートすることに成功しました。

得られた教訓

このプロジェクトを通じて、私たちは以下の重要な教訓を得ました。

RAGは複雑: RAGシステムの構築は、予想以上に複雑でした。数多くの技術の評価、マイクロな意思決定、多様なリソースタイプへの対応など、多岐にわたる課題がありました。この経験から、RAGの複雑性に対する深い理解と、その難易度への認識が深まりました。
まず実運用、次にベンチマークと改善: あらゆる決定事項やベンダーを評価する中で、完璧を追求しすぎるとプロジェクトが停滞してしまうことを学びました。まずは製品要件を満たす最低限の機能を開発し、実運用に乗せること。その後、実際のデータに基づいてベンチマークを確立し、繰り返し改善していくアプローチが効果的であると認識しました。
ベンダーに頼る: AIエコシステムには優れたソリューションを提供するベンダーが多数存在します。彼らは自社製品の専門家であり、私たちのビジネスのために競争しています。彼らを活用し、彼らから知識を学び、彼らのソリューションがなぜ優れているのかを理解することが、効率的な開発と成功への鍵となります。

今後の計画

今後のAliceの進化に向けて、私たちは以下の計画を立てています。

メールにおけるハルシネーションの追跡と対処: AIが事実に基づかない情報を生成する「ハルシネーション」の問題を追跡し、その発生を抑制するメカニズムを開発します。
パースベンダーの精度と網羅性の評価: 現在利用しているパースベンダーについて、精度と網羅性という、初期段階では重視していなかった指標に基づいて定期的に評価を行い、より高品質なデータ取得を目指します。
ハイブリッドRAG（ベクトルDB + グラフDB）の実験: 現在のベクトルデータベースに加えてグラフデータベースを導入し、より複雑な関係性や構造を持つ情報を効率的に検索・利用できるハイブリッドRAGシステムの可能性を探ります。
パイプライン全体のコスト削減: 全てのパイプラインにおけるコストを最適化し、より効率的かつ経済的な運用を目指します。特に、実運用データが得られたことで、具体的な利用状況に基づいたコスト削減策を講じることが可能になります。

AIセールス担当者「Alice」は、まだ進化の途上にあります。しかし、この知識ベースの構築を通じて、私たちはAIが人間のように学習し、思考し、そしてビジネスに貢献する未来への確かな一歩を踏み出しました。デジタルワーカーが当たり前になる未来において、Aliceがどのように企業の成長を加速させるのか、今後の展開にご期待ください。