司法書士事務所で登記の依頼ごとに受け取る印鑑証明書・住民票の写しを読み取り、氏名・住所・生年月日を申請書の案と突き合わせて、期限切れと表記の違いを拾う

処理の起点を決める

補助者が証明書を取込フォルダに保存することを起点にします。 届いた証明書はその日のうちにスキャンし、ファイル名を「案件番号_当事者番号_受領日」にします。Windows のタスクの予約で、Python のスクリプトを15分おきに動かします。

もう1つの起点は、案件管理の表の予定日の変更です。 スクリプトは毎朝、表の予定日の列を前日の写しと比べ、変わった案件があれば、その案件のすべての証明書の期限を数え直します。 証明書を読み直す必要はなく、保存してある作成日と新しい予定日で計算し直すだけです。

証明書は1枚ずつのファイルにします。 1件の依頼の証明書をまとめてスキャンすると、どの当事者の証明書かがファイル名で決まらなくなります。当事者番号で結び付けられることが、突き合わせの前提です。

入力データを集める

質を決めるのは、申請書の案の値と予定日が表にあることです。 申請書の案が作成ソフトの中にしか無く、値を取り出せないと、突き合わせる相手がありません。 案件管理の表に当事者ごとの列がそろっていることが、この構成の前提です。

登記記録上の氏名と住所も、別の列で持ちます。 証明書と申請書の案が一致していても、登記記録の住所と違えば、前提の登記が要るかを司法書士が判断することになります。 この違いも同じ確認表に並べます。

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

読み取りは、スクリプトから Document AI の処理の API を呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。

氏名の欄は、シンボル（1文字）の単位で信頼度を見ます。 公式には、OCRの結果はシンボルの単位でも位置と信頼度を持ちます。旧字体や異体字で1文字だけ信頼度が下がっても、欄全体の平均で見ると埋もれます。1文字でも基準を下回れば、その欄を low_confidence にします。

作成日は、項目名と値の組ではなく全文から取ることが多くなります。 証明書の作成日は「上記の写しは…であることを証明する」のような文の後に日付として書かれ、項目名の横に並ばない書式があるからです。

AIへ渡す前に整形する

1. 形式の確認 … Document AI の対象は PDF、TIFF、JPEG、PNG などです。スキャナの設定をPDFに固定します
2. 解像度と色 … 公式には、スキャンは最低200dpiが望ましく、300dpi以上が一般に最もよい結果になるとされています。証明書は地紋が入るため、300dpiのカラーで取ります
3. ページ数の確認 … 同期の処理は15ページまでです。世帯全員の住民票の写しで数ページになるものは、1ファイルのまま渡します
4. 伏せる領域の決め方 … 本籍と筆頭者の欄、印影の領域は、読み取りの後に位置で伏せます。本籍は「記載があるか」だけを残し、値は生成AIに渡しません
5. 案件番号の確認 … ファイル名から案件番号と当事者番号を取り出し、案件管理の表に無いものは取り込まずに戻します
6. 重複の確認 … 同じ当事者の同じ種類の証明書が既にあれば、新しいほうを使い、古いほうに印を付けます

2番目を軽く見ないでください。 証明書の地紋（偽造防止の模様）は、白黒の低い解像度でスキャンすると文字に重なり、読みにくくなることがあります。氏名の1文字を守るために、カラーで取ります。

AIに処理させる

させるのは、証明書に書かれた項目を、書かれたとおりに分けることだけです。 申請書の案との一致の判断、期限の判断、前提の登記の要否の判断はさせません。

氏名の字の形を変えないことを、表に明記しています。 読み取りが「髙橋」と返したとき、AIは一般的な「高橋」に直したがります。それが登記で同じに扱えるかは、司法書士が決めることです。 字の形は読み取りのまま返させ、違いは規則が見つけます。

2行目がいちばん起きやすい失敗です。 住所を「申請書の案に合わせた書き方」で返されると、突き合わせは必ず一致します。一致したことが、そろえた結果なのか元から同じだったのかが分からなくなります。

指示内容を固定する

あなたは司法書士事務所の補助者として、依頼者から届いた証明書の
読み取り結果を、項目に分けて書き写す立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 証明書の種類を、印鑑登録証明書（seal）、住民票の写し（resident）、
   住民票記載事項証明書（resident_items）、戸籍の附票の写し（koseki_fuhyo）、
   それ以外（other）から選んでください。
2. 氏名、生年月日、住所、作成日（証明日）、住所を定めた年月日を写してください。
3. 本籍の欄に値があるかを yes / no / unknown で答えてください。
   本籍の値は [MASKED] で伏せてあります。値を推し量らないでください。
4. 世帯の複数の人が載っている場合は、全員を persons に並べてください。

【厳守事項】
- 文字は書かれたものをそのまま入れてください。
  氏名の旧字体や異体字を、一般的な字に置き換えないでください。
