登記事項証明書や公図をOCRで読み取り、自社システムに取り込むことは技術的に可能です。ただし成否を分けるのは読み取り精度そのものではなく、「どの登記簿を自動確定させ、どれを人に回すか」を先に決める設計です。本記事ではその判断基準と工程を示します。
登記簿OCRとは何を指すのか？
登記簿OCRとは、登記事項証明書や公図のPDF・画像から、表題部・権利部といったセクションの境界を判別し、所有者名・持分・抵当権などの項目を自社システムのフィールドに対応づけて構造化する処理である。
単に文字を文字列として起こすだけなら市販のOCRで済みます。業務で使えるかどうかを決めるのは、その後の3つです。
- どのセクションの記載かを正しく判別できるか（甲区の所有者と乙区の抵当権者を混同しない）
- 抹消された記載を除外できるか
- 判別できなかったものを「判別できなかった」と自己申告できるか
3番目が抜けている実装が最も危険です。誤った値を自信満々に返すシステムは、人が全件を目視し直すことになり、結果として誰も使わなくなります。
登記簿はOCRしやすいのか、しにくいのか？
書式が安定しているという点ではOCR向きです。しかし入力ソースによって難易度が段違いに変わります。取り込み対象の内訳を最初に棚卸ししてください。
| ソース | テキスト情報 | 難易度 | 注意点 |
|---|---|---|---|
| 登記情報提供サービスのPDF | 埋め込みあり | 低 | レイアウト解析で足りる。OCRを通さない方が精度が高い |
| 法務局発行の証明書をスキャン | なし（画像） | 中 | 傾き・かすれ・押印のかぶり。表罫線の検出が必要 |
| FAXやコピーの孫コピー | なし（画像） | 高 | 細い文字が潰れる。地番の枝番が読めない |
| 閉鎖登記簿・旧表記の謄本 | なし（画像） | 非常に高 | 縦書き、手書き、旧字体。全自動化の対象から外す判断も要る |
| 公図（法務局PDF） | 図形＋地番文字 | 中〜高 | 座標を持たないラスタ図。地番文字の向きが一定でない |
ここで多くのプロジェクトが躓くのは、検証用サンプルを「きれいなPDF」だけで集めてしまうことです。デモは通るのに本番で崩れます。サンプル母集団には、共有名義・区分建物・相続で権利者が複数・古い紙の謄本を意図的に混ぜてください。
精度を崩す例外パターンは具体的に何か？
実装で繰り返し問題になるのは以下です。いずれも「たまにしか出ない」ため設計初期に見落とされ、運用開始後に信頼を失う原因になります。
1. 抹消事項の下線
登記事項証明書では抹消された記載に下線が引かれます。PDFからテキストを抽出すると下線情報は落ちるため、住所変更前の旧住所や、すでに抹消された抵当権を「現在有効」として取り込みます。所有者へのDM発送で旧住所に送る、担保状況を誤認するといった実害に直結します。テキスト抽出とは別に、下線の描画オブジェクトまたは画像上の直線を検出して該当文字列に紐づける処理が必要です。
2. 共有持分
「持分2分の1」が複数行に分かれ、権利者ごとに順位番号と受付年月日が異なります。1レコード1所有者という素直なデータモデルを組むと、持分の合計が1にならないまま登録されます。持分は文字列でなく分子・分母に分解して保持し、合計値の検算をシステム側で行ってください。
3. 相続による権利者多数
数十名の共有になった土地では、甲区の記載が複数ページにまたがります。ページ跨ぎでレコードが切れる、ヘッダが再出現して1件目と誤認される、という不具合が出ます。
4. 区分建物
一棟の建物の表示、専有部分の建物の表示、敷地権の表示と、表題部が入れ子になります。「一棟の建物の床面積」を専有部分の面積として取り込む誤りが典型です。
5. 分合筆・地積更正の履歴
表題部に旧地番や旧地積が下線付きで残ります。ここでも下線処理が効きます。
6. 附属建物
主たる建物とは別に符号付きで並びます。棟数分のレコードを生成する必要があり、単純な1建物1レコード設計では欠落します。
7. 地番の表記
枝番、いわゆる字持ち地番、イロハ地番など、「123-4」に収まらない表記があります。数値型で持つと壊れます。地番は必ず文字列として保持し、正規化ルールを別に持ってください。
8. 公図の地図種別
不動産登記法第14条第1項の地図と、「地図に準ずる図面」（旧土地台帳附属地図）では精度が全く違います。後者を面積根拠に使うことはできません。
例外はどう扱うべきか？
結論は、例外は自動化せず人に回す前提で設計することです。「例外もいずれ精度を上げて自動化する」というロードマップは、運用開始時点の信頼を犠牲にします。
抽出結果を3つに振り分けます。
| 区分 | 条件の例 | 処理 |
|---|---|---|
| 自動確定 | テキストレイヤあり／単独所有／下線検出ゼロ／必須項目すべて充足 | そのままシステム登録。人の確認を省く |
| 要確認 | 共有持分あり／下線を検出／権利者が複数ページ／信頼度が閾値未満 | 検証UIに載せ、該当箇所をハイライトして人が確定 |
| 自動化対象外 | 手書き・縦書きの閉鎖謄本／解像度が基準未満／セクション判別失敗 | OCRを試みず、原本参照のフラグを立てて手入力に回す |
重要なのは、区分の判定をAIの出力の「確からしさ」だけに頼らないことです。「共有持分がある」「下線が1本でもある」といった構造的なルールで先に要確認へ落とす方が、運用者に説明可能で安定します。判定理由を必ずレコードに保存し、後から閾値を動かせるようにしておきます。
抽出項目はどう絞るのか？
抽出項目は「登記簿に書いてある項目」から選ぶのではなく、出力先の業務から逆算して決めます。項目を1つ増やすたびに例外パターンと確認工数が増えるため、使わない項目は最初から対象外にします。
| 業務目的 | 最小限の抽出項目 | 落としてよい項目 |
|---|---|---|
| 仕入れ・買取査定 | 所有者氏名／住所／共有持分／地目／地積／抵当権の有無と債権額 | 原因日付、共同担保目録の全内容 |
| 所有者へのDM・追客 | 所有者氏名／住所／地番 | 権利部乙区すべて |
| 重要事項説明書の下書き | 所在／地番／地目／地積／所有権に関する事項／所有権以外の権利に関する事項 | 閉鎖された旧記載 |
| 物件データベースの整備 | 不動産番号／所在／家屋番号／構造／床面積 | 甲区の履歴全件 |
判断基準はシンプルです。「その項目が空欄だったとき、業務が止まるか」。止まらないなら必須項目にしません。必須項目を増やしすぎると、要確認に落ちる件数が増えて自動化の意味が薄れます。
導入までの工程はどう進めるのか？
エクサテックが業務自動化を組むときの順序は、対象業務が転記でもOCRでも共通しています。株式会社イーリアルティ様の転記エージェントでも、契約の前段階から何度も現場に足を運び、困りごとを理解するところから始めました。登記簿OCRでも同じ手順を踏みます。
- 現場で実際の入力操作を観察する。 登記簿を見ながらどのフィールドに何を入れているか、どこで手が止まるかを記録します。ここで「実は地積は使っていない」といった事実が出ます。
- 出力先のフィールド定義を確定する。 自社システム側のカラム、型、必須／任意を先に固めます。抽出項目はここから逆算します。
- サンプルの母集団を作る。 きれいなPDFだけでなく、共有・区分・相続多数・古い紙を意図的に混ぜます。数を揃えるより種類を揃えます。
- テキストレイヤの有無で処理を分岐させる。 テキストがあるPDFにOCRをかけると精度が落ちます。分岐は最初に入れます。
- セクション分割 → 項目抽出の2段構成で組む。 表題部・甲区・乙区・共同担保目録を先に切り、そのうえで項目を取ります。1回のプロンプトで全部取ろうとすると、甲区と乙区の混同が起きます。
- 例外検出ルールを実装する。 下線検出、持分合計の検算、権利者数、ページ跨ぎ。ここが自動確定と要確認を分ける関門になります。
- 検証UIを同時に作る。 後述しますが、これは後回しにできません。
- 人が修正した内容をログに残す。 どの項目がよく直されるかが、次の改善の唯一の根拠になります。
検証UIには何が必要か？
抽出処理と検証UIはセットで作らないと運用に乗りません。「まずAPIだけ作って精度を見る」という進め方は、精度の評価自体ができないため推奨しません。
検証UIの必須要件は以下です。
- 原本と抽出結果の左右並置。 別画面に切り替える構成にすると、確認のたびにウィンドウを行き来し、手入力より遅くなります。
- 該当箇所のハイライト。 抽出値をクリックすると原本画像の該当位置が光る。これがないと確認者は結局全文を読みます。
- 項目単位の確定・修正。 レコード単位のOK／NGでは、1項目の誤りで全項目を打ち直すことになります。
- 要確認となった理由の表示。 「持分の合計が1になりません」「下線を検出しました」と理由が出れば、確認者はその1点だけ見れば済みます。
- 差し戻しと手入力への切り替え。 自動化対象外に落ちた案件を、同じ画面で手入力できる導線を必ず用意します。別業務にすると運用が分断します。
- 修正ログの保存。 誰がどの項目をどう直したかを残します。
できないこと・限界はどこか？
過大な期待のまま導入すると使われなくなるため、限界を明示します。
- 法的判断はできません。 権利関係の有効性、対抗要件の充足、相続関係の確定といった判断は行えません。抽出はあくまで記載事項の転記です。
- 境界の確定はできません。 公図から読み取れるのは地番と隣接関係までです。境界確定は土地家屋調査士の業務であり、公図は境界確定図ではありません。
- 地図に準ずる図面からの面積算出は用途を限定してください。 精度が保証されていないため、査定の参考値までに留めます。
- 手書き・縦書きの閉鎖登記簿の全自動化は現実的ではありません。 対象外に振り分け、必要なものだけ人が入力する運用が結果的に速くなります。
- 原本性は担保されません。 抽出データは業務用の写しであり、証明力を持つのは登記事項証明書そのものです。
- 重要事項説明書は下書きまでです。 宅地建物取引業法第35条により、重要事項の説明は宅地建物取引士が行い、書面には宅地建物取引士の記名が必要です（2022年5月18日の法改正で押印は不要となりました）。生成物の最終確認と説明責任は人に残ります。個別案件の運用は専門家にご確認ください。
- 100%の自動確定は目標にしません。 目標は「確認すべき件数を確認すべきものだけに絞る」ことです。
関連する実装・運用の手順
不動産資料の読み取りでは、帳票ごとの抽出方法と、抽出後の住所表記の統一を分けて考えます。対象資料に応じて次の手順を参照してください。
まとめ
- 登記簿・公図のOCR構造化は実用段階にあるが、成否を決めるのは読み取り精度ではなく例外の振り分け設計である
- 抹消事項の下線、共有持分、区分建物、権利者多数、古い手書き謄本が精度を崩す主要因
- 抽出結果は「自動確定／要確認／自動化対象外」の3区分に振り分け、判定は構造的ルールで行う
- 抽出項目は登記簿の記載項目からではなく、出力先の業務から逆算して最小限に絞る
- 検証UIは抽出処理と同時に作る。原本並置・該当箇所ハイライト・項目単位の確定・修正ログが必須要件
よくある質問
Q. 登記簿謄本をOCRで読み取って自社システムに取り込めますか？
A. 可能です。ただし全件自動確定は現実的ではありません。登記情報提供サービスのPDFはテキストレイヤがあるため高精度で処理できますが、共有持分や権利者多数、古い手書き謄本は例外として人の確認に回す設計が前提になります。
Q. OCRで最も事故が起きやすい項目は何ですか？
A. 抹消事項です。登記事項証明書では抹消された記載に下線が引かれますが、テキスト抽出では下線情報が落ちるため、旧住所や抹消済みの抵当権を現在有効な情報として取り込む事故が起きます。下線検出を別処理として持つ必要があります。
Q. 公図から敷地形状のデータを自動生成できますか？
A. 地番と隣接関係の読み取りまでは実用域ですが、面積計算や境界確定に使えるポリゴン生成は用途を限定すべきです。公図の多くは「地図に準ずる図面」で精度が保証されず、境界確定図でもないため、参考図としての利用に留めます。
Q. 抽出項目はどう決めればよいですか？
A. 出力先の業務から逆算します。仕入れ査定なら所有者・共有持分・抵当権・地目・地積、DM発送なら所有者の氏名住所だけで足ります。項目を増やすほど例外パターンが増え確認工数が跳ねるため、使わない項目は最初から抽出対象に入れません。
Q. 重要事項説明書の作成にOCR結果をそのまま使えますか？
A. 下書き生成までは有効ですが、最終確認は必須です。宅地建物取引業法第35条により重要事項の説明は宅地建物取引士が行い、書面には宅地建物取引士の記名が必要です（2022年5月18日の改正で押印は不要）。個別の運用は専門家にご確認ください。
ご相談について
エクサテックは、不動産・建設業の現場に入り込み、仕組みの設計からWebアプリの実装までを同一チームで行っています。登記簿の取り込みについても、まずは現在どの帳票をどの順で入力しているかを拝見するところから始めます。手元にある登記簿のパターンを一緒に棚卸しするだけでも、自動化できる範囲は見えてきます。お気軽にお声がけください。
