Media > AI活用ユースケース > 知財 > 対外発表の資料を公開前に点検して未出願の発明と秘密情報の記載を洗い出す

対外発表の資料を公開前に点検して未出願の発明と秘密情報の記載を洗い出す

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

学会の予稿やプレスリリースなど社外へ出す技術資料を入力に、社内の公開前チェック基準と過去の指摘記録に照らして、出願前の発明や秘密にしている条件値に当たりうる記載を、基準番号・理由・確認先つきの表にします。知財担当の作業は、資料を読んで該当箇所を探すことから、挙がった箇所を確かめることに変わります。

サマリー
利用ツール
ChatGPT/Claude/Gemini/Google Apps Script/Microsoft Copilot/Power Automate/Python
対象業界
IT・SaaS/医療/製造
対象部門
知財/研究開発
対象業務
内容確認・チェック/書類作成
主な課題
人手が足りない/属人化している/確認ミスが多い
AIで行う処理
校正
主な効果
品質標準化/工数削減/機会損失防止
導入難易度
★☆☆☆☆
実装レベル
最小構成
費用感
既存ツールのみ(小)
人間の確認
必須
現在工数
20h/月
AI導入後
7h/月
想定削減
65%
年間削減
156h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 技術者が資料を作り、公開予定日と一緒にチャットで知財部へ送る
  2. 知財担当が資料を頭から読む(スライドは図も見る)
  3. 課題と解決手段が対で書かれている箇所に印を付ける(発明に当たりうる記載)
  4. 温度・圧力・時間・配合比などの条件値、歩留まり、装置の型式、工程の順序に印を付ける
  5. 印を付けた技術内容を、出願管理システムで引く(出願済みか、記録がないか)
  6. 顧客名、共同開発先、受領した図表、他社の商標や図表の引用を見る
  7. 指摘コメントを書いて戻し、直った資料を見て公開を認める
導入後(After)
  1. 技術者が、資料・媒体・公開予定日・関連する出願番号(分かる範囲で)を添えて提出する
  2. 知財担当が、伏せ字の範囲を決めてから、公開前チェック基準を置いた生成AIのプロジェクトに資料を貼る
  3. 自動AIが要確認の箇所を洗い出し、基準番号・理由・確認先・書き換え案を付けた表を返す
  4. 自動機械的に拾える語(数値と単位、型式、社名)を正規表現でも拾い、AIの表にないものを足す
  5. 【人またはプログラム】 挙がった技術内容を出願管理台帳と照合する
  6. 知財担当が資料全体を読み、AIの表と照合する(図やグラフの中身は資料で見る)
  7. 発明者に「これは出願前の内容か」を確認し、公開の可否を決める
  8. 指摘コメントを直して返し、判断を指摘記録に残す
  9. 公開後、公開日・媒体・公開した内容を記録に残す
各工程の詳しい説明を読む
  1. 技術者が資料を作り、公開予定日と一緒にチャットで知財部へ送る
  2. 知財担当が資料を頭から読む(スライドは図も見る)
  3. 課題と解決手段が対で書かれている箇所に印を付ける(発明に当たりうる記載)
  4. 温度・圧力・時間・配合比などの条件値、歩留まり、装置の型式、工程の順序に印を付ける
  5. 印を付けた技術内容を、出願管理システムで引く(出願済みか、記録がないか)
  6. 顧客名、共同開発先、受領した図表、他社の商標や図表の引用を見る
  7. 指摘コメントを書いて戻し、直った資料を見て公開を認める

問題は4つあります。

(a)点検が2名に集中する。 学会の締切前に資料が集中し、「明日提出なので今日中に」という依頼が重なります。急かされた状態で読むことが、見落としの原因になっています。

(b)見るところが人によって違う。 Aさんは装置の型式を止め、Bさんは通します。技術者から見ると基準が読めません。

(c)一度公開すると取り返しがつかない。 誤字や数値の誤りは訂正すれば済みますが、公開した技術情報を未公開に戻すことはできません。 出願の機会を失う可能性があります。

