特許事務所から届く庁通知の報告を読み取って、案件台帳の応答期限を更新する

処理の起点を決める

共有メールボックスにメールが届いたことを起点にします。 Office 365 Outlook コネクタの「新しいメールが届いたとき」系のトリガーを使います。

1つ目の注意は、添付ファイルを含める設定を「いいえ」にすることです。 Include Attachments を「はい」にすると、すべての添付のダウンロードを待ち、多数のメールが同じ時間に届くとタイムアウトする可能性があるとされています。示されている回避策は、「いいえ」にして「添付ファイルの取得 (V2)」を使う方法です。

2つ目は、後からフォルダーへ移したメールは拾われないことです。 トリガーは受信日時に基づき、別のフォルダーに移しても受信日時は変わらないため、最新の実行より前に受信したメールはスキップされるとされています。手で監視フォルダーへ移す運用にすると、移したメールが処理されないまま残ります。

トリガーにはまれに最大1時間の遅延があるともされています。そのため、毎朝の一覧を作る前に、前日に届いた通数と処理した通数を突き合わせます。

入力データを集める

質を決めるのは、台帳の整理番号の列です。 報告に必ず書かれているのは事務所の整理番号で、自社の案件番号は書かれていないことがあります。この列が空欄の案件は、報告を読み取れても台帳のどの行か決まりません。

事務所の一覧に整理番号の書式の例を持たせるのは、読み取りの手がかりにするためです。 「P2024-0123」のように事務所ごとに形が決まっているので、書式に合わない文字列を整理番号として拾う誤りを後段で弾けます。

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

メールが届いたら、ワークフローは次の順で動きます。

1. 差出人を事務所の一覧とドメインで照らす … 一覧に無い差出人は処理しません
2. 添付ファイルを取り出す … 「添付ファイルの取得 (V2)」で、メッセージIDと添付ファイルIDを指定します
3. 本文と添付を両方OCRへ渡す … 期限が本文にだけ書かれている事務所があるため、本文もHTMLのまま読み取りに回します
4. レイアウトモデルを呼ぶ … outputContentFormat=markdown でMarkdown出力を指定します。表の構造を保ったまま生成AIへ渡せるので、発送日の列を期限として読む誤りが減ります

庁の通知書の写しが後ろに綴じられたPDFでは、pages パラメーターでページ範囲を指定し、まず報告の部分だけを読みます。 期限が見つからなかったときだけ全ページを読み直します。

AIへ渡す前に整形する

1. 差出人と件名の確認 … 事務所の一覧に無い差出人、件名に「期限のお知らせ」「リマインド」を含むものに印を付けます。催促のメールは新しい通知ではありません
2. 形式の確認 … PDF、画像、Word、HTML 以外の添付は処理せずに担当者へ回します
3. パスワードの確認 … ロックされたPDFは提出前にロックを解除する必要があるとされています。解除の方法を事務所と先に決めます
4. スキャンした報告の確認 … 画像の寸法は縦横50ピクセルから10,000ピクセルの間、テキストの最小高さは横1024・縦768ピクセルの画像で12ピクセル（150dpiで約8ポイント）とされています。紙をスキャンして送ってくる報告は、この下限に近いことがあります
5. 重複の検知 … 整理番号、書類の種類、発送日が同じものが直近にあれば、既処理として印を付けます
6. 暗号化メールの確認 … 暗号化メールでは、トリガーの出力に本文が含まれないとされています。本文が空のものは担当者へ回します

4番目を軽く見ないでください。 日付の「8」と「3」、「1」と「7」が読み違えられると、期限が5日ずれても形式の検査は通ります。 単語ごとの信頼度を日付の数字だけ取り出して見るのは、このためです。

AIに処理させる

させるのは、報告に書かれた値を、書かれたとおりに抜き出すことだけです。 抜き出す項目は次のとおりです。

応答期限と指示の締切を別の項目にしているのが、この表のいちばん大事な点です。 多くの事務所は、庁への応答期限より前に「○日までにご指示ください」と書きます。2つの日付を1つの項目で受けると、どちらかが黙って捨てられます。

書類の種類は5区分に絞ります（プロンプト参照）。区分は台帳のどの期限欄に入れるかを決めるためのもので、細かく分けすぎると当てはまらない書類が無理に寄せられます。

2行目がいちばん起きやすい失敗です。 発送日だけが書かれた報告を渡すと、「一般的な期間」から期限を計算して埋めようとします。その瞬間、事務所に確認すべき報告が、正しそうな期限を持った報告に変わります。

指示内容を固定する

あなたは知財部で、特許事務所から届いた受領報告を読み取る担当です。
下の読み取り結果に書かれている値だけを、書かれているとおりに抜き出してください。

【抜き出す項目】
1. 事務所の整理番号（firm_ref）
2. 自社の案件番号（client_ref）… 「貴社整理番号」「御社番号」などの欄
3. 出願番号（application_no）と国（country）
4. 書類の種類（doc_type）… 次のどれか1つ
   office_action / invitation_to_correct / decision_to_grant /
   decision_of_rejection / other
   other のときは doc_title に報告に書かれた書類名をそのまま入れる
5. 発送日（dispatch_date）
6. 庁への応答期限（reported_deadline）
7. 事務所が依頼人に求める指示の締切（instruction_due）

【厳守事項】
- 期限を計算しないでください。発送日から期限を求めることは禁止です。
  報告に応答期限が書かれていなければ reported_deadline は null とし、
  deadline_status を "not_stated" にしてください。
- 「ご指示ください」「ご回答ください」に続く日付は instruction_due です。
  reported_deadline に入れないでください。
- 日付が複数あり、どれが応答期限か決められないときは
  deadline_status を "ambiguous" にし、候補をすべて candidates に並べてください。
