ダウンロード

ダウンロードマネージャーにできて、Webブラウザにできないこと

4ギガバイトのファイルが90%まで進んだところで電話がかかってきた、あるいは画面がロックされただけで、ダウンロードは消えてしまう——iOSでのダウンロードに関する最も多い不満ですが、これはバグではありません。OSが設計どおりに動いているだけであり、だからこそダウンロード専用のアプリという種類が存在するのです。

約3分 更新 2026年7月29日

  • 30秒 一時停止されたアプリがiOSに終了させられるまでのおおよその猶予
  • 206 再開そのものを可能にするHTTPステータス
  • 1バイト 正しく再開された転送で再ダウンロードされる分量

アプリを切り替えると転送が止まる理由

iOSは、アプリが「続けたい」というだけの理由で動作を許してはくれません。アプリを離れると数秒以内に一時停止され、一時停止されたアプリにはCPU時間もネットワークソケットもなく、自分が止められたことに気づく手段さえありません。メモリに保持していたものはそのまま残ってはいますが凍結されており、システムがメモリを必要とすれば、何の通知もなくそのまま終了させられます。

そのため、アプリ内の通常の接続で走っているダウンロードは、ホームジェスチャーの瞬間に終わります。数秒だけ追加のバックグラウンド時間を要求してこれを隠しているアプリもあり、そのせいで「バックグラウンドでも続いていた」と思った矢先に、ちょうど気づくころ止まっていたということが起こります。

正しい解決策はまったく別の種類のものです。iOSはバックグラウンド転送サービスを提供しており、URLと保存先のリストをシステムに渡せば、あとはシステム自身が独自のプロセスで、独自のスケジュールでダウンロードを実行します。アプリ自体は一時停止していても、終了していても、まったく起動していなくても構いません——転送は続き、報告すべきことがあればアプリはバックグラウンドで再起動されます。これがロック画面の間も生き残るすべてのダウンロードの背後にある仕組みで、これを使うかどうかはアプリが事前に決める設計上の判断であり、ユーザーがオンにできる設定ではありません。

ダウンロードが生き残るかを決める4つの仕組み

範囲リクエスト
ファイル全体ではなく「500万バイト目以降」を求めるHTTPリクエストです。サーバーが206 Partial Contentで応じれば途中からの再開が可能ですが、200 OKで最初から返してくるなら再開はできず、ファイルをゼロから取り直すしかありません。
並列接続
1つのファイルを複数の範囲に分けて同時に取得する方法です。役に立つのは、1本の接続がサーバー側でスロットリングされていたり、往復の遅延で頭打ちになっていたりすることが多いからで、ソケットを増やせばインターネット自体が速くなるわけではありません。
コミット済みオフセット
転送中ではなく、すでに安全にディスクへ書き込まれた分量のことです。最後にコミットされたバイトから再開するダウンロードは正しく動作しますが、「受け取ったはず」の位置から再開するものは壊れたファイルを生み、それが発覚するのは何時間も後です。
バックグラウンドセッション
上で説明した、システムが実行する転送のことです。起動は遅く、独自のロジックを自由に組み込むこともできませんが、アプリが動いていないときに唯一動き続けるものでもあります。

ダウンロードが失敗する理由と、それぞれの見え方

「ダウンロードが止まった」という報告のほとんどは、この5パターンのどれかです。形さえ分かれば見分けは簡単です。

見えている症状実際に起きていること有効な対処
アプリを離れた瞬間に止まる転送がバックグラウンドセッションではなく、アプリ内プロセスで実行されていた。外側からできることはありません。これはアプリ側の設計の問題です。
毎回0%からやり直しになるサーバーが範囲リクエストを無視しており、途中から続ける手段がない。安定した接続を使うか、より小さいファイルにする。署名付きリンクにだけ範囲指定を許可するホストもあります。
数分後に何度も失敗するリンクの有効期限切れ。多くのホストは5〜10分だけ有効なURLを発行します。元のページからリンクを取り直してやり直す。期限切れのリンクは二度と機能しません。
ダウンロードは速いのにファイルが開かない届いたのはHTMLのエラーページか、動画のファイル名がついたログインページだった。サイズを確認してください。14KBの「映画」はWebページです。取り込む前にリンクを検査しましょう。
接続は速いのに異常に遅いサーバー側で接続ごとにスロットリングされている。サーバーが許可していれば並列接続を増やす。IPアドレス単位で制限されている場合は何をしても変わりません。

そもそもダウンロードできるファイルが存在しない場合

Web上の動画の多くはファイルとして配信されていません。HLSとして配信されており、.m3u8プレイリストが数秒単位の小さなセグメントを何百個も、しばしば複数の画質レベルで並べ、接続状況の変化に応じてプレーヤーが切り替えられるようになっています。映画そのものを保持する1本のURLは存在しません。映画は「連なり」としてしか存在しないからです。

保存するということは、すべてのセグメントを取得したうえで再多重化すること——つまり映像と音声のストリームを通常のMP4コンテナに書き出すことを意味します。再エンコードは一切行われないので画質の劣化はなく、かかる時間も映画の長さではなく数秒です。結果として得られるのは、どこでも再生できる普通のファイルです。

「このストリームをダウンロード」がファイルのダウンロードよりも始まるまで明らかに時間がかかるのはこのためです。プレイリストを取得して解析し、画質レベルを選んでから、ようやくセグメントが届き始めます。そして一部のストリームがまったく保存できないのも同じ理由です。セグメントがDRMで暗号化されている場合、鍵は意図的に取得不可能にされており、法律を守るツールがそれを回避することはありません。

