エンティティ解決こそAIエージェントの核心問題

私たちRevo AIは、メール上で動作するアンビエントAIエージェントを開発しています。以前、なぜメールがAIエージェントのコールドスタート問題を解決するのかについて記事を書きました。今回は、その開発で直面した最も困難なエンジニアリング問題について、そしてなぜこれがアンビエントAI全般における最大の難題だと考えるかについてお話しします。

地味だから誰も語らない問題

AI業界の会話はモデルの話題で持ちきりです。推論品質、コンテキストウィンドウ、ツール使用、推論速度。どれも重要ですが、実際の本番環境でエージェントが破綻する原因はそこにはありません。

エージェントが破綻するのは、エンティティ解決の問題です。

同じ人物が、Slackでは名前だけ、契約書ではフルネーム、メールスレッドではドメイン名、CRMでは会社名、サポートチケットではアカウントIDとして現れます。プロフェッショナルな文脈で動作するエージェントは、これらすべてのシグナルを見て、幻覚を起こすことなく、それらが同一のエンティティを指しているかどうか、そしてそのエンティティが他の既知の情報とどのような関係にあるかを判断しなければなりません。

これを間違えると、エージェントは静かに失敗するだけでは済みません。間違った案件の言葉遣いで返信を作成したり、間違った連絡先にフォローアップしたり、見るべきでない人に機密性の高い会話を結び付けたりします。アンビエントエージェントにおけるエンティティ解決の失敗は、単なるUXの問題ではありません。関係性のリスクであり、潜在的なプライバシー違反なのです。

これは、Revo AIで他の何よりも多くの時間を費やした問題です。まだ完全には解決していません。管理しているだけです。私たちが学んだことをお話しします。

なぜエンティティ解決は検索やCRMよりもエージェントにとって構造的に難しいのか

エンティティ解決は新しい問題ではありません。検索エンジン、CRM、データウェアハウスは何年も前からこの問題の変形版に対処してきました。しかし、エージェントは3つの理由でより困難なバージョンに直面しています。

エラーコストが非対称です。 通常のメールクライアントでの誤った自動補完は煩わしいだけですが、あなたに代わってメールを作成・送信するエージェントでの誤ったエンティティマッチングは関係性のリスクです。エラーに対する許容度は、受動的なツールよりも桁違いに低いのです。

シグナルがより雑音的です。 メールは非公式で、一貫性がなく、人間的です。人々は数千のメッセージで同じエンティティを何十通りもの異なる方法で参照します。スキーマはありません。強制される命名規則もありません。エージェントは、大規模な非構造化シグナルから構造を推論しなければなりません。

グラフが動的です。 エンティティは変化します。人々は役職を変え、企業は買収されてドメインが変わります。エンティティグラフは一度構築してキャッシュすることはできません。新しいメッセージが届くたびに継続的に更新し、新しいシグナルが既知の情報と矛盾する場合は競合をフラグする必要があります。

Revo AIで実際に構築したもの

私たちは、処理されるすべてのメッセージと共に更新される生きたエンティティグラフを維持しています。このグラフは人、企業、案件、スレッド、ツールを接続し、異なる命名規則やデータソース間で同じエンティティをリアルタイムで解決します。

グラフが矛盾するシグナルに遭遇した場合（同じ会社にJamesという名前の2人の連絡先がいる、買収後にドメインが変更された、2人の異なる人物を指す可能性のある名前など）、推測する代わりに曖昧性をフラグします。私たちは未解決の曖昧性を、抑制すべきエラーではなく、第一級の状態として扱います。

これは自動化のカバレッジを犠牲にします。曖昧性をフラグすることは、一部のアクションが自動的に実行されず、代わりに人間のレビューのために表面化することを意味します。私たちはこのトレードオフを意図的に選択しました。代替案（推測して間違える）は、ユーザーがエージェントを永久にオフにしてしまうような失敗を生み出します。

エンティティ解決は、厳格なプライバシー境界内で行われる必要もあります。プロフェッショナルな受信箱を読むエージェントは、クライアント、案件、チーム、組織階層にわたる機密情報にアクセスできます。エンティティグラフは、エンティティがどのように接続されているかだけでなく、エージェントが何を接続することを許可されているかを知る必要があります。ドメインレベルのアクセス制御は、オプションのインフラストラクチャではなく、解決ロジックの中核部分です。プライバシー制御なしのエンティティ解決は、機能ではなく負債です。

アンビエントAIが機能するとき実際に何が起こるか

ほとんどのアンビエントAI製品は「技術的に正しい」と「信頼できる」の間のギャップで死にました。難しいのは、行動できるエージェントを構築することではなく、行動すべきでない時を知っているエージェントを構築することです。

エンティティ解決が機能しているときの火曜日の朝はこのような感じです：

午前8時14分 「Lisa ChenがMeridian契約のIP条項にフラグを立てました。Acme案件の標準文言を使用して返信案を作成しました。」

午前8時22分 「James ParkからQ2予算について返信なし（5日間）。フォローアップを作成しました。」

午前9時01分 「Sarahが移行が完了したと言及しました。3つのクライアントチケットがそのバグに言及しています。更新を作成しました。」

それぞれ：承認、拒否、またはフィードバックを提供。これが全インタラクション表面です。エージェントが作業を計画し、ユーザーが出力を管理します。

UXの帰結：信頼は段階的に獲得される

Revo AIのエージェントは、狭い範囲から始めて、より広範なアクションへの道を獲得するように設計しました。初日は単純なものを表面化します：忘れられたフォローアップ、保留中の返信のドラフト、フラグされた競合。承認または却下。設定不要、プロンプト不要、マニュアル不要。

これは元のデザインではありませんでした。技術的に正しかったが、信頼する準備ができているよりも速く動いたエージェントを初期ユーザーがオフにするのを見て対応したものです。段階的開示は単なるUXパターンではありません。エージェントがより高リスクなアクションを開始する前に、エンティティ解決が機能していることを確認するのに十分な時間をユーザーに与える方法なのです。

これがエージェントインフラに意味すること

エンティティ解決は機能ではなくインフラストラクチャです。実際のプロフェッショナルなコンテキストで動作するAIエージェントが行動を信頼できるかどうかを決定するレイヤーです。データが複雑になった瞬間に壊れる洗練されたデモではありません。

ほとんどのエージェントフレームワークはこれをエッジケースとして扱っています。そうではありません。これが核心的な問題です。長期的に使用されるエージェントは、最高の推論を持つものではなく、グラフアーキテクチャ、曖昧性処理、プライバシー制御、信頼ペーシングの適切な組み合わせでこの問題を解決するものになるでしょう。

メールは、データが最も雑然としていてエラー許容度が最も低いため、エンティティ解決を解決するのが最も困難な環境です。これがメール上でそれを解決することが一般化する理由でもあります。Revo AIでプロフェッショナルな受信箱全体でエンティティを解決するために構築したインフラストラクチャは、あらゆるアンビエントエージェントが非構造化された実世界のデータで確実に動作するために必要な同じインフラストラクチャです。

ご興味をお持ちいただけましたら、ご連絡ください：mehdi@revo.ai