リモート素材パッケージに localhost が現れると、なぜ別のパソコンで開けなくなることがあるのか？

リモートパッケージの素材アドレスが localhost を指していると、別のパソコンでは受け取った人のマシンにリクエストしてしまう。制作者のパソコン上のサービスは ZIP と一緒に移動しないため、「自分のところで再生できる」だけでは他人も再生できる証拠にはならない。対処順は、実際のリクエスト先を確認し、アプリのドメインを照合し、再エクスポートし、別の端末で検証する。

本記事は DramaFork が整理したもので、現在のプロジェクトのエクスポートと素材受け渡しの実装説明に基づく調査方法である。以下の『霧港来信』、ポート、現象は架空の教学例であり、オンラインでの実測記録として扱ったものではない。

リモートリンクパッケージは依然として、解凍しパッケージ内の説明に従って開く必要があるプレイヤーパッケージである。動画などのリソースはサーバー側に残し、アプリドメイン配下の素材受け渡し入口を通して読み込む。プレイヤーページは開けるが最初の動画の読み込みに失敗する場合と、圧縮パッケージが解凍できない場合は、別種の問題である。

まず受け取った人が得たパッケージのバージョン、発生位置、ネットワークが利用可能か、ページに表示された元のメッセージを記録する。プレイヤーすら開いていないなら、まず README.txt に従って解凍と起動方法を確認する。タイトルと選択肢が見えていて動画だけ失敗しているなら、素材リクエストを調べる。位置を特定しないまま脚本、動画、ドメインを同時に変更してはいけない。そうしないとどの変更が効いたのか判断できなくなる。

確認するのは実際のリソースアドレスであり、本文中にこの単語が現れるかどうかではない。説明文がローカルテスト方法に言及していても、それはプレイヤーが本当にローカルリソースをリクエストしたことを意味しない。

架空の例では、制作者が自分のパソコンでポート 3000 のサービスを実行し、この環境からリモートパッケージをエクスポートした。パッケージ内の動画アドレスは localhost:3000 を使用している。制作者が開くとき、アドレスは自分のサービスを指す。受け取った人が開くとき、それは受け取った人のパソコン上のポート 3000 を指す。受け取った人が同じサービスを実行していなければ、動画を取得できない。

127.0.0.1 も同様にローカルループバックアドレスを表す。それを別のローカルポートに変えても、パソコンをまたいだ共有は解決しない。LAN アドレスは対応するネットワーク内で到達可能な端末しかカバーできない。公網出口 IP も、あるポートが外部から到達可能であることを単独では証明できない。正式な受け渡しでは、実際にデプロイされ受け取った人がアクセスできるアプリドメインを使用し、具体的な素材リクエストを検証すべきである。

この種の確認は、アドレスが誰を指すか、サービスが到達可能かに関心があり、受け取った人が自分のパソコンで創作環境全体を複製する必要はない。

現在のエクスポートパッケージには story.json、index.html、説明と起動ファイルが含まれる。テキストエディタでストーリーデータとプレイヤーページを確認し、localhost、127.0.0.1 を検索し、ヒットが動画その他の素材アドレスにあるかを確認できる。まず元のパッケージを保持し、検索しながら一括置換してはいけない。

ブラウザの開発者ツールに慣れているなら、再生時に失敗したリクエストのドメインと応答状況も確認できる。ドメイン、ノード位置、エラー種別を記録すればよく、公開フィードバックに受け渡し凭证付きの素材リンク全体を貼るのは避ける。

アプリのトップページが開けることは、すべての素材入口が正常であることを意味しない。トップページとある動画は別のリクエストであり、実際に失敗した位置に沿って確認を続けなければならない。

現在の実装はアプリのアドレスに基づいてリモート素材入口を生成する。アプリドメインを設定したなら、それが実際にデプロイされたサービスを指すことを確認すべきである。ローカルアドレスを見つけたら、まずプロジェクトを保守する人がデプロイドメインを照合し、その後再エクスポートする。古いパッケージにすでに書き込まれたアドレスは、プロジェクト設定を変更しただけでは自動更新されない。

パッケージ内のすべての localhost 文字列を直接あるドメインに置換することは勧めない。リソース入口はパスとアクセス凭证にも関わり、ホスト名だけ変えても新しいサービスが同じプロジェクトと素材を識別できる証明にはならない。再エクスポート後、新しいパッケージの実際のリクエストから、想定したドメインを使用していることを確認する。

新しいパッケージには区別できるバージョン名を付け、受け取った人にどれを使うか通知する。2 つのファイルがどちらも「最終版」という名前だと、受け取った人が依然として古いパッケージを開き、すでに修正した問題が再び現れる可能性がある。

創作サービスを実行していない端末を選び、新しいリモートパッケージを解凍し、説明に従って起動し、ネットワーク接続を保つ。少なくとも冒頭、1 つの選択点、選択後の次の動画を確認する。冒頭だけを検証すると、後続ノードの古いリソースアドレスを見落とす可能性がある。

結果を記録として書く。パッケージバージョン、端末とネットワーク、通った選択、読み込みに成功したか、失敗がどこで起きたか。記録は「未検証」と「検証済み」を分け、別の端末がないときはこの欠落を残し、元のパソコンでの再生で受け取った人の受け入れ検証を代替してはいけない。

リモートパッケージはネットワークと素材サービスの継続的な可用性に依存する。安定した受け渡し入口は、恒久的なサービス保証として解釈できない。受け取った人が完全にオフラインでなければならない場合は、ローカル素材パッケージに切り替え、説明に従ってオフライン再生を検証すべきである。これは受け渡し条件が変化した後の選択であり、リモートドメインの変更で達成できるものではない。

次回の受け渡し前に、まず元のパッケージを保持し、実際に失敗したリクエストを 1 つ確認し、再エクスポートして同じルートをテストする。そうすればフィードバックを明確なバージョンと明確なリソースに対応させられる。