本物のダウンロードマネージャーと単なるダウンロードボタンを分けるもの

アプリを閉じても生き残る

バックグラウンド転送がシステムに引き継がれ、ファイルを最初からではなく、同じコミット済みバイトから続きを取得します。

取り込む前にリンクの正体を教えてくれる

サイズ、種類、サーバーが再開に対応しているかどうか——これらはすべて1回のHEADリクエストで分かり、4ギガバイトのデータ通信量を使う前に知っておく価値があります。

殺到させず、列を作る

10個のファイルを同時に走らせるのは3個ずつより遅くなります。各接続の取り分が小さくなり、失敗も増えるからです。適切な同時実行数の上限を持つキューのほうが早く終わります。

着地するのは普通のファイル

見える場所に、まともな名前で置かれ、何でも再生できます。そのアプリでしか開けないデータベースのBLOBではありません。

ダウンロードの問題の多くを防ぐ習慣

  • 大きなファイルはWi-Fiで始め、最初の数秒だけ画面を点けたままにする

    バックグラウンドセッションへの引き継ぎは早い段階で起きます。それ以降は画面の状態は関係ありません。

  • 20個も一度にキューへ入れない

    ほとんどの接続で、同時に3〜5件が最も効率のよい範囲です。

  • 空き容量は事後ではなく事前に確認する

    ディスクが満杯になる転送は98%地点で失敗し、iOSがすでに空きを作ろうとキャッシュを消していることもあります。

  • 一瞬で「完了」した表示は疑ってかかる

    2秒で終わった映画はエラーページです。ファイルサイズを見てください。

  • 期限切れのリンクは元のページから取り直す

    失効した署名付きURLは、アプリが何度リトライしても永遠に失敗し続けます。

デバイスによる違い

iPhone

最も厳しい環境です。一時停止は容赦なく、ストレージにも余裕がありません。ここではバックグラウンドセッションは最適化の一つではなく、唯一機能する手段です。

iPad

ルールは同じですが動ける余地は広く、大きなライブラリを内蔵ストレージではなく外付けドライブに置くことが現実的な唯一のiOSデバイスでもあります。

Mac

一時停止という概念自体がないため、長時間の転送も普通のデスクトップと同じように振る舞います。実質的な制約はOSではなくサーバー側にあります。

ここから出てくる疑問

接続数を増やせば必ずダウンロードは速くなりますか?

いいえ。サーバーが個々の接続の速度を制限している場合はよく効きます(実際よくあることです)。制限が自分の回線側にある場合は何の効果もなく、ホストがIPアドレスごとの接続数を数えて拒否し始めれば、かえって悪化することもあります。有効な範囲はだいたい4〜8で、30も同時に張るのは逆効果です。

画面がロックされている間もダウンロードは続きますか?

システムのバックグラウンド転送サービスに渡されていれば続きます。そのサービスにとってロック画面は無関係で、重要なのはアプリが一時停止していることそのもの——この仕組みの要点は、それに関係なく動き続ける点にあります。

なぜダウンロードは再開されずに最初からやり直しになるのですか?

サーバーが範囲リクエストに応じなかったからです。進捗がゼロに戻ることで見分けがつきます。署名付きダウンロードURLでだけ範囲指定に対応するホストもあれば、まったく対応しないホスト、小さなファイルだけ対応して大きなファイルには対応しないホストもあります。

ストリームをMP4に変換するのは、再エンコードと同じことですか?

いいえ。再多重化は既存の映像・音声をそのままMP4コンテナへ移すだけなので、劣化はなく数秒で終わるほど高速です。再エンコードは別のコーデックで映像を作り直す処理で、必ず画質が落ちます。2時間のストリームを保存するのに2時間かかるなら、不要な再エンコードが行われているということです。

FoxDL

FoxDLのダウンロードの仕組み

エンジンには2つの経路があります。アプリが画面に出ている間は高速なアプリ内経路、画面から離れた後は同じバイトから引き継ぐシステムのバックグラウンドセッションです。

  • 1つのファイルを並列チャンクで取得し、後で結合する一時ファイルではなく、ディスク上の最終位置へ直接書き込みます。
  • バックグラウンド転送はアプリが画面を離れた後も続き、アプリが把握していた最後のバイトではなく、最後にコミットされたオフセットから再開します。
  • サーバーが範囲リクエストに対応していれば、通信断・再起動・強制終了のあとも再開します。対応していない場合はループさせず、そのことをはっきり伝えます。
  • HLSストリームはMP4へ再多重化されるため、ライブラリに残るのはセグメントの入ったフォルダーではなく普通のファイルです。
  • ダウンロードインスペクターが、開始前にリンクの実際のサイズ・種類・再開対応状況を教えてくれます。
  • すべては「ファイル」アプリから見える普通のフォルダーに置かれます

無料枠はプラットフォームごとに異なります。iPhoneとiPadでは、自分で開始する短いリワード動画で少しずつ回数が追加されます。広告のないMacでは1日あたりの固定回数です。Proはすべてのデバイスでこの制限をなくします。

よくある質問

すべての質問

続きを読む

あなたのライブラリが、やっと一箇所に。

無料でダウンロード。アカウント不要。機能は無料版にすべて含まれます。

ダウンロードは App Store