掲示板のお便りに、
途中まで答える

なぜ「完全回答」にしないのか

質問に完璧に答えると、質問した人は読んで終わりになります。手を動かさないまま「わかった気」になって、 三日後には何も残っていない。これは自分がさんざんやってきた失敗です。

それに、私が書ける「正解」は私の環境での正解でしかありません。使っているツールも、扱う技術分野も、 社内の制約も違う。手順書をそのまま渡しても、たいてい三行目で合わなくなります。

だからここでは、難所がどこにあるかを先に言います。そのうえで、最初の一手だけ渡します。 転ぶ場所が分かっていれば、あとは自分で進めます。

他社の動きを定点観測して、
自社の位置を見たい

本丸は「定期的に」ではなく「その式でいいのか」

自動化から入りたくなりますが、間違った式を毎週自動で回しても、間違った絵が毎週出てくるだけです。 しかも自動化されている分、疑わなくなる。ここがいちばん危ない。

先に固めるべきは検索式です。そして式の良し悪しは、取れた件数では判定できません。 「500件取れました」は何の保証にもならない。判定する方法は一つで、 この式なら当然引っかかるはずの特許を、先に5件挙げてから回すことです。

私は【技術分野／製品名】の競合動向を追いたい。
まず検索式を作りたいので、順にやってください。

1. この分野の技術要素を5〜8個に分解して
2. 各要素について、FI / Fターム の候補と
   キーワード（同義語・表記ゆれ・カタカナ／漢字の両方）を挙げて
3. J-PlatPat の論理式として組み立てて
   ※ J-PlatPat の論理式は後置記法（postfix）です
4. その式で当然ヒットするはずの特許を、
   公開番号つきで5件、先に予想して挙げて
5. 私が J-PlatPat で5件を確認します。
   外れていたら、式のどこをどう直すか教えて

4と5が肝です。式を作らせっぱなしにしない。 5件で往復して初めて、その式は信用できます。私はこれを省いて、 半年分の集計をやり直したことがあります。

先に言っておく、転びどころ

• 0件に近い式は、たいてい間違っています。ノイズが多すぎるより、少なすぎる方がずっと危険です。ノイズは目で捨てられますが、漏れは気づけません。
• 同義語の網羅は、最後は人間の仕事です。AIは一般的な言い換えは出せますが、その業界だけで通じる言い回しや、社内用語は持っていません。
• 「他社動向」を見るなら出願人の名寄せが要ります。子会社、旧社名、表記ゆれ、共同出願。ここを放置すると、同じ会社が3社に分裂した絵ができます。
• J-PlatPat の画面を機械で叩くのは、規約上おすすめしません。自動化するなら特許庁の公開APIが正道です。現実的には「式はJ-PlatPatで練る → CSVで手動書き出し（月1回で十分）→ 加工と作図を自動化」で、価値の9割は出ます。

審査官ごとの
「通り易い筋」を読みたい

技術の前に、母数の問題があります

やりたいことは実現できます。審査官名は公報にも経過情報にも載っている公開情報です。 ただし先に言っておくと、「この審査官は◯◯を認めやすい」と言えるだけの件数は、たいてい集まりません。 一人の担当件数は限られ、しかも技術分野が偏ります。

n が足りないまま傾向を語ると、審査官の癖ではなく、その技術分野の癖を見ていることになります。 これは統計的な失敗というより、方針を誤る実務的な事故です。

そこで、狙いを少しずらすことを勧めます。効くのは審査官個人の当たり外れではなく、 その審査官が拒絶理由をどう組み立てるかの「型」です。29条2項なら、主引例と副引例の関係をどう説明するか。 動機づけを課題の共通性に求めるのか、作用効果に求めるのか。周知技術をどこまで使うか。 これは1通の拒絶理由通知を精読するだけで見えはじめます。

以下は、同じ審査官が出した拒絶理由通知◯件の本文です。
完全な結論は要りません。「仮説」を立ててください。

1. この審査官が29条2項を組み立てるとき、
   主引例と副引例の関係をどう説明する傾向があるか
2. 「動機づけ」をどこに求めているか
   （課題の共通性／作用効果／技術分野の関連性）
3. 周知技術・慣用手段をどの程度使うか
4. 補正で通った案件と通らなかった案件の差はどこか
5. この仮説を検証するには、あと何を見ればいいか

