ソフトウェア発明には筐体がありません。三面図や断面図に逃げられないため、出願書類の図面が「カメラとパソコンを一本の線でつないだ絵」一枚だけ、というケースが本当に多い。この絵の問題は見た目ではなく、審査官がクレームの構成要素を一つも図面上で特定できないことです。学習の話なのか推論の話なのかすら読み取れません。
どの図を何枚描くかは、感覚で決めるものではありません。クレームを分解すれば自動的に決まります。方法クレームがあればフローチャート、システムクレームがあればブロック図、学習済みモデルが請求されていれば学習と推論の二枚、画面にかかるクレームがあれば画面線図。本記事では対応表を先に示し、架空の「金属部品の外観検査AI」を題材に四つの例を挙げます。各例には PatentFig AI の生成画面にそのまま貼れるプロンプトを付けます。
クレームの構成要素を一つずつ箱にしたブロック図。符号付き・白黒線画が基本形です。
早見表：クレームの種類 → 図面の種類
| クレームに書かれているもの | 対応する図 | 基本ルール |
|---|---|---|
| 方法のステップ列 | フローチャート | 1ステップ1箱、番号は明細書と一致 |
| システムの「部」「ユニット」 | ブロック図 | 1要素1箱、ラベルはクレーム用語のまま |
| データの変換の連鎖 | データフロー図 | 変換自体が発明点のときだけ |
| 機器間のやり取りの順序 | シーケンス図 | 順序が請求範囲に入るときだけ |
| モード・状態の切り替え | 状態遷移図 | 遷移条件が請求範囲に入るときだけ |
| 機械学習モデル | 学習図＋推論図 | 必ず別図。モデルの符号は共通 |
| ユーザー画面 | 画面線図 | スクリーンショット提出は不可。線画＋符号 |
任意の図を足すかどうかの基準は毎回同じです。その図は、文章の苦手な仕事を代わりにやってくれるか。やってくれるなら描く、飾りなら削る。
例1：方法クレーム → フローチャート
架空のクレーム：
部品の外観検査方法であって、部品画像を取得するステップと、前記部品画像に前処理を施すステップと、学習済みモデルにより欠陥候補を検出するステップと、検出された欠陥候補の欠陥種別を分類するステップと、分類結果と閾値との比較により良品、不良品または再検査に振り分けるステップとを含む方法。
構成のポイント：
- ステップが五つなら箱も最低五つ。クレームにないステップの箱は作らない。
- 図中で S101〜S105 と振ったら、明細書の説明も必ず S101〜S105。審査官が図と文章を往復するときの負担がまるで違います。
- 閾値との比較による振り分けは判断です。ひし形の判断ボックスとして正直に描くこと。この種の振り分けロジックこそ発明の中心であることが多く、長方形に隠すと損をします。
- 従属クレームで追加されるステップは別図で展開。図2が全体の流れ、図3が前処理の内訳、という階層にします。
プロンプト：
JPO・USPTO の白黒線画要件に合う特許用フローチャートを生成してください。方法は金属部品の外観検査:S101 部品画像を取得、S102 前処理を実施、S103 学習済みモデルで欠陥候補を検出、S104 欠陥候補の欠陥種別を分類、S105 分類結果と閾値との比較により良品・不良品・再検査に振り分け。S105 はひし形の判断ボックスとし、良品・不良品・再検査の三つの出口にラベルを付ける。他のステップは長方形、上から下への一列配置、実線黒のみ、グレー・影・色は使わない。
例2：システムクレーム → ブロック図
架空のクレーム：
部品の外観検査システムであって、撮像部と、前処理部と、欠陥検出部と、分類部と、前記分類部に接続された判定部とを備えるシステム。
構成のポイント：
- 「部」を一つずつそのまま箱にし、符号（101、102……）を添える。
- 箱のラベルはクレーム用語のまま。社内で「ふるい」と呼んでいても、箱には欠陥検出部と書きます。社内の呼び名は本人たちには自明でも、審査官には暗号です。
- 箱と箱を結ぶ線には意味を持たせる。画像データの流れと制御信号の区別をつけます。
- 社内プレゼン用の、ロゴやグラデーション入りの構成図は流用不可。特許図面は白黒線画です。
プロンプト：
特許用のシステムブロック図を白黒線画で生成してください。システムは部品外観検査システムで、構成は撮像部 101、前処理部 102、欠陥検出部 103、分類部 104、判定部 105 の五つ。画像データは 101 から 102、103、104、105 の順に流れる。各構成要素は実線の長方形で描き、枠内に名称と符号を記載、要素間は矢印付き実線でデータの流れを示す。色・影・アイコンは使わない。
例3：機械学習 → 学習図と推論図は別々に
架空のクレーム（従属項）：
前記学習済みモデルは、良品および不良品のラベルが付された部品画像を教師データとしてパラメータを更新することにより生成される。
構成のポイント：
- 学習フェーズ（教師データの収集、ラベル付け、パラメータ更新）と推論フェーズ（製造ラインの画像が検出・分類・判定を通過する経路）は別図にします。一枚に混ぜると、クレームが学習方法を保護したいのか推論の実行を保護したいのか、図面からは区別できなくなります。
- 同じモデルは両方の図に登場させ、符号は共通にします。学習図で 201 なら推論図でも 201。読む側は、同じものが二つの場面で違う役割をしていると迷わず理解できます。
- 学習側にしか出ない構成（教師データ格納部など）は 200 番台に寄せ、オンライン経路の 100 番台と混ぜないこと。
プロンプト：
特許用の機械学習・学習フェーズのフローチャートを白黒線画で生成してください。流れ:良品・不良品のラベル付き部品画像を教師データとして収集 202、教師データを検査モデル 201 に入力して予測を計算、予測とラベルの誤差に基づき検査モデル 201 のパラメータを更新 203、終了条件をひし形の判断ボックスで判定し、満たさなければ学習を継続。長方形はステップ、ひし形は判断、全構成要素に符号を付け、上から下への配置、実線黒のみ。
推論図も同じ要領で別途生成し、モデルの符号は 201 のまま変えないでください。
学習と推論を別図に分け、同じモデルには同じ符号を使うのが機械学習出願の基本です。
例4：状態遷移図 — モード切り替えが請求範囲にあるとき
架空のクレーム（従属項）：
前記システムは通常検査モードと追加学習モードとを有し、再検査に振り分けられた部品画像の件数が所定数を超えた場合に追加学習モードへ移行する。
構成のポイント：
- モード間の遷移条件が請求範囲に入っているなら、状態遷移図の出番です。状態を丸または角丸の枠で、遷移条件を矢印上のラベルで描きます。
- 文章で書くと数段落かかる遷移条件の組み合わせが、一枚で伝わります。逆に、モードの切り替えがクレームにないなら、この図は不要です。
プロンプト：
特許用の状態遷移図を白黒線画で生成してください。状態は二つ:通常検査モード 301 と追加学習モード 302。遷移条件:301 から 302 へは「再検査に振り分けられた部品画像の件数が所定数を超えた場合」、302 から 301 へは「パラメータ更新の完了後」。状態は角丸の枠、遷移は矢印付き実線とし、矢印の上に遷移条件のラベルを記載する。実線黒のみ、色・影は使わない。
提出前の検算：構成要素の対応表
図が揃ったら、独立クレームを構成要素ごとにばらし、「構成要素 → 符号 → 登場する図番号」の三列の対応表を作ります。
| クレームの構成要素 | 符号 | 登場する図 |
|---|---|---|
| 撮像部 | 101 | 図1 |
| 前処理部 | 102 | 図1、図3 |
| 欠陥検出部 | 103 | 図1、図2 |
| 判定部 | 105 | 図1、図2 |
| 検査モデル | 201 | 図4、図5 |
| 振り分けステップ | S105 | 図2 |
空欄が出たら、図が足りないか、その要素の書き方が曖昧かのどちらかです。図に描けない要素は明細書でも説明しきれていないことが多い。逆方向の点検も忘れずに。図の中にあるのに表と明細書で見つからない符号は孤児符号で、いちばん安く直せるミスです。表の下敷きには patentfig.ai/ja/resources の符号台帳テンプレートが使えます。提出前には Figure Checker で余白と符号の整合を一度通しておくと、目視で見落とす孤児符号を機械的に拾えます。
法的な注意
明細書と図面がクレームを支えられているか、という観点は最後まで手放さないでください。どこまで描けば支えたことになるかの線引きは案件ごとの判断で、そこは弁理士の領分です。作る側にできるのは、対応表を空欄なしで渡すところまで。形式面は特許庁の特許・実用新案審査基準が公開されており、国際出願を視野に入れるなら PCT規則11 が図面の形式基準になります。
よくある質問
フローチャートの箱は、クレームのステップと一対一でなければいけませんか？
独立クレームの各ステップに対応する箱があることが最低ラインです。箱が多い分には構いません。一つのステップの内部を別図で展開するのは普通のやり方です。問題は逆で、クレームにあるステップが図のどこにもないのは欠落です。
画面のスクリーンショットをそのまま図面にできますか？
できません。色や装飾を落とした白黒線画に変換し、請求範囲にかかる画面領域に引出線と符号を付けて提出します。
ソフトウェア特許の図面は普通何枚くらいですか？
クレームが決めるので固定の枚数はありません。方法・システム・画面でそれぞれ一〜二枚、モデルが請求されていれば学習と推論で二枚追加、という積み上げで五〜八枚に落ち着くことが多い。枚数が目標なのではなく、全構成要素に指せる図があることが目標です。
シーケンス図はいつ必要ですか？
機器間のメッセージの順序（たとえばエッジ端末とクラウドの間のタイムアウト処理）が請求範囲に入っているときだけです。順序が発明の肝でないなら見送って構いません。
クレーム文からの下書きはここから試せます：patentfig.ai/generate。出てきた図は、必ず対応表で検算してから弁理士に渡してください。