「このワークスペースの中から、先月の議事録に出てきた課題をまとめて」——Notion AIにそう尋ねると、答えとあわせて出典となるページへのリンクが返ってきます。この一連の動きが、2026年7月21日に米国特許として登録されました。US 12,688,361、発明の名称は「Machine learning based question and answer (Q and A) assistant」です。
本記事では、この特許の請求項1を原文のまま引用し、構成要件に分解して読み解きます。生成AIを自社プロダクトに組み込んでいる企業にとって、「どこまで書けば特許になるのか」「どこを外せば権利範囲から出られるのか」を考える具体的な材料になるはずです。
💡 要点：本記事はNotion特許シリーズの個別解説編です。ポートフォリオ全体の分析はNotionの特許戦略（総論）をご覧ください。
目次
| 特許番号 | US 12,688,361 |
| 発明の名称 | Machine learning based question and answer (Q and A) assistant （機械学習に基づく質問応答アシスタント） |
| 出願人 | Notion Labs, Inc. |
| 出願番号／出願日 | 18/634,357 ／ 2024年4月12日 |
| 登録日 | 2026年7月21日 |
| 請求項数 | 20項 |
| 対応する国際出願 | WO 2025/216752（優先日2024年4月12日） |
出願から登録まで約2年3か月。Notionの登録特許の中でも直近のもので、同社のAI機能の中核に位置づけられる一件です。同じ優先日でPCT国際出願も行われており、この技術については海外展開も視野に入っていることがうかがえます。
この特許が対応するのは、ワークスペース全体を対象に自然言語で質問すると、関連する情報を探し出して、出典リンク付きの文章で答える機能です。要約（アブストラクト）は次のように述べています。
US 12,688,361 要約（原文引用）
A multimodal content management system having a block-based data structure can include a question and answer (Q&A) assistant engine. The Q&A assistant engine can capture a natural language prompt, which can be tokenized to generate a set of data source tokens and a set of parameter tokens. A parameter token in the set of parameter tokens can be indicative of a block property in the block-based data structure. A trained neural network can accept the data source tokens and/or parameter tokens as inputs to generate a query executable against the block-based data structure.
ポイントは、自然言語をそのままLLMに投げて答えさせるのではなく、いったん「クエリ」に変換してデータ構造に対して実行しているという設計です。ここが権利化の勘所になります。
特許の権利範囲は請求項の文言によって定まります。まずは原文をそのまま掲げます。
US 12,688,361 特許請求の範囲 請求項1（原文引用）
One or more non-transitory, computer-readable storage media comprising instructions recorded thereon, wherein the instructions, when executed by at least one data processor of a computing system, cause the computing system to: capture, via an input control of a graphical user interface (GUI) associated with a question and answer (Q&A) assistant engine for a multimodal content management system having a block-based data structure, a natural language prompt; tokenize the natural language prompt to generate a set of data source tokens and a set of parameter tokens, wherein a parameter token in the set of parameter tokens is indicative of a block property in the block-based data structure; using the set of data source tokens and the set of parameter tokens, execute a trained neural network to generate a query structured to operate on the block-based data structure; cause the generated query to be executed against the block-based data structure to generate a result set; and using the result set, generate and display, via the GUI, a visualization comprising a result set item, by: generating a navigable citation relating to a result set item in the result set; generating a narrative comprising the navigable citation; and while displaying the input control to accept a second natural language prompt, and responsive to detecting a user interaction with the navigable citation, causing the GUI to display content of a block in the block-based data structure, wherein the block corresponds to the result set item.
請求項を実務的に読むには、構成要件ごとに分解するのが基本です。この請求項は次の6つに分けられます。
| 要件 | 内容（日本語による分説） |
|---|---|
| A（前提） | ブロック型データ構造を持つマルチモーダルなコンテンツ管理システムであること |
| B（入力） | Q&AアシスタントのGUIの入力コントロールから、自然言語プロンプトを取得すること |
| C（分解） | プロンプトをトークン化し、データソーストークンとパラメータトークンを生成すること。 さらに、パラメータトークンがブロックのプロパティを示すものであること |
| D（生成） | 両トークンを用いて学習済みニューラルネットワークを実行し、ブロック型データ構造に対して動作するクエリを生成すること |
| E（実行） | そのクエリをデータ構造に対して実行し、結果セットを得ること |
| F（提示） | 結果セットから遷移可能な引用（navigable citation）を生成し、それを含むナラティブ（説明文）を作って表示すること。 加えて、次の質問を受け付ける入力欄を表示したまま、引用をクリックすると対応するブロックの内容が表示されること |
実務Tips（構成要件の読み方）：特許権の効力は、A〜Fのすべてを満たす実施にのみ及ぶのが原則です（オールエレメントルール）。逆に言えば、1つでも欠けていれば原則として侵害にはなりません。他社特許を検討するときは「似ているか」ではなく「全部そろっているか」で見るのが正しい読み方です。
分説してみると、この請求項が押さえようとしているのは「LLMで答えを作ること」ではないことがはっきりします。守られているのは、次の3点をつないだ一連の流れです。
ニューラルネットワークが生成するのは答えではなくクエリです。しかもそのクエリは、汎用のSQLではなくブロック型データ構造に対して動作するものと限定されています。プロンプトを「どのデータを見るか（データソーストークン）」と「どの属性で絞るか（パラメータトークン）」に分けている点も、単なる検索とは異なる設計です。
生成された説明文の中に、クリックできる引用を織り込みます。生成AIの弱点である「もっともらしい誤り」に対して、出典を辿れるようにするという実務的な解決です。
見落とされがちですが、「次の質問を受け付ける入力欄を表示したまま」という限定が入っています。出典を確認するために対話が中断されない、というUXそのものが構成要件に組み込まれているのです。
弁理士の視点：「AIが答える」という抽象的なアイデアだけでは、米国でも日本でも特許は通りにくいのが現状です。この請求項は、データ構造・処理の順序・画面の挙動まで具体的に書き込むことで、抽象的アイデアの域を脱しています。生成AI系の出願を検討する際の、実践的な書き方の一例と言えます。
この請求項には、権利範囲を絞る方向に働く限定が複数入っています。他社の立場から「回避できるか」を検討するなら、着目すべきは次の3点です。
| 限定 | 実務上の意味 |
|---|---|
| ブロック型データ構造であること | 対象がブロック単位で管理されるシステムに限られます。ファイル単位・レコード単位で管理する一般的な文書管理システムは、この前提から外れる可能性があります |
| クエリを生成して実行すること | ベクトル検索で文書片を取り出してLLMに渡すだけの構成（典型的なRAG）は、「クエリを生成し、データ構造に対して実行する」という流れと一致しない場合があります |
| 入力欄を表示したまま出典を開くこと | 出典クリックで画面遷移してしまう実装は、この要件を満たさない可能性があります |
注意：上記はあくまで請求項1の文言に基づく一般的な検討です。実際の侵害判断では、他の請求項（本件は全20項）、明細書の記載、出願経過における主張（包袋禁反言）、均等論の適用可否まで含めて総合的に判断されます。本記事の記載をもって非侵害の判断をすることはできません。
この請求項1は、「方法」でも「システム」でもなく、“One or more non-transitory, computer-readable storage media”（1以上の非一時的なコンピュータ可読記憶媒体）から始まっています。これは米国実務でよく見られる書き方です。
記録媒体クレーム（CRMクレーム）には、次のような特徴があります。
実務Tips（クレーム類型の使い分け）：日本でも「方法」「システム（装置）」「プログラム」「記録媒体」を組み合わせて出願するのが一般的です。SaaSのようにサーバとクライアントで処理が分かれる発明では、どの主体の行為を捉えるクレームなのかを意識して類型を揃えておくことが、後の権利行使のしやすさに関わります。詳しくはSaaSプロダクトの機能マップもあわせてご覧ください。
社内文書にAIで問い合わせる仕組み——いわゆるRAG（検索拡張生成）を開発している企業は日本にも数多くあります。この特許から読み取れる、実務上のヒントを整理します。
日本の審査でも、発明該当性（特許法2条1項）と進歩性が関門になります。自然言語で質問してAIが答えるという構成だけでは、既に多数の先行技術があり、権利化は容易ではありません。ソフトウェア特許で拒絶されやすい類型はソフトウェア特許の拒絶理由あるある5選で整理しています。
この特許が「ブロック型データ構造」を前提に置いたように、自社プロダクト固有のデータの持ち方を請求項に取り込むと、先行技術との差が出しやすくなります。権利範囲は狭まりますが、自社実装をしっかりカバーする形にはなります。
「入力欄を表示したまま出典を開く」のように、画面上の挙動を要件に入れる書き方は有効な選択肢の一つです。技術的な処理と画面の振る舞いをセットで捉えると、実装の実態に沿った権利になります。
本件の出願日は2024年4月12日。生成AI機能をプロダクトに載せる各社が動いていた時期です。機能をリリースして公表すると、原則としてその内容は新規性を失います。出願はリリース前に済ませておくのが鉄則です。スケジュールの組み方はシステム・ソフトウェア特許 出願の流れ完全ガイドで解説しています。
Q. この特許は日本でも効力がありますか？
A. いいえ。特許権の効力は国ごとに独立しています（属地主義）。US 12,688,361は米国内での実施にのみ効力が及びます。ただし同じ優先日でPCT国際出願（WO 2025/216752）が行われており、日本を含む各国への移行があり得ます。日本国内移行の期限は2026年10月頃と見込まれます。
Q. 自社のRAGシステムは、この特許に触れますか？
A. 米国で事業を行っていない限り、この特許自体を直接気にする必要はありません。米国展開がある場合は、請求項1のA〜Fすべてを満たすかを実装と照合してご確認ください。特に「ブロック型データ構造」「クエリの生成と実行」「入力欄を保持したまま出典表示」の3点が判断の分かれ目になり得ます。個別の判断は弁理士にご相談ください。
Q. 「トークン化」はLLMのトークナイザと同じ意味ですか？
A. 請求項の文言は「データソーストークン」と「パラメータトークン」を生成すると述べており、単に文字列を分割するのではなく、意味的な役割ごとに区分する処理を指していると読めます。用語の正確な意義は明細書の定義と出願経過を踏まえて解釈されます。
Q. 生成AIを使った機能は、日本で特許を取れますか？
A. 取得例は増えています。鍵になるのは、AIを使うこと自体ではなく、どのようなデータをどう処理し、どんな課題を解決するのかを具体的に記載できるかどうかです。日本・米国・欧州の審査実務の違いはAIエージェントの特許事例と審査実務で比較しています。
US 12,688,361 が押さえているのは、「自然言語をクエリに変え、ブロック型データ構造に実行し、出典リンク付きの答えを、対話を止めずに提示する」という一連の流れです。生成AIそのものではなく、プロダクト固有のデータ構造と画面挙動を織り込むことで具体性を確保している点が、この請求項の設計の要になっています。
生成AI機能の権利化を検討している企業にとって、「どこまで具体的に書けば通るのか」を測るうえで参考になる一件です。
知的財産事務所エボリクスへのご相談
エボリクス（evorix.jp）では、生成AI・RAG・SaaS分野の特許出願と、他社特許のクリアランス調査を承っております。「自社のAI機能は特許になるか」「この他社特許に触れないか」といったご相談に対応いたします。まずはお問い合わせフォームよりお気軽にご相談ください。
本記事の注意事項：本記事は2026年7月時点の公開特許情報に基づく一般的な解説です。引用した請求項・要約は公開データベースの記載に基づきますが、権利範囲は最終的にUSPTOの正本と出願経過により定まります。本記事の分説・解説は理解を助けるための整理であり、権利範囲を画定するものではありません。侵害の成否、特許の有効性について本記事は何ら断定するものではなく、個別事案の結論を保証するものでもありません。事業判断にあたっては専門家の個別検討をご利用ください。