点群OBJのアップロードで使われる署名付きURLとは
点群から生成したOBJや、OBJに関連するMTL、テクスチャ画像をクラウドへアップロードするとき、ブラウザや業務用アプリから保存領域へ直接ファイルを送信する仕組みが使われることがあります。その際、利用者の端末へ保存領域の恒久的な認証情報を渡さず、特定の対象と操作に限った一時的な権限を付与するために利用されるのが署名付きURLです。
署名付きURLには、一般にアップロード先、対象オブジェクト、許可する通信方法、有効期限、署名の検証に必要な情報などが含まれます。構成によっては、送信時に使うヘッダー、ファイルの種類、チェックサムなども署名条件に含まれます。利用者は発行されたURLを使い、条件が有効な間に指定された要求を送信します。
署名付きURLは、その文字列を知っている者が有効期間内に利用できる一時的な認証情報として扱う必要があります。画面、操作記録、問い合わせ文、アクセスログなどへURL全体を不用意に残すと、期限内に第三者が利用するおそれがあります。そのため、必要な操作の直前に発行し、不要になった値を長期間保存しない設計が基本です。
点群OBJでは、一般的な文書や小さな画像よりも期限管理が難しくなる場合があります。点群から細かなメッシュを生成すると、頂点、面、法線、テクスチャ座標などの記述量が増え、OBJ本体が大きくなりやすいためです。さらに、材質情報を記録するMTLや、一枚または複数枚のテクスチャ画像を伴うことがあります。
利用者から見ると一つのモデルをアップロードしているように見えても、内部ではOBJ、MTL、画像を別々の要求として送信している場合があります。大容量ファイルを複数の部分へ分ける方式では、各部分の送信、完了確認、全体の確定処理も別の要求になります。署名付きURLが要求単位で必要な構成では、後から開始する要求ほど期限切れの影響を受けやすくなります。
また、画面を表示した時刻と実際に送信を始める時刻は一致しません。画面の初回表示時にURLを発行すると、利用者がファイルを探す時間、関連ファイルを確認する時間、容量検査やハッシュ計算を行う時間にも有効期間が消費されます。
点群 OBJ アップロードを安定させるには、単純に有効期限を長くするだけでは不十分です。ファイル容量、関連ファイル数、通信環境、署名を発行する時点、署名に使う認証情報の有効期間、再試行方法、分割送信の状態管理、アップロード後の整合性確認まで含めて設計する必要があります。
署名付きURLの期限切れで起こる症状
署名付きURLが期限切れになると、アップロード開始直後に拒否される、途中の再試行だけ失敗する、OBJは成功したのにMTLやテクスチャ画像が失敗するなど、複数の症状が現れます。
画面を開いてから長時間が経過した後、アップロードボタンを押した直後にエラーになる場合は、事前に取得したURLが送信開始前に期限切れになった可能性があります。ファイルを選び直しても同じURLを保持する実装では、操作を繰り返しても同じエラーが続きます。
進捗表示が途中まで進んだ後に止まる場合もあります。ただし、ここでは「転送中に有効期限を過ぎたため、必ずその瞬間に切断された」と断定できません。保存サービスや方式によっては、単一のHTTP要求が有効期間内に開始されていれば、転送中に時刻を過ぎてもその要求が継続することがあります。一方、通信切断後の再試行、分割アップロードの次の部分、完了確定の要求などが期限後に開始されると拒否されることがあります。
したがって、途中停止に見える症状では、ファイル全体を一度に送っていたのか、複数の部分へ分けていたのか、停止直前に再接続や再試行が発生したのかを確認する必要があります。単に進捗率だけを見ても、期限切れの判定時点は分かりません。
OBJ本体だけ成功し、MTLやテクスチャ画像が失敗する症状も典型的です。すべてのファイル用URLを最初にまとめて発行し、OBJの送信に長い時間がかかると、後から使用するURLの残り時間が不足します。この場合、モデル本体が保存されていても、材質や色が反映されない、変換処理が関連ファイル不足で停止するなどの問題につながります。
画面を再読み込みすると成功する場合は、再読み込みによって新しいURLが発行された可能性があります。ただし、再読み込みで選択ファイル、入力内容、アップロード済み部分の情報が失われる設計では、利用者の負担が大きくなります。期限切れを検知して新しいURLを取得し、必要な範囲だけを安全に再送できる仕組みが望まれます。
表示されるエラーが必ず「期限切れ」と明示されるとは限りません。アクセス拒否、署名不一致、要求失敗などの一般的な文言にまとめられることがあります。同じ症状は、権限不足、送信方法の不一致、署名対象ヘッダーの違い、ファイル容量制限、ログイン切れ、通信障害でも起こります。
そのため、期限切れは画面表示だけで断定せず、署名発行時刻、表示上の有効期限、署名に利用した認証情報の期限、送信開始時刻、各要求の失敗時刻、再試行の有無、保存先から返されたエラー情報を組み合わせて判断します。
原因1 有効期限がアップロード時間より短い
第一の原因は、署名付きURLを実際に利用できる残り時間が、送信開始までの待ち時間やアップロード処理に対して不足していることです。
容量の小さい確認用ファイルでは成功するのに、現場で取得した大容量データでは失敗する場合、この原因が候補になります。確認用ファイルの成功だけを基準にすると、本番データの容量、関連ファイル数、通信速度の変動、再試行に必要な時間を見落とします。
OBJは、頂点座標、面を構成する頂点番号、法線、テクスチャ座標などをテキストで記述することが多く、細かなメッシュほど容量が増えやすくなります。色付きモデルでは、OBJ本体だけでなく、MTLとテクスチャ画像を含む合計容量で考える必要があります。
アップロード時間はファイル容量だけでは決まりません。利用者側の継続的な上り速度、無線環境、回線の混雑、社内ネットワークの制御、端末の処理負荷、ブラウザの省電力制御などによって変化します。事務所で短時間に完了するデータでも、建設現場や山間部では長くかかることがあります。
必要時間を見積もるときは、回線契約上の最大速度ではなく、実際に継続して利用できる上り速度を基準にします。容量を速度で割った理論値だけではなく、送信準備、通信速度の低下、接続の揺らぎ、再試行の余裕を加えます。
もう一つ見落としやすいのが、URLを発行してから送信を開始するまでの時間です。画面表示時に発行する構成では、利用者がファイルを選択し、OBJとMTLの参照を確認し、テクスチャを探し、アップロード操作を行うまでの時間も有効期間に含まれます。
さらに、表示上の有効期限より早く使えなくなる構成もあります。署名を一時的な認証情報や短いセッションで生成している場合、署名付きURLに長い期限を設定しても、署名元の認証情報が先に失効するとURLも利用できなくなることがあります。管理ポリシーや鍵の無効化によって利用できなくなる場合もあるため、URLに表示した期限だけを見て判断しないことが重要です。
この問題を防ぐには、ファイルの容量確認、関連ファイルの検査、ハッシュ計算などを先に済ませ、送信準備が整ってからURLを取得します。複数ファイルを順番に送る場合は、全ファイル用URLを早い段階でまとめて取得するのではなく、使用する直前または一定数のまとまりごとに取得する方法が有効です。
ただし、有効期限を必要以上に長くするだけの対策は適切ではありません。署名付きURLは一時的な操作権限を持つため、漏えいした場合の利用可能時間も長くなります。想定する最大規模、通信環境、再試行方式を踏まえて必要な余裕を確保しながら、利用目的に対して過度に長くしないことが重要です。
原因2 OBJ関連ファイルの送信順序と待ち時間を考慮していない
第二の原因は、OBJ、MTL、テクスチャ画像の送信順序と、各要求が開始されるまでの待ち時間を考慮せずにURLを発行していることです。
点群から生成したモデルは、OBJだけで構成される場合もありますが、材質情報を持つ場合はMTLを伴い、MTLから複数の画像を参照することがあります。画面で一つのフォルダーや圧縮ファイルを選択しても、内部では関連ファイルを取り出し、別々の要求として保存する場合があります。
すべてのURLを同時に発行すると、後から使うURLほど実際の利用開始までの待ち時間が長くなります。OBJ本体の送信だけで長い時間を使うと、その間にもMTL用URLや画像用URLの有効期間が減少します。
送信前の処理時間にも注意が必要です。ファイル名の検査、拡張子の判定、重複確認、容量計算、ハッシュ計算、圧縮ファイルの展開などをURL取得後に行うと、通信が始まる前から有効期間を消費します。大容量ファイルでは、端末側の検査だけでも無視できない時間がかかる場合があります。
分割アップロードでも同様です。各部分に個別の署名付きURLを使う方式では、後半の部分を送信する時点で、そのURLが期限切れになっていることがあります。また、各部分の送信が成功しても、最後に全体を確定する要求へ別の認証が必要な構成では、確定処理の期限も確認する必要があります。
対策として、各ファイルまたは各部分を送信する直前に、必要なURLを取得します。OBJの送信後にMTL用URLを取得し、その後に画像用URLを取得する構成であれば、後続ファイルの待ち時間による期限消費を抑えられます。
URL取得回数を抑えたい場合は、OBJとMTL、次に一定数の画像というように、使用時点が近い要求をまとめて発行します。どの単位が適切かは、ファイル数、取得APIの負荷、通信速度、再発行のしやすさによって決めます。
アップロード全体の完了判定も重要です。OBJだけ保存できた段階で完了とせず、必要なMTLとテクスチャがそろい、参照名が一致し、モデル単位の検証が終わってから完了状態へ切り替えます。
原因3 古い署名付きURLを再利用している
第三の原因は、以前に発行した署名付きURLをブラウザやアプリが保持し、失効後も再利用していることです。
同じ保存先へ同じ操作を許可するURLであっても、再発行ごとに署名情報や期限が変わる場合があります。サーバーが新しいURLを返しても、実際の送信処理が古い値を参照していれば、期限切れは解消しません。
よくあるのは、画面表示時にURLを取得し、その値を画面の状態として保持し続けるケースです。利用者が別作業を行い、しばらくしてから送信すると、保持していたURLはすでに失効している可能性があります。
失敗後の自動再試行にも注意が必要です。同じ要求を同じURLへ繰り返すだけでは、期限切れURLを再利用し続けます。期限切れが疑われる場合は、まず新しいURLを取得し、送信処理そのものを更新後の値で作り直します。
処理を作成した時点のURLを内部に固定する実装では、画面上の変数だけを書き換えても古いURLが使われることがあります。再発行後に新しい要求を生成し、古い要求を停止する必要があります。
作業再開機能でURLそのものを端末へ保存している場合も問題になります。翌日や数時間後に復元したURLは、通常、再利用に適しません。保存するのはアップロード管理番号、ファイル識別情報、完了した部分の番号、必要なチェックサムなどにとどめ、再開時には新しい認証情報を取得します。
署名付きURLを返すAPIの応答がキャッシュされる設計にも注意します。キャッシュを許可する応答設定になっていたり、アプリ側が同じ応答を再利用したりすると、新しいURLを要求したつもりでも古い値を受け取ることがあります。署名発行APIは一時的な認証情報を返すため、通常の静的情報とは分け、再利用されない応答制御を行います。
古いURLの再利用を防ぐ基本は、署名付きURLを恒久的な保存先として扱わないことです。ファイルまたは部分との対応、発行時刻、実効期限、利用済み状態を管理し、失効後や再試行時には新しい値へ確実に切り替えます。
署名付きURLを更新する基本手順
署名付きURLが期限切れになった場合、通常はURL文字列の期限部分だけを書き換えて利用することはできません。期限、対象操作、保存先、署名対象の情報をもとに検証されるため、権限を持つサーバー側で新しいURLまたは新しいアップロード用情報を発行します。
最初に、アップロード対象が現在も有効か確認します。対象プロジェクト、モデルの版、保存先、利用者権限、ファイル名、ファイル容量、アップロード管理番号が、最初に発行した時点から変わっていないかを確認します。
次に、古いURLではなく、アップロード管理番号やファイル識別情報を使って再発行を要求します。URL自体を業務上の識別子として扱うと、ログや画面へ一時認証情報が広がりやすくなるため避けます。
新しいURLを受け取ったら、対象ファイルまたは対象部分との対応を確認します。OBJ用、MTL用、画像用、分割部分用のURLを取り違えると、有効期限内でも保存先や署名条件が一致せず拒否されます。
再送信の範囲は、アップロード方式によって異なります。単一要求でファイル全体を送る方式では、失敗した要求を最初からやり直すのが基本です。分割アップロードや再開可能な方式では、保存サービスが認識している完了済み部分を確認し、同じアップロードセッションへ未完了部分を送れる場合があります。
ここで重要なのは、単に新しいURLを発行すれば必ず途中から再開できるわけではないことです。再開には、アップロードID、セッション情報、部分番号、完了済み部分の識別情報などが必要です。方式によっては署名付きURLではなく、開始処理で発行された専用のセッション情報を使って再開します。
送信後は、保存先に同名のファイルが見えることだけで完了と判断しません。単一要求が失敗した場合に不完全なオブジェクトが通常の完成ファイルとして見えるとは限らず、分割方式では完了前の部分が内部的に保持されても、全体のオブジェクトとして利用できない場合があります。
そのため、完成したオブジェクトの容量、チェックサム、部分数、完了確定の結果を確認します。OBJ関連ファイルがある場合は、モデル単位で必要なファイルがそろっていることも検証します。
再発行時には、古い送信処理を停止します。新旧の処理が並行すると、同じ保存先への競合、重複送信、古い版による上書きが起きる可能性があります。処理ごとに版や世代を持たせ、最新の処理だけを完了として採用すると管理しやすくなります。
アップロード開始前に期限切れを防ぐ方法
期限切れ後の再送だけでなく、送信開始前に残り時間の不足を検知する仕組みを用意すると、利用者のやり直しを減らせます。
署名発行サーバーは、URLとともに発行時刻、利用可能期限、サーバー時刻、アップロード管理番号などを返す構成にできます。ブラウザ側では送信開始時に残り時間を確認し、余裕が不足していれば新しいURLを取得します。
ただし、残り時間が推定送信時間より短いかだけで機械的に判断すると、保存サービスの判定仕様と合わないことがあります。単一要求では開始時点の有効性が重視される場合がある一方、再試行や後続部分は別要求として有効期限内に開始する必要があります。
そのため、安全側の設計として、送信開始までの待ち時間、想定される再試行、後続要求の数を考慮します。特に複数ファイルや分割部分を順番に送る場合は、最後の要求が開始される時点まで十分な余裕があるか確認します。
推定時間には、ファイル容量と最近の上り速度を利用できます。ただし、通信速度は変動するため、短時間の測定結果をそのまま使わず余裕を持たせます。初回で速度情報がない場合は、実際の現場利用を想定した保守的な値を使います。
利用者が画面を長時間開いたままにしていた場合、アップロードボタンを押した時点で再確認します。画面が非表示になった後、端末が省電力状態から復帰した後、通信接続が切り替わった後にも確認すると安全です。
端末時計がずれていると、ブラウザ側の残り時間計算が不正確になります。サーバー時刻と期限を返し、その差分を利用する方法や、送信直前にサーバーへ有効性を問い合わせる方法が考えられます。
ファイル検査やハッシュ計算は、可能な限りURL取得前に済ませます。準備が整った後に署名を発行し、発行から要求開始までの時間を短くすることが基本です。
アップロード途中で期限切れになった場合の対応
大容量の点群OBJでは、通信速度の急低下、無線の切断、端末の休止、再試行によって、アップロード途中に期限切れが表面化することがあります。
単一要求で送る方式では、要求開始時にURLが有効であれば、転送中に期限時刻を過ぎても継続できる構成があります。しかし、通信が切断され、期限後に同じ要求を再開しようとすると失敗することがあります。保存サービスや実装により挙動が異なるため、途中失敗を一律に「転送中の期限判定」と説明しないことが重要です。
単一要求が失敗した場合は、新しいURLを取得し、ファイル全体を再送するのが基本です。失敗した要求で送られた途中データを、そのまま完成オブジェクトとして利用できると想定しないようにします。
容量の大きなファイルでは、分割アップロードや再開可能な方式が有効です。正常に送信できた部分を保存サービス側で確認できれば、新しい認証情報を取得した後、未完了部分だけを送れる場合があります。
分割方式では、アップロードID、部分番号、各部分の結果、チェックサムなどを管理します。画面側だけで完了状態を持つと、再読み込みや端末終了で情報が失われます。サーバー側にも管理番号と状態を保存し、保存サービス側の状態と照合できるようにします。
未完了の分割アップロードでは、完成オブジェクトになる前の部分が保存領域に残る場合があります。これらは通常の完成ファイルとして利用できない一方、放置すると管理上の負担や保存容量の消費につながることがあります。再開しない処理は明示的に中止し、古い未完了処理を定期的に整理します。
期限切れを検知した場合は、同じURLで無制限に再試行しません。新しいURLの取得、送信処理の再作成、未完了範囲の確認という順序で進めます。
自動再試行には回数と時間の上限を設けます。権限不足や署名条件の不一致を期限切れと誤判定すると、再発行と再送を繰り返しても解決しません。一定回数で停止し、どの段階で何が拒否されたかを管理者が確認できる状態にします。
再試行中は重複操作も防ぎます。URL更新中、送信中、完了確認中などの状態を画面で管理し、利用者がアップロードボタンを繰り返し押して複数処理を起動しないようにします。
OBJとMTLとテクスチャを安全にアップロードする設計
点群OBJのアップロードでは、OBJ本体が保存されただけではモデル全体の成功とはいえません。MTLやテクスチャが不足すると、色や材質が反映されず、変換処理が失敗する場合があります。
関連ファイルごとにURLを発行する場合は、ファイル名、役割、容量、チェックサム、版、保存先、URLの対応関係を明確に管理します。配列の順番だけで対応させると、並べ替えや再試行の際に別ファイル用URLを使う危険があります。
各ファイルに識別情報を付け、OBJ、MTL、各画像を個別に管理します。一部のファイルだけ再送する場合も、どのモデル版に属するファイルかを確認します。
同時に発行したURLでも、実効期限が同じとは限りません。発行処理の差、署名元の認証情報、管理ポリシーなどにより、利用可能時間が異なる場合があります。各要求を使う直前に有効性を確認する設計が安全です。
MTLに記録されたテクスチャ参照名と、実際に保存した画像名が一致していることも必要です。期限切れを直しても表示できない場合は、参照名、文字の大小、使用可能な文字、相対的な配置、画像形式などを確認します。
異なる版のファイルを混在させないことも重要です。新しいOBJへ古いMTLや画像を組み合わせると、参照関係が崩れる可能性があります。モデル単位で版番号やアップロード管理番号を持たせ、同じ版に属する関連ファイルだけを確定します。
モデルの状態は、準備中、送信中、検証中、変換中、完了、失敗などに分けます。OBJだけ成功した途中状態を完成扱いせず、必要な関連ファイルがそろい、整合性検証が終わってから変換処理や公開処理へ渡します。
期限切れと権限エラーを見分ける確認方法
署名付きURLによるアップロードが失敗しても、原因が必ず期限切れとは限りません。権限不足、要求方法の違い、署名対象ヘッダーの不一致、ファイル容量制限、認証セッションの終了、通信切断でも似た症状が起こります。
期限切れを判断する材料の一つは、新しいURLを発行すると、同じ条件の要求が成功することです。発行直後は成功し、一定時間が経過すると失敗する場合は、有効期限や古いURLの再利用が関係している可能性があります。
新しいURLを取得した直後でも毎回失敗する場合は、期限以外を確認します。アップロード用として許可された方法を使っているか、署名時に含めたヘッダーと実際の要求が一致しているか、ファイルの種類やチェックサムが条件と合っているかを調べます。
小容量ファイルは成功し、大容量ファイルだけ失敗する場合は、有効期限だけでなく、容量制限、通信タイムアウト、端末負荷、分割設定も候補になります。毎回ほぼ同じ経過時間で失敗する場合でも、URL期限、通信機器のタイムアウト、アプリ側の制限など複数の可能性があります。
OBJは成功し、MTLや特定画像だけ失敗する場合は、そのファイルに対応するURL、送信順序、要求条件、ファイル名、容量を個別に確認します。モデル全体を一つの原因で説明しようとせず、要求単位で結果を整理します。
調査時には、アップロード管理番号、ファイル識別情報、発行時刻、表示上の期限、署名元認証情報の期限、送信開始時刻、失敗時刻、送信済み容量、再試行回数、保存先のエラー分類を記録します。
利用者向け表示と管理者向け情報は分けます。利用者には再試行、再認証、通信確認など次の操作を示し、管理者には原因を切り分けられる情報を残します。
署名付きURL全体をエラー画面や通常ログへ記録することは避けます。必要な場合でも、クエリ部分を伏せる、識別用の短い値だけを記録するなど、一時認証情報が広がらない形にします。
サーバー側で確認したい署名生成の設定
期限切れが繰り返される場合は、署名を発行するサーバー側の設定を確認します。
最初に、有効期限の計算方法を確認します。現在時刻への加算、秒と分とミリ秒の単位、協定世界時と現地時刻の変換、開始時刻と終了時刻の扱いが処理間で一致しているかを調べます。
署名元の認証情報の期限も確認します。一時認証情報や短いセッションで署名している場合、URLへ指定した期限より先に署名元が失効すると、URLの実効期限も短くなることがあります。鍵の無効化や権限変更が影響する構成もあります。
サーバー時計のずれにも注意します。複数サーバーで署名を発行している場合、特定のサーバーを通った要求だけ失敗するなら、時刻差や設定差が候補です。時刻同期を行い、発行時刻と保存先判定の差を小さくします。
開始時刻を明示する方式では、時刻差によって発行直後のURLがまだ有効ではないと判定されることがあります。即時利用が目的なら、使用する保存環境の仕様に合わせて開始時刻の設定方法を見直します。
署名時に許可した操作と、実際の要求方法が一致していることも必要です。読み出し用URLをアップロードへ使う、アップロード用URLを別の方法で送ると、有効期限内でも拒否されます。
署名対象へヘッダー、ファイル種類、チェックサムなどを含めている場合は、ブラウザが実際に送る値と一致させます。画面側で自動追加または変更されるヘッダーが署名不一致の原因になる場合があります。
URL再発行には利用者の認証と権限確認が必要です。ログイン状態が切れて新しいURLを取得できないのに、画面が古いURLで再試行し続けると、利用者には期限切れが直らないように見えます。ログイン期限と署名付きURLの期限を区別して扱います。
発行回数の制御も確認します。不正な大量発行を防ぎつつ、正常な再試行を一律に拒否しないよう、利用者、プロジェクト、アップロード処理ごとに適切な制限を設けます。
記録には、発行時刻、実効期限、対象ファイル、操作、アップロード管理番号、結果を残します。ただし、署名付きURL全体や秘密情報は不要に保存しません。
ブラウザ側で確認したいキャッシュと再試行の設定
ブラウザ側では、URLの取得時点、保存場所、応答キャッシュ、再試行時の更新処理を確認します。
画面の初回表示時に取得し、その後更新しない構成では、画面を開いている時間が長いほど期限切れが起きやすくなります。アップロード開始直前に取得するか、送信前に残り時間を確認して再発行します。
取得したURLを長期保存領域へ入れないことも重要です。画面を閉じた後に作業を再開する場合でも、URL自体ではなく、アップロード管理番号や完了状態を保存します。
署名発行APIの応答は、静的な設定情報と同じようにキャッシュさせない設計にします。サーバー側の応答制御と、アプリ側の取得処理の両方を確認し、新しい発行要求で古い応答が再利用されないようにします。
再試行では、新しいURLが実際の送信処理へ渡されていることを確認します。画面上の表示だけ更新しても、送信処理が作成時のURLを保持していれば、期限切れが続きます。
新しいURLの取得が完了した後に送信処理を作り直し、古い処理を停止します。複数ファイルを並行送信している場合は、どのファイルがどのURLを使っているかを個別に管理します。
並行数を増やすと全体時間を短縮できる場合がありますが、回線を分け合うことで一つ当たりの速度が低下することもあります。利用環境に合わせて同時実行数を調整し、後続要求の開始が遅れすぎないようにします。
画面が非表示になったときや端末が省電力状態になったとき、通信や処理が一時停止する場合があります。復帰後は経過時間、通信状態、URLの有効性を再確認します。
画面には、URL取得中、送信準備中、アップロード中、URL更新中、再送中、完了確認中などの状態を表示します。利用者が処理状況を理解できれば、重複操作や不要な再読み込みを減らせます。
点群OBJアップロードを安定させる運用ルール
システム設定だけでなく、実際の業務手順を整えることでも期限切れを減らせます。
アップロード画面を開く前に、対象ファイルを確定します。OBJ、MTL、テクスチャ画像を探しながら画面を長時間開くと、画面表示時に発行する構成では有効期間が減ります。
必要なファイルを作業用フォルダーへまとめ、ファイル名、参照関係、版を確認してから操作を始めます。不要ファイルを除外すると、検査時間と送信時間の短縮にもつながります。
通信環境も確認します。大容量OBJを不安定な回線で送信すると、速度低下や再接続によって再試行が増え、期限切れが表面化しやすくなります。
現場からの即時共有が必要な場合は、通信が不安定になることを前提に、分割送信、再開、再発行、未完了処理の整理を設計します。高速回線だけを前提にするのではなく、実際の利用場所で検証します。
同じモデルを複数人が更新する場合は、版管理が必要です。誰がどの版を送信しているかを共有し、一つの処理が完了する前に別版を同じ保存先へ確定しないようにします。
アップロード後は、保存成功の表示だけで完了と判断しません。OBJ、MTL、テクスチャがそろい、整合性検証、変換、プレビューまで正常に終わったかを確認します。
アップロード後の変換処理が、一時的な読み出し用URLを使う構成もあります。この場合、アップロードは成功していても、変換処理の開始が遅れたことで読み出し用URLが失効することがあります。送信と変換を別工程として記録し、どの段階で失敗したかを切り分けます。
期限切れが繰り返される場合は、画面の再読み込みだけを案内せず、対象容量、関連ファイル数、通信環境、画面を開いていた時間、発行から各要求開始までの時間、再試行の有無を記録します。
事前検証には、実運用に近いデータを使います。小容量の試験OBJだけでなく、想定最大規模のOBJ、多数の画像を含むモデル、低速または不安定な回線を使い、発行、送信、再試行、検証、変換、表示まで確認します。
有効期限を延長した場合は、安全面も見直します。URL全体を画面や共有資料へ残さないこと、不要な処理を停止すること、再発行時に権限を確認すること、未完了の分割処理を整理することが重要です。
まとめ
点群OBJの署名付きURLが期限切れになる主な原因は、実際に利用できる時間がアップロードに対して不足していること、関連ファイルや分割部分の送信順序と待ち時間を考慮していないこと、古いURLを再利用していることの三つです。
点群 OBJ アップロードでは、OBJ本体だけでなく、MTL、テクスチャ画像、ファイル検査、送信開始までの待ち時間、後続要求、再試行まで含めて期限を設計します。また、URLに設定した期限よりも、署名元の一時認証情報や管理ポリシーによって実効期限が短くなる場合があるため、発行側の条件も確認します。
単一要求が有効期間内に開始されていれば、転送中に期限時刻を過ぎても継続できる構成があります。一方、通信切断後の再試行、分割送信の次の部分、完了確定などは別要求となるため、開始時点で新しい認証情報が必要になる場合があります。途中停止を一律に「送信中に期限切れした」と断定せず、要求単位で調べることが重要です。
期限切れが起きた場合は、URL文字列を編集したり、同じURLで再試行を繰り返したりせず、サーバー側で新しいURLまたは再開用情報を発行します。新しい値が実際の送信処理へ渡されていることを確認し、古い処理を停止します。
大容量の点群OBJでは、分割アップロードや再開可能な方式を利用すると、失敗時の再送範囲を減らせます。ただし、途中から再開するには、アップロードID、部分番号、セッション情報などの状態管理が必要です。未完了部分が保存領域へ残る方式では、再開しない処理を中止し、放置しない運用も必要です。
期限切れと権限不足、署名条件の不一致、通信エラーは似た症状になります。発行時刻、実効期限、送信開始時刻、失敗した要求、再試行、ファイル容量、保存先のエラー情報を記録し、原因を切り分けてから設定を変更します。
LRTK Phoneで取得した現場データを点群やメッシュとして活用する場合も、取得後の変換、OBJ関連ファイルの整理、アップロード、検証、共有までを一つの流れとして設計することが重要です。実際のファイル規模と通信環境に合わせて署名の発行時点、再発行、再試行、完了判定を整えることで、点群OBJの共有を安定させやすくなります。