顧問先から届く「あの案件はいまどうなっているか」の問い合わせに、案件台帳と庁との往復書類を根拠にして回答案を作る

処理の起点を決める

問い合わせ用の共有メールボックスにメールが届いたことを起点にします。 担当弁理士の個人のアドレスに届いた問い合わせは、共有メールボックスへ転送する運用にします。入口を1つにしないと、送った回答が報告履歴として積み上がりません。

二つ目の起点は、案件管理システムの更新です。 台帳は毎晩、案件管理システムから書き出したファイルを検索基盤へ入れ直します。書類は、保管フォルダに新しい書類が保存されたときに本文を取り出して入れます。台帳は1日1回、書類はその都度という時間差が、後述の stale の印の出どころです。

三つ目は、回答の送信です。 送った回答を案件の報告履歴として書類の索引に加えます。送らなかった下書きは加えません。

入力データを集める

質を決めるのは、台帳の「現在の段階」と「最終更新日」です。 この構成は段階を台帳から読むので、台帳が正しくなければ回答は正しくなりません。段階の値は、「出願済み」「審査請求済み」「拒絶理由通知・応答期間中」「応答済み・審査待ち」「特許査定・登録料納付待ち」「登録済み」のように、事務所で決めた選択肢から選ぶ形にしておきます。 自由記述の段階は、検索でも回答でも扱えません。

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

検索基盤に2つの索引を作ります。 案件台帳の索引は1案件1文書、書類の索引は書類を段落の単位に分けた断片を1文書にします。どちらにも、顧問先ID、事務所の案件番号、担当チームの項目を持たせます。

担当チームの線引きは、文書レベルのセキュリティで入れます。 チームごとに検索用の利用者を作り、バックエンドロールとしてチームの名前を持たせます。ロールの文書レベルのセキュリティには、次のクエリを書きます。

{ "terms": { "team": [${user.roles}] } }

${user.roles} は、利用者のバックエンドロールを引用符付き・カンマ区切りで並べたものに置き換わります。連携の仕組みは、顧問先の担当チームの検索用の利用者で問い合わせるので、担当外のチームの案件は検索結果に1件も現れません。 検索の問いに「このチームの」と書く方法とは違い、問いの組み立てを誤っても線引きは崩れません。

候補の案件の検索は、次のような形にします。顧問先IDは filter に置き、すべての下位のクエリにかけます。

{
  "size": 5,
  "query": {
    "hybrid": {
      "filter": { "term": { "client_id": "K-0231" } },
      "queries": [
        { "multi_match": { "query": "電池 正極 共同 B社",
                           "fields": ["title", "co_applicants", "client_ref"] } },
        { "neural": { "title_embedding": { "query_text": "去年の秋に出した電池の件",
                                           "model_id": "…", "k": 20 } } }
      ]
    }
  }
}

team と client_id の項目は、keyword の型にします。 文書レベルのセキュリティの説明では、text の型の値にハイフンなどの記号が入ると、標準の解析器が値を分割して扱い、意図しない文書が絞り込みを通ることがあるとされています。「team-A」「K-0231」のような値はこれに当たります。

AIへ渡す前に整形する

1. 顧問先と担当チームの特定 … 送信元アドレスを対応表で引きます。見つからない、または複数の顧問先に当たるときは、ここで止めて事務担当に選ばせます
2. 引用部分の切り分け … 返信の連鎖で下に続く過去のメールは、手がかりとしてだけ使い、問い合わせの本文とは分けて渡します。古い問い合わせへの回答を作らないためです
3. 番号の形の正規化 … 「特願2025－012345」「2025-12345」のような表記を、台帳と同じ形にそろえてから検索します
4. 台帳の鮮度の確認 … 台帳の書き出しが前の晩に成功しているかを確かめます。失敗していれば、すべての回答案に「台帳が前日より古い」と印を付けます
5. 添付の扱い … 問い合わせに添付がある場合は検索に使わず、「添付あり」と知らせるだけにします

AIに処理させる

AIにさせる仕事は2つで、呼び出しも2回に分けます。 1回目は問い合わせから案件の手がかりを取り出すこと、2回目は決まった案件の台帳と書類だけを根拠に回答案を書くことです。

1行目がいちばん起きやすい失敗です。 書類を渡すと、生成AIは「拒絶理由通知が届いているので応答期間中です」と自分で段階を組み立てます。その通知がすでに応答済みの古いものでも、文は同じようにもっともらしくなります。 段階は台帳から渡し、文にするだけにします。

5行目も守秘に近い話です。 弁理士が確かめる前に回答案が「進歩性がないとの指摘です」と書けば、事務所として検討していない評価が顧問先に伝わります。

1回目の呼び出しでは structured outputs を使い、2回目では citations を使います。 Claude API では、この2つを同じ要求で使うと400のエラーが返るとされているためです。1回目は output_config.format にJSONスキーマを指定して手がかりを受け取り、2回目は台帳と書類の断片をそれぞれ citations を有効にした文書として渡します。文書の title と context は引用の対象にならないので、書類の種類と日付は context に入れ、本文だけを引用の対象にします。

指示内容を固定する

あなたは特許事務所で、顧問先の知財担当者からの問い合わせに答える回答案を作る担当です。
渡された「案件台帳の記録」と「書類」だけを根拠にしてください。

【問い合わせ】{inquiry_text}
【顧問先】{client_name}
【案件】{case_no}（この案件の記録と書類だけが渡されています）
【案件台帳の記録】{docket_record}   … 段階・次の期限・台帳の最終更新日
【書類】{documents}                 … 日付の新しい順。reported が false のものは未報告
【台帳が古い可能性】{stale_flag}

