メニュー
発明内容が固まった後の書類作成・編集フェーズ専用。JPO様式準拠の特許明細書ドラフトを作成し、三位一体クレーム・AI発明記載・明細書レビューに対応。「特許明細書を書いて」「クレームを書いて」「請求項を作って」「明細書をレビューして」「従属項を追加して」「要約書を書いて」などで発動。構想段階や先行技術調査は patent-coach を使う。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/ynitto/sandbox --skill patent-writerコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
会話中の話題を、最小の視覚表現（擬似コード・呼び出しツリー・コンポーネントツリー・ファイルツリー・Mermaid・diff・HTML）で見せて理解を助けるスキル。「図で説明して」「見せて」「視覚的に説明して」「イメージで教えて」「構造を見せて」「どう変わるのか見せて」「show me」などで発動する。説明が長文になりそうなときに、文章の代わりに図で示す。
agent-flow の orchestrator 向け高精度タスク分解・戦略選択スキル。要求を分析し、7パターン（map-reduce 含む）＋複合パターンから最適な戦略を選定し、実行可能なタスクグラフを生成する。decomposition スキルの分解能力を内包し、agent-flow の `--planner flow-planner` で利用する。
セッションをまたいで知識・決定事項を継続させたいときのスキル。「覚えておいて」でsave、「思い出して」でrecall、「記憶一覧」でlist、「忘れて」でarchive、「共有して」でshare、「整理して」でcleanup、「役立った／間違ってた」でrate、「固定化して」でconsolidate。重要な知見を発見したら自律的にsaveを実行すること。
| name | patent-writer |
| description | 発明内容が固まった後の書類作成・編集フェーズ専用。JPO様式準拠の特許明細書ドラフトを作成し、三位一体クレーム・AI発明記載・明細書レビューに対応。「特許明細書を書いて」「クレームを書いて」「請求項を作って」「明細書をレビューして」「従属項を追加して」「要約書を書いて」などで発動。構想段階や先行技術調査は patent-coach を使う。 |
| metadata | {"version":"2.2.0","tier":"stable","category":"research","tags":["patent","jpo","claims","specification"]} |
日本特許庁（JPO）様式に準拠したソフトウェア・AI発明の特許明細書を作成するスキル。
作業開始前に以下のフローで発明の全体像を引き出す。
ラウンド1: 発明の概要把握
→ 「まず1分でこの発明を説明してください。どんな技術で、何が新しいですか？」
→ ユーザーの回答を聞いて大枠を把握
ラウンド2: 詳細深掘り（下記ヒアリングシートを使用）
→ 7カテゴリの構造化質問で情報を補完
→ 不明点・曖昧点のみ追加質問する
【技術分野】
【従来技術と課題】
【解決手段（コア）】
【効果】
【実施例】
【ハードウェア資源】
【図面候補】
【先行技術（既知文献）】
以下8項目がすべて埋まればヒアリング完了:
明細書作成前に必ず確認する。ソフトウェア発明が「自然法則を利用した技術的思想の創作」に該当するか確認する。
発明に該当する条件（以下のどちらかを満たすこと）：
発明に該当しない典型例：ビジネスルールのみ・ゲームルールのみ・数式の計算のみ・人の精神活動のみ
対応策: ソフトウェアとハードウェア資源（CPU・メモリ・センサ等）の協働を明細書で明示すること。
詳細要件ガイド → references/software-patent-requirements.md
日本特許庁の様式に従い、以下の順序で記載する:
【書類名】特許願
【発明の名称】○○○
【特許請求の範囲】
【請求項1】（独立項）
【請求項2】（従属項）
...
【明細書】
【技術分野】
【背景技術】
【先行技術文献】（任意）
【発明が解決しようとする課題】
【課題を解決するための手段】
【発明の効果】
【図面の簡単な説明】（図面がある場合）
【発明を実施するための形態】
【要約書】
【要約】
【選択図】
最重要セクション。先にクレームを確定させてから明細書本文を書く。
請求項1に記載の○○において、 で始めるクレーム文例 → references/claims.md クレーム作成詳細ガイド → references/claims-guide.md 明細書構成詳細 → references/structure.md
1〜2文で簡潔に。IPC（国際特許分類）を意識した表現を使う。
ソフトウェア向けIPCコードの例:
G06F: 電気的デジタルデータ処理（汎用ソフトウェア処理）G06Q: 管理・商業・金融・経営・監督・予測目的のデータ処理システムG06N: 機械学習・ニューラルネットワークG16H: 医療情報学記載例: 「本発明は、G06F 16/00（データベース管理）に属し、特に〜に関する。」
【先行技術文献】 セクションを設けて引用する背景技術の問題点を明確に記述する。クレームの課題と対応するよう一貫性を保つ。先行技術の限界を明示しておくと、後の拒絶理由通知への反論の基盤になる。
クレームの構成要件を言い換えて説明するセクション。クレームと乖離しないよう注意する。
クレームの構成要件から生じる効果のみ記載する。数値付き効果（精度・処理速度・コスト等）を記載し、先行技術との定量的差分を示せる根拠を埋め込む。クレームに記載のない構成から生じる効果は記載しない。
各セクション詳細ガイド → references/description-guide.md
システム・方法・プログラムの三つを必ず検討する。侵害者の行為態様（販売/実施/配布）に対応した権利行使が可能になる。
| クレーム種別 | 特許法カテゴリ | 権利行使の対象 |
|---|---|---|
| システム（装置）クレーム | 物の発明 | システムの製造・販売・使用 |
| 方法クレーム | 方法の発明 | 処理の実施（SaaSに有効） |
| プログラムクレーム | 物の発明 | プログラムの配布・ダウンロード販売・API提供 |
システム（装置）クレームの書き方 「〜部」で機能ブロックを記述。末尾は「〜システム」「〜装置」「〜サーバ」で終わる。
【請求項1】
〔機能ブロックA〕する取得部と、
〔機能ブロックB〕する処理部と、
〔機能ブロックC〕する送信部と、
を備える〔発明の名称〕。
※「一以上のプロセッサと、メモリとを備えるシステムであって、前記プロセッサが〜として機能するシステム」という形式も広いクレームになり有効。
方法クレームの書き方 「コンピュータが、〜するステップ」の形式で処理フローを列挙。末尾は「〜方法」で終わる。
【請求項2】
コンピュータが、〔処理A〕するステップと、
コンピュータが、〔処理B〕するステップと、
コンピュータが、〔処理C〕するステップと、
を含む〔発明の名称〕方法。
プログラムクレームの書き方 「コンピュータを〜として機能させるためのプログラム」の定型形式を使う。機能は「〜手段」と記す。
【請求項3】
コンピュータを、
〔機能A〕する〔手段A〕、
〔機能B〕する〔手段B〕、
〔機能C〕する〔手段C〕、
として機能させるためのプログラム。
機能的クレームの注意点
「〜するための手段（ミーンズ・プラス・ファンクション）」は明細書記載の実施例に限定解釈されるリスクがある。システムクレームでは「〜部」を使い、プログラムクレームでは「〜手段」を使い分けることで明確性を確保する。
「コンピュータに〜させるための学習済みモデル」として記載し、ネットワーク構造・学習条件の特徴を含める。単なる数値データにならないようモデルの構造的特徴をクレームに記載すること。
【請求項X】
コンピュータに〔タスク名〕を実行させるための学習済みモデルであって、
〔入力データ形式〕を入力として受け付ける入力層と、
〔処理の特徴（畳み込み・注意機構等）〕を行う中間層と、
〔出力形式〕を出力する出力層と、
を備え、
前記中間層の重みパラメータが、〔特徴的な学習データ・学習条件〕を用いて学習されたものである、
学習済みモデル。
AI発明のクレームに含めるべき要素:
以下を記載しないと特許法第36条第4項（実施可能要件）違反になりうる：
容易想到とされやすいケース（進歩性なしと判断されやすい）：
進歩性が認められやすいケース：
プロセッサ・メモリ・ストレージ・通信インタフェースを物理構成として明示する（特許適格性のハードウェア資源との協働を示す根拠となる）。クラウド・SaaS構成の場合は「クラウドサーバ」「APIゲートウェイ」「データベースサーバ」などで表す。各ブロックに参照符号（10、20、21…）を付し、発明を実施するための形態の本文で参照する。
方法クレームの「〜するステップ」と図のフローチャートの処理ボックス（S101、S102…）を必ず対応させる。クレームの構成要件がフローチャートのどのステップかを明細書本文で明示する。
明細書本文に擬似コード・数式・アルゴリズムを記載する場合、変数・記号は初出時に定義し、数式には番号を付ける。実装コードそのものでなく「当業者が理解できる抽象度」で記載する。
サーバ・クライアント・データベース間の通信プロトコル、APIリクエスト/レスポンス、非同期処理の流れをシーケンス図で示す。マイクロサービスアーキテクチャでは各サービスを行として表現する。
図面作成詳細ガイド（Mermaid）→ references/drawings-guide.md
同一の構成要件には同一の用語を使う（「スイッチ」と「切替器」を混在させない）。
下記の5フェーズで対話的にドラフトを作成する。先行技術調査（フェーズ1.5）は必須ステップとして毎回実施する。
「インタラクティブヒアリング（前提確認）」セクションのフローに従いヒアリングシートを埋める。
[対話ポイント] ヒアリング完了後: 「ヒアリング情報を確認します。以下の理解で合っていますか？」として8項目の要約をユーザーに提示し、承認後に次フェーズへ進む。
ヒアリングで収集した情報と既知特許番号をもとに先行技術調査を実施する。
調査対象データベース:
調査手順:
調査結果の活用:
【先行技術文献】 セクションに記載必須[対話ポイント] 「先行技術調査の結果を共有します。以下の文献が最も近い先行技術です。本発明との差分（新規性・進歩性）を確認してください。」として調査結果とその差分分析をユーザーに提示し、承認後にフェーズ2へ進む。
詳細ガイド → references/claims-guide.md（進歩性を踏まえたクレーム設計）
[対話ポイント] 「クレームのスコープを確認してください。広すぎ/狭すぎていないか？不要な限定が入っていないか？」としてユーザーに確認を求める。
[対話ポイント] 「三位一体クレーム（システム/方法/プログラム）をすべて作成しますか？」とユーザーに確認し、承認後に次フェーズへ進む。
確定したクレームに整合させながら以下の順序で各セクションを執筆する:
技術分野 → 背景技術 → 発明が解決しようとする課題 → 課題を解決するための手段 → 発明の効果 → 発明を実施するための形態 → 要約書
[対話ポイント] 「各セクションのドラフトを提示しました。追記・修正点はありますか？」としてユーザーの確認を受け、承認後に次フェーズへ進む。
「叩き台チェックリスト（弁理士渡し前）」セクションのチェックリストを実行する。
[対話ポイント] 「以下の項目を確認してください。」としてチェックリストをユーザーに提示し、問題があれば該当箇所を修正してから弁理士に渡す。
チェックリスト → references/checklist.md
各セクションの穴埋めテンプレート → references/section-templates.md
ドラフトとして出力する。段落番号（【0001】等）は付与しない。正式出願時には弁理士等が番号を付与する。ユーザーから特に指定がない場合、以下の書式で出力する:
【書類名】特許願
【発明の名称】
（発明の名称）
【特許請求の範囲】
【請求項1】
（構成要件A）と、（構成要件B）と、を備える、（発明の名称）。
【請求項2】
請求項1に記載の（発明の名称）において、
（追加の特徴）である、（発明の名称）。
【明細書】
【技術分野】
本発明は、...に関し、特に...に関する。
【背景技術】
従来、...
【先行技術文献】
【特許文献】
【特許文献1】特開〇〇〇〇-〇〇〇〇〇〇号公報
【発明が解決しようとする課題】
しかしながら、...という問題があった。
本発明は、上記問題に鑑みてなされたものであり、...を目的とする。
【課題を解決するための手段】
上記課題を解決するため、本発明に係る...は、...を備える。
【発明の効果】
本発明によれば、...という効果が得られる。
【発明を実施するための形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【要約書】
【要約】
【課題】...を提供する。
【解決手段】...を備える。
【選択図】図1