似た特許が見つかった。それでも出願するべきか――AI業務支援サービスを、戦略知能工学で考える｜演習シリーズ②

執筆・文責：弁理士　中村幸雄（登録番号 第12870号）

「似た特許が、いくつも見つかりました」

従業員15人のA社は、企業向けのAI業務支援サービスを開発しています。

社内の規程や業務マニュアルを検索し、その内容を根拠にAIが質問へ回答する。さらに、回答に応じて申請システムへの登録まで進める仕組みです。

例えば、社員が現在の規程に基づく備品の購入について質問すると、利用できる制度や必要な手続きを案内し、申請内容を作成する。条件が整えば、そのまま登録まで行います。

サービスの公開予定は6週間後。社長は、今後の事業の柱になる技術を特許で守りたいと考えていました。

ところが、開発責任者が特許を調べると、文書の検索、AIによる回答生成、業務システムとの連携に関する公報が次々と見つかります。

「検索して、AIが答えて、次の処理につなぐ。どれも、すでに書かれているように見えます」

社長も迷い始めました。

「これだけ似た特許があるなら、出願の費用を開発に回したほうがよいのだろうか」

ここで、調査の対象をさらに広げる前に、一つの問いを置きます。

A社は、今回、何を決める必要があるのでしょうか。

私は、決めることから必要な情報を定め、選択肢、実行、見直しまでをつなぐ方法を「戦略知能工学（Strategic Intelligence Engineering：SIE）」としてまとめています。今回は、その7ステップに沿って、A社の判断を追ってみます。(知財の余白)

Step 1：意思決定設計――公開前に、何を決めるのか

最初の相談は、「このサービスで特許を取れるか」というものでした。

ただ、その答えを事業上の判断に使うには、もう少し具体的な条件が必要です。

A社へのヒアリングで、次の事情が明らかになりました。

サービスの公開と、最初の対外的な技術説明は6週間後に予定されています。これまでの動作確認は社内の検証環境で行っており、公開するデモや説明資料は、これから確定する段階です。

当面の知財予算は、日本での出願1件を基本に考えています。社長が重視しているのは、顧客企業が安心して業務処理を任せられる仕組みを、継続的な強みに育てることです。

そこで、今回の意思決定を次の一文にします。

「公開前に決める」というだけでは、書類作成の時間が不足する可能性があります。判断の期限と、出願を完了させる目標時期を分けて置くことで、実行に使える時間を確保します。

併せて、調査費用の上限と、判断を見直す条件も決めておきます。

出願の検討と、他社特許への対応を分ける

ここでは、二つの検討を並行して進めます。

一つは、自社のどの技術について、権利化を目指すか。もう一つは、サービスを提供する際に、他社の特許権との関係をどう確認するかです。

後者では、他社の出願が審査中か、特許権が登録され存続しているかなどの状態を確認します。そのうえで、特許請求の範囲と自社の具体的な処理を照合します。（参考：特許庁「特許のリーガルステータス」、特許庁「被害に遭ったら―権利侵害とは」）

自社の出願を進めることと、事業実施に関する権利関係の確認は、それぞれ別の作業として扱います。(INPIT「特許調査研修」)

本稿では、出願方針の選択を中心に追います。他社特許との関係は、サービス提供に向けた並行の確認事項とします。

Step 2：情報源設計――判断材料は、どこにあるのか

何を決めるかが定まると、必要な情報が見えてきます。

A社の場合、特許公報に加えて、開発の経緯や顧客への提供方針も判断材料になります。

表が画面に収まらない場合は、横にスクロールしてご覧ください。

開発者へのヒアリングでは、サービス紹介資料に表れにくい工夫を探ります。開発記録をもとに、チームがどの問題にぶつかり、何を変えたのかをたどることにしました。

この演習では、AIには公開文献の要点抽出や比較表の下書きを担当させます。判断に用いる記載は原文で確認し、未公開の仕様や検証記録は、事前に合意した管理環境で扱います。技術内容の確認は開発担当者、法的な評価は弁理士、投資判断は社長が担います。

