特許から読む DevRev の思想 ― AIはなぜ"業務"に入れるのか
特許から読む DevRev の思想 ― AI はなぜ「業務」に入れるのか
このブログで、なぜ自分が DevRev という会社を選んだのかを、初めてきちんと書こうと思います。
転職理由としてよく語られる「プロダクトが面白そうだった」「人が良かった」「成長していそうだった」といった話ではありません。
自分の場合、決定的だったのは DevRev が出している特許群を読んだときでした。特許を読んだ瞬間に、「あ、この会社は AI をどう"使うか" ではなく、業務をどう定義し直すか を考えている」と感じたのを、今でもはっきり覚えています。
なぜ転職を決めたのか：家庭教師 AI から見えた「分断」という本質問題
2025 年 2 月に子供の中学受験があったため、2024 年は OpenAI を使って子供向けの家庭教師 AI を開発していました。
その過程で、RAG やコンテキスト管理の課題と向き合うことになりました。
AI が生活に欠かせないものになっていく中で、インターネットが出てきたときと同じような感覚を得ました。残りの人生で、こういう産業革命に当たるタイミングはそう多くない。だから、AI に全力投資しようと決めました。
LLM/RAG だけではどうにもならないという実感
AI 関連の企業を調べる中で、LLM を作っている会社の話も聞きました。しかし、自分が家庭教師 AI を作るプロセスを振り返ったとき、LLM と RAG だけではどうにもならないという実感を持っていました。
人間だったらどういう業務をやるかを考えて、それを AI にやらせようとしたときに、どうしても分断が起きるのです。
一つの問題集を読ませても、RAG でわざわざ分解してチャンクにして、また LLM で再合成したら精度が出ないのは当たり前です。受験問題を自分で作ったのに、解説のときに間違えたり、似ているから OK ではないものを求められたりしました。
LLM はこれからも進化を続けるでしょう。しかし、根本的には LLM/RAG ではできないところをやる必要があると思っていました。
業務の「分断」をどう扱うか
家庭教師 AI を作る中で気づいたのは、次のような問題でした。
- 問題集をチャンク化すると、文脈が失われる
- 再合成しても、元の構造が復元できない
- 似た問題を区別できない（「似ているから OK」ではない）
- 自分で作った問題なのに、解説で間違える
これらは、技術的な問題というより、業務をどう定義するかの問題でした。
人間の家庭教師なら、問題集全体を理解し、子供の理解度を把握し、適切な問題を選び、解説する。この一連の流れは、分断されていません。
しかし、RAG ベースのアプローチでは、この流れを分解して再構成する必要があります。その過程で、どうしても情報が失われ、精度が落ちる。
この経験から、自分は次のように考えるようになりました。
AI を業務に組み込むとき、
既存の業務を分解して AI に渡すのではなく、
業務そのものを AI が理解できる形に再定義する必要がある
同じ業務データを扱う場合でも、アプローチによって結果が大きく異なります：
従来のアプローチ：業務を分解して AI に渡す
DevRev のアプローチ：業務を再定義する
この「分断」の問題は、後述する DevRev の 4 つの中核特許が解決する課題そのものです。
なぜ「特許」なのか
プロダクト資料やデモは、どうしても「今できること」を語ります。
一方で特許は、「何を前提に世界を切り取っているか」が露骨に出ます。
- 何を第一級の概念として扱うのか
- どこを自動化の境界線に引くのか
- どこを人間に残し、どこを機械に渡すのか
DevRev の特許は、どれも一貫して
「AI を業務の外に置かない」
という思想で貫かれていました。
特許が語る「設計前提」
特許を読むと、その会社が何を「当たり前」として設計しているかが分かります。
例えば、多くの SaaS は「データは一箇所に集まっている」ことを前提にします。しかし DevRev の特許は、最初からデータが分断されていることを前提にしています。これは単なる技術的な選択ではなく、現実の業務をどう捉えるかという設計思想の違いです。
特許は、その設計思想を法的に保護するものです。つまり、特許を読むことで、その会社が何を変えられない前提として固定しているかが分かります。
AI の世界では、モデルやフレームワークは数年で置き換わります。しかし、業務構造の設計思想は、そう簡単には変えられません。だからこそ、特許から「この会社が何を前提にしているか」を読み取ることが重要です。
AI をやると決めたとき、会社選びで一番重視したもの
自分が「AI を本気でやる」と決めたとき、会社選びで一番重視していたのは **特許や IP（知的財産）**でした（理由は前述の通り）。
家庭教師 AI を作る経験から、技術の進化よりも、業務構造の設計が重要だと実感していました。LLM は進化し続けますが、業務をどう定義するかは、もっと根本的な問題です。
DevRev が解こうとしている問題は「AI 活用」ではない
多くの AI 活用は、次の問いから始まります。
既存の業務に、どこで AI を使えるか？
DevRev の特許を読んで気づいたのは、この問い自体を最初から採用していない、という点です。DevRev が立てている問いは、もっと根本的です。
そもそも「業務」とは何か？
AI が理解できない業務とは、どこが壊れているのか？
この問いに対する答えが、4 つの中核特許に分解されて現れています。
中核となる 4 つの特許が示す思想
1. 業務データは、最初から分断されているという前提
METHOD AND SYSTEM FOR INTEGRATED ANALYSIS OF DATA FROM MULTIPLE SOURCE ENVIRONMENTS
この特許が前提にしているのは、とても現実的な世界です。
- 顧客情報はここ
- 開発の履歴はここ
- 人事情報はここ
- 経費関連はここ
- 障害や問い合わせはメール、チャット、リモート会議など
「正しい情報が一箇所にある」世界を、最初から信じていません。
なぜこの前提が重要なのか
多くのシステムは、「データを一箇所に集めれば解決する」と考えます。しかし、現実の業務では：
- データは常に複数のシステムに分散している
- 各システムは異なるスキーマや形式を持っている
- データの整合性は、システム間の同期によって保たれている
この特許が重要なのは、単にデータを集めるのではなく、分析可能な一つの現実として再構成する方法を定義している点です。
例えば、顧客サポートの問い合わせが来たとき、顧客情報は CRM に、過去の問い合わせ履歴は別のシステムに、契約情報はまた別のシステムにあります。従来のアプローチでは、AI が質問に答えるために、これらのシステムを個別に参照する必要があり、情報が分断されたままです。しかし、この特許が示す統合アプローチでは、これらを意味的に統合して一つの現実として再構成することで、AI が顧客の全体像を理解できるようになります。
技術的なアプローチ
この特許では、複数のソース環境からデータを統合し、一貫性のある分析を可能にするシステムを定義しています。単純なコピーではなく意味的な統合を行い、複数のソース環境に対応できる拡張性を持っています。
これにより、AI が業務データを理解する際に、分断されたデータを一つの現実として扱えるようになります。前述の家庭教師 AI で感じた「分断」の問題も、この統合アプローチによって解決できます。
2. 業務の正体は「状態」と「変化」である
NOTIFICATIONS OF EVENTS OF A SYSTEM OF RECORD
この特許では、業務を状態遷移の連続＝イベントとして定義しています。ワークフローや対応は、人間の頭の中にある暗黙知ではなく時間軸を持つ変化として外に出されます。
なぜイベントベースの設計が重要なのか
従来のシステムは、現在の状態を記録します。しかし、業務の本質は変化です。
- チケットが「オープン」から「解決済み」に変わる
- 顧客の契約が「トライアル」から「有料」に変わる
- プロダクトが「開発中」から「リリース済み」に変わる
これらの変化をイベントとして記録することで、AI は業務の流れを理解できます。
例えば、チケットの状態が同じ「オープン」でも、過去に一度クローズして再オープンしたものは、初めてオープンしたものとは異なります。人間は過去のイベント履歴を見て、再オープンしたチケットには優先順位を上げて対応する判断をします。
そうしたイベントを LLM が見ることで、ただ MCP（Model Context Protocol）で情報を引っ張ってきただけのその瞬間だけを切り取る AI から、過去のやりとりを考えられる AI に変化するのです。これこそが長期メモリとして求められているものの一つの例です。
技術的なアプローチ
この特許では、システムオブレコード（System of Record：業務の真実の記録を保持するシステム）のイベントを通知する仕組みを定義しています。業務の変化を構造化されたイベントとして記録し、イベントの時系列を保持することで、業務の履歴を追跡可能にします。
これにより、AI は現在の状態だけでなく、どのように変化してきたかを理解できるようになります。前述の分断問題も、このイベントベースの設計によって解決できます。
3. 業務は「検索」ではなく「意味」で扱う
SYSTEM AND METHOD TO IMPLEMENT A SCALABLE VECTOR DATABASE
DevRev のベクトル DB は、ドキュメント検索のための部品ではありません。イベント履歴、状態の遷移、関係性の変化を意味空間に写像し、業務的に関係しているものを引き出すための基盤です。
なぜベクトル DB が重要なのか
RAG とベクトル DB は、技術的には同じものを使うことが多いです。違いは何を意味空間に写像するかです。
一般的な RAG の使い方では、文書をチャンク化したものを意味空間に写像します。ベクトル DB で類似性を検索し、「似ている文書のチャンク」を返すだけになります。しかし、業務では似ているだけでは不十分です。
DevRev のベクトル DB は、イベント履歴、状態の遷移、関係性の変化を意味空間に写像することで、業務的に関係しているものを確実に引き出せます。
例えば、顧客が「前回の問い合わせと同じ問題が再発した」と言ったとき、一般的な RAG の使い方では「似ている文書」を返すだけです。しかし、DevRev のベクトル DB の使い方では、意味空間で「同じ顧客、同じ問題、同じチケット ID」という業務的に関係しているものを特定できます。これにより、AI は単に「似ている」情報ではなく、「業務的に関係している」情報を正確に理解できるようになります。なお、業務の集合的把握（クラスタリング）については、申請中の関連特許として扱われています（詳細は「特許の積み上げ方」セクションを参照）。
技術的なアプローチ
この特許では、スケーラブルなベクトルデータベースの実装方法を定義しています。イベント履歴、状態の遷移、関係性の変化を意味空間に写像し、業務的な関係性をベクトル空間で表現することで、大量のデータに対応しながら業務的に関係しているものを確実に引き出せます。
これにより、AI は一般的な RAG の使い方ではなく、イベント履歴や状態遷移を意味空間に写像することで、業務的に関係しているものを確実に引き出すことができます。前述の「似ているから OK ではない」という問題も、この意味ベースのアプローチによって解決できます。
なお、特許では具体的な実装方法までは記載されていません。詳細な実装は非公開の知的財産として保護されています。
4. AI を「UI」の位置に置かない
COMMUNICATION PLATFORM FOR A CONNECTED ENVIRONMENT
ここでの AI は、質問に答えるだけの存在ではありません。業務文脈を前提に対話し、業務の一部として振る舞うことが設計されています。
なぜ AI を UI に置かないのか
多くの AI アプリケーションは、AI をユーザーインターフェースとして扱います。つまり：
- ユーザーが質問する
- AI が答える
- 終わり
しかし、これでは AI は業務の外部にあります。業務の一部として機能するためには、AI が業務の内部に存在する必要があります。
例えば、AI が単に質問に答えるのではなく、チケットの状態を変更したり、関連するドキュメントを自動的に関連付けたり、次のアクションを提案したりする。顧客からの問い合わせに対して、AI が過去の履歴を参照して回答するだけでなく、適切な担当者に割り当て、関連する情報を自動的に紐付け、次のステップを提案する。つまり、AI は「答える存在」ではなく「業務を進める存在」になります。これが業務参加者としての AI の姿です。
技術的なアプローチ
この特許では、接続環境のためのコミュニケーションプラットフォームを定義しています。AI が業務の文脈を理解し、それを前提に対話し、複数のシステムやデータソースと接続した統合環境で業務の一部として振る舞います。
これにより、AI は便利な外部ツールではなく、業務の参加者として機能します。AI は業務の文脈を理解し、業務の変化を追跡し、業務の一部として判断を下します。前述の分断問題も、このアプローチによって解決できます。
4 つを貫く一つの思想
- データではなく、状態を見る
- 検索ではなく、理解させる
- 自動化ではなく、業務参加させる
AI を便利な外部ツールにしないために、
業務そのものを AI が理解できる形に作り直す。
DevRev との出会い
そんな中、元々所属していた Nutanix の創業者が立ち上げた DevRev のことを知る機会がありました。
DevRev は 2020 年に創業し、2022 年に製品販売を開始しました。Transformer が登場し、ChatGPT が世の中を変えようとしていた時期です。最初は DevCRM として紹介されていましたが、業務プロセスを根本から AI Native で再定義するという特許をベースにしていたため、向かう方向性は明確でした。
AI 関連の企業を調べる中で、カジュアルミーティングで必ず聞いていたのは IP/Patent に関することでした。前述の通り、絶対にブレないラインを IP/Patent から判断するということを、いつもやっていました。
DevRev は、AI Native な企業として、どうやって AI を使うのかを社内で実践し、それを世の中に AI エージェントプラットフォーム として提供していくことが重要だと考えています。AI エージェントプラットフォームとは、AI が業務の参加者として機能するための基盤であり、前述の 4 つの中核特許が示す設計思想を実装したものです。この考え方に強く共感し、実際に創業者と会話する機会もあり、無事に入社することになりました。
DevRev の特許を読んで、特に良いと感じたのは、この 4 つの特許が「点」ではなく「骨格」になっていることでした。
- 分断された業務データを一つの現実として統合する
- 業務を状態遷移（イベント）として定義する
- 業務文脈を意味空間として保持する
- AI を UI ではなく業務参加者として位置づける
これらは機能ではなく、設計前提そのものです。
特許の積み上げ方：骨格から拡張へ
さらに重要なのは、DevRev がこの骨格の上に、エンティティ理解、業務の集合的把握（クラスタリング）、プロダクトや業務のライフサイクル管理といった関連特許を申請中という形で積み上げている点でした。
なぜこの積み上げ方が重要なのか
多くの企業は、機能を後付けで追加します。しかし、DevRev は設計前提を先に固定し、その上に機能を積み上げるというアプローチを取っています。
この違いは重要です。後付けのアプローチは、既存の業務に AI を追加し、機能ごとに特許を申請するため、結果として機能がバラバラになり、統合が難しい。一方、骨格ベースのアプローチは、業務の設計前提を先に固定（4 つの中核特許）し、その上に機能を積み上げ（関連特許）るため、結果として一貫性のあるシステムが構築される。
特許が示す設計思想の一貫性
4 つの中核特許は、それぞれ独立した機能ではなく、一つの設計思想の異なる側面を表しています。
- データ統合特許：業務データの分断を前提に、統合方法を定義
- イベント通知特許：業務を状態遷移として定義
- ベクトル DB 特許：業務を意味空間で扱う方法を定義
- コミュニケーションプラットフォーム特許：AI を業務参加者として位置づける
これらが組み合わさることで、AI が最初から業務に存在する世界が構築されます。「AI をどう使うか」を後付けで考えるのではなく、先に特許という形で固定している。この順序が、とても健全だと感じました。
AI は、賢く見えることよりも、壊れない前提で設計されていることの方が重要です。自分が DevRev を選んだ理由は、この 4 つの取得済み特許が示す骨格と、その骨格を拡張する申請中特許の積み上げ方に、「この会社は、AI を一過性の技術として扱っていない」という強い意思を感じたからでした。
実例：Bill.com が示す 4 つの中核特許の効果
Bill.com は、米国 GDP の 1% （2024 年の米国 GDP は 4350 兆円 1 ドル 150 円換算、1%だと 43.5 兆円規模）に相当する取引を処理する決済プラットフォームで、50 万社以上の顧客を抱えています。年間百数十万件のサポートチケットを処理していましたが、自社 AI のチケット自動応答率は 10-13% にとどまり、サポートコストは年間で数十億円に達していました。
Bill.com が直面していた課題
- AI による自己解決率が低い：既存の RAG ベースのアプローチでは、時間経過とともに劣化し、業務効率が悪化
- クローズまでの平均が数時間：顧客体験リスクが増大
- サポートコストの上昇：チケット数が倍増見込みで人間では対応できない規模
DevRev を選定した理由
Bill.com の AI チームは多くのベンダーを評価しましたが、どれも似たようなチャットボットでした。しかし、DevRev だけがコンテキストレイヤとアーキテクチャを提供していました。
重要なのは、お客様を正しく継続的に認識し、次のチケット作成のときに前回のチケットを正確に把握できる点でした。これは、前述の 4 つの中核特許が実現する機能そのものです。Salesforce、Zendesk、請求システムとシームレスに連携し、チケットの状態遷移を追跡し、お客様を正しく継続的に認識し、チケット受信時にインテント検知して自動ワークフローを実行します。
さらに、DevRev だけがテスト環境の構築を即日で完了できました。他のベンダーは 1 ヶ月かかると説明されていました。
実現した効果
Bill.com では、使っているツールを変えることも、オペレーションを変えることもありませんでした。AI がお客様対応を裏側でやってくれるようになっただけです。毎月 3 兆円以上の取引を処理するシステムにおいて、既存ツールを置き換えることなく、契約から 7 週間で本番環境で稼働しました。
- チケット削減率 73%：POC では 40-50% の改善でしたが、本番では 73% に到達
- 100 万件以上のチケットが AI によって自動対応：人が関与せず AI のチャットのみで対応完了
- 年間サポートコスト 20 億円以上の削減
- チケットクローズまでの時間を数時間から数分に短縮
- 顧客満足度向上、エスカレーション減少、解約リスク低減
Bill.com の事例は、4 つの中核特許が示す設計思想が、単なる理論ではなく、実際の業務で劇的な効果を生み出すことを証明しています。既存システムをリプレースするような問題解決ツールではなく、既存システムとシームレスに統合する新たな価値を創造する AI 基盤となったのです。
2025年1月：BCGが指摘する日本のAI投資の課題
2025年1月、BCGが発表した調査結果は、日本のAI投資の現状を浮き彫りにしました。日本企業の約半数が2,500万ドル超のAI投資を計画しており、その割合は世界最多です。しかし、投資額だけでは成功は保証されません。「AI先進企業」は他社と比較して2.1倍のROI（投資利益率）を達成している一方で、多くの企業が「インパクト・ギャップ」に直面しています。
日本のAI投資が直面する「分散型POC」の罠
BCGの調査によると、成功している企業とそうでない企業の違いは明確です。成功企業は平均3.5個のユースケースに集中投資する一方、平均的な企業は平均6.1個のユースケースに分散投資しています。「まずは手広く試す」アプローチはリソースを分散させ、失敗の要因となるのです。
さらに重要なのは、成功企業は**「生産性向上」ではなく「ビジネスモデルの再構築」に投資する**点です。単なる効率化にとどまらず、ビジネスモデルそのものを変革する領域に資金を集中させることが、高収益への第一歩です。
2025年1月の時点で、日本はAIへの投資では世界をリードする一方、細かい生産性向上や分散したPOCを大量に行うという世界のAI投資失敗をリードしてしまっているのが現実です。
DevRevの思想との一致
BCGが指摘する成功企業のアプローチは、DevRevが目指すものと完全に一致しています。
- コア業務の再構築：DevRevの4つの中核特許は、まさに「業務をどう定義し直すか」を問うています。単なる効率化ではなく、業務そのものをAIが理解できる形に再定義する。
- 選択と集中：Bill.comの事例が示すように、DevRevは少数の高インパクトなユースケースに集中し、確実に実装・定着させるアプローチを取っています。
- 業務参加型AI：お試しのPOCをたくさんやるのではなく、会社全体の業務プロセスを見たときに、どうやってコアな既存プロセスにAIを業務参加させるのかを考える。これがDevRevの思想そのものです。
BCGの調査では、60%の企業がAIの価値創出に関する財務KPIを定義できていません。一方、成功企業は導入前に明確な財務目標を設定し、「導入数」や「PoC完了数」ではなく、実際の「売上高」や「利益」への影響を厳密に追跡しています。Bill.comの事例でも、明確なROI（チケット削減率73%、年間サポートコスト20億円以上の削減）が示されています。
世界最大のAI投資国、かつ世界最大の失敗国にならないために
世界最大のAI投資国、かつ世界最大の失敗国に日本がなってしまうことは避けたい。そのためには、DevRevが示すアプローチが重要です。
- お試しのPOCをたくさんやるのではなく、コア業務の再構築に集中する
- 細かい生産性向上に分散投資するのではなく、ビジネスモデルそのものの変革に投資する
- 既存の業務にAIを後付けするのではなく、業務そのものをAIが理解できる形に再定義する
日本はAIでやらなければいけないことはたくさんあります。しかし、投資額を増やすだけでは不十分です。DevRevの4つの中核特許が示すように、業務をどう定義し直すかを先に考えることが、ROI最大化の鍵なのです。
まとめ：これは AI の話ではなく、業務の話
DevRev は、「AI をどう使うか」を売っている会社ではありません。「業務とは何か」を再定義し、AI が最初から業務に存在する世界を先に固定している会社です。
Bill.com の事例が示すように、従来のチャットボットでは実現困難だった一連の業務フロー（お客様を正しく認識し、複数システムの情報を統合し、適切なアクションを実行する）を、DevRev の中核特許を構成する技術によって実現できました。
重要なのは、特許そのものではなく、業務を AI が理解できる形に再定義するという設計思想を実現する技術を正しく使うことです。
だから自分は、DevRev を選びました。
参考文献
-
DevRev Inc., METHOD AND SYSTEM FOR INTEGRATED ANALYSIS OF DATA FROM MULTIPLE SOURCE ENVIRONMENTS
複数のソース環境からのデータの統合分析に関する特許。業務データの分断を前提に、分析可能な一つの現実として再構成する方法を定義。 -
DevRev Inc., NOTIFICATIONS OF EVENTS OF A SYSTEM OF RECORD
システムオブレコードのイベント通知に関する特許。業務を状態遷移の連続として定義し、時間軸を持つ変化として記録する仕組み。 -
DevRev Inc., SYSTEM AND METHOD TO IMPLEMENT A SCALABLE VECTOR DATABASE
スケーラブルなベクトルデータベースの実装に関する特許。イベント履歴や状態遷移を意味空間に写像し、業務的に関係しているデータを引き出す基盤。 -
DevRev Inc., COMMUNICATION PLATFORM FOR A CONNECTED ENVIRONMENT
接続環境のためのコミュニケーションプラットフォームに関する特許。AI を UI ではなく業務参加者として位置づけ、業務文脈を前提に対話する仕組み。 -
How Bill.com uses Computer
Bill.com が DevRev の AI エージェントプラットフォームをどのように活用しているかの詳細な事例。 -
Boston Consulting Group, From Potential to Profit: Closing the AI Impact Gap (2025年1月)
https://www.bcg.com/ja-jp/press/22january2025-ai-optimism-autonomous-agents
世界19市場・12業界の経営層1,803人を対象としたBCG調査。日本企業の約半数が2,500万ドル超のAI投資を計画する一方、「AI先進企業」は他社と比較して2.1倍のROIを達成している。成功企業は「生産性向上」ではなく「ビジネスモデルの再構築」に投資し、ユースケースを厳選して集中投資するアプローチを取っている。
更新履歴
- 2026-01-21 — BCGの2025年1月調査結果を追加、日本のAI投資の課題について追記
- 2025-12-21 — 初版作成
注記
本記事は AI を活用して執筆しています。
Discussion