AskCleanAskClean

まず動画のどこが壊れているかを見て、それから直す

動画を選ぶと、このページはストリーム全体をたどって映像データが壊れたフレームを探し、その位置をタイムライン上に示します。修復ではデコードできるフレームだけを含む新しいファイルを書き出すので、途中で止まらずに再生できます。すべて手元の端末で完結し、何もアップロードされません。

このページが実際に調べていること

MP4 や MOV の中で、H.264 / HEVC の各フレームは鎖のように格納されています。長さを表す数値、その分だけの映像データ、次の長さ、というように隙間なく続き、そのフレームのデータを使い切って終わります。この鎖はぴったり末尾に着地しなければなりません。長さが 0 だったり、データの終わりを越えた先を指していたら、そのフレームのバイト列はファイルが主張しているものとは違うということです。

このページがファイル全体にわたってフレームごとに測っているのは、その一点だけです。だからこそ「再生できない」ではなく損傷が**どこにあるか**を言えます。壊れたフレームには位置とタイムスタンプがあるので、損傷をタイムライン上に描けるのです。

壊れた動画を ffmpeg に通して `Invalid NAL unit size (0 > 1241)` が流れていくのを見たことがあれば、それはまさに同じ状態の報告です。プレーヤーは普通、止まる・飛ばす・ブロック状に崩れるという反応をします。存在しないバイト列に対してできることは、それくらいしかありません。

この検査には映像デコーダーが不要です。だからブラウザが再生すらできないファイルにも効きます。読んでいるのはバイト列で、映像ではありません。

「壊れ方」は二種類あり、見え方も違う

**データが壊れたフレーム。** 何かが誤ったバイトを書き込んでいます — USB メモリへのコピーの中断、寿命を迎えつつあるカード、途中で落ちた同期など。ファイルの長さも索引も無傷で動画は普通に開きますが、中の一部のフレームが使えません。タイムライン上では、損傷が起きた場所に散らばった印として現れます。

**途中で切れた動画。** ダウンロードや転送が早く終わってしまった場合です。ヘッダーは元の長さを主張し続けるのでプレーヤーは全長のシークバーを表示しますが、映像データは途中で単に終わっています。このページは、ファイルが主張する長さと実際に到達できた最後のフレームを比べて検出します — タイムライン上では末尾のひとつの灰色のブロックです。

この二つを分けて考える価値があるのは、期待できることが違うからです。散らばった損傷は、ここで 1 秒・あそこで 1 秒という程度で済むことが多い。一方 40% で切れたファイルは動画の 60% が存在せず、書かれなかったものはどんなツールでも作り出せません。

修復後のファイルが短くなる理由

動画のフレームは独立していません。キーフレームは単独で成立しますが、その後のフレームはキーフレームとの差分として格納されています。つまりキーフレームのデータが壊れると、それに寄りかかっているフレームは、自身のバイト列がまったく無事でも使えなくなります。壊れたフレームが十個のファイルが、十個よりずっと多くを失いうるのはこのためです。

修復は実際にデコードできるフレームだけを残し、隙間を詰めて、損傷箇所で固まる代わりに最後まで再生できるようにします。その代わり、出力は捨てた分だけ元より短くなります。その数値は、決める前にも、結果の画面でも表示されます。

再エンコードは行いません。残ったフレームはバイト単位でそのまま複製されるので、残った部分の画質は元のままです。そして処理全体が数分ではなく数秒で終わります。

**音声は残り、同期も保たれます。** 隙間を詰めると、元の長さのままの音声とは映像が合わなくなります。そこで音声はまったく同じ境界で切られます — 残った映像の各区間が、それぞれ自分の音声区間を、同じ量だけずらして持っていきます。区間の内側では両者は固定されており、ずれが生じうるのは区間のつなぎ目だけ、しかも音声パケット半分(約 10 ミリ秒)を超えることはありません。これは口の動きのずれとして知覚される水準より一桁小さい値です。

このページにできないこと

**まったく開けないファイルは、ここでは手が届きません。** どの MP4 も、各フレームがどこにあるかを記した索引を持っています。その索引が壊れていたり失われていたりすると — 録画が正常に閉じられずに終わったときによくあります — たどるべき地図がありません。このページはその場合、回り続けるのではなくそう伝えます。こうしたファイルを救うには、元データか、フレーム境界を推測して索引を作り直すツールが必要です。

