| name | patent-writer |
| description | 発明内容が固まった後の書類作成・編集フェーズ専用。JPO様式準拠の特許明細書ドラフトを作成し、三位一体クレーム・AI発明記載・明細書レビューに対応。「特許明細書を書いて」「クレームを書いて」「請求項を作って」「明細書をレビューして」「従属項を追加して」「要約書を書いて」などで発動。構想段階や先行技術調査は patent-coach を使う。 |
| metadata | {"version":"2.2.0","tier":"stable","category":"research","tags":["patent","jpo","claims","specification"]} |
Patent Writer
日本特許庁（JPO）様式に準拠したソフトウェア・AI発明の特許明細書を作成するスキル。
インタラクティブヒアリング（前提確認）
作業開始前に以下のフローで発明の全体像を引き出す。
ヒアリングフロー
ラウンド1: 発明の概要把握
→ 「まず1分でこの発明を説明してください。どんな技術で、何が新しいですか？」
→ ユーザーの回答を聞いて大枠を把握
ラウンド2: 詳細深掘り（下記ヒアリングシートを使用）
→ 7カテゴリの構造化質問で情報を補完
→ 不明点・曖昧点のみ追加質問する
発明ヒアリングシート（構造化質問リスト）
【技術分野】
- どのような技術分野か（Webアプリ・API・AI/ML・クラウドサービス・組み込みソフト等）
- 使用言語・フレームワーク・プラットフォームは？
- 主な動作環境は（クラウド/オンプレ/エッジ/モバイル）？
【従来技術と課題】
- 現状（従来）どのように解決されているか？
- その方法のどこが問題か？（定量的に：「〜が〇〇%遅い」「〜にかかるコストが〇円」等）
- なぜ既存手法では解決できないのか？
【解決手段（コア）】
- 何が新しいのか（1行で言うと）？
- どのように動くか？（入力→処理→出力を1ステップずつ説明）
- その仕組みの「ミソ」はどこか？
【効果】
- 何がどう改善されるか？（数値・ユーザー体験・コスト・速度等）
- 従来技術と比較した定量的な改善値は？
- 誰が・どのシーンで利益を得るか？
【実施例】
- 代表的な使い方シナリオを1つ（入力→処理→出力の流れ）
- 変形例・応用例があれば1〜2件
【ハードウェア資源】
- 動作するハードウェアは何か（サーバ・PC・スマホ・組み込みデバイス等）？
- CPU・メモリ・ストレージ・通信インタフェースの特記事項は？
- クラウド/オンプレの区別、使用するサービス（AWS・GCP・Azure等）は？
【図面候補】
- どんな図があるか・作れるか（フロー図・ハードウェア構成図・シーケンス図等）？
- 最も発明を代表する図（選択図）はどれか？
【先行技術（既知文献）】
- 知っている関連特許番号はあるか？（例: 特開2020-123456、US10,123,456B2）
- 社内の類似技術・先行出願はあるか？
- 参考にした論文・標準規格・OSSはあるか？
- 競合他社で類似の特許を取得していると思うものはあるか？
ヒアリング完了条件
以下8項目がすべて埋まればヒアリング完了:
特許適格性の確認（必須）
明細書作成前に必ず確認する。ソフトウェア発明が「自然法則を利用した技術的思想の創作」に該当するか確認する。
発明に該当する条件（以下のどちらかを満たすこと）：
- (ⅰ) 機器等（センサ・ロボット・制御装置等）に対する制御・制御に伴う処理を具体的に行うもの
- (ⅱ) 対象の物理的・電気的・化学的・生物学的性質（技術的性質）に基づく情報処理を具体的に行うもの
発明に該当しない典型例：ビジネスルールのみ・ゲームルールのみ・数式の計算のみ・人の精神活動のみ
対応策: ソフトウェアとハードウェア資源（CPU・メモリ・センサ等）の協働を明細書で明示すること。
詳細要件ガイド → references/software-patent-requirements.md
明細書の基本構成
日本特許庁の様式に従い、以下の順序で記載する:
【書類名】特許願
【発明の名称】○○○
【特許請求の範囲】
【請求項1】（独立項）
【請求項2】（従属項）
...
【明細書】
【技術分野】
【背景技術】
【先行技術文献】（任意）
【発明が解決しようとする課題】
【課題を解決するための手段】
【発明の効果】
【図面の簡単な説明】（図面がある場合）
【発明を実施するための形態】
【要約書】
【要約】
【選択図】
各セクションの記載方針
特許請求の範囲（クレーム）
最重要セクション。先にクレームを確定させてから明細書本文を書く。
- 独立項（請求項1）: 発明の最広クレーム。必須構成要件のみを記載し、不要な限定は避ける
- 従属項: 独立項に特徴を付加して権利範囲を絞る。
請求項1に記載の○○において、 で始める
- 一文で完結させる。句点（。）は使わずに読点（、）で構成要件を繋ぐ
- 機能的クレーム（〜するための手段）は限定解釈されるリスクがあるため慎重に使う
クレーム文例 → references/claims.md
クレーム作成詳細ガイド → references/claims-guide.md
明細書構成詳細 → references/structure.md
技術分野
1〜2文で簡潔に。IPC（国際特許分類）を意識した表現を使う。
ソフトウェア向けIPCコードの例:
G06F: 電気的デジタルデータ処理（汎用ソフトウェア処理）G06Q: 管理・商業・金融・経営・監督・予測目的のデータ処理システムG06N: 機械学習・ニューラルネットワークG16H: 医療情報学
記載例: 「本発明は、G06F 16/00（データベース管理）に属し、特に〜に関する。」
背景技術
- 従来技術を客観的に説明する。自社の出願・公知文献を引用しても良い
- 誇張や憶測は避ける
- 具体的な公知文献がある場合は
【先行技術文献】 セクションを設けて引用する
発明が解決しようとする課題
背景技術の問題点を明確に記述する。クレームの課題と対応するよう一貫性を保つ。先行技術の限界を明示しておくと、後の拒絶理由通知への反論の基盤になる。
課題を解決するための手段
クレームの構成要件を言い換えて説明するセクション。クレームと乖離しないよう注意する。
発明の効果
クレームの構成要件から生じる効果のみ記載する。数値付き効果（精度・処理速度・コスト等）を記載し、先行技術との定量的差分を示せる根拠を埋め込む。クレームに記載のない構成から生じる効果は記載しない。
発明を実施するための形態
- 図面の符号を使って具体的な実施例を詳細に説明する
- 複数の実施形態がある場合は「第1実施形態」「第2実施形態」と分ける
- クレームより広い・狭い実施例両方を記載してサポート要件を満たす
要約書
- 400字以内を目安
- 課題・解決手段・効果を簡潔に記載
- 選択図（最も発明を代表する図）の番号を記載する
各セクション詳細ガイド → references/description-guide.md
三位一体クレームの構成
システム・方法・プログラムの三つを必ず検討する。侵害者の行為態様（販売/実施/配布）に対応した権利行使が可能になる。
| クレーム種別 | 特許法カテゴリ | 権利行使の対象 |
|---|
| システム（装置）クレーム | 物の発明 | システムの製造・販売・使用 |
| 方法クレーム | 方法の発明 | 処理の実施（SaaSに有効） |
| プログラムクレーム | 物の発明 | プログラムの配布・ダウンロード販売・API提供 |
システム（装置）クレームの書き方
「〜部」で機能ブロックを記述。末尾は「〜システム」「〜装置」「〜サーバ」で終わる。
【請求項1】
〔機能ブロックA〕する取得部と、
〔機能ブロックB〕する処理部と、
〔機能ブロックC〕する送信部と、
を備える〔発明の名称〕。
※「一以上のプロセッサと、メモリとを備えるシステムであって、前記プロセッサが〜として機能するシステム」という形式も広いクレームになり有効。
方法クレームの書き方
「コンピュータが、〜するステップ」の形式で処理フローを列挙。末尾は「〜方法」で終わる。
【請求項2】
コンピュータが、〔処理A〕するステップと、
コンピュータが、〔処理B〕するステップと、
コンピュータが、〔処理C〕するステップと、
を含む〔発明の名称〕方法。
プログラムクレームの書き方
「コンピュータを〜として機能させるためのプログラム」の定型形式を使う。機能は「〜手段」と記す。
【請求項3】
コンピュータを、
〔機能A〕する〔手段A〕、
〔機能B〕する〔手段B〕、
〔機能C〕する〔手段C〕、
として機能させるためのプログラム。
機能的クレームの注意点
「〜するための手段（ミーンズ・プラス・ファンクション）」は明細書記載の実施例に限定解釈されるリスクがある。システムクレームでは「〜部」を使い、プログラムクレームでは「〜手段」を使い分けることで明確性を確保する。
AI・機械学習発明
学習済みモデルクレーム（データ構造クレーム）
「コンピュータに〜させるための学習済みモデル」として記載し、ネットワーク構造・学習条件の特徴を含める。単なる数値データにならないようモデルの構造的特徴をクレームに記載すること。
【請求項X】
コンピュータに〔タスク名〕を実行させるための学習済みモデルであって、
〔入力データ形式〕を入力として受け付ける入力層と、
〔処理の特徴（畳み込み・注意機構等）〕を行う中間層と、
〔出力形式〕を出力する出力層と、
を備え、
前記中間層の重みパラメータが、〔特徴的な学習データ・学習条件〕を用いて学習されたものである、
学習済みモデル。
学習方法クレームと推論方法クレームは分けて記載
- 学習方法クレーム：学習データ構成・損失関数・最適化手法の工夫を特徴として記載
- 推論方法クレーム：前処理・モデル適用・後処理（閾値処理・出力解釈）の工夫を特徴として記載
AI発明のクレームに含めるべき要素:
- 訓練データの特徴（形式・ラベル付け方法・データ構成の工夫）
- モデル構造の特徴（特定の層構成・スキップコネクション・アテンション機構等）
- 学習条件の特徴（損失関数の工夫・正則化手法・ハイパーパラメータの特定値）
AI発明の明細書記載必須事項（実施可能要件）
以下を記載しないと特許法第36条第4項（実施可能要件）違反になりうる：
- 学習データの構成・フォーマット・ラベル付け方法・データ数の目安
- ネットワーク構造（層数・ユニット数・接続方法）の典型例
- ハイパーパラメータ（学習率・バッチサイズ・エポック数）の典型値
- 評価指標と達成した性能の具体的数値（「〜%の精度を達成」）
- フローチャート（学習フロー・推論フロー）をクレームのステップと対応付けて記載
進歩性の論証に備えた記載
容易想到とされやすいケース（進歩性なしと判断されやすい）：
- 汎用機械学習手法（DNN等）を既知問題へ適用しただけ
- APIやサービスを単純に組み合わせたビジネスロジック
進歩性が認められやすいケース：
- 学習データの特異な選択・前処理が予測外の汎化性能をもたらす
- 従来手法では解けなかった課題を新しいモデル構造で解決
- 複数技術の組み合わせ方自体に工夫があり、組み合わせの動機付けが先行技術にない
ソフトウェア発明の図面・実施例記載実務
ハードウェア構成図
プロセッサ・メモリ・ストレージ・通信インタフェースを物理構成として明示する（特許適格性のハードウェア資源との協働を示す根拠となる）。クラウド・SaaS構成の場合は「クラウドサーバ」「APIゲートウェイ」「データベースサーバ」などで表す。各ブロックに参照符号（10、20、21…）を付し、発明を実施するための形態の本文で参照する。
フローチャートとクレームの対応
方法クレームの「〜するステップ」と図のフローチャートの処理ボックス（S101、S102…）を必ず対応させる。クレームの構成要件がフローチャートのどのステップかを明細書本文で明示する。
擬似コード・アルゴリズムの記載
明細書本文に擬似コード・数式・アルゴリズムを記載する場合、変数・記号は初出時に定義し、数式には番号を付ける。実装コードそのものでなく「当業者が理解できる抽象度」で記載する。
シーケンス図の使い方
サーバ・クライアント・データベース間の通信プロトコル、APIリクエスト/レスポンス、非同期処理の流れをシーケンス図で示す。マイクロサービスアーキテクチャでは各サービスを行として表現する。
図面作成詳細ガイド（Mermaid）→ references/drawings-guide.md
記載上の注意点
サポート要件・記載要件
- クレームの範囲が明細書の実施例でサポートされているか確認する
- 当業者が実施できる程度に詳細に記載する
- クレームが広すぎると特許権が無効になるリスクが増す
用語の一貫性
同一の構成要件には同一の用語を使う（「スイッチ」と「切替器」を混在させない）。
ワークフロー
下記の5フェーズで対話的にドラフトを作成する。先行技術調査（フェーズ1.5）は必須ステップとして毎回実施する。
フェーズ1: ヒアリング（intake）
「インタラクティブヒアリング（前提確認）」セクションのフローに従いヒアリングシートを埋める。
[対話ポイント] ヒアリング完了後: 「ヒアリング情報を確認します。以下の理解で合っていますか？」として8項目の要約をユーザーに提示し、承認後に次フェーズへ進む。
フェーズ1.5: 先行技術調査（必須）
ヒアリングで収集した情報と既知特許番号をもとに先行技術調査を実施する。
調査対象データベース:
調査手順:
- ヒアリングで得た技術キーワード（3〜5語）で全文検索
- ヒアリングシートで収集した既知特許番号を直接確認
- ヒット件数が多い場合は IPC コードで絞り込む
- 調査結果から「最も近い先行技術」を 1〜3 件選定しユーザーに提示
調査結果の活用:
- 選定した先行技術文献は
【先行技術文献】 セクションに記載必須
- 先行技術との差分（本発明の新規性・進歩性ポイント）をクレーム起案前に明確化する
- 先行技術と同一・類似のクレームを避けてクレームスコープを設計する
[対話ポイント] 「先行技術調査の結果を共有します。以下の文献が最も近い先行技術です。本発明との差分（新規性・進歩性）を確認してください。」として調査結果とその差分分析をユーザーに提示し、承認後にフェーズ2へ進む。
詳細ガイド → references/claims-guide.md（進歩性を踏まえたクレーム設計）
フェーズ2: クレーム起案
- 独立項（請求項1）のドラフトを提示する
[対話ポイント] 「クレームのスコープを確認してください。広すぎ/狭すぎていないか？不要な限定が入っていないか？」としてユーザーに確認を求める。
- ユーザー確認・修正後、従属項（請求項2〜）を追加する
[対話ポイント] 「三位一体クレーム（システム/方法/プログラム）をすべて作成しますか？」とユーザーに確認し、承認後に次フェーズへ進む。
フェーズ3: 明細書作成
確定したクレームに整合させながら以下の順序で各セクションを執筆する:
技術分野 → 背景技術 → 発明が解決しようとする課題 → 課題を解決するための手段 → 発明の効果 → 発明を実施するための形態 → 要約書
[対話ポイント] 「各セクションのドラフトを提示しました。追記・修正点はありますか？」としてユーザーの確認を受け、承認後に次フェーズへ進む。
フェーズ4: 叩き台チェック（弁理士渡し前）
「叩き台チェックリスト（弁理士渡し前）」セクションのチェックリストを実行する。
[対話ポイント] 「以下の項目を確認してください。」としてチェックリストをユーザーに提示し、問題があれば該当箇所を修正してから弁理士に渡す。
叩き台チェックリスト（弁理士渡し前）
チェックリスト → references/checklist.md
出力フォーマット
各セクションの穴埋めテンプレート → references/section-templates.md
ドラフトとして出力する。段落番号（【0001】等）は付与しない。正式出願時には弁理士等が番号を付与する。ユーザーから特に指定がない場合、以下の書式で出力する:
【書類名】特許願
【発明の名称】
（発明の名称）
【特許請求の範囲】
【請求項1】
（構成要件A）と、（構成要件B）と、を備える、（発明の名称）。
【請求項2】
請求項1に記載の（発明の名称）において、
（追加の特徴）である、（発明の名称）。
【明細書】
【技術分野】
本発明は、...に関し、特に...に関する。
【背景技術】
従来、...
【先行技術文献】
【特許文献】
【特許文献1】特開〇〇〇〇-〇〇〇〇〇〇号公報
【発明が解決しようとする課題】
しかしながら、...という問題があった。
本発明は、上記問題に鑑みてなされたものであり、...を目的とする。
【課題を解決するための手段】
上記課題を解決するため、本発明に係る...は、...を備える。
【発明の効果】
本発明によれば、...という効果が得られる。
【発明を実施するための形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【要約書】
【要約】
【課題】...を提供する。
【解決手段】...を備える。
【選択図】図1