Step 3：証拠収集――発明の手がかりは、開発中の困りごとにあった

調査では、次のような資料が見つかったと想定します。文献A〜Cは、すべて演習用の仮想資料です。

文献Aには、社内文書を検索し、検索結果を使ってAIが回答を生成する構成が記載されていました。

文献Bには、回答の信頼度に応じて、自動処理と人による確認を切り替える構成が記載されていました。

文献Cには、利用者による修正結果を、その後の検索に反映する構成が記載されていました。

ここまでを見ると、A社が説明していたサービスの大枠は、複数の先行技術と重なっています。

ところが、開発責任者に実際の動作を見せてもらうと、別の話が出てきました。

「最初は、回答の信頼度が高ければ処理を進め、低ければ人に確認してもらう設計でした。ただ、古い規程を根拠にした回答にも、高い信頼度が付くことがあったんです」

この演習でいう信頼度は、回答と参照文書の対応を評価したスコアです。

信頼度の基準を厳しくすると、人による確認が増える。基準を緩めると、誤った内容が申請システムに渡るおそれがある。

そこで開発チームは、回答の信頼度に加えて、参照した文書の改訂状態や、根拠となる情報同士の食い違いを確認する処理を実装していました。

文書の改訂状態と施行日を確認し、問い合わせの対象時点に適用されない版を参照していた場合は、適用される版に検索対象を切り替えて再検索する。根拠の食い違いが残る場合には、人による確認へ回す。確認者が確定した内容と修正理由は記録し、同じ種類の問い合わせに用いる検索条件へ反映する。

「私たちは、これを実装上の調整だと思っていました」

ここで、出願候補の捉え方が変わります。

当初の候補は、

でした。

ヒアリング後に検討の中心となったのは、

です。

開発チームがすでに実装していた工夫を、課題と処理の関係が分かる形に言語化したのです。

「違いがある」の次に、何を確かめるか

ここで確認できたのは、出願候補となる具体的な構成です。次は、その構成を先行技術と詳しく比較します。

新規性は、請求項に記載する発明と、一つの引用発明とを対比して判断します。進歩性では、他の先行技術や技術常識も踏まえ、その構成に容易に到達できたかを検討します。文献A〜Cを組み合わせた場合の評価も、進歩性を検討する際の論点です。(特許庁「新規性・進歩性」)

A社では、追加調査の焦点を「AI業務支援サービス全般」から、「根拠の問題を判別し、その結果に応じて検索条件と実行経路を変える制御」へ移します。

相談後2週間以内に、制御部分の追加調査と仕様の確認を進めました。この演習では、同じ問い合わせに旧版の規程を根拠とする高い信頼度の回答が生成されたとき、検証記録から次の動作の違いを確認できたとします。

表が画面に収まらない場合は、横にスクロールしてご覧ください。

仮想文献A〜Cには、検索、信頼度による切替、修正結果の反映という個々の処理が記載されていました。追加検討では、問題の種類に応じて検索条件を変え、その結果を実行経路の選択につなげる関係に着目しました。弁理士は、この関係を具体的な構成に分け、比較対象とした各先行技術との相違点を示しました。

検証記録からは、その関係によって処理がどう変わるかも確認できました。一方、既知の処理を組み合わせれば容易に到達できると評価される可能性は、残る論点として社長に伝えました。

先行技術との違いと、なお検討が必要な点を、社長が確認できるようになりました。

検索対象や文書の改訂状態を扱う技術的な着眼点は、RAGの特許に関するコラムでも解説しています。

Step 4：全体俯瞰――その工夫は、事業のどこを支えるのか

ここで、どこまで広く見る必要があるかを判断します。

今回の目的は、公開前に出願対象を選ぶことです。俯瞰の範囲は、A社のサービスを構成する主要な処理と、顧客が評価する機能に絞ります。

