点群OBJアップロード後に旧データが残る主な原因
点群や三次元形状をOBJ形式でアップロードしたにもかかわらず、閲覧画面に修正前の形状や古い色、削除したはずの部分が表示されることがあります。アップロード画面では完了と表示されているため、実務担当者から見ると、ファイルの置き換えに失敗したように感じられる現象です。
なお、OBJは三次元形状を記述する形式であり、頂点だけを点として扱うデータと、面情報を含むポリゴンメッシュの両方があり得ます。どの記述を点群として読み込めるか、面や材質をどこまで扱えるかは、アップロード先や表示アプリの対応仕様によって異なります。本記事では、OBJで管理される点群またはメッシュデータをまとめて「点群OBJ」と表現します。OBJは頂点、テクスチャ座標、法線、面などを記述でき、外部のMTLファイルを参照できる形式です。The Library of Congress+1
サーバーには新しいOBJファイルが保存されているものの、閲覧側だけが以前取得したデータを再利用している場合があります。この再利用に関係するのがキャッシュです。キャッシュとは、一度取得したデータを端末や配信経路に一時保存し、次回以降の読み込みを速くする仕組みです。
OBJは、頂点、面、法線、UVなどの記述が増えるほどファイル容量が大きくなる傾向があります。テクスチャ画像やマテリアル情報を併用する場合には、関連ファイルを含めた通信量も増えます。そのため、閲覧のたびにすべてを最初から取得するのではなく、一度取得したデータを再利用する設計が採用されることがあります。
キャッシュが適切に働けば、点群OBJの表示開始までの時間を短縮しやすくなります。通信環境が安定しない現場でも、取得済みのデータを再利用できる構成であれば、再表示にかかる通信量を抑えられます。一方で、ファイルの内容が変わっているのに、表示側が同じデータだと判断すると、更新前のOBJが残り続けることがあります。
特に発生しやすいのが、同じファイル名と同じURLでOBJを上書きする運用です。たとえば、修正前も修正後も同じ保存先に同じ名前でアップロードすると、閲覧側から見たURLが変わりません。内容だけが変わっていても、HTTPキャッシュの有効期間や再検証の設定によっては、保存済みのファイルが再利用される可能性があります。HTTPキャッシュでは、応答の保存期間や再検証方法がヘッダーなどで制御されます。MDN Web Docs+1
キャッシュが存在する場所は一つではありません。利用者のブラウザ内に保存されることもあれば、ウェブサーバー、CDNなどの配信経路、社内ネットワークの中継部分、表示アプリケーション内部などに保存されることもあります。そのため、ブラウザの通常の再読み込みだけでは解消しない場合があります。
また、点群OBJの表示では、OBJファイル以外のデータが関係していることがあります。材質の設定を記録するMTLファイル、表面の見え方に使用するテクスチャ画像、表示システムが生成した軽量化データ、案件情報を記録した管理データなどです。OBJだけが新版になっていても、関連ファイルや表示用データが旧版であれば、全体として古いデータが残っているように見えます。
旧データの問題を解決するには、利用者に毎回すべてのキャッシュを削除してもらうのではなく、更新されたデータを確実に識別できる仕組みを整えることが重要です。ここからは、点群OBJアップロード後に実施したい5つのキャッシュ対策を順番に解説します。
キャッシュ対策1 更新ごとにURLを変える
点群OBJの更新を確実に反映させる方法として、最初に検討したいのがURLの変更です。一般的なHTTPキャッシュでは、リクエスト先のURLなどがキャッシュを識別する要素になります。内容が変わっていてもURLが同じであれば、設定によっては以前取得したデータが再利用されます。
たとえば、毎回同じ場所に同じ名前のOBJを保存する運用では、修正前と修正後のURLが変わりません。この状態で閲覧画面を開くと、保存済みの旧OBJが表示される可能性があります。
対策として、更新ごとにファイル名や保存先を変えます。版番号を付けて管理すれば、更新前と更新後を別のURLとして扱えます。ファイル名に連番を含める方法や、データの更新番号を含める方法などが考えられます。
ただし、担当者が自由な形式でファイル名を付けると管理が複雑になります。「最新版」「最終版」「修正版」といった名称を繰り返すと、どれが本当の最新版なのか分からなくなるためです。版番号の桁数や付与方法を統一し、公開中の版が明確に分かるようにします。
ファイル名を変えられないシステムでは、URLの末尾に更新識別子を追加する方法があります。OBJの保存先自体は同じでも、更新番号を含むURLで読み込めば、キャッシュキーにクエリ文字列を含める構成では、以前とは異なるデータとして扱わせることができます。
ただし、クエリ文字列をキャッシュキーに含めるかどうかは、CDN、プロキシ、サービスワーカー、表示アプリなどの設定によって異なります。クエリ文字列を除外または無視する構成もあるため、更新識別子を付ければ必ず反映されると断定せず、実際の配信設定と取得結果を確認します。Cloudflare Docs+2AWS ドキュメント+2
更新識別子には、アップロード日時、管理画面で発行した版番号、ファイル内容から生成したハッシュ値などを使用できます。重要なのは、データが変わったときに識別子も変わり、データが変わっていないときは同じ識別子を維持することです。
画面を開くたびに現在時刻を付ける方法は、一時的な動作確認には利用できますが、恒常的な運用には適していません。多くの構成では毎回別のURLとして扱われ、対象データのキャッシュを再利用しにくくなるため、点群OBJを開くたびに大容量のダウンロードが発生しやすくなります。
更新がないときは同じURLを使い、更新したときだけ新しいURLへ切り替える仕組みにすると、表示速度と更新反映を両立しやすくなります。
OBJにMTLやテクスチャ画像が付属する場合は、OBJのURLだけを変更しても不十分なことがあります。OBJから読み込まれるMTLのURLや、MTLから参照される画像のURLが以前と同じであれば、外観だけ旧版のままになる可能性があります。
関連ファイルを含むフォルダ全体に版番号を付ける方法は、運用を整理しやすい対策です。新版のOBJ、MTL、画像を新しい版のフォルダへ保存し、すべての転送が完了してから閲覧画面の参照先を切り替えます。
この方法なら、利用者がキャッシュ削除を行わなくても、新しいURLから新版を取得させやすくなります。また、問題があった場合に参照先を以前の版へ戻しやすくなります。
外部の関係者へ点群OBJを共有する場合にも、URL変更は有効です。複数の利用者に端末ごとのキャッシュ削除を依頼するより、公開側で新版のURLや版識別子を管理する方が、更新漏れや確認ミスを減らしやすくなります。
キャッシュ対策2 ブラウザ側の保存データを更新する
URLを変更しても表示が変わらない場合や、原因を切り分けるために新版をすぐ確認したい場合は、ブラウザ側の保存データを更新します。
通常の再読み込みでは、保存済みのOBJや画像が再利用されることがあります。画面の構成情報だけが再取得され、容量の大きい三次元データはキャッシュから読み込まれる構成もあります。そのため、単に再読み込みを何度繰り返しても表示が変わらない場合があります。
最初に、ブラウザが提供する強制再読み込みや、保存済み応答の再検証を促す操作を試します。操作名や挙動はブラウザによって異なりますが、一般的な強制再読み込みでは、通常の再読み込みよりキャッシュの利用を抑えた要求が行われます。MDN Web Docs+1
それでも旧データが残る場合は、対象サイトに関連するキャッシュを削除します。閲覧履歴やすべての保存データを一括削除する必要はありません。可能であれば、点群OBJを表示しているサイトだけを対象にします。
すべての保存情報を削除すると、業務で利用している他の画面からログアウトしたり、入力設定が失われたりする可能性があります。キャッシュ問題を解消するために、別の業務へ影響を与えてしまっては効率的ではありません。
点群OBJの閲覧システムによっては、一般的なHTTPキャッシュとは別に、Cache Storage、IndexedDB、ローカル保存領域などへデータを保存していることがあります。たとえば、読み込んだOBJを解析し、頂点や面の情報を表示しやすい形式へ変換してから保存している場合です。
このような構成では、一般的なブラウザキャッシュだけを削除しても、解析済みの旧データが残ることがあります。サービスワーカーやCache StorageはHTTPキャッシュとは別に応答を保持できるため、対象サイトの保存領域、オフラインデータ、アプリ内の一時データを削除または更新する機能があるかを確認します。MDN Web Docs+1
同じ閲覧画面を複数のタブで開いているときにも注意が必要です。一方のタブで新しいOBJをアップロードしても、別のタブは古いモデルをメモリ内に保持していることがあります。旧データを表示しているタブを閉じずに画面を切り替えると、古い状態が再び表示されることもあります。
アップロード後の確認時には、同じ案件を開いているタブを整理し、対象画面を閉じてから開き直します。単に表示を切り替えるだけでなく、旧モデルを保持している画面自体を終了させることがポイントです。
一時的な閲覧状態を利用して、通常環境との差を確認する方法もあります。通常の画面では旧データが表示され、既存のサイトデータを引き継がない別の閲覧環境では新版が表示されるなら、端末側の保存データが原因である可能性が高まります。ただし、サービスワーカーや組織内の共有キャッシュなど、閲覧モードだけでは切り分けられない要因もあります。
別の端末で同じURLを開くことも有効です。ある端末だけが旧版で、他の端末では新版が表示される場合は、利用者側の保存データを重点的に確認します。
反対に、すべての端末で同じ旧データが表示される場合は、ブラウザだけでなく、サーバー側や公開処理を調べる必要があります。利用者側のキャッシュを何度削除しても、配信元や表示用データが旧版のままであれば表示は変わりません。
端末の再起動で解決することもありますが、再起動だけを標準的な対策にするのは避けたいところです。原因が分からないまま一時的に直ると、同じ問題が再発した際に対応手順を再現できません。
どの操作を行った時点で新版に変わったのかを記録します。強制再読み込みで変わったのか、対象サイトの保存データ削除で変わったのか、画面を閉じたことで変わったのかを残せば、次回以降の切り分けが早くなります。
キャッシュ対策3 サーバー側のキャッシュ設定を見直す
複数の端末で旧データが表示される場合や、端末側の保存データを削除しても変化しない場合は、サーバーや配信経路のキャッシュ設定を確認します。
点群OBJは容量が大きくなりやすいため、サーバー負荷や通信量を抑える目的で、一定期間データを再利用する設定が行われていることがあります。この保存期間が更新頻度に対して長すぎると、同名ファイルを上書きした後も旧版が配信され続ける可能性があります。
サーバーからOBJを返す際には、データをどの程度の期間保存してよいか、利用前に更新確認が必要か、保存自体を認めるかといった情報をHTTPヘッダーで指定できます。ブラウザや共有キャッシュは、その指示と自身の設定に基づいて、保存済みデータを使うか、新しいデータを取得するかを判断します。MDN Web Docs+1
作業途中で頻繁に更新するOBJと、公開後は変更しない完成版のOBJでは、適切なキャッシュ条件が異なります。作業中のデータに長い保存期間を設定すると、修正が反映されにくくなります。
一方、完成後に変更しないファイルへ固有の版番号を付けている場合は、長めに保存しても更新混同が起こりにくくなります。新版では別のURLになるため、旧版のキャッシュと区別できるからです。
同じURLを上書きする運用を続ける場合は、閲覧側が更新の有無を再検証できるようにします。サーバーがETagや最終更新日時などの検証情報を返し、保存済みデータと比較できる構成であれば、変更があるときだけ新版を取得しやすくなります。
ただし、OBJの内容を変更しても、サーバー上の検証情報が適切に変わらない処理になっていると、正しい再検証ができません。ファイル本体だけでなく、配信時に利用する管理情報や応答ヘッダーも更新されているかを確認します。
アップロード先と閲覧用の公開先が分かれているシステムにも注意が必要です。アップロードが完了していても、公開領域への転送や表示用データへの変換が終わっていない場合があります。
この状態で閲覧すると、公開先に残っている以前のOBJが表示されます。アップロード完了の表示が、端末から受け付けサーバーへの転送完了だけを意味している可能性もあります。その後に解析、軽量化、公開領域への複製などが続く場合は、各処理の状態を確認します。
配信経路の途中に共有キャッシュがある場合、元の保存先を更新しても中継地点から旧版が返されることがあります。元ファイルを直接確認すると新版なのに、通常の閲覧URLでは旧版になる場合は、配信経路やキャッシュキーの設定を疑います。
更新時には、対象URLのキャッシュを無効化または削除する処理を組み込む方法があります。ただし、点群OBJを更新するたびに配信経路の全データを削除すると、他の利用者や別案件の表示速度へ影響する可能性があります。
削除対象は、更新したOBJ、MTL、テクスチャ画像、表示用に生成された関連データなどに限定します。URLを版ごとに変更する運用であれば、旧URLのキャッシュを急いで削除しなくても、新URLへ安全に切り替えられる場合があります。
社内ネットワークを利用した場合だけ旧データが表示され、別の通信経路では新版が表示される場合は、組織内の通信中継や保存設定も確認します。この場合、個々の端末を操作しても、中継地点が同じ旧データを返し続ける限り解決しません。
サーバー側の対策では、キャッシュを一律に無効化するのではなく、データの更新方法に合わせて制御することが重要です。変更時だけ確実に新版を取得させ、変更がないデータは再利用できる構成を目指します。
キャッシュ対策4 表示アプリ内のデータを再読み込みする
ブラウザ上で動作する点群OBJの表示システムでは、通常のHTTPキャッシュとは別に、アプリケーション内部でモデルを保持している場合があります。
一度読み込んだOBJを画面内のメモリへ残し、再表示時にすぐ利用する仕組みです。この仕組みがあると、画面の切り替えや視点移動をすばやく行えますが、アップロード後も旧モデルが残る原因になることがあります。
アップロード完了後に画面を再表示しても、アプリケーションが同じモデル識別子を使っていると、メモリ内の旧データを再利用する可能性があります。新しいOBJを取得する前に、現在表示中のモデルを破棄する処理や、版情報を比較する処理が必要です。
モデルの差し替えでは、画面上から旧形状を非表示にするだけでは不十分な場合があります。内部に頂点、面、材質、テクスチャなどが残っていると、条件によって旧版が再表示されたり、新版と重なったりすることがあります。
特に、複数の点群やOBJを重ねて表示できるシステムでは、旧版が別レイヤーとして残っている場合があります。新版を表示したつもりでも、旧版とほぼ同じ位置に重なるため、変更部分が分かりにくくなります。
新旧の形状がわずかに異なる場合は、深度の競合などにより、表面がちらつく、色が不安定になる、削除した部分が残って見えるといった現象が発生することもあります。この場合は、単なるファイルキャッシュではなく、表示中の旧オブジェクトが削除されているかを確認します。
アプリケーションが独自の保存領域を利用している場合は、モデルの版番号を管理する必要があります。案件番号だけを識別子にすると、同じ案件内でOBJを更新しても同一データとして扱われることがあります。
案件番号に加えて、アップロードごとの版番号や更新識別子を使用すれば、アプリケーション側でも新版を区別できます。表示中の版と公開中の版を比較し、異なる場合に再取得する仕組みが有効です。
通信が不安定な現場で利用するため、閲覧データを端末内へ保存する機能がある場合にも注意します。圏外や低速回線でも点群OBJを確認できる点は便利ですが、保存済みデータとサーバー上の新版をどのように同期するかを決めておかなければなりません。
通信が回復した際に自動で更新確認を行うのか、利用者が更新操作を行うのか、旧版を残すのかを明確にします。自動更新を行う場合でも、作業中に突然モデルが切り替わると混乱する可能性があります。更新があることを通知し、利用者が適切なタイミングで再読み込みできる設計が望ましいでしょう。
表示アプリ本体のプログラムが旧版のまま残る場合もあります。アプリ本体が以前の取得方法やキャッシュ制御を使用していると、サーバー上のOBJが更新されても古い読み込み処理が続く可能性があります。
このような場合は、表示アプリ本体の版と、モデルデータの版を分けて管理します。アプリ本体が更新されたときは画面全体を更新し、モデルだけが更新されたときは対象データだけを再取得する仕組みにすると、不要な再読み込みを減らせます。
ブラウザのHTTPキャッシュを削除しても直らない場合には、表示アプリがどのデータをメモリ、Cache Storage、IndexedDB、独自領域などへ保存しているかを確認することが重要です。
キャッシュ対策5 OBJ関連ファイルを版単位で管理する
キャッシュ対策を安定して運用するには、OBJファイルを単体で上書きする方法から、版単位で管理する方法へ切り替えることが有効です。
複数の担当者が点群OBJを修正する現場では、同じファイル名で上書きを続けると、どのデータが最新版か分からなくなります。キャッシュが残っているのか、古いファイルを誤ってアップロードしたのか、公開先が違うのかを判断しにくくなります。
版管理では、作業中、確認中、公開中といった状態を分けます。アップロード直後のデータをすぐ全利用者へ公開するのではなく、確認用の状態で表示します。
形状、座標、材質、テクスチャ、容量、読み込み状態などを確認し、問題がなければ公開中の版として切り替えます。確認前のOBJが利用者へ表示されることを防げるほか、不具合が見つかった際に旧版へ戻しやすくなります。
管理画面では、ファイル名だけでなく、版番号、更新日時、登録者、容量、関連ファイル、公開状態などを確認できるようにします。ファイル名が同じでも、版番号が異なれば別データとして追跡できます。
可能であれば、OBJの内容から生成したハッシュ値も記録します。修正後に再アップロードしたつもりでも、更新前後のハッシュ値が同じであれば、同じ内容のファイルを選んでいる可能性があります。
一方、ハッシュ値が異なるのに表示が変わらない場合は、保存先や配信経路、表示アプリのキャッシュを重点的に調べられます。このように、版情報は原因の切り分けにも役立ちます。
外部へ共有するURLについても、最新版を表示するURLと、特定の版を表示するURLを分ける方法があります。日常的な確認では最新版URLを利用し、検査記録や報告資料には特定版のURLを残します。
最新版URLは公開中の版へ自動的につながる設計にできるため、更新後も同じ共有先を使えます。一方、特定版URLは後から見ても同じ状態を確認できるように設計できるため、記録性を高められます。
旧版を削除するときは、公開先から削除することと、履歴として保管することを分けて考えます。旧版を公開領域へ置いたままにすると、以前のURLから誤って閲覧される可能性があります。
履歴として残す場合は、通常の閲覧先とは異なる保管場所へ移します。必要な保管期間、閲覧権限、削除方法を決め、誤参照されない状態で保存します。
版単位の管理を行うと、キャッシュを全面的に無効化しなくても、新版を異なるデータとして取得させやすくなります。更新速度、表示速度、履歴管理を両立するための基本的な対策です。
キャッシュ以外の原因を切り分ける方法
点群OBJアップロード後に旧データが表示されたとしても、必ずしもキャッシュが原因とは限りません。元ファイルの保存漏れ、アップロード先の間違い、表示対象の選択ミス、変換処理の未完了などでも、似た現象が起こります。
最初に、アップロード前のOBJをローカル環境で確認します。今回修正した部分が本当に保存されているかを見ます。不要部分を削除した場合は、その形状が消えているかを確認します。頂点位置を変更した場合は、座標や基準となる形状との位置関係を確認します。
元ファイルが古いままであれば、キャッシュを削除しても表示は変わりません。修正作業に使用したデータと、アップロード時に選択したデータが同じかを確かめます。
保存日時とファイル容量も確認材料になります。ただし、座標値の一部だけを修正した場合、ファイル容量がほとんど変わらないことがあります。容量だけで新版と旧版を判断せず、内容、版番号、ハッシュ値なども確認します。
次に、アップロード先を確認します。案件名やフォルダが似ていると、別の保存先へアップロードしてしまうことがあります。アップロード画面では新版が登録されていても、閲覧画面が別案件のOBJを開いていれば、古いデータが表示されます。
表示用URLに含まれる案件識別子や版番号が確認できる場合は、想定したデータを参照しているかを調べます。共有された古いURLを開いているだけであれば、キャッシュを削除しても、そのURLが指す旧版が正しく表示され続けます。
アップロード後に変換処理が行われる場合は、処理状態も確認します。元のOBJを表示用の軽量データへ変換するシステムでは、原本が新版でも、表示用データが旧版のままということがあります。
変換処理が失敗していると、システムが直前の正常な表示データを残す設計になっている場合もあります。利用者から見ると旧データがキャッシュされているように見えますが、実際には新版の表示用データが生成されていません。
アップロード完了、変換完了、公開完了を分けて確認できるようにすると、どの段階で止まっているかを判断しやすくなります。
複数の端末や通信環境で同じURLを確認することも有効です。一台だけ旧版なら端末側、全端末で旧版なら公開側、特定の通信経路だけ旧版なら中継部分というように、確認結果から原因を絞れます。ただし、複数の要因が同時に存在する可能性もあるため、結果だけで断定せず、応答ヘッダー、版番号、取得ログなどを合わせて確認します。
キャッシュ対策を行う前に、元ファイル、保存先、版番号、処理状態、閲覧URLを確認することで、不要な削除作業を減らせます。
OBJ・MTL・テクスチャをまとめて更新する重要性
点群OBJの中には、頂点や面の情報だけで表示できるものもありますが、材質や画像を組み合わせて表示するものもあります。この場合、OBJだけを更新しても、見た目が完全には変わらないことがあります。
OBJには、参照するMTLファイルを示す記述や、使用する材質名を示す記述を含めることができます。MTLには、色や表面特性、テクスチャ画像の参照先などを記録できます。ただし、OBJやMTLの機能への対応範囲は表示ソフトによって異なるため、利用するシステムの仕様確認が必要です。The Library of Congress+2ウィキペディア+2
形状を変更したOBJをアップロードしても、MTLが以前の構成を前提にしていれば、材質の割り当てが正しく反映されない可能性があります。オブジェクト名や材質名を変更した場合は、OBJとMTLの記述が一致しているかを確認します。
テクスチャ画像だけを差し替えた場合も注意が必要です。同じ名前の画像を上書きすると、画像キャッシュから旧版が表示されることがあります。
画像名を変更した場合は、MTL内の参照先も同時に変更します。画像を新版へ更新しても、MTLが旧画像の名前を参照していれば、外観は変わりません。
OBJ、MTL、テクスチャを別々のタイミングで公開すると、新旧ファイルが混在する可能性があります。OBJだけ新版、MTLは旧版、画像はさらに以前の版という状態になると、表示結果の予測が難しくなります。
関連ファイルは一つの更新単位として扱います。新版用の保存先へOBJ、MTL、画像をすべて転送し、必要なファイルがそろったことを確認してから、閲覧側の参照先を切り替えます。
この方法なら、転送途中の不完全な組み合わせを利用者が読み込むことを防ぎやすくなります。新しい版に問題が見つかった場合も、参照先を以前の一式へ戻せます。
ファイル名の大文字と小文字、拡張子、相対的な保存位置にも注意が必要です。作業端末のファイルシステムでは同じ名前として扱われても、アップロード先では大文字と小文字を区別し、別ファイルとして扱う構成があります。
画像が見つからない場合に、以前保存された画像だけが表示されると、キャッシュ問題と区別しにくくなります。関連ファイルが正しい場所にあり、OBJやMTLの参照文字列と一致しているかを確認します。
テクスチャを使用しない点群OBJでも、色分け条件、点の大きさ、表示範囲、レイヤー状態などがアプリ側へ保存されている場合があります。OBJ内のデータだけでなく、表示設定の更新有無も確認する必要があります。
点群OBJアップロード後の確認手順
キャッシュ問題を再発させないためには、アップロード後の確認手順を決めておくことが重要です。担当者の経験だけに頼ると、確認する場所や判断基準が人によって変わります。
最初に、アップロード対象のOBJをローカル環境で開きます。修正した部分が保存されているかを確認し、ファイル名、版番号、更新日時、関連ファイルの組み合わせを整理します。
次に、確認用の状態でアップロードします。アップロード完了後は、管理画面に表示される版番号、容量、登録日時、登録者などを確認します。想定したファイルが登録されたことを確かめてから、表示確認へ進みます。
表示画面では、モデル全体が開くことだけでなく、今回修正した箇所を重点的に確認します。削除した形状が残っていないか、移動した頂点が正しい位置にあるか、面を含むデータでは面の向きが乱れていないか、材質が対応しているかを見ます。
座標を変更した場合は、周辺データや既知の基準との位置関係も確認します。旧データが表示されていると、修正した座標と以前の座標の差が確認できないため、変更内容を事前に記録しておくと判断しやすくなります。
テクスチャを更新した場合は、画像の内容だけでなく、向き、拡大率、継ぎ目、材質との対応も確認します。形状だけが新版になり、画像が旧版のままという状態を見逃さないようにします。
通常利用する環境で確認した後、既存のサイトデータを引き継がない別の閲覧環境や別端末でも確認します。両方で同じ新版が表示されれば、端末固有のキャッシュ問題が発生している可能性は下がります。
公開切り替え後には、確認用URLではなく、実際に利用者へ共有する公開URLを開きます。確認環境では新版でも、公開用の配信経路に旧キャッシュが残っていることがあるためです。
複数の担当者が確認する場合は、「表示できた」という記録だけで終わらせません。確認した版番号、日時、URL、修正箇所、端末や通信環境を残します。これにより、後から別の担当者が旧版を見たときも、参照先や環境の違いを確認できます。
問題がなければ公開状態へ切り替えます。旧版はすぐ削除せず、必要な期間だけ戻せる状態で保管します。ただし、通常の公開領域へ残すと誤参照の原因になるため、履歴用の保管場所を分けます。
この一連の手順を標準化すれば、点群OBJアップロード後の表示確認を効率化でき、キャッシュ以外の不具合も早期に発見しやすくなります。
キャッシュ対策で避けたい運用
キャッシュ問題が起こるたびに、すべてのキャッシュを無効化する運用は避けた方がよいでしょう。旧データは残りにくくなりますが、点群OBJを開くたびに大容量の通信が発生しやすくなります。
現場の通信環境によっては、表示までの待ち時間が長くなり、確認作業が進みにくくなる可能性があります。複数の担当者が同じデータを閲覧すれば、サーバー側の負荷や配信量も増えます。
キャッシュを使わないのではなく、更新時だけ新版を取得し、変更されていないデータは再利用できる仕組みが適しています。
同じファイル名を上書きし続け、表示が変わらなければ利用者へ削除操作を依頼する方法も、恒常的な運用には向きません。担当者ごとに端末設定が異なり、操作を正確に統一しにくいためです。
削除対象を誤ると、ログイン状態や別業務の保存内容まで失われる可能性があります。利用者側の手作業だけに頼らず、版番号、URL、検証情報などによって新版へ切り替えることが望ましいでしょう。
アップロード完了の表示だけを見て、すぐに再アップロードを繰り返すことも避けます。変換処理や公開転送が続いている場合、複数の処理が重なり、最終的にどの版が公開されたのか分からなくなることがあります。
処理中、確認待ち、公開済みといった状態を確認し、一つの版の処理が終わってから次の操作を行います。
OBJだけを確認して作業を終えることにも注意します。MTLやテクスチャ画像が旧版なら、形状は新しくても見た目が以前と同じになる場合があります。関連ファイルを含めて一式で確認することが必要です。
旧データが見えた際に、すぐキャッシュだと決めつけるのも危険です。アップロードした元ファイルが古かった、別の案件へ保存していた、表示用の変換に失敗したといった可能性もあります。
キャッシュ削除を始める前に、元ファイル、保存先、版番号、閲覧URL、処理状態を確認します。原因を順番に切り分ければ、不要な作業を減らせます。
端末の再起動だけで解決し、原因を記録しない運用も再発防止にはつながりません。どの操作で表示が切り替わったかを残し、必要に応じてシステム側の設定を改善します。
まとめ
点群OBJアップロード後に旧データが残る場合は、ブラウザのHTTPキャッシュだけでなく、サーバー、配信経路、サービスワーカーやアプリ独自の保存領域、関連ファイル、版管理まで確認する必要があります。
一つ目の対策は、OBJを更新するたびにURLや更新識別子を変えることです。新版を旧版とは異なるデータとして扱わせることで、利用者側の手動操作を減らせます。ただし、クエリ文字列がキャッシュキーへ含まれるかは配信設定によるため、実環境での確認が必要です。
二つ目の対策は、ブラウザ側の保存データを適切に更新することです。通常の再読み込みだけで変化しない場合は、強制再読み込み、対象サイトのHTTPキャッシュ、Cache Storage、オフラインデータなどを段階的に確認します。
三つ目の対策は、サーバーや配信経路のキャッシュ条件を、OBJの更新方法に合わせることです。同じURLを上書きする場合は再検証情報を適切に更新し、版ごとにURLを変える場合は変更されていないデータを効率よく再利用します。
四つ目の対策は、表示アプリ内部に残るモデルや独自キャッシュを更新することです。画面上で非表示にするだけでなく、旧モデルを内部から破棄し、新しい版を読み込む必要があります。
五つ目の対策は、OBJ、MTL、テクスチャ画像を版単位で管理することです。関連ファイルを一式で公開し、確認中と公開中の状態を分けることで、新旧データの混在を防ぎやすくなります。
点群OBJの更新では、同じファイル名を上書きし続け、問題が起きるたびにキャッシュを削除する方法だけに頼らないことが重要です。更新版を明確に識別し、関連ファイルをそろえて公開し、実際の共有URLで確認する運用を整えます。
アップロード後は、表示できるかだけでなく、修正箇所、座標、形状、材質、テクスチャ、版番号まで確認します。確認結果を記録しておけば、旧データが表示されたときも、端末側、配信側、ファイル管理のどこに原因があるかを切り分けやすくなります。
現場で取得した点群をOBJとして整理し、計測から確認、共有までの作業を効率化する際には、位置情報を活用できるLRTK Phoneを取り入れた運用も検討できます。