現地代理人から届く英文の審査経過の報告レターを読み取り、応答期限・指示事項・費用の見込みを案件台帳に転記する

処理の起点を決める

起点は2つあります。レターが届いたときと、毎朝の定時です。

1つ目は、受付フォルダ（Amazon S3）に報告レターのPDFが保存されたことです。共有受信箱のルールで、登録した代理人のアドレスから届いたメールの添付をS3へ転送します。保存の通知で AWS Lambda が動き、読み取りから台帳への記録までを済ませます。届いた日に読むので、指示の締切までの日数を最大限残せます。

2つ目は、毎朝9時の定時です。台帳のうち、期限の候補が期限管理システムにまだ入っていないもの、指示の締切まで2週間を切ったのにクライアントの指示が無いものを一覧にして、事務スタッフと担当の弁理士に送ります。候補のまま放置された期限を、台帳の側で拾います。

入力データを集める

質を決めるのは、期限の規則の一覧です。 たとえば USPTO の審査便覧では、本案の通知への応答は3か月の短縮法定期間で、期間の末日が土曜・日曜・連邦の休日に当たれば、次の営業日の応答で期限内とされています。国と通知の種類の組ごとに、こうした規則を1行で持ちます。 規則の無い組の案件は、計算をせずに人に回します。

代理人の整理番号も欠かせません。 レターには自所の整理番号が書かれていないことがあり、代理人の整理番号か出願番号から案件を引けるようにしておきます。

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

読み取りは StartDocumentAnalysis にS3の場所と FeatureTypes を渡して始めます。完了は NotificationChannel に指定した Amazon SNS のトピックに通知され、状態が SUCCEEDED なら GetDocumentAnalysis で結果を取ります。

質問の答えが見つからなければ空のまま返ります。 期限が空なら、全文から deadline、respond by、due、months from を含む行を探します。それでも無ければ missing にし、発送日から計算した値で埋めることはしません。

結果は1回最大1,000ブロックで区切られ、NextToken が返る限り呼び直します。レターは添付の通知の写しを含めて数十ページになることがあり、非同期で読みます。 写しのページは質問の対象から外し、QueriesConfig の Pages で本体のページだけに質問を向けます。

案件台帳、期限の規則の一覧、期限管理システムの出力は、Python が読みます。 生成AIには渡しません。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます。メール本文に報告が書かれているものは、本文をPDFにして入れます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。保護されたものは代理人に解除したものを頼みます
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. 本体と添付の分離 … レター本体のページと、庁の通知の写し・引用文献のページを分けます。英字がほとんど出ないページは添付として扱います
5. 代理人の特定 … 送信元のアドレスから代理人を決め、その代理人の国と書式の癖（日付の書き方など）を引きます
6. 重複の検知 … 同じ出願番号・同じ発送日のレターがあれば、続報か再送として印を付けます

5番目の「日付の書き方」を代理人ごとに持つのが、日付の取り違えを防ぐ近道です。 同じ代理人はいつも同じ書き方をするので、決まった書き方の代理人のレターでだけ、日と月の順序を確定させます。

AIに処理させる

させるのは、レターから9つの項目を取り出し、原文の文字列と、日付や金額の解釈を分けて書き出すことです。 期限の計算と照合はさせません。

庁の期限と指示の締切を別の項目にするのが、いちばん大事な区別です。 1つの「deadline」として取ると、早い方の日付だけが残るか、遅い方の日付だけが残ります。 どちらが消えても事故になります。

期限が複数書かれているレターもあります。 「3か月の期限、延長すれば6か月まで」と並ぶと、どちらを応答期限とするかで台帳が変わります。選ばせずに両方を並べ、どちらを正式とするかは規則と人で決めます。

指示内容を固定する

あなたは特許事務所の外国部で、海外の現地代理人から届いた英文の
報告レターの記載を記録する担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
application_no、our_ref、associate_ref、action_type_raw、
mailing_date_raw、mailing_date、official_deadline_raw（配列）、
official_deadline（配列）、instruction_due_raw、instruction_due、
extension_raw、instructions_needed（配列）、cost_raw、cost_min、
cost_max、cost_currency、cited_refs（配列）、
各項目の status と source（ページと行）

【status の選び方】
- ok ........... 値が読み取れており、その項目として解釈できる
- missing ...... 書かれていない
- unreadable ... 文字は検出されているが値として確定できない
- ambiguous .... 候補が複数ある、または日付の順序が決まらない

【厳守事項】
- 庁への応答期限と、代理人が指示を求める締切は別の項目です。
  混ぜたり、片方で他方を埋めたりしないでください。