【作ってほしいもの】
1. 問い合わせで問われていること（1〜3個）
2. 顧問先の担当者に向けた回答案
3. 回答案の各部分の種類
   - docket ...... 案件台帳の記録に書いてあること
   - document .... 渡された書類に書いてあること
   - reported .... 過去に報告済みの内容を繰り返すこと
   - ask_attorney  担当弁理士の判断が要ること
4. 担当弁理士に確かめるべきこと

【厳守事項】
- 現在の段階は、案件台帳の記録の「段階」の値をそのまま使ってください。
  書類の内容から段階を判断したり、言い換えて別の段階にしたりしないでください。
- 審査の見通し、登録になる時期、応答の方針は書かないでください。
  問われている場合は ask_attorney とし、
  「担当弁理士から改めてご連絡します」とだけ書いてください。
- reported が false の書類は、書類の種類と日付だけを書いてください。
  内容の要約や評価は書かないでください。
- 期限の日付は、案件台帳の記録に書かれているものだけを使ってください。
  書類の日付から期限を計算しないでください。
- 【台帳が古い可能性】が true のときは、段階の文の末尾に
  「（台帳の更新前の情報の可能性があります）」と付けてください。
- 出願番号・案件番号は、渡された記録に書かれているものをそのまま写してください。
- 渡された記録と書類で答えられないことは、「記録からは確認できません」と書いてください。

「段階の値をそのまま使う」を、言い換えの禁止まで書いているのが要点です。 「応答済み・審査待ち」を「もうすぐ結果が出る見込みです」と言い換えれば、段階の文が見通しの文に変わります。 決まった値のまま書かせれば、台帳の画面と見比べるだけで確かめられます。

「期限を計算しない」を別に書いているのも同じ理由です。 応答期間は延長の有無で変わり、その事実は台帳にしかありません。書類の発送日から数えた期限は、延長を出した案件で必ず外れます。

出力形式を固定する

次の形のJSONを、連携の仕組みで組み立てます。 回答案の本文と根拠は2回目の呼び出しの citations の結果から取り、case_candidates と stale は検索と突き合わせの結果から入れます。

{
  "inquiry_id": "",
  "client_id": "",
  "team": "",
  "clues": {
    "case_no": "", "client_ref": "", "application_no": "",
    "title_terms": [""], "period": "", "co_applicants": [""],
    "asked": ["stage | deadline | document"]
  },
  "case_candidates": [ { "case_no": "", "title": "", "score": 0 } ],
  "resolved_case": "",
  "docket": { "stage": "", "next_deadline": "", "updated_at": "" },
  "stale": false,
  "answer_parts": [
    { "kind": "docket | document | reported | ask_attorney",
      "text": "",
      "sources": [ { "doc_type": "", "date": "", "link": "" } ] }
  ],
  "questions_to_attorney": [""]
}

1つ目の理由は、case_candidates と resolved_case を分けていることです。 候補が1件のときだけ resolved_case に入り、2件以上なら空のまま回答案を作りません。 通知の画面は候補の一覧と、顧問先に確かめる文の下書きになります。

2つ目は、docket を回答案と別に持つことです。 担当者は docket.stage を案件管理システムの画面と見比べ、回答案の段階の文と一致しているかだけを見れば足ります。

3つ目は、stale です。 台帳の最終更新日より新しい書類が書類の索引にあれば true にします。台帳の更新が追いついていない案件を、回答の前に見つける合図です。

システムへ連携する

案件管理システムへは書き込みません。 台帳が古いと分かっても、この構成は印を付けるだけで、段階を直すのは事務担当が案件管理システムの画面で行います。 検索基盤の写しから台帳を直す経路を作ると、写しの誤りが正へ逆流します。

チームごとの検索用の利用者には、読み取りの権限だけを与えます。 文書レベルのセキュリティは検索や取得のような読み取りを制限するもので、書き込みは制限しないとされています。索引への追加は、別の取り込み用の利用者で行います。

人が確認する

全件、事務担当が確認してから送ります。 確認の順番を決めておきます。

1. 顧問先と案件を見る … 通知の先頭に顧問先名と resolved_case の案件番号・発明の名称を出します。問い合わせの手がかりと合わなければ、以降は読まずに差し戻します
2. docket.stage を案件管理システムと見比べる … 回答案の段階の文と一致しているかを見ます
3. stale が true なら先に台帳を確かめる … 新しい書類が台帳に反映されていなければ、台帳を更新してから回答案を作り直します
4. ask_attorney を担当弁理士へ回す … 見通しや方針を問われた部分です。事務担当が埋めません
5. document の根拠を開く … 書類の原本で、その文が本当にそう書いているかを確かめます

2番目を省かないでください。 検索基盤の台帳は前の晩の写しで、今日の午前に段階を直していれば、写しはまだ古い値です。

例外に対処する

3行目の「チームを変えて検索し直さない」が、線引きを守る最後の工程です。 権限の広い利用者で探し直す分岐を作れば、文書レベルのセキュリティを入れた意味がなくなります。

記録を残す

• 問い合わせメールの原文と、特定した顧問先ID・担当チーム（自動で決めたか、人が選んだか）
• 1回目の呼び出しで取り出した手がかりのJSON
• 検索に使った利用者、検索の条件、返った候補の案件の一覧
• 回答案のJSONと、citations で付いた根拠の位置
• 台帳の最終更新日と stale の判定
• 事務担当と弁理士が直した箇所と、送った回答の全文

3つ目で「検索に使った利用者」を残すのは、線引きの証跡になるからです。 担当外の案件を見ていないことを後から示せます。