法律事務所に届く期日呼出状・送達書面・裁判所のFAXを読み取り、事件番号・期日・提出期限を期日台帳と弁護士の予定に入れ、近い期限を知らせる

処理の起点を決める

受付フォルダへのPDFの保存を起点にします。 システムからダウンロードした書面、スキャンした郵便、FAXの受信PDFを、いずれも同じフォルダに保存します。経路ごとに処理を分けると、どれか1つの経路だけが止まっていても気づけません。

システム送達の通知メールは、自動では処理しません。 通知を受けたら事務職員が裁判所のシステムにサインインして書面をダウンロードし、その日時をファイル名に入れて受付フォルダに保存します。 システム送達は、閲覧した時、ダウンロードした時、通知から1週間を経過した時のいずれか早い時に効力が生じるとされています。ダウンロードの日時は、送達の日を確かめる材料になります。

加えて、通知メールの受信を数える仕組みを置きます。通知を受けた件数と、受付フォルダに入った件数が合わない日は、ダウンロードし忘れた書面があります。期間は通知から進むので、ここだけは毎日数えます。

入力データを集める

質を決めるのは、期日台帳の事件番号の列です。 事件番号は裁判所・年・符号・番号の組み合わせで、同じ番号でも裁判所が違えば別の事件です。 台帳に裁判所の列が無いと、照合が1件に決まらない事件が出ます。

受け取りの記録は、書面の中身と別に持ちます。 書面に書かれているのは期日や期限で、いつ受け取ったかは書面の外にしかありません。 ファイル名に経路と日時を入れて、読み取り結果と一緒に扱います。

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

書面： システムからのダウンロードは事務職員が行い、ファイル名を 経路_受取日時_任意.pdf の形にそろえます。郵便はスキャンし、FAXは複合機の受信PDFを保存します。同じ書面が複数の経路で届くこともあるので、どれも受付フォルダに入れて、照合の段で重複を見ます。

OCRの呼び出し： モデルIDは prebuilt-layout です。使うのは次の4つです。

期日台帳： 共有の表を読み、事件番号・裁判所・担当弁護士・登録済みの期日を取ります。書き込みは、承認された登録案だけを、照合のスクリプトが行います。

AIへ渡す前に整形する

1. 書面の種類の判定 … 表題の段落から、呼出状、期日請書の依頼、決定・命令、事務連絡などに分けます。判定できないものは種類を空にして一覧に出します
2. 事件番号の正規化 … 全角・半角、括弧、「第」「号」の有無をそろえ、裁判所・年・符号・番号の4つに分けます。符号の文字は書かれたとおりに残し、似た符号に寄せません
3. 日付の正規化 … 和暦を西暦に直し、曜日が書かれていれば日付と曜日が合うかを確かめます。合わなければ日付を確定させず、date_mismatch を付けます
4. 数字の信頼度の確認 … 日付・時刻・事件番号を含む単語の信頼度がしきい値を下回れば、low_confidence を付けます
5. 重複の検知 … 同じ事件・同じ書面の種類・同じ期日の書面が、別の経路から先に届いていないかを見ます

3番目の曜日の確認は、手軽で効きます。 書面の期日には「令和8年11月12日（木）午前10時30分」のように曜日が添えられていることが多く、読み取りで日付の数字を1つ取り違えると、曜日と合わなくなります。 機械で確かめられる数少ない手がかりです。

事件の種類によって、書面の様式が違うことも前処理で吸収します。 民事訴訟の呼出状は期日を表で示すことが多い一方、刑事や家事の事件の書面、書記官からの事務連絡のFAXは、期日を本文の文章の中に書くことがあります。表から取れなかった期日は、段落の本文から抜き出す側に回し、どちらから取ったかを記録しておきます。 表から取った値と本文から取った値が食い違う書面は、needs_review として一覧に出します。

AIに処理させる

させるのは、書面に書かれている事件番号・期日・場所・手続・提出期限を、書かれたとおりに抜き出すことだけです。

送達の日から数える期限は、抜き出しの対象に入れません。 書面に「この決定に不服があるときは…」のような案内が書かれていても、満了日を計算するのは弁護士です。 機械が出すのは「期間の計算が要る書面である」という印と、受け取りの記録だけです。

2行目が、この構成で最も重い制約です。 生成AIに書面を渡すと、案内の文言から親切に満了日を計算して添えます。その日付が予定表に入れば、誰もが正しいと思って使います。 計算させないことを指示に明記し、出力の形にも満了日の欄を置きません。

指示内容を固定する

あなたは法律事務所の事務局で、裁判所から届いた書面の読み取り結果を整理する立場です。
OCRが返した文字と表だけを使い、書かれている項目を抜き出してください。
期間の計算、送達の日の判断、期日の扱いの判断はしません。

【抜き出す項目】
- document_type: 書面の表題（書かれたとおり）
- case: court（裁判所と支部・係）, year, code（符号）, number
- parties: 書面に書かれた当事者の表示
- hearings: 期日ごとに date, weekday, time, place, kind（手続の種類）
- deadlines: 書面に日付が書かれた提出期限ごとに date, what（何を出すのか）, quote
- changes: 期日の変更・取消の記載ごとに quote
- period_notice: 不服申立てなどの期間についての案内文があれば true

【厳守事項】
- 日付と時刻は書かれたとおりに写し、曜日も書かれていれば写してください。
  和暦を西暦に直すこと、曜日を補うことはしないでください。
