特許分類を検索するためのAPI
- NISHIO KEI
- 3 日前
- 読了時間: 5分
LLMへのアプローチの変化
LLMを活用するための取り組みは、大きく3段階で変化してきています。
プロンプトエンジニアリングは、LLMへの指示をどのように書くかを工夫する段階です。出力品質がプロンプトの書き方に大きく依存することが分かり、多くの知見が蓄積されました。
コンテキストエンジニアリングは、LLMに渡す情報（コンテキスト）の設計に焦点を当てます。RAGに代表されるように、適切な情報をどう取得・整形してLLMに渡すかが重要になってきました。
そして近年注目されているのがハーネスエンジニアリングです。LLM自体の性能に頼るのではなく、LLMを取り囲むシステム全体、複数のAPIコール、外部データソースへのアクセス、結果の統合と後処理を設計することで、単体のLLMでは達成できないタスクを実現する考え方です。
今回公開した特許分類APIは、このハーネスエンジニアリングの一環として位置付けられます。特許調査を支援するLLMシステムのコンポーネントとして、特許分類体系の意味検索・コード解決・検索式生成を担うAPIを公開しました。
特許分類APIの概要
IPC（国際特許分類）、CPC（協力特許分類）、FI（ファイルインデックス）、Fターム（ファイリングターム）の4つの分類体系を対象としています。各分類記号とその定義テキストをPineconeにインデックスし、ハイブリッド検索（密ベクトル＋疎ベクトル）で意味的に近い分類を探すことができます。
ベースURLはCloud Runのサービスエンドポイントとなります。以下に各エンドポイントを説明します。
データについて
インデックスに格納されている分類データは2026年4月時点で取得したものです。各分類体系のデータソースは以下の通りです。
分類体系 | データソース |
IPC（国際特許分類） | WIPO IPC MasterFiles（edition 20260101） |
CPC（協力特許分類） | 特許庁 分類対照ツール用データ（2026年2月公開版） |
FI（ファイルインデックス） | 特許庁 分類対照ツール用データ（2026年2月公開版） |
Fターム |
IPCの日本語タイトルは特許庁公開の IPC_Ver*-?section.xls/xlsx を使用しています。データの最新性については各機関の公式サイトをご確認ください。
エンドポイント一覧
GET /health
ヘルスチェック用のエンドポイントです。
GET /health
レスポンス:
{"status": "ok"}
POST /search
自然言語クエリで特許分類を意味検索します。
POST /search
Content-Type: application/json
リクエストボディの主要フィールド:
フィールド | 型 | 必須 | 説明 |
query | string | ○ | 検索クエリ（日本語・英語可） |
namespaces | array | ? | 検索対象（ipc / cpc / fi / fterm）。既定は ["ipc", "cpc", "fi"] |
top_k | integer | ? | 各パターンから取得する最大件数 |
alpha | number | ? | dense/sparseの重み（0.0=疎のみ, 1.0=密のみ） |
translate_query_to_english | boolean | ? | クエリを英訳してから検索するか |
openai_api_key | string | ? | 未指定時は環境変数 OPENAI_API_KEY を使用 |
concept_ladder_min_patterns | integer | ? | 生成する概念パターンの最小数 |
concept_ladder_max_patterns | integer | ? | 生成する概念パターンの最大数 |
concept_ladder_model | string | ? | パターン生成に使うLLMモデル名 |
api_key | string | ? | 未指定時は環境変数 PINECONE_API_KEY を使用 |
index_name | string | ? | Pineconeインデックス名（既定: patent-class-hybrid） |
このエンドポイントは 多概念展開（concept ladder）を必ず実行します。内部でLLMがクエリから「上位概念→下位概念」の複数パターンを生成し、各パターンで独立して検索した結果をマージして返します。そのためOpenAI APIキーが必須です。
レスポンス例（抜粋）:
{
"total": 15,
"results": [
{
"namespace": "ipc",
"score": 0.872,
"id": "ipc:H04N21/00",
"symbol": "H04N21/00",
"def_en": "PICTORIAL COMMUNICATION, e.g. TELEVISION",
"def_ja": "画像通信、例．テレビジョン"
}
],
"concept_patterns": [
{
"pattern": "動画配信システム",
"queries": ["ストリーミング配信", "コンテンツ配信ネットワーク"]
}
],
"per_pattern_hit_counts": [
{"pattern": "動画配信システム", "count": 8}
]
}
resultsの各ヒットにはnamespace（分類体系）、score（類似度スコア）、symbol（分類記号）、def_en/def_ja（英日の定義文）が含まれます。またmatched_dimensionsとmatched_queriesでどのパターンにマッチしたかを確認できます。
GET /classify/{namespace}/{code}
分類記号1件のメタデータを取得します。ベクトル検索ではなく、PineconeのFetch APIで直接IDを指定して取得します。
GET /classify/{namespace}/{code}
namespace: ipc / cpc / fi / fterm
code: 分類記号（スラッシュを含むコードも可。例: H04N21/00）
クエリパラメータ:
パラメータ | 型 | 説明 |
index_name | string | 既定: patent-class-hybrid |
api_key | string | 未指定時は環境変数 PINECONE_API_KEY を使用 |
リクエスト例:
GET /classify/ipc/H04N21/00
レスポンス例:
{
"total": 1,
"results": [
{
"namespace": "ipc",
"symbol": "H04N21/00",
"def_en": "PICTORIAL COMMUNICATION, e.g. TELEVISION",
"def_ja": "画像通信、例．テレビジョン"
}
],
"not_found": []
}
見つからなかったコードはnot_found配列に格納されます。
POST /classify/batch
分類記号を最大200件まとめて取得します。
POST /classify/batch
Content-Type: application/json
リクエストボディ:
フィールド | 型 | 必須 | 説明 |
namespace | string | ○ | ipc / cpc / fi / fterm |
codes | array | ○ | 分類記号の配列（1-200件） |
index_name | string | ? | 既定: patent-class-hybrid |
api_key | string | ? | 未指定時は環境変数 PINECONE_API_KEY を使用 |
リクエスト例:
{
"namespace": "ipc",
"codes": ["H04N21/00", "H04L67/00", "G06F16/00"]
}
レスポンスはGET /classify/{namespace}/{code}と同形式のClassifyCodeResponseです。見つかった分類はresults、見つからなかったコードはnot_foundに入ります。
POST /llm/patent-search-expression
自然言語の説明から、複数の特許データベース向け検索式をLLMで生成します。
POST /llm/patent-search-expression
Content-Type: application/json
リクエストボディの主要フィールド:
フィールド | 型 | 必須 | 説明 |
user_prompt | string | ○ | 検索したい内容の自然言語説明 |
api_key | string | ? | OpenAI APIキー。未指定時は環境変数 OPENAI_API_KEY |
base_url | string | ? | OpenAI互換エンドポイントのベースURL |
model | string | ? | 使用するLLMモデル名 |
target | string | ? | jplatpat_like（既定）または generic_boolean |
use_classification_api | boolean | ? | Pinecone検索で分類候補をLLMに渡すか（既定: true） |
use_concept_ladder_for_classification | boolean | ? | 分類検索に多概念展開を使うか（既定: true） |
pinecone_api_key | string | ? | 未指定時は環境変数 PINECONE_API_KEY |
classification_namespaces | array | ? | 分類検索の対象（既定: ["ipc", "cpc", "fi"]） |
use_classification_api=true（既定）の場合、user_promptと同じ内容でPinecone検索を実行し、ヒットした分類記号をLLMのプロンプトに付加した上で検索式を生成します。分類記号を明示的に指定しなくても、意味的に近い分類が自動的に検索式に反映されます。
レスポンス例:
{
"expression": "(動画 OR ストリーミング) AND (配信 OR 送信) AND (H04N/21 OR H04L/65)",
"espacenet_smart": "((video OR streaming) AND (delivery OR transmission)) AND (H04N21 OR H04L65)",
"wipo_patentscope": "...",
"google_patents": "...",
"lens_org": "...",
"uspto_patentsview": "...",
"notes": "...",
"model": "gpt-4o",
"classification_hits": [...]
}
expressionはJplatPat向け、その他のフィールドは各データベース向けの検索式となります。classification_hitsには内部で使用した分類ヒットが格納されます。
エラーレスポンス
ステータスコード | 説明 |
400 | APIキー未設定、空クエリ、パラメータ不正など |
502 | Pinecone側のエラー |
ます。
