点群OBJアップロードで発生するCORSエラーとは
点群データをOBJ形式でアップロードしようとしたとき、ファイルを選択できているのに送信が始まらない、進捗表示が途中で止まる、アップロード後のプレビューだけが表示されないといった問題が起こることがあります。ブラウザの開発者向け画面を確認すると、CORSやCross-Originを含むエラーが記録されている場合があります。
CORSは、ブラウザ上のページから異なるオリジンへ通信するときに、通信先がそのアクセスを許可しているかをブラウザが確認する仕組みです。オリジンは、通信方式、ホスト名、ポート番号の組み合わせで判定されます。画面とアップロード先のホスト名が異なる場合だけでなく、同じホスト名でもHTTPとHTTPSが異なる場合や、ポート番号が異なる場合は別オリジンとして扱われます。
たとえば、点群OBJを操作する画面と、ファイルを受け取るAPIや保存先が異なる環境に配置されている場合、ブラウザは別オリジンへの通信として扱います。この通信を成立させるには、通信先がレスポンスヘッダーを通じて、画面側のオリジン、通信方法、必要なリクエストヘッダーなどを許可する必要があります。
CORSはOBJファイルの座標、面、法線、材質、テクスチャなどを検査する仕組みではありません。そのため、CORSエラーが出たという理由だけで、OBJファイル自体が壊れていると判断するのは早計です。多くの場合は、アップロード画面、API、保存先、配信用URLの間で通信条件が一致していないことが原因です。
点群OBJのアップロードでは、一般的な文書ファイルより通信経路が複雑になることがあります。最初にAPIからアップロード先URLを取得し、次にブラウザから保存領域へOBJファイルを直接送信し、その後にアップロード完了をAPIへ通知する構成が考えられます。さらに、プレビュー時には保存されたOBJ、材質定義ファイル、テクスチャ画像を別の配信先から取得する場合があります。
このような構成では、APIへの接続が成功していても、保存先への直接送信でCORSエラーが発生する可能性があります。OBJ本体のアップロードが完了していても、プレビュー用の取得通信だけが拒否されることもあります。したがって、点群OBJのアップロードに失敗したと一括りにせず、どの段階の通信が止まったのかを確認することが重要です。
CORSエラーを解消する際は、単に許可範囲を広げればよいわけではありません。すべてのオリジンや通信方法を無条件で許可すると、意図しない外部ページから通信を試みられる範囲が広がります。実際に必要な通信元、通信方法、ヘッダー、認証方式を整理したうえで、必要な範囲だけを許可することが基本です。
CORSエラーとOBJファイル破損を見分ける考え方
点群OBJアップロードでエラーが発生すると、担当者はOBJファイルの破損や容量超過を疑うことがあります。しかし、CORSエラーとファイル内容の問題では、失敗する段階が異なる場合があります。原因を早く特定するには、アップロード処理を複数の段階に分けて考える必要があります。
ファイル選択の直後に処理が止まり、実際の送信が始まっていない場合は、アップロード先URLの取得、認証、プリフライトリクエストなどで失敗している可能性があります。この段階ではOBJ本体がサーバーへ送られていないことがあるため、座標や面構成を解析した結果として発生したエラーとは考えにくい状況です。
進捗表示が始まり、途中まで送信された後に失敗する場合は、CORSだけでなく、通信切断、署名付きURLの有効期限、保存先の容量制限、分割アップロードの不整合なども確認します。エラー応答に必要なCORSヘッダーが付いていないと、本来は容量超過や権限不足であっても、ブラウザ上ではCORSに関連する失敗として見えることがあります。
アップロード完了の表示後にプレビューだけが失敗する場合は、OBJファイルの取得処理や関連ファイルの参照処理を確認します。OBJ本体は保存されていても、材質定義ファイルやテクスチャ画像へのアクセスが許可されていないと、見た目が正しく表示されないことがあります。
OBJの解析エラーでは、頂点行や面定義の形式、参照番号、文字コード、数値表現などが問題になることがあります。一方、CORSエラーでは、リクエストURL、通信方法、送信元オリジン、リクエストヘッダー、レスポンスヘッダーなどが主な確認対象です。どちらに分類されるかを判断するには、ブラウザの通信記録とサーバー側の処理記録を組み合わせます。
小容量の確認用OBJを使用する方法も有効です。小さいOBJでも同じ通信段階で失敗する場合は、ファイル容量よりもCORS、認証、署名条件などが関係している可能性が高くなります。小さいOBJは成功し、大きいOBJだけが失敗する場合は、通信時間、ファイル上限、タイムアウト、分割送信の条件も確認します。
ただし、小さいファイルで成功したからといって、すべてのCORS設定が正しいとは限りません。ファイル容量によってアップロード方式が切り替わるシステムでは、大きいファイルだけ別の通信方法や追加ヘッダーを使用することがあります。成功した通信と失敗した通信を比較し、URL、通信方法、ヘッダー、認証情報の有無に差がないかを確認します。
原因1：アップロード元のオリジンが許可されていない
CORSエラーの代表的な原因は、アップロード先の許可設定に、実際の画面のオリジンが登録されていないことです。点群OBJを操作する画面と、ファイルを保存するサーバーや保存領域が異なる場合、通信先は画面側からのアクセスを許可する必要があります。
本番環境のオリジンだけが登録され、検証環境や開発環境のオリジンが登録されていないケースは珍しくありません。反対に、検証環境では正常に動作していたものの、本番環境のホスト名が許可一覧に追加されておらず、公開後にアップロードできなくなることもあります。
オリジンはページ全体のURLではなく、通信方式、ホスト名、ポート番号の組み合わせとして扱われます。ページのパスや検索文字列まで含めて登録しても、想定どおり判定されないことがあります。また、HTTPSで開いている画面からHTTPのアップロード先へ接続する構成では、CORSとは別に混在コンテンツとしてブラウザに遮断される可能性があります。
解決策は、ブラウザが送信するOriginヘッダーの値を確認し、実際に必要なオリジンをアップロード先の許可一覧へ登録することです。本番、検証、開発など複数の環境がある場合は、環境ごとに許可対象を整理します。一時的な検証用オリジンを追加した場合は、検証終了後に削除する運用も必要です。
エラーを早く消すために、すべてのオリジンを示すワイルドカードを設定する方法は慎重に扱います。公開情報を認証なしで読み取る用途では選択肢になる場合がありますが、Cookieなどの認証情報を伴う通信では、Access-Control-Allow-Originにワイルドカードを返す構成は利用できません。案件情報や位置情報を含むデータを扱う場合は、必要なオリジンを具体的に限定する方が安全です。
正常な応答だけでなく、エラー応答にも必要なCORSヘッダーが付与されているか確認します。認証切れ、権限不足、容量超過などが発生したとき、通常時とは別のサーバーや中継処理から応答が返されることがあります。その応答に許可ヘッダーがなければ、本来の原因を画面側で読み取れず、CORSエラーとして扱われる場合があります。
原因2：プリフライトリクエストへの応答が不足している
ブラウザは、別オリジンへ特定の通信方法やヘッダーを使って送信する前に、OPTIONSメソッドでプリフライトリクエストを送ることがあります。点群OBJをPUTで直接送信する場合や、許可対象に明示が必要なヘッダーを付ける場合は、実際のファイル送信より先にプリフライトが発生することがあります。
プリフライトへの応答が不足していると、ブラウザはOBJ本体の送信を開始しません。ファイル選択後すぐにエラーが出る、進捗率がゼロのまま止まる、サーバー側にOBJ本体の受信記録が残らないといった状態になりやすくなります。
通信先は、必要に応じてAccess-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headersなどを返します。ブラウザが送るAccess-Control-Request-MethodやAccess-Control-Request-Headersの内容と、通信先の許可内容が一致していない場合、実際のアップロードは実行されません。
たとえば、画面側がPUTで送信しようとしているのに、通信先がGETとPOSTしか許可していない場合は失敗します。独自ヘッダーや認証ヘッダーを追加したのに、そのヘッダーが許可一覧へ含まれていない場合も同様です。
解決策は、ブラウザが実際に送信しようとしている条件と、通信先が許可している条件を一致させることです。ただし、すべての通信方法やヘッダーを無条件で許可するのではなく、アップロード処理で使用するものだけを整理します。
画面側で不要な独自ヘッダーを追加している場合は、サーバー側の許可範囲を広げる前に削除できないか検討します。ヘッダーが増えるほどプリフライト条件が複雑になり、署名付きURLの署名条件とも不一致が起きやすくなるためです。
中継サーバーや保存先がOPTIONSを受け付けず、GETやPOSTだけを処理する設定になっている場合もあります。アプリケーションサーバーでは対応済みでも、その手前の中継処理がOPTIONSを拒否していれば、ブラウザからはアップロードできません。通信経路上のどの層が応答しているかを確認します。
機能追加後に突然CORSエラーが発生した場合は、新しく追加された通信方法やヘッダーを確認します。アップロード進捗の取得、分割送信、再開処理、ファイル整合性確認などを実装した際に、それまで発生していなかったプリフライトが必要になることがあります。
プリフライト応答を一定時間キャッシュする設定もあります。開発中に設定を変更した直後は、古い結果がブラウザ側に残っている可能性があるため、修正後の確認では新しいブラウザセッションを使うなど、現在の応答を確認できる状態で再試行します。
原因3：認証情報と許可オリジンの設定が競合している
ログイン状態を利用して点群OBJをアップロードする場合、Cookieなどの認証情報を別オリジンへ送信することがあります。この構成では、通常のCORS設定に加えて、認証情報を伴う通信を許可する設定が必要です。
よくある問題は、認証情報を送信する設定と、許可オリジンのワイルドカード指定が競合していることです。認証情報を伴う通信では、通信先がAccess-Control-Allow-Originに単純なワイルドカードを返しても、ブラウザはそのレスポンスを利用できません。
画面側で認証情報を含める設定を有効にしている場合は、サーバー側で送信元オリジンを具体的に返し、Access-Control-Allow-Credentialsも適切に設定する必要があります。画面側とサーバー側の片方だけを変更しても、双方の条件がそろわなければCORSエラーは解消しません。
点群OBJのアップロードでは、すべての通信で同じ認証方式を使用するとは限りません。最初に認証付きAPIへ接続して一時的なアップロードURLを取得し、そのURLを使って保存先へ直接OBJを送信する構成があります。この場合、保存先への直接送信ではCookieが不要なことがあります。
画面側がすべての別オリジン通信に認証情報を付ける設計になっていると、本来は不要な保存先への送信まで厳しいCORS条件の対象になります。通信ごとに認証方式を分け、アップロード先URLを取得するAPIではログイン情報を使い、発行されたURLへの送信ではそのURLに設定された一時権限を使うなど、役割を明確にします。
ただし、認証情報を外せば必ず解決するわけではありません。システムによっては保存先への送信にも認証が必要です。実際の設計を確認せずに画面側だけを変更すると、CORSエラーが消えても権限不足でアップロードできない可能性があります。
認証期限が切れたときの応答も確認が必要です。ログイン直後は成功するのに、一定時間後だけ失敗する場合は、認証情報の期限や更新処理が関係している可能性があります。未認証として返された応答に必要なCORSヘッダーがなければ、本来は認証切れであっても、画面にはCORSエラーとして表示されることがあります。
調査時には、リクエストにCookieや認証ヘッダーが含まれているか、サーバーがどの状態コードを返しているか、エラー応答にも許可ヘッダーが付いているかを確認します。ログインし直すと一時的に直る場合は、認証更新処理やセッション期限を重点的に調べます。
Cookieを使用する構成では、CORS以外のブラウザ制約も関係します。CookieのSameSite属性やSecure属性、画面とAPIの関係によっては、画面側が認証情報を送る設定を有効にしてもCookieが送信されない場合があります。CORS設定だけでなく、実際のリクエストに必要なCookieが含まれているかを確認します。
CORSは利用者の本人確認や案件ごとの権限管理を代替するものではありません。許可したオリジンからの通信であっても、アップロードを実行する利用者が対象案件へ登録する権限を持っているか、サーバー側で確認します。CORS、認証、認可は別々の仕組みとして設計することが重要です。
原因4：署名付きURLやリダイレクト先の条件が一致していない
大容量の点群OBJを扱うシステムでは、アプリケーションサーバーを経由せず、ブラウザからファイル保存先へ直接アップロードする構成があります。このとき、一時的に利用できる署名付きURLを発行する方法が使われることがあります。
署名付きURLでは、URLの有効期限だけでなく、通信方法、ホスト名、パス、検索文字列、リクエストヘッダーなどが署名条件に含まれる場合があります。URL発行時に想定した条件と、ブラウザが実際に送信した条件が異なると、保存先はアップロードを拒否します。
この拒否応答に必要なCORSヘッダーが含まれていない場合、ブラウザ上では署名不一致や期限切れの詳細を読み取れず、CORSエラーとして見えることがあります。そのため、許可オリジンを何度変更しても直らない状態になりやすい原因です。
代表的な確認項目は、発行時に指定したContent-Typeと実際の送信値、PUTとPOSTの違い、署名対象に含めたヘッダーの有無、URLの有効期限です。画面側が自動で追加するヘッダーや、送信ライブラリが付与する値によって署名条件が変わる場合もあります。
大容量OBJでは、URLの有効期限も重要です。ファイル選択後に座標範囲や関連ファイルの確認を行ってから送信する場合、アップロード開始前または送信中に期限が切れることがあります。画面表示時にURLを発行し、利用者が長時間操作した後で送信を開始する設計では、期限切れが起こりやすくなります。
Content-Typeを署名条件へ含める構成では、URL発行時と実送信時で値をそろえます。未指定として署名したのに画面側が値を追加した場合や、特定の値で署名したのに別の値で送信した場合は、保存先で拒否されることがあります。
期限は長くすればよいわけではありません。長すぎる期限は、URLが意図せず共有された場合の利用可能時間を広げます。一方、短すぎる期限では、大容量ファイルの準備や通信の再試行が難しくなります。想定するOBJ容量、通信環境、前処理時間を踏まえ、必要な範囲で設定します。
リダイレクトも確認が必要です。アップロード先URLへ接続した後、別のホスト名や通信方式へ転送されると、最終的な接続先にもCORS設定が必要になります。また、転送によってホスト名やパスが変わると、署名条件と一致しなくなる場合があります。
HTTPからHTTPSへの転送、旧ホスト名から新ホスト名への転送、保存領域ごとの転送などがある場合は、最初に指定したURLだけでなく、実際の到達先を確認します。可能であれば、最初から最終到達先を示すURLを発行し、アップロード途中の転送を避けます。
署名不一致、期限切れ、容量制限、保存権限不足など、本来はCORS以外の問題であっても、エラー応答に必要なCORSヘッダーが付いていなければ、ブラウザから詳細を読み取れません。保存先の処理記録とURL発行側の記録を照合し、失敗理由を直接確認することが重要です。
原因5：OBJ関連ファイルごとにCORS設定が異なっている
OBJ形式では、形状を記録するOBJ本体だけでなく、材質定義ファイルやテクスチャ画像を組み合わせる場合があります。点群やメッシュの用途によってはOBJ本体だけで運用できますが、色や模様を表示する場合は関連ファイルが必要になることがあります。
OBJ本体のアップロードが成功していても、材質定義ファイルやテクスチャ画像の送信先だけCORS設定が不足していると、処理全体が失敗したように見えることがあります。画面にOBJアップロードエラーと表示されていても、実際に拒否されたのは別の関連ファイルだったというケースです。
アップロード直後のプレビューでは、保存されたOBJを取得し、内部の参照情報を読み取って追加ファイルへアクセスすることがあります。OBJ本体を取得できても、材質定義ファイルを取得できなければ表示が不完全になります。材質定義ファイルを取得できても、その中で参照されているテクスチャ画像が別オリジンに置かれていれば、画像の取得時にCORSエラーが起こる可能性があります。
アップロード時にはPUTやPOST、プレビュー時にはGETが使われることがあります。ファイルの存在やサイズを確認するためにHEADを使う実装もあります。送信時に必要な方法だけ許可されていても、取得時のGETや確認時のHEADが許可されていなければ、アップロード後の処理で失敗します。
OBJ本体、材質定義ファイル、テクスチャ画像を異なる保存領域へ配置している場合は、それぞれのCORS設定を確認します。OBJ本体用の保存先だけを修正しても、関連ファイルの保存先が別であれば問題は残ります。
アップロード用URLとプレビュー配信用URLが異なる構成もあります。アップロード時には正常でも、表示用の配信先に許可オリジンが登録されていなければ、アップロード後の確認画面でエラーが発生します。送信時と取得時の両方について設定を確認する必要があります。
ファイル名や参照パスの不一致が、CORSエラーと同時に起きる場合もあります。OBJ内の材質定義参照や、材質定義ファイル内のテクスチャ参照が実際の配置先と一致していなければ、取得先からエラーが返されます。そのエラー応答に必要なCORSヘッダーがないと、画面上ではCORSの問題に見える可能性があります。
解決策として、OBJ関連ファイルを一つのアップロード単位として管理します。OBJ本体と関連ファイルに共通の管理番号を付け、同じ案件や処理単位へひも付けます。どのファイルがどの保存先へ送られ、どのオリジンから取得されるかを明確にします。
アップロード完了の判定をOBJ本体の送信成功だけで行わないことも重要です。必要な関連ファイルがすべて保存され、参照関係が解決できる状態になってから完了として扱います。一部だけ失敗した場合は、失敗したファイル名と処理段階を画面へ表示すると、再送や原因調査を行いやすくなります。
利用目的によって材質やテクスチャが不要な場合は、OBJ変換時に不要な参照を整理する方法もあります。関連ファイルが減れば通信経路が単純になり、CORS設定の対象も減ります。ただし、色や模様が必要な業務では表示結果が変わるため、用途を確認して判断します。
点群OBJアップロードのエラーを切り分ける手順
点群OBJのCORSエラーを効率よく調べるには、設定を手当たり次第に変更するのではなく、失敗した通信を特定します。最初に、エラーが発生したタイミングを確認します。
ファイルを選択した直後に止まる場合は、アップロード先URLの取得、認証、プリフライトなどが疑われます。進捗表示が途中まで進んで止まる場合は、通信切断、期限切れ、容量上限、分割送信の処理も確認します。アップロード完了後にプレビューだけ失敗する場合は、保存されたOBJや関連ファイルを取得する通信を調べます。
次に、ブラウザの開発者向け画面で通信記録を開きます。表示されたCORSメッセージだけでなく、失敗したリクエストのURL、通信方法、状態コード、リクエストヘッダー、レスポンスヘッダーを確認します。
OPTIONSが失敗している場合は、実際のPUTやPOSTが送信されていない可能性があります。プリフライトの応答に必要な許可ヘッダーがあるか、要求された通信方法とヘッダーが許可されているかを確認します。
OBJ本体の送信が成功している場合は、その後に行われる完了通知やプレビュー取得を確認します。画面上の一つの操作で複数の通信が実行されるため、最後に表示されたエラーだけでは原因を判断できません。
状態コードがブラウザから確認できない場合でも、サーバー側や保存先には具体的な記録が残っていることがあります。アップロード先URLの発行時刻、ファイル送信時刻、完了通知時刻を照合し、どこまで処理が進んだかを確認します。
利用者の端末時刻とサーバー時刻に差がある可能性も考慮します。特に署名付きURLの期限を調べる場合は、時刻の基準や記録形式をそろえて比較します。
同じOBJを使用し、アクセス元の環境だけを変えて比較する方法も有効です。検証環境では成功し、本番環境だけ失敗する場合は、許可オリジンや経路設定の差が疑われます。特定の利用者だけ失敗する場合は、認証状態や案件権限も確認します。
ブラウザ以外の通信方法でアップロードできたとしても、CORS設定が正常とは限りません。CORSはブラウザが適用する制御であり、一般的なサーバー間通信やコマンドラインツールでは同じ制限が適用されないためです。一方、ブラウザ以外でも同じ状態コードで拒否される場合は、CORSより前に署名、認証、容量制限などで失敗している可能性があります。
修正後は、正常なアップロードだけでなく、期限切れ、権限不足、容量超過、関連ファイル不足などの失敗条件も確認します。本来の原因を画面側で判別できる状態にしておくと、将来の調査が容易になります。
CORS設定を変更しても直らない場合の確認事項
許可オリジンや通信方法を修正してもエラーが続く場合は、CORS以外の問題がCORSエラーとして見えていないか確認します。ブラウザは、通信先から適切な許可ヘッダーを受け取れないと、レスポンス本文を画面側の処理へ渡しません。そのため、本来のエラーメッセージが隠れることがあります。
まず確認したいのは、アップロード先が実際に返している状態コードです。認証エラー、権限不足、ファイル容量超過、署名不一致、URL期限切れ、保存領域不足などが発生していないか、サーバー側の記録を確認します。
次に、アップロード経路上の中継サーバーやゲートウェイを確認します。アプリケーション側ではCORSヘッダーを設定していても、その手前の中継処理がエラーを返している場合、アプリケーションの設定は利用されません。中継先への接続失敗や容量制限によって、別の応答が返されている可能性があります。
レスポンスヘッダーが途中で削除されていないかも確認します。複数の層で同じヘッダーを設定した結果、重複や想定外の値になる場合があります。アプリケーション、中継処理、保存先のそれぞれでCORSを設定し、最終応答が不正になることもあります。
リダイレクトが発生している場合は、転送後の通信先を確認します。最初のURLでCORSが許可されていても、転送後のホストで許可されていなければ失敗します。署名付きURLの場合は、転送によって署名条件が変わっていないかも確認します。
画面側の設定変更が反映されていない可能性もあります。古い画面ファイルがキャッシュされ、以前のAPI URLやヘッダー設定を使い続けていることがあります。修正後は、実際に送信されたリクエストを見て、変更内容が反映されているかを確認します。
サーバー側の設定反映状況も同様です。設定ファイルを変更しても、対象の処理が再読み込みされていなかったり、別環境へ変更を加えていたりする場合があります。現在アクセスしている環境と、設定を変更した環境が一致しているかを確かめます。
ファイル名やパスの問題も確認します。存在しない関連ファイルを取得しようとしてエラー応答が返され、その応答に必要なCORSヘッダーがない場合、画面上ではCORSエラーになります。OBJ内の参照、保存先の配置、文字の大文字と小文字、URLエンコードの扱いなどを照合します。
HTTPSの画面からHTTPの通信先へ接続している場合は、混在コンテンツとして遮断される可能性があります。この問題は許可オリジンの追加だけでは解決しません。画面と通信先の両方をHTTPSへ統一し、最初から安全な通信先URLを使用します。
ブラウザの安全機能を無効化して動作確認する方法は、恒久的な解決策にはなりません。安全機能を無効にすると一時的に通信できても、利用者の通常環境では再び失敗します。通信先の設定と経路を正しく修正する必要があります。
点群OBJアップロードの再発防止策
CORSエラーの再発を防ぐには、許可設定だけでなく、点群OBJアップロード全体の通信設計を整理します。画面、認証API、アップロード先、完了通知、プレビュー配信について、送信元、送信先、通信方法、必要なヘッダー、認証方式を明確にします。
アップロードでPUTやPOSTを使い、プレビューでGETを使い、存在確認でHEADを使う場合は、それぞれが本当に必要かを整理したうえで許可します。利用していない通信方法まで広く許可しないことで、設定の見通しを保ちやすくなります。
環境ごとの許可オリジンは、変更しやすい設定として管理します。本番、検証、開発で値を分け、変更履歴を確認できるようにします。過去の検証環境や一時的な確認環境を無期限に許可したままにしないことも大切です。
画面側では、アップロードに必要なヘッダーだけを送信します。将来使う可能性があるという理由だけで独自ヘッダーを追加すると、プリフライトや署名条件が複雑になります。案件番号、ファイル種別、管理番号などの情報をどこへ含めるかは、保存先の仕様とあわせて決めます。
Content-Typeを固定する場合は、URL発行側、画面側、保存先で同じ値を使用します。署名条件へ含めない場合でも、保存後の処理がその値を前提としていることがあるため、実際のファイル形式と整合するように管理します。
エラー応答の設計も再発防止に関係します。正常時にはCORSヘッダーが付いていても、認証失敗や容量超過時に付いていなければ、利用者には原因が分かりません。代表的な失敗条件について、画面側が適切なエラー内容を判別できることを確認します。
画面上の表示は、アップロードに失敗しましただけにしない方が実務的です。アップロード先URL取得失敗、プリフライト失敗、OBJ本体送信失敗、関連ファイル送信失敗、完了通知失敗、プレビュー取得失敗など、処理段階を区別できるようにします。
再試行処理を設ける場合は、期限切れURLをそのまま再利用しないようにします。必要に応じて新しいアップロード先URLを取得し、途中まで保存されたファイルの扱いを決めます。一部の関連ファイルだけが成功した状態で全体を再送すると、重複や参照不整合が起こる可能性があります。
アップロード単位を識別する管理番号を発行し、OBJ本体と関連ファイルを同じ単位へひも付ける方法が有効です。途中失敗したものは未完了として管理し、一定期間後に整理できるようにすると、不要なファイルが保存先へ残りにくくなります。
設定変更後の試験では、許可されたオリジンから正常に送信できることだけでなく、許可されていないオリジンが拒否されることも確認します。必要な通信方法とヘッダーだけが許可されていることを確かめ、安全性と動作の両方を確認します。
点群OBJを安全に運用するための注意点
CORSエラーが解消しても、点群OBJを安全に運用できるとは限りません。CORSはブラウザ通信の制御であり、ファイル内容の検査、利用者権限、容量管理、保存期間などは別に設計する必要があります。
受け付ける拡張子を.objに限定するだけで、ファイル内容の安全性や正当性を保証することはできません。サーバー側でファイルサイズ、実際の内容、想定する構文、頂点数や面数、関連ファイルの参照方法などを確認し、処理負荷や不正入力への対策を行います。
OBJ内で関連ファイルを参照する場合は、保存領域の外へ意図せずアクセスしないようにします。上位階層へ移動する記述や、管理外の場所を示す参照をそのまま解決すると、想定外のファイルやURLへアクセスするおそれがあります。参照先を許可された範囲へ限定し、パスを正規化してから扱います。
ファイル名の扱いも統一します。空白、記号、文字種、大文字と小文字の違いによって、アップロード時には成功しても表示時に参照できないことがあります。利用者が付けた元のファイル名を表示用として保持し、実際の保存名には管理番号を使用する方法も考えられます。
点群OBJは容量が大きくなる場合があるため、アップロード上限を設定します。ただし、業務で扱うデータ量を確認せずに小さな上限を設定すると、実用上必要なファイルを登録できません。想定する点数、面数、関連画像の有無、通信環境を踏まえて決めます。
上限を超えた場合は、CORSエラーではなく容量超過として利用者へ伝わるようにします。エラー応答にも必要なCORSヘッダーを付け、画面側が理由を表示できる状態にします。
通信が中断した場合の扱いも決めておきます。最初から再送するのか、途中から再開できるようにするのかによって、必要な管理方法が変わります。再開処理を実装する場合は、分割データの順序、整合性、期限、重複送信を管理します。
途中まで保存されたOBJを完成済みとして扱わないことも重要です。アップロード完了通知や整合性確認が終わるまでは未完了状態として管理し、プレビューや共有の対象から除外します。
点群データには、現場の形状や位置に関する情報が含まれる場合があります。アップロードできる利用者だけでなく、アップロード後に閲覧、取得、共有、削除できる利用者も制御します。
CORSでアクセス元を限定していても、配信URLを知っている第三者がファイルを取得できる構成では、十分な権限管理とはいえません。案件単位の権限、期限付きの取得URL、認証を必要とする配信などを、データの重要度に応じて組み合わせます。
アップロード記録には、利用者、日時、対象案件、ファイル名、容量、処理結果などを残します。CORSエラーの調査では、ブラウザ側の情報だけでなく、サーバー側の処理記録が重要です。失敗した通信も追跡できるようにします。
一方で、署名付きURLや認証情報をそのまま記録へ残すのは避けます。URLの検索文字列に一時的な認証情報が含まれる場合、記録や画面共有を通じて漏れる可能性があります。調査に必要な管理番号と、秘匿すべき情報を分けて扱います。
開発者向け画面の画像や通信記録を共有するときも注意が必要です。Cookie、認証ヘッダー、署名付きURL、案件名、保存先パスが含まれている場合があります。不要な情報を伏せたうえで、発生時刻、状態コード、通信方法など、調査に必要な情報を共有します。
まとめ
点群OBJアップロードで発生するCORSエラーは、OBJの座標や面情報そのものではなく、ブラウザと通信先の許可条件が一致していないときに起こる問題です。
代表的な原因は、アップロード元オリジンの登録不足、プリフライトへの応答不足、認証情報と許可オリジンの競合、署名付きURLやリダイレクト条件の不一致、OBJ関連ファイルごとの設定差です。
ただし、本来は認証切れ、署名不一致、容量超過、参照ファイル不足などの問題であっても、エラー応答に必要なCORSヘッダーがなければ、ブラウザから詳細を読み取れず、CORSエラーとして見えることがあります。許可設定だけを変更し続けるのではなく、サーバー側や保存先の処理記録も確認することが重要です。
プリフライトではOPTIONS、実際のアップロードではPUTやPOST、プレビュー取得ではGETなどが使われることがあります。どの段階で失敗しているかを分けて確認し、リクエストURL、通信方法、要求ヘッダー、応答ヘッダー、認証状態を照合します。
設定を修正するときは、すべてのオリジンや通信方法を無条件で許可するのではなく、実際に必要な範囲を明確にします。本番、検証、開発の許可オリジンを分け、不要になった設定を削除します。正常応答だけでなく、期限切れや容量超過などのエラー応答にも必要なCORSヘッダーを付けることで、将来の調査を行いやすくできます。
点群OBJを継続的に活用するには、CORS設定だけでなく、ファイル内容の検査、関連ファイルの管理、容量上限、アクセス権限、処理記録、保存期間を含めて運用を整えることが大切です。
現場で取得した点群をアップロードし、確認や共有まで円滑につなげる方法を検討する際は、LRTK Phoneを含む実際の取得・アップロード環境について、対応形式、容量上限、通信条件、権限設定を事前に確認してください。