相続手続きで集めた戸籍・除籍の証明書を読み取って、つながりを確かめ、相続関係説明図の下書きを作る

処理の起点を決める

案件フォルダに証明書のファイルが保存されたことを起点にします。 証明書は一度にそろわず、依頼人から預かった分、取り寄せた分、追加で取り寄せた分が日をずらして届きます。届いた分から読み取り、つながりの確認はそのたびにやり直します。 まとめて一度に処理する作りにすると、すき間の発見が遅れます。

ファイルは1通ずつ保存するのが理想ですが、実際には束をまとめてスキャンすることが多くなります。1つのPDFに何通入っていても受け付け、前処理で証明書ごとに分けます。

つながりの確認は、証明書が1通増えるたびに案件全体で計算し直します。 追加の1通が届いてすき間が埋まれば、すき間の一覧からその行が消えます。一覧が空になったことが、取り寄せの完了の合図です。

入力データを集める

質を決めるのは、2つ目の信頼度と手書きの判定です。 読み取りの結果をそのまま使うのではなく、どこを人が見るべきかの目印として使います。

案件の情報は、つながりの確認の起点にします。 被相続人の死亡の日が分かっていれば、最後の戸籍でその日の死亡の記載を探し、そこから時間をさかのぼって出生まで期間を埋めていきます。

字体の対応表は、事務所の運用で決めます。 戸籍に書かれた旧字体を、図の下書きで新字体に直すのか、そのまま残すのかは、提出先と事務所の方針で変わります。読み取りの段階では書かれたとおりの字を残し、置き換えは後段で行います。

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

読み取りは、連携の仕組みから Enterprise Document OCR の処理を呼ぶだけです。呼ぶときに、3つの設定を付けます。 言語のヒントに日本語（ja）を入れること、画像の品質スコアを有効にすること、フォントスタイルの検出（computeStyleInfo）を有効にすることです。応答のうち、使う部分は決まっています。

生成AIへは、全文と、行ごとの信頼度と手書きの判定の一覧をあわせて渡します。 行ごとの値は、行に含まれる単語の値から連携の仕組みで作ります。本文だけを渡すと、生成AIは読めていない箇所も読めたものとして扱います。信頼度を横に置くことで、「この日付は信頼度が低い」と出力に書かせることができます。

品質スコアは、読み取りの前の関門にします。 スコアは0から1で、1が完全な品質です。0.5を下回ると、ぼやけや照り返しなどの原因が、可能性の高い順に一覧で返ります。 そのページは書き出しに回さず、原因を添えて取り直しを依頼します。

位置の情報は、確認の画面で使います。 書き出した項目ごとに、その根拠になった行のページと位置を持たせておくと、確認のときに画像の該当箇所へ一度で移れます。

AIへ渡す前に整形する

1. 形式の確認 … PDF、GIF、TIFF、JPEG、PNG、BMP、WebP のいずれかであることを確かめます
2. ページ数とサイズの確認 … 1回の要求で待ち受けながら処理するオンライン処理は、15ページまで、ファイルサイズ40MBまでです。束のPDFがこれを超えるときは、6番目の分割を先に行います
3. 画像の解像度の確認 … 画像の解像度は1ページあたり40メガピクセルが上限です（PDFには適用されません）
4. 文字の大きさの確認 … 古い戸籍の欄外の書き込みや訂正の印は、本文より小さく書かれています。品質スコアの原因に「通常より小さい文字」が出たページは、解像度を上げて取り直します
5. ロックの解除 … パスワードでロックされたPDFは、解除してから保存し直します
6. 証明書ごとの分割 … 束でスキャンしたPDFを、証明書の見出しと認証文の位置を手がかりに1通ずつに分けます。分けた結果は人が一覧で確かめます
7. 重複の検知 … 同じ証明書を依頼人と事務所が別々に取っていることがあります。本籍・筆頭者・種類が同じものに印を付けます

4番目を軽く見ないでください。 解像度が足りないだけの箇所は、読み違いと区別がつきません。 古い戸籍は、300dpi程度で取り込む運用を先に決めておきます。

6番目の分割には、束のままではなく1通ずつ読み取る理由があります。 1通ずつの読み取り結果を生成AIへ渡せば、ある証明書の記載が別の証明書の書き出しに混ざることが起きません。

AIに処理させる

させるのは、1通ごとに書かれている事項を決まった項目へ書き出すことだけです。

元号の日付は、元号のまま書き出させ、西暦への換算は後段の計算で行います。 生成AIに換算させると、換算の誤りと読み取りの誤りが区別できなくなります。

4行目が、いちばん起きやすい失敗です。 ある戸籍で読めなかった生年月日を、別の戸籍に書かれた同じ名前の人物の生年月日で埋めると、その瞬間に、2人を1人と決めつけたことになります。 同じ人物かどうかは、1通ずつ書き出した後で、別の工程でまとめます。

指示内容を固定する

あなたは司法書士事務所で、戸籍・除籍の証明書の記載を書き出す担当です。
渡すのは1通分の読み取り結果です。この1通に書かれていることだけを書き出してください。

【読み取り結果】{ocr_text}
【行ごとの信頼度と手書きの判定】{line_confidence}

【書き出す項目】
1. 証明書の種類、本籍、筆頭者
2. この戸籍の期間に関わる事項（編製、改製、転籍、消除）とその日付・事由
3. 載っている人物ごとの氏名、生年月日、父母の氏名、続柄
4. 人物ごとの身分事項（出生、婚姻、離婚、養子縁組、認知、死亡、入籍、除籍）
   と、その日付、相手方、どこから入りどこへ出たか

