ファイル転送が 100% で止まるとき：検証と最終処理を確認する

転送が 100% に達し、ネットワークのグラフも落ち着いたのに、編集者はまだ素材を待っている。ジョブを再起動する前に、そのパーセントが何を数えているのか確認しましょう。送信済みのデータ量だけを示していて、検証や転送先での最後の処理が続いている可能性があります。

診断では、データの送信完了、転送先の処理完了、受け入れ確認の完了という三つの時点を分けて考えると役立ちます。その間の待ち時間だけで、ファイルの破損やアプリケーションの故障を判断することはできません。

実際の報告から分かること

2026 年 7 月の Synology に関する投稿では、rclone 1.74.3 の利用者が、マウントした SMB 共有への暗号化コピーが 100% に達した後も止まって見えると報告しています。掲載されたログには、最終的にチェックサムの一致とコピー完了が記録され、その後の返信では追加の検証が続いています。

これは特定の構成で起きた事例であり、調査の手掛かりになります。ただし、すべての Synology や暗号化転送に共通する原因を示すものではありません。後から行われたチェックサム検証を無効にする実験は、実行する処理自体を変えています。同じ検証水準で納品が完了したとはいえません。

一方、2026 年 3 月の過去の報告では、成功した S3 のサーバー側コピー中に、rclone 1.73.2／1.73.3 が 0% を表示し続けるという逆の現象がありました。後にメンテナーがベータ版での修正を案内しています。これは過去の進捗表示の事例であり、現行リリースに同じ問題があるという主張ではありません。

どちらも、パーセントの意味を処理内容と合わせて読む必要があることを示しています。次に確認するのは、その表示の裏で何が動いているかです。

残っている処理を特定する

ファイル転送には、バイト数だけでは表しにくい処理が含まれます。

• データの読み取りと送信。 通常、転送速度の表示が最も直接的に反映する段階です。
• 転送先の検証。 サーバーから取得したハッシュを比較する場合も、ファイル内容をもう一度読む場合もあります。
• 転送先での処理完了。 ストレージサービスがアップロード済みのパートを結合していたり、クライアントがファイルを閉じたりメタデータを設定したりしている可能性があります。
• 受け入れ確認。 受信者が必要なファイルの存在、検証結果、使用予定のアプリケーションで扱えることを確認します。

これらの段階は重なる場合があり、実装によっても異なります。すべての待ち時間をチェックサム計算と決めつけず、ログで該当する処理を確認してください。

Amazon S3 は最終処理の具体例です。CompleteMultipartUpload の公式ドキュメントによると、完了処理には数分かかることがあり、最初に HTTP 200 が返っても、その後のレスポンス本文にエラーが含まれる場合があります。アップロード済みパートや初期レスポンスだけでなく、クライアントの最終結果を確認します。

ローカルパスやマウント先では、最後のメタデータ操作も調べてください。rclone のローカルバックエンドの説明には、コピー後の更新日時の設定と、CIFS マウントで生じ得る権限の問題が記載されています。タイムスタンプのエラーと長時間のデータ読み取りでは、調べる対象が異なります。

動作状況から原因を絞り込む

次の表は診断のための整理であり、どのアプリケーションでも確認済みの原因一覧ではありません。

送信側の通信量が少ないという情報だけでは、正常なサーバー側処理と停止状態を区別できません。同様に、ディレクトリにファイルが見えても、それだけで完成しているとは判断できません。ジョブの成功と、合意した検証結果を確認します。

最後だけでなく転送全体が遅い場合は、アップロードのボトルネックを調べるガイドから始めてください。

チェックサムを計算する場所で負荷は変わる

チェックサムはファイル内容から計算するダイジェストです。両方の値が既にあれば比較の負荷は小さい一方、値の取得にはファイル全体の再読み取りが必要な場合があります。

マウントした SMB パスは、データが別の機械にあっても、転送アプリケーションにはローカルパスとして見えることがあります。検証がそのパスを読み取るなら、データは再びネットワークを通る可能性があります。実際のバックエンドと設定を確認してください。rclone のネイティブ SMB バックエンドと、マウントした共有を指定するローカルバックエンドは別の経路であり、同じハッシュ処理になるとは限りません。

rclone の SFTP バックエンドでは、許可されたリモートシェルコマンドで転送先のハッシュを計算できます。転送先ファイル全体の読み戻しを避けられる場合がありますが、転送先の読み取り帯域と CPU は使います。制限付き SFTP アカウントでは、そのコマンドを実行できない場合があります。

既存のアクセス方針に合う場合に限って、この構成を選んでください。検証時間を短くするために広いシェル権限を与えることは、別の運用判断です。送信段階の調整については、SFTP の性能ガイドを参照してください。

検証時間を見積もりに含める

これは計算例であり、ベンチマークではありません。10 進表記の 100 GB のファイルを実効速度 100 MB/s で送り、その後 40 MB/s で全体を一度読み取って検証するものとします。二つの段階は重なりません。

ファイル列挙、その他の読み取り、再試行、最終処理は含みません。キャッシュ、サーバー提供のハッシュ、処理の重なり、低速な機器によって結果は変わります。この例は、送信だけの完了予測では納品までの残り時間を大きく過小評価し得ることを示しています。

必要な検証を維持してコピーを確認する

受け入れ確認が終わるまで、元のデータは変更しないでください。既存の rclone 環境では、バックエンドに合う検証方法を選びます。

• rclone check は、ファイル一覧、サイズ、利用できる互換性のあるハッシュを比較します。実際に何を検証できたか出力を確認してください。サイズの一致だけでは内容の一致を証明できません。
• rclone checksum は、保存した SUM マニフェストと転送先を比較します。必要なら download オプションでリモートの内容からハッシュを計算できます。
• rclone cryptcheck は、暗号化されたリモートを検証します。基盤となるストレージのハッシュ対応が必要です。読み取りと暗号化処理の負荷も見込んでください。

ハッシュを利用できない場合、rclone check の --download モードは内容を読み取って比較します。大規模なリモートデータに対して実行する前に、追加の通信量とストレージ負荷を見積もります。

チェックサムを無効にして早く終了するのは、検証処理が一つ減ったためかもしれません。送信と検証を別のスケジュールに分けるなら、両方の結果を記録し、検証ジョブが未完了の状態で受け入れ済みにしないでください。

実用的な完了条件を決める

次の代表的な納品では、送信進捗が終端に達した時刻、クライアントが成功を報告した時刻、受信者の検証が終わった時刻を記録します。ファイル数、総バイト数、エラー、検証方法も残し、テストごとに変更する設定は一つにします。

カメラオリジナルなら、整合性の検証後に代表的なファイルを開く、または再リンクする確認も加えます。リモート編集向け素材受け渡しガイドで、一覧管理と受け入れの手順を説明しています。

最後の待ち時間がファイルサイズと読み戻しの動作に応じて増えるなら、検証の実行場所と処理能力を調べます。明確なエラーがあるなら、そのエラーを解決してください。パーセントが動かなくなるたびに再起動するより、こうした観察を次の行動の根拠にできます。