制約：
- 各項目に、根拠となる原文の記述を必ず引用すること
- 引用できない項目は「根拠不足」とだけ書くこと
- 一般論としての審査実務の説明は不要です

最後の三行が本体です。根拠を引かせないと、それらしい傾向論を創作します。 しかもその創作は非常に読みやすく、もっともらしい。「根拠不足」と書かせる余地を残しておかないと、 全項目が埋まって返ってきます。

先に言っておく、転びどころ

• 対照群がないと「その人の特徴」は言えません。同じ分野の別の審査官と比べて、初めて差分が意味を持ちます。1人だけ見ると、全部が特徴に見えます。
• 「通った／通らなかった」は補正の内容に強く依存します。審査官の要因を切り出すのは、思うより難しい。うまく通った案件は、審査官がよかったのではなく補正がよかっただけかもしれません。
• データ収集は案件単位です。経過情報はまとめて取れません。いきなり全件を狙わず、まず1人 × 10件から。

長期連載のブログを、
相談相手にしたい

技術の前に、二つ決めることがあります

ひとつは著作権です。自分ひとりが手元で使うのと、チームで共有するのとでは、まったく別の話になります。 私的複製の範囲に収まっているうちは問題になりにくい。共有した瞬間に、他人の著作物の複製物を配布したことになります。 技術的には同じ作業なのに、法的な立ち位置が変わる。ここは最初に決めておかないと、後から戻れません。

もうひとつは「いつ時点の理解か」です。長期連載ということは、 後の記事が前の記事を修正している可能性があります。そして判例の理解は、 その後の上級審や後続判決で変わります。

ここに、RAGでいちばんよく踏む地雷があります。 チャンクに分割するとき、公開日が落ちる。 落ちたまま検索すると、令和3年の理解と令和6年の理解が同じ重みで混ざって返ってきます。 しかも出力は自信たっぷりです。私はニュース記事で同じことをやって、古い数字を最新として引きました。

ある法律ブログの記事◯年分を、検索して相談できるようにしたい。
実装の前に、設計の穴を指摘してください。

前提：
- 記事は時系列で、後の記事が前の記事を修正していることがある
- 判例の理解は上級審や後続判決で変わることがある
- 私は「いつ時点の理解か」を必ず知りたい
- ブログ主の見解と、判決文そのものは区別したい

質問：
1. チャンクに必ず持たせるべきメタデータは何か
2. 「古い理解を新しい理解と混同して答える」事故を防ぐには、
   検索時と生成時それぞれで何をすべきか
3. 最初の10記事だけで設計の正しさを確かめるための、
   検証用の質問を3つ作って

そして、出来上がったら必ずこの三つを聞いてください。設計が正しければ答えられ、 間違っていれば答えられません。

・この論点について、いちばん新しい記述はいつのものですか
・同じ論点で、時期の違う記述が複数ありますか。
  あれば、古い方と新しい方を両方出してください
・いまの回答は、ブログ主の見解ですか、判決文の記述ですか。
  出典の記事タイトルと日付を添えてください

先に言っておく、転びどころ

• 「相談相手」にすると、断定する方向に引っ張られます。相談相手らしく振る舞おうとして、根拠のない一般論を混ぜてきます。「出典が示せないことは答えない」を明示的に指示に入れてください。
• 全部入れる前に、10記事で試す。数年分を投入してから設計ミスに気づくと、やり直しが重くなります。10記事なら30分で作り直せます。
• RSSがあるかを最初に見る。あれば取得はほぼ自動化できます。無ければ手動保存になりますが、それでも10記事なら現実的です。
• ブログ主の見解と判決文は別物です。混ざったまま answers に出ると、他人の意見を判例として引くことになります。メタデータで分けておくと事故が減ります。

三つに共通していたこと

書きながら気づいたのですが、三つとも「作る前に決めておくこと」でつまずく形をしていました。

• 特許マップ — 自動化の前に、式が正しいかを5件で確かめる
• 審査官分析 — 収集の前に、対照群をどこに置くかを決める
• 判例RAG — 投入の前に、共有するのか手元だけかと、日付をどう持つかを決める

どれも技術の問題ではありません。作り始めると決めにくくなることを、作る前に決めるという同じ形です。 そして三つとも、最初の一歩は「10件」や「5件」で足りる。 全部やろうとすると重いのに、確かめるだけならその日のうちに終わります。