- 期限が複数書かれていれば、すべてを配列に並べてください。
  どれが正式な期限かを選ばないでください。
- 日付は、日と月の順序が文面または {date_style} から確定できるときだけ
  YYYY-MM-DD で入れてください。決まらなければ空にし、ambiguous にしてください。
- 期限が書かれていない場合は missing にしてください。
  発送日から計算して埋めないでください。
- 応答の方針や、費用が妥当かを書かないでください。
- 報告レターでない書類（請求書、受領の連絡、引用文献など）と判断した場合は、
  項目を取り出さず document_type に種類を書いてください。

【読み取り結果】{textract_forms_tables_queries}
【この代理人の日付の書き方】{date_style}

「発送日から計算して埋めない」を明記しないと、埋めます。 期限の欄が空で発送日が読めていると、3か月を足した日付を期限として返し、その値は後段の計算と必ず一致するので、照合で食い違いが出ません。 照合を無意味にする失敗なので、指示で止めます。

出力形式を固定する

Claude API の構造化出力（output_config.format に json_schema を指定）で、次の形のJSONを受け取ります。

{
  "file": "",
  "document_type": "oa_report_letter",
  "application_no": "18/123,456",
  "our_ref": "P26-0412US",
  "associate_ref": "",
  "action_type_raw": "Non-Final Office Action",
  "mailing_date_raw": "September 22, 2026",
  "mailing_date": "2026-09-22",
  "official_deadline_raw": ["December 22, 2026", "March 22, 2027 (with extension fees)"],
  "official_deadline": ["2026-12-22", "2027-03-22"],
  "instruction_due_raw": "November 24, 2026",
  "instruction_due": "2026-11-24",
  "extension_raw": "extendable up to three months upon payment of fees",
  "instructions_needed": ["whether to amend claim 1 as proposed", "whether to request an interview"],
  "cost_raw": "USD 2,500 - 3,500",
  "cost_min": 2500, "cost_max": 3500, "cost_currency": "USD",
  "items": [
    { "item": "official_deadline", "status": "ambiguous", "confidence": 0, "source": "p1:L14" }
  ]
}

1つ目の理由は、照合をプログラムの側に置けることです。 Python が案件台帳で案件を引き、規則の一覧で発送日から期限を計算して、レターの期限と比べます。

2つ目は、期限を配列で持てることです。 延長前と延長後の期限が並ぶレターでも、規則で計算した期限と一致したものを「延長前の期限」とし、もう1つは延長の上限として記録します。

3つ目は、source で根拠をたどれることです。 事務スタッフは画像のその行だけを見れば、期限の原文を確かめられます。

システムへ連携する

期限管理システムへは書き込みません。 正式な期限を入れるのは、これまでどおり事務スタッフで、二重確認の手順も変えません。 この構成は、二重確認の1人目の前に「規則で計算した期限と一致したか」という3つ目の目を置くものです。

人が確認する

事務スタッフが開くのは、match 以外の印が付いた案件です。 match の案件も、期限管理システムへ入れるときにはレターの画像の期限の行を確かめます。

1. deadline_mismatch を最初に片付ける … 規則の側の誤りか、レターの側の誤りかを確かめます。レターの側なら代理人に問い合わせます
2. needs_human の日付を確定させる … 順序が決まらない日付を画像で確かめます
3. 期限を期限管理システムに入れ、二重確認を受ける … 庁の期限と指示の締切の両方を入れます
4. 弁理士が報告の下書きを直してクライアントに送る … 指示が要る事項と費用の見込みを添えます

1番目で、規則の一覧が間違っていたと分かることがあります。 一覧を直すのは弁理士の確認を経てからにし、直した理由を一覧の版に残します。

例外に対処する

上から3行目と4行目が、期限の事故のほとんどを生みます。 どちらも期限という1つの値の問題で、ここを人に回す設計を崩すと、照合そのものが当てにならなくなります。

記録を残す

• 元の報告レターと、受け取った日時、代理人、メールの件名
• AWS Textract が返したJSONの全文と、使った質問の一覧
• Claude API が返したJSON（原文と解釈の両方）
• 照合の結果と、そのとき参照した規則の一覧の版
• 事務スタッフが期限を確定させた記録 … どの値を、どう確定させたか、誰が二重確認したか
• 代理人への問い合わせと、その回答

4つ目の「規則の一覧の版」を残すのは、規則が後から変わるためです。 一覧を直すと過去の照合の意味が変わり、当時の規則が残っていないと、どの案件を見直すかが決まりません。