(d)過去の指摘が探せない。 指摘はチャットに散らばっていて引けません。

  1. 【人】 技術者が、資料・媒体・公開予定日・関連する出願番号(分かる範囲で)を添えて提出する
  2. 【人】 知財担当が、伏せ字の範囲を決めてから、公開前チェック基準を置いた生成AIのプロジェクトに資料を貼る
  3. 【自動】 AIが要確認の箇所を洗い出し、基準番号・理由・確認先・書き換え案を付けた表を返す
  4. 【自動】 機械的に拾える語(数値と単位、型式、社名)を正規表現でも拾い、AIの表にないものを足す
  5. 【人またはプログラム】 挙がった技術内容を出願管理台帳と照合する
  6. 【人】 知財担当が資料全体を読み、AIの表と照合する(図やグラフの中身は資料で見る)
  7. 【人】 発明者に「これは出願前の内容か」を確認し、公開の可否を決める
  8. 【人】 指摘コメントを直して返し、判断を指摘記録に残す
  9. 【人】 公開後、公開日・媒体・公開した内容を記録に残す

自動化されるのは「洗い出す」「基準番号と理由を書く」の2つです。読むこと、出願状況を確かめること、判断することは人に残ります。 AIが見ているのは貼ったテキストだけです。

02今回想定するシステム構成

構成図
技術者が社外へ出す資料
(学会予稿 / 展示パネル / 技術ブログ / リリース / 顧客向け / 採用向け)
   ▼ 知財担当が貼る(伏せ字の範囲を決めてから)
生成AIのプロジェクト
   │  知識:公開前チェック基準 / 過去の指摘記録 / 用語の言い換え表
   │  指示:表の形と禁止事項(公開可否を書かせない)
   ▼
要確認箇所の表(引用 / 種類 / 基準番号 / 理由 / 確認先 / 書き換え案)
   ├──▶【人またはプログラム】出願管理台帳と照合
   ▼
【人】知財担当と発明者が判断 ──▶ 指摘コメントを返す
   ▼
公開後:公開日・媒体・内容を記録に残す

最小構成(今回の推奨)

半自動化する場合は、この「貼る」を提出フォームに置き換えます。各工程が何を読み、何を返すのかは第7章で説明します。

役割想定する製品代替候補
生成AIClaude(プロジェクト。半自動化では Claude API)ChatGPT(プロジェクト)、Gemini(Gem)、Microsoft 365 Copilot(Notebooks)
連携Google Apps Script(半自動化の段階)Power Automate、Python
資料の提出Google フォームMicrosoft Forms
基準・記録の置き場Google スプレッドシートSharePoint リスト
出願管理台帳既存の知財管理システム表計算ソフト

最小構成のままで効果の大半が取れます。 手間がかかるのは設定ではなく、基準を自社の言葉で書くことです。

03どうやって実装するのか

Step1

処理の起点を決める

最小構成では、知財担当が点検の依頼を受け取ったときが起点です。

半自動化では、提出フォームの送信を起点にします。Google Apps Script のインストール可能なトリガーには、ユーザーがフォームに回答すると実行されるフォーム送信トリガーがあり、Google フォーム用とシート用の2種類があります。このトリガーは常に作成者のアカウントで実行されるため、部署の管理用アカウントで設定します。

共有フォルダを見る形にするなら Power Automate の SharePoint コネクタが使えますが、「フォルダーにファイルが作成されたとき」は公開ドキュメント上で非推奨とされ、代替は「ファイルの作成時(プロパティのみ)」です。

提出の締切は運用で決めてください。 決めがないと、急かされた点検は減りません。

Step2

入力データを集める

