patent-application-creator

特許出願作成スキル

ユーザーが持っているものがコードベースでも、発明開示書でも、断片的なメモでも、特許出願までの一連の取り組みを実行し、出願準備が整った仮出願用パッケージを作成するか、作成できない理由を根拠と証拠を示して説明します。

このワークフローは、実際に運用して改良されました（2026年7月、本番コードベースを対象とした一連の取り組み）。以下の各フェーズは、その取り組みで省略した際に損失が生じたために設けられています。

契約事項

• 正直な結論こそが成果物です。「ここには新規性の基準を満たすものはなく、各候補を否定する先行技術はこれです」という結論も、失敗ではなく成功です。「特許を取得できる可能性はあるものの、費用に見合わないため、出願しないか、防衛的公開を行うべきです」という結論も同様です。弱い候補を誇張してはいけません。
• **この取り組みでは、出願の成功だけでなく、ユーザーの資金も守ります。**このツールの対象となる人々は、商業的価値のない特許のために、技術的に完璧なパッケージを用意する余裕はありません。費用に見合うかどうかは、コストのかかるフェーズに入る前に問い、請求項を狭めるたびに再確認します。最後になって「小さな防壁」にすぎないと判明するような取り組みでは、すでにユーザーの予算を誤った問いへの回答に費やしていることになります。
• **機械的なチェックを関門とし、人間が検証します。**信頼度が低いと判定された自動検出結果はすべて手動で検証します。また、問題がないとする場合は、実施したチェックと省略したチェックの両方を明示します。
• **日付は重要です。**先行技術は継続的に公開されているため、調査中に見つかった新たな脅威を記録し、パッケージに記載します。仮出願では、長く磨き込むより、早く出願する方が有利です。
• **AIは決して発明者ではありません。**発明者はユーザーです。AIは情報を抽出し、検索し、草案を作成し、検証します。保護されるのはユーザーの創作物です。

フェーズ 0 — 受付（あらゆる素材）

大まかな依頼をそのまま受け付けます。素材がコードベースであれば、発明開示書の提出を求めてはいけません。発明の抽出はフェーズ 1 の役割です。確認するのは、素材から推測できない情報だけにします。発明者の氏名と、内容がすでに公開または販売されているかどうか（法定期限に関わる日付）です。その後、発明者自身の公開実績（リリース済み製品、デモ、公開リポジトリ、マーケティングページなど）を監査し、最初の開示日を記録します。発明者自身による開示は米国の猶予期間の起算となり、外国での権利を直ちに失う原因になることもあります。この確認は、草案の作成後ではなく、作成前に行います。

フェーズ 1 — 発明の抽出

機能ではなく、具体的な技術的メカニズムを探します。コードベースの場合は、各サブシステムにつき 1 人の担当者を割り当てて調査します。候補は、（a）具体的で実装済みであること、（b）技術的な問題を解決していること、（c）非慣用的であると議論の余地があること、を満たす必要があります。教科書的な認証、CRUD、キャッシュなどは対象外です。各候補について、メカニズム（何をするかではなく、どのように行うか）、証拠の場所、解決する問題、従来の代替手段をどう上回るか、その違いがなぜ非自明なのかを記録します。

次に、以下の基準で候補を選別します（却下／追求）。

• 第 101 条のスクリーニング：請求、商取引、人間の活動の組織化に関する主題は、工夫の有無にかかわらず Alice 判決に基づく拒絶を受けるため、優先度を下げます。
• 競合の激しい分野のスクリーニング：スレッドプール、再試行、分散同期、テスト手法については、通常とは異なる工夫がなければ、却下を求めます。
• 統合のスクリーニング：複数の候補に共通する原理を 1 つ探します。複数の実施形態を含むシステムの請求項は、散在する小規模な請求項より有力です。

フェーズ 1-H — 履歴のマイニング（素材が git リポジトリの場合）

現在のコードからは何が存在するかが分かります。一方、履歴からは、それが何を打ち破ったのか、どれほど困難だったのか、いつ実現したのかが分かります。また、HEAD を読むだけでは決して見つけられない仕組みも含まれています。放棄されたブランチで消えてしまった仕組みです。頻繁に作り直す発明者にとって、放棄されたブランチこそが最も明確な発掘場所です。マージされなかった仕組みはデプロイされていないため、開示の時計は動いておらず、外国の権利が完全に残っています。 素材に git 履歴がある場合は、フェーズ 1 のコードマイニングと並行してこの調査を実施してください。