**音声の損傷は検出しません。** 音声トラックはそのまま運ばれ同期も保たれますが、**検査はされません** — 壊れた音声パケットを見つけるにはデコーダーを通す必要があり、長さプレフィックスを読むのとは別の、はるかに遅い作業になります。映像は完全で音声だけが壊れている動画は、この走査では「無傷」として出てきます。

**H.264 と HEVC のみ。** 長さプレフィックスでフレームを格納するのはこの二つで、それがこの検査の読む対象です。MJPEG や MPEG-4 Part 2 などはフレームの並べ方が違い、この物差しで測ればすべて損傷しているように見えてしまうため、このページは受け付けません。

よくある質問

動画はどこかにアップロードされますか?

いいえ。ファイルはあなた自身の端末上のブラウザが読み取り、修復コピーもそこに書き出されます。サーバーへは何も送られません — 走査中にブラウザのネットワークパネルを開いて確認するか、先にインターネット接続を切って試すこともできます。

修復すると画質は落ちますか?

落ちません。残ったフレームは再エンコードなしでそのまま複製されるので、残った部分はビット単位で元の映像です。失われるのは長さで、画質ではありません。

修復したファイルにも音は残りますか?

残りますし、同期も保たれます。音声は映像と同じ境界で切られ、同じ量だけずらされるので、残った各区間の内側では両者が固定されています。ずれが生じうるのは区間のつなぎ目だけで、最大でも音声パケット半分 — およそ 10 ミリ秒、知覚できる水準を大きく下回ります。戻ってこないのは、捨てられた区間に属していた音です。対応する映像も失われているためです。

走査では無傷と出たのに、やはり再生できません。なぜ?

この検査が対象にしているのは H.264 / HEVC 映像の映像データです。検査を通っても別の理由で再生できないことはあります — プレーヤーが対応していないコーデック、壊れた音声トラック、コンテナ側の癖など。ここでの「無傷」は問題の範囲を狭めるもので、問題を解決するものではありません。

走査にはどれくらいかかりますか?

すべてのフレームを読むため、時間は動画の長さではなくファイルサイズに比例します。ごく普通の機械なら毎秒数百メガバイトで進むので、1 GB のファイルなら数秒程度です。いつでもキャンセルできます。

そもそもダウンロードされなかった部分は復元できますか?

できません。転送が早く終わっていた場合、欠けている映像データはあなたのディスクに一度も書かれていません — 端末上に復元できるものが存在しないのです。このページができるのは、どれだけ欠けているかを正確に伝え、届いていた部分をきれいで再生可能なコピーとして書き出すことです。

ファイルが開くことすらできません。どうすれば?

それはフレームではなくファイルの索引を指しており、このページが唯一助けになれない場合です。可能なら元のファイルをもう一度入手してみてください。それが無理なら、次の手はフレーム境界を走査して索引を作り直す専用の復旧ツールです。Mac 版なら、ブラウザでは扱えない損傷を避けて再エンコードすることもできます。

他の動画ツール

アップロードせずに動画を圧縮するブラウザ内で動画を圧縮。アップロードは一切なく、サイズ制限もありません。エンコードしながらディスクへ書き出すので、数 GB のファイルでも処理できます。MOV・MKV・WebM を MP4 に変換するMOV、MKV、WebM をブラウザ内で MP4 に変換。多くのファイルは入れ物を変えるだけで済むので、映像はそのまま数秒で完了します。アップロードは一切ありません。動画を MP3 に、あるいは音声を取り出す動画から音声を M4A で取り出す、MP3 に変換する、あるいは音を消して映像だけ残す。音声トラックのコピーは一瞬かつ無劣化で、ファイルは一切アップロードされません。iPhone の動画を画質を落とさずに圧縮する方法画質の劣化を目に見えないレベルに抑えて iPhone の動画を圧縮する方法。撮影設定の変更、HEVC での再エンコード、無料の iMovie やショートカットの活用、ライブラリ全体の一括圧縮まで解説します。何も入っていないのに iPhone のストレージがいっぱい?容量を食べている本当の犯人何もないはずなのに iPhone のストレージがいっぱいになる理由を解説します。ストレージグラフの読み方、システムデータの正体、そして写真・キャッシュ・アプリデータから容量を取り戻す方法まで。

AskClean チーム · 更新日 2026-08-21