酵素の変異体、プロモーター配列——バイオ分野では「この配列、自由に使えるのか」という問いが日常的に発生します。ところがこの問いは、調べようとすると意外に手間がかかります。
先日、あるタンパク質について、実施できる候補配列を洗い出す調査を行いました。対象は米国特許100件以上。最終的に約50件の特許から300本以上のアミノ酸配列を、権利状況で区分したうえで抽出しました。この作業のかなりの部分を生成AIに任せています。
本稿では、そこで確立した手順を一般論としてまとめます。遺伝子配列やタンパク質配列を対象とした調査にそのまま応用できる考え方です。
なぜ配列のFTO調査は手間がかかるのか
配列を対象としたFTO調査には、通常のFTO調査にはない固有の壁が3つあります。
壁1：配列そのものが特許文献の本文に載っていない
米国特許の場合、配列表は明細書とは別のファイルとして提出されます。特許データベースからエクスポートした全文にも、Google Patentsの画面にも、配列そのものは含まれていないことが多い。「SEQ ID NO: 1」という参照だけがあって、その中身は別途取りに行かなければなりません。
今回の調査でも、明細書本文から配列を読み取れたのは全体の2〜3割程度でした。
壁2：権利状況と配列が別々の場所にある
「失効した特許の配列なら使える」という発想は自然ですが、権利状況はGoogle Patents、配列は配列表ファイル、請求項の内容は公報全文と、情報が三方に散っています。これを1件ずつ人力で突き合わせるのは、100件を超えたあたりで現実的でなくなります。
壁3：失効していても使えるとは限らない
これが最も見落とされやすい点です。ある特許がAbandonedでも、同じファミリーの継続出願が権利化されていれば実施できません。今回の調査では、失効していた特許のうち約3分の1がこれに該当しました。権利状況の欄だけ見て「使える」と判断すると、かなりの確率で事故ります。
全体設計：まず6つに区分する
配列を「使える／使えない」の二択で考えると行き詰まります。実際にはグラデーションがあるので、次の6区分に分けました。
| 区分 | 定義 | 位置づけ |
|---|---|---|
| ① | 権利が失効し、ファミリーにも有効な権利がない | FTO候補の本命 |
| ② | 権利は失効しているが、同一ファミリーに生存権利がある | ファミリーのクレーム範囲を要検討 |
| ③ | 有効だが、独立請求項の構成要素が限定的で、想定する実施形態では構成要件を充足しないと考えられる | 非侵害の可能性あり／要法的判断 |
| ④ | 有効だが、請求項に配列番号による特定がなく、明細書にのみ記載がある | 配列自体はクレームされていない |
| ⑤ | 有効で、独立請求項が配列番号で結合ドメインを特定している | 回避対象 |
| ⑥ | 審査係属中で権利が未確定 | 継続監視 |
この区分の要点は3つあります。
第一に、①と②を分けたこと。前述のファミリー問題を構造的に拾うための区分です。この2つを分けずに「失効特許」とひとまとめにすると、②の誤判定がそのまま成果物に残ります。
第二に、③という区分を設けたこと。有効な特許でも、独立請求項が「用途限定」「他のタンパク質との組み合わせ必須」「数値限定」といった構成になっていれば、こちらの実施形態では構成要件を充足しない可能性があります。ここを一律に「有効だから使えない」と切ると、実は使える配列をごっそり捨てることになります。
第三に、⑥を独立させたこと。係属中の出願は権利範囲が未確定なので、①〜⑤のどれとも性質が違います。今回はヒット件数の4割強が⑥でした。件数が多い区分なので、混ぜてしまうと全体像が歪みます。
手順を5つのフェーズに分ける
区分が決まれば、あとはそこに至る情報を順番に埋めていく作業です。
Phase 1：権利状況の取得
Google Patentsから各特許のLegal statusを取得します。Active / Pending / Abandoned / Expired など、表示されている文言をそのまま記録します。
ここで同時に、失効系の特許についてはファミリー各メンバーの権利状況も取得しておきます。Google Patentsのファミリー表には各行に状態が埋め込まれているので、まとめて拾えます。この一手間が①と②を分ける根拠になります。
Phase 2：請求項の分析
請求項に結合ドメインの配列が配列番号で特定されているかを、3値で判定します。
- 2：請求項に配列が配列番号で特定されている
- 1：配列番号による特定はないが、タンパク質名称の言及はある
- 0：言及がない
判定のロジックは「対象タンパク質名称を含む請求項の中で、配列番号を含む文を拾う」という素直なもので足ります。ただし配列番号が目的のタンパク質以外のドメイン、リンカー等を含むものを除外しないと、誤検出だらけになります。
Phase 3：明細書中の配列番号の特定
明細書本文から、対象タンパク質に関連する配列番号を拾います。同時に、その特許の明細書に配列本体が印刷されているかどうかも判定しておきます。ここで「配列表を別途取りに行く必要がある特許」のリストができます。
Phase 4：区分の確定
権利状況・請求項判定・ファミリー確認を組み合わせて①〜⑥を割り当てます。
③と⑤の切り分けだけは機械的にできません。有効かつ請求項に配列特定がある特許について、独立請求項を抽出して構成要素に分解し、想定する実施形態が充足するかを検討する必要があります。
Phase 5：配列の取得
公式の配列表から配列を抽出します。ここが本稿の核心なので、節を分けます。
配列表を自動で取得する
明細書本文から配列を読み取ろうとすると、精度が出ません。実際に試した範囲では、次のような誤りが高頻度で発生しました。
- 配列が途中で切れる（245残基のところが47残基になる）
- 同じ配列が2回描画されていて二重に連結される
- メチオニンの
MがIVIと誤読される（OCR由来と思われる） - 末尾の1残基が落ちる、次の「SEQ ID」という文字列が配列に混入する
FTO調査の成果物として誤った配列を渡すことは、何も渡さないより有害です。ですので公式配列表を取りに行くという方針に切り替えました。
その経路がこれです。
米国特許番号
→ Google Patents（Worldwide applicationsセクション）
→ WO番号を特定
→ PATENTSCOPE（WIPO）の詳細ページ
→ Documentsタブ
→ 配列表のTXT（またはST.26形式のXML）をダウンロードこの経路には、手作業では見えにくい大きな利点があります。
ファミリー集約が効きます。 米国特許を個別に見ていると別々の案件に見えても、遡ればひとつのPCT出願に行き着くことが多い。今回は米国特許の3分の2がWO出願に収束しました。取得すべきファイル数が3割減ったことになります。ある企業の3件の米国特許が1つのWOでカバーされた、というようなケースが複数ありました。
しかも同一ファミリーの配列表は配列番号も一致します。別々に取得した2つのファイルで、8つの配列番号すべてが完全一致することを確認しました。つまり1ファイルで複数特許分を賄えます。
生成AIにブラウザを操作させれば、この経路を自動で回せます。Google Patentsからの情報取得はページ遷移すら不要で、数十件でも数秒です。PATENTSCOPE側はクリック操作が必要ですが、これも自動化できます。
なお、ダウンロードされるファイル名は出願人の内部管理番号（48538_701_601_SL.TXT のような形式）で、どの特許のものか分かりません。配列表の冒頭にある出願人名と発明の名称を読んで紐付ける必要があります。これも自動化できる処理です。
生成AIに任せてよい仕事、任せてはいけない仕事
この調査を通じて、線引きが明確になりました。
任せてよい仕事
- 権利状況の一括取得（約150件を数分で完了）
- 請求項テキストの機械的なパターン判定
- 配列表ファイルのパース（ST.25、ST.26テキスト、ST.26 XMLの3形式に対応するパーサを一度書けば再利用できる）
- ファミリー関係の突合と重複排除
- 成果物の集計と検算
これらは、判断基準さえ明確に定義できれば、人間がやるより速く、かつ一貫性があります。約150件×5工程を人力でやれば数日仕事ですが、半日程度で回りました。
任せてはいけない仕事
- 非侵害の最終判断。③の区分について、生成AIには「独立請求項を構成要素に分解して列挙し、想定する実施形態で充足しないと考えられる要素を示す」ところまでをやらせ、結論は出させませんでした。事実の整理と法的判断を分ける設計です。
- 対象／対象外の最終判定。検索式にヒットしても目的のタンパク質とは限りません。今回は、目的タンパク質と結合するタンパク質の特許がヒットしていました。明細書に目的タンパク質名が頻出するため機械的には区別がつきません。逆に、タイトルが別のタンパク質でも従属請求項で対象タンパク質を特定している例もありました。タイトルだけで切ると取りこぼします。
要は、生成AIには「根拠を揃える」仕事をさせ、「判断する」仕事は人が持つという分担です。この線引きを最初に明示しておくと、成果物の信頼性が上がります。
実際に踏んだ落とし穴
一般化できるものを挙げます。
特許DBのエクスポートは途中で切れていることがある
請求の範囲が10,003文字で打ち切られていました。この状態で請求項を分析すると、配列番号を引いている独立請求項が後半にある場合に丸ごと見落とします。文字数が上限に張り付いている行を検出して、全文を取り直す工程が必要でした。
請求項の配列番号と明細書の配列番号が食い違うことがある
ある特許では、請求項が「配列番号14」としているのに、明細書上の配列番号14は別のドメインで、目的のドメインの実体は配列番号6でした。
また、PCT出願時の配列表と各国公報とで再採番されることがあります。PCT配列表が100配列しかないのに、米国公報の請求項は101番以降を引いている、というケースに遭遇しました。実体は同じクローンなのに番号だけがずれています。
大量データをブラウザから持ち出すときの制約
ブラウザ内でスクリプトを実行した結果は、一度に取り出せる量に上限があります。数百配列を扱うなら、分割して回収するか、ファイルに落として処理する設計にしておく必要があります。ページ全体を取り出そうとしないこと——特許ページは1件で数十万文字あります。
成果物の形
最終的に用意したのは2つです。
配列ファイル（FASTA形式）
>No 46 SEQ_ID_6|①_XXX_YYY|amino_acid US20XXXXXXXX
MQSGAAEVKKSPGSSVGKVSKCKASG...ヘッダーに、リスト番号・配列番号・区分・配列種別・文献番号を入れます。区分をヘッダーに埋め込んでおくと、後工程で「①だけ抜き出す」といった操作がそのままできます。
ファイル冒頭には、出典（公式配列表か否か）と調査範囲（対象国、一次スクリーニングである旨）をコメント行で明記します。時間が経ってから見た人が誤用しないための保険です。
内訳表（Excel）
区分別・特許別に集計した表です。あわせて、回避対象となる特許の一覧と、番号の食い違いなどの注記を別シートにまとめます。
内訳表の合計と配列ファイルのレコード数が一致することを必ず検算します。
まとめ
配列のFTO調査は、情報が散在しているために手間がかかる作業でした。生成AIを使うことで、この「散在した情報を集めて突き合わせる」部分を大幅に圧縮できます。
ただし、効果を出すために設計が必要な点が3つあります。
- 区分を先に決める。使える／使えないの二択ではなく、権利状況とクレーム構成の組み合わせで区分を定義する。特にファミリー生存の有無を独立した区分にする
- 公式の一次情報を取りに行く。二次的なテキストからの推定は、量が増えるほど誤りが混入します。取得経路を自動化すれば、一次情報を取るコストは十分下がります
- 判断と事実整理を分ける。生成AIには根拠を揃えさせ、法的判断は人が持つ。この線引きを最初に明示しておく
配列を扱う調査は、遺伝子治療のベクター配列、酵素の改変体、核酸医薬の配列など、今後さらに増えていくはずです。同じ枠組みがそのまま使えると思います。