この絞り込み手順は、808 コミット、9 ブランチ、92 件の PR 参照を持つ実際のリポジトリで検証済みです（エージェントのトークン約 250 万、実時間で数分）。

1. すべてを列挙します。 ミラークローンを作成し、+refs/pull/*/head も取得します。git rev-list --all が全体集合です。制限を正直に明記します。ホストが提供するのは参照から到達可能なコミットだけです。強制プッシュで消された履歴は失われているため、記録に示すのは「ホストに現在残っているもの」であり、「これまで存在したすべて」ではありません。
2. patch-id でまとめます。 git rev-list --all | git diff-tree --stdin -p -r | git patch-id --stable を実行します。数百のブランチにまたがるチェリーピックやリベースも、それぞれ 1 つのエントリにまとめられます。処理コストはブランチ数ではなく、固有パッチの数に応じて増加します。（--no-commit-id は渡さないでください。パッチの帰属を示すコミット行が patch-id に必要です。）
3. 機械的にトリアージし、名前付きのバケットに分類します。 ノイズとなる件名（依存関係、ドキュメント、マージ）、ロックファイルやバイナリのみのパッチ、小さな差分を除外し、除外したものはすべて件名を記録したバケットに入れます。カバレッジは算術的に一致させます。全体集合 = 読み込んだもの + 除外したもので、突き合わせ可能でなければなりません。
4. 残ったものをすべて読みます。 パッチをまとめて処理します（エージェント 1 つあたり約 30 件、差分の上限は約 7KB。上限を設けたことも明記します）。各読者には、パッチごとに判定を 1 つ返し、さらに読んだパッチ数も報告するよう求めます。バッチごとに件数を突き合わせます。「MECHANISM（仕組み）」か「ROUTINE（定型作業）」かを判定し、「差分によってどの従来の方法が置き換えられたか」も記録します。読者には明確に指示してください。放棄された作業や未完成の作業を決して格下げしないこと。狙うべき対象は、放棄された創意工夫です。
5. クラスタリングして所在を特定します。 多数のコミットにまたがる同じ仕組みは、1 つのクラスタとして扱います。候補ごとに git branch --contains を実行し、デフォルトブランチへの到達可能性を調べたうえで、その仕組みが SHIPPED コードに移行しているかを確認します（ブリッジブランチによって「取り残された」コミットの内容が別の場所で生きている場合があるため、ブランチの構成ではなく、デプロイ済みのソースを確認してください）。「出荷されたものすべてに存在しない」場合に限り、開示の時計が動いていないというラベルを付けられます。
6. 何も見つからなくなるまで、敵対的な視点で再調査します。 1 つの視点では見落としが生じます。フェーズ 1 で何を誤って判定したかを問うプロンプトを使って ROUTINE の山を再読し、新しい発見がなくなるまで繰り返します。

履歴からは、HEAD だけでは分からない情報も得られます。差分には置き換えられた従来の代替手段が示されます（フェーズ 1 で最も埋めにくい項目です）。ブレークスルーに至るまでの一連の失敗は、非自明性を示す客観的な証拠です。また、コミットの日付と作成者は着想の記録になります。残った候補は、他の候補と同様に、フェーズ 1 のトリアージ基準（worth-it を含む）にかけてください。

フェーズ 2 — 先行技術：あらゆる情報源を、敵対的に調査する

ソフトウェアでは、特許だけでは不十分です。決定的な先行技術は通常、 製品、オープンソース、標準規格、論文に存在します。以下をすべて調査します。

1. 特許：search_patents_google（請求項を含む、全文の世界規模検索。すべての単語が一致する必要があるため、特徴的な語句から始め、分類内に絞り込むには CPC=G06F16/00 のような語句を追加します）。詳細を読むには Google Patents のページを使用します（無料）。SerpApi キーがない場合の代替手段： search_patents_bigquery と search_patents_by_cpc_bigquery ですが、ここでキーワード検索を行うと約 341 GiB がスキャンされます（約 2 ドルで、無料利用分の 3 分の 1 に相当します）。
2. 非特許文献：主張の各クラスターごとに、敵対的なウェブ調査エージェントを並行して稼働させ、それぞれの主張を「潰す」よう指示します。対象は製品（既存の執筆・コーディングアシスタントは実際に何をするのか）、オープンソース（コードを読む）、標準化団体、arXiv、エンジニアリングブログです。
3. すべてのエージェントに、項目ごとの判定を返すよう指示します：「こちらにあって、これにはないもの」または「先取りあり」。結果を「クリーンな領域」（独立請求項に記載する）、「キルゾーン」（単独で請求しない）、「必読請求項資料」（出願前に弁護士が読むべき参考資料）、「未解決の手掛かり」（ボットによってブロックされたページなど。ユーザーにエスカレーションし、黙って除外しない）に分類して集約します。

言葉遣いの規律（譲れません）。 調査結果が裏付けるのは、日付入りの要素ごとの対比表を根拠とした、「[調査した情報源] において [日付] 時点で先取りは見つからなかった」という形式の記述だけです。「誰も」「先行技術は存在しない」「調査済みで問題なし」「生き残る」といった表現を事実として書いてはいけません。エージェントによるリポジトリの確認は進化し続けるコードベースのスナップショットであり、数週間後に再確認すれば矛盾することがあります。また、切迫した状況で誤りやすい日付に関するルールがあります。第三者がすでに公開した先行技術に、後から先んじることはできません。 すでに公開されているものは、猶予期間の有無にかかわらず、後のあらゆる出願に対する先行技術となります。出願を急ぐべきという議論が当てはまるのは、まだ公開されていない開示に限られます。

判断ゲート：クリーンな領域を持つ候補がなければ、ノーゴーレポート（候補、潰す根拠となる参考資料、候補ごとの理由）を作成して終了します。このレポートが成果物です。その後、生き残った各候補について、調査後の範囲で投資価値を再評価します。クリーンな領域は常にフェーズ 1 の候補より狭くなります。問うべきなのは、縮小した防護範囲でも競合他社に何らかのコストを強いるかどうかです。明白な代替案で回避できる候補も、ノーゴーレポートに含めます。その際は設計回避策を明記し、防御的公開という代替案（ほぼ無料で永久に有効となり、同じ仕組みに関する後発の第三者特許を無効化します）も記載します。

フェーズ 3 — クレームを先に作成する

まずクレームを作成し、その後に明細書を作成します。クリーンな先行技術調査の結果に基づいてクレームを定めます。

• 各独立クレームの根幹となる限定は、調査でどこにも見つからなかった要素でなければなりません。単独では見つかった要素は従属クレームに入れます。
• 正しい形式は「クレーム N に記載の方法であって、…」です。省略形は使わないでください（依存関係の追跡には解析ツールが、審査には審査官が必要とします）。
• 用語を統一します。「a/an」で導入し、同一の名詞句を使って「the」で参照します。
• 既知の先行技術との差異は、容易にできる範囲で明示します（たとえば、最も近い先行技術が抑制を時間経過で解除する場合は、「経過時間によるものではない」と記載します）。
• 狭まっていく権利範囲を追跡します。 差異の明示や限定する補正を行うたびに（ここで、さらにフェーズ 5 の攻撃的レビュー後にも）、クレームは設計回避されやすくなります。攻撃的レビュー後に最終的なクレームの形が定まったら、実際に残った内容に対して、価値があるかどうかの最終判定をもう一度行います。判定（設計回避にかかるコスト、検出可能性、特許出願か防御的公開かの推奨）をパッケージの README に記録し、ユーザーが、想定していた特許ではなく、実際に取得できる特許について判断できるようにします。

次に明細書を作成します。技術分野、背景技術（課題を技術的に記述）、要約（独立クレームごとに 1 段落）、図面の簡単な説明、参照符号を付した全ての実施形態を網羅する詳細な説明、実施例、および変形例の段落（範囲を広げ、任意のモデル、任意の類似度指標、例示的なしきい値を含める）を記載します。明細書には各クレーム用語を逐語的に記載する必要があります。サポートチェッカーがこれを検証します。

ソースコードで検証済みのクレーム（必須）。 全てのクレームの全ての限定は、採掘エージェントの要約でも、古くなっている可能性のあるヘッダーコメントでもなく、実装そのものを開いてコードを確認し、検証しなければなりません（実際の取り組みで、コントラクト文書には最も近い項目への移動が記されていた一方、その下の実行コードには曖昧さを理由に拒否するゲートがありました。要約に基づいて作成されたクレームは、明細書と矛盾する形で誤っていました）。クレーム、明細書、図面に記載すべき内容を最終的に判断する基準は実施例です。それら全てで同じアルゴリズムを記載しなければならず、異なる場合は、それぞれを別個の実施形態として明示する必要があります。実装にない動作をクレームしてはいけません（コードが実行しない「保存型プランの有効な結果」への再分類は、新規事項として拒絶を待つだけです）。

終端状態の網羅性。 決定論的な終了、再試行回数の上限、または結果の保証を主張する明細書では、全ての終端状態と全ての予算遷移を列挙しなければなりません。機械的な試行枯渇やグローバルな超過時の最終防止策など、目立たないものも含めます。図には全ての分岐を記載し、各エッジにラベルを付けなければなりません。

図面：システム図には create_block_diagram を使い、明細書と一致する番号付きコンポーネントを記載します。独立クレームごとの決定分岐には、手書きの DOT を使って render_diagram で図を生成し、エッジに「はい／いいえ」のラベルを付けます（create_flowchart はエッジにラベルを付けません）。全てのノードに参照符号を付けます。

フェーズ 4 — 機械的な検証ループ（問題がなくなるまで反復）

1. patent-creator config set PATENT_ENABLE_ANTECEDENT_CHECK 1 — 先行詞チェックはオプトイン方式ですが、キャンペーンでは必ず実行しなければなりません。
2. すべてのクレームに対して review_patent_claims を実行します。実際の問題（形式、用語の不一致）を修正します。残った信頼度 LOW のフラグはそれぞれ手動で検証し、判定を記録します。この手動確認もワークフローの一部であり、省略できません。
3. review_specification（クレーム＋明細書）を実行し、重大な問題がゼロになるまで反復します。フラグが立ったクレーム要素はすべて、文言を一切変えずに明細書に組み込みます。
4. check_formalities（要約は50～150語、タイトルの制限、各セクション）を実行します。

検証スタンプにはコンテンツハッシュが含まれ、編集すると無効になります。 記録するすべてのチェック結果には、検証対象となった成果物の正確なテキストの SHA-256（または同等のハッシュ）を記載しなければなりません。その後の編集（クレームを1つ追加する、文を1つ変更するなど）によって、その成果物に付与されたすべてのスタンプが無効になります。パッケージ化する前にチェックを再実行してください。検証後に編集された成果物について、README に「検証済み」と記載することは、パッケージに含まれ得る虚偽の中で最も有害なものです。レビュー担当者がそれを見つければ、ほかのすべての内容も信用しなくなるからです。（これはキャンペーン自体の主題が AI スキャンに適用する、入力フィンガープリントの規律と同じです。自分自身にも適用してください。）

フェーズ 5 — レッドチームは1つではなく2つ

5a. 敵対的な審査官による攻撃パス（クレーム）。 敵対的なエージェントを起動し、USPTO の審査官として最終クレームに反論させます。最も近い先行技術文献を調査で特定しておき、最も有力な新規性欠如（102）の主張、各限定事項に対応する文献と組み合わせる動機を示した最も有力な自明性（103）の組み合わせ、そして Alice に基づく（101）攻撃と、それに対する技術的解決策の反論を用意させます。攻撃が成立した場合は、クレームを限定するか、反論できなかった要素を従属クレームに移します。そのうえで、変更したクレームについてフェーズ 4 を再実行します。

5b. パッケージのレッドチーム（成果物全体）。 クレームを攻撃するだけでは不十分です。クレームが完璧でも、パッケージが出願に適さないことがあります。まず、決定的ゲートとして、組み立てたディレクトリに対して check_package を実行します。このチェックは、すべてのコンテンツハッシュ検証スタンプを再計算し（記録済みのチェック後の編集は重大な失敗です）、「N claims」というすべての記載とクレーム数を照合し、ドラフトの印が付いた箇所の近くに出願準備完了を示す表現があれば警告し、出願用コピー内の注釈を検出し、日付の妥当性を確認します。レビュー担当者の労力を費やす前に、重大な問題をすべて修正してください。次に、組み立てたパッケージのすべてのファイル（それ以外は何もなし）を、キャンペーンの背景をまったく知らない新たな敵対的レビュー担当者に渡し、README、クレーム、明細書、図面の間の内部矛盾、成果物自体と矛盾する検証済みとの記述、編集より前の日付のスタンプ、日付の誤り、出願書類に含めてはならない戦略上の注釈、先行技術に関する広範な断定、裏付けのないクレーム文言を探させます。パッケージのレッドチームレビューに合格するまで、出願準備が整ったとは記載してはなりません。（実際のキャンペーンでは、クレームを攻撃して強化したパッケージが、まさにこのような新鮮な視点でのレビューによって問題を指摘されました。README に「検証済み」と記載されていた一方で、「まだコンプライアンスチェックを受けていない」という古いヘッダーが残っており、記録されたチェック後にクレームが追加され、3つの成果物がそれぞれ異なる3つの照合アルゴリズムを説明していました。クレームのレッドチームでは、そのどれも検出できませんでした。いずれもクレームの問題ではなかったからです。）

フェーズ 6 — パッケージ

作業用コピーと提出用コピーは別ファイルであり、提出用コピーは機械的に生成します。 提出書類には、クレームと開示文のみを含めます。角括弧付きの戦略メモ、チェッカーのスコア、「先行技術との比較」に関するコメント、次のステップのセクション、制限戦略は一切含めません。背景説明では、先行技術について断定的な認定をしません（「発明者に知られていた」という表現を使い、「Xを行うシステムは存在しない」とは書きません）。スクリプトで作業用コピーから不要な内容を削除して提出用コピーを生成し、差分を確認して、クレーム／開示文以外が残っていないことを確かめます。

提出用ディレクトリには、次のものを含めます。明細書とクレーム（提出用コピー）、図面（Patent Center の要件を満たす PDF に変換済みであること。レターサイズ／A4、フォント埋め込み、変換後の目視確認を実施すること。ブラウザーから SVG を印刷するのは品質管理ではありません）、SB/16 表紙のデータ（発明者の居住地、連絡先住所）、申請する場合はマイクロエンティティ認証（注：総所得を基準にする場合も、小規模事業体の適格性、カウント対象となる出願の上限、所有権を持つ者の適格性が必要です）、およびプロ・セの仮出願の手順、12 か月の実用特許出願期限、必ずクレームと照合して読むべき一覧、将来の弁護士レビューに向けた未解決の手がかりを記載した README。パッケージの性質を明確に記載します。これは人間による法的レビューを迅速に進めるために作成した仮出願であり、その代わりになるものではありません。また、検証状況はコンテンツハッシュ付きのスタンプで示し、「検証済み」という語だけで示してはいけません。

このワークフローで防ぐべき失敗

• 発明の内容がコードにあるのに、開示面談を鵜呑みにする。
• 特許文献だけを対象に先行技術を調べる（致命的な引用例はたいてい製品です）。
• 調査で見つかった要素をクレームする（従属クレームに入れるか、断念します）。
• 重要なチェックが黙って無効になっているのに、「100% 準拠」と報告する。
• 明細書でクレーム用語を言い換える（サポートの欠落は審査過程で明らかになります）。
• 公開競合に先を越されるまで磨き続ける（日付のプレッシャーは現実のものです）。
• 正直に見送りと判断する代わりに、弱い出願を提出する。
• チェック後に編集された成果物について README に「検証済み」と記載する（コンテンツハッシュのないスタンプは、いつ発覚してもおかしくない嘘です）。
• ソースではなくエージェントの要約や、実行可能な本体ではなく古いヘッダーコメントからクレームを作成する。
• クレーム、明細書、図面で、同じアルゴリズムの異なるバージョンをそれぞれ説明する。
• 実装にない動作を説明するクレーム文言を使う。
• すべての終端状態を列挙せずに、「決定論的な終了」を主張する。
• すでに公開済みの先行技術を理由に「Xより先に出願せよ」と急かす（追い越すことはできず、対処できるのは将来の先行技術だけです）。
• 特許庁に提出する書類に、戦略に関するコメント、チェッカーのスコア、新規性の絶対的な断定を残す。
• クレームだけを攻撃し、組み立てたパッケージ全体を一度も検証しない。
• クレームが特許取得可能であることの証明に予算を使い果たし、その結果できる防御範囲を所有する価値があるかどうかを一度も問わない。その価値はトリアージで問い、調査によって対象範囲が絞られたときに再度問い、攻撃パスによってクレームが絞られたときにも改めて問い直します。