中断した転送を再開：ゼロからやり直さない方法

再開可能な転送は、ファイルをチャンクに分割してどのチャンクが正常に受信されたかを追跡します。接続が切れたとき、クライアントはバイト 0 から再開する代わりに、次の未送信チャンクから再開します。これに対するウェブ標準は tus.io（オープンな再開可能アップロードプロトコル）で、 SwissTransfer 、 HexaTransfer 、 Vimeo 、 Cloudinary 、その他多くの最新の転送サービスに実装されています。ダウンロードでは、 HTTP Range リクエスト（RFC 7233）により、ブラウザや curl 、 aria2 のようなツールが中断されたダウンロードを再開できます。再開機能なしでは 9.5 GB で失敗した 9.8 GB アップロードはすべてを失いますが、再開機能があれば損失はせいぜい 50 MB で済みます。

再開不可能なアップロードの問題

素朴なファイルアップロードは、ファイル全体を一つの HTTP POST リクエストとして送信します。何かが接続を中断すると（ Wi-Fi 切断、 VPN タイムアウト、ノートパソコンのスリープ、 ISP の瞬断）、 TCP 接続が閉じてサーバーは受け取った部分データを破棄します。クライアントはバイト 0 からやり直します。

50 Mbps 接続での 5 GB アップロードでは、 13 分の作業が無駄になります。 50 GB アップロードなら 2 時間以上です。モバイル接続での再開不可能なアップロードの失敗率は深刻で、 4G 接続での 30 分のアップロードが初回で成功することは稀です。

再開可能プロトコルの仕組み

最新の再開可能アップロードはおおよそこのように動作します。

作成： クライアントがファイルの総サイズとメタデータでサーバーに POST を送信。サーバーがこの特定のアップロード用のユニークな URL を返し、ストレージを予約。
チャンク： クライアントがファイルをチャンクに分割（一般的に各 5〜64 MB ）。
アップロード： クライアントが各チャンクを PATCH リクエストとして送信し、 Content-Range または Upload-Offset ヘッダーでチャンクの位置を示す。
確認応答： サーバーがチャンクをストレージに書き込み、新しいオフセットを確認。
再開： 接続が切れた場合、クライアントがアップロード URL に HEAD リクエストを送信。サーバーが現在のオフセット（受け取ったバイト数）で応答。クライアントがそのオフセットから再開。
完了： 最終チャンクが確認応答されると、アップロードが完了。

このモデルは tus.io 仕様（バージョン 1.0.0 が広く展開）で定義されています。他のバリエーションには、 S3 Multipart Upload（直接 S3 アップロード用）と Google Cloud Storage Resumable Uploads があります。

tus.io ：オープン標準

Tus（「transloadit upload server」）は Transloadit が管理する無料のオープンプロトコルです。仕様は tus.io で公開されており、以下に実装されています。

クライアントライブラリ： tus-js-client（ブラウザ + Node.js ）、 TUSKit （iOS）、 tus-android-client 、 tus-java-client
サーバー実装： tusd （ Go リファレンスサーバー）、 tus-node-server 、多くのフレームワーク統合
商用サービス： SwissTransfer 、 HexaTransfer 、 Vimeo 、 Cloudinary 、 Transloadit 、 Uppy のコンパニオンサーバー

プロトコルは意図的に最小限で、 4 つの HTTP 動詞（ POST 、 HEAD 、 PATCH 、 OPTIONS ）と少数のヘッダー（ Upload-Offset 、 Upload-Length 、 Tus-Resumable ）で構成されています。これにより実装がシンプルで相互運用可能になっています。

チャンクサイズの判断

チャンクサイズは、再開の粒度と HTTP オーバーヘッドのトレードオフです。

| チャンクサイズ | 失敗時の損失 | オーバーヘッド | |---|---|---| | 1 MB | 最大 1 MB の損失 | 高（多くのリクエスト） | | 5 MB | 最大 5 MB の損失 | 中程度 | | 16 MB | 最大 16 MB の損失 | 低 | | 64 MB | 最大 64 MB の損失 | 最小 | | 256 MB | 最大 256 MB の損失 | 無視できるオーバーヘッドだが失敗時は痛い |

安定した接続では 32〜64 MB チャンクがスループットを最大化します。モバイルや不安定な Wi-Fi では 2〜5 MB チャンクが各失敗から速く回復します。サービスは通常 5〜10 MB 範囲のデフォルトを選んで妥協を図っています。

実際に転送を中断するもの

失敗モードを理解すると、サービスの再開実装が堅牢かどうかを評価できます。

Wi-Fi 切断： ネットワーク切替、信号損失、ルーター再起動。非常によくある。
ノートパソコンのスリープ： macOS / Windows で蓋を閉じる。 OS がネットワークを一時停止し、起動後に接続の再確立が必要になる。
タブの一時停止： 最新のブラウザはメモリ節約のためバックグラウンドタブを一時停止。一時停止されたタブのアップロードはストールすることがある。
ISP / バックホール問題： 一時的なルーティング変更、 TLS 再ハンドシェイクが必要になる。
VPN 再接続： VPN クライアントが定期的に再交渉。 TCP 接続が切れる。
サーバー側の再起動： 転送サービスが新バージョンをデプロイ。進行中のリクエストが失敗する。
クロスオリジンポリシー変更： トラフィックを検査する企業ファイアウォールが長時間実行接続を切ることがある。

堅牢な再開実装は、これらすべてを同じメカニズムで処理します。再接続し、 HEAD でオフセットを確認し、そこから再開します。

ダウンロードの再開

HTTP Range リクエスト（ RFC 7233 ）は再開可能ダウンロードを支えます。レスポンスヘッダーで Accept-Ranges: bytes を広告するサーバーは Range リクエストをサポートします。クライアントは Range: bytes=1000000- を発行して、オフセット 1,000,000 以降のバイトのみを取得できます。

ブラウザはダウンロードマネージャーで「再開」を押すと自動的にこれを使用します。 Chrome 、 Firefox 、 Safari はすべて準拠サーバーからのダウンロード再開をサポートします。ほとんどの CDN （ Cloudflare 、 Fastly 、 CloudFront ）も Range をサポートしています。

コマンドラインツールではより細かい制御が可能です。

curl -C - -O url で停止したところからダウンロードを再開
wget -c url で同じ動作
aria2c -c -s 16 url で速度のため 16 並列 Range リクエストストリームでダウンロード

再開をサポートするサービス

最新の転送サービスはほとんどがアップロード再開を処理します。

| サービス | アップロード再開 | ダウンロード再開 | |---|---|---| | SwissTransfer | あり（tus ベース） | あり（ HTTP Range ） | | HexaTransfer | あり（チャンク + tus 互換） | あり | | WeTransfer | あり（チャンクアップロード） | あり | | Dropbox Transfer | あり | あり | | Google Drive | あり（再開可能アップロード API ） | あり | | OneDrive | あり | あり | | Box | あり | あり |

無料プランは有料アップグレードを促すために再開を無効化することがありますが、 2026 年では稀です。再開サポートのない古いサービスはユーザーが失敗に疲れるため、推奨リストから消えつつあります。

自動的に再開しないもの

素朴なアプリケーションのプレーン HTTP POST アップロードは再開しません。 FTP 転送は歴史的にさまざまで、一部のクライアントとサーバーは REST（restart）コマンドをサポートし、他はサポートしません。メールの添付ファイルは再開できません。 Gmail の送信が 90% で失敗すれば最初からやり直しです。

トレントベースの転送は本質的に再開します。トレントプロトコルがどのピースが検証されたかを追跡するためです。これがウェブが他の指標で追いついた後も BitTorrent が非常に大きな配布に有用であり続けた理由の一つです。

エンドツーエンド暗号化での再開

クライアント側暗号化と組み合わせた再開可能アップロードは、慎重なチャンク化が必要です。ファイルがチャンクに分割され、各チャンクがユニークな IV（初期化ベクトル）で AES-256-GCM により暗号化され、その後アップロードされます。再開時、クライアントはどのチャンクが完了したかを知り、次から続行する必要があります。

各チャンクは独立して暗号化され認証されるため（ GCM の AEAD モード）、部分アップロードは改ざんできません。オフセット 5 GB にゴミを挿入する悪意のあるサーバーは、受信者が復号する際に認証失敗となります。 GCM タグの不一致が必ず検出されます。

HexaTransfer のような実装は、マスターキーとチャンクインデックスから決定論的に導出したチャンクごとの IV を使用するため、再開時に IV を別途保存する必要がありません。復号側は同じ導出から再構築します。

クライアント側のベストプラクティス

再開成功を最大化するために。

アップロード中はタブをアクティブに保つ。 ブラウザのタブ一時停止は進行中のアップロードを終了させる。「このタブを閉じないでください」という警告は転送サービスの UI で標準的。
可能なら有線ネットワークに接続する。 Wi-Fi 切断がほとんどの失敗を引き起こす。
長いアップロード中は省電力スリープを無効化する。 macOS ：caffeinate -i。 Windows ： Powertoys Awake ユーティリティまたは電源プラン変更。
アップロード中に Wi-Fi ネットワークを切り替えない。 TCP 接続の IP が変わって切断される。
アップロードが完了する前にノートパソコンの蓋を閉じない。 最新の macOS は短いスリープを通じてアップロードを保持することがあるが、確実ではない。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。