執筆・文責：弁理士　中村幸雄

RAG（検索拡張生成）とは、外部文書を参照しながら回答を生成する仕組みです。社内文書や契約書、規程、FAQなどを検索し、その情報を根拠として使うサービスが広がっています。

RAGが注目されるのは、生成AIに「社内の知識」や「最新の文書」を参照させやすくなるためです。たとえば、社内規程に基づいて回答する、契約書の条項を参照してリスクを説明する、FAQから根拠を示して回答する、といった使い方が考えられます。

もっとも、RAGを使えば自動的に精度の高いサービスになるわけではありません。どの文書を検索対象にするのか、文書をどの単位で分割するのか、古い文書や権限外の文書をどう扱うのか、回答の根拠をどのように示すのか。実際のサービスでは、こうした細かな設計が品質を左右します。

では、このようなRAGを使ったAIサービスは特許になるのでしょうか。

結論からいえば、RAGを使っているだけで、直ちに特許になるわけではありません。

しかし、どの文書を、どの粒度で分割し、どの範囲を検索し、どの根拠を提示し、古い情報や誤回答をどのように抑えるか——こうした具体的な仕組みが設計されている場合には、そこに発明の余地が生まれることがあります。

特に、社内文書検索AI、契約書検索AI、FAQ自動回答、規程検索AIなどを開発している事業者にとって、RAGのどこを発明として整理できるかは重要な論点になります。

この記事では、RAGそのものの技術解説ではなく、RAGを使ったAIサービスのどこに発明の本質が表れやすいかを整理します。

RAGそのものではなく、「どう使っているか」を見る

「RAGを使っています」「社内文書を検索できます」「回答に根拠を表示できます」——これだけでは、特許性を主張する根拠としては弱いかもしれません。

重要なのは、RAGを使うこと自体ではありません。むしろ問われるのは、次のような設計です。

RAGの発明性は、「AIが回答すること」ではなく、回答に至るまでの検索・文書管理・根拠提示の処理設計に表れます。

文書分割の粒度は、発明の入口になり得る

RAGでは、検索対象となる文書を一定の単位に分割することがあります。いわゆるチャンク化と呼ばれる処理です。

単に文字数で等分するだけでは特許性はありませんが、文書の性質に応じて分割単位を変えているのであれば、特許の種が眠っているかもしれません。

ここで問われるのは、その分割方法によって、検索精度・回答精度・根拠提示・誤回答抑制がどのように改善されるのかを説明できるかどうかです。文書の性質に合わせた分割設計は、業務に適した情報処理として整理しやすくなります。

検索対象をどう制御するか

RAGでは、「検索できること」よりも、何を検索対象にし、何を対象から外すかが重要になることがあります。

たとえば社内文書検索AIでは、法務部・営業部・人事部それぞれで参照すべき文書が異なります。すべての文書を一律に検索するのではなく、質問内容・ユーザー属性・部署・文書種別などに応じて検索対象を変える仕組みがあれば、そこに発明の余地が生まれることがあります。

具体的には次のような処理です。

このような仕組みは、単なるRAGの利用ではなく、業務に合わせた検索制御の工夫と言えるからです。

メタデータ設計が、RAGの価値を左右する

RAGでは、文書の本文だけでなく、文書に付与されるメタデータが重要になります。文書種別、承認状態、更新日、効力発生日、適用期間、閲覧権限、旧版・最新版の区別——こうした情報です。

これらを単に保存しているだけでは特許性は弱いですが、メタデータを使って、

といった処理を行っている場合には、RAGシステムの具体的な工夫として主張できる可能性があります。RAGにおける発明の本質は、こうした文書管理と検索制御の組み合わせに表れることがあります。

権限外の情報を、回答に混ぜない設計

社内文書には、誰でも閲覧できる情報だけではなく、特定の部署・役職・プロジェクトメンバーだけが閲覧できる情報もあります。

業務用RAGでは、この権限管理が重要になります。たとえば、営業担当者が質問したときに、人事部だけが閲覧できる評価資料や、経営層だけが見られる未公開情報に基づいて回答してしまうと問題です。

そのため、単に検索結果の一覧を制限するだけでは十分ではありません。検索対象を制御するだけでなく、回答文の生成、根拠文書の表示、ログへの保存まで含めて、権限外の情報が混ざらないように設計する必要があります。

たとえば、権限外の文書を検索対象から外す、権限外の情報に基づく回答生成を抑制する、根拠として表示できる文書だけを提示する、ログに残す情報を制限する、といった処理が考えられます。

このように、業務用RAGにおける権限管理は、単なるアクセス制御にとどまりません。検索、回答生成、根拠提示、ログ管理を一体として制御する仕組みとして設計されているかが、発明を検討するうえでも重要になります。

更新日・鮮度管理は、誤回答を防ぐための重要論点

RAGを使ったAIサービスでは、古い情報に基づく回答が問題になることがあります。旧版の就業規則、改定前の契約ひな形、廃止された社内ルール——生成AIは古い情報でも、それらしく自然な文章で回答してしまいます。そのため、情報の鮮度管理は業務用RAGにおいて不可避の設計課題です。

たとえば次のような処理が考えられます。

このような処理は、回答精度だけでなく、業務上のリスク低減にも直結します。文書の鮮度をどのように判定し、回答にどう反映するかは、発明の検討対象になり得ます。

回答根拠の提示は、単なるリンク表示では終わらない