【厳守事項】
- 日付は書かれている元号のまま書いてください。西暦に直さないでください。
- 読めない字は推測せず「〓」としてください。
  それらしい字や、よくある名前に近づけないでください。
- 読めない日付は null とし、前後の記載から計算で埋めないでください。
- 信頼度が 0.8 未満の行から取った値には low_confidence を true にしてください。
- 手書きと判定された行から取った値には handwritten を true にしてください。
- 他の証明書の記載を前提にしないでください。この1通に無いことは書かないでください。
- 誰が相続人になるかは書かないでください。
- 各項目には、根拠にした行の番号を source_lines に入れてください。
- 戸籍の証明書でない書類と判断した場合は、document_type を other にして
  それ以上は書き出さないでください。

「元号のまま書く」を最初に置いているのは、誤りの出どころを分けるためです。 西暦への換算まで生成AIにさせると、日付が1年ずれていたとき、読み違いなのか換算の誤りなのかが分かりません。換算は計算で行えば、誤りは必ず読み取りの側にあります。

「よくある名前に近づけない」も同じ考えです。 崩した字が読めないとき、生成AIはありそうな名前を選びます。それは読み取りではなく創作です。 読めないことを記録するほうが、確認の段階で速く正しく直せます。

出力形式を固定する

1通ごとに、次の形のJSONで受け取ります。

{
  "doc_id": "",
  "document_type": "koseki_zenbu | joseki | kaisei_genkoseki | other",
  "honseki": { "value": "", "low_confidence": false, "source_lines": [] },
  "hittousha": { "value": "", "low_confidence": false, "source_lines": [] },
  "period_events": [
    { "event": "hensei | kaisei | tenseki | shojo", "date_wareki": "", "reason": "",
      "low_confidence": false, "handwritten": false, "source_lines": [] }
  ],
  "persons": [
    { "name": "", "birth_wareki": "", "father": "", "mother": "", "relation": "",
      "events": [
        { "type": "birth | marriage | divorce | adoption | acknowledgment | death | nyuseki | joseki",
          "date_wareki": "", "counterpart": "", "from_to": "",
          "low_confidence": false, "handwritten": false, "source_lines": [] }
      ] }
  ]
}

1つ目の理由は、low_confidence と handwritten を項目ごとに持てることです。 確認の画面では、この2つが付いた項目だけを色で示します。全文字を見直す必要がなくなり、見るべき数十か所に絞れます。

2つ目は、period_events を独立させていることです。 期間のつながりの計算は、この項目だけを案件の全証明書から集めて並べます。人物の事項と混ぜないことで、計算の入力が決まった形になります。

3つ目は、source_lines で画像へ戻れることです。 下書きの図の1つの線が、どの証明書の何行目に基づくかをたどれます。

つながりの計算は、period_events から被相続人の在籍の期間を並べ、次のような一覧を出します。

3行目が、取り寄せを依頼する先になります。 婚姻で新しい戸籍が作られた先の本籍は、前の戸籍の除籍の事項に書かれているので、請求先の本籍地まで一覧に出せます。

同じ人物の候補のまとめも、計算の側で行います。 通数をまたいで、生年月日と父母の氏名がともに一致する記載を1人の候補とし、氏が違うものは婚姻や養子縁組の事項で説明がつくかを確かめます。どちらかが low_confidence のときは、まとめずに「同じ人物の可能性」として並べるだけにします。 まとめる判断は、確認の段階で人が行います。

システムへ連携する

登記の申請の仕組みには、この構成からつなぎません。 出すのは、確認前の下書きの図とすき間の一覧までです。申請書に添付する図は、司法書士が確定させたものだけです。

人が確認する

全件、補助者と司法書士の二段階で確かめます。

1. 分割の結果を見る … 束で読み込んだものが正しく1通ずつに分かれているか。ここが崩れると以降のすべてがずれます
2. 色の付いた項目を画像と突き合わせる … low_confidence と handwritten の項目を、source_lines から画像の該当箇所を開いて直します
3. 氏名と日付を優先する … 同じ人物かどうかと、期間のつながりの両方に効く項目です
4. 同じ人物の候補を確かめる … 生年月日と父母の氏名が一致する記載のまとめ方を確かめます
5. すき間の一覧を見て取り寄せる … 請求先の本籍地を確かめ、依頼します
6. 司法書士が相続人を判断する … 下書きの図に、相続人の範囲と順位を書き込んで確定させます

2番目で直した値は、そのまま記録に残します。 どの項目を、何から何へ直したかが残れば、どの種類の戸籍で読み違いが多いかが分かり、スキャンの設定や確認の重点を見直せます。

目標は、1件54分です。 書き写す作業はなくなりますが、画像と突き合わせる時間、すき間を確かめる時間、図を確定させる時間は残ります。手書きの戸籍が多い案件ほど長くかかります。

例外に対処する

上から4行目が、この構成で最も多く起きます。 読めない日付を空のまま扱うのは不便に見えますが、すき間として一覧に出るので、必ず人の目に触れます。 推測で埋めた日付は、一覧から消えてしまいます。

記録を残す

• 証明書のスキャン画像と、案件・受け取った経路（依頼人から預かった／事務所が取り寄せた）
• OCRが返したJSONの全文
• 1通ごとの書き出しのJSONと、人が直した項目の直す前と直した後
• つながりの計算の結果と、そのとき案件にあった証明書の一覧
• 同じ人物としてまとめた記載と、まとめた人
• 司法書士が確定させた図と、確定の日

4つ目で「そのときの証明書の一覧」を残すのは、すき間の一覧が証明書の到着とともに変わるためです。 いつの時点で何が足りなかったかが分かれば、取り寄せにかかった日数を案件ごとに振り返れます。