知財・情報フェア＆コンファレンス2026の169社を、カオスマップに落としながら三日間眺めた。
その整理の途中で、ひとつの仮想敵が浮かんだ。「AIツールを揃えれば、知財業務は変わる」という見立てである。
会場の熱量はこの見立てを後押しする。しかしブースを工程順に並べ直すと、ツールが揃うことと、
知財部門の進め方が変わることの間には、ベンダーが埋めてくれない空白がある。
本稿は、その空白を「データのつなげ方」の問題として言語化する試みである。
数字を先に置く。
「AI搭載」はもはや機能ではなく前提になった。ここまでは誰の目にも明らかで、争点はすでに次に移っている。 ブースの訴求文を工程別に読むと、その移動の方向が見える。
| 潮流 | 会場での訴求 | 意味するもの |
|---|---|---|
| 検索 → 読む・判断する | 「"読む"から"判断"する時代へ」「根拠・結論・次のアクションまで提示」「検証可能なAI調査」 | AIの出力が構造化された判断材料の形を取り始めた |
| エージェント化とMCP | 12組織がエージェント、5組織がMCPを明示。「MCP・API・AIエージェントで技術知識をつなぐ」 | 単体UIの競争から接続性の競争へ |
| 管理システムは「つながる」 | 「企業⇄事務所のデータ自動同期」「EDIで転記ゼロ」「事業部・知財部・代理人が同一画面」 | 台帳から、AIに食わせるデータ基盤へ |
| 調査代行は「人×AI」 | 「AIが探し、人が見極める」「AIの速さ×弁理士の責任」 | 判断の責任主体を明示する設計 |
一つひとつは製品の売り文句である。しかし並べると、ベンダー側が同じ方向を向いていることがわかる。 出力を構造化し、他のシステムと接続し、人間の判断に接続する。 問題は、この方向の先に何があるのか、そこへ誰が連れて行くのか、である。
知財部門におけるAIの適用領域は確かに広がっている。ただし、拡大の内実は二層に分かれる。
前者は「速い担当者が一人増えた」で終わる。担当者の速度は上がるが、部門の進め方は変わらない。 後者に進んで初めて、進め方そのものが変わる。
問われているのは個々のツールの性能ではなく、データのつなげ方である。 そしてつなげ方は、ベンダーの製品には入っていない。組織の中にしかない。
つなげ方を議論するために、AI活用の状態を5段階に分けてみる。
| 段階 | 状態 | 成果物の行き先 |
|---|---|---|
| L1 | 単発の調査 | 個人のPC・頭の中に滞留 |
| L2 | AIチャットによる対話型調査 | 揮発する（セッション終了で消える） |
| L3 | 反復・連携した調査結果を構造化出力 | 社内文書・HTML等として蓄積される |
| L4 | 蓄積した記録にAIが問える | 文脈つきの知識基盤になる |
| L5 | 判断軸に沿ってデータが接続される | 出願稟議・決裁・レビューの基盤 |
L2までは「速い担当者が一人増えた」状態にすぎない。対話は便利だが、セッションが終われば消える。次の案件で同じ問いを立て直す。
出力が構造化されて残った瞬間に、それが次工程の入力になり、初めてパイプラインが成立する。 L3はツールの話ではなく、出力の「形」と「置き場所」の話である。
ベンダーがL2を高速化し、接続子を用意し、器を用意した。しかしL3で「何を残すか」、L5で「何の軸で接続するか」は、 組織が決めない限り誰も決めてくれない。仮想敵の見立てが崩れるのは、この点である。
L5で下された判断の結果と根拠も、記録に戻して再利用する。「あのとき何を見て、なぜ出願しなかったか」は、次の類似案件で最初に参照されるべき入力データである。判断はループの一部であり、終点ではない。
つなげ方の原理は一つに集約される。
多くの現場では、調査を先に走らせ、結果を後から決裁資料に整形している。順序を逆にする。
決裁で問われる判断軸を先にスキーマ化し、調査段階からその欄を埋めに行く。
こうすると、調査担当者への指示、AIへのプロンプト、レビュー担当者が見る画面が、同じスキーマを共有する。 「読む・判断する」を謳うツールの出力も、このスキーマの欄に流し込む形で受け取れば、ベンダーが変わっても蓄積は切れない。
決裁で効くのは「何が見つかったか」よりも、どの条件で、いつ、誰が、何を見て、何を判断しなかったかである。
会場で「検証可能なAI調査」「根拠提示」が訴求されていたのは正しい方向だが、それはツール内での根拠表示であって、 組織の判断イベントの記録ではない。「この公報を見たうえで、事業寄与が薄いと判断して出願を見送った」という事実は、 どのベンダーのDBにも入らない。
調査の網羅性を上げる投資より、判断イベント自体をデータとして残す設計のほうが効く。
中間成果物をHTML / Markdown / 表に固定し、案件IDと日付を必ず持たせる。 これだけで、次段のAIへの入力と、人間のレビュー対象が同一物になる。
MCPへの注目は当然だが、MCPが標準化するのはツールの「呼び出し方」であって、中間成果物の「形」ではない。 呼び出せるようになった後で、何を渡し、何を受け取り、どこに置くかを決めるのは組織側の仕事として残る。
技術区分や事業の呼び名が部署ごとに揺れていると、蓄積した記録へのAI問い合わせ（L4）が機能しない。 「同じものを別の名前で呼んでいる」記録は、AIにとって別のものである。
パイプライン化の実務は、8割がここの整備に費やされる。会場に並んだツールのどれを選んでも、この8割は減らない。
新しい仕組みを作る前に、すでに組織が持っている判断軸を可視化する。 最短経路は、既存の出願稟議書のフォーマットを、逆にスキーマとして読み直すことである。
稟議書は、その組織が何を判断軸としてきたかの、最も正直な記録である。そこから始めれば、判断軸をゼロから設計する必要はない。
「AIツールを揃えれば、知財業務は変わる」。
会場を歩いた実感として、ツールは十分に揃った。検索は読むに進み、読むは判断の材料を出すところまで来た。 接続子も器も、ベンダーが用意し始めている。
それでも、L3で何を残すか、L5で何の軸でつなぐかは、ベンダーの製品には入っていない。 入っていないのは怠慢ではなく、それが組織固有の判断軸であって、外から与えられるものではないからだ。
だから順序はこうなる。ツールを選ぶ前に、稟議書を開く。判断軸を欄に書き出す。調査の出力をその欄に合わせる。 案件IDと日付を付けて残す。語彙を揃える。
地味な作業だが、来年のフェアでどのブースが残っていても、この蓄積は残る。