RAGサービスでは「回答の根拠を表示できます」と説明されることがあります。しかし特許の観点では、参照元リンクを表示しているだけでは発明の特徴として弱い場合があります。

より重要なのは、回答と根拠をどのように対応づけているかです。

ここまで設計されていると、RAGは単なる「検索付きチャット」ではなくなります。回答の信頼性を高めるための情報処理システムとして、工夫の所在が整理しやすくなります。

「回答してよいか」を判断する設計

AIサービスでは、便利に回答できることが強調されがちです。しかし、業務で使うAIでは、いつでも答えることが正しいとは限りません。根拠が不十分なまま自然な文章で回答してしまうと、ユーザーがその回答を信頼し、誤った判断につながるおそれがあります。

RAGを使ったAIサービスでは、根拠文書が見つからない場合、根拠の信頼度が低い場合、複数の文書の内容が矛盾している場合があります。そのようなときに、通常どおり回答するのではなく、回答を保留する、根拠が不足していることを表示する、人による確認を促す、といった処理が重要になります。

たとえば、社内規程について質問された場合に、最新版の規程が見つからなければ回答を控える。契約書について質問された場合に、複数の条項が矛盾していれば確認を促す。FAQに基づく回答でも、根拠となる文書が古ければ、そのまま回答しない。このような制御は、業務上のリスクを抑えるための具体的な情報処理といえます。

したがって、RAGの発明を検討するときは、「どのように回答するか」だけでなく、「どのような条件では回答しないか」「どのような場合に確認へ切り替えるか」も見る必要があります。回答を抑える仕組みは、単なる安全対策ではなく、業務用RAGの品質を支える重要な設計ポイントになり得ます。

対象文書ごとに、発明のポイントは変わる

同じRAGでも、扱う文書によって問題になりやすい点は異なります。社内文書、契約書、FAQ、規程類では、文書の構造も、更新のされ方も、ユーザーが知りたい内容も違うからです。

そのため、RAGの発明を検討するときは、「RAGを使っているか」ではなく、「どの種類の文書について、どのような不都合を、どのような情報処理で解決しているか」を見る必要があります。

対象文書 問題になりやすい点 発明のポイントになり得る視点
社内文書 文書量が多く、部署・役職・プロジェクトごとに参照できる情報が異なる ユーザー属性に応じた検索対象の選択、権限外情報を回答に混ぜない制御
契約書 条項、契約類型、相手方、改定版の違いによって参照すべき内容が変わる 条項単位の検索、契約類型に応じた根拠選択、旧版との差分管理
FAQ 似た質問や言い換えが多く、公開範囲や回答対象の違いも問題になる 質問意図に応じたFAQ選択、関連FAQの提示、公開範囲に応じた回答制御
規程類 改定日、効力発生日、旧規程との関係によって、回答に使える文書が変わる 有効期間に基づく文書選択、旧版の除外、改定履歴を含めた根拠提示

このように、RAGの特許性は、AIモデルだけで決まるものではありません。対象文書に固有の問題を捉え、その問題を解決するために、検索対象の制御、文書分割、メタデータの利用、根拠提示、回答抑制などをどのように組み合わせているかが重要になります。

つまり、発明のポイントは「RAGを使うこと」ではなく、対象文書の性質に合わせて、検索から回答までの流れをどのように設計しているかに現れます。

よくある質問

Q RAGを使えば、それだけで特許になりますか？

RAGを使っているというだけでは難しいでしょう。重要なのは、RAGを使ってどのような課題を解決し、そのためにどのような具体的な情報処理を行っているかです。

Q 回答文の根拠を表示する、という工夫で特許を取得できますか？

根拠を表示するだけでは難しいでしょう。回答文と根拠箇所の対応づけ、根拠の信頼度判定、矛盾する根拠がある場合の処理、権限に応じた根拠表示の制御――このような具体的な仕組みを検討する必要があります。

Q 社内文書検索AIは、単なる業務効率化にすぎないのでは？

そのような場合もあります。しかし、文書分割・検索対象制御・権限管理・鮮度管理・根拠提示・回答抑制などの具体的な情報処理に踏み込めば可能性があります。

Q AIモデルを改良していなくても特許になりますか？

AIモデルそのものを改良している必要はありません。文書管理・検索制御・回答生成制御・根拠提示の仕組みなど、モデル周辺の処理設計に発明の種が見つかることも珍しくありません。

発明の種は、現場の制約の中にある

最新版と旧版が混在する社内文書、部署ごとに異なる契約ひな形、更新されないFAQ、権限の異なるユーザー、現場の言葉で入力される質問――そうした泥臭い実装環境の中にこそ、発明の種が埋まっていることがあります。

どの文書を検索対象にするか、何を回答に使わないか、どの根拠を提示するか、いつ回答を保留するか。その一つひとつの判断が、処理設計として積み重なったとき、RAGは単なる「検索付きチャット」ではなくなります。

仕様が固まりきる前に、その設計の悩みをそのまま持ち込んでください。発明の余白では、RAGを用いたAIサービスの発明の本質を、事業・開発フローも踏まえながら一緒に整理しています。

執筆・文責

弁理士　中村幸雄

AIサービス、ソフトウェア、業務フロー、試作・現場改善に関する発明整理・特許相談を扱う弁理士。 「発明の余白」では、まだ曖昧な技術構想や現場の工夫を、発明のポイントとして整理するための情報を発信しています。