情報の流れを追うと、サービスは「検索」「回答生成」「根拠の確認」「実行経路の選択」「結果の反映」という処理でつながっています。

そのうち、A社の工夫は、根拠の確認から実行経路の選択、次回の検索への反映にまたがっていました。

営業メモを確認すると、導入候補企業が関心を示していたのも、この部分です。

「回答を作ってくれるのは助かる。ただ、申請まで進めるなら、どの時点で人が確認するのかが重要になる」

A社が提供したい価値と、開発チームが工夫していた場所が重なりました。

ただし、事業上の重要性と、権利としての使いやすさには別の検討が必要です。

今回の制御は、サーバー内部の処理が中心です。A社では、将来、他社による同様の処理をどのような情報から把握できるかも検討項目に加えます。利用者画面や公開資料に表れる動作と、内部でのみ確認できる動作を分け、出願内容を考える材料にします。この検討は、AI SaaSの特許設計に関するコラムでも扱っています。

ここでの問いは、次のようになります。

どの技術を守ることが事業上重要で、その技術をどのような権利として捉えることに意味があるのか。

Step 5：選択肢設計――三つの案を、同じ基準で比べる

調査とヒアリングの結果を、社長が比較できる三つの案に変えます。

表が画面に収まらない場合は、横にスクロールしてご覧ください。

この三案の違いは、出願する範囲の広さだけではありません。何を技術の中心と考え、どの不確実性を引き受けるかの違いです。

案Bでも、周辺のシステム構成や実施のバリエーションは検討します。制御部分に焦点を合わせることと、一つの細かな実装例だけを対象にすることは、分けて考えます。

今回は、案Bで出願を進める

相談後3週間以内に、社長は追加調査と仕様確認の結果を踏まえて三案を比較しました。

案Aについては、今回の資料で説明できた技術的な特徴が、サービス全体の連携より、根拠確認と実行切替の制御に集中していました。

案Cについては、現行仕様と検証記録を使って出願内容を具体化できる状態でした。追加開発を待つことで得られる検証結果と、現時点で出願を進める価値を比較し、今回は公開前に出願を進める価値を重視しました。

そのうえで社長は、この制御を今後も主要機能として維持する方針を確認しました。顧客が重視する「安心して業務処理を任せられること」とも結びついています。弁理士が示した技術構成、想定する保護範囲、権利化の評価に残る論点を踏まえ、今回の予算をこの制御の権利化に充てると判断しました。

社長は、他社による内部処理の把握には限界があることも確認しました。外部から確認できる動作と請求項の構成を引き続き検討することを、出願書類作成時の課題として残しました。

出願対象、調査・出願・その後の対応に使う費用、公開方針を確認し、案Bで出願を進める方針と予算を決裁しました。 出願書類の最終確認と提出の承認は、次の工程で行います。

具体的な連動関係まで重なる先行技術が新たに見つかった場合や、顧客向け仕様から当該機能を外す方針になった場合には、決裁を見直します。案Cへ移る場合も、その時点の公開予定を踏まえて実行できるかを確認します。

選んだ方針と、その判断を変更する条件をセットにしておく。
これにより、追加情報を得た後の判断も進めやすくなります。

出願を見送る案には、公開方針も含める

案Cは、再評価まで対象技術の公開・提供範囲を管理できることを前提とします。その間に得たい検証結果と再評価の時期を定め、再評価時には、出願を進める方針と、秘密として保持する方針を比較します。出願・秘匿・併用の考え方は、演習①「特許か、秘匿か」で扱っています。

デモ、説明資料、実際のサービス提供から何が外部に伝わるかを確認し、必要に応じて、その機能の公開や提供の時期も変更します。待てる条件が整っていることと、待つことに事業上の意味があることを、それぞれ確認します。

出願前の公開は新規性の判断に影響します。日本には一定の条件で適用される例外規定がありますが、海外も含めて出願の選択肢を確保するには、公開内容と時期を管理することが重要です。(特許庁「発明の新規性喪失の例外規定」)

