英文の譲渡証書・宣誓書を読み取り、発明者名・出願の特定・署名日を案件台帳と照らして、食い違いと署名漏れを手続きの前に拾う

処理の起点を決める

受付フォルダ（Amazon S3）に署名済みの書類が保存されたことを起点にします。 顧客から転送されたメールの添付は、担当者が案件番号を付けて入れます。電子署名サービスで署名を集めている案件は、署名の完了の通知で完成したPDFを受付フォルダに入れる仕組みを置きます。

届いた順に1通ずつ処理します。 署名し直しを頼むなら、早いほど発明者の手間が少なく済みます。発明者が出張や休暇に入る前に依頼が届くかどうかで、そろうまでの日数が大きく変わります。

さらに、毎週月曜に「手続きの予定が近いのに書類がそろっていない出願」の一覧を出します。 案件台帳の出願予定日、記録の申請の予定日、登録料の納付の予定日と、発明者ごとのそろい具合を照らします。米国特許法115条では、宣誓書等は登録料を納付する日までに提出するとされているので、納付の予定日は特に早めに見ます。

入力データを集める

質を決めるのは、台帳の発明者の綴りです。 照合は台帳の綴りと比べるので、台帳の綴りが誤っていれば、正しい書類が食い違いとして出ます。 「綴りの確認済みか」の列は、そのためにあります。確認済みでない発明者の食い違いは、どちらが正しいかを弁理士が決めるまで、どちらにも寄せません。

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

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

質問は書類全体に1つずつ聞くものに限ります。 発明者名と署名日は署名欄の数だけあるので、質問ではなく、FORMS のキーと値（Inventor:、Signature:、Date:）と、SIGNATURES の署名の位置から組み立てます。

署名の位置と名前の組は、ページ上の位置で決めます。 署名のブロックの枠と、Inventor のキーの値の枠が、同じ署名欄の範囲に入るかを座標で見ます。キーと値の一部として署名が返ればその組を使い、返らなければ座標で近いものを候補にします。

結果は1回最大1,000ブロックで区切られます。NextToken が返る限り呼び直し、最後のページの署名欄が抜けないようにします。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF であることを確かめます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけないとされています。電子署名サービスの出力でロックが掛かっているものは、ロックの無い版を取り直します
3. サイズとページ数の確認 … 非同期の処理で、PDFとTIFFは500MB・3,000ページまでです
4. スキャンの解像度の確認 … 文字の高さは最小15ピクセルで、150 DPIで8ポイントの文字に相当します。手書きの署名日は小さく書かれやすく、下回りやすい箇所です
5. 書類の分け方の確認 … 宣誓書と譲渡証書が1つのファイルなら、書類の表題でページを分けます
6. 案件の特定 … ファイル名の案件番号で台帳を引き、出願の前か後か、発明者の一覧を取り出します

6番目で「出願の前か後か」を決めておくのが大事です。 出願の後なら出願番号で、出願の前なら発明者の氏名と発明の名称で、書類が出願を特定しているかを見るからです。

AIに処理させる

させるのは、書類の種類と項目を取り出し、署名欄ごとに「名前・署名の有無・署名日」の組を作ることです。 照合と要件の判断はさせません。

発明者名は、書類に印字された名前を取ります。 署名そのものの筆跡から名前を読ませることはしません。署名は読める文字ではないことが多く、読ませると近い名前を作ります。

署名日の原文を残すのは、国で日と月の順序が違うためです。 05/06/2026 は5月6日にも6月5日にも読めます。署名日が出願日より前か後かで、譲渡証書の出願の特定の見方が変わるので、順序が決まらない日付は解釈させません。

3行目がいちばん起きやすい失敗です。 台帳の発明者名を一緒に渡すと、Johnathan を台帳の Jonathan にそろえて返し、そろえた瞬間に、出してはいけない綴りの書類が「一致」になります。 台帳の名前は渡さず、照合は Python で行います。

指示内容を固定する

あなたは特許事務所の外国出願の事務の担当で、海外の発明者から返送された
英文の譲渡証書・宣誓書の記載を記録する担当です。
OCRの読み取り結果だけを使ってください。推測で埋めないでください。

【取り出す項目】
document：doc_type（declaration / assignment / combined / other / unknown）、
          title_raw、app_no_raw、invention_title_raw、listed_inventors_raw、
          assignee_raw
signature_blocks：署名欄ごとに次を入れてください。
  printed_name_raw（印字された名前）、signature_detected（true / false）、
  signature_confidence、signed_date_raw、signed_date、status、
  source（ページと署名欄の位置）

【厳守事項】
- 名前は印字された文字列をそのまま入れてください。ウムラウトや
  アクセント、ミドルネームを足したり外したりしないでください。
- 署名の筆跡から名前を読み取らないでください。
- signature_detected は、読み取り結果に署名のブロックがあるときだけ
  true にしてください。署名欄の線や "Signature:" の文字だけでは
  true にしないでください。
- 署名日は日と月の順序が文面から決まるときだけ YYYY-MM-DD にし、
  決まらなければ空にして status を ambiguous にしてください。
  書かれていなければ missing にし、補わないでください。
- 書類が要件を満たすか、署名が本人のものかを書かないでください。
- 1つのファイルに複数の書類がある場合は、書類ごとに分けてください。

【読み取り結果】{textract_forms_queries_signatures}
【この案件が出願の前か後か】{filing_status}

「署名欄の文字だけでは true にしない」を明記しないと、true にします。 読み取り結果には Signature: という文字列と下線が確かにあり、何も言わなければそれを署名と見なします。署名の有無は、署名のブロックがあるかどうかという、OCRが返した事実だけで決めます。

出力形式を固定する

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

{
  "file": "",
  "case_no": "",
  "documents": [
    { "doc_type": "declaration", "app_no_raw": "", "invention_title_raw": "",
      "listed_inventors_raw": [], "assignee_raw": "",
      "signature_blocks": [
        { "printed_name_raw": "Anna Müller", "signature_detected": true,
          "signature_confidence": 0, "signed_date_raw": "June 5, 2026",
          "signed_date": "2026-06-05", "status": "ok", "source": "p2:B1" }
      ] }
  ],
  "request_draft": ""
}

1つ目の理由は、署名欄ごとの組が、発明者ごとのそろい具合の材料になることです。 Python が signature_blocks の名前を台帳の発明者に対応付け、宣誓書と譲渡証書の受領を発明者ごとに数えます。

2つ目は、照合をプログラムの側に置けることです。

3つ目は、出願ごとの「そろっていない発明者」の一覧が作れることです。 台帳の発明者の一覧から、宣誓書と譲渡証書の受領日が空の人を数えれば、書類が届かないまま手続きの予定日が近づいている出願が分かります。

システムへ連携する

案件台帳の受領日の列は、担当者が確かめてから人が埋めます。 照合の結果を自動で台帳に書き込むと、誤って ok になった書類が「そろった」ことになり、手続きが進みます。 台帳の発明者の綴りも、弁理士が決めたときだけ人が直します。

人が確認する

事務の担当者が開くのは、ok 以外の印が付いた書類です。 ok の書類は、名前と署名日を並べた一覧で流し見て、台帳の受領日を埋めます。

1. signature_missing を先に見る … 画像で署名欄が本当に空いているかを確かめます。電子署名の形式によっては、署名として検出されないことがあります
2. name_mismatch を弁理士に上げる … 書類と台帳のどちらの綴りが正しいかを決めてもらいます
3. app_id_mismatch を確かめる … 出願の前か後かの扱いが正しいか、書式の版が古くないかを見ます
4. 署名し直しの依頼を送る … 下書きを直して、顧客経由で発明者へ送ります

1番目で「検出されない」を「署名が無い」と決めつけないでください。 手書きの署名は検出されやすくても、電子署名サービスの署名の形は様々です。画像で確かめて署名があれば、その書式を記録して次から人が見る対象を減らします。

例外に対処する

上から5行目は、軽く扱わないでください。 台帳に無い名前の署名は、発明者の追加の可能性を示しています。発明者の名前の付け方は出願の根本に関わるので、事務の担当者ではなく弁理士が判断します。

記録を残す

• 元の書類と、受け取った日時、案件番号、送ってきた経路（顧客のメール、電子署名サービス）
• AWS Textract が返したJSONの全文（署名のブロックの位置と信頼度を含む）
• Claude API が返したJSON（署名欄ごとの組）
• 照合の結果と、そのとき参照した案件台帳の発明者の一覧と綴り
• 担当者や弁理士が印を覆した記録 … どの署名欄を、どう判断したか
• 署名し直しの依頼と、署名し直した書類との対応

台帳の綴りの版を残すのは、綴りが後から直されるためです。 弁理士が台帳の綴りを直すと、過去の照合の name_mismatch の意味が変わります。当時どの綴りと比べたかが残っていないと、どの書類を出し直すべきかが決まりません。