AIエージェントは「チームメイト」になれるか - 開発・サポート・ビジネスをつなぐ新しい働き方

生成AIでコード生成や要約が当たり前になった今、次の問いは「AIがチームの一員として事業成果に貢献できるか」です。本セッションでは、DevRevが実践する「AI as Teammate」のアプローチを紹介。開発チケット、カスタマーサポート、プロダクトフィードバックをナレッジグラフで統合し、AIエージェントが文脈を理解して自律的にアクションする世界を、グローバル事例とデモでお見せします。年間140万件の問い合わせの70%をAIが自律解決し500万ドルを削減した事例など、「要約の先の自動化」を支えるアーキテクチャと設計思想を共有します。

Transcript

1. AIエージェントは 「チームメイト」になれるか 開発・サポート・ビジネスをつなぐ新しい働き方 17-C-3 鈴木 孝規 · DevRev Japan · Lead of Solution Engineering 2026.07.17 · JP Tower P1
2. 開発（Dev）と顧客（Rev）を、一つのナレッ ジグラフでつなぐAIプラットフォームです。 サポート・製品開発・営業に散らばった情報を統合し、AIエージェントが文脈を理解して動作す る基盤を提供しています。 2020年 米国パロアルトで創業 Nutanix共同創業者が設立 従業員750名・世界8拠点 2025年9月 日本法人設立 特許30件以上 CodeZine（翔泳社）インタビュー 数兆規模のデータを現場のコンテキストに変換 ── 「Computer」が変えるAIの正確 さ・コスト・安全性 自己紹介 鈴木 孝規 DevRev Japan / Lead of Solution Engineering X @takanorisuzuki 著書（Zenn Book） LLMをもっと賢くする ナレッジグラフ実践入門 ナレッジグラフとLLMの実装を専門にしています。 OSS · cc-room ホワイトボードのある会議室に集まるように、みんなで Claude Code を使って一緒に開発する 体験をつくるツール。人とAIが共存する開発のためのOSSです。 P2
3. 本セッションのテーマ RAGを組み、デモでは完璧に動いた。 それでも本番で、AIは自信を持って間違える。 多くのチームが直面しているこの課題を、今日は一段深いところから捉え直します。 AIエージェントを本番で機能させるための、今日から使える新しい視点を一つ、お持ち帰りいただきます。 P3
4. ここからは、ある1件の問い合わせの物語 あるSaaS企業に、顧客からこんな問い合わせが届きました。 TKT-421 · 新規 受信: 2026年6月30日（火）9:02 「ログインできません。朝から全社員が入れない。至急お願いします」 エーテック製作所 情報システム部 佐藤様 あなたのチームのAIエージェントは、この1件に答えられるか P4
5. AIエージェントに、状況の調査を頼む "エーテック製作所でログイン障害が起きている。原因と影響範囲を調査して" MCP経由: 4つのツールを直列で呼び出す ▸ zendesk.search_tickets(query="ログイン エーテック") 312ms ├─ TKT-368 solved 2026-06-22 "ログインできません" │ resolution: "トークン期限の問題、修正済み (6/25)" └─ TKT-421 open 2026-06-30 "ログインできません。朝から..." → 先週の類似チケットに「修正済み」の記録あり ▸ jira.search_issues(jql='text~"login" ORDER BY created') 418ms └─ ISS-9 Closed fixVersion: v2.3.1 → 関連Issueは1件。Closed。本当の原因はまだ未起票 ▸ salesforce.query("エーテック") 502ms ├─ ACC-2201 "株式会社エーテック製作所" ← 今回の顧客 └─ ACC-3047 "エーテックス株式会社" ← 別会社 → 2社ヒット。共通キーなし。判別不能 ▸ notion.search(query="ログイン障害 対応手順") 603ms ├─ "対応手順 v1" (2024-08) similarity 0.88 ├─ "対応手順 v2" (2025-11) similarity 0.91 └─ "対応手順 v3" (draft) similarity 0.89 → 3件。本文8割同一。現行版の判別不可 AIの回答: 自信満々の誤答 ⚠ investigation_result (confidence: high) { "incident": "ログイン障害", "status": "resolved", "root_cause": "トークン期限のリグレッション (ISS-9)", "fixed_on": "2026-06-25", "customer": "エーテック製作所", "recommendation": "先週修正済みです。再発の場合は 環境をご確認ください" } ▪ 検索は「今あるもの」しか返さない：本当の原因はまだ誰にも起票されていない ▪ システム間に共通キーがない：類似度で「たぶんこっち」と推測するしかない ▪ 類似度では「現行版」を選べない：本文8割同一の手順書から判断できない これはモデルの性能の問題ではありません。速いモデルでも、賢いモデルでも解決しません。AIに渡している「記憶」の問題です。 P5
6. なぜ、AIエージェントは本番で戦力にならないのか 読む（質問して、回答をもらう） 精度が低くても許容できる 回答が甘くても、人間が「それは違う」 「先週のとは別では？」と何度でも壁打ちでき ます。 間違った回答が返ってきても、読んで捨てればいいだけ。実害はありません。 つまり、多少精度が低くても、対話でカバーできます。 アクション（データを書き換える・送信する） 精度が低いと任せられない 一度実行したら取り返しがつきません。例： ▪ 別会社（エーテックス）に、他社の障害情報を誤送信 ▪ 顧客のデータベースを、誤った内容で上書きして破壊 ▪ 「修正済みです」と誤った案内を顧客に送信 壁打ちでカバーできない。実行された時点で事故です。 だからAIにはドラフト作成までしかさせられない。最終アクションは、必ず人間が確認して実行する。 その結果、AIがどれだけ速くても、人間がボトルネックになる デモは動く。読むのも速い。それでも本番で戦力にならないのは、"安心して任せられない"からです。 P6
7. 一方、社内で最も状況を把握している担当者に聞くと サポートマネージャー・高橋さん（もともと開発部で認証システムを担当し、3年前にサポートへ異動） 「これは認証まわりのログイン障害ですね。先週も似た障害があって、直したのは開発の中村 さんです。ただ、あれはログインの有効期限の設定ミスでした。先週いったん直っているの で、今回はおそらく別の原因でしょう。中村さんに調査を依頼しましょう。あと、エーテック 製作所は契約更新の時期が近いので、営業にも共有しておいてください」 10秒 この担当者の頭の中には、 何があるのか P7
8. 詳しい人の頭の中には、何があるのか TKT-421 サポート エーテック 製作所 担当営業 ログイン機能 製品コンポーネント ISS-9 先週Close・別原因 ISS-12 今回の本当の原因 手順書v2 現行公開版 商談 9,000万円 サポート 顧客・営業 製品・開発 ナレッジ クローズ済み この順に線をたどると、推測だった判断が根拠を持って確定します ① TKT-421 をくれたのは エーテック製作所（エーテックスとは別会社と確定） ② TKT-421 は ログイン機能 に紐づく ③ ログイン機能で先週 ISS-9 が直っている。時系列で見ると今回とは無関係 ④ だから今回は別事象。新しい Issue（ISS-12）が必要と判断できる ⑤ ログイン機能には手順書がマップ。現行版は v2 だと分かる ⑥ エーテック製作所には 商談9,000万円 が紐づいている ⑦ その商談には 担当営業 が紐づく。営業に連絡が必要と分かる バラバラだった点が、線でつながった瞬 間。AIは、推測ではなく、たどって答えら れます。 これが、詳しい人の頭の中にあったものです。 P8
9. 点を線でつなぐもの、その名前 ナレッジグラフ 点（データ）を、関係でつなぐ層。詳しい人の頭の中を、AIに渡せる形にしたもの。 あらかじめ定義された関係（オントロジー）に沿って、点と点をつなぎます。 関係 時系列 権限 オントロジー このナレッジグラフで、開発チケット・カスタマーサポート・プロダクトフィードバックの3つを統合します。 P9
10. ナレッジグラフが持つ、3つの鍵 関係 チケット・障害・商談・手順書が、どう繋がっているか。開発・サポート・ビジネスをつなぐ鍵です。 時系列 いつ何が起きて、いま何が変わっているか。先週の障害と今回は、同じか別か。 権限 誰に、何を見せてよいか。役割によって、見える情報と答えが変わります。 P10
11. 鍵① 関係 つながりをたどれば、影響範囲まで一度でわかる "エーテック製作所でログイン障害が起きている。原因と影響範囲を調査して" graph.traverse(start="TKT-421", depth=3) 1回のクエリ · 41ms TKT-421 (緊急) ├─ caused_by ──→ ISS-12 [修正中 80%, v2.4.2 で 7/8 リリース予定] │ └─ affects ──→ 3社 (名寄せ済み: エーテック製作所 / C社物流 / B社リース) │ ├─ has_opportunity ──→ 商談 ¥90,000,000 ← この障害が商談を止めている │ └─ resolves_by ──→ 手順書 v2 [前提: 先に認証サーバ再起動を実施] v1 → 無効化済み ✗除外 / v3 → 下書き ✗除外 ✓ 調査結果（グラフを1回たどって取得） 原因 : ISS-12（恒久修正 v2.4.2 を 7/8 リリース予定） 影響顧客 : 3社（エーテック製作所 / B社リース / C社物流） 商談影響 : 9,000万円の商談が、この障害で止まっている 対応手順 : 手順書 v2 ※先に「認証サーバ再起動」が必要 → Jira / Salesforce / Zendesk も同時に更新済み 推測で止まるか、根拠を持って答えるか P11
12. 鍵② 時系列 その時しか見ないAIには、できない判断 Close → 再Open は、重要度が違う（一度直したのにま た開いた） デプロイ前後で原因を切り分けられる（このリリース後 にだけ症状） 今回のケース：先週のISS-9と今回は、似ているが別原因 timeline(node="ログイン機能", window="30d") 06-25 ISS-9 修正完了（Close） 原因: ログイン有効期限の設定ミス 06-29 22:00 v2.4 リリース ← この後にだけ、今回の症状が出ている 06-30 09:15 認証エラーが急増 ▲ ← リリース後の朝ピークで発生 06-30 10:20 ISS-12 起票 → 修正着手 07-07 修正 80%（レビュー完了・QA中） ────────────────────────────────────── ⇒ ISS-9 は 6/25 に Close。今回は 6/29 リリース後に発生。→「別原因」と判定 「似ているが別原因」は、前後関係を持っているから言える P12
13. 鍵③ 権限 誰が聞くかで、答えが変わる 営業が聞くと 商談への影響を中心に サポートが聞くと 進捗・FIX予定・類似判定を中心に 開発が聞くと 技術的な原因中心。商談金額は見えない 質問:「TKT-421 の状況を教えて」 ▸ 営業が実行 → 商談 9,000万円 が停止中 / 修正 7/8 予定 / 顧客への共有を推奨 （進捗の技術詳細は要約のみ） ▸ サポート担当が実行 → 原因 ISS-12（修正中）/ 先週の ISS-9 とは別原因 / 対応手順 v2 （商談金額は結果に含まれない） 権限外のデータは、そもそも回答に含まれない だから、誰にでも安心して使わせられる P13
14. 3つの鍵を、システムにすると エージェントは考える、ワークフローが実行する エージェント層　思考・判断（Claude / GPT） コンテキスト層　ナレッジグラフ + 時系列 + 権限 + クエリルーター オーケストレーション層　ガードレール / ロールバック / Human-in-the-loop 外部システム　Jira / GitHub / Zendesk / Salesforce / Confluence（双方向同期） 集計・確定値（影響は何社？契約金額の合計は？） SQL 意味の近い文書・過去事例 ベクトル検索 ID・チケット番号・エラーコードの完全一致 逆インデックス 関係の探索（どの機能の話か） グラフDB LLMに検索させない。記憶が先、LLMは判断だけ。 P14
15. あの朝を、記憶がある世界で。要約の、その先へ もし最初から、記憶を持ったエージェントがいたら？ ① 着弾 9:02〔サポート〕チケット作成の瞬間にエージェント起動。同顧客・同認証コンポーネントの過去Issueを発見。 「先週のISS-9は6/25 Close、今回はそれ 以降に発生。別事象の可能性が高い」 ② 原因特定〔開発〕デプロイ履歴×ログ相関 →「このリリースが原因」 deploy auth-gw v2.4 22:00 │ metric エラー急増 08:45 ▁▁▁▂▅█ ③ ロールバック判断＝動かない判断〔開発〕v2.4にセキュリティ修正（セッション固定化攻撃対策）が同梱 → ロールバック不可、前方修正（新しいパッチで直 す）が必要と判断。理由付きで記録 ④ インシデント起動＝承認①〔開発〕ISS-12自動起票、中村さんアサイン。Slack #incident-auth-gw 自動作成、関係者招待。人間の判断: この方針でGoか ⑤ 影響顧客通知＝承認②〔営業・サポート〕affectsリンクから3社特定、担当営業・SEに自動通知。佐藤部長への一次回答ドラフト生成 → 人間の判断: 顧客に出 す前の最終確認 ⑥ 自動クローズ〔全部門〕修正コミット → CI/CD → デプロイ検知 → ISS-12 Closed。Jira/Zendesk/Salesforce横断更新。営業に「商談再開可」シグナル。 #incident-* にサマリー投稿 人間がやったこと: 承認2回 P15
16. 1週間後。あのチケットは、どうなったか AIに投げた質問 "先週のエーテック製作所のログイン障害、あれどうなった？" ✓ TKT-421 の顛末（グラフをたどって取得） ・原因 ISS-12 は 7/8 に修正版をリリース、Close 済み ・エーテック製作所へは、障害中に「原因特定・修正予定」を事前共有できたため、大きなクレームにならずに済んだ ・同じ「ログイン機能」を使う他2社（B社・C社）にも、担当から事前に連絡済み。問い合わせが来る前に説明できたので、こちらも大事にならなかった ・止まっていた 9,000万円の商談 は、修正完了の連絡で再開 関係を理解したAIは、聞かれる前に動ける。 P16
17. データの複利：使うほど賢くなる 判断が記憶になる。記憶が次の判断を助ける 【今回】 人間が判断し、AIが実行する。 「前方修正で行く」と 決定 → エージェントが実行 【次回】 3ヶ月後、同じ認証システムで別障害。エージェント が過去の対応を参照し「前回の判断理由はこれです。 今回はどうしますか？」と提示 【やがて】 誰かの失敗を別の人が繰り返さない。誰かの成功を全 員で使える。全員の経験から学ぶ = データの複利 記憶があると、ツールの"ズレ"にも気づける。例：PRはQAまで進んでいるのに、Jiraのステータスだけ未更新 → AIが矛盾を検知し、自動で同期／通知だけで止める。ツール間のコピペ確 認は、人間の仕事じゃない。 memory.md は自分の経験からしか学ばない。組織の記憶は、全員の経験から学ぶ。 P17
18. グローバル事例：BILL（米国のFINTECH・GDPの約1%相当の取引を処理） 140万件 年間の問い合わせ 70% AIが人手を介さず解決 500万ドル 年間コスト削減 この数字の中身：エージェントが何をしているのか ▪ システムはリプレースしていません。記録システムの Salesforce Service Cloud と請 求システムを、そのままつないだだけ。 ▪ 現場の人の仕事も、ツールも変わりません。サポート担当は今までどおり Salesforce Service Cloud の画面でサポート業務を続けています。 ▪ 金融機関なので、依頼にはお金が絡みます。返金処理や請求書の取得といった依頼も含 まれます。 ▪ それを、AIエージェントだけで7割、人手を介さず自動で対応しています（インテント 検知 → 自動ワークフロー実行） 。 既存システムをリプレースしないから速い。最初の顧客セグメントは契約から約7週間で本番稼働。全セグメントへの100%展開まで15週間。 出典: devrev.ai/ja/customers/bill P18
19. 実測の比較動画 同じClaudeでも、記憶があると答えが変わる 同じ質問を、同じClaude Sonnet 4.6で実行。左＝Claude単体（Skills / MCP で毎回データを取りに行く） 、右＝Computer（同じClaudeが、事前統 合された記憶を読む） 。 動画で投げている質問 「最近の問い合わせから、顧客の不満に共通するテーマを教えて」 サポートに来た大量のチケットを横断して、傾向をまとめる調査 Claude 単体の答え 不満を箇条書きで並べるだけ。分類は抽象的でハイレベ ル。 「どのチケットが根拠か」が示されず、次に何をすべき かまでは踏み込めない。 Computer の答え 要約と優先アクションで構造化。 「ゴールド会員に不要な 手荷物料金が請求されている」など具体的な事象まで、元 チケットへの出典つきで提示。 Claudeは毎回データを取りに行き、推測で補う。Computerは構造化した記憶から必要な情報だけを読 む。だから同じ問いでも、要約の質・具体性・裏付けが変わる。 正確さ 1回で確定 Claude:何度も聞き直し トークン 95%減 同条件ベンチ 速さ 5.5倍 同条件ベンチ 出典: devrev.ai（Claude Sonnet 4.6 同条件比較・7回実行の平均） P19
20. では、それをどう測るのか 同じものさしがなければ、比べられない 問題：測る基準がなかった 世のLLMベンチは競技のように"難問が解けるか"を測ります。しかし本番のエンタープライ ズで問われるのは違います。 ▪ 本番の大量データでも精度が保てるか ▪ 持続可能なコストで動くか ▪ 権限を守って動くか 解：第三者機関と作り、公開した DevRev は、第三者機関（Laude Institute）と共同で Enterprise-Bench を作り、データ セット・評価方法・採点基準をすべて公開しました。どのベンダーも自社のエージェントで 走らせて、結果を提出できます。 実験条件: 同一モデル(Claude Opus)・同一データ(128件 → 32,768件、正解は全スケールで固定)・変えたのはデータの取り方だけ / 14タスク × 10試行 × 5スケール = 700観測点 精度（データ量を変えても） 92–97% 記憶（一定） / MCP 57% 信頼性 pass@5 100% 記憶 / MCPの多段は 2–7/10 データ256倍時のコスト 横ばい 記憶 / MCP +37% ※pass@5＝同じ質問を5回繰り返して5回とも正解する確率 モデルを最新にしても +1pt vs 正しい記憶を渡すと +18pt ボトルネックはモデルではなく、記憶。 同じモデル・同じデータで、変えたのはデータの取り方だけ。その実験的な裏付けです。 Enterprise-Bench Methodology Deep Dive (July 2026) · Laude Institute と共同 · dataset + harness: public · devrev.ai/enterprise-bench-methodology P20
21. 製品としての紹介と、実装上の線引き Computer, by DevRev ナレッジグラフ・時系列・権限フィルタといった基本構造は、OSSでも構築できます。では製品として何が違うのか。取得済みの特許4件が、本日ご覧いただいた仕組みの骨格です。 1 異種システムのイベント統合・自動相関 チケットとIssueを自動で結ぶ仕組み（P11） US12,112,297 2 変更のインテリジェント通知 影響する3社へ自動で先回り通知（P15） US12,306,822 3 3層スケーラブルなベクトルDB 大規模データでも速い類似探索エンジン（P14） US12,361,029 4 LLM＋ライブ文脈での応答生成 記憶を渡した上で、根拠つきで答える（P11） US12,475,156 200名超のエンジニアが、2年以上・1.5億ドル以上をかけて作ってきたのは、"最後の、地味な2割"： ▪ 4システムの複合マッチによる自動名寄せ ▪ プレビルトオントロジー（関係の定義が最初から入っている） ▪ 全エンジンへの権限注入（検索もSQLも漏れなく制御） 小規模なチームや、単一ツールで完結する範囲であれば、自作の方が速い場合もあります。自作と製品導入、いずれを選ぶかは要件次第です。 P21
22. AIエージェントは、 「チームメイト」になれる。 条件は、関係・時系列・権限という「記憶」を渡すこと。 Work Softer. P22
23. ご清聴ありがとうございました P23