GeoJSON公開前に消すべき個人情報と確認項目7つ

GeoJSONは、地物の形状と属性情報をひとつのデータとして扱いやすく、地図表示、現地調査、設備管理、施工管理、公開用マップなどで広く使われます。一方で、座標と属性が結びつく形式であるため、公開前の確認が不十分だと、氏名や連絡先のような明らかな個人情報だけでなく、位置情報、作業履歴、写真名、メモ欄、管理番号などから個人や特定の場所が推測されるおそれがあります。

この記事では、geojsonで検索する実務担当者に向けて、公開前に消すべき個人情報と確認項目を7つに分けて解説します。単に「名前を消す」だけではなく、座標、属性、ファイル名、履歴、公開範囲まで含めて見直すことで、外部公開や関係者共有のリスクを下げやすくなります。

目次

• GeoJSON公開で個人情報が残りやすい理由

• 1 氏名・住所・連絡先など直接識別できる情報を消す

• 2 座標から個人や場所が特定されないか確認する

• 3 属性情報の自由記述欄に個人情報が混ざっていないか確認する

• 4 写真名・添付ファイル名・リンク先に個人情報が残っていないか確認する

• 5 管理番号や内部IDから個人や案件が推測されないか確認する

• 6 作成者情報・更新履歴・メタ情報を公開用に整理する

• 7 公開範囲と利用目的に合わせてデータを最小化する

• GeoJSON公開前の確認フローを整える

• まとめ

GeoJSON公開で個人情報が残りやすい理由

GeoJSONは、点、線、面といった地理空間情報を扱うためのデータ形式です。現地で取得した点の座標、道路や設備の線形、敷地や区域のポリゴンなどを、属性情報と一緒に保存できます。たとえば、ある点が「点検箇所」であり、その属性として点検日、担当者、異常内容、写真番号、対応状況などを持つことがあります。この構造は実務上とても便利ですが、公開前の確認では注意が必要です。

個人情報は、氏名や住所のようにひと目で分かるものだけではありません。座標そのものが住宅、私有地、勤務先、通学先、現場の出入り口、設備の所在などを示す場合があります。また、属性欄に「山田様宅前」「佐藤氏立会い」「入居者不在」「苦情対応済み」のような記録が残っていると、氏名と生活情報、対応履歴が結びついてしまいます。さらに、ファイル名や写真リンク、内部管理番号から案件名や顧客名が推測できることもあります。

GeoJSONはテキストとして中身を確認しやすい一方で、行数が多くなると人の目だけでは見落としが増えます。地図画面では見えていない属性がデータ内には残っている、公開画面では非表示にしている項目がダウンロードデータには含まれている、といったことも起こり得ます。そのため、GeoJSONを公開する前には、表示結果だけではなく、元データの中身を確認することが重要です。

特に、行政区域、現地調査、設備台帳、建設現場、災害調査、不動産関連、インフラ点検、農地管理、地域イベントなどのデータでは、場所と人の関係が近くなります。地図としては便利な情報でも、公開用データとしては詳しすぎる場合があります。公開の目的に対して、その座標精度や属性項目が本当に必要かを考えることが、個人情報対策の出発点になります。

1 氏名・住所・連絡先など直接識別できる情報を消す

最初に確認すべきなのは、氏名、住所、電話番号、メールアドレス、建物名、部屋番号、個人名を含む事業者名など、個人を直接識別できる情報です。GeoJSONでは、これらがpropertiesの中に保存されていることが多くあります。たとえば、owner_name、resident_name、contact、address、memo、note、customer、applicant、managerといった項目名がある場合は、公開前に必ず確認する必要があります。

実務データでは、作業効率を優先して、調査時のメモや台帳項目に個人名を入れていることがあります。現場では「誰の土地か」「誰に確認したか」「どこへ連絡するか」が重要になるため、内部利用では自然な運用です。しかし、公開用のGeoJSONでは、そのまま出す必要がない情報がほとんどです。公開目的が位置の可視化や傾向の共有であれば、個人名や連絡先は削除しても目的を達成できることが多いです。

住所についても注意が必要です。公開する情報が店舗や公共施設などの公開済み所在地であれば問題になりにくい場合がありますが、個人宅、私有地、賃貸物件、入居者情報と結びつく住所は慎重に扱うべきです。番地や部屋番号まで含む住所は、個人の生活拠点を示す可能性があります。必要に応じて町丁目程度に丸める、区域名に置き換える、住所項目そのものを削除するなどの処理を検討します。

連絡先も公開前に消すべき代表的な項目です。電話番号やメールアドレスは、担当者連絡用として内部データに入っていることがありますが、公開用地図には通常不要です。連絡先を公開する必要がある場合でも、個人の連絡先ではなく、組織の代表窓口や公開専用の問い合わせ先に置き換えるのが安全です。

ここで大切なのは、項目名だけで判断しないことです。たとえば、remarks、description、comment、備考、摘要、自由記述といった欄に個人名が入っていることがあります。逆に、nameという項目が地物名を示している場合もあります。公開前には、項目名の意味と実際の値の両方を見て、直接識別できる情報が残っていないか確認します。

削除作業では、値を空欄にするだけでなく、項目ごと削除するかどうかも考えます。値を空にしても、項目名が「顧客名」「所有者名」のまま残っていると、データの性質が推測されることがあります。公開用として不要な項目は、列ごと削除するほうが分かりやすく、安全性も高まります。

2 座標から個人や場所が特定されないか確認する

GeoJSONの特徴は、座標を持つことです。そのため、個人情報対策では属性だけでなく、geometryの座標も確認対象になります。氏名や住所を消しても、座標が個人宅の玄関、私有地内の設備、特定の部屋の位置、入退場場所、通学路上の細かな地点などを示していれば、個人や生活実態が推測される可能性があります。

点データは特に注意が必要です。点は位置を直接示すため、精度が高いほど特定性が高まります。たとえば、調査地点を数センチから数十センチ単位で記録している場合、その点が敷地内のどこにあるかまで分かります。公開目的が「地域内の分布を示すこと」であれば、そこまで細かい座標は不要かもしれません。公開用には座標を丸める、代表点に置き換える、区域単位に集計するなどの処理が考えられます。

線データや面データでも油断はできません。道路、配管、境界、通路、敷地、調査範囲などの線や面は、個人の土地や施設と強く結びつく場合があります。特に、面データが宅地や建物の輪郭に近い場合、個人の所有や利用状況が推測されることがあります。公開する必要がある範囲を見直し、詳細すぎる境界線を簡略化する、広い区域にまとめる、内部の細かな形状を削除するなどの対策が有効です。

座標精度の調整は、単に桁数を減らすだけでは十分でない場合があります。座標を丸めても、元の場所がほぼ分かることがあります。また、複数の点が集まることで、特定の住居、施設、作業エリアが浮かび上がることもあります。公開前には、実際に地図上で表示し、どの程度の場所まで分かるかを目で確認することが大切です。

位置情報のリスクは、単体のGeoJSONだけで判断できないこともあります。公開済みの住所情報、航空写真、地番図、施設一覧、過去の資料などと組み合わせると、匿名化したつもりの点が再識別される場合があります。そのため、公開範囲が広いほど、座標の扱いは慎重にする必要があります。社内共有、関係者限定共有、一般公開では、許容される精度が異なると考えるべきです。

現場で取得したGeoJSONは、業務上は高精度であることに価値があります。しかし、公開用データでは、精度が高いことが常に良いとは限りません。公開目的に必要な位置の粒度を決め、その目的を超える精度は落とすという考え方が重要です。

3 属性情報の自由記述欄に個人情報が混ざっていないか確認する

GeoJSONの個人情報確認で見落としやすいのが、自由記述欄です。定型項目であれば項目名からリスクを見つけやすいですが、自由記述欄には現場担当者が状況をそのまま記録していることがあります。備考、メモ、コメント、説明、対応内容、引き継ぎ事項、調査結果、異常内容といった項目には、公開に向かない情報が混ざりやすくなります。

たとえば、点検データに「住民から連絡あり」「所有者に確認済み」「隣地の方より指摘」「担当者が不在」「高齢者宅のため事前連絡」などの記載が残っている場合、個人名がなくても生活状況や関係者の存在が分かることがあります。公開用には、こうした具体的な人物関係や生活情報を削除し、「現地確認済み」「関係者確認済み」「対応済み」のような抽象的な表現に置き換えるほうが安全です。

自由記述欄には、感情的な表現や内部判断が残っていることもあります。たとえば、苦情、トラブル、未納、拒否、危険、要注意、クレームといった言葉が、個人や場所と結びついて公開されると、関係者に不利益を与える可能性があります。公開の目的が状態の共有であれば、表現を中立的に整え、必要な事実だけに絞るべきです。

また、自由記述欄には、作業者の個人名や社内担当者名が入ることもあります。公開データでは、作業者名を出す必要がない場合が多いため、担当部署、担当区分、確認済みフラグなどに置き換えると扱いやすくなります。担当者を残す必要がある場合でも、個人名ではなく役割名や部署名にすることで、公開時のリスクを下げられます。

自由記述欄の確認では、目視だけに頼ると見落としが出やすくなります。氏名らしい文字列、電話番号らしい数字、メールアドレスらしい記号、住所に使われやすい語、部屋番号、建物名、個人を示す敬称などを検索し、候補を洗い出す方法が有効です。ただし、機械的な検索だけでは文脈までは判断できません。最終的には、公開目的に照らして人が確認することが必要です。

公開用のGeoJSONを作るときは、自由記述欄をそのまま残すのではなく、公開用の説明文に再編集する意識が大切です。内部メモは業務のための記録であり、公開文は第三者に見せるための情報です。この2つを分けて管理すると、公開前の確認がしやすくなります。

4 写真名・添付ファイル名・リンク先に個人情報が残っていないか確認する

GeoJSONには、写真や資料へのリンクを属性として持たせることがあります。現場写真、報告書、図面、点検票、添付ファイルなどを紐づけると、地図上で情報を確認しやすくなります。しかし、公開前には、リンク先やファイル名にも個人情報が残っていないか確認する必要があります。

よくあるのは、写真名やフォルダ名に案件名、顧客名、住所、担当者名が含まれているケースです。たとえば、公開画面では写真のサムネイルしか見えなくても、GeoJSONの中には元のファイル名や保存先の文字列が残っていることがあります。閲覧者がデータを取得できる状態であれば、画面に表示されない情報でも確認できてしまいます。

添付ファイルへのリンクも注意が必要です。リンク先の資料に個人情報が含まれていれば、GeoJSON本体をきれいにしても意味がありません。公開前には、GeoJSONに含まれるリンクをたどり、リンク先の内容も確認します。写真の中に表札、車両番号、顔、郵便物、掲示物、室内の個人物、作業員の名札などが写っていないかも確認対象です。

リンクの公開範囲も重要です。内部共有用のリンクをそのまま公開データに含めると、本来見せる予定のない資料へアクセスされるおそれがあります。また、アクセス制限があるつもりでも、リンクを知っていれば閲覧できる設定になっている場合があります。公開用GeoJSONでは、公開してよい資料だけを別に用意し、不要なリンクは削除するのが安全です。

ファイル名については、公開用の命名規則を用意しておくと管理しやすくなります。個人名や住所を含めず、公開用の連番、地物種別、撮影日、区域コードなど、必要最小限の情報にします。ただし、区域コードや連番でも内部台帳と簡単に照合できる場合は、後述する管理番号の扱いにも注意が必要です。

写真や添付資料は、GeoJSON本体とは別ファイルであるため、確認漏れが起きやすい部分です。公開前チェックでは、propertiesの中にurl、link、photo、image、file、attachment、documentといった項目がないか確認し、それぞれの値とリンク先を見直します。地図上では見えない情報ほど、公開前に丁寧に確認することが大切です。

5 管理番号や内部IDから個人や案件が推測されないか確認する

氏名や住所を消しても、管理番号や内部IDから個人や案件が推測できる場合があります。たとえば、顧客番号、契約番号、受付番号、工事番号、問い合わせ番号、地番に近い番号、台帳番号などです。これらは一見すると個人情報ではないように見えますが、内部資料や別の公開資料と照合できると、個人や案件を特定する手がかりになります。

GeoJSONでは、各地物にidやproperties内の識別子が付いていることがあります。データ管理上は必要な項目ですが、公開用にそのまま残す必要があるかは別問題です。一般公開では、内部システムで使う主キーや管理番号を削除し、公開用の一時的な番号に置き換えることを検討します。公開用番号は、元の番号と直接対応しない形にすることで、照合リスクを下げられます。

管理番号の中に意味が埋め込まれている場合もあります。たとえば、日付、地域、担当部署、案件種別、顧客区分、受付順などが番号から読み取れる場合です。内部では便利な設計ですが、外部に出すと業務量、特定地域の対応状況、個別案件の時期などが推測されることがあります。公開に必要なのが地物の識別だけであれば、意味を持たない公開用IDに変換するほうが安全です。

また、番号が連番である場合、公開されていないデータの存在が推測されることもあります。たとえば、公開データに1番、2番、5番があり、3番と4番が欠けていると、非公開の案件があるのではないかと推測される可能性があります。必ずしも問題になるとは限りませんが、公開データとしての見え方を確認しておくことが大切です。

内部IDを削除すると、公開後の問い合わせ対応が難しくなると考える担当者もいます。その場合は、公開用IDと内部IDの対応表を社内だけで管理する方法があります。公開データには公開用IDだけを残し、問い合わせがあったときには社内の対応表で確認します。このように、公開用データと内部管理データを分けることで、利便性と安全性を両立しやすくなります。

管理番号は、個人情報確認の中でも判断が難しい項目です。単体では無意味に見えても、他の情報と組み合わせると意味を持つことがあります。公開前には、番号の由来、他資料との照合可能性、公開目的に対する必要性を確認し、不要であれば削除または変換します。

6 作成者情報・更新履歴・メタ情報を公開用に整理する

GeoJSON本体には、作成者や更新者、作成日時、更新日時、データ取得方法、編集履歴などが属性として含まれることがあります。これらはデータ管理では便利ですが、公開時には必要性を確認すべき情報です。特に、個人の作業者名、社内アカウント名、端末名、部署内の略称、内部プロジェクト名などが残っている場合は注意が必要です。

作成者情報は、責任の所在を示すために内部では重要です。しかし、一般公開データで個人名まで出す必要があるとは限りません。公開用には、作成主体を組織名や部署名に置き換える、問い合わせ先を代表窓口にする、個人の編集履歴は削除するなどの対応が考えられます。担当者の個人名が残っていると、外部から直接連絡が来る、業務外の問い合わせが集中する、といったリスクもあります。

更新日時や作業日時も、扱い方によっては注意が必要です。たとえば、個人宅周辺の調査日時が細かく残っていると、在宅確認、訪問履歴、作業時間帯などが推測される可能性があります。公開目的に詳細な時刻が不要であれば、日付だけにする、月単位に丸める、期間表示にするなどの方法があります。災害対応や点検履歴など、時系列が重要なデータでも、どの粒度まで公開するかを検討します。

メタ情報には、座標系、測定方法、データ作成条件、精度情報なども含まれる場合があります。これら自体は個人情報ではないことが多いですが、公開すると現場の詳細な作業方法や設備位置の精度が分かることがあります。公開目的が利用者の理解を助けることであれば必要な情報ですが、内部運用や安全管理に関わる情報まで含める必要はありません。

また、GeoJSONを他形式から変換した場合、変換元の項目がそのまま残ることがあります。画面上では使っていない属性でも、データ内には元の列名や値が含まれている場合があります。公開前には、表示項目だけでなく、データ内の全項目を確認します。不要なメタ情報や編集用項目は、公開用データから取り除くのが基本です。

更新履歴を公開する場合は、履歴の内容にも注意が必要です。「誰が」「いつ」「何を修正したか」が細かく残ると、作業者や関係者の行動が分かることがあります。公開用には、個人単位の履歴ではなく、データ全体の更新日や版番号だけを示す方法が適しています。利用者に必要な情報は残しつつ、内部の作業過程までは出さない設計にすることが大切です。

7 公開範囲と利用目的に合わせてデータを最小化する

GeoJSONの公開前チェックで最も重要なのは、公開目的に対して必要な情報だけを残すことです。個人情報を消す作業は、単なる伏せ字処理ではありません。公開する相手、利用目的、必要な精度、必要な属性を整理し、それを超える情報を削ることが基本になります。

たとえば、一般向けに地域の傾向を示すだけなら、個別地点の正確な座標は不要かもしれません。関係者向けに現場対応を共有する場合でも、氏名や個人連絡先までは不要なことがあります。行政区域や設備分布を見せるだけであれば、内部メモ、担当者、作業履歴、添付リンクは削除できます。このように、目的から逆算して項目を減らすと、安全性が高まります。

データ最小化では、まず公開対象者を明確にします。社内だけで使うのか、協力会社と共有するのか、発注者に提出するのか、一般公開するのかによって、許容される情報量は変わります。社内向けと一般公開向けで同じGeoJSONを使い回すと、不要な情報が外に出やすくなります。公開範囲ごとに別の出力設定を用意することが望ましいです。

次に、属性項目を必要性で分類します。公開目的に必須の項目、あると便利だが必須ではない項目、内部管理だけに必要な項目、公開してはいけない項目に分けます。迷う項目は、残す理由を説明できるかどうかで判断します。説明できない項目は、公開用データから削除する候補です。

座標についても同じです。高精度な座標が必要な利用者もいれば、区域単位で十分な利用者もいます。GeoJSONは高精度な位置情報を保持できますが、公開時にはその精度を目的に合わせて調整する必要があります。正確すぎる位置情報は、個人や設備の特定につながる場合があるため、一般公開では特に注意します。

公開用データは、元データのコピーとして作るのではなく、公開専用の成果物として作る意識が大切です。元データには業務に必要な情報を保持し、公開用データには必要最小限の情報だけを出力します。この分離ができていれば、公開後に元データを更新しても、不要な項目が再び混入するリスクを下げられます。

GeoJSON公開前の確認フローを整える

個人情報対策は、担当者の注意力だけに頼ると安定しません。公開のたびに確認項目が変わったり、急ぎの作業で見落としたりすると、同じミスが繰り返されます。GeoJSONを継続的に公開する場合は、公開前の確認フローを決めておくことが重要です。

まず、公開用GeoJSONを作成する前に、元データと公開データを分けます。元データには現場運用に必要な情報が含まれていても構いませんが、公開データには公開目的に必要な項目だけを出力します。最初から公開用の項目一覧を決めておけば、不要な列を後から探す手間が減ります。

次に、属性項目の棚卸しを行います。すべてのproperties項目を一覧にし、各項目について公開可否を判断します。項目名、値の例、公開目的との関係、削除または変換の方法を確認します。自由記述欄、リンク項目、ID項目、住所関連項目は、特に重点的に確認します。

その後、実際の値を確認します。項目名が安全そうに見えても、値に個人情報が入っていることがあります。逆に、項目名だけでは判断できない場合もあります。データ件数が多い場合は、検索や抽出で候補を洗い出し、代表例だけでなく異常値や長文の値も確認します。自由記述欄は、長い文ほど個人情報が混ざりやすいため注意が必要です。

座標確認では、地図上に表示して位置の粒度を確認します。住所を消した後でも、点が個人宅や特定施設を直接示していないかを見ます。公開目的に対して細かすぎる場合は、座標の丸め、代表点化、集計、形状の簡略化などを検討します。地図として見たときに、第三者が何を推測できるかを想像することが大切です。

最後に、第三者視点で確認します。作成者本人はデータの背景を知っているため、危険な情報に慣れてしまうことがあります。公開前に別の担当者が確認すると、見落としを減らせます。特に、一般公開や外部提出のデータでは、作成者と確認者を分ける運用が有効です。

公開後の対応も決めておく必要があります。公開後に個人情報の混入が見つかった場合、すぐに公開停止できるか、修正版を出せるか、関係者へ連絡できるかを事前に確認しておきます。公開前対策が基本ですが、万一の対応手順を用意しておくことで、被害を小さくしやすくなります。

まとめ

GeoJSONは、位置情報と属性情報をまとめて扱える便利な形式です。しかし、その便利さは、公開時のリスクにもつながります。氏名や連絡先を消すだけでは不十分であり、座標、自由記述、写真リンク、添付ファイル名、管理番号、作成者情報、更新履歴、公開範囲まで含めて確認する必要があります。

公開前に見るべき基本は、直接識別できる情報が残っていないか、座標から個人や場所が特定されないか、自由記述欄に関係者情報や生活情報が混ざっていないか、リンク先やファイル名に内部情報が残っていないか、管理番号から元データと照合できないか、作成者や履歴の情報が過剰ではないか、公開目的に対してデータ量が多すぎないかの7点です。

GeoJSONの安全な公開では、すべてを隠すことが目的ではありません。必要な情報を、必要な相手に、必要な粒度で届けることが目的です。内部業務で使う高精度なデータと、外部に見せる公開用データを分けることで、実務の便利さを保ちながら、公開時のリスクを抑えやすくなります。

特に現地調査や施工管理では、位置情報の正確さが業務品質に直結します。一方で、公開や共有の場面では、正確な位置情報をどこまで出すかを慎重に判断する必要があります。取得時は高精度に記録し、共有時は目的に応じて整理するという運用が重要です。

現場で取得した位置情報、写真、属性情報を活用しながら外部公開や関係者共有を行う場合は、取得時の便利さだけでなく、公開前に不要な項目を削除しやすい管理体制を整えることが大切です。元データ、作業用データ、公開用データを分け、確認担当者と公開手順を明確にしておくことで、GeoJSONを安全に活用しやすくなります。