Web地図にGeoJSONを読み込ませたのに、ポリゴンやライン、ポイントが表示されない。ファイルの中身は正しそうで、座標も入っている。それなのにブラウザの開発者向け画面を見ると、CORSに関するエラーが出ている。この状況は、地図を扱う実務でよく発生します。
CORSエラーは、GeoJSONそのものの記述ミスではなく、ブラウザが別の場所にあるファイルのレスポンスを、ページ上のスクリプトへ渡してよいかを確認する仕組みによって起きることが多いです。そのため、座標値や地物の属性を何度見直しても解決しないことがあります。
この記事では、GeoJSONがCORSエラーで地図に表示されない時に確認すべきポイントを、実務で使いやすい手順として5つに整理します。原因の切り分けから、同一オリジン配置、サーバー設定、中継APIやプロキシの利用、本番環境での確認まで、公開前後で迷わないように解説します。
GeoJSONのCORSエラーとは何が起きている状態か
GeoJSONは、地図上に表示する点、線、面などの地理情報を扱うためのJSONベースのデータ形式です。ブラウザ上の地図画面では、GeoJSONファイルを読み込み、その中の座標情報をもとに地物を描画します。行政区域、設備位置、現地調査ポイント、工事範囲、点検ルートなど、実務で扱う地図データの受け渡しにもよく使われます。
一方で、Web地図にGeoJSONを表示する時は、GeoJSONファイルの内容だけでなく、そのファイルをどこから取得しているかが重要です。たとえば、地図ページは自社のWebサイト上にあり、GeoJSONファイルだけが別のサーバーや別の保管場所にある場合、ブラウザは「このページが別の場所のデータを読み込んでよいのか」を確認します。この確認に失敗すると、GeoJSONのレスポンスが地図表示用の処理へ渡らず、地図上に何も表示されないことがあります。
この仕組みに関係するのがCORSです。CORSは、サーバーがHTTPヘッダーを通じて、どのオリジンからの読み取りを許可するかをブラウザへ示す仕組みです。オリジンとは、通信方式、ホスト名、ポート番号の組み合わせを指します。たとえば、同じドメイン名に見えても、通信方式がHTTPとHTTPSで異なれば別オリジンです。ホスト名が少し違う場合や、ポート番号が違う場合も別オリジンとして扱われます。
CORSエラーが起きると、ブラウザは取得先から返ってきた内容をページのスクリプトに利用させません。ここで重要なのは、サーバー上にファイルが存在しているかどうかと、ブラウザがそのファイルを地図表示用に使えるかどうかは別問題だという点です。ブラウザのアドレス欄にGeoJSONのURLを直接入力すると中身が見えるのに、地図ページから読み込むと失敗することがあります。これは、人が直接URLを開く動作と、あるページのスクリプトが別オリジンのデータを取得する動作では、ブラウザ側の扱いが異なるためです。
CORSエラーは、地図表示の実装では特に見落とされやすい原因です。GeoJSONの座標順序、座標参照系、プロパティ名、地物タイプなどを疑いたくなりますが、CORSでブロックされている場合、そもそもデータが地図ライブラリの処理まで届いていない可能性があります。つまり、描画処理以前の段階で止まっています。
実務での切り分けでは、「GeoJSONが正しいか」より先に「GeoJSONがブラウザに取得でき、スクリプトから利用できる状態になっているか」を確認することが大切です。取得に失敗していれば、どれだけ地図側のスタイルや表示範囲を調整しても解決しません。まずは通信経路を確認し、次に表示処理を確認するという順番が、無駄な調査を減らす近道です。
CORSエラーの代表的な症状としては、地図は表示されているのにGeoJSONレイヤーだけが出ない、開発者向け画面のコンソールにCORS関連の警告が出る、通信履歴ではGeoJSONへのリクエストが失敗扱いで表示される、レスポンスが地図側の処理に渡されない、ローカル環境では動いたのに本番環境で動かない、といったものがあります。
特に「ローカルでは動いたが公開後に動かない」というケースは要注意です。ローカル開発では一時的に同一オリジンに近い構成で動いていたり、簡易サーバーの挙動で問題が表面化していなかったりすることがあります。逆に、HTMLを file:// で直接開いている場合は、ブラウザの扱いによってCORSに似た問題が出ることもあります。本番公開後に、地図ページとGeoJSONの配置場所が分かれた瞬間にCORSエラーが発生することもあります。
GeoJSONのCORSエラーを解決するには、原因をやみくもに探すのではなく、取得元、配置場所、サーバー応答、ブラウザ制約、本番環境の差分を順番に見ていく必要があります。以下では、そのための5つの手順を実務向けに解説します。
解決手順1：ブラウザのエラー内容とGeoJSONの取得先を確認する
最初に行うべきことは、ブラウザの開発者向け画面で、実際にどのURLへGeoJSONを取りに行っているかを確認することです。地図に何も表示されない時、見た目だけでは原因を判断できません。GeoJSONファイルが見つからないのか、CORSで止まっているのか、ファイル形式が間違っているのか、座標が表示範囲外なのかを切り分ける必要があります。
開発者向け画面では、まずコンソールのエラーを確認します。CORSに関するエラーが出ている場合、エラーメッセージには、どのオリジンからどのオリジンへアクセスしようとしてブロックされたかが示されることがあります。ここで確認すべきなのは、地図ページのオリジンとGeoJSONファイルのオリジンが一致しているかどうかです。
たとえば、地図ページがHTTPSの本番サイトにあり、GeoJSONがHTTPの別サーバーに置かれている場合、CORSだけでなく混在コンテンツとして扱われる可能性もあります。地図ページがHTTPSで配信されているなら、GeoJSONもHTTPSで配信するのが基本です。また、同じ組織内のサーバーであっても、ホスト名が異なれば別オリジンです。サブドメインの違いも別オリジンとして扱われます。
次に、通信履歴を確認します。GeoJSONのリクエストが送信されているか、ステータスはどうなっているか、レスポンスヘッダーにCORS許可に関する情報が含まれているかを見ます。リクエスト自体が送られていない場合は、URLの指定ミスや読み込み処理の実行条件が原因かもしれません。リクエストは送られているが失敗している場合は、サーバー側の応答、リダイレクト、CORS設定、認証設定に原因がある可能性が高くなります。
GeoJSONのURL指定では、相対パスと絶対URLの違いにも注意が必要です。開発中に相対パスで動いていたものを本番環境へ移すと、基準となるページ階層が変わり、想定と違う場所へファイルを取りに行くことがあります。逆に、絶対URLで外部の保管先を指定している場合は、CORS設定が必要になることがあります。
ここで大切なのは、エラー文を「CORSっぽい」と見るだけで終わらせないことです。実際の取得先URL、リクエスト方式、レスポンスの状態、レスポンスヘッダーを確認します。GeoJSONは読み取りのための取得で使われることが多いですが、認証情報を含める設定や独自ヘッダーを付ける設定にしていると、ブラウザが事前確認の通信を行うことがあります。この事前確認への応答が正しくないと、実際のGeoJSON取得まで進みません。
また、GeoJSONファイルを直接ブラウザで開いた時に表示できるかも確認します。ただし、直接開けることはCORS解決の証明にはなりません。直接開けるのに地図ページから読み込めない場合こそ、CORSの可能性が高まります。直接アクセスで404や403などの応答になる場合は、CORS以前にファイルの配置、権限、URLの誤りを確認する必要があります。
実務では、同じGeoJSONを読み込むURLが複数箇所に分散していることもあります。環境変数、設定ファイル、画面側の固定値、サーバー側で生成されるURLなど、どこか一箇所だけ古い参照先が残っていると、想定外の場所へアクセスしてCORSエラーになることがあります。特に、開発環境、検証環境、本番環境でドメインが異なる場合は、設定値の取り違えが起きやすくなります。
手順1の目的は、問題を「地図が出ない」という漠然とした状態から、「このページがこのGeoJSON URLへアクセスし、この応答で止まっている」という具体的な状態に変えることです。ここまで特定できれば、次に取るべき対応はかなり明確になります。
解決手順2：GeoJSONを同一オリジンに配置して読み込み経路をそろえる
CORSエラーを避けるためにまず検討しやすい方法は、地図ページとGeoJSONを同一オリジンに配置することです。同一オリジンであれば、ブラウザのCORS制約に引っかからず、通常の静的ファイルとして読み込めることが多くなります。小規模な地図ページや、社内向けの簡易ビューア、検証用ページでは、この方法が扱いやすいです。
同一オリジンに配置するとは、通信方式、ホスト名、ポート番号をそろえるということです。たとえば、地図ページがあるWebサイトの配下にGeoJSONファイルを置き、相対パスで参照するようにします。これにより、別サーバーからの取得ではなく、同じWebサイト内のファイル取得として扱えます。
この方法の利点は、CORS設定の複雑さを減らせることです。サーバー側で許可するオリジンを細かく管理しなくてもよいため、実装や運用がシンプルになります。地図ページとGeoJSONの管理者が同じで、データ更新の頻度がそれほど高くない場合は、まず同一オリジン配置を検討するとよいです。
一方で、同一オリジン配置には注意点もあります。GeoJSONファイルの容量が大きい場合、Webサイト全体の配信負荷に影響することがあります。また、複数のシステムや複数の地図画面から同じGeoJSONを参照したい場合、各サイトにファイルをコピーすると更新漏れが起きやすくなります。現地調査データや設備台帳のように頻繁に更新されるデータでは、ファイルの配置場所を増やすほど管理が難しくなります。
それでも、原因切り分けのためには同一オリジン配置が有効です。まず一時的にGeoJSONを地図ページと同じ配下に置き、相対パスで読み込ませて表示されるかを確認します。これで表示されるなら、GeoJSONの中身や地図側の描画処理は大きく間違っていない可能性が高く、問題は元の取得先とのCORS設定に絞れます。表示されない場合は、CORS以外の原因も考える必要があります。
実務では、同一オリジン配置を恒久対応にするか、一時的な検証に使うかを分けて考えると整理しやすくなります。恒久対応に向いているのは、静的な公開データ、更新頻度が低い区域データ、特定の地図画面だけで使うGeoJSONなどです。一時的な検証に向いているのは、外部保管先や別システムから取得する予定のデータです。
相対パスで指定する場合は、ページの場所を基準にしたパスになる点にも注意します。地図ページが階層の深い場所にある場合、GeoJSONまでの相対パスが想定とずれることがあります。できれば、公開ディレクトリ内で地図ページとデータの配置ルールを決め、パスが読みやすい構成にすると保守しやすくなります。
また、GeoJSONを同一オリジンに置いても、ファイルへのアクセス権限が制限されていると取得できません。認証が必要なページ配下に置いた場合、地図表示時の取得リクエストにも同じ認証状態が必要になることがあります。社内システムでログイン後に地図を表示する場合は、GeoJSONの取得にも認証が通るかを確認してください。
同一オリジン配置は、技術的には地味な対応ですが、問題の切り分けにも本番運用にも使える堅実な方法です。CORS設定をすぐに変更できない場合や、別部門が管理するサーバーの設定変更に時間がかかる場合は、まず同一オリジンで読み込める状態を作ることで、表示確認を前に進められます。
解決手順3：サーバー側でCORS許可ヘッダーを設定する
GeoJSONを別オリジンから読み込む必要がある場合は、GeoJSONを配信するサーバー側でCORS許可ヘッダーを設定します。CORSは、読み込む側の地図ページだけで解決できる問題ではありません。ブラウザは、取得先サーバーが「このオリジンからの読み取りを許可している」と応答した場合に、レスポンスをスクリプトへ渡します。
代表的に確認するのは、アクセスを許可するオリジンを示す Access-Control-Allow-Origin です。ここに地図ページのオリジンが含まれていない場合、ブラウザはGeoJSONの利用をブロックします。公開データで、認証情報を含まない読み取りだけを広く許可する場合はワイルドカードが使われることもあります。一方で、業務データや限定公開データでは、許可するオリジンを明示的に絞るのが基本です。
重要なのは、CORS許可ヘッダーはGeoJSONファイルを置いているサーバーから返す必要があるという点です。地図ページ側のHTMLやスクリプトに何かを書き足しても、取得先サーバーが許可していなければ解決しません。特に、別部門が管理するファイルサーバー、外部の配信基盤、別システムのAPIなどからGeoJSONを取得している場合は、管理者にCORS設定を依頼する必要があります。
CORS設定では、許可するオリジンのほかに、許可するメソッドやヘッダーも確認します。通常のGeoJSON取得であれば読み取り用のGETだけで足りることが多いですが、独自ヘッダーを付けて取得している場合や、認証情報を含める場合は追加の設定が必要になります。事前確認の通信が発生する構成では、その事前確認に対しても正しく応答する必要があります。
認証情報を含める場合は、特に注意が必要です。Cookieや認証ヘッダーを含むクロスオリジン通信では、サーバー側で認証情報付きの通信を許可する設定が必要になります。また、認証情報を含む通信では、Access-Control-Allow-Origin に単純なワイルドカードを指定しても期待通りに動きません。許可するオリジンを明示し、必要なヘッダーを正しく返す設計にします。
ここでよくある失敗は、ファイル自体の取得には成功しているように見えるのに、ブラウザではCORSエラーになるというものです。サーバーのアクセスログには200番台の応答が残っていても、CORS許可ヘッダーが不足していれば、ブラウザはレスポンスを地図側の処理に渡しません。サーバーログだけで成功と判断せず、ブラウザの通信履歴でレスポンスヘッダーまで確認することが大切です。
また、CORS許可を広げすぎると、意図しないサイトから業務データを読み取られる可能性があります。GeoJSONには、設備の位置、管理区域、点検対象、現地調査結果など、公開範囲に注意すべき情報が含まれることがあります。公開前に、そのGeoJSONが本当に誰に見えてよいデータなのかを確認してください。地図に表示するための技術設定と、データ公開範囲の判断は別の問題です。
CORS設定を行う時は、開発環境、検証環境、本番環境で許可するオリジンを分けて管理すると安全です。開発中だけ広く許可し、本番では正式なオリジンに限定する運用が考えられます。ただし、開発時の緩い設定がそのまま本番へ残らないように注意が必要です。設定ファイルや環境変数で明確に分離し、公開前の確認項目に含めておくと安心です。
複数の許可オリジンに応じてサーバーが Access-Control-Allow-Origin の値を動的に返す場合は、キャッシュの影響にも注意します。配信中継やブラウザが別のオリジン向けの応答を再利用しないよう、必要に応じて Vary: Origin を返す設計にします。
GeoJSONを静的ファイルとして配信している場合、サーバーの静的ファイル配信設定でヘッダーを追加します。APIとして返している場合は、APIのレスポンス処理でヘッダーを付与します。どちらの場合も、実際にブラウザが受け取る最終レスポンスにヘッダーが付いているかが重要です。途中に転送、認証、キャッシュ、配信中継が入っていると、設定したはずのヘッダーが最終的に消えていることがあります。
CORS許可ヘッダーの設定後は、ブラウザのキャッシュを避けて再確認します。古い応答が残っていると、設定変更が反映されていないように見えることがあります。開発者向け画面でキャッシュを無効にして再読み込みする、URLに検証用のクエリを付けるなど、最新の応答を見て確認するとよいです。
サーバー側でCORSを正しく設定できれば、地図ページとGeoJSONを分離して管理できます。データ配信基盤を独立させたい場合、複数の地図画面から同じGeoJSONを参照したい場合、更新頻度の高いデータを一元管理したい場合には、この方法が有効です。
解決手順4：中継APIやプロキシで安全に読み込みを制御する
GeoJSONの配信元サーバーを直接変更できない場合や、公開範囲を細かく制御したい場合は、中継APIやプロキシを使う方法があります。これは、地図ページが直接外部のGeoJSONへアクセスするのではなく、自社側で用意した中継先へアクセスし、その中継先がGeoJSONを取得してブラウザへ返す構成です。
この方法の利点は、ブラウザから見た取得先を自社管理の同一オリジンまたは許可済みオリジンにできることです。外部のデータ保管先がCORSに対応していなくても、自社側の中継処理で必要なレスポンスヘッダーを付与できます。また、認証、ログ記録、データ加工、キャッシュ制御、ファイルサイズ制限などを中継側でまとめて扱えるため、業務システムでは現実的な選択肢になります。
ただし、中継APIやプロキシは便利な反面、設計を誤るとセキュリティ上の問題になります。任意のURLを指定して中継できる仕組みにすると、意図しない外部サイトや内部ネットワークへのアクセス経路として悪用される可能性があります。中継対象は、許可したデータ元や許可したパスに限定するべきです。ユーザーが自由にURLを入力できる構成にする場合でも、厳密な検証と制限が必要です。
GeoJSONの中継では、取得したデータをそのまま返すだけでなく、必要に応じて検証を行うと安全性が上がります。レスポンスがGeoJSONとして妥当か、想定以上の大容量ではないか、不要な情報が含まれていないか、座標や属性の範囲が想定内かを確認できます。特に、現場からアップロードされたデータや、外部システムから連携されたデータを地図に表示する場合は、表示前の検証が重要です。
中継APIを使う場合、ブラウザ側の地図画面は中継APIのURLを読み込みます。中継APIは必要なGeoJSONを取得し、適切なContent-Typeと、必要に応じたCORS許可ヘッダーを付けて返します。地図画面と中継APIが同一オリジンならCORSの問題は起きにくくなります。別オリジンの場合でも、自社で管理しているAPIであればCORS設定を制御しやすくなります。
また、GeoJSONのサイズが大きい場合は、中継側で圧縮や簡略化、範囲指定を行うことも検討できます。地図画面に一度に大量の地物を読み込ませると、CORSが解決しても表示が重くなったり、ブラウザの処理が固まったりすることがあります。中継APIで必要な範囲だけ返す、属性を必要最小限にする、ズーム段階に応じてデータを分けるなどの工夫が有効です。
中継APIは、認証が必要なGeoJSONにも向いています。ブラウザから直接データ元へ認証情報を渡す構成では、認証情報の扱いやCORS設定が複雑になることがあります。中継APIでログイン状態を確認し、権限のあるユーザーにだけGeoJSONを返す構成にすれば、地図表示とアクセス制御を整理しやすくなります。
一方で、中継APIを導入すると、システム構成は増えます。サーバー側の処理、監視、障害対応、ログ管理が必要になります。静的な公開GeoJSONを少数のページで表示するだけなら、同一オリジン配置や配信元のCORS設定で十分なこともあります。中継APIは、配信元を変更できない、データ公開範囲を制御したい、認証や加工が必要、複数システムから安定して利用したい、といった要件がある場合に検討するとよいです。
実務では、地図表示の問題を単なるCORS対応として片付けるのではなく、データの流れ全体として設計することが重要です。どのデータを、誰が、どの画面で、どの範囲まで見られるのか。更新頻度はどれくらいか。大容量化した時にどうするのか。これらを整理すると、同一オリジン配置で足りるのか、CORS設定で足りるのか、中継APIが必要なのかを判断しやすくなります。
解決手順5：本番環境でMIMEタイプ、HTTPS、キャッシュを確認する
CORS設定を見直してもGeoJSONが表示されない場合、本番環境特有の設定差分を確認します。特に、MIMEタイプ、HTTPS、キャッシュは、GeoJSON表示のトラブルでよく関係します。CORSエラーとして見えていた問題が、実際には複数の要因と重なっていることもあります。
まず確認したいのは、GeoJSONのContent-Typeです。GeoJSONの正式なメディアタイプは application/geo+json です。環境によっては application/json として返しても地図ライブラリ側で扱えることがありますが、GeoJSONとして配信するなら application/geo+json を設定しておくと意図が明確になります。逆に、HTMLや不明なファイルとして返っている場合は、地図側の読み込み処理が想定外の挙動になることがあります。
次に、HTTPSの統一を確認します。本番の地図ページがHTTPSで提供されている場合、GeoJSONもHTTPSで取得するのが基本です。HTTPSのページからHTTPのデータを取得しようとすると、ブラウザが安全でない混在コンテンツとしてブロックすることがあります。この場合、CORS設定が正しくても、別の理由で読み込みが止まります。エラーメッセージ上は複数の警告が出ることがあるため、CORSだけでなく混在コンテンツの警告も確認してください。
キャッシュも見落とされやすいポイントです。CORS設定やGeoJSONの中身を修正したのに表示が変わらない場合、ブラウザ、配信中継、サーバー側のキャッシュが古いファイルを返している可能性があります。GeoJSONの更新が頻繁な運用では、キャッシュの有効期間を適切に設計する必要があります。更新直後にすぐ地図へ反映したいデータと、頻繁には変わらない背景的なデータでは、キャッシュ方針を分けた方がよいです。
本番環境では、開発環境と異なる配信経路が入ることがあります。たとえば、公開用の配信中継、負荷分散、認証ゲート、社内外のネットワーク境界などです。これらの途中経路で、レスポンスヘッダーが追加、変更、削除されることがあります。開発環境では正しく返っていたCORSヘッダーが、本番環境では最終レスポンスに含まれていないというケースもあります。
また、リダイレクトにも注意が必要です。GeoJSONのURLへアクセスした時、別のURLへ転送されている場合、最終的な転送先のレスポンスにCORS許可ヘッダーが必要です。最初のURLだけ設定していても、転送先でヘッダーが不足していればブラウザはブロックします。HTTPからHTTPSへの転送、古いパスから新しいパスへの転送、認証画面への転送などが発生していないかを確認します。
認証が絡む場合は、さらに慎重な確認が必要です。ログイン済みの画面からGeoJSONを取得する構成では、ブラウザが認証情報を含めてリクエストするか、サーバーがそれを許可するか、CORS設定が認証情報付きの通信に対応しているかを確認します。認証情報付きの通信では、単純に広く許可するだけでは期待通りに動かない場合があります。セキュリティ上も、許可するオリジンを明確に絞る必要があります。
ファイル名や拡張子の扱いも本番環境で差が出ることがあります。サーバーによっては、未知の拡張子のファイルを配信しない設定になっていたり、ダウンロード扱いにしたりすることがあります。GeoJSONファイルを静的に置く場合は、その拡張子が配信対象になっているかを確認してください。ファイルの権限や公開ディレクトリの設定も確認対象です。
本番環境での確認では、地図画面からの通信と、GeoJSON URLへの直接アクセスの両方を見ると効果的です。直接アクセスで正しい内容が返るか、地図画面からのアクセスで同じ内容が返るか、ヘッダーに差がないかを比較します。直接アクセスでは問題がなくても、地図画面からのアクセスではOriginヘッダーが付くため、サーバー側の応答が変わる場合があります。
さらに、GeoJSONの更新運用も確認しておくべきです。ファイルを差し替えた時、古いファイル名のまま上書きするのか、バージョン付きのファイル名にするのか、キャッシュをどう更新するのかを決めておくと、公開後の混乱を減らせます。現場データを日次や随時で更新する場合、古いデータが表示され続けることは業務判断にも影響します。
CORSエラーの解消はゴールではなく、地図上に正しい最新データが安定して表示される状態を作ることが目的です。本番環境では、CORSヘッダーだけでなく、配信形式、通信方式、キャッシュ、認証、リダイレクトまで含めて確認することが大切です。
CORS以外でGeoJSONが地図に出ない原因も確認する
CORSエラーが出ていた場合でも、設定を直した後にまだGeoJSONが表示されないことがあります。その場合は、CORS以外の原因も確認します。実務では、複数の不具合が同時に存在することが珍しくありません。CORSを直して初めて、次の問題が見えることもあります。
まず確認したいのは、GeoJSONの構文です。GeoJSONはJSON形式をもとにしているため、括弧、カンマ、引用符などの記述ミスがあると読み込めません。見た目には少しの違いでも、構文として不正であれば地図側の処理は失敗します。地物の集合を表す構造、各地物のジオメトリ、属性情報の入れ方が正しいかを確認します。
次に、座標の順序を確認します。RFC 7946に沿ったGeoJSONでは、座標は経度、緯度の順で記述します。緯度、経度の順にしてしまうと、意図しない場所に表示されたり、地図の表示範囲外に飛んでしまったりします。日本国内のデータであれば、経度はおおむね100台、緯度はおおむね20台から40台の範囲に入ることが多いため、値の並びを見れば取り違えに気づける場合があります。
座標参照系の前提も確認します。現在のGeoJSON仕様では、基本的にWGS 84の経度・緯度を使います。別の座標系で管理していたデータをそのままGeoJSONとして出力すると、地図上で大きくずれることがあります。既存のGISデータから変換した場合は、変換時の座標系設定も確認してください。
地図の表示範囲も重要です。GeoJSONは正しく読み込まれていても、現在の地図表示範囲の外にあると、画面上には何も見えません。読み込み後に地物の範囲へ地図を移動する処理があるか、初期表示位置がデータの範囲に合っているかを確認します。特に、全国データ、広域データ、現場単位の小さなデータを切り替える画面では、初期表示範囲の設定がずれていることがあります。
ジオメトリタイプの対応も確認します。GeoJSONには点、線、面、複数地物などの表現があります。地図側の処理が特定のタイプだけを想定している場合、別のタイプの地物が入っていると表示されないことがあります。たとえば、点だけを表示する処理に面データを渡している、単一地物を想定した処理に地物集合を渡している、といったケースです。
ポリゴンのリングの扱いにも注意が必要です。面データでは、外周や穴を座標配列で表します。座標配列の構造が誤っていると、表示されなかったり、形状が崩れたりします。また、非常に細かい頂点を大量に含むポリゴンでは、読み込みに成功しても描画が重くなり、表示まで時間がかかることがあります。
スタイル設定が原因で見えないこともあります。GeoJSONは読み込めているのに、線色や塗り色が背景と同化している、透明度が高すぎる、線幅が細すぎる、表示レイヤーの順序が下になっている、ズーム条件で非表示になっている、といった状況です。この場合、通信上は成功しているため、CORSエラーは出ません。読み込み成功後に、地図側で何件の地物を受け取っているかを確認すると切り分けやすくなります。
ファイルサイズも実務上の大きな要因です。大容量のGeoJSONは、ブラウザでの読み込みや描画に時間がかかります。特に、詳細な行政界、細かな調査軌跡、大量の点群的な位置データをそのままGeoJSONで読み込ませると、表示性能が落ちることがあります。CORSを解決しても、表示が遅い、固まる、途中で処理が止まるといった問題が残る場合があります。
データの文字コードも確認対象です。属性に日本語を含むGeoJSONでは、文字化けや読み込みエラーが発生することがあります。通常はUTF-8で統一し、サーバー側のレスポンスでも適切に扱われるようにします。属性名に空白や特殊な記号を多用している場合、地図側のスタイル分岐やポップアップ表示で想定外の挙動になることもあります。
また、GeoJSONの内容が動的に生成される場合は、サーバー側のエラーがGeoJSONとして返っていないかを確認してください。APIのつもりでアクセスしたら、実際にはエラーメッセージやログイン画面のHTMLが返っていることがあります。ブラウザの通信履歴でレスポンス本文を確認し、本当にGeoJSONが返っているかを見ることが重要です。
CORS以外の原因を確認する際も、順番が大切です。まず通信で取得できているかを確認し、次にレスポンスがGeoJSONとして正しいかを確認し、その後に地図側の表示範囲やスタイルを確認します。この順番を守ると、原因が複数あっても一つずつ潰していけます。
まとめ：GeoJSONの表示不具合は取得経路から順に切り分ける
GeoJSONがCORSエラーで地図に表示されない時は、地図の描画設定やGeoJSONの座標だけを見ても解決しないことがあります。CORSは、ブラウザが別オリジンのデータを安全に扱うための仕組みであり、問題はデータの中身ではなく、データを取得する経路やサーバー応答にあることが多いです。
最初に行うべきことは、ブラウザの開発者向け画面で、どのGeoJSON URLへアクセスしているか、どのようなエラーが出ているか、レスポンスヘッダーはどうなっているかを確認することです。ここで取得先とエラー内容を具体化できれば、次の対応を選びやすくなります。
まず検討しやすい解決策は、GeoJSONを地図ページと同一オリジンに配置することです。これによりCORSの制約を避けられ、原因切り分けにも役立ちます。複数の画面やシステムから同じGeoJSONを参照する必要がある場合は、配信元サーバーでCORS許可ヘッダーを適切に設定します。サーバーを直接変更できない場合や、認証、加工、公開範囲の制御が必要な場合は、中継APIやプロキシを使う構成が有効です。
本番環境では、CORS設定だけでなく、MIMEタイプ、HTTPS、キャッシュ、リダイレクト、認証、配信中継の有無も確認してください。開発環境で動いたものが本番環境で動かない場合、これらの差分が原因になっていることがあります。
また、CORSを解決した後も表示されない場合は、GeoJSONの構文、座標順序、座標参照系、地図の表示範囲、ジオメトリタイプ、スタイル設定、ファイルサイズなどを確認します。地図に出ない原因は一つとは限りません。通信、データ形式、描画の順に切り分けることで、無駄な修正を減らせます。
GeoJSONは、現地調査、設備管理、区域確認、工事計画、点検記録など、実務の地図活用で便利な形式です。しかし、Web地図で安定して使うには、ファイルを作るだけでなく、配信方法とブラウザの制約まで考える必要があります。CORSエラーはその代表的な壁ですが、仕組みを理解して手順通りに確認すれば、原因の特定と解決は十分に可能です。
現場で取得した位置情報をGeoJSONとして扱い、Web地図や業務システムへつなげる場面では、データの精度、取得方法、更新頻度、公開範囲、運用フローも重要になります。公開前には、取得経路、CORS設定、MIMEタイプ、HTTPS、キャッシュ、GeoJSONの構文と座標順序をまとめて確認し、地図上に正しいデータが安定して表示される状態を作りましょう。