-
お電話でのお問い合わせ045-555-9505
- メールでのお問い合わせ
お電話でのお問い合わせ045-555-9505
生成AIを使ったサービスを開発していると、「RAG（ラグ）」という言葉をよく聞くようになりました。
そして、
「RAGを使ったシステムは特許になるの？」
「社内資料を検索してChatGPTに回答させるだけでも特許になる？」
「RAGのどの部分を発明として考えればいい？」
という疑問を持つ方もいると思います。
結論からいうと、RAGを利用したシステムでも特許になる可能性はあります。
ただし、
「RAGを使った」というだけでは、特許としては弱い
と考えた方がよいでしょう。
現在、RAGの基本的な仕組み自体は広く知られています。
そのため特許を考える際には、
検索方法、取得した情報の取捨選択、プロンプト生成、LLMとの連携、出力結果の評価など、RAGを含む一連の処理全体にどのような工夫があるか
を見ることが重要です。
RAGは「Retrieval-Augmented Generation」の略で、日本語では「検索拡張生成」などと呼ばれます。
非常に簡単にいうと、
LLMに質問する前に、外部のデータベースなどから必要な情報を検索し、その情報も一緒にLLMへ渡して回答させる仕組み
です。
例えば、会社独自の就業規則についてChatGPTに質問しても、ChatGPTがその会社の最新の就業規則を知っているとは限りません。
そこで、
「育児休業について教えて」
という質問が来たら、
社内文書を検索し、育児休業について書かれた部分を取り出して、その情報を質問文と一緒にLLMへ入力します。
そうすると、LLMは検索された社内資料を参考に回答を生成できます。
AWSもRAGについて、外部データから関連情報を検索し、その情報を質問とともにLLMへ与えて回答を生成する仕組みとして説明しています。AWS ドキュメント
Microsoftも、RAGを「検索とLLMを組み合わせ、取得した情報をモデル入力に含めて回答を生成する仕組み」と説明しています。Microsoft Learn
典型的なRAGは、
ユーザーが質問
↓
データベースを検索
↓
関連情報を取得
↓
質問＋関連情報をプロンプトに入れる
↓
LLMが回答
という構成です。
この基本的な流れ自体は、すでにAWSやMicrosoftなどが一般的な技術として公開しています。AWS ドキュメント
そのため、
「ベクトルDBを検索して、その結果をChatGPTに入れます」
というだけでは、新規性・進歩性のある発明として差別化することは難しくなってきていると思います。
ここは、以前の記事で説明した生成AI特許と同じです。
既存のAIや既存のRAGを使うこと自体ではなく、それを「どう使うか」に発明のポイントがある
ということです。
では、どこに発明のポイントがあるのでしょうか。
私は、RAGそのものよりも、RAGを含むシステム全体の処理を見るのが重要だと考えています。
例えば、次のような部分です。
こうした処理の中に独自のアイデアがあれば、特許として検討できる可能性があります。
RAGでは、検索結果を全部LLMへ渡せばいいとは限りません。
例えば100件の文書がヒットしても、その中には、
古い情報、信頼性の低い情報、質問とは少しずれた情報
などが含まれている場合があります。
そこで、
検索結果をどう評価し、どの情報を採用するか
という処理に工夫を入れることができます。
例えば、
質問の種類を判定し、
↓
検索対象となるデータベースを切り替え、
↓
取得した文書に信頼度を付け、
↓
一定以上の信頼度のものだけLLMへ渡す
といった処理です。
単にRAGを使うのではなく、情報の選別方法そのものに特徴があるというわけです。
企業のシステムであれば、検索対象は一つとは限りません。
例えば、
など、複数の情報源があります。
質問内容によって、
「この質問なら社内規程だけを検索する」
「この質問なら顧客DBと商品マニュアルを両方見る」
「最新情報が必要ならWeb情報も検索する」
というように、検索先を制御する仕組みにも工夫が考えられます。
Microsoftの現在のRAG解説でも、ベクター検索だけでなく、キーワード検索、セマンティック検索、ハイブリッド検索など複数の取得手法が利用されることが示されています。Microsoft Learn
つまり、何を、どこから、どう検索するかもシステム設計の重要な部分です。
検索で情報を取ってきた後は、その情報をLLMへ渡します。
ここでも、
「検索結果をそのまま全部プロンプトへ貼り付ける」
だけとは限りません。
例えば、
取得した文書を要約し、
重要部分だけ抽出し、
質問の種類に応じて順序を変更し、
特定のテンプレートに組み込んでプロンプトを生成する
といった処理が考えられます。
このあたりは、前回の記事
「生成AIを使った発明はどこを特許にする？」
で説明したプロンプト周辺の発明とも非常に近いです。
RAGとプロンプト生成を別々に見るというより、一連の処理として考える方がよいでしょう。
LLMが回答を生成した後にも、発明のポイントがあり得ます。
例えば、
回答内容を別のAIでチェックする、
引用元と回答が一致しているか確認する、
信頼度を算出する、
一定基準を満たさなければ再検索する、
別の検索条件で情報を取り直す
といった処理です。
典型的なRAGでは、
検索 → LLM → 回答
で終わります。
しかし、
検索 → 選別 → プロンプト生成 → LLM → 評価 → 再検索 → 再生成
というような独自の処理ループがあれば、システム全体として特徴を出しやすくなります。
今回一番お伝えしたいのはここです。
RAGという技術自体は、すでに一般的になっています。
したがって、
「RAGを使っています」
だけではなく、
「RAGを含むシステム全体として、従来と何が違うのか」
を見る必要があります。
例えば、
入力
↓
質問内容の分類
↓
検索先の決定
↓
情報検索
↓
検索結果の再順位付け
↓
情報の取捨選択
↓
プロンプト生成
↓
LLM処理
↓
回答評価
↓
必要なら再検索
という一連の流れです。
この中の一部分だけに特徴がある場合もありますし、複数の処理を組み合わせた全体構成に特徴がある場合もあります。
特許庁もAI関連発明について、進歩性、記載要件、発明該当性などの判断事例を公開しており、AIだから特別なルールで審査されるというより、発明の具体的な処理や構成が特許要件を満たすかが判断されます。特許庁
もちろん、処理を複雑に組み合わせれば特許になるわけではありません。
重要なのは、
その工夫によって何の問題を解決しているのか
です。
例えば、
「検索結果に不要な情報が多く、回答精度が低い」
という課題があるとします。
そこで、
質問の内容を分類し、
検索先を変更し、
検索結果を信頼度によって再順位付けする
ことで、
「LLMへ渡す情報の精度を高め、回答精度を改善する」
という関係があるのであれば、
課題 → 処理 → 効果
が説明しやすくなります。
特許出願では、この関係を明確にすることが重要です。
RAGは一般的な技術になっているので、
「RAGだからもう特許は無理だろう」
と思う必要もありません。
RAGはあくまでシステムを構成する一つの技術です。
その周辺に、
があれば、特許化を検討する余地があります。
特に実際のサービスでは、標準的なRAGをそのまま使うだけでは十分な性能が出ず、さまざまな工夫を追加しているケースも多いでしょう。
その**「実務上工夫したところ」**に、発明が隠れていることがあります。
RAGを使ったサービスの場合も、できれば公開前に特許性を確認することをおすすめします。
例えば、
「この検索方法に特徴がある」
「回答精度を上げる独自処理を作った」
「複数DBを使い分ける仕組みを考えた」
といった段階です。
システムが100％完成している必要はありません。
処理フローがある程度整理できていれば、
どこに発明のポイントがあるか
を検討できます。
RAGを使ったシステムは、特許になる可能性があります。
ただし、
「RAGを使った」だけでは十分とは限りません。
重要なのは、
という、RAGの前後を含めた一連のシステム構成です。
私自身も、RAGについては「RAGそのもの」より、
RAGを含んだ全体の処理の組み合わせにどんな工夫があるのか
を見ることが、特許を検討するうえで重要だと考えています。
既存の技術を使っていたとしても、その組み合わせ方や処理方法によって新しい課題を解決できるのであれば、特許になる可能性があります。
遠山総合特許事務所では、
「RAGを使ったサービスを開発している」
「検索方法に独自の仕組みがある」
「生成AIの回答精度を高める処理を考えた」
「既存技術の組み合わせだが特許になるか知りたい」
「生成AIシステムのどこを特許にすればいいか分からない」
といった段階からご相談いただけます。
処理フローを一緒に整理しながら、どこに特許化できるポイントがあるかを検討します。
AIを使ったサービスは特許になる？生成AI・LLM・AIアプリの特許化を弁理士が解説
https://toyamapat.com/archives/1679
生成AIを使った発明はどこを特許にする？プロンプト・処理・システム構成を弁理士が解説
https://toyamapat.com/archives/1727
AIで作ったアプリでも特許は取れる？AI・ノーコード開発でも特許になる条件を弁理士が解説
https://toyamapat.com/archives/1686
執筆・監修：弁理士 遠山敬一
この記事へのトラックバックはありません。
この記事へのコメントはありません。