- 住所は書かれた表記のまま写してください。
  数字や丁目・番地・号の書き方を変えないでください。
- 日付は書かれた和暦のまま写し、西暦に直さないでください。
- 書かれていない項目は空にしてください。ほかの欄から推し量らないでください。
- 有効期限や、申請に使えるかどうかについて、何も書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。

【読み取り結果（キーと値の組、全文。本籍・筆頭者・印影は伏せてあります）】{ocr_result}

「有効期限について何も書かない」を入れるのは、AIが期限を気にかけてくれるからです。 何も言わなければ「作成日から3か月以内のため有効です」と添えます。今日を基準に数えた一言が確認表にあると、予定日で数えた判定と食い違って見えます。 期限は規則の側だけで数えます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、output_config.format に json_schema の形でスキーマを渡すと、制約付きのデコードでスキーマに従う応答を返すとされています。enum と required を使え、オブジェクトの additionalProperties は false にする必要があります。

{
  "doc_type": "seal | resident | resident_items | koseki_fuhyo | other | unknown",
  "issued_on": { "value": "" },
  "persons": [
    {
      "name": { "value": "" },
      "birth_date": { "value": "" },
      "address": { "value": "" },
      "address_since": { "value": "" },
      "honseki_present": "yes | no | unknown"
    }
  ],
  "evidence": [{ "field": "", "text": "" }]
}

突き合わせの状態は、スクリプトが規則で付けます。

notation_only を match と分けるのは、そろえた事実を残すためです。 補助者は notation_only を一覧で流し見て、申請書の案の書き方を証明書に合わせるかを決めます。 規則でそろえたことが表に出ているので、何をそろえたかを後から追えます。

期限の3つは、印鑑登録証明書だけに付けます。 住民票の写しには、事務所の内規の期間を別の列で付け、法令の期限と内規の期限を混ぜません。

システムへ連携する

申請書の案は書き換えません。 notation_only や different が出ても、どちらに合わせるかは補助者と司法書士が決め、作成ソフトで直します。 照合の仕組みが申請書を直し始めると、誰の判断で直したかが分からなくなります。

確認表には、期限が近い順の並びも用意します。 expires_before_filing の案件を予定日の近い順に並べ、依頼者への取り直しの連絡を早い順に出せるようにします。 連絡の文案は「印鑑登録証明書の作成日から3か月が決済の予定日より前に過ぎるため、新しいものをお願いします」のような下書きにとどめ、送るのは補助者です。

予定日の変更の検知は、案件管理の表の写しとの比較で行います。 毎朝、表の予定日の列を前日の写しと比べ、変わった案件の番号だけを数え直しに回します。表の側に変更の履歴の機能が無くても動く形にしておくのが、事務所の表を作り直さずに済むやり方です。

人が確認する

補助者が見るのは、match 以外の項目と、valid 以外の期限だけです。 すべての項目を証明書と見比べる設計にすると、第10章の12.0時間には収まりません。

1. expired と expires_before_filing を先に見る … 予定日を確かめ、取り直しの連絡を依頼者に出します
2. low_confidence の欄を証明書と見比べる … 氏名は1文字ずつ見ます
3. different を確かめる … 字の形の違い、番地の違い、登記記録との違いを、判断の要るものは司法書士に回します
4. notation_only を流し見る … 申請書の案の書き方を合わせるかを決めます

3番目を補助者だけで閉じないでください。 字の形の違いや登記記録の住所との違いは、前提の登記や上申書の要否につながります。 判断は司法書士が行い、その結果を確認表に記録します。

司法書士の判断は、当事者ごとに「採用する表記」として確認表に残します。 同じ依頼者の証明書が後から届いたとき、前回どちらの字で申請すると決めたかが分かれば、同じ相談を繰り返さずに済みます。 判断した司法書士の名前と日付も同じ行に入れます。

目標は、360件をならして1件2分です。 match と valid だけの証明書は数十秒で終わり、different は司法書士との相談を含めて数分かかります。

例外に対処する

5行目の扱いが、この構成でいちばん大事な例外です。 作成日が読めない証明書を「期限の判定なし」で流すと、確認表の上では何も問題がないように見えます。 数えられないものは、切れているものとして人に見せます。

記録を残す

• 元の証明書のファイルと、案件番号・当事者番号・受領日・取込の日時
• Document AI が返した Document のJSONの全文
• Claude API に渡した伏せた後の読み取り結果と、返ってきたJSON
• スクリプトが付けた状態と、そのときの申請書の案の値と予定日
• 期限を数え直した日時と、きっかけになった予定日の変更
• 補助者と司法書士の判断（どちらの表記で申請するか、前提の登記の要否）と、判断した人

4つ目で「そのときの予定日」を残すのは、予定日が動くからです。 後から期限の判定を見直すとき、どの予定日で数えた結果なのかが残っていないと、判定が正しかったかを確かめられません。