「追加開発後に再評価する」という選択には、その時点まで何を保留し、何を進めるかという事業上の判断も含まれます。

Step 6：実行計画――出願方針を、担当者が動ける形にする

案Bの出願方針と予算を決裁した後は、書類作成、最終確認、提出へ進みます。

相談開始から公開までの工程と、3週間後の決裁時点の状況を示します。この架空事例における計画です。

表が画面に収まらない場合は、横にスクロールしてご覧ください。

出願に向けて、開発チームは「AIが適切に判断する」という説明を、具体的な処理へ書き換えます。

どのデータを取得するのか。文書の改訂状態と施行日をどの情報から確認するのか。どの条件で再検索へ進み、どの条件で人に確認を求めるのか。確認結果を、次の検索条件にどう反映するのか。

これらを処理フローと具体例で示します。弁理士は、外部から確認できる動作と請求項の構成も検討し、出願書類へ反映します。

また、調査時点で確認できる情報には限界があります。特許出願は原則として出願から1年6か月後に公開されるため、調査時点では公開前の出願も存在します。評価の対象とした資料、調査日、残る不確実性を記録し、その時点の判断根拠を残します。(INPIT「特許出願前に注意すること」)

A社の成果物は、調査報告書に加えて、次の内容を備えた意思決定メモになりました。

Step 7：監視と学習――出願後、どの変化で判断を更新するのか

出願を終えた後も、A社のサービスは変わっていきます。

顧客の使い方が分かり、確認を求める場面が変わり、参照する文書も増える。競合のサービスや特許情報も更新されます。

そこでA社は、次のような変化を、判断を見直すきっかけとして定めました。

類似する制御を示す新しい公報が見つかったとき。
弁理士が出願内容との関係を確認し、権利化の見通しや、他社の権利への対応を再検討します。

根拠確認や実行切替の仕組みに、重要な改良が加わったとき。
開発責任者が変更点と効果を記録し、外部公開前に、追加出願の要否を相談します。

顧客の評価や事業方針が変わったとき。
例えば、顧客が全件について人による承認を求めるようになれば、自動実行との切替に置いた価値も再評価します。社長は、製品方針と知財への投資配分を見直します。

さらに、公開後3か月を目安に、今回の判断を振り返ります。

出願対象とした機能は、実際に顧客に使われているか。期待した価値は確認できたか。判断時に不足していた情報は何だったか。

この記録を、次の発明候補を評価するときの確認項目へ反映します。

変化を見つけて判断を更新することと、判断の経験を次に残すこと。
この両方が、Step 7の役割です。

似た特許が見つかったことが、判断の出発点になった

A社の最初の問いは、「似た特許がある。それでも出願する価値はあるのか」でした。

検討を進めると、「顧客が安心して業務処理を任せられる仕組みのうち、どの技術を、いつまでに、どの条件で出願するか」という具体的な問いになりました。

その過程で、先行技術との比較、開発チームの工夫、顧客の評価、予算、公開予定が一つの判断につながりました。

最後に残ったのは、出願の対象、選んだ理由、実行する担当者、そして判断を変える条件です。

戦略知能工学が目指すのは、情報を使って選べる状態をつくり、その選択を行動につなげることです。

似た特許が見つかったという情報も、その使い方によって、次に調べる対象や、発明として検討する場所を具体化する手がかりになります。

まだ、出願する部分が決まっていない段階から

「似た技術は見つかったが、自社の工夫をどう捉えればよいか」

「サービス全体と、個々の実装の工夫を、どう結びつければよいか」

「公開が近づいており、出願と開発の進め方を決めたい」

発明の余白では、こうした段階からご相談いただけます。

初回無料相談では、技術テーマ、現在の状況、公開予定などをお聞きし、次に確認する事項と進め方をご案内します。正式な調査、特許性の評価、出願書類の作成は、別途、範囲と費用をご相談のうえで進めます。(発明の余白)