点群由来の3DモデルをOBJ形式でアップロードしたあと、新しいファイルを登録したはずなのに、画面上では古い形状や古いテクスチャ、以前の位置合わせや表示情報が見えることがあります。実務では、この現象を単なる表示ミスとして片づけて再アップロードを繰り返すと、どの版が最新なのか分かりにくくなり、確認作業の手戻りが増えます。なお、OBJは点群そのものに限定された形式ではなく、頂点や面などの3D形状を記述できる形式です。点群からメッシュ化してOBJを書き出している場合は、元の点群、OBJ本体、材質定義、テクスチャ、クラウド側で生成される表示用データを分けて考える必要があります。
OBJでは、形状を記述するOBJ本体とは別にMTLファイルやテクスチャ画像を参照する構成が使われることがあります。また、クラウドサービスやWebビューアによっては、アップロードした元ファイルからサムネイル、軽量プレビュー、階層化された表示データなどを生成します。そのため、元ファイルが更新されても、ブラウザ側のキャッシュ、サービス側の変換結果、関連ファイルの参照、共有先の版が同時に切り替わるとは限りません。
重要なのは、旧データが見える原因を「キャッシュ」と一括りにしないことです。ブラウザに古い応答が残っている場合もあれば、共有リンクが旧ファイルを指している場合、MTLやテクスチャ画像が旧版のままの場合、クラウド側のプレビュー生成が完了していない場合もあります。サービスごとに仕様が異なるため、再変換や権限反映の挙動を断定せず、どの段階で差が生じているかを順番に確認することが安全です。
点群OBJアップロード後に旧データが出る仕組みを理解する
点群OBJアップロード後に旧データが出る原因を考えるときは、まず「アップロードされた元データ」と「画面に表示するために取得されたデータ」が同じタイミングで更新されるとは限らない、という前提を持つことが重要です。Webサービスでは、表示速度や通信量を抑えるため、ブラウザキャッシュやCDNなどの共有キャッシュが使われることがあります。3Dビューア側でも、元のOBJをそのまま表示するのではなく、サービス独自の軽量データやプレビューを生成する場合があります。
OBJファイルには頂点座標、面、テクスチャ座標などを記述できます。表面の見え方はMTLファイルやテクスチャ画像と組み合わせて表現されることがあり、OBJ本体だけを差し替えても見た目に関係する関連ファイルが更新されていなければ、古い外観が残ったように見える場合があります。ただし、OBJやMTLの対応範囲、アップロード時のファイル配置、プレビュー生成方法はサービスやソフトウェアによって異なるため、特定の挙動をすべての環境に当てはめないことが大切です。
旧データが出る場面にはいくつかの切り分け方があります。新しい形状をアップロードしたのに輪郭が古い場合は、まず開いているファイルや版が正しいかを確認し、そのうえでブラウザ側のキャッシュやサービス側の変換結果を確認します。形状は更新されているのに色や写真由来の見た目だけが古い場合は、MTLやテクスチャ画像の更新漏れ、参照名の不一致、同名画像へのキャッシュなどを疑います。サムネイルだけ古く詳細表示は新しい場合は、一覧用画像と本表示が別に管理されているサービスであれば、一覧用プレビューだけ更新が遅れている可能性があります。
自分の画面では新しいのに関係者の画面では古い場合は、閲覧者側が旧リンクや旧版を開いていないかを最初に確認します。同じURLを開いている場合でも、ブラウザや中間キャッシュの状態によって取得結果が異なることがあります。一方、サービスが版ごとにURLや識別子を分けているなら、単純なブラウザキャッシュではなく、共有対象そのものが違う可能性があります。
ここで大切なのは、いきなり再アップロードを繰り返さないことです。OBJ一式は容量が大きくなることがあり、アップロードや変換に時間がかかります。原因を切り分けずに何度も上書きすると、どの版が最新なのか、どの関連ファイルが使われているのか、どの共有リンクを確認しているのかが分かりにくくなります。画面更新、閲覧側キャッシュ、クラウド側の処理状況、関連ファイル、共有対象という順で確認すると、無駄な作業を減らしやすくなります。
また、表示だけを見て判断しないことも重要です。ファイルの更新日時、容量、アップロード履歴、変換状態、表示中のデータ名、変更した形状やテクスチャの差分などを合わせて確認すると、旧データなのか、新データだが別の表示条件になっているのか、そもそも別ファイルを開いているのかを判断しやすくなります。複数人で確認する場合は、同じプロジェクト、同じフォルダ、同じ版、同じリンクを見ていることをそろえる必要があります。
対策1としてファイル名と版管理を分けて上書き表示を避ける
点群OBJアップロード後に旧データが出る場合、最初に見直したいのがファイル名と版管理です。ただし、ブラウザキャッシュは単純にローカルのファイル名だけを見て再利用するわけではありません。Web上では主にURLやHTTPのキャッシュ制御、サービス独自の識別方法などが関係します。そのため、「同じファイル名だから必ず古いキャッシュが出る」とは言えませんが、同じ保存先や同じ参照先を使い続ける運用では、新旧データを人が取り違えたり、同じURLで配信される資源の古い応答が再利用されたりする余地があります。
実務では、単に「最新版」という名前を使い続けるよりも、日付、対象範囲、作業段階などが分かる名称にしておくと混乱を避けやすくなります。同じ現場の同じエリアでも、計測直後、ノイズ処理後、メッシュ化後、軽量化後、承認用といった段階を区別しておけば、旧データが見えたときに比較しやすくなります。名称に日本語、空白、記号を使えるかどうかは利用するサービスの仕様によるため、互換性を重視する場合は、そのサービスが推奨する命名規則に合わせるのが安全です。
OBJでは、OBJ本体だけでなくMTLやテクスチャ画像にもファイル名があります。OBJ本体の名前だけを変えても、内部で参照するMTLや画像が以前と同じ名前、同じURL、同じ保存先のままであれば、見た目だけ旧版のように見える可能性があります。逆に、サービスがアップロード時に一式を別識別子で管理する仕組みなら、同名でも問題にならない場合があります。重要なのは、名称だけで判断せず、実際にどのファイルがどの参照先を使っているかを確認することです。
上書き運用そのものが悪いわけではありません。サービスが正式に版管理や上書き更新をサポートしているなら、その仕組みに従う方が安全な場合もあります。ただし、重要な確認や承認に使うデータでは、旧版と新版の区別ができるようにし、変更内容と更新日時を記録しておくと確認ミスを減らせます。新しい版として登録した場合は、共有リンクが旧版を指したままになっていないかも合わせて確認します。
アップロード前にローカル環境のフォルダ構成を整理しておくことも有効です。変換前、変換後、軽量化後、アップロード済みのフォルダが混在すると、古いOBJを誤って再アップロードすることがあります。旧データ表示に見えて、実際にはアップロード元が旧版だったという可能性は最初に除外すべきです。アップロード対象の更新日時、容量、変更箇所、ローカルでの表示結果を確認してから登録すると、切り分けがしやすくなります。
ファイル名と版管理はキャッシュ対策の土台です。キャッシュを削除しても、新旧のファイルが混在し、どれを正とするか分からなければ同じ混乱が再発します。点群OBJアップロードの運用では、表示更新だけでなく、データを一意に識別できる管理方法を整えることが第一の対策になります。
対策2としてブラウザと端末側のキャッシュを更新する
ファイルや版が正しいにもかかわらず旧データが見える場合は、閲覧しているブラウザ側に古い応答が残っていないかを確認します。ブラウザは画像やスクリプト、モデルデータなどのHTTP応答をキャッシュし、条件に応じて再利用します。キャッシュの再利用可否はURLだけでなく、Cache-Control、ETag、Last-ModifiedなどのHTTPヘッダーやブラウザの実装、サービスワーカーなどにも左右されます。そのため、単に「端末に古いファイルがあるから」と決めつけず、Web資源の取得状態として考えることが大切です。
最初に試しやすいのは、通常の再読み込みに加えて強制再読み込みを行うことです。一般的なブラウザでは、強制再読み込みによってキャッシュ済み応答をそのまま使わず、再取得を試みる範囲を広げられます。ただし、サービスワーカーやアプリ独自のキャッシュ、CDNなどが関与する場合は、これだけで必ず更新されるとは限りません。サービス側に推奨手順がある場合は、その手順を優先します。
作業者の画面では新しいデータが見えているのに、別の担当者では旧データが見える場合は、閲覧者ごとの条件を比較します。同じリンクを開いているか、同じプロジェクトや版を選んでいるか、ログインしているアカウントや権限が同じか、ブラウザを開き直しても同じかを確認します。別ブラウザやプライベートウィンドウ、別端末で同じリンクを開くと、端末固有の状態かどうかを切り分けやすくなります。
ログイン状態や権限が関係するサービスでは、閲覧できるファイルがアカウントごとに異なることがあります。ただし、権限情報が古いから必ず旧版が表示されるとは限りません。アクセスできない、一覧に出ない、旧版しか選択できないなど、サービスごとに現れ方は異なります。再ログインや権限確認は、ブラウザキャッシュ削除とは別の確認項目として扱うのが安全です。
端末のメモリ不足や通信不安定も、3Dデータの読み込み失敗や不完全表示につながることがあります。ただし、これを旧データ表示の直接原因と断定するのは適切ではありません。不要なタブやアプリを閉じ、安定した通信環境で再度開くことは切り分けとして有効ですが、それで改善した場合も、単純なキャッシュ問題なのか、読み込み失敗が解消したのかを分けて考える必要があります。
複数人で確認する現場では、再読み込みの方法をそろえておくと原因を追いやすくなります。新しいデータ名、確認用リンク、変更箇所、表示がおかしい場合に試す手順を共有し、どの環境で問題が再現したかを記録します。LRTK Phoneで取得したデータを加工してOBJとして共有する運用でも、現場端末、作業者端末、閲覧者端末を分けて確認すると、再計測や再アップロードが必要なのか、閲覧環境の更新だけで済むのかを判断しやすくなります。
対策3としてクラウド側の変換キャッシュとプレビューを再生成する
ブラウザ側の確認をしても旧データが残る場合は、クラウドサービス側で生成される表示用データを確認します。サービスによっては、アップロードしたOBJをそのまま配信せず、閲覧用に軽量化したデータ、サムネイル、階層表示用データ、圧縮済みテクスチャなどを生成します。このような仕組みがある場合、元ファイルの登録完了と、表示用データの生成完了は別の状態です。
一覧画面のサムネイルだけ古く、詳細表示は新しいという現象は、一覧用画像と本表示が別に生成されるサービスで起こり得ます。また、アップロード直後に旧表示が見え、一定時間後に更新される場合は、非同期の変換処理やキャッシュ更新が関係している可能性があります。ただし、どの表示データをどのタイミングで生成するかはサービス固有です。「近づくと新しい形状になる」「特定角度だけ旧テクスチャになる」といった症状を一般的なキャッシュ動作として断定せず、実際のサービス仕様や変換状態を確認することが重要です。
まず、アップロード完了だけで判断せず、変換中、処理待ち、完了、失敗などのステータスが確認できる場合は確認します。処理ログやエラー表示があるなら、その内容を優先します。明示的な再変換、プレビュー更新、サムネイル再作成などの機能が用意されている場合は、サービスの案内に従って実行します。
再生成機能がないからといって、すぐに旧版を削除して再登録する必要はありません。削除によって共有リンク、コメント、注釈、承認履歴などの付随情報が失われるサービスもあります。新しいファイル名や新しい版として登録すると別資源として扱われることがありますが、これもサービス仕様次第です。重要なデータでは、再登録前に履歴や共有先への影響を確認します。
新しいOBJのプレビュー生成に失敗したとき、サービスによってはエラー表示になる場合もあれば、以前の表示が残る場合もあります。最後に成功したプレビューを保持するかどうかは実装依存であり、一般論として断定できません。そのため、「旧データが見えるから新OBJの変換に失敗した」と決めつけず、元ファイルが正しいか、処理ステータスはどうか、別環境でも同じ表示かを合わせて確認します。
OBJの読み込みや変換では、MTLやテクスチャの欠落、未対応の記述、非常に大きなデータ、複雑なジオメトリなどが問題になる場合がありますが、許容される容量や仕様はサービスによって異なります。座標値、文字コード、ファイル名、材質数なども、特定サービスでは制約になる可能性がありますが、一律にプレビュー失敗の原因とすることはできません。公開前の記事では「利用先の仕様とログを確認する」という表現にとどめるのが安全です。
重要な確認では、アップロード後すぐに関係者へ送るのではなく、アップロード担当者自身が新データの変更箇所を確認してから共有します。サムネイルだけでなく詳細表示、テクスチャ、位置、変更範囲などを確認し、必要であれば別ブラウザや別アカウントでも開きます。クラウド側の問題が疑われる場合は、アップロード時刻、ファイル名、処理状態、期待する変更点、実際に見えている内容を整理して問い合わせると原因を追いやすくなります。
対策4としてOBJ関連ファイルの参照先と更新漏れを確認する
点群OBJアップロード後に旧データが出る原因として、OBJ本体以外の関連ファイルの更新漏れは重要です。OBJは形状情報だけで利用できる場合もありますが、表面材質を表すMTLやテクスチャ画像を組み合わせる構成も一般的です。OBJ本体が新しくても、MTLや画像が旧版なら、形状は新しいのに表面だけ古く見えることがあります。
実務で起こりやすいのは、OBJだけをアップロードし直し、MTLやテクスチャ画像の差し替えを忘れるケースです。テクスチャが複数枚ある場合、一部だけ旧版が混ざることもあります。形状の一部だけ古い色に見える、修正したはずの範囲に以前の画像が貼られているといった場合は、ブラウザキャッシュだけでなく、関連ファイルそのものの内容を確認します。
OBJ本体では、MTLを参照する記述が使われることがあります。MTL側ではテクスチャ画像への参照が記述されます。ファイル名を変更した場合は、参照記述も一致している必要があります。ローカルで開けていても、クラウド側の配置規則や対応するパス表現が異なれば読み込めない場合があります。そのため、利用するサービスがOBJ、MTL、画像をどのようなフォルダ構成で受け付けるかを確認することが重要です。
相対パスと絶対パスの扱いにも注意が必要です。ローカル端末上の絶対パスを前提にした参照は、別環境へ移動すると成立しないのが一般的です。ただし、その場合に必ず旧画像が表示されるわけではなく、テクスチャが欠落したり、サービス側で参照を書き換えたりすることもあります。「参照が崩れたら古い画像が出る」と決めつけず、参照先が解決できているかを確認します。
圧縮ファイルでアップロードする運用でも、更新漏れが起こります。新しいOBJを作成したあと、以前作った圧縮ファイルを誤ってアップロードすれば、中身は当然旧版のままです。圧縮ファイル名だけを変えても内容は変わらないため、必要に応じて展開して中身の更新日時やファイル構成を確認します。
クラウド上に同名の関連ファイルが存在する場合の扱いはサービスによって異なります。同名ファイルを上書きするサービスもあれば、内部で別IDとして管理するサービスもあります。したがって、「同名ファイルがあると新OBJが必ず旧ファイルを参照する」とは言えません。問題が続く場合は、新旧を別フォルダや別版として分け、どの一式を参照しているかを明確にすると切り分けやすくなります。
旧データ表示の調査では、今回どこを変更したかに応じて確認対象を絞ります。形状を変更したならOBJの頂点や面、色や画像を変更したならMTLとテクスチャ、配置や向きを変更したなら変換時の座標やクラウド側の配置設定を確認します。点群OBJアップロードでは、OBJ本体だけを「データ」と考えず、表示に必要な一式とサービス側の設定を合わせて管理することが重要です。
対策5として共有リンクと閲覧権限の表示タイミングをそろえる
点群OBJアップロード後に旧データが出る問題は、データそのものやキャッシュだけでなく、共有リンクや閲覧権限の運用でも起こります。新しいデータを別ファイルや別版として登録したのに、関係者へ以前の共有リンクを送れば、そのリンクが旧版を指したままのことがあります。また、新版への権限が付与されていなければ、閲覧者が新版を選べないサービスもあります。
作業者の画面では新しいデータが見えているのに、発注者や協力会社では古いデータが見える場合は、まず同じURL、同じプロジェクト、同じ版を開いているかを確認します。管理者は新旧両方を閲覧できても、外部閲覧者は共有された対象だけにアクセスできることがあります。単に「更新してください」と伝えるだけでは、相手が同じ旧リンクを再び開く可能性があります。
共有リンクがプロジェクト全体、フォルダ、個別ファイル、特定版のどれを指すかによって更新時の挙動は変わります。個別ファイルへのリンクで新版を別ファイルとして登録したなら、旧リンクから自動的に新版へ切り替わるとは限りません。逆に、サービス側が常に最新を表示する共有リンクを提供している場合は、リンクを変えなくてもよいことがあります。ここもサービス仕様を確認する必要があります。
閲覧権限の変更や新しいプレビューの生成に反映時間があるかどうかもサービスによって異なります。すぐ反映される環境もあれば、バックエンド処理に時間がかかる環境もあります。そのため、「権限反映には必ず時間差がある」とは断定せず、共有前に閲覧者に近い条件で表示を確認するのが安全です。
共有時には、データ名、更新日時、対象範囲、今回の変更点を短く添えると、閲覧者が誤った版を開いていることに気づきやすくなります。旧版を履歴として残す場合も、現行版と区別できる名称や保管場所にしておくと誤閲覧を減らせます。旧リンクを無効化できるか、最新版を固定リンクで示せるかはサービスの機能に応じて判断します。
アップロード前から画面を開いたままにしていた場合、アプリの状態やブラウザ履歴によって以前の表示が残ることがあります。確認依頼では、必要に応じて古いタブを閉じ、新しく案内したリンクから開き直してもらいます。再ログインが必要かどうかはサービスの仕様によるため、権限変更を行った場合など、必要な場面で実施します。
共有リンクと閲覧権限の問題は、技術的なキャッシュ削除だけでは解決できません。どの版を正とするのか、誰がどの範囲を見るのか、旧版をどう保管するのかを決める必要があります。OBJの見た目は旧版でも一見正しく見えることがあるため、閲覧者側でも最新版を判別できる情報を添えることが重要です。
現場運用で旧データ表示を再発させない管理方法
旧データ表示への対策は、発生したときだけ行うのではなく、点群OBJアップロードの標準手順に組み込むことで再発を減らせます。現場では、計測、点群処理、メッシュ化、テクスチャ生成、確認、アップロード、共有、承認という流れが短時間で進むことがあります。急いでいると、旧ファイルの混入、関連ファイルの更新漏れ、共有リンクの使い回し、閲覧者ごとの確認条件の違いが起こりやすくなります。
アップロード前には、対象データの版、更新日時、容量、対象範囲、関連ファイルの有無を確認します。OBJ本体だけでなく、MTLやテクスチャ画像も同じ作業時点のものかを確認します。点群からOBJへ変換した場合は、ローカル環境で変更箇所を表示し、古い形状や不要な範囲が残っていないかを確認します。ここで旧データが混入していれば、クラウド側でキャッシュを更新しても正しい表示にはなりません。
アップロード後は、登録完了と表示確認を分けて判断します。サービスによっては、一覧にファイルが出たあとにプレビュー生成が続く場合があります。変更箇所が反映されているか、テクスチャが正しいか、配置が意図どおりかを確認してから関係者へ共有します。処理状態を確認できるサービスなら、完了表示も合わせて確認します。
共有前には、可能であれば別環境で開きます。アップロードした本人の環境だけでは、すでに開いていた画面や管理者権限の影響を受けることがあります。別ブラウザ、別端末、閲覧者に近い権限で同じリンクを開くと、共有後の表示差を減らせます。
旧データ表示の報告方法も標準化しておくと原因を特定しやすくなります。「古いです」だけでは、版違い、キャッシュ、関連ファイル、プレビュー生成のどれか分かりません。開いたリンク、表示されたデータ名、確認時刻、利用環境、変更箇所がどう見えたかを残すと、問題の層を切り分けやすくなります。
旧版を削除するか残すかもルール化します。履歴確認が必要なら旧版は残しつつ、現行確認用の場所から外します。現行、作業中、承認済み、保管用などの区分を決め、現在使う版が一目で分かる状態にします。サービスに正式な版管理機能がある場合は、独自運用よりその機能を優先した方が管理しやすい場合があります。
点群OBJアップロードに関わる人数が増えるほど、キャッシュ対策は個人の知識ではなくチームの運用になります。アップロード担当者はデータ一式の正しさを確認し、管理者は共有対象と権限を確認し、閲覧者は指定されたリンクと版を確認する、という役割を明確にすると対応が安定します。
LRTK Phoneを使って現場で取得した情報を活用する場合も同じ考え方が役立ちます。現場で取得した点群や位置情報などを加工し、OBJとして関係者へ共有する流れでは、取得データ、加工データ、アップロード済みデータが別の版として存在します。どの段階のデータを最新版とするかを決め、更新時に旧版との違いを説明できるようにすると、確認作業の信頼性を高めやすくなります。
旧データ表示を再発させないためには、キャッシュ削除という単発の対応だけでなく、版管理、関連ファイルの一式管理、アップロード後の表示確認、共有リンクの確認、閲覧者への案内までを一つの流れとして管理することが必要です。毎回同じ確認手順で扱えるようにすることが、結果的にもっとも確実なキャッシュ対策になります。
まとめ
点群OBJアップロード後に旧データが出る場合、原因は一つとは限りません。ブラウザや共有キャッシュの再利用、旧版や旧リンクの参照、クラウド側のプレビュー生成、OBJに関連するMTLやテクスチャ画像の更新漏れ、アップロード元ファイルの取り違えなど、複数の要因が考えられます。旧データが表示されたときは、すぐに再アップロードを繰り返すのではなく、どの段階で古い情報を参照しているのかを順番に確認することが大切です。
まず、ファイル名と版管理を見直し、旧版と新版が混在していないかを確認します。ただし、ブラウザキャッシュはファイル名だけで決まるものではないため、同じURLやサービス側の識別方法、HTTPのキャッシュ制御も関係することを理解しておきます。次に、強制再読み込みや別ブラウザなどで閲覧側の状態を切り分けます。
そのうえで、クラウド側に変換処理やプレビュー生成の仕組みがある場合は、処理状態を確認します。再変換やプレビュー更新機能があるなら、サービスの正式な手順に従います。OBJ本体だけでなく、MTLやテクスチャ画像を含めた一式が正しいかも確認します。さらに、共有リンクが正しい版を指しているか、閲覧者が新版へアクセスできるかを確認します。
点群OBJアップロードの実務では、表示されたものが必ず最新版だと決めつけないことが重要です。一方で、旧表示が出たからといってすべてをキャッシュのせいにするのも適切ではありません。版違い、関連ファイル、サービス側の変換、共有設定などを分けて確認することで、不要な再計測や再アップロードを避けやすくなります。
再発防止には、アップロード前の一式確認、アップロード後の変更箇所確認、共有前の別環境確認、旧版の保管ルール、閲覧者への版情報の案内を標準化することが有効です。現場で取得した情報を後工程の設計確認、施工管理、出来形確認、維持管理へつなげるには、関係者が同じ最新版を確認できることが前提になります。点群や位置情報を扱えるLRTK Phoneを活用する場合も、取得から加工、共有までの版を明確に管理し、表示更新とデータ更新を分けて確認する運用が重要です。