データ中身取得元
点検対象の資料予稿・スライド・パネル原稿・ブログ原稿提出フォーム
媒体と公開予定日学会/展示会/ブログ/報道発表/顧客/採用提出時に選ぶ
公開前チェック基準基準番号、区分、見るところ、例、確認先スプレッドシート(新しく作る
過去の指摘記録指摘した記載、判断、理由(代表例30件程度)スプレッドシート
用語の言い換え表社内の装置名・工程名と社外で使える一般名スプレッドシート
出願管理台帳出願番号、発明の名称、出願日、発明者知財管理システム

公開前チェック基準が、この構成の本体です。 8区分から始められます。

基準番号区分見るところ確認先
G-01発明に当たりうる記載課題と解決手段が対で書かれている知財・発明者
G-02効果の数値効果を数値で示している知財・発明者
H-01秘密にしている条件値温度・圧力・時間・濃度・配合比技術部門長
H-02装置構成・工程順装置名・型式・工程の並び生産技術
H-03歩留まり・生産能力生産に関する実数製造部門
C-01顧客名・共同開発先相手方が特定できる記載営業・法務
C-02受領資料の引用相手から受け取った図表法務・提供元
T-01他社の商標・図表他社製品名、出典のない図表法務・広報

H区分の背景として、不正競争防止法第2条第6項は営業秘密を「秘密として管理されている生産方法、販売方法その他の事業活動に有用な技術上又は営業上の情報であって、公然と知られていないもの」と定義しています。個別の情報がこれに当たるかは法務部門に確認してください。 基準表は、その判断に回すべき記載を拾う社内ルールです。

Step3

データの取得方法を決める

最小構成: ファイルを知識として置ける機能を使います。

  • Claude のプロジェクト … 文書やテキストを知識として置き、指示を設定できる
  • ChatGPT のプロジェクト … 文書・表計算・PDFを参照資料として追加し、指示を書ける
  • Gemini の Gem … カスタム指示を入れ、[知識]に端末や Google ドライブのファイルを足せる
  • Microsoft 365 Copilot の Notebooks … OneDrive・SharePoint のファイルを参照に追加できる

Claude のプロジェクトは、有料プランでは知識が大きくなると検索して使う方式になります。全項目が毎回読まれる前提にしないでください。 基準表は100項目程度に収めます。

Step4

AIへ渡す前に整形する

  1. 図やグラフの中の文字をテキストでも提出してもらう … 条件値はスライドの図の中にあることが多く、貼り付けたテキストには入りません
  2. 伏せ字の範囲を先に決める … 顧客名、共同開発先の名称、未公開の出願番号は記号に置き換えます
  3. 注記と図表のキャプションを本文と同じテキストに含める … 条件値はキャプションに出ます
  4. 機械的に拾える語はプログラムでも拾う … 数値と単位の組、型式らしい英数字、社名を正規表現で拾い、AIの表にない語を確認対象に足します
Step5

AIに処理させる

処理内容
洗い出し基準表の区分に当たる記載を資料から引用して並べる
種類の付与発明に当たりうる/秘密にしている条件値/相手方の情報/他社の権利/基準外
基準番号と理由該当する番号と、基準表の「見るところ」に沿った理由
確認先知財/発明者/技術部門長/営業/法務のうち誰に確認すべきか
書き換え案の例数値を範囲にする、装置名を一般名にする、工程の順序を書かない、相手方を業種にする、の4方向で1案

やらせないこと: 公開してよい・いけないの判定、出願済みかどうかの推測、新しい技術説明や数値を足す書き換え案、条文番号や法的な結論の記載。

生成AIに「この技術は出願されていますか」と聞けば、それらしい答えが返りますが、根拠はありません。AIがするのは「出願されていれば問題にならないが、されていなければ問題になる記載」を挙げることだけです。

Step6

指示内容を固定する

あなたは、社外へ出す技術資料の公開前点検を補助する担当者です。
知識の【公開前チェック基準】【過去の指摘記録】【用語の言い換え表】
だけを基準に、資料から「人が確認すべき箇所」を表にしてください。

【厳守事項】
- 公開してよい、問題ない、掲載可、といった判定は書かないでください。
- この技術が出願済みか、出願できるか、特許になるかを書かないでください。
  判断できるのは「出願前であれば確認が要る記載かどうか」だけです。
- 該当箇所は資料から一字一句そのまま引用してください。
- 基準番号は【公開前チェック基準】の番号だけを使い、当てはまらない
  気づきは番号を「なし」として表の最後に並べてください。
- 書き換え案は「数値を範囲にする」「装置名を一般名にする」
  「工程の順序を書かない」「相手方を業種に置き換える」の4方向に限り、
  資料にない技術説明・数値・効果を足さないでください。
- 図やグラフの中身は確認できません。図があれば「図の中は未確認」と
  表の下に書いてください。
- 法令の条文番号や、法的な結論は書かないでください。
- 最後に、使った基準表の版(ファイル名の日付)を書いてください。

【媒体】{media} 【公開予定日】{publish_date}
【伏せ字】{masked}
【資料】{document_text}

「公開してよい、と書かない」の1行が最も重要です。 これがないとAIは「一般的な技術説明の範囲で、問題ないと考えられます」と書き、それを読んだ知財担当の読む手が緩みます。「出願済みかを書かない」も同じ理由で必須です。

Step7

出力形式を固定する

最小構成では表で返させます。

該当箇所の引用種類基準番号理由確認先書き換え案の例
予熱を二段に分けることで反りを抑えた発明に当たりうるG-01課題と解決手段が対知財・発明者出願状況を確認するまで記載しない
焼成温度1,180度、保持12分秘密にしている条件値H-01条件値が数値技術部門長数値を範囲で示す
歩留まりは92%に向上秘密にしている条件値H-03生産の実数製造部門実数を外す

半自動化では、検査のためJSONで返させます。

{
  "rule_version": "2026-09-01",
  "findings": [
    { "quote": "", "type": "", "rule_id": "H-01",
      "reason": "", "confirm_with": "", "suggestion": "" }
  ],
  "figures_unchecked": true
}

quote が資料にない指摘は捨て、rule_id が基準表にないものは「基準外」に回します。出力に「問題ありません」「公開可」「出願済み」が含まれていないかも機械的に検査します。

Step8

システムへ連携する

最小構成: AIの表を点検記録のスプレッドシートに貼り、判断の列を埋めます。技術者には判断後の指摘だけを返します。

半自動化: Apps Script が点検用スプレッドシートに1行1指摘で書き出し、機械的に拾った語のうちAIの表にないものを足します。台帳照合もここで行います。

指摘をそのまま技術者へ自動送信しないでください。 台帳を引いてから返さないと、技術者が「既に出しているはず」と自己判断して押し戻します。

Step9

人が確認する

全件、知財担当が判断します。 判断は「修正依頼」「このまま公開可(確認済み)」「出願の検討が先」の3つです。

  • AIの表が空でも、資料は最後まで読む。 基準表にない型は拾われません
  • 図・グラフ・写真の中身は資料で見る。 条件値は図の中にあることが多い箇所です
  • 出願状況は必ず台帳で引く。 出願済みなら問題にならない指摘があります
  • 発明者に確認する。 資料にない周辺の内容が未出願のこともあります

公開してしまった発明について、特許庁は新規性喪失の例外規定(特許法第30条)を案内しています。特許庁のページでは、適用を受けるには出願と同時に適用を受けようとする旨を記載した書面を提出し、出願から30日以内に要件を満たすことを証明する書面を提出する必要があるとされています。例外期間は平成30年の改正で6か月から1年に延長されました。この規定があるから公開してよい、とは読まないでください。 適用の可否と手続は個別の事情によります。

Step10

例外に対処する

起きること対応
資料にない記載を引用してくるその指摘を捨てる。多ければ指示を見直す
「公開して問題ありません」と書いてくるその回の結果を使わず、禁止事項を強める
「これは出願済みと思われます」と書いてくる同上。台帳で引く運用に戻す
1本で指摘が40件を超える基準表に細かすぎる項目が混ざっている
図しかなく本文テキストがない差し戻す。読めないまま「指摘なし」としない
台帳に記録がない技術内容未出願と断定せず、発明者に確認する
APIが応答しない(半自動化)拾った語の一覧を渡し、点検を止めない
Step11

記録を残す

  • 資料の版、AIが返した表の全件(捨てた指摘を含む)、基準表の版
  • 知財担当の判断、判断者、日時、照合した出願番号
  • 公開した日・媒体・公開した内容そのもの(公開した版の資料)

最後の記録が重要です。 特許庁のQ&A集では、権利を有する者の行為で公開された発明が複数あるときは、原則としてそれぞれの公開について例外規定の適用を受ける手続が必要とされています。予稿集への掲載と学会発表で内容が異なる場合、学会発表で公開された発明は予稿集の発明と同一とみなせないことが多いとも示されています。「いつ、どの媒体で、何を出したか」を後から示せる状態が要ります。

月1回、「修正依頼が多い基準番号」と「AIが拾わなかった記載」を集計します。

04実装レベルの3段階

最小構成:生成AIのプロジェクトに基準表と指摘記録を置き、資料を貼って表を出させる / 洗い出しと理由の下書き
半自動化:フォーム送信で Google Apps Script が動き、語の拾い出し・出願番号の照合・Claude API での表作成・スプレッドシート出力を行う / 貼る手間、台帳照合、記録への書き出し
本格構成:上記に加え、共有フォルダの監視、公開記録の自動蓄積、基準表の更新候補を出す集計 / 判断以外の記録と管理

最小構成と半自動化の差が小さい業務です。 本格構成の知財管理システム連携は、利用環境に応じた個別実装が必要です。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
2 名
月間件数
30 件
1件あたり現在時間
40 分
1件あたり導入後時間
14 分
現在  30件 × 40分 ÷ 60 = 20 時間/月
導入後 30件 × 14分 ÷ 60 = 7 時間/月
月間削減時間
13h
削減率
65%
年間削減時間
156h
年間金額換算(時間単価4,000円)
62万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 社外へ出す技術資料が月20本以上あり、公開前の点検を知財担当1〜3名が担っている企業。特許出願を継続していて、出願管理台帳が存在すること。過去の指摘が、メモ程度でも文書で残っていること。
向いていない
  1. 社外発表がほとんどない企業。公開前の点検が月に数本しかない場合。公開してよいかの判断そのものをAIにさせたい場合。未公開の技術情報を外部のサービスに入力することを社内規程が一律に禁じている場合。

07最小構成で試す方法

開発は不要です。

  1. 過去の資料を20本用意する(指摘して直した10本、指摘なしで公開した10本)
  2. 過去1年の指摘から、公開前チェック基準を8区分・30項目書き出す
  3. 生成AIのプロジェクトに、基準表・指摘記録・用語の言い換え表・指示を置く
  4. 伏せ字の範囲を決め、20本を1本ずつ貼って表を出させる
  5. 直した10本で、当時の人の指摘をAIが拾えたかを数える
  6. 公開した10本で、AIが出した指摘の中身を見る

6番目で人の見落としが見つかったら、公開後の対応が要るかを知財部門で検討します。

結果判断
人の指摘の8割以上を拾い、判定の言葉が出ない実務で並行運用に入る
拾えるが、基準外の気づきが多い「細かすぎる指摘をしない」を指示に足す
半分も拾えない基準表の「見るところ」を過去の指摘から書き足す
「問題ありません」「出願済みです」が出る禁止事項を強める。直るまで実務に入れない

08実装時につまずきやすいポイント

問題対策
AIが「公開して問題ない」と書く判定の禁止を明記し、判定の語が出た回の結果は使わない
AIが出願状況を推測する台帳照合は人またはプログラムに固定し、禁止事項に明記する
書き換え案で新しい技術説明を足す書き換えの方向を4つに限定する
図の中の条件値が素通りになる提出フォームに図中テキストの欄を設ける
更新前の基準表で答えるファイル名に日付を入れ、出力に版を書かせる
指摘が多すぎて読まれない細かすぎる項目を外し、確認先ごとに並べる
非推奨のトリガーで組んでしまう公開ドキュメントで非推奨表示と代替を確認する

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 公開前の技術資料、チェック基準、過去の指摘記録。点検の対象そのものが未公開の技術情報です。

  1. 外部AIへの入力可否が、技術の話より先に来る … 未出願の発明や秘密にしている条件値を外部サービスに送ってよいかを、情報管理規程で先に確認します。社内で認められた業務用の生成AIだけを使い、個人アカウントでの利用を禁じてください
  2. 伏せ字にする範囲を決める … 顧客名、共同開発先の名称、未公開の出願番号、発明者の氏名は、貼る前に記号に置き換えます。区分の判定には影響しません
  3. 出願管理台帳はAIに渡さない … 台帳には未公開の出願内容が入ります
  4. 学習利用 … 入力を学習に使わないことが契約で保証されるサービスを選びます
  5. 共同開発先から受け取った資料 … 秘密保持契約の範囲を確認します。相手方の情報は自社の判断だけで公開できません
  6. アクセス権限 … 点検記録には「公開しかけた内容」が残ります。知財部門に絞ります
  7. 自動実行してよい範囲 … 洗い出しまでです。表が空であることを理由に公開してよいことにしないでください

最も気づきにくいリスクは、AIの表に理由が書いてあることで、点検した気になることです。誤りのリスクは出願前の発明の公開と秘密情報の流出で、どちらも取り消せません。

10まず何から始めるか

1週目:公開前チェック基準を30項目つくる

過去1年の指摘を見返し、8区分に整理して「見るところ」「例」「確認先」を埋めます。この作業で、必ず部門間の食い違いが見つかります。 「工程の順序は出してよい」と考えている技術部門と、「出せない」と考えている知財部門が同時に存在します。それを決めることが本体です。

2週目:過去の20本で試す

第8章の手順で試し、AIの表に「公開可」「出願済み」の言葉が混ざっていないかを確かめます。混ざっていたら指示を直してから次に進みます。

3週目:提出のしかたを決める

提出フォームに、媒体・公開予定日・関連する出願番号・図中テキストの欄を作ります。公開の5営業日前までという締切も、ここで決めます。

4週目〜:最小構成で1か月まわす

知財担当2名が、依頼のたびに資料を貼る運用を1か月続け、40分が何分になるかを実測します。AIが拾わなかった記載は基準表に足します。貼る手間が負担になったら、自動点検に進みます。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-09-15/最終更新:2026-09-15
確認した内容情報源確認日
新規性喪失の例外規定(特許法第30条)の手続(出願と同時の書面提出、出願から30日以内の証明書提出)と、平成30年改正で例外期間が6か月から1年に延長されたこと特許庁: 適用を受けるための手続2026-09-15
公開された発明が複数あるときは原則それぞれ手続が必要で、予稿集の掲載より詳細な学会発表は同一とみなせない場合が多いとされていること特許庁: 例外規定についてのQ&A集2026-09-15
不正競争防止法第2条第6項の営業秘密の定義e-Gov法令検索: 不正競争防止法2026-09-15
生成AIにファイルを知識として置き、指示を設定できること(Claude のプロジェクト、有料プランでは検索して使う方式/ChatGPT のプロジェクト/Gemini の Gem/Copilot Notebooks)Claude / ChatGPT / Gemini / Copilot2026-09-15
Apps Script のフォーム送信トリガー(フォーム用とシート用の2種類。常に作成者のアカウントで実行される)Google: インストール可能なトリガー2026-09-15
Power Automate の SharePoint コネクタで「フォルダーにファイルが作成されたとき」が非推奨、推奨される代替が「ファイルの作成時(プロパティのみ)」であることMicrosoft Learn: SharePoint コネクタ2026-09-15

個別の記載を公開してよいかは、この記事では判断していません。 出願の可否、例外規定の適用の可否、営業秘密に当たるかどうかは個別の事情によります。外国への出願を予定している場合の取扱いは確認していません。未公開の技術情報を外部のサービスに送ることの可否は、情報管理規程と取引先との契約によります。利用環境に応じた個別確認が必要です。

広告表現のチェックは [UC-0047]、数値と固有名詞の突合は [UC-0064]、発明届出書の下書きは [UC-0067] で別に扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-0074)についてのご相談はこちらから。

AI活用について相談する
目次