- 延長後の期限が併記されているときは、延長前の期限を reported_deadline に、
  延長後の期限を extended_deadline_as_written に、書かれたとおり入れてください。
  延長するかどうかを判断しないでください。
- 日付は raw に書かれたとおりの文字列を写し、iso に年-月-日の形で入れてください。
  和暦はそのまま raw に写してください。
  日と月の並びが決められない日付（例: 03/04/2027）は iso を null にしてください。
- 整理番号・出願番号は、桁を補ったり記号を直したりしないでください。
- evidence には、その値を読んだ文字列をそのまま写してください。
- 受領報告でない書類（請求書、挨拶状など）と判断したら、
  is_notice_report を false にして、他の項目は null にしてください。

【事務所名と整理番号の書式の例】{firm_profile}
【読み取り結果（Markdown）】{layout_markdown}

「ご指示ください」に続く日付を名指しで禁じないと、指示の締切を応答期限として返します。 報告の中で最初に目立つ日付が指示の締切であることが多く、何も言わなければそれを選びます。

日付を raw と iso の2つで受け取るのは、変換の誤りを後段で見つけるためです。 和暦から西暦への変換、「27年」のような2桁の年の扱いは、生成AIに任せずワークフローの規則でもう一度変換し、iso と一致するかを確かめます。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力では、すべてのフィールドを required に含め、省略可能な項目は null との共用体型（"type": ["string", "null"]）で表すとされています。オブジェクトには常に additionalProperties: false を設定します。

{
  "is_notice_report": true,
  "firm_ref": "P2024-0123",
  "client_ref": null,
  "application_no": "特願2024-012345",
  "country": "JP",
  "doc_type": "office_action",
  "doc_title": "拒絶理由通知書",
  "dispatch_date": { "raw": "令和8年9月16日", "iso": "2026-09-16" },
  "reported_deadline": { "raw": "令和9年1月16日", "iso": "2027-01-16" },
  "extended_deadline_as_written": null,
  "instruction_due": { "raw": "令和8年12月10日", "iso": "2026-12-10" },
  "deadline_status": "stated | not_stated | ambiguous",
  "candidates": [],
  "evidence": {
    "firm_ref": "",
    "doc_type": "",
    "dispatch_date": "",
    "reported_deadline": "",
    "instruction_due": ""
  }
}

（日付と番号は説明のための架空の値です。）

1つ目の理由は、値の形が崩れないことです。 台帳へ書き込む処理は、項目の欠けや余分な項目を前提にしなくて済みます。ただし、文字列の pattern や format はサポートされていないとされています。 「2027-13-01」が返ってもスキーマは通るので、日付として正しいかはワークフローで検査します。

2つ目は、deadline_status で区分けを規則にできることです。 ワークフローはこの値と台帳の現在の値から、次の区分を機械的に決めます。

3つ目は、evidence で確認が速くなることです。 どの文字列から期限を読んだかを、PDFを開く前に一覧で読めます。

システムへ連携する

台帳へ書き込むのは、期限欄と、確認状態・受領日・根拠の列だけです。 担当者の欄や、応答の方針を書く欄には触りません。知財管理システムを台帳にしている場合は、そのシステムの取り込み機能か個別実装になり、この部分の作りは利用環境によって変わります。

処理済みフォルダーへ移すのは、書き込みか確認待ちへの登録が成功したときだけです。 受信フォルダーに残っている数が、そのまま未処理の報告の数になります。毎朝の一覧は、上に確認待ち、下に期限が近い順の案件を並べます。「近い」の日数は部内で決めます。

人が確認する

人が1件ずつ開くのは、確認待ちのものだけです。 new と same は台帳に「AI登録・未確認」で入り、一覧で流し見て確定に切り替えます。

1. changed を最初に見る … 報告の期限と台帳の期限のどちらが正しいかを、PDFと台帳の履歴で確かめます。台帳の側の転記ミスだったことが分かるのも、この確認です
2. no_deadline を事務所に問い合わせる … 期限が本当に書かれていないのか、別の書類で届くのかを確かめます。自分で計算して埋めません
3. unmatched の案件を特定する … 整理番号の列が空欄だった案件なら、特定したついでに台帳の列を埋めます。 次からは引き当たります
4. 「AI登録・未確認」を流し見る … 根拠の列と期限の日付を見比べ、確定に切り替えます
5. 判定を覆したら記録する … どの項目を、どの値に変えたかを残します

1番目を後回しにしないでください。 changed は、台帳の期限が誤っている可能性がある唯一の区分です。

目標は、240通をならして1通2分です。 確認待ちが1〜2割という想定で、それより多い月は、台帳の整理番号の列か、特定の事務所の書式に原因があります。

例外に対処する

上から4行目が、この構成の要です。 期限の記載が無い報告は、計算で埋めた瞬間に見えなくなります。 件数は少なくても、毎朝の一覧のいちばん上に出し続けます。日と月の並びは、国ごとの書式を規則で決めつけず、事務所に年月日の書き方を揃えてもらうほうが確実です。

記録を残す

• 元のメール（差出人、件名、受信日時）と添付ファイル
• OCRが返した結果の全文（Markdown、段落、表、単語ごとの信頼度）
• 生成AIが返したJSONの全文と、ワークフローが決めた区分
• 台帳に書き込んだ値と、書き込む前の台帳の値
• 人が確定した日時と確定した人、判定を覆した記録
• 事務所に問い合わせた日時と回答

4つ目で「書き込む前の値」を残すのは、誤った書き込みを元に戻せるようにするためです。 特定の事務所だけ ambiguous や no_deadline が続くなら、読み取りを工夫するより報告の書式を相談するほうが早く片づきます。