司法書士事務所で法務局から返ってくる登記完了証と登記識別情報通知を読み取り、案件台帳の完了日と次の手続きを更新して、完了が遅れている案件を拾う

処理の起点を決める

事務所のPCで、Windows のタスクスケジューラーから数分おきに Python のスクリプトを起動します。 スクリプトは受付フォルダを見て、前回から増えたファイルだけを処理します。書類は事務所のファイルサーバーに保存するので、クラウドのストレージにスキャンを置かずに済みます。

数分おきで足ります。 完了予定日との比較は日単位で、書類が届いてから台帳に載るまでが数分延びても困りません。

処理が終わったファイルは処理済みのフォルダへ移します。移すのは、更新待ちのシートへの書き出しまで成功したときだけです。 受付フォルダに残っている数が、そのまま未処理の数になります。

遅れの一覧は、別のスクリプトを毎朝1回起動して作ります。 書類の読み取りとは切り離し、読み取りが止まっていても一覧は出るようにします。

入力データを集める

質を決めるのは、案件台帳の受付番号と登記所です。 申請のときに受付番号を台帳へ入れていない案件は、読み取った番号を引き当てる相手がありません。 オンラインで申請した案件は申請のソフトの画面で、書面で申請した案件は受付の控えで、その日のうちに入れる決まりにします。

納品の取り決めは、選択式の列に直します。 「完了証の写しを金融機関へFAX」「識別情報通知書を依頼者へ手渡し」のように型を決めておくと、次の手続きの候補を機械が出せます。 自由記述のままでは、AIに読ませても毎回違う候補が出ます。

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

画像の品質の値は、要求のときに有効にしないと返りません。 処理結果の説明では、imageQualityScores は Enterprise Document OCR で enableImageQualityScores を true にしたときに返るとされています。返る値には品質の値と、反射などの欠陥の種類（quality/defect_glare など）と信頼度が入ります。

値は text から写します。 処理結果の説明では、text が文書の文字の source of truth で、各要素は textAnchor の位置でそこを指すとされています。受付番号のように桁が大事な値は、textAnchor の範囲どおりに写し、前後の文字を足しません。

案件台帳は、スクリプトがスプレッドシートを読むだけです。台帳の全体をAIに渡すことはしません。 照合はスクリプトの側で行います。

AIへ渡す前に整形する

1. 形式の確認 … PDF、TIFF、JPEG、PNG などの対応形式であることを確かめます
2. ページ数とサイズ … Enterprise Document OCR のオンラインの処理は1回の要求で15ページまで、ファイルは40MBまでです。まとめてスキャンしたものは書類ごとに分けます
3. 回転の補正 … 封筒から出した向きのままスキャンされた書類は、OCRの回転の補正に任せます
4. 品質の値による振り分け … 品質の値が一定より低いページは、AIに渡す前に「要目視」の印を付けます
5. 地紋のための設定 … スキャナーをカラーまたはグレーで300dpi前後に設定します。白黒の2値で読むと地紋が文字に重なって残ります
6. 重複の検知 … 同じ登記所・受付年月日・受付番号の書類が直近にあれば、同じ案件の2通目（完了証と通知書）として扱います
7. 目隠しの確認 … 1ページ目の画像の、通知書の目隠しの位置に当たる領域が目隠しの状態のままかを、スキャンの直後に補助者が目で確かめます

7番目を手順に入れるのは、スキャンの前に開けてしまう事故を止めるためです。 機械の検査（第7章「AIに何をさせるのか」の後段）は最後の網で、最初の網はスキャンする人の手順です。

AIに処理させる

させるのは、OCRの全テキストから、台帳の照合に使う値を拾って項目にそろえることだけです。

状態の印は、ok・missing・unreadable・ambiguous の4つです。 照合に使う3つ（登記所・受付年月日・受付番号）のどれかが ok でなければ、結び付けをせずに人に回します。

2行目が起きやすい失敗です。 読み取りで1桁がにじんだ受付番号を渡すと、台帳にありそうな番号に直して返すことがあります。直した番号が別の案件に当たれば、取り違えが静かに起きます。

登記識別情報の検査は、AIではなくスクリプトで行います。 AIへの指示で「写さない」と書くだけでは足りません。OCRの全テキストの段階で、英字と数字が続けて並ぶ一定の長さ以上の文字列がないかを規則で調べ、見つかったら、AIに渡す前にその書類の処理を止めて、OCRの結果を消し、司法書士に知らせます。 不動産番号のように数字が続く値もあるため、規則は事務所の書類で試して決めます。

指示内容を固定する

あなたは司法書士事務所の補助者で、法務局から返ってきた書類から、
案件台帳との照合に使う値を拾う立場です。
OCRが返した全テキストだけを見て、書かれているとおりに写してください。

【拾う項目】
1. 書類の種類（登記完了証／登記識別情報通知書／その他）
2. 登記所の名前（本局・支局・出張所の別まで）
3. 受付年月日
4. 受付番号
5. 不動産番号（複数あればすべて）
6. 登記の目的
7. 不動産の表示（所在・地番・家屋番号）

