海外の特許事務所から届く英文の請求書から、案件番号・作業の内容・金額・通貨を抜き出して案件ごとの費用台帳にそろえ、見積との差を拾う

処理の起点を決める

請求書の受付用メールアドレスに、PDFの添付があるメールが届いたことを起点にします。 Make の Gmail の Watch emails は、見張るフォルダやラベルを選び、条件で絞り込めます。「添付のあるメールだけ」に絞り、1回に扱う件数は最大の結果の数で決めます（500以下）。

受付用のアドレスは、請求書専用にします。 事務所との通常のやりとり（拒絶理由の報告や指示の確認）と同じアドレスで受けると、報告に添付された見積や庁の書類まで請求書として読もうとします。 事務所には、請求書だけを専用のアドレスに送るよう依頼します。

処理が終わったメールには、ラベルを付けます。 Make の Gmail には、メールのラベルを更新するモジュールがあります。「処理済み」のラベルは、台帳への書き込みが最後まで終わったときだけ付けます。 ラベルの無いメールの数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、案件の対応表と段階の一覧です。 対応表が無ければ、事務所の整理番号しか書かれていない請求書を自社の案件に結びつけられません。段階の一覧が無ければ、Claude は作業の説明から段階をそれらしく決め、担当者ごとの判断のばらつきがAIのばらつきに置き換わるだけです。

段階の一覧は、見積の段階と同じ区切りにします。 見積が「国内段階への移行」「審査請求」「拒絶理由への応答」「登録」「年金」で書かれているなら、台帳も同じ5つに分けます。区切りが違うと、累計と見積を比べられません。

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

Watch emails で届いたメールから、添付の一覧を取り出し、Iterator で1つずつに分けます。 Make の Iterator は配列を一連のバンドルに変える特別なモジュールで、メールの添付を1つずつ扱う例が公式のヘルプにあります。1通のメールに請求書が2枚付いていることがあるので、Iterator は必ず置きます。

PDFでない添付は、ここで外します。 事務所によっては、請求書と一緒に庁の受領書の画像や、明細の表計算のファイルを付けてきます。ファイル名の拡張子が .pdf のものだけを先へ送り、それ以外は担当者に知らせます。

PDFは base64 で符号化して、Messages API の document のブロックに入れます。 Make an API Call の本文に、モデル、最大トークン数、メッセージ（document のブロックと指示の文）、そして output_config.format に JSON スキーマを書きます。base64 への符号化は、Make の関数で行います。

案件の対応表は、Google Sheets の Search Rows で引きます。 引く順番は、自社の番号（Your Ref）が先、事務所の整理番号（Our Ref）が後、出願番号が最後です。自社の番号は書き方がばらついても桁の並びが同じなので、ハイフンと空白を除いてから引きます。

AIへ渡す前に整形する

1. 送信元の確認 … 送信元のアドレスが事務所の一覧にあるかを確かめます。無ければ処理せずに担当者に知らせます
2. 形式の確認 … PDFであることを確かめます
3. サイズとページ数の確認 … 1回の要求の上限は32MBです。数十ページの請求書（年金の一括請求など）は、明細のページだけを分けて渡すことを検討します
4. 暗号化の確認 … パスワードや暗号化のかかったPDFは対象外です。事務所に、パスワード無しで送り直してもらいます
5. 重複の確認 … 同じ事務所・同じ請求番号の請求書が台帳にあれば、二重に入れません

3番目の年金の一括請求は、ほかの請求書と別の扱いにします。 年金の管理を事務所にまとめて任せていると、1枚に数十件の案件が並ぶ請求書が届きます。これを1回で渡すと出力が長くなり、途中で切れることがあります。 一括請求の事務所は事務所の一覧に印を付け、ページを分けて渡します。

5番目は、事務所が同じ請求書を催促として送り直してきたときに効きます。 請求番号が同じなら、台帳には入れず、催促が来たことだけを担当者に知らせます。

AIに処理させる

Claude にさせるのは、請求書に書かれていることを、決まった項目に分けて写すことだけです。

右端の列が、この構成でいちばん大事なところです。 unknown と null の行は、案件と段階が確かでないので、累計に入れません。 推測で段階を埋めると、見積との比較そのものが誤ります。

合計は、明細の合計とは別に写させます。 明細の金額の和と、請求書の合計の欄が一致するかは、Make の側で計算して確かめます（例外処理の表を参照）。一致しなければ、明細の抜き出しに漏れか重複があります。

最後の行がいちばん起きやすい失敗です。 自社の番号の1桁が読みにくいとき、それらしい番号に寄せると、別の案件の費用台帳に積み上がり、その案件が見積超過に見えます。 案件の特定は、書かれた文字列を対応表で引く規則の側に置きます。

指示内容を固定する

You are assisting the IP department of a Japanese company.
Read the attached invoice from a foreign patent law firm and copy its contents
into the JSON schema. Copy only what is written. Do not guess.

[Stages] Choose one stage for each line from this list:
- national_phase_entry : entering the national/regional phase, filing
- examination_request  : requesting examination
- office_action        : reviewing, reporting, responding to an office action,
                         interviews, amendments
- grant                : allowance, issue fee, grant, registration
- annuity              : annuity, renewal, maintenance fee
- unknown              : none of the above, or you are not sure

