検索は「今あるもの」しか返さない。問題はどのように記憶を渡すか
日本では「RAG」がバズワードのように広がっている。一方で、デモやPoCでは動くのに、本番環境で使うには不安が残る──DevRev Japanの鈴木孝規氏は、多くのチームが直面しているこの課題を、1件の架空の問い合わせに沿って掘り下げた。
あるSaaS企業に、顧客から「ログインできません。朝から全社員が入れない」という問い合わせが朝9時に届いた。AIエージェントにZendesk・Jira・Salesforce・Notionを横断調査させると、4つのツールを300〜600ミリ秒ほどで直列に呼び出した末に、確信度「high」を示しながら「すでに修正済みです」という調査結果を返してくる。だが実際には、先週別の原因で解決した既知のチケットと、今朝発生した新しいチケットを取り違えており、顧客名も似た別の企業のものと混同し、ドラフト段階の手順書を類似度の高さだけで現行版と判定していた。
検索は「今あるもの」しか返さない。システム間に共通のキーがなく、似た会社名やバージョン違いの手順書を区別できないためだ。鈴木氏は、これはモデルの性能の問題ではないと強調する。モデルが公開情報しか学習しておらず、社内固有の情報を知らないのは今後も変わらない。問題は「どのような記憶をAIに渡すか」にある。
現在のAIエージェントは、人間に質問されて答えを返す「壁打ち相手」の域を出ていないと鈴木氏は指摘する。読むだけの用途であれば、精度が多少低くても人間が「それは違う」と指摘し直せば済む。しかし顧客への返信やデータの書き換えといった「アクション」を任せる段になると、一度実行された時点で事故になる。結局、AIがどれだけ速く動いても、確認と修正のために人間がボトルネックになってしまう。
一方、社内に必ずいる「大体のことを知っている」担当者に同じ質問をすると、10秒で的確な答えが返ってくる。「それは先週の障害とは別だね。担当者はこの人。あと、このお客様は商談中だから営業にも共有しておいて」というように、原因・担当・商談の状況までが素早く出てくる。
この担当者の頭の中では、チケットと顧客、商談、担当営業、そして製品機能と過去のIssue、現行の手順書までが線でつながっている。存在するデータそのものは、AIが参照したものと変わらない。違うのは、どのデータとどのデータが関係しているかを、あらかじめ知っているかどうかだ。この「線でつなぐ」作業を担うのが、ナレッジグラフだと鈴木氏は説明する。
記憶をあらかじめ用意して、LLMは判断だけを担う
鈴木氏は、ナレッジグラフに教え込むべき情報を「関係性」「時系列」「権限」という3つの鍵に整理する。開発チケット、カスタマーサポート、プロダクトフィードバックといった領域をこの3つの鍵でオントロジーにマッピングすることで、AIはベテラン社員のように振る舞えるようになるという。
「関係性」では、チケットを起点にグラフを深さ3までたどるクエリを1回実行するだけで、原因のIssue、影響を受ける複数の顧客、止まっている商談の金額、参照すべき手順書のバージョンまでが同時に確定する。「時系列」では、過去のIssueがいつ閉じられ、いつ新しいバージョンがリリースされ、いつからエラーが増えたのかという流れを見せることで、「似ているが別の現象である」とAIが正確に判断できるようになる。
「権限」では、同じ質問でも回答者が変わる。同じ「チケットの状況を教えて」という問いに対し、営業担当者が聞けば「あなたの担当のお客様が影響を受けます。早めにお客様と密にコミュニケーションを取り、調整と謝罪をしておきましょう」と商談への影響を中心に返し、サポート担当者が聞けば「現在開発はこの段階まで進んでおり、いつ直る予定です」と対応状況を中心に返す。同じAIを個別にチューニングしなくても、権限情報を埋め込んでおくだけで質問者の役割に応じて回答の中身そのものを切り替えられる。権限外のデータはそもそも回答に含まれないため、情報漏洩の防止にもつながる。
これをシステムとして構成すると、思考と判断を担うエージェント層、ナレッジグラフや時系列・権限・クエリルーターを持つコンテキスト層、ガードレールやロールバック、人間の承認を組み込むオーケストレーション層、そしてJiraやGitHub、Zendesk、Salesforce、Confluenceなどと双方向に同期する外部システムという4層構造になる。集計や確定値の取得にはSQL、類似文書の検索にはベクトル検索、IDやチケット番号の完全一致には逆インデックス、関係性の探索にはグラフデータベースというように、用途ごとに最適な技術を使い分ける。LLMにすべてを検索させるのではなく、記憶をあらかじめ用意しておき、LLMは判断だけを担うという構成だ。
もし最初から記憶を持つエージェントがこの障害に対応していたらどうなるか。チケット作成の瞬間にエージェントが起動し、同一顧客・同一コンポーネントの過去のIssueから「別事象である可能性が高い」と判断する。デプロイ履歴とログの相関から原因を特定し、直前のリリースにセキュリティパッチが含まれているためロールバックできないと判断した上で、その方針の可否だけを人間に確認する。影響を受ける顧客への通知ドラフトも自動生成され、内容の最終確認だけ人間が行う。修正が完了すればチケットは自動でクローズされ、関連システムも横断的に更新される。この一連の流れの中で、人間が行うのは方針への承認2回だけだった。
関係性・時系列・権限という組織の記憶を渡すことで、AIはチームメイトになる
鈴木氏が紹介したのは、米国のフィンテック企業「BILL」の事例だ。米国GDPの約1％に相当する取引を処理する金融機関で、年間140万件の問い合わせのうち70％を、AIエージェントが人手を介さずに解決しているという。
既存のSalesforce Service Cloudなど現場のツールは一切置き換えず、裏側でシステムをつなぎAIエージェントが自動でモニタリングする仕組みを構築した結果、返金処理のように従来は数分から数時間かかっていた問い合わせも、AIによって数秒で解決されるようになり、年間で約500万ドルのコスト削減につながった。最初の顧客セグメントは契約から約7週間で本番稼働し、全セグメントへの展開までも15週間で完了している。
この効果がモデルの進化によるものではないことを示すため、DevRevは第三者機関Laude Instituteと共同で「Enterprise-Bench」というベンチマークを作成し、データセットと評価方法をすべて公開している。同一モデル・同一データで検証した結果、データの取得方法をナレッジグラフ経由の記憶に変えるだけで精度は18ポイント向上した一方、モデルを新しいものに変えても向上したのはわずか1ポイントだった。同じ質問に対する回答の再現性を示すpass@5の値も、記憶を渡した場合は100％だったのに対し、MCP経由で都度検索させた場合は10回中2〜7回にとどまっている。
同じClaudeのモデルを使って比較した実測動画も紹介された。「最近の問い合わせから、顧客の不満に共通するテーマを教えて」という同一の質問に対し、都度データを取りに行くClaude単体は不満を箇条書きで並べるだけで、どのチケットが根拠かを示せない。一方、あらかじめ構造化された記憶を読む構成では、元チケットへの出典付きで具体的な事象まで踏み込んで整理できたという。この比較でトークン使用量は95％削減され、速度は5.5倍に向上した。同じモデルでも、渡す記憶が違うだけで結果はここまで変わる。
DevRevはこの仕組みを「Computer, by DevRev」という製品として提供している。200名を超えるエンジニアが2年以上、1.5億ドル以上を投じて開発してきたものだという。ナレッジグラフや時系列、権限フィルタといった基本構造自体はOSSでも構築できるが、異なるシステム間のイベントを自動で結びつける仕組みや、変更の影響を先回りで通知する仕組みなど、4件の特許が同社の技術の骨格になっている。ナレッジグラフに特化した企業は珍しく、鈴木氏はより大きな社会課題に取り組む企業としてPalantir社の名を挙げつつ、DevRevは企業向けのナレッジグラフに特化していると位置づけた。
鈴木氏は最後に、AIエージェントが本番で期待通りに動かないとき、まずモデルを疑う前に、AIに渡している記憶を確認してほしいと呼びかけた。部門をまたいで関係がつながっているか、いつ何が変わったかが分かるか、誰に何を見せてよいかが制御されているか。この関係性・時系列・権限という組織の記憶を渡せて初めて、AIエージェントは単なる道具ではなく、チームメイトになれる。
DevRev Japan合同会社からのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