【status の選び方】
- ok ......... 値が読み取れており、その項目として解釈できる
- missing .... 値が無い
- unreadable . 文字は検出されているが信頼度が低く、値として確定できない
- ambiguous .. 値の候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 受付番号・不動産番号は、読み取った数字をそのまま value に入れてください。
  桁を補う、似た番号に直す、前後の数字をつなげることをしないでください。
  1桁でも読み取りに自信がなければ unreadable にしてください。
- 受付年月日は書かれた年号のまま写し、西暦に直さないでください。
- 登記の目的と不動産の表示は要約せず、書かれたとおりに写してください。
- 登記識別情報、またはそれに見える符号の並びが読み取り結果にあっても、
  一切写さないでください。その場合は secret_suspected を true にしてください。
- どの案件に当たるかは書かないでください。照合は別の仕組みが行います。
- 登記の内容が正しいかどうかは書かないでください。
- evidence には、判定の根拠にした文字列をそのまま写してください。
  ただし登記識別情報に見える文字列は evidence にも入れないでください。
- confidence は OCR が返した値をそのまま入れてください。

【OCRの全テキストと信頼度】{ocr_result}
【ページごとの画像の品質の値】{quality}

「似た番号に直さない」を明記しないと、にじんだ1桁を埋めてきます。 受付番号の1桁違いは、台帳に実在する別の案件の番号であることが珍しくありません。 埋めた番号が照合に通ってしまうのが、いちばん困る失敗です。

secret_suspected はAIの側の網で、スクリプトの検査とは別に持ちます。 2つのうちどちらかが立てば止めます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力では、output_config.format に json_schema を渡してこの形に固定し、オブジェクトには additionalProperties: false を付けます。

{
  "file_id": "",
  "document_type": "completion_certificate | identification_notice | other",
  "secret_suspected": false,
  "fields": [
    { "item": "registry_office", "status": "ok | missing | unreadable | ambiguous",
      "value": "", "confidence": 0, "evidence": "" }
  ],
  "property_numbers": [],
  "low_quality_pages": []
}

fields の item は registry_office ／ receipt_date ／ receipt_number ／ purpose ／ property_description です。

構造化出力を使う理由は2つです。 1つ目は、照合に使う3つの値の status を、スクリプトがそのまま条件に使えることです。2つ目は、secret_suspected を必ず返させられることです。自由文では、書かない日が出ます。

公式のページでは、列挙の値の大文字・小文字が変わることがあるとされているため、比較は大文字・小文字を区別せずに行います。 max_tokens で途切れた出力や、拒否（stop_reason が refusal）で返った出力はスキーマに合わないことがあるため、検証に通らないものは更新待ちに「要目視」で載せます。

スクリプトが更新待ちのシートに書く1行は次のとおりです。

システムへ連携する

案件台帳へは、補助者が確かめた行しか反映しません。 スクリプトは更新待ちのシートに書くところまでです。完了日が台帳に入ると遅れの一覧から外れるため、誤った結び付けで入ると、本当の遅れが一覧から消えます。

申請用のソフトには書き込みません。 オンラインで申請した案件の処理状況は、これまでどおりソフトの画面で見ます。この構成は、書面で返ってくる書類の記録に絞ります。

人が確認する

1. matched の行 … 書類の画像の受付番号と台帳の案件を見比べ、反映します。1件数十秒です
2. not_found と multiple の行 … 台帳に受付番号が入っていない案件か、登記所の読み違いかを確かめます
3. 要目視の行 … 品質の低いページや unreadable の値を、画像で確かめて直します
4. 次の手続き … 候補を見て、担当の司法書士に回すものを決めます
5. 遅れの一覧 … 司法書士が毎朝見て、法務局への確認と依頼者への連絡を決めます

secret_suspected が立った書類は、補助者ではなく司法書士が扱います。 画像とOCRの結果をどう消すか、目隠しがどの段階で開いていたかを確かめます。

目標は、240通をならして1通2分です。 matched は数十秒で終わり、時間を使うのは not_found と要目視の行です。

例外に対処する

最後から2行目の注は、東京法務局の完了予定日のページにある注書きです。 申請に不備がある場合や、本人確認のための事前通知を要する場合などは、予定日の翌日以降になることがあるとされています。そうした案件まで遅れとして毎朝並ぶと、一覧が読まれなくなります。 事前通知の案件は、台帳の列で分けておきます。

記録を残す

• スキャンした書類の画像と、届いた日
• OCRが返したJSON（登記識別情報らしい文字列で止めた書類は保存しない）
• AIの出力と、スクリプトの照合の結果
• 補助者が反映した内容と、直した値の記録
• secret_suspected が立った件の、止めた日時と、司法書士が行った処理
• 遅れの一覧に出た案件と、法務局に確かめた結果

2つ目の括弧書きを、保存の規則として最初に決めます。 止めた書類のOCRの結果を「調査のため」に残すと、残してはいけない情報を、もっとも残りやすい場所に残すことになります。

最後の行は、登記所ごとの遅れの傾向を見る材料になります。 遅れやすい登記所の案件は、納品の期日を依頼者と決めるときに余裕を持たせられます。