参加する(無料)
ルビコンブログ No.007 実務×AI

審査で指摘された記載要件の不備を、生成AIは出願前に検出できたか ― 公開特許公報20件での検証

本記事の数は、生成AIが挙げた候補の数と、それを初回の拒絶理由通知の指摘と人が突き合わせた結果です。候補の妥当性をすべて検証したものではありません。対象とした公報は実在する案件であり、取り扱いに注意が必要であるため、本記事では特定していません。本記事は検証結果の報告であり、特定のサービスやモデルの利用を推奨するものではありません。

この記事のポイント
  • 審査で記載要件(36条)の指摘を受けた公報20件のうち17件(85%)で、生成AIは審査官と同じ原因の不備を出願前の文面から検出していた
  • 審査官の指摘43か所では、同じ原因を検出したのが26か所(60%)。関連する指摘まで含めると36か所(84%)、指摘がなかったのは7か所(16%)
  • 「前記○○」の受け先がない10か所とサポート要件の5か所は検出率100%。処理の内容・対象が特定されていないという指摘は11か所中4か所(36%)にとどまった
  • AIが36条に関わるとした候補は20件で89か所。審査官の指摘と対応したのは26か所(29%)で、残りの妥当性は未検証。候補は人が判断する前提

この記事の概要

調べたこと

審査で記載要件(特許法36条)の指摘を受けた公開特許公報20件について、生成AIが出願前の文面から「記載要件に関わる」と判定した指摘候補を、実際の拒絶理由通知の指摘と1つずつ突き合わせました。

結果:20件中17件(85%)で、審査官と同じ不備を事前に検出

20件のうち17件で、AIは審査官の指摘の少なくとも1か所を、同じ原因で事前に検出していました。関連する指摘があった1件を加えると18件(90%)です。

指摘のか所数では、審査官の指摘43か所のうち検出が26か所(60%)、部分検出が10か所(23%)、未検出が7か所(16%)でした。

検出しやすい不備と、しにくい不備

「前記○○」の受け先がない10か所と、サポート要件の5か所は、すべて検出していました。処理の内容や対象が特定されていないという指摘は、11か所のうち4か所(36%)にとどまりました。

AIの候補は人が確認する前提

AIが36条に関わるとした候補は20件で89か所あり、審査官の指摘と対応したのは26か所(29%)です。残りの63か所が不備かどうかは検証していません。

結論

この20件に限れば、出願前にAIに36条の観点で一度見せていれば、17件(85%)で審査官の指摘の少なくとも1か所を事前に直せた計算になります。請求項の形式面の点検はAIに先にやらせ、技術内容の特定は人が読む。その分担が妥当だというのが本記事の結論です。

背景:審査官の指摘と、AIの指摘を突き合わせる

誤字脱字や用語の揺れといった表記の不備は、原文を見れば採否をその場で判断できます(表記の不備については、別の記事で扱いました)。

記載要件の不備はそうはいきません。明確性要件やサポート要件に関わる指摘は、拒絶理由として通知されると補正と意見書で対応することになり、請求項の範囲にも影響します。出願前に見つけて直せるなら、その価値は表記の不備より大きいはずです。

そこで、拒絶理由通知で指摘される36条の不備のうち、出願前の文面だけから機械的に見つけられるものがどれだけあるのかを確かめました。公開特許公報と審査経過はどちらも公的に読めるので、AIの指摘と審査官の指摘を1件ずつ突き合わせることができます。

調査の方法

対象

ITソフトウェア関連の2019〜2020年出願の公開公報から、審査請求され、初回の拒絶理由通知に36条の指摘があったもの20件を抽出しました。母集団を一定の順序で並べ、先頭から順に審査経過を確認して、36条の指摘があったものを20件そろうまで採用しています。選ぶ段階で筆者は通知を読んでいますが、AIには渡していません。

審査官の指摘は、原因ごとに数えると20件で43か所です。内訳は明確性要件(36条6項2号)が37か所、サポート要件(36条6項1号)が5か所、実施可能要件(36条4項1号)が1か所です。通知の「なお書き」で触れられているだけのものや、36条以外の条文で挙げられた指摘は数えていません。

具体的にどの公報を対象としたかは、実在する案件であり取り扱いに注意が必要であるため、本記事では割愛しています。

公開公報と審査経過の確認:J-PlatPat(特許情報プラットフォーム)/条文:特許法(e-Gov法令検索) 第36条

AIの実行

生成AI(claude-fable-5-1)に、公報ごとに新しい会話で本文(要約・特許請求の範囲・発明の詳細な説明。公報に掲載された出願公開前の補正書があればそれも含む)を渡し、各請求項の引用関係、各処理の実行主体・入力・出力、分岐ごとの整合、課題と請求項の対応を順に点検させるプロンプトを、1件につき1回実行しました。AIは、記載要件に関わると判断した候補に印を付けて出力します。プロンプトの全文は、ルビコンのDiscordで公開しています。

AIには拒絶理由通知を見せていません。審査結果を知らない状態での出力です。

本文はJ-PlatPatのテキスト表示から取得しました。20件のうち1件で、画面に表示されるテキストから請求項の一部の行が欠けていることが分かったため、J-PlatPatの内部データに基づいて補ってから実行しています。

突き合わせの基準

審査官の指摘1か所ごとに、AIの出力に対応する候補があるかを人が確認し、次の3つに分けました。

  • 検出:同じ請求項について、同じ原因を記載要件の候補として指摘している
  • 部分検出:同じ箇所に関連する指摘はあるが、原因の捉え方が違う、または記載要件の候補ではなく誤記や改善提案として扱っている
  • 未検出:該当箇所に関連する指摘がない

本記事では、AIが挙げた箇所を「指摘候補」、拒絶理由通知の指摘を「審査官の指摘」と呼びます。百分率は小数点以下を四捨五入しています。

結果:20件中17件で、審査官と同じ不備を事前に検出

突き合わせの結果を表1に示します。

公報の件数で見ると、20件のうち17件(85%)で、AIは審査官の指摘の少なくとも1か所を、同じ原因で事前に検出していました。部分検出にとどまった公報が1件、どの指摘にも関連する候補がなかった公報が2件です。

指摘のか所数で見ると、審査官の指摘43か所のうち、検出が26か所(60%)、部分検出が10か所(23%)、未検出が7か所(16%)でした。

AIの側から見ると、20件でAIが36条に関わるとした候補は89か所で、このうち審査官の指摘と対応したのは26か所(29%)です。候補と指摘は1対1ではなく(1つの候補が指摘2か所に対応する例、1か所の指摘に2つの候補が対応する例、部分検出の候補を含みます)、検出26か所と同じ数になったのは偶然です。

表1 審査官の36条の指摘と、AIの指摘候補の対応(36条の指摘を受けた公報20件)

項目 数
審査官の指摘の少なくとも1か所を、AIが同じ原因で事前に検出していた公報 17件/20件(85%)
審査官の36条の指摘 43か所
うち、AIが同じ原因を事前に指摘していた(検出) 26か所(60%)
うち、関連する指摘はあった(部分検出) 10か所(23%)
うち、AIの指摘がなかった(未検出) 7か所(16%)
AIが36条に関わるとした指摘候補(20件の合計) 89か所
うち、審査官の指摘と対応したもの 26か所(29%)

検出できたかどうかは、指摘の種類によって差がありました。審査官の指摘43か所を、その文面をもとに7つに分けたものが図1です。

図1 審査官の36条の指摘43か所を7区分に分け、AIが検出できたかを示した図。「前記○○」の受け先がない10か所はすべて検出。処理の内容・対象が不特定の11か所は検出4、部分検出4、未検出3。ステップの実行主体が不特定の6か所は検出3、部分検出2、未検出1。誤記・記載漏れ・引用形式の7か所は検出3、部分検出3、未検出1。択一的記載・引用元との矛盾の3か所は検出1、部分検出1、未検出1。サポート要件の5か所はすべて検出。実施可能要件の1か所は未検出
図1 審査官の指摘の種類別に見た、AIが検出した数(43か所)

「前記○○」の受け先がない10か所と、サポート要件の5か所は、すべて検出していました(検出率100%)。誤記・記載漏れ・引用形式の誤り、ステップの実行主体の不特定、択一的記載や引用元との矛盾も、大半は検出か部分検出で、未検出は各1か所です。請求項の形式面に当たるこれら4区分の26か所で見ると、検出が17か所(65%)、部分検出まで含めると23か所(88%)です。

一方、処理の内容や対象が特定されていないという指摘は、11か所のうち検出が4か所(36%)、部分検出が4か所、未検出が3か所でした。実施可能要件の1か所も検出していません。

なお、この7区分は審査官の指摘の文面をもとに本記事で整理したもので、通知にこの区分があるわけではありません。

検出できた不備の例、できなかった不備の例

検出できた不備の例

AIが審査官と同じ原因を指摘していた例を表2に示します。

表2 検出できた不備の例(AIが同じ原因を指摘)

審査官の指摘(要旨) 根拠条文 AIの指摘候補(要旨) 記載箇所
「前記予測部」に対応する「予測部」の記載がなく、指示先が不明確 36条6項2号(明確性) 請求項14の引用経路(14→12→11→1 など)のいずれにも「予測部」が導入されておらず、予測の主体は「前記分析処理部」である。「前記分析処理部」に改めるべき 請求項14
「前記耐タンパー」「前記第2の保存デバイス」に対応する記載が、択一的に引用される請求項の一方にしかなく、その請求項を引用しない場合に指示先が不明確 36条6項2号(明確性) 請求項7の択一引用の経路ごとに受け先を確認し、どの経路でも「耐タンパーなセキュリティチップ」(請求項6のみ)か「第2の保存デバイス」(請求項5のみ)の先行記載が欠けると指摘 請求項7
「購入日時から昼食か残業食かを判定し、判定結果に応じて企業負担額を決定する処理」が、一方の場合だけ決定するとも、両方で異なる方法で決定するとも読め、意味が不明 36条6項2号(明確性) 昼食と判定した場合と残業食と判定した場合とで、企業負担額の決定にどのような違いが生じるのかが請求項上特定されていない 請求項1
顧客位置に紐付けられた駅IDを駅マスタから検索するとあるが、駅マスタは顧客位置を持たず、どのように検索するのか把握できない 36条6項2号(明確性) 請求項に定義された駅マスタの項目は駅名・駅ID・駅位置のみで顧客位置を含まないため、請求項内で検索が成立しない。所定数をどの基準で選ぶかも特定されていない 請求項1・4・5
「判定部により新たに作業が開始されたと判定される場合に、作業時間の計測を開始する」が発明の詳細な説明に記載されていない 36条6項1号(サポート要件) 明細書で計測開始の契機として記載されているのは、作業対象が所定の温度に達した場合のみで、「作業が開始されたと判定する」処理は記載されていない 請求項1・5

これらに共通するのは、請求項の文言どうし、あるいは請求項と明細書の対応関係を突き合わせれば判断できることです。「前記」の受け先の有無、判定結果と処理の対応、駅マスタの項目と検索条件の食い違い、計測開始の契機の違いは、いずれも文面の中で閉じています。

部分的に検出した不備の例

AIが箇所は押さえながら、記載要件の候補として印を付けなかった例や、原因の捉え方が違った例を表3に示します。

表3 部分的に検出した不備の例(関連する指摘はあるが、原因の捉え方が違う、または記載要件の候補にしていない)

審査官の指摘(要旨) 根拠条文 AIの指摘候補(要旨) 記載箇所
「係数手段」は「計数手段」の誤り 36条6項2号(明確性) 「係数手段」は「計数手段」の誤記と判断し、修正案を提示。ただし明白な誤記であるとして、記載要件の候補にはしていない 請求項11
各処理(データメッセージへの変換、部分関数の構成など)の実行主体がプログラムかユーザか不明 36条6項2号(明確性) 方法の各ステップに実行主体の特定がなく、明細書の記載からは人の設計作業としても読めると指摘。ただし記載要件の候補ではなく改善提案として扱った 請求項1〜8
「変換された居住設備情報に対応する価格帯」を、どのように特定できるのか不明 36条6項2号(明確性) 従属項にある「履歴を参照して価格帯を算出する」について、履歴のどの項目からどう算出するのかが明細書に記載されていないと、実施可能要件の候補として指摘。箇所は近いが、請求項と原因が異なる 請求項15(AIは請求項16)

「係数手段」のような請求項の誤記について、AIは「明白な誤記であり36条違反には格上げしない」と判断しましたが、審査官は明確性の拒絶理由としました。20件の中には、請求項の助詞の脱落と衍字を審査官が明確性の理由とし、AIは誤字脱字として挙げた例が他に2か所ありました。請求項の誤記は、表記の点検と記載要件の点検の両方で見る必要があります。

検出できなかった不備の例

AIが該当箇所について関連する指摘をしていなかった例を表4に示します。

表4 検出できなかった不備の例(AIに関連する指摘がない)

審査官の指摘(要旨) 根拠条文 AIの指摘候補(要旨) 記載箇所
プログラム命令が各処理を行う具体的な方法が発明の詳細な説明に記載されていない 36条4項1号(実施可能要件) 該当する指摘なし 請求項9〜16
装置の適用範囲・対象の記載がなく、数理モデルによる予測値算出の具体的な情報処理が不明 36条6項2号(明確性) 請求項3の式の関係や定義については候補を挙げたが、請求項1の数理モデルの不特定は指摘していない 請求項1〜5
サービス利用時に取得される「外出情報」が、携帯情報端末自体の機能でどのように特定されるのか分からない 36条6項2号(明確性) 同じ請求項について、装置と方法のカテゴリーの混在や用語の揺れは指摘したが、原因が異なる 請求項4〜6・11
方法の各ステップの動作主体が明記されておらず、人がコンピュータを操作する手順も含み得る 36条6項2号(明確性) 同じ請求項について、独立項どうしの用語の不統一は指摘したが、主体の不特定には触れていない。別の公報では同じ種類の不備を検出している 請求項9
「システム、装置またはプログラム」という択一的な記載は、選択肢どうしが類似の性質・機能を持たない 36条6項2号(明確性) 該当する指摘なし 請求項4・5

検出できなかった例の多くは、発明の技術内容に踏み込んで、「これでは実施できない」「これでは何をしているのか特定されていない」と判断するものでした。AIは同じ請求項について別の候補を挙げていることが多く、箇所は見ていても、審査官と同じ問題意識には至っていません。

もう1つ注意したいのは、方法のステップの実行主体のように、別の公報では検出していた種類の不備を、ある公報では検出できなかったことです。同じプロンプトでも、出力は公報ごとに揺れます。

結果の読み方

  • 各公報1回の実行であり、同じ入力で再実行した場合のばらつきは確認していません。
  • 「検出」と「部分検出」の線引きには人の判断が入っています。基準は「突き合わせの基準」のとおりです。突き合わせは通知の内容を知った状態で行っているため、一致の判定が甘くなっている可能性があります。
  • 審査官の指摘は、公開公報に掲載された時点の文面に対するものです。公開後の補正を経て通知された案件では、指摘された箇所が公開時の文面にも存在することを確認しています。
  • 20件は36条の指摘があることを条件に選んでいます。36条の指摘がどの程度の割合の出願で出るかは、この20件からは分かりません。また、36条の指摘を受けていない公報でもAIは同程度の候補を挙げます(別途確認した9件で39か所)。候補があることと、不備があることは別です。
  • 対象はITソフトウェア関連・2019〜2020年出願で、36条の指摘を受けた20件・43か所です。他の分野、他のモデル、他の時点に当てはめる根拠はありません。

特許事務所の運営や実務に置き換えると

今回の結果を、出願前のチェック手順に置き換えると、次のようになります。

出願前に、36条の観点でAIに一度見せる

この20件に限れば、出願前にAIに見せていれば、17件(85%)で審査官の指摘の少なくとも1か所を事前に直せた計算になります。候補の確認に人の時間はかかりますが、拒絶理由通知への応答に比べれば小さい手間です。出願前の最終確認の前に、AIに一覧を出させて人が確認する手順を入れる価値はあります。

請求項の形式面は、AIに先にやらせる

「前記○○」の受け先、引用経路ごとの用語の整合、方法のステップの実行主体、択一的記載、引用形式。この種の不備は、今回の20件では26か所中23か所(88%)で検出か部分検出でした。人が目視で追うと見落としやすく、AIが得意な領域です。ただし、同じ種類の不備を検出できなかった公報もあるので、AIの一覧に載っていないことを根拠に「問題なし」とはしないほうがよいでしょう。

技術内容の特定は、人が読む

処理の中身が特定されているか、明細書の記載で実施できるか、という判断は、検出が11か所中4か所(36%)にとどまりました。AIの候補がない箇所が正しいとは限らないので、請求項については、AIの一覧とは別に人が最後まで読む手順を残しておくのが安全です。

請求項の誤記は、記載要件の問題にもなる

「係数手段」の例のように、誤記であっても請求項にあれば明確性の拒絶理由になり得ます。AIが誤記として挙げた候補のうち、請求項にあるものは、記載要件の観点でも確認しておくと安心です。

未公開の明細書を入力する前に、利用規約とプランを確認する

出願前の明細書は未公開の情報です。生成AIに入力する前に、使うサービスのプランで、入力内容が学習に使われないか、秘密保持の定めがあるかを確認してください。プランごとの違いは汎用型生成AIの利用規約比較表にまとめています。

本記事について

  • 本記事は、2026年10月時点で実施した検証の結果を報告するものです。数はいずれも生成AIが挙げた候補の数と、それを初回の拒絶理由通知の指摘と人が突き合わせた結果であり、候補の妥当性をすべて検証したものではありません。
  • 対象とした公報は実在する案件であり、取り扱いに注意が必要であるため、本記事では特定していません。表2〜表4の要旨は、公開特許公報と公開されている審査経過の文面から、案件を特定しない範囲でまとめています。
  • 本記事は一般的な情報提供を目的とするもので、法的助言ではありません。生成AIの利用の可否や、入力してよい情報の範囲は、各サービスの最新の規約と、締結している契約書面を確認したうえで、ご自身の責任でご判断ください。
  • 本記事は、特定のサービスやモデルの利用を推奨または非推奨するものではありません。
  • 更新履歴:2026年10月19日 初版公開/2026年10月19日 「本記事について」の運営元に関する記述を削除
ルビコン 知財実務 × 生成AI 共創コミュニティ

ルビコンに参加しませんか(参加無料)

ルビコンは、特許事務所の弁理士・特許技術者・事務スタッフや、企業の知財部員など、知財実務に携わる人のための生成AIコミュニティです。Discordを拠点に、次のような活動をしています。

  • 毎週「今週のプロンプト」を公開し、プロンプト全文と検証結果を共有
  • 知財実務に関わる生成AIの最新ニュースを共有
  • 実務での使い方や困りごとを、実務家どうしで気軽に相談

参加は無料です。参加方法は「参加案内」ページをご覧ください。

参加案内ページを見る

この記事の続きは、Discordで。 実際のプロンプト全文、他の分野で試した参加者の報告、うまくいかなかったケースへの対処は、Discordの「今週のプロンプト」「プロンプト置き場」で共有しています。質問もそちらへ。参加は無料です。
参加する