14条地図GeoJSONを地番検索対応にする前に押さえる考え方
14条地図GeoJSONを地番検索対応にしたい実務担当者が最初に押さえるべきことは、GeoJSONを地図に表示できる状態と、地番で迷わず探せる状態は別物だという点です。地図上に筆界らしき形状が表示されていても、利用者が「この地番を見たい」と検索したときに目的の筆候補へすぐ到達できなければ、業務では使いにくいデータになります。反対に、属性の整理や検索キーの設計を丁寧に行えば、14条地図GeoJSONは相続調査、用地調査、境界確認の準備、現地踏査前の下調べ、庁内・社内での情報共有などに使いやすい基盤になります。
ここでいう14条地図GeoJSONは、実務上の呼び方として使われることが多い表現です。公開されている登記所備付地図データには、不動産登記法第14条第1項の地図に加えて、同条第4項の地図に準ずる図面に係るデータが含まれる場合があります。そのため、すべての区域を同じ精度や同じ重ね合わせ性能で扱えると考えるのは安全ではありません。地図データの整備状況や座標の有無、変換方法によって、背景地図や現地測位結果との合い方が変わることがあります。
また、公開データや変換済みデータは、加工して利活用するためのデータであり、法務局が内容を証明する地図証明書や図面証明書の代替ではありません。GeoJSONを取り込んで検索できるようにしたからといって、それだけで筆界や所有範囲を最終判断できるわけではありません。地番検索対応の目的は、目的の土地候補を素早く探し、関連する周辺筆を確認し、必要な資料や現地確認へ進むための入口を整えることにあります。この前提を明確にしておくと、検索機能に過剰な意味を持たせず、実務で安全に使える仕組みにできます。
GeoJSONは、点、線、面などの形状と属性情報を一つのデータとして扱える形式です。14条地図GeoJSONを扱う場合、多くの実務では筆ごとの面形状を表示し、その属性に含まれる所在や地番に関する情報をもとに検索します。ただし、地番の表記は地域やデータの作成経緯によって揺れが出やすく、同じ土地を指しているつもりでも、入力の仕方が少し違うだけで検索に引っかからないことがあります。たとえば、全角数字と半角数字、ハイフンと長音記号、枝番の区切り、字名の有無、地番区域の表記などが検索精度に影響します。
そのため、地番検索対応では、単にGeoJSONの属性をそのまま全文検索するだけでは不十分です。人が入力する検索語と、データに入っている地番表記の間にある差を吸収する設計が必要です。検索用の正規化、候補表示、複数項目の結合、表記ゆれへの対応、地図表示との連動、更新時の再処理までを一連の流れとして考えることで、実務担当者が迷わず使える地番検索になります。
この記事では、14条地図GeoJSONを地番検索に対応させるための考え方を、6つのステップに分けて解説します。特定の民間ソフトウェアやサービス名に依存せず、汎用的な地理空間データの扱いとして整理します。すでにGeoJSONを入手している担当者だけでなく、これから業務システムや地図ビューアに取り込む担当者にも使える内容です。
ステップ1：地番検索で何を探せる状態にするかを決める
最初のステップは、地番検索で何を探せる状態にするのかを決めることです。ここを曖昧にしたまま作業を始めると、GeoJSONの整形や属性整理を進めても、後から「大字名でも検索したい」「枝番なしで候補を出したい」「周辺筆も同時に見たい」といった要望が増え、検索設計をやり直すことになります。地番検索は、単純な文字検索に見えて、実際には業務フローそのものに関わる機能です。
まず、利用者が入力する検索語を想定します。実務では、地番だけを入力する場合もあれば、町名、大字、字、地番をまとめて入力する場合もあります。調査依頼書や登記関係資料から転記する場合は、所在地の表記が長くなることもあります。一方、現地で急いで確認する場合は、地番の一部だけを入力して候補から選びたいこともあります。このように、検索語の長さや詳しさは利用場面によって変わります。
次に、検索結果として何を表示するかを決めます。目的の筆候補だけを地図上で強調表示するのか、同じ大字や同じ字に属する筆を一覧表示するのか、候補が複数ある場合に地番、所在、データ識別子、必要に応じた参考属性などを並べて選べるようにするのかで、必要な属性整理が変わります。地図上で筆形状をハイライトするだけなら最低限の検索キーで足りますが、候補の取り違えを防ぐには、利用者が見比べられる情報が必要です。
また、地番検索の目的が内部確認なのか、現地作業支援なのか、外部関係者との共有なのかも重要です。内部確認であれば、ある程度専門的な表記でも使えますが、現地作業者や関係部署が使う場合は、候補表示の分かりやすさがより大切になります。外部共有を想定する場合は、検索結果が候補情報であること、最終判断には公的な証明書類や現地確認が必要であることを示す表現も必要になります。
この段階で決めておきたいのは、検索対象の範囲、検索語の想定、検索結果の表示内容、地図上での動作、そして検索結果をどの業務判断に使うのかです。たとえば、地番から筆形状を探し、周辺筆との位置関係を確認し、現地確認の対象を絞るところまでを目的にするのか、それとも調査票作成のための補助情報として使うのかで、求められる精度や説明の仕方が変わります。
さらに、検索できないケースをどう扱うかも最初に決めておくべきです。入力された地番がデータ内に存在しない場合、表記ゆれの可能性があるのか、対象地域外なのか、データ更新が追いついていないのか、単純な入力ミスなのかを利用者が判断できるようにする必要があります。検索結果がゼロ件のときに何も表示しない設計は、実務では不親切です。候補を広げる、地番の一部で再検索する、地域名から絞り込むといった次の動線を用意しておくと、利用者の負担を減らせます。
地番検索対応の成否は、技術的な取り込み作業だけでは決まりません。どの業務で、誰が、どの粒度で、何を確認するために検索するのかを明確にすることで、後続の属性整理や検索キー設計の判断基準ができます。この基準がないと、データをきれいに整えたつもりでも、実務では探しにくい仕組みになってしまいます。
ステップ2：GeoJSON内の属性項目を確認して地番候補を洗い出す
次のステップは、14条地図GeoJSONの中にどのような属性項目が含まれているかを確認し、地番検索に使える候補を洗い出すことです。GeoJSONでは、形状情報と属性情報がセットで格納されます。筆の形状が正しく表示されても、検索に使う属性が不足していたり、想定と違う項目名で入っていたりすると、地番検索はうまく機能しません。まずは地図画面だけを眺めるのではなく、属性の中身を項目単位で確認することが大切です。
確認すべき主な観点は、地番に相当する項目がどれか、所在や区域を示す項目がどれか、筆ごとの識別に使える項目があるか、空欄や欠損がどの程度あるかです。地番が一つの項目にまとまっている場合もあれば、大字、字、親番、枝番のように複数項目に分かれている場合もあります。検索対応では、これらをそのまま使うのか、組み合わせて検索用文字列を作るのかを判断します。
地番候補を洗い出すときは、項目名だけで判断しないことが重要です。項目名が分かりやすく見えても、実際の値には想定外の表記が入っていることがあります。たとえば、数字だけに見える項目に枝番の区切りが含まれている、地番の一部に記号が混ざっている、同じ区域名でも表記が微妙に違う、空欄が一定数存在する、といったケースです。サンプルを数件見るだけでなく、できるだけ全体を集計して、値の種類や空欄の割合を確認すると安全です。
また、筆ごとに一意に近い識別ができるかどうかも確認します。地番は区域が違えば同じ番号が存在することがあります。地番だけで検索すると、複数候補が出ることは珍しくありません。したがって、検索用には地番単体だけでなく、所在に相当する項目と組み合わせたキーを作る必要があります。候補一覧では、同じ地番が複数存在しても利用者が選び分けられるように、区域名や字名を合わせて表示する設計が望ましいです。
GeoJSONの属性確認では、文字コードや改行、不要な空白にも注意します。見た目では同じ文字列に見えても、先頭や末尾に空白が入っていると完全一致検索で失敗することがあります。全角スペースと半角スペースが混在していることもあります。地番検索では、こうした小さな差が検索漏れにつながります。属性を取り込む前に、余分な空白の除去、改行の整理、空欄の扱いを決めておくと後の不具合を減らせます。
さらに、形状と属性の対応関係も確認が必要です。地図上の一つの筆に見えるものが、データ上では複数の面に分かれている場合があります。逆に、複数の形状を一つの属性で扱うべき場合もあります。地番検索で結果を表示したとき、一つの地番に複数の面が該当する可能性を考慮しておかないと、地図上で一部だけが強調され、利用者が誤って判断する恐れがあります。検索結果と形状の関係は、属性だけでなく地図表示でも確認する必要があります。
この段階では、検索に使う項目、候補表示に使う項目、内部管理に使う項目を分けて整理しておくと後の設計が楽になります。検索に使う項目は表記ゆれを吸収するために加工することがありますが、元の属性値はできるだけ保持しておくべきです。元データを残しておけば、後から変換ルールを見直すときにも、どこで値が変わったのかを追跡できます。地番検索対応では、元データ、表示用データ、検索用データを混同しないことが安定運用の基本です。
ステップ3：大字・字・地番を検索しやすい表記に整える
属性項目を確認したら、次は大字、字、地番を検索しやすい表記に整えます。ここが地番検索対応の中心です。地番検索でよく起こる問題は、データに存在するのに検索できないことです。その原因の多くは、地番そのものが間違っているというより、入力された検索語とデータ内の表記が一致していないことにあります。表記ゆれを吸収する仕組みを作ることで、検索漏れを大きく減らせます。
最初に行うべきは、数字と記号の正規化です。地番には数字が多く含まれますが、実務資料では全角数字、半角数字、漢数字、枝番の区切り記号などが混在することがあります。検索では、利用者がどの表記で入力しても候補にたどり着けるように、検索用の文字列を共通の形にそろえます。たとえば、全角数字を半角数字相当として扱う、枝番の区切りを統一する、不要な空白を取り除くといった処理が有効です。
ただし、表示用の地番まで無理に変えてしまう必要はありません。画面に表示する地番は、元データに近い表記を保ったほうが実務資料との照合がしやすい場合があります。一方、検索用の内部文字列は、見た目よりも検索しやすさを優先します。表示用と検索用を分けることで、利用者には見慣れた表記を見せながら、内部では表記ゆれに強い検索を実現できます。
次に、大字や字の扱いを整理します。地番だけでは候補が多くなりすぎる地域では、所在情報との組み合わせが重要になります。利用者が「大字名 地番」や「字名 地番」のように入力することを想定し、複数の属性を結合した検索用文字列を作ります。このとき、項目の間に入る空白や区切り記号に依存しすぎると、入力形式が少し違うだけで検索できなくなります。検索用には、区切りありの文字列と区切りなしの文字列の両方を用意するなど、入力の揺れに備えると実用性が高まります。
地番の親番と枝番が分かれている場合は、検索時の一致条件に注意します。親番だけで検索したときに枝番を含む候補を一覧表示するのか、完全一致だけを出すのかで利用者の体験が変わります。調査の初期段階では、親番だけで関連候補が出るほうが便利です。一方、最終確認に近い場面では、完全一致の候補を優先したほうが取り違えを防げます。検索結果の並び順として、完全一致、前方一致、部分一致のように優先度を分ける設計が有効です。
地番検索では、文字列の正規化だけでなく、候補の見せ方も重要です。検索結果に同じような地番が並ぶ場合、利用者はどれを選べばよいか迷います。候補一覧には、地番だけでなく、大字、字、地番区域、データ上の識別情報、必要に応じておおよその位置を判断できる情報を表示すると、選択ミスを減らせます。地図上で候補を順に強調表示できるようにすると、さらに実務で使いやすくなります。
また、旧字、異体字、略称、地域独自の表記が問題になることもあります。すべてを完全に自動処理するのは難しいため、よく使われる表記だけを別名として登録する方法もあります。たとえば、正式な字名とは別に、現場で通じやすい呼び方や、資料でよく見かける略称を検索用別名として持たせる考え方です。ただし、別名を増やしすぎると誤検索も増えるため、運用ルールを決めて管理する必要があります。
ここで大切なのは、検索しやすくするための加工と、登記関係資料としての原表記を混同しないことです。検索用に整えた文字列は、あくまで探しやすくするための補助です。実際の照合や説明では、元の属性値や公的な資料を確認する流れを残しておくべきです。この分離ができていれば、地番検索は便利でありながら、実務上の誤解も起こしにくい仕組みになります。
ステップ4：筆ポリゴンと検索用インデックスを分けて設計する
地番検索対応を安定させるには、筆ポリゴンそのものと検索用インデックスを分けて考えることが重要です。GeoJSONの各筆属性をそのまま検索するだけでも簡易的な検索はできますが、データ量が増えたり、検索条件が複雑になったりすると、動作が重くなったり、表記ゆれに対応しにくくなったりします。実務で継続的に使うなら、表示用の地図データと検索用の索引データを分けて設計するほうが扱いやすくなります。
筆ポリゴンは、地図上に面として表示するためのデータです。形状が細かいほど表示や読み込みの負荷が高くなります。一方、地番検索に必要なのは、最初からすべての座標を読むことではなく、検索語に該当する筆候補を特定することです。検索時には、地番や所在、筆の識別子、代表点または外接範囲などがあれば、まず候補を出すことができます。選択された後に筆ポリゴンを読み込み、地図上で強調表示する設計にすると、処理を軽くできます。
検索用インデックスには、元の地番表記、正規化した地番表記、所在を含む結合文字列、親番、枝番、候補表示用の名称、筆ポリゴンを参照する識別子などを持たせます。これにより、利用者が地番だけを入力した場合も、所在を含めて入力した場合も、検索候補を返しやすくなります。さらに、代表点やおおよその中心位置を持たせておけば、候補一覧から選択したときに地図をその付近へ移動できます。代表点が元データに含まれない場合は、運用側で計算した値であることが分かるように管理します。
筆ポリゴンと検索用インデックスを分けるもう一つの利点は、更新管理がしやすいことです。GeoJSONが更新された場合、形状データの差し替えだけでなく、検索用文字列や索引も再生成する必要があります。もし検索用の加工結果を筆ポリゴンの属性に直接上書きしていると、元データとの差分が分かりにくくなります。元データから検索用インデックスを再生成する流れを作っておけば、更新時の作業を標準化できます。
地図表示では、検索結果を選択した後の動きも設計します。該当筆を拡大表示する、境界線や塗りを変えて強調する、周辺筆も薄く表示する、属性パネルに元の地番表記を表示する、といった動作が考えられます。ここで注意したいのは、検索結果の筆だけを過度に強調しすぎると、隣接関係や周辺状況が分かりにくくなることです。地番検索は目的地へ移動するための機能であると同時に、周辺を確認するための入口でもあります。
検索用インデックスには、完全一致だけでなく候補検索に使う情報も含めます。たとえば、地番の一部、親番、所在名、読み相当の別名などです。ただし、あいまい検索を広げすぎると、候補が多すぎて実務で使いにくくなります。検索結果の上位には完全一致に近いものを出し、その下に部分一致や関連候補を出すなど、優先順位を設計することが大切です。候補が多い場合は、地域名で絞り込めるようにしておくと操作性が上がります。
また、検索用インデックスを作る際には、データの単位を明確にします。一つの地番に複数ポリゴンが対応する場合、インデックスを地番単位にするのか、ポリゴン単位にするのかを決める必要があります。地番単位にまとめると候補一覧は見やすくなりますが、地図表示では複数形状を同時に強調する処理が必要です。ポリゴン単位にすると形状との対応は単純ですが、候補一覧に同じ地番が複数出る可能性があります。どちらが適切かは、データの構造と利用目的によって判断します。
このように、筆ポリゴンと検索用インデックスを分けて設計すると、検索速度、表記ゆれ対応、更新管理、地図表示の自由度が高まります。小規模な確認用であれば簡易的な方法でも始められますが、業務で繰り返し使うなら、最初から分離設計を意識しておくことをおすすめします。
ステップ5：地図表示と検索結果のズレを点検する
検索用の属性やインデックスを整えたら、次は地図表示と検索結果のズレを点検します。地番検索は、検索候補が表示されるだけでは完成ではありません。利用者が候補を選んだときに、地図上で意図した筆候補が表示され、周辺との位置関係を確認できる必要があります。ここでズレや違和感があると、データ全体への信頼が下がります。
まず確認するのは、検索結果と筆ポリゴンの対応です。検索した地番に対して、想定した筆形状が強調されるかを複数の地域で確認します。特に、同じ地番が複数区域に存在するケース、枝番が多いケース、筆が細長いケース、複数の面に分かれているケースは重点的に確認します。検索候補の表示上は正しく見えても、内部の識別子の紐付けが誤っていると、地図上では別の筆が強調されることがあります。
次に、座標系や位置の扱いを確認します。標準仕様に沿ったGeoJSONでは、経度・緯度を前提に扱われることが多い一方、登記所備付地図データ由来の変換データでは、公共座標系から変換されたデータと、任意座標系のまま扱われるデータが混在する可能性があります。そのため、座標配列の順序、測地系、変換設定、任意座標系の扱いを確認せずに背景地図へ重ねると、位置が大きくずれることがあります。地図に表示できることと、正しい位置に重なることは分けて確認すべきです。
ただし、背景地図や現地測位結果と完全に一致しないからといって、すぐに14条地図GeoJSONが誤っていると判断するのは危険です。各データは作成目的、作成時期、精度、表現方法が異なります。背景地図側に一般化や描画上のズレがある場合もありますし、現地測位にも環境による誤差があります。大切なのは、ズレの有無だけでなく、どのデータを何の判断に使うのかを明確にすることです。地番検索結果は、現地確認や資料確認へ進むための案内として扱うのが安全です。
検索結果の拡大表示にも注意が必要です。筆ポリゴンを選択したとき、地図が適切な縮尺に移動しないと、利用者はどこを見ているのか分からなくなります。小さな筆では十分に拡大し、広い筆では全体が収まるように表示するなど、形状の大きさに応じた表示調整が必要です。細長い筆や離れた面を持つ形状では、単純に中心点へ移動するだけだと一部が画面外に出ることがあります。外接範囲を使って全体を表示する方法が実務的です。
候補が複数ある場合の挙動も点検します。たとえば、地番だけで検索して複数の区域に候補が出たとき、最初の一件だけを自動的に地図表示すると、利用者が誤って選択したと感じることがあります。複数候補がある場合は、まず一覧を表示し、利用者が選んだ候補を地図上で強調するほうが安全です。候補一覧と地図上のハイライトが連動していれば、取り違えを減らせます。
さらに、地番検索の点検では、検索できたケースだけでなく、検索できないケースも確認します。存在しない地番を入力したとき、枝番の区切りを変えて入力したとき、全角で入力したとき、所在名を省略したとき、余分な空白を入れたときなどを試します。実務では、利用者が常に整った形式で入力するとは限りません。入力の揺れにどこまで対応できるか、対応できない場合にどのような案内を出すかを確認することで、現場での使いやすさが変わります。
最後に、検索結果を業務資料と照合します。サンプルとして複数の地番を選び、手元の資料や現地での確認結果と照らし合わせます。このとき、地図表示だけで判断せず、属性表示、地番表記、周辺筆、更新日やデータ管理情報も合わせて確認します。地番検索対応は一度作って終わりではなく、利用しながら不具合や例外を見つけて改善していくものです。点検結果を記録し、変換ルールや検索ルールに反映できる体制を作ることが重要です。
ステップ6：運用時の更新・例外・現地確認まで含めて管理する
最後のステップは、運用時の更新、例外、現地確認まで含めて管理することです。14条地図GeoJSONを地番検索対応にする作業は、初回の変換と検索機能の実装だけで完了するわけではありません。公開データは特定時点の情報であり、将来更新される可能性があります。業務で使うほど例外も見つかります。運用ルールがないまま使い始めると、いつのデータを見ているのか、検索できない地番をどう扱うのか、現地確認結果をどう反映するのかが曖昧になります。
まず、データ更新の流れを決めます。新しいGeoJSONを入手したときに、元データの保管、属性確認、正規化、検索用インデックス生成、地図表示確認、サンプル照合、本番反映という流れを標準化します。毎回担当者の判断だけで処理すると、変換ルールが少しずつ変わり、過去の検索結果との整合が取りにくくなります。更新手順を固定し、処理日、対象範囲、データの抽出時点、変換ルール、確認結果を記録しておくことが大切です。
公開データや変換済みデータを使う場合は、出典の記載や加工の明示も運用ルールに含めます。元データをそのまま表示するのか、検索用に正規化したのか、別レイヤーとして現地確認情報を追加したのかが分からない状態で公開・共有すると、利用者が国や公的機関の原データそのものだと誤解するおそれがあります。編集や加工を行った場合は、元データと加工後データの区別が分かるように管理します。
次に、例外管理を行います。検索できない地番、候補が多すぎる地番、複数ポリゴンに分かれる地番、属性が欠損している筆、表示位置に違和感がある筆などを例外として記録します。例外は一時的な不具合として放置せず、原因を分類します。データに存在しないのか、表記ゆれなのか、区域指定が不足しているのか、変換処理の問題なのかを分けておくと、改善の優先順位が決めやすくなります。
現地確認との関係も重要です。地番検索で目的の筆を見つけられるようになると、画面上の情報だけで判断したくなります。しかし、14条地図GeoJSONは現地の境界標、利用状況、構造物、地形、最新の工事状況を直接示すものではありません。現地での確認、関係資料の照合、必要に応じた専門的な測量や確認手続きと組み合わせて使うべきです。地番検索は、現地へ向かう前の準備と、現地で確認すべき箇所の整理に大きな効果を発揮します。
運用画面には、利用者が誤解しないための表示も必要です。たとえば、表示されている地図情報の性格、更新時期、検索結果が候補であること、最終判断には関係資料や現地確認が必要であることを分かりやすく示します。注意書きが長すぎると読まれませんが、重要な前提を画面や運用マニュアルに入れておくことで、検索機能の過信を防げます。
また、現地確認で得た情報をどう扱うかも決めておきます。現地で撮影した写真、確認した境界標、立会いメモ、測位結果、作業者のコメントなどは、地番検索で見つけた筆と紐づけることで後から探しやすくなります。ただし、現地情報は14条地図GeoJSONの元データそのものを上書きするのではなく、別レイヤーや別属性として管理するのが安全です。元データと現地確認情報を分けておけば、どちらの情報に基づく判断なのかを明確にできます。
さらに、利用者からのフィードバックを受ける仕組みも有効です。検索できなかった地番、候補が分かりにくかった地番、地図表示に違和感があった場所を簡単に報告できるようにすると、運用しながら検索精度を改善できます。特に、地域特有の表記や現場でよく使われる呼び方は、実際に使ってみないと分からないことがあります。利用者の声を検索用別名や候補表示の改善に反映することで、業務に根づく検索機能になります。
地番検索対応は、データ整備、検索設計、地図表示、現地確認、更新管理がつながって初めて実務で役立ちます。初回構築時には完璧を目指しすぎず、元データを保持し、変換ルールを明確にし、例外を記録しながら改善する姿勢が重要です。運用を前提に設計すれば、14条地図GeoJSONは単なる地図表示データではなく、調査業務を支える検索基盤になります。
まとめ：14条地図GeoJSONは地番検索と現地確認をつなげて価値が出る
14条地図GeoJSONを地番検索対応にするには、GeoJSONを読み込んで地図に表示するだけでは足りません。地番検索で何を探せるようにするのかを決め、属性項目を確認し、大字、字、地番の表記を検索しやすく整え、筆ポリゴンと検索用インデックスを分けて設計し、地図表示とのズレを点検し、運用時の更新や例外まで管理する必要があります。この一連の流れを押さえることで、検索漏れや取り違えを減らし、実務で使いやすい地図データに近づけられます。
特に重要なのは、元データ、表示用データ、検索用データ、現地確認情報を混同しないことです。検索しやすくするために地番表記を正規化しても、元の属性値は残しておくべきです。現地で確認した情報を追加する場合も、14条地図GeoJSONそのものを直接書き換えるのではなく、別の記録として紐づけるほうが安全です。こうした分離ができていると、後からデータ更新や確認作業を行うときにも、情報の由来を追いやすくなります。
地番検索は、調査対象の土地を素早く見つけるための入口です。しかし、実務で本当に価値が出るのは、検索した筆を地図上で確認し、周辺筆との関係を見て、現地で何を確認すべきかを整理できるところです。検索結果から現地確認へ自然につなげられる仕組みを作れば、机上調査と現場作業の間にある手戻りを減らせます。
現場では、地図上で見た筆の位置と実際の状況を照合する作業が欠かせません。地番検索で対象地を見つけた後、現地で位置を確認し、写真や測位結果を記録し、関係者と共有できる状態にすることで、14条地図GeoJSONの活用範囲は大きく広がります。スマートフォンを使って高精度な位置確認や写真記録を行えるLRTK Phoneを併用すれば、机上のGeoJSONデータと現場確認の記録を結びつけやすくなります。検索で見つけ、現地で確かめ、記録として残す流れを整えることが、14条地図GeoJSONを実務に活かすためのポイントです。