特許AIは「文章が上手いモデル」ではなく、根拠・管轄・案件記録・人の最終確認が付いたワークスペースかどうかで選ぶ。流暢なドラフトはどこからでも出る。実務で分かれるのは、そのドラフトがどの原文に付いているか、同じ案件に残るか、誰が確定したかだ。
請求項の範囲と対応方針の 最終決定権は弁理士（代理人） にある。以下の基準はツールを評価するチェックリストであり、特許性・登録を約束しない。
シリーズ目次は 特許AI実務ガイド（I0） を見るとよい。
なぜ汎用ChatGPT・Claudeだけでは足りないか
汎用LLMは、明細書ドラフト・要約・翻訳スケッチには使える。ただし特許案件では、次の四つのリスクが繰り返される。
- 案件文脈の断絶 — チャットが変わると、請求項バージョン・引用文献・前回の指示が散らばる。
- 引用・原文追跡の弱さ — 「似た文献」の要約だけが残り、セル単位の原文ハイライトがない。
- 版・監査の欠如 — 誰がどの文言をロックし、変えたかを再現しにくい。
- 管轄形式 — 日本の明細書を US・PCT 形式に移すとき、限定・数値・符号が静かに落ちることがある。
恐怖を煽る必要はない。問題は「AIを使うか」ではなく、上の四つを製品が前提として扱うかだ。
市場には役割の違うツールが共存する。おおよそ四バケットだけ見れば足りる。
| バケット | 典型的な仕事 | 例（名前のみ、1回） |
|---|---|---|
| 明細書作成・中間対応クラウド | 請求項・明細書、拒絶対応、構成要素対比、版管理 | appia-engine（Smart-IP） |
| 調査・審査シミュ・文書支援 | 先行調査、登録可能性シミュレーション、対話型文書作成 | AI Samurai（ONE / ZERO） |
| 特許読解・調査支援 | 要約・分類・クリアランス／無効資料の読解支援 | Summaria / サマリア（Patent Integration） |
| 案件単位ワークスペース | 先行比較＋明細書＋レビュー＋版＋管轄変換を一つの案件に | Patenty |
以下の七基準は、特定ブランドを勝者にしない。どのベンダーでも、同じ質問で30分以内にふるい分けられるようにする。
基準1: 発明の構成要素 ↔ 先行を原文で対比できるか
なぜこの基準か。先行判断の単位は「文献一件が似ているか」ではなく、構成要素ごとに何がどこにあるかだ。類似度の一行だけを返すツールは、実務根拠にならない。
確認すること:
- 行＝発明の構成要素、列＝文献の マトリクス（または同等の対比表） があるか
- セルを開くと source passage（原文区間） へ移動・表示されるか
- Partial（部分対応）のとき「何だけが対応するか」を書けるか
- AI提案と人の確定が区別されるか
「AIが似ていると言った」だけなら、不合格に近い。マトリクス自体の解説は 構成要素対比（I2） に続く。
基準2: 請求項 → 明細書が同じ案件の中でつながるか
なぜこの基準か。請求項をAチャットで書き、明細書をBチャットに貼ると、用語・要素ID・従属関係がずれやすい。
確認すること:
- 同一 案件（matter） の中で、請求項と発明の詳細な説明がつながるか
- 構成要素の定義が明細書・マトリクスに再利用されるか
- コピペなしでも版を追えるか
別チャットのコピペが基本ワークフローなら、ツールが二つあるのと同じだ。
基準3: レビュー・修正が diff で残るか
なぜこの基準か。事務所・企業知財では「誰が確定したか」が後で問題になる。最終ファイルだけだと監査が切れる。
確認すること:
- 提案修正と採択版を 比較（diff） で見られるか
- 重要文言を lock する、または同等の保護があるか
- 寄与者・版・エクスポート（監査パッケージ：明細書・請求項・レビュー決定が中心——範囲はデモで確認）があるか
流暢な書き換えより、変更履歴の再現可能性 が選定基準である。
基準4: 拒絶理由・中間対応まで同じ文脈か
なぜこの基準か。出願だけできて拒絶理由通知（OA）対応が別ツール・別チャットに移ると、引用原文と請求項履歴をまた組み立て直さねばならない。
確認すること:
- OA番号・対象請求項・引用文献が 同一案件 に付くか
- 出願時に作った構成要素マトリクスを中間で再利用できるか
- 意見書・補正書ドラフトが旧版請求項に戻らないようにするか
ドラフト前後のチェックリストは 拒絶理由対応チェック（I3） にまとめる。対応方針をAIに外注しないことが前提だ。
基準5: 管轄変換・翻訳で欠落を拾えるか
なぜこの基準か。外国出願の品質は「英語が自然か」ではなく、限定的表現・数値・従属・図面符号が原文と1:1で残ったかだ。
確認すること:
- 日↔US/PCT など変換後に 原文との並列対照 ができるか
- 数値・単位・範囲（例：電圧・温度・比率のうち一部だけ残る 類型）をフラグできるか
- 図面符号・要素IDが翻訳後も同じ行を指すか
架空案件・偽の数値で「何％落ちる」とは言わない。欠落類型と校閲手順は 日→US/PCT 翻訳欠落（I4） で扱う。
基準6: データ・学習・保管方針が文書化されているか
なぜこの基準か。明細書・先行・クライアント資料は機微だ。マーケ文言より 文書に書かれた方針 が重要である。
確認すること（断定せず、ベンダーに聞く一覧として）:
- 顧客資料を モデル学習に使うか／使わないか が FAQ・方針に明示されているか
- subprocessors（再委託先）・保管・削除手順を文書で受け取れるか
- セキュリティ・コンプライアンスのページ（または同等資料）にリンクできるか
この記事は特定ベンダーのセキュリティ水準を断定しない。何を確認するか だけ固定する。Patenty については導入時に trust 等の最新ページを直接確認する。
基準7: 弁理士の最終確認が製品前提か
なぜこの基準か。「自動出願」「特許性の自動判定」「確認なし提出」を示唆するメッセージは、実務・倫理の双方でレッドフラグだ。
確認すること:
- UI・コピーが 人の最終確認 を前提にしているか
- 登録・許可・無効克服など 結果保証 の文言がないか
- AI出力と確定版が区別されるか
人は請求項範囲・対応方針の最終決定権者である。ツールはその判断を加速するだけだ。
30分評価プロトコル
ベンダーデモやトライアルでは、サンプル発明1件 で下だけ回せばよい。自社ブランドでなくても同じだ。
| 段階 | やること | 通過の合図 |
|---|---|---|
| (a) | 発明の構成要素を5個以下に分解 | 要素が案件内に保存される |
| (b) | 先行1–2件を原文で確認 | セル→原文区間が開く |
| (c) | 独立請求項1件 → 明細書初稿 | 同じ案件でつながる |
| (d) | 意図的な誤り1つを直し、diff を確認 | 変更・寄与者が残る |
| (e) | 学習・セキュリティ方針ページを確認 | 文書リンク・文言を確保 |
通らなかった項目は「あとでUIに追加」ではなく、いまのワークフローに穴がある という信号として書く。
この基準で見ると（Patenty）
上の七つを Patenty の案件ワークスペースでどう確認できるかだけ書く。他ブランド名は再登場させない。
- 基準1 — 構成要素比較マトリクスと、セルごとの source passage
- 基準2 — 同一案件で請求項・明細書・レビューがつながる
- 基準3 — レビュー・修正の diff、重要文言の lock、版の比較・復元（監査パッケージは明細書・請求項・レビュー決定が中心——範囲はデモ・方針で確認）
- 基準4 — 出願文脈を拒絶理由・中間対応まで同じ案件で維持
- 基準5 — 管轄変換と翻訳欠落の対照（原文並列レビュー）
- 基準6 — サイト FAQ・方針に沿った学習非利用など文書化された扱い（導入時は最新の trust 等を直接確認）
- 基準7 — 専門家の最終確認が前提。自動登録・特許性保証なし
画面証拠はデモで一緒に見るのがいちばん早い。機能列挙が目的ではなく、上のプロトコル (a)–(e) を同じ案件で再現できるか が目的だ。
Soft CTA
チーム導入を検討中なら、上の30分プロトコルをベンダーにそのまま依頼してみるとよい。Patenty で同じ判断を案件単位でどう残すかを見るには、製品・プラン または導入相談でデモを取ればよい。提出どと権利範囲の最終責任は弁理士にある。