カオスマップは来場者ポータルの公開データから169社を並べ替えたもので、MCPの先にある特許情報サービスはそこから先を考えたものだった。本稿はその間にある「実際にブースでお話を伺ったら、何を教えていただけたか」の記録である。
筆者は特許庁の特許情報標準データを自前で取り込み、検索と分析を手元で回してきた。探索は何とかなるが、社内に配ること——権限、保守、発明者が直接使える画面——で行き詰まっている。その行き詰まりを正直にお話しして、12のブースと2つの講演を、同じ6つの質問を携えてお伺いして回った。教えていただいたことを一言でまとめると、自前で続けられるのは探索まで、提供の部分は専門のサービスに任せたほうがよい、ということだった。
同じ質問を同じ順で伺うと、あとで見比べられる。自分たちが実際に行き詰まっている6点に絞り、どのブースでも最初にお断りしたうえで伺った。
少人数の知財チーム。特許庁の標準データと米国特許庁の公開 API を自前で取り込み、検索・分類・レポート生成を手元で回している。探索は速くなったが、社内に配ること——権限、保守、発明者が直接使える画面——で行き詰まっている。この状況を最初にお伝えしたうえで伺った。
「AI からの利用」欄の◎は MCP、○は API を各社が公開資料で掲げているもの。「—」は質問の対象外か、会場では確認しなかったもの。社名が録音に残っていない3ブースは、確認できるまで表から外している。
| ブース | AI からの利用 | 会場でご説明いただいた主題 | 教えていただいて分かったこと |
|---|---|---|---|
| パテント・インテグレーション「サマリア」 3-C06 | ◎ MCP | 調査・読解・分類・作成・共有を一つのアシスタントに束ねる設計。MCP でチャットから直接データベースに当たる使い方 | 質問3（社内に配る）に最も近い答えをいただいた。知財部員でない人が検索式を書かずに一次調査できる入口として、丁寧にご説明いただいた |
| パテント・リザルト Biz Cruncher 3-C14 | ○ API | グローバル版の分析機能と、AI を使った母集団作成・分類 | 質問2と4。海外を含む母集団を一気に作って軸で切る使い方を見せていただいた |
| root ip 3-E08 | ○ API | クラウド知財管理の1年分のアップデート（別稿） | 質問1。管理システムを外から同期する前提で API について伺った |
| Speeda（ユーザベース） 3-C13 | ◎ MCP | 企業・市場データと、MCP で AI アシスタントから呼び出す使い方。専門家への質問サービス | 質問6。「AI で一次調査をして、判断の直前だけ有償データと専門家で裏を取る」という使い分けを一緒に考えていただいた |
| ジー・サーチ 3-I38 | — | 企業情報・新聞記事など複数の有償情報源を一つの画面で横断検索する設計。与信・コンプライアンス用途 | 質問1。横断検索が価値の中心で、AI 連携を前提にした設計ではないことを率直に教えていただいた。利用条件は各情報源の契約に依るので、AI で扱う前提なら契約前に相談が要る |
| 日本国特許庁 3-K08 | ○ API | 特許情報標準データと API | 質問2の本丸。標準データの構造化と機械可読性の高さに助けられている一方、審査経過とリーガルステータスをどう機械で追うかは、利用者側の課題として残っている。§03 で述べる |
| GMO アイアールディー 3-H08 | — | 知財管理システムの製品ライン | 質問への答えというより、業界の再編と AI の話を伺う時間になった |
| NTT データ 3-D04 | — | 特許審査支援の経験を土台にした企業向け AI 活用支援 | 質問4。審査で求められる厳密さと、事業判断で求められる速さは別の要件だという整理を教えていただいた |
| DBoy × I-clear assist （ブース番号は要確認） | — | オンプレの知財管理と、先行技術調査ツールの連携 | 質問3の変奏。社内の未公開データを外に出さずに公報データと突き合わせたい、という要望に合う構成をご説明いただいた |
| 講演：Pillsbury（P6-04） | — | 米国特許訴訟の最新動向。venue 選択、NPE への防衛、ITC | 質問4の裏付け。量と速度で出す側は、訴訟側の速度も知っておく必要があると学んだ |
| 講演：萬 秀憲氏（P5-06） | — | 花王・大王製紙での経験から、知財部を「権利の守護者」から「事業創造の先導者」へ | 質問4の反対側。件数評価からの脱却、Human-in／on／out-of-the-loop の段階導入 |
カオスマップの段階では「MCP 対応5組織、AI エージェント12組織」と数えていた。ブースで伺うと、線はもっとはっきりしていた。サマリアと Speeda は MCP で会話の中から呼べる。Biz Cruncher、root ip、特許庁は API を公開している。一方で、横断検索や画面での閲覧を価値の中心に置くサービスは、AI 連携を前提にしていない。これは優劣ではなく、どういう使い方を想定して作られているかの違いで、ジー・サーチのように「AI 連携は前提にしていない」と率直に教えていただけたのはありがたかった。自分たちの使い方に合うサービスを選ぶ材料になる。
筆者の状況をお話しすると、いくつかのブースでは「探索の部分は既にお持ちですね」と言っていただいた。ところが提供の部分——社内に配る、保守する、発明者が直接使う——になると、どのブースでも自前で持ち続けるのは大変だと教えていただいた。権限管理、監査ログ、画面の保守、問い合わせ対応は、専門のサービスが最初から持っているもので、少人数の知財チームが持ち続けるには人手がかかる。どこまでを自前で持ち、どこからをお願いするかの線引きが、今回いちばんの収穫だった。
特許庁ブースでの対話がいちばん濃かった。特許情報標準データは構造化と機械可読性が高く、大規模に処理しやすいことに日々助けられている。一方で、審査経過（包袋）と最新のリーガルステータスを機械的に取り込む経路については、利用者側でまだ工夫が要る。仮説を立てるところまでは標準データで速く回るが、検証は別の経路に頼ることになる。この構造は前稿で「最後に残る硬い価値は、まだ存在しないデータ」と書いたことの具体例で、ここを各社がどう補っていくかを、利用者として引き続き教えていただきたい。