- 書面に日付が書かれていない期限を作らないでください。
  「送達の日から2週間」のような期間は deadlines に入れず、
  period_notice を true にするだけにしてください。満了日を計算しないでください。
- 事件番号は書かれたとおりに写してください。読めない文字は □ にしてください。
  似た符号や番号に直さないでください。
- 期日が複数書かれていれば、すべて hearings に並べてください。
  どれが有効かを選ばないでください。
- quote には、根拠にした文を書面からそのまま写してください。
- 書面が裁判所からのものでないと判断した場合は、document_type に書き、
  ほかの項目は空にしてください。

【受け取りの経路と日時】{receipt}
【読み取り結果】{ocr_result}

「満了日を計算しない」を2か所に書くのは、1か所では足りないからです。 期間の案内文があると、生成AIはそれを期限として deadlines に入れようとします。入れる場所そのものを period_notice という真偽の欄に限ることで、日付を作る余地をなくします。

和暦を西暦に直させないのは、変換をスクリプトに任せるためです。 生成AIに直させると、年の境目で1年ずれた日付がまれに出ます。決まった規則で変換できるものは、規則で変換します。

出力形式を固定する

書面1件ごとに、次の形のJSONを作ります。 extracted は生成AIが返し、match と proposals は照合のスクリプトが付けます。

{
  "doc_id": "SYS_20261007-0912_01",
  "receipt": { "route": "system | mail | fax", "received_at": "2026-10-07T09:12" },
  "extracted": {
    "document_type": "期日呼出状",
    "case": { "court": "", "year": "", "code": "", "number": "" },
    "hearings": [ { "date": "", "weekday": "", "time": "", "place": "", "kind": "", "quote": "" } ],
    "deadlines": [ { "date": "", "what": "", "quote": "" } ],
    "changes": [],
    "period_notice": false
  },
  "match": { "status": "matched | ambiguous | not_found", "case_id": "", "lawyer": "" },
  "proposals": [
    { "action": "add_hearing | change_hearing | add_deadline | duplicate",
      "date": "2026-11-12", "time": "10:30", "flags": ["date_mismatch", "low_confidence"] }
  ]
}

生成AIの部分は構造化出力で受け取ります。Claude API では output_config の format に type: "json_schema" とスキーマを指定し、返るJSONがスキーマに沿うことが保証されます。 route や action は enum で固定します。

ただし、スキーマで書けないことがあります。 数値の範囲の制約と文字列の長さの制約は使えません。日付が実在するか、曜日と合うかは、スキーマではなくスクリプトで確かめます。

出力に満了日の欄を置かないのが、この形の要です。 period_notice が真の書面は、一覧で「期間の確認が要る」と目立たせ、担当弁護士への連絡の対象にします。 満了日は、弁護士が確かめてから事務局が台帳に入れます。

システムへ連携する

予定表への書き込みは、承認されたものだけです。 イベントを作るときは、書面の識別子から作った値を transactionId に入れ、再実行しても同じ期日が二重にできないようにします。 予定の本文には事件番号と書面のファイルへのリンクだけを入れ、当事者の名前は入れません。 予定表は事務所の中で共有されることが多いためです。

期日の変更の書面は、既存の予定を書き換えず、新しい予定を作って古い予定に「変更済み」の印を付けます。 書き換えると、いつ変わったのかが予定表から消えます。

人が確認する

事務職員が一覧で見るのは、登録案と書面の画像の該当部分です。 単語には多角形の座標が付いて返るので、期日と事件番号の部分を切り抜いて、登録案の横に並べます。

1. match が matched 以外のもの … 期日台帳のどの事件かを人が決めます。似た事件に寄せません
2. date_mismatch と low_confidence が付いたもの … 画像で数字を読み直します
3. change_hearing と duplicate … 書面の文言と台帳を見比べ、変更か、新しい期日か、再送かを決めます
4. period_notice が真のもの … 送達の日を確かめて記録し、担当弁護士に連絡します
5. それ以外のもの … 登録案と画像を流し見て承認します

4番目で送達の日を記録するとき、機械が出すのは受け取りの記録だけです。 システムの書面ならダウンロードの日時、郵便なら受け取った日、と材料を並べ、どの日を送達の日とするかは事務職員が確かめ、担当弁護士が満了日を確かめます。

目標は、400件をならして1件1.8分です。 一覧で印の付いたものは全体の3割前後という想定で、それより多い月は、台帳の事件番号の書き方がそろっていないか、FAXの画質が落ちています。

例外に対処する

7行目は、この構成で唯一、書面が届く前の段階の例外です。 ダウンロードされなかった書面は、読み取りにも照合にも上がってきません。機械が見張れるのは受付フォルダに入ったものだけなので、入口の数を合わせる仕組みを別に持ちます。

記録を残す

• 書面のPDFと、経路・受け取った日時・ダウンロードした日時
• OCRが返したJSONの全文と、生成AIが返した抜き出し
• 照合の結果と登録案、承認した人と日時、承認の前に直した項目
• 期日台帳と予定表に書き込んだ内容と、Graph の応答
• 送達の日として記録した日と、その根拠にした受け取りの記録
• 通知メールの件数と受付フォルダの件数の日ごとの記録

5つ目を必ず残してください。 後から期限の計算を問われたとき、どの日を送達の日としたかと、その根拠が記録に無いと、事務所として説明ができません。