Segmentsのご紹介：AIエージェントが事前に把握する内容を決める定義

有料プランのお客様が請求について質問すると、そのお客様が有料プランであることを前提とした回答が返ってきます。アカウントにフラグが付いたユーザーは、探り合いも回り道もなく、適切な復旧フローへ案内されます。多数のブランドを抱える企業の1ブランドに問い合わせたお客様が、同じグループの別ブランドのポリシーを聞かされることはありません。お客様は、なぜ回答がこれほどぴったりなのかを知りません。それこそが狙いです。

こうした体験を支えているのがSegmentsです。Mavenプラットフォームの中でも目立たない機能のひとつですが、最も重要な土台のひとつでもあります。そこで製品シリーズの第1回では、通常の発表では触れられない領域を取り上げます。エージェントが話し始める前に、どのナレッジドキュメントにアクセスできるかを決めるオーディエンス定義です。

Segmentsとは何か

Segmentsは、会話の種類やユーザーの種類を表す、名前付きの再利用可能な定義です。プレミアムアカウント、利用停止アカウント、メールチャネルでの会話、本人確認済みのユーザーなどが該当します。一度定義して分かりやすい名前を付ければ、必要な場所に適用できます。同じ定義でナレッジベース、アクション、ワークフロー全体を制御でき、そのたびに書き直す必要はありません。

Segmentは、オーディエンスの定義です。誰なのか、どのチャネルにいるのか、何を閲覧できるのかを定めます。見落とされがちなのは、Segmentsが製品の決定論的な要素であり、モデルの推論より前に実行されるという点です。調子が良ければモデルが従ってくれる、プロンプト内の提案ではありません。ゲートです。エージェントはまず定義を評価して対象となる情報を決め、通過したものに対してのみ推論します。セグメント外のナレッジやアクションは、使用を控えるよう促されるのではなく、そもそも存在しない扱いになります。

この順序こそが設計の要です。別ブランドの価格情報を無視するようモデルに丁寧に指示すれば、たいていは従うでしょう。しかし「たいてい」は、企業が責任を持てる基準ではありません。セグメントを使えば、この問題自体がなくなります。誤ったコンテンツは、最初から取得対象になっていないからです。

お客様が気づかないうちにセグメントに触れている場面

Segmentsは機能らしく見えないため、リリースノートで取り上げられることはほとんどありません。問題が起きないこと、という形で現れるからです。目立たないところで機能している例をいくつかご紹介します。

プラン別のアカウント

標準ユーザーと有料ユーザーが同じ質問をしても、必要な回答は異なります。アカウントの状態に基づくセグメントにより、それぞれに適したナレッジが対象となるため、エージェントが文脈の手がかりからお客様のプランを推測する必要はありません。お客様は、自分のプランに合った回答を受け取るだけです。

ブランドと事業の分離

あるMavenのお客様は、複数の消費者向けブランドを1つのエージェントで運用しています。ブランドの語り口、ポリシー、製品情報が境界を越えて漏れてはならないため、各ブランドのナレッジは互いに完全に分離しておく必要があります。Segmentsはこの分離を決定論的に実現するため、同じエージェントが多数のブランドに対応しても、あるブランドが別ブランドの回答を借用することはありません。ブランド間の混在もなく、ブランドごとに別のエージェントを管理する必要もありません。

社内向けナレッジと顧客向けナレッジ

サポートチームは多くの場合、エージェントが人間のオペレーターを支援する際には社内のランブックを参照し、お客様と会話する際には決して参照しないことを望みます。会話がCopilotモードかどうかに紐づいたSegmentを使えば、オペレーター向け資料は必要な場面では利用でき、不要な場面では見えなくなります。お客様が社内メモを目にすることはなく、オペレーターは常に参照できます。

インテントに基づくルーティング

ユーザーが何をしようとしているかをプラットフォームが判別できれば、Segmentによってその会話を専用の経路に送ることができます。アカウント作成とアクセス回復のインテントは、最初のメッセージでは似ていても、必要な対応はまったく異なります。Segmentsを使えば、エージェントは期待まじりの推測ではなく、決定論的なルールで適切なワークフローを選択できます。

「モデルが推論する前」がすべての核心である理由

ここでSegmentsは、より大きな仕組みとつながります。MavenのエージェントはGraph of Recordに基づいて推論します。Graph of Recordは、お客様、その履歴、そしてその背後にある信頼できるシステムを統合した全体像です。グラフには、エージェントが利用し得るすべての情報が含まれています。セグメントは、推論が始まる前に、その会話でどの部分を使うかを決めます。

いわば、インテリジェンスのためのアクセス制御です。Graph of Recordがナレッジであり、Segmentsは誰がいつどの部分を利用できるかを定める決定論的な定義です。この役割分担があるからこそ、1つのエージェントが企業全体を横断しても、リスクにはなりません。全体としては膨大な情報を把握しながら、どの瞬間においても厳密に範囲が限定されています。

これはまた、オーバーレイモデルと相反するのではなく、むしろ適合する理由でもあります。Mavenは、企業がすでに運用しているヘルプデスク、CRM、ナレッジソースの上に位置します。Segmentsは、その幅広い情報を無差別にすべての会話へ流し込むのではなく、適切に統制するための仕組みです。エージェントは多くのシステムに接続しながら、一度に許可される範囲はごく一部に意図的に限定されています。

大規模な自律解決においてこれが重要な理由

目指すのは自律解決です。エージェントは単にルーティングやディフレクションを行うのではなく、問題そのものを解決します。しかし、信頼できる解決を実現するには、エージェントが適切なナレッジと適切なアクションを、ほとんどの場合ではなく毎回選び取る必要があります。**Mastermindは、この基盤のもとで6週間以内に93%の自律解決率を達成しました。**高い解決率が安全といえるのは、エージェントが厳密に範囲を絞った正しい入力に基づいて推論している場合だけです。

リスクは具体的です。範囲の設定を誤れば、失敗は抽象的なものではありません。お客様に誤ったポリシーが伝えられる、利用停止アカウントが新規アカウントとして扱われる、あるブランドが別ブランドの語り口で回答する、といった事態が起こります。いずれも信頼を少しずつ損なうものであり、信頼こそAIエージェントが守るべきものです。こうした事態が起こらないのは、地味ながら欠かせないSegmentsがあるからです。

まとめ

最も信頼できるAIカスタマーサービスは、より賢いモデルだけで生まれるものではありません。モデルに何を見せるかを厳格に制御することで生まれます。Segmentsはその制御を担います。推論が1語も始まる前に、エージェントが誰と話しているのか、相手が何を知るべきかを、あらかじめ決めておく定義です。お客様がSegmentsについて尋ねることはないでしょう。ただ、ぴったりの回答を受け取り続けるだけです。