[Fee type] service_fee / official_fee / disbursement / unknown

[Rules]
- Copy reference numbers exactly as written (our ref, your ref,
  application number). Do not correct or complete them.
- Copy the line description exactly as written in "description".
- Amounts: numbers only, in the invoice currency. Do not convert currencies.
- If the invoice does not state a value, use null.
- If a line covers several cases, split it only when the invoice
  shows a separate amount for each case. Otherwise keep one line
  and set stage to "unknown".
- Copy the invoice total from the total field into "invoice_total".
  Do not calculate it.
- Do not judge whether the fees are reasonable.
- If the document is not an invoice (receipt, cost estimate, report),
  set document_type accordingly and leave lines empty.

指示を英語で書いているのは、請求書が英語だからです。 段階の名前と作業の英語の言い方を同じ言語で並べると、「Reviewing Office Action and reporting」のような説明を、どの段階に当てるかが安定します。 段階の一覧は、運用しながら事務所ごとの言い方を足していきます。

「見積（cost estimate）なら明細を空にする」を入れているのは、事務所が見積を請求書と同じ書式で送ってくることがあるからです。 見積を請求として台帳に入れると、まだ発生していない費用が積み上がります。

出力形式を固定する

次の形のJSONで受け取ります。 output_config.format に JSON スキーマを指定する構造化出力を使います。

{
  "document_type": "invoice | credit_note | cost_estimate | other",
  "firm_name": "",
  "invoice_no": "",
  "invoice_date": "",
  "due_date": "",
  "currency": "USD",
  "invoice_total": 0,
  "lines": [
    { "our_ref": "", "firm_ref": "", "application_no": "",
      "description": "",
      "stage": "office_action",
      "fee_type": "service_fee",
      "amount": 0 }
  ]
}

構造化出力を使う理由は、stage と fee_type を列挙型で縛れることです。 決めた値の外の言葉が返ってくると、Make の側の累計の条件に引っかからず、その行が静かに集計から落ちます。 構造化出力では、オブジェクトの additionalProperties を false にする必要があり、数値の範囲や文字数の制約は使えないとされています。金額が0以上かどうかの確認は、Make の側で行います。

document_type に credit_note を持たせているのは、減額の請求書があるからです。 事務所が請求の誤りを直すとき、マイナスの金額の請求書（クレジットノート）を送ってきます。金額はマイナスのまま台帳に入れ、累計から差し引きます。

費用台帳の1行は、明細の1行です。 列は、受付日、事務所名、請求番号、請求日、自社の案件番号、国、段階、費用の種類、通貨、金額、作業の説明、確からしさの印（確定／要確認）、確認者です。

システムへ連携する

Add a Row では、「列の見出しを列のIDとして使う」をはいにします。 公式のヘルプでは、はいにすると見出しの名前が列のIDになり、列の並びを入れ替えても名前を変えない限り崩れないとされています。費用台帳は経理や予算の担当も列を足すので、位置で指定すると書き込む列がずれます。

値の入れ方（Value input option）は「Raw」にします。 「User entered」にすると、画面で打ち込んだのと同じように解釈され、請求番号や出願番号が数値や日付に変わることがあります。

知財の案件管理システムには書き込みません。 台帳はスプレッドシートに置き、案件管理システムの費用の欄への反映は、月に1回、確定した行だけを担当者が行います。

人が確認する

人が見るのは、「要確認」の行と、見積の8割を超えた案件だけです。

1. 要確認の行を直す … 案件を特定できなかった行、段階や費用の種類が unknown の行を、PDFを見て直します。直したら確定の印を付け、累計に入ります
2. 明細の合計と請求書の合計が合わない請求書を見る … 抜き出しの漏れか重複を、PDFと見比べて直します
3. 見積を超えた案件を判断する … 事務所に理由を尋ねるか、予算を見直すかを決めます。尋ねるメールは担当者が書きます
4. 見積の8割を超えた案件に目を通す … まだ超えていない案件で、次の請求で超えそうなものを先に知っておきます

1番目の直し方を記録します。 どの事務所のどの言い方を、どの段階に直したかを残し、同じ直しが続けば段階の一覧に言い方を足します。 一覧が育つほど、unknown は減ります。

目標は、150枚をならして1枚6分です。 要確認の行が無い請求書は、台帳の行を流し見るだけで終わります。

例外に対処する

上の3行が大半を占めます。 どれもAIの読み取りの問題ではなく、対応表と見積の一覧の整備の問題です。 対応表に事務所の整理番号を足していくほど、要確認の行は減ります。

記録を残す

• 元のメールとPDF（受付用のメールボックスに残す）
• Claude に渡した要求の内容（PDFを除く）と、返ってきたJSONの全文
• 費用台帳の各行と、確定／要確認の印、確認者、直した内容
• 段階を直した記録 … どの事務所のどの説明を、どの段階に直したか
• 見積との比較の結果と、そのとき使った見積額
• 事務所に理由を尋ねた日と、返ってきた理由

5つ目で「そのとき使った見積額」を残すのは、見積が後から出し直されるためです。 事務所が見積を改めたとき、どの時点の見積で超過と判断したかが残っていないと、尋ねた理由の筋が後から分からなくなります。