DevRev: AI ナレッジ管理に必要なのはガベージコレクタかもしれない
はじめに
DevRev を紹介していると、お客様から決まってこう聞かれます。
「結局、DevRev の強みは何なのか」
本記事では、DevRev の強みを「ガベージコレクタ （GC）」に例えてみます。
AI 活用ではモデルの性能やプロンプトに注目が集まりがちですが、実際の業務ではもう少し手前に大きな問題があります。それは、AI に何を食わせるのかという問題です。社内ドキュメント、問い合わせ履歴、チケット、仕様書、FAQ、議事録などをつなげれば、AI が参照できる情報は増えます。しかし参照できる情報が増えても、回答品質がそのまま上がるとは限りません。古い仕様書が残っていたり、過去の暫定対応が正式な手順のように見えたり、社内向けの情報が顧客向けの回答に混ざったり、似た記事が複数あってどれが正しいのか分からなくなる、といったことが起こるためです。
これは Garbage In, Garbage Out、すなわち「入力の品質が低ければ出力の品質も低くなる」という問題です。AI が賢くなっても、参照する情報が古ければ、古い情報をもとにそれらしい回答を返してしまいます。
散らかったナレッジをどう整理するかという問題を眺めたとき、私は GC を連想しました。プログラムが使わなくなったメモリを自動で回収し、メモリ空間を健全に保つ、あの仕組みです。本記事では、DevRev を「AI ナレッジの GC 的な実行基盤」として捉えたときの強みを考察していきます。
DevRev とは
DevRev は、サポート、開発、顧客情報をつなぎ、AI agents と人間が同じ業務情報を扱えるようにする SaaS です。Knowledge Base や Article により、AI が参照するナレッジを所有者、状態、公開範囲、関連情報を持つ管理対象として扱えます。
対象読者
- DevRev の強みをエンジニア向けに説明したい方
- AI に食わせるナレッジの管理に課題を感じている方
- RAG や AI agents を業務で使う際の情報管理に関心がある方
- GC やメモリ管理の比喩で SaaS の価値を理解したい方
参考
- DevRev
- Knowledge Base Management for Self-Service
- Computer by DevRev overview
- Explore DevRev's new article creation and article analytics dashboard
- Java Garbage Collection Basics
- C++ reference: Dynamic memory management
メモリ管理の責務はどこにあるのか
C や C++ に長く触れてきたエンジニアであれば、メモリ管理の難しさを知っていると思います。
メモリを確保したら、不要になった時点で解放する必要があります。解放を忘れればメモリリークにつながります。逆に、まだ使われているメモリを解放すれば、不正なメモリアクセスにつながります。つまり、データには寿命があります。 寿命を正しく扱えなければ、プログラムは不安定になります。
一方、Java や C# などの実行環境では、GC が不要になったオブジェクトの回収を担います。 GC は、プログラムから到達できなくなったオブジェクトを検出し、そのメモリを回収します。
もちろん、GC があるからといって、メモリを完全に意識しなくてよいわけではありません。大きなオブジェクトを長く保持すれば、メモリ使用量は増えます。参照を持ち続ければ、本来不要なオブジェクトも回収されません。GC は魔法ではありません。
それでも、GC の存在によって、メモリ管理の責務の一部はアプリケーションコードから実行環境へ移りました。開発者がすべてを手作業で扱うのではなく、実行環境が寿命管理の一部を担うようになりました。
そして現在 AI に食わせるナレッジにおいても、似たことが起きているように見えます。
AI に食わせるナレッジにも寿命がある
業務で使うナレッジにも寿命があります。
作成された時点では正しかった記事も、製品仕様が変われば古くなります。公開当時は有効だった FAQ も、料金プランやサポート方針が変われば、現在の回答根拠としては使いにくくなります。過去の問い合わせ対応は貴重な情報ですが、そのまま現在の標準回答として扱えるとは限りません。
ここで問題になるのは、古い情報が存在すること自体ではありません。
過去の情報には、監査や調査のための価値があります。過去の経緯を確認するために必要な場合もあります。問題は、現在の回答に使うべきではない情報が、AI の回答根拠として残り続けることです。
メモリ管理では、不要になったオブジェクトが残り続けると、利用可能なメモリが減っていきます。同様に AI ナレッジ管理においては、現在の回答に使うべきではない情報が残り続けると、AI が参照する情報源にノイズが混ざります。結果として、回答品質や信頼性が下がりやすくなります。
さらに、AI ナレッジの扱いは、メモリ管理よりも少し複雑です。
GC が主に見るのは到達可能性です。つまり、あるオブジェクトにプログラムから到達できるかどうかです。しかしながら、AI ナレッジでは、到達できるかどうかだけでは足りません。その情報が現在も正しいのか・顧客に見せてよいのか・誰が責任を持っているのか・ほかの情報と矛盾していないのかといった観点が重要です。
AI 活用では、このナレッジの寿命管理が重要になります。
DevRev を AI ナレッジの実行基盤として見る
ここで DevRev の話に戻ります。
DevRev は、AI に食わせるナレッジを単なるテキストの集合として扱うのではなく、業務上の文脈を持つ情報として扱うための SaaS です。Knowledge Base や Article といった形でナレッジを管理し、AI による回答や検索のための情報源として利用できます。
DevRev コンソール Knowledge Base 管理画面
重要なのは、ナレッジをただ保存するだけではない点です。たとえば Article には、所有者、状態、公開範囲、関連する製品情報などの管理情報を持たせられます。これにより、AI が参照する情報を、単なるドキュメントではなく、寿命を持つ管理対象として扱いやすくなります。
AI に何を見せるのか・どの情報を現在の回答根拠として扱うのか・どの情報は社内向けであり、顧客向けには見せないのか・誰がそのナレッジの更新責任を持つのか……これらは、AI 導入時に避けて通れない問題です。
外部サービスとの連携だけであれば、さまざまな方法があります。ワークフロー自動化ツールや API 連携を使えば、多くの情報を AI に渡せますが、接続できることと、AI が安心して使える状態にすることは別の問題でしょう。 DevRev の価値は、この接続後の問題にあります。
AI が参照する情報を、所有者、状態、公開範囲、関連情報を持つ管理対象として扱う。これにより、ナレッジを人間の記憶や個別運用だけに依存させず、プロダクト上で扱えるようになります。その意味で、DevRev は AI ナレッジの GC そのものというより、ガベージコレクション的な寿命管理を可能にする実行基盤に近いと考えています。
DevRev は魔法の GC ではない
ただし、この比喩には注意も必要です。
DevRev を導入すれば、AI がすべてのナレッジの正しさを自動で判定してくれる、という話ではありません。古い記事を自動で見つけ、常に正しい情報だけを残してくれるわけでもありません。
これは、GC がある言語でも設計が重要であることに似ています。GC は不要になったオブジェクトの回収を助けます。しかし、どのようなデータ構造にするか・どの範囲で参照を持つか・どの程度のメモリ使用量を許容するかといった点は、依然として開発者が考える必要があります。
AI ナレッジ管理でも同じです。どの情報を正式なナレッジとして扱うのか・誰が内容を確認するのか・どの範囲のユーザーに公開するのか・古くなった情報をどのように退役させるのか……これらの判断には、人間の責任が残ります。
DevRev の役割は、人間の責任をなくすことではありません。責任を持つべき情報を見える場所に置き、状態や所有者や公開範囲を管理できる形にすることです。属人的な運用に頼っていたナレッジ管理を、AI が参照できる形で扱えるようにすることです。
そのため、DevRev を AI が勝手に正しい情報だけを選ぶ製品として説明するのは適切ではありません。むしろ、AI に食わせる情報の寿命管理を行うための基盤として説明する方が、製品の強みを伝えやすいと感じています。
まとめ
AI 活用では、モデルやプロンプトだけでなく、AI に食わせるナレッジの状態も回答品質に影響します。DevRev は、ナレッジを所有者、状態、公開範囲、関連情報を持つ管理対象として扱えるため、AI が参照する情報の寿命管理に向いています。 これは、GC がメモリ管理の責務の一部を実行環境へ移したことに似ています。ただし、DevRev は魔法の GC ではなく、人間が判断すべき内容を扱いやすい場所に置くための基盤と捉えるのが適切でしょう。本記事が、AI に食わせる情報の管理に悩んでいる方の参考になれば幸いです。
