会社に届く内容証明・督促状・通知書を読み取り、差出人・要求事項・回答期限を法務の受付台帳にそろえて担当へ回す

処理の起点を決める

受付フォルダにスキャンが保存されたことを起点にします。 1日1回の定時実行にはしません。書面の期限は到達から数えるので、受付が半日遅れるだけでも担当者の持ち時間が減ります。

入る経路は2つあります。本社の総務がスキャンしたものと、店舗がスキャンしたものです。店舗には、書面を本社へ社内便で送る前に、店舗の複合機でスキャンして受付フォルダに保存することを頼みます。紙の原本は従来どおり本社へ送りますが、法務が見始めるのはスキャンが届いた時点からになります。

スキャンのときに、到達した日を入力欄に書いてもらいます。 受付フォルダへの保存画面に「この書面を受け取った日」の欄を設け、空のままでは保存できないようにします。到達日は、書面のどこにも書かれていない情報です。 後から推定できないので、受け取った人に入れてもらうしかありません。

入力データを集める

封筒を付けるのには2つ理由があります。 1つは、差出人の住所と名称が封筒にしか書かれていない書面があること。もう1つは、内容証明かどうか、書留かどうかの表示が封筒に出ることです。封筒を捨てると、どちらも後から確かめられません。

過去の案件を引くのは、同じ差出人からの続きの書面を見分けるためです。 2通目の内容証明は、1通目への回答を受けての再反論であることが多く、担当者は1通目と同じ人にするのが自然です。

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

読み取りは、Power Automate からレイアウトモデルを呼ぶだけです。このとき、出力をMarkdown形式にする指定（outputContentFormat=markdown）を付けます。 見出しや表の構造が記号で残るため、後段の取り出しで「どこが要求の段落か」を見分けやすくなります。

単語ごとの信頼度は、日付と金額の部分だけを見ます。 本文全体の信頼度が高くても、期限の日付の数字1文字が読めていなければ意味がありません。 取り出した期限の文字列に対応する単語の信頼度を引き、低ければ台帳の行に印を付けます。

取引先の一覧と担当の割り当て表は、SharePoint のリストを読むだけで足ります。照合は差出人の名称と住所の両方で行います。 名称だけで照合すると、同じ名前の別の会社や個人を取り違えます。

AIへ渡す前に整形する

1. 形式の確認 … PDFまたは画像であることを確かめ、パスワード付きのPDFは受付フォルダに残して総務に戻します
2. 封筒のページの判定 … 最後のページが封筒かどうかを確かめ、無ければ「封筒なし」の印を付けます
3. 複数の書面が混ざっていないかの確認 … 1回のスキャンに別の差出人の書面が混ざっていれば、ページで分けます
4. ページの上端・下端の除去 … pageHeader と pageFooter の段落を本文から外します。内容証明の用紙の欄外の印字が本文に混ざるのを防ぎます
5. 到達日の確認 … 入力欄の日付が、スキャンの日より後になっていないかを見ます
6. 重複の検知 … 同じ差出人・同じ日付の書面が直近に受け付けられていれば、同じ書面の再送か写しとして印を付けます

4番目を軽く見ないでください。 内容証明の用紙には、郵便局が押す証明の文言や日付印が欄外に入ることがあります。それが本文に混ざると、差出の日付や期限として取り出されることがあります。

AIに処理させる

させるのは、書面に書かれていることを台帳の項目に取り出し、根拠にした文をそのまま書き出すことだけです。

期限は、書かれた文言のまま取り出させます。 日付への換算はさせません。「到達後7日」を日付にするには到達日が要り、それは書面の外にある情報だからです。 換算は規則の側で、入力された到達日を使って行います。

1行目がいちばん起きやすい失敗です。 書面の冒頭には差出の日付があり、AIはそれを起点に「7日後」を計算しがちです。差出日から数えた期限は、到達日から数えた期限より早くなり、一見安全そうに見えますが、台帳の日付が書面と食い違うことになります。 期限の列に入るのは、規則で計算した日付だけにします。

指示内容を固定する

あなたは法務部の受付係です。会社に届いた書面の読み取り結果から、
受付台帳の項目を取り出してください。書かれていることだけを取り出し、推測で埋めないでください。

【取り出す項目】
1. document_type … dunning（督促）／termination（解除通知）／damages（損害賠償請求）／
   attorney_notice（受任通知）／rent_revision（賃料改定通知）／court_like（裁判所名の記載がある）／other
2. sender … 名称、住所、代理人の弁護士名（いれば）
3. addressee … 宛先として書かれた会社名・店舗名・個人名
4. demands … 要求事項をすべて。種類（payment／termination／apology／reply／disclosure／other）と内容
5. deadline_text … 期限を、書かれた文言のまま
6. claims_summary … 差出人の主張を3文以内で。「差出人は〜と主張している」の形で書く
7. announced_actions … 予告された措置を、書かれた文言のまま

【厳守事項】
- 期限を日付に換算しないでください。「本書到達後7日以内」は、そのまま写してください。
- 差出の日付を、期限の起点として扱わないでください。
- 主張を事実として書かないでください。必ず「差出人は〜と主張している」としてください。
- 主張が正しいか、回答すべきか、法的に意味があるかは書かないでください。
- 要求が複数ある場合は、すべて demands に並べてください。最後の段落だけを見ないでください。
- 金額は書かれた数字をそのまま写し、合計を計算し直さないでください。
- 差出人の名称が本文に無い場合は、封筒のページから取ってください。
  封筒にも無ければ unknown としてください。
- 欄外の印字（郵便局の証明文言や日付印）を本文として扱わないでください。
- evidence には、各項目の根拠にした文を読み取り結果からそのまま写してください。

【読み取り結果（Markdown）】{layout_markdown}
【封筒のページの読み取り結果】{envelope_text}

「差出人は〜と主張している」の形を指定しないと、主張が事実のように要約されます。 「当社の店舗で転倒事故が発生し、顧客が負傷した」と書かれた要約は、台帳を見た人に事実として読まれます。要約の文の形そのもので、主張であることを残します。

court_like という名前にしているのも同じ理由です。 AIが返すのは「裁判所名の記載がある」という事実までで、本当に裁判所から送達された書類かどうかは、規則と人の確認で決めます。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONを受け取ります。 構造化出力は、呼び出しのときに渡したJSONスキーマに出力を従わせる機能で、すべての項目を必須にし、additionalProperties を false にする必要があります。書面によって項目が抜けたり名前が変わったりすると、台帳への登録が止まるため、形を固定します。

{
  "document_type": "dunning | termination | damages | attorney_notice | rent_revision | court_like | other",
  "sender": { "name": "", "address": "", "attorney": "", "source": "body | envelope | unknown" },
  "addressee": "",
  "demands": [
    { "kind": "payment | termination | apology | reply | disclosure | other",
      "detail": "", "amount_text": "", "evidence": "" }
  ],
  "deadline_text": "",
  "claims_summary": "",
  "announced_actions": "",
  "evidence": { "document_type": "", "deadline_text": "" }
}

1つ目の理由は、規則の判定を後段に置けることです。 deadline_text から日付を計算するのも、document_type が court_like のものを責任者へ回すのも、Power Automate の条件分岐で行います。

「手続上の期間」の日付を機械で入れないのは、意図してのことです。 裁判所の案内では、支払督促は受け取ってから2週間以内に督促異議を申し立てることができるとされています。ただし、どの書類にどの期間がかかるか、いつから数えるかは、書類の種類と送達の状況で変わります。 台帳には「手続上の期間がある書類」という印だけを機械で付け、日付は責任者が確かめて入れます。

2つ目の理由は、要求が複数あっても1行の台帳に収まることです。 demands を配列にしておけば、支払と謝罪と資料の開示を同時に求める書面も、要求ごとに担当の部署を分けて回せます。

システムへ連携する

台帳に足した行は、当番が確認するまで「未確認」のままにします。 担当者への通知は、当番が確認して担当者を確定したときに送ります。取り出しの誤りが、そのまま担当者の作業の前提になることを防ぎます。

裁判所の書類だけは例外です。 court_like と出たものは、当番の確認を待たずに法務の責任者へ「裁判所名の記載がある書面が届いた」とだけ通知します。 中身の確認は当番が行いますが、存在を知る人を最初から増やしておきます。

人が確認する

当番は、台帳のすべての行を原本と見比べます。 法的な書面の受付は件数が少なく、1件の重みが大きいので、一部だけを見る設計にはしません。

1. 期限を最初に見る … deadline_text が原本の文言と同じか、到達日が正しいか、計算した日付が合っているか
2. 書面の種類と差出人を見る … とくに court_like のものは、裁判所から送達された書類かどうかを封筒と書面の形で確かめます
3. 要求事項を見る … 原本の最後の段落まで読み、取り出されていない要求が無いかを確かめます
4. 担当者を確定する … 候補を確かめ、過去の案件の担当者と合わせます
5. 直した項目を記録する … どの項目を、どう直したかを残します

1番目を省かないでください。 期限の誤りは、ほかのどの誤りよりも取り返しがつきません。到達日の入力の誤りも、ここでしか見つかりません。

目標は、1件5分です。 読み取りと書き写しがなくなるぶん、原本と台帳の対応を確かめることに時間を使います。 手書きの書面や10枚を超える書面では、5分を超えます。

例外に対処する

7行目は、最初に決めておいてください。 会社に届く郵便物には、従業員個人に宛てた私的な書面が混ざることがあります。会社の業務として読み取ってよいかは、届いた時点で判断する必要があります。

記録を残す

• 書面と封筒のスキャン、到達日、受け取った拠点、スキャンした人
• 読み取り結果の全文と、取り出した項目のJSON
• 規則で計算した期限と、計算に使った到達日
• 当番が直した項目と、直す前の値
• 担当者への割り当ての日時と、裁判所の書類の責任者への通知の日時
• 拠点ごとの「到達からスキャンまでの日数」

3つ目で「計算に使った到達日」を残すのは、到達日の入力が後から直されることがあるからです。 期限がどの到達日から計算されたかが残っていないと、直した後の期限が正しいかを確かめられません。

最後の行は、店舗への頼み方を見直す材料になります。 特定の店舗だけスキャンまでの日数が長いなら、その店舗に書面の扱いをもう一度伝えます。