研究者から出る「この技術は他社の特許に触れないか、前に調べたか」の質問に、過去の侵害予防調査の報告書と知財部の見解を根拠に答え、新しい調査が要るものを知財の担当へ回す

処理の起点を決める

研究者が照会フォームを送信したことを起点にします。 自由なチャットの書き込みではなく、項目の決まったフォームにします。テーマの番号、仕様の版、出したい国が欠けた照会は、範囲を比べる材料がありません。 フォームの側で必須にしておけば、後段で「分からないので知財へ」と回す件数が減ります。

もう一つのトリガーは、要旨カードの登録です。 カードが Cloud Storage に置かれたら、メタデータの JSON Lines を更新してデータストアAに取り込み直します。取り込みは1日1回の夜間にまとめます。 調査の完了は月に数件なので、それで足ります。

入力データを集める

質を決めるのは、要旨カードの項目の書き方です。 特に調査日と対象の仕様の版と対象国は、文章ではなく値で書きます。 「2023年ごろ、試作2次までを対象」と書くと、比べられません。search_date: 2023-06-30、spec_version: 試作2次（図面 Rev.C）、countries: JP, US, CN のように、メタデータの項目として持ちます。

結論の区分は、知財部が決めた語だけを使います。 例えば「該当特許なし（調査日時点）」「回避設計済み」「要注意特許あり・対応中」「鑑定書あり」の4つです。AIに結論を言い換えさせないために、区分の語をカードにそのまま持たせ、回答にもその語を写させます。

テーマの対応表は、第3章の（a）への手当てです。 テーマの名前が途中で変わっても、旧名のカードを引けるように、照会のテーマ番号から旧番号を足して絞り込みます。

データの取得方法を決める

要旨カードは、1件ごとにテキストのファイルにして Cloud Storage に置きます。公式のドキュメントでは、非構造化データは TXT・PDF・HTML・DOCX などに対応し、1ファイル200MBまで、1回に10万ファイルまで取り込めます。 メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"fto-2023-031","structData":{"theme":["T-118","T-092"],
 "search_date":"2023-06-30","spec_version":"試作2次 Rev.C",
 "countries":["JP","US","CN"],"conclusion_label":"回避設計済み",
 "report_no":"FTO-2023-031","valid_review":"2025-06-30"},
 "content":{"mimeType":"text/plain","uri":"gs://fto-cards/fto-2023-031.txt"}}

照会のたびに、中継プログラムが絞り込みの条件を作ります。 公式のドキュメントでは、文字の項目は ANY() で列挙した値のどれかに完全に一致するかを見られ、AND／OR でつなぎ、NOT で否定できます。項目は、スキーマで索引可能にしておかないと絞り込みに使えません。

theme: ANY("T-118","T-092") AND NOT conclusion_label: ANY("取り下げ")

国と調査日では絞り込みません。 絞り込むと、国が足りない調査や古い調査が検索結果から消え、not_covered になります。研究者に返したいのは「調べた調査はあるが、この国は入っていない」という答えなので、カードは取ってきてから比べます。

検索の件数は maxReturnResults で決めます。公式では既定が10、上限が25です。ここでは10のままにします。 1つのテーマの調査は多くても数件です。

AIへ渡す前に整形する

1. テーマ番号の展開 … 照会のテーマ番号に、対応表から旧番号と統合元の番号を足します
2. 仕様の版の正規化 … 「試作2次」「2次試作」「Rev.C」の書き方を、知財部が決めた書式にそろえます
3. 国の正規化 … 「アメリカ」「米国」「US」を国コードにそろえます。「欧州」は、知財部の方針で国の一覧に展開します
4. 技術の内容の長さの確認 … 短すぎる照会（50字未満）は、研究者に書き足しを頼みます
5. 固有の番号の除去 … 照会に他社の特許番号が書かれていたら、検索の質問文からは外し、知財部への転送の欄に移します
6. 重複の確認 … 同じ研究者から同じテーマの照会が7日以内にあれば、前の回答を添えて知財部に回します

5番目は見落としやすい処理です。 研究者が「この特許に触れないか」と特定の番号を書いてくる照会は、調べ済みかどうかではなく、その特許そのものの評価を求めています。 これは要旨カードでは答えられないので、not_covered として知財部へ回します。

AIに処理させる

させるのは、技術の内容が近い要旨カードを探し、カードの記載を引用して、調べた範囲を並べることだけです。

4つ目の「させること」が、AIにしかできない部分です。 照会の技術が「樹脂Aと充填材Bの組み合わせ、成形温度を下げた」で、カードの観点が「樹脂Aと充填材Bの組み合わせ」なら、成形温度の条件が観点の外にあることを挙げさせます。 ここは値では比べられません。挙がった違いは、知財部が見て、追加の調査が要るかを決めます。

指示内容を固定する

answer メソッドの promptSpec の preamble に、次の指示を書きます。公式では、回答をカスタマイズするための自然文の指示とされています。

あなたは知財部の窓口として、研究者からの照会に答える立場です。
検索結果の「要旨カード」に書かれていることだけを使って答えてください。

【答えること】
1. 照会の技術に近い調査があるか。あれば調査番号を挙げる
2. その調査の観点、対象の仕様と版、調査日、対象国を、カードから写す
3. 結論の区分を、カードの語のまま写す
4. 照会の技術にあって、カードの調査の観点に書かれていない要素を挙げる

【厳守事項】
- 他社の特許に触れるか、触れないかを書かないでください。
- 「問題ない」「進めてよい」「安全」「リスクは低い」と書かないでください。
- 結論の区分を言い換えないでください。「回避設計済み」は
  「回避設計済み」と書いてください。
- 調査がいまも有効かどうかを書かないでください。
  調査日と版と国を写すだけにしてください。
- カードに書かれていない特許番号、会社名を書かないでください。
- 近い調査が無いときは「該当する調査は見つかりませんでした」とだけ書き、
  推測で近い調査を挙げないでください。
- 照会の技術にあってカードの観点に無い要素は、
  見つけた分をすべて挙げてください。迷ったら挙げてください。
- 最後に必ず次の一文を付けてください：
  「この回答は過去の調査の範囲を示すもので、特許に触れるかどうかの
  判断ではありません。進めるかどうかは知財部に相談してください。」

「迷ったら挙げる」を明記しないと、AIは観点の違いを小さく見積もります。 似た技術ほど「同じ観点の範囲内」と書きたがります。挙げすぎて困るのは知財部の確認が1件増えることですが、挙げ損ねて困るのは調べていない技術で製品が出ることです。 誤りの重さが違うので、片側に倒します。

あわせて、ignoreAdversarialQuery と ignoreNonAnswerSeekingQuery を有効にし、照会ではない書き込みに回答を作らせません。ignoreLowRelevantContent も有効にして、関係の薄いカードから回答を作らせません。

出力形式を固定する

answer メソッドの返り値を、中継プログラムが次の形のJSONにまとめます。

{
  "inquiry_id": "",
  "theme": "",
  "matched_cards": [
    { "report_no": "", "search_date": "", "spec_version": "",
      "countries": [], "conclusion_label": "", "quote": "" }
  ],
  "gaps": [
    { "type": "date | spec | country | scope", "detail": "" }
  ],
  "coverage": "covered | partial | not_covered",
  "answer_text": "",
  "route": "answered | ip_review",
  "skipped_reason": ""
}

matched_cards は、answer メソッドの references から取ります。公式では、references の chunkInfo に本文の断片と文書のメタデータが入り、citations の sources が referenceId で references を指します。quote には、引用の位置に当たる原文を入れます。 引用の位置（startIndex／endIndex）は文字数ではなく UTF-8 のバイト数なので、日本語の文で文字数として切り出すとずれます。

gaps は、AIではなく中継プログラムが作ります。

coverage の決め方は単純です。 カードが1件以上あり gaps が空なら covered、カードがあって gaps があれば partial、カードが無ければ not_covered です。JSONにする理由は、この判定を規則で行うためです。 answer_text の文章だけでは、どこが範囲外かを機械で拾えません。

answerSkippedReasons に NO_RELEVANT_CONTENT や LOW_GROUNDED_CONTENT が返ったときは、skipped_reason に写して not_covered にします。

システムへ連携する

待ち行列の1行には、照会の内容、見つかったカード、gaps、データストアBで同じ質問を検索した上位の報告書を付けます。 知財部の担当者は、探すところからではなく、読むところから始められます。

知財管理システムには書き込みません。 新しい調査を企画するかは、知財部が決めて、いつもの手順で案件を起こします。

人が確認する

人が確認するのは、partial と not_covered の照会です。 covered の回答は研究者に直接返しますが、運用を始めてから2か月は、covered も含めて全件を知財部が見てから返します。

1. partial の gaps を読む … 日付・版・国・観点のどれが外れたかを見ます
2. 報告書の本文を確かめる … scope が挙がったものは、データストアBで報告書の観点の章を開き、本当に観点の外かを確かめます
3. 追加の調査の要否を決める … 決めた結果と理由を待ち行列の行に書きます
4. 研究者へ返す … 「追加の調査を企画する」「この範囲なら過去の調査で足りる」と、知財部の名前で返します

2か月の全件確認で見るのは、covered で返したものの中に、知財部が見れば partial にしたものが無いかです。 あれば、カードの観点の書き方が粗いか、AIが観点の違いを挙げ損ねています。1割を超えるなら、covered の自動返信を始めません。

例外に対処する

6行目の禁止の語の検知は、プロンプトとは別に、中継プログラムの文字列の照合で行います。 プロンプトで禁じても、言い換えて書くことがあります。最後の門は機械の照合に置きます。

記録を残す

• 照会の内容（6項目）と照会者、日時
• answer メソッドへの要求（絞り込みの条件、preamble の版）と返り値の全文
• matched_cards、gaps、coverage、route
• そのとき参照した要旨カードの版 … カードは書き直されるので、版の番号で残す
• 知財部が判定を変えた記録 … covered を partial に変えた、など
• 研究者へ返した文と、返した日時

4つ目の「カードの版」は、後から問われたときのためです。 「あのとき知財部は調査済みと答えた」と言われたとき、その日のカードに何が書かれていたかを示せないと、回答の正しさを確かめられません。

保存先は Cloud Storage の、知財部だけが読める場所にします。 照会の記録には、研究中の技術の内容が書かれています。