VLCで動画をトリミングする方法（および、より高速なブラウザベースの代替手段）

もしあなたがVLCで動画をトリミングするためにここに来たのなら、おそらくすでにアプリを開き、クリップを放り込み、メニューを探し回って「トリミング」や「カット」のコマンドを探したことでしょう——しかし、それが存在しないことに気づいただけでした。タイムラインなし。ハサミのアイコンなし。明確なイン/アウトのフィールドなし。VLCは確かに動画をトリミングできますが、本物のエディターではなく、詳細コントロールツールバーに埋もれた録画ボタンを通じて行います。ファイルを切り分ける代わりに、欲しいセグメントを再生し直し、新しいクリップとして再キャプチャするのです。ベンダーのチュートリアルでもこれをはっきり述べています。MovaviのVLCトリミングガイドによると、VLCは「ファイルを正確にカットするわけではなく」、代わりに「動画からクリップを録画する」のです。

この一つの設計上の細部が、このワークフローで違和感を覚えるすべてを説明しています。トリミングされたクリップは、ソースのバイト単位のコピーではなく、第二世代の再エンコードです。そしてキャプチャは再生速度で実行されるため、10分のトリミングには実際に10分の待ち時間がかかります。このガイドでは、正確なVLCの方法をステップごとに説明し、それがどこで破綻するかを正確に示し、VLCの録画による回避策が邪魔になるときのために、ブラウザベースの代替手段——ローカル、アップロードなし、フレーム精度——を紹介します。

目次

• VLCの「トリミング」が実際にどう機能するか——カットではなく録画する
• VLCで動画をトリミングする：完全なステップバイステップ
• VLCのトリミングが不十分な点：フォーマット、精度、待ち時間
• ブラウザベースの代替手段：再エンコードやアップロードなしでローカルにトリミング
• ブラウザで動画をトリミングする：ステップバイステップ
• VLC対ブラウザベースのトリミング：どちらを使うべきか？
• VLCトリミングFAQ：品質、保存場所、複数クリップの制限

VLCの「トリミング」が実際にどう機能するか——カットではなく録画する

ボタンに触れる前に、その仕組みを理解しましょう——なぜなら、それが後に続くすべてのステップが逆向きに感じる理由を説明するからです。VLCにはタイムラインベースのノンリニアエディターがありません。ドラッグするクリップも、入力するイン点・アウト点も、削除するセグメントもありません。VLCにあるのは、詳細コントロールツールバーにある録画機能であり、すべての「VLCで動画をトリミングする方法」チュートリアルが実際にあなたに教えているのは、これを使うことなのです。

仕組みはこうです。VLCはソースファイルを再生し、再生中に録画機能が画面上の再生ストリームを真新しいファイルにキャプチャします。出力は元のスライスではなく、新しくエンコードされたコピーです。GuideRealmのVLCトリミング解説は、Movaviガイドが示すのと同じ点を強調しています：トリミングは元のファイルを編集するのではなく、録画機能を通じて行われるのです。あなたはカットしているのではなく——再演して再キャプチャしているのです。

技術的に言えば、これが重要なのは、VLCの変換/保存および録画パイプラインがトランスコーディングのためにlibavcodecとlibavformatを通じて実行されるからです。出力は元のコンテナからストリームコピーされるのではなく、アクティブなプロファイルに従って再エンコードされます。したがって、トリミングされたクリップのコーデック、解像度、ビットレートは、ソースからきれいに継承されるのではなく、録画設定によって決定されます。

では、後で出会うアプローチと対比してみましょう。FFmpegスタイルのストリームコピートリミングは、開始と終了のタイムスタンプをマッピングし、コピーモードを使用して、コンテナレベルでカットします。FFmpegのドキュメントによると、これは再エンコードを一切行わずに、元のコーデック、解像度、ビットレートを保持します。この2つの方法の違いは、コピーをさらにコピーすることと、元の本からページを単純に切り取ることの違いです。

この一つの仕組みが、このガイドの残りで紐解く3つの下流の結果を生み出します：

• リアルタイム速度。キャプチャは再生速度で実行されます。VLCトリミングチュートリアルがリアルタイムで実演しているように、10分のセグメントには10分かかります。
• 世代的な品質損失。すでに圧縮されたH.264映像を再エンコードすると、圧縮アーティファクトが累積します。r/ffmpegとr/VLCのスレッドにいる実務経験のある動画エンジニアたちは、これがすでに一度圧縮された映像で最も悪化すると警告しています。
• 手動の、近似的なタイミング。再生ヘッドを見ながら、手でキャプチャを開始・停止します。

これはバグではありません。設計思想なのです。VideoLAN社長兼VLC主任開発者のJean-Baptiste Kempfは、VLCを「何よりもまずメディアプレーヤー」であり、ノンリニアエディターではないと繰り返し位置づけてきました——これこそが、トリミングがタイムラインカットではなく録画として実装されている理由です。このツールは、それが作られた目的を正確に果たしているのです。ミスマッチは、その目的と、あなたが無理に押し込もうとしている編集作業との間にあります。

VLCはあなたの動画をカットしません——再生中に欲しい部分を再録画します。だからこそ、簡単なトリミングがクリップそのものと同じくらい時間がかかることがあるのです。

VLCで動画をトリミングする：完全なステップバイステップ

これが正確なワークフローです、最初から最後まで。各ステップは意図的に短くしています——これは、すでにVLCを開いた状態で従う部分です。

1. 録画ツールバーを有効にする。VLCを開き、メニューバーに移動して表示 → 詳細コントロールを選択します。これにより、標準の再生コントロールの上に、丸い赤の録画ボタンを含むボタンの追加行が表示されます。録画ボタンはデフォルトで非表示になっており、これがほとんどのユーザーがVLCで動画をトリミングする方法をまったく見つけられない唯一の理由です。Movaviガイドも、この同じステップから説明を始めています。
2. 動画ファイルを開く。メディア → ファイルを開くに移動するか、単にファイルをVLCウィンドウに直接ドラッグします。
3. 再生ヘッドを開始点まで移動する。クリップを開始したい位置の少し手前までシークバーをスクラブします。より正確にするには、一時停止してフレームごとボタンを使い（またはeを押し）、開始フレームに正確に到達するまで1フレームずつ前進させます。この1フレームずつの操作が、カット/分割/トリミング解説を含むVLCチュートリアルが正確な編集点に到達するために推奨する方法です。
4. 録画を押してから、再生を押す。録画を押して再生が始まった瞬間、VLCはキャプチャを開始します。これがリアルタイムの部分です——それより速くではなく、ちょうど再生速度でキャプチャします。
5. 終了点まで再生させ、その後もう一度録画を押して停止する。きれいなアウト点のためには、終了の少し手前で一時停止し、正確な最終フレームまでフレームを進め、その後録画をオフに切り替えます。リアルタイムトリミングチュートリアルは、この手動停止の動作を実際に示しています。
6. 出力ファイルを見つける。VLCは録画したクリップをオペレーティングシステムのデフォルトメディアフォルダに保存します——名前を付けて保存ダイアログはありません。VideoHelpフォーラムでのVLCのレコーダーの動作に関する議論に記録されているように、これは多くの初めてのユーザーをつまずかせます。

オペレーティングシステム別のデフォルト保存場所：

オペレーティングシステム	デフォルト保存場所
Windows	ビデオフォルダ
macOS	ムービーフォルダ
Linux	ホームまたはデフォルトメディアディレクトリ

ファイルは自動生成された名前（通常はvlc-record-2024…のようなもの）でそこに保存されるので、確認が表示されない場合は、トリミングが失敗したと決めつける前にそのフォルダを確認してください。

VLCのトリミングが不十分な点：フォーマット、精度、待ち時間

トリミングは完了しました。さて、実用的な頭痛の種がやってきます——クリップをキャプチャして実際に使おうとしたときにのみ気づくものです。

予測不可能な出力フォーマットとコーデック。トリミングはVLCの録画とトランスコード設定によって支配されるキャプチャであるため、出力のコーデックとコンテナは単にソースから継承されるのではなく——アクティブなプロファイルによって決定され、多くの場合、それを設定する明確な場所がありません。この方法を「素早く簡単」と売り込むベンダーのチュートリアルは、出力コーデックやビットレートを明示的に制御する方法がないという事実をごまかしがちです。MovaviガイドもGuideRealm解説も、きれいなコーデック選択を一度も与えることなくワークフローを実演しています。

正確な再生時間の制御がない。録画は手動で停止するので、毎回フレームを進めない限り、トリミングの長さは近似的です。「00:14で開始、00:42で終了」と入力するフィールドはありません。精度は存在しますが、カット/分割/トリミングチュートリアルが示すように、フレームごとボタンでフレームごとに手動で獲得するものです。

第二世代エンコードによる品質劣化。圧縮された映像を再エンコードすると、アーティファクトが累積します。r/ffmpegとr/VLC全体の貢献者たち、実務経験のある動画エンジニアを含め、あらゆる再エンコードワークフローはストリームコピートリミングと比較して世代的な品質損失を被ると注意しています——そしてそれは、あなたがカットするものの大半を占める、すでに圧縮されたH.264映像で最も顕著です。

リアルタイムの待ち時間ペナルティ。ワークフローはデータストリーム速度ではなく再生速度で実行されるため、10分のセグメントのキャプチャには10分かかります。短いクリップの場合、これは問題になりません。長いものの場合、これはこの方法の最大の唯一のコストです。VLCトリミングチュートリアルは、このリアルタイムの制約を明確にしています。

複数セグメントやバッチトリミングがない。1パスにつき1セグメントをキャプチャします。1つのソース動画から3つのクリップを取り出すには、3つの完全な、別々の録画セッションが必要です——それぞれがリアルタイムで実行されます。複数セグメント解説は、この制限を直接説明しています。

出力の発見が分かりにくい。ファイルは名前を付けて保存ダイアログを通じてではなく、自動生成された名前でOSのデフォルトメディアフォルダに保存されるので、ユーザーは頻繁にトリミングされたクリップを「見失い」、何も起こらなかったと思い込みます。VideoHelpフォーラムのスレッドは、まさにこの動作が人々を混乱させるために存在しています。

クリップから10秒を切り取るだけのために、10分待つ——または映像を2回再エンコードする——必要はないはずです。

ブラウザベースの代替手段：再エンコードやアップロードなしでローカルにトリミング

上記のすべての痛点は、1つの根本原因にたどり着きます：VLCはスライスする代わりに再録画するのです。FFmpegの上に構築されたブラウザベースのトリマーは、それをソースで修正し、しかもあなたのファイルをどこにも送信せずに行います。Media Tools Suiteのオンライン動画トリマーは、WebAssemblyとFFmpegを使用して完全にブラウザ内で実行されます——つまり、トリミングのロジックがあなた自身のデバイス上でローカルに実行されるのです。ffmpeg.wasmの上に構築されたブラウザエディターは、まさにこれを宣伝しています：「アップロードなし、サーバーなし——すべての処理はWebAssemblyを使用してブラウザ内でローカルに行われます」、ffmpeg-webCLI GitHub READMEより。

これを6つのVLCの痛点と対比させると、その違いは明確です。

速度。WebAssembly/FFmpegトリマーは、リアルタイムの再生ではなくデータストリーム速度で動作するため、数秒でカットを処理します。あの10分の待ち時間は単純に消えます——ffmpeg-webCLIプロジェクトが実演しているように、カットはほぼ瞬時に完了します。

品質。コンテナタイムスタンプでのストリームコピーは、元のコーデック、解像度、ビットレートを保持します。ソースコーデックがサポートされている場合、そもそもエンコードがないので、第二世代エンコードもありません。FFmpegのドキュメントは、このコピーモードの動作を、品質損失なしでカットする標準的な方法として説明しています。

精度。ブラウザトリマーは明示的なイン/アウトのタイムスタンプとドラッグ可能なハンドルを公開するので、録画ボタンを見ながら手探りで押す代わりに、ミリ秒単位で選択をマークできます。Smart Web Video Editorを手がけるエンジニアのAlexsandro Souzaは、現代のWebAssemblyとWebCodecsがこの種のフレーム精度のクライアントサイド選択を完全に実現可能にしていると指摘しています。

フォーマットの明確さと出力。結果を選択して直接ダウンロードします。録画プロファイルの推測も、OSのデフォルトフォルダの探索も、見つけられない自動生成ファイル名もありません。

プライバシーの観点には明確な注記が必要です。なぜなら、それが比較が変わるところだからです。VLCデスクトップとローカル処理のブラウザツールはどちらも、あなたのメディアをあなたのマシンに保持します——だからプライバシーは、これらを互いから区別するものではありません。意味のある区別は、clideo.comやveed.ioのようなクラウドエディターに対してです。その多くは、ファイルに触れる前に、生のファイルをサーバーにアップロードします。WebAssemblyトリマーは、サーバーサイドの処理がないことを明示的に保証します。これは、ブラウザエディターに関するr/ffmpegの議論で強調されている点です。機密性の高い映像——法律、医療、社内、誰か他人のサーバーで危険を冒せないもの——にとって、その保証は重要です。

エンジニア自身の枠組みが、設計意図を明確にしています。Tejaswi Gowdaは、彼のffmpeg.wasmブラウザエディターを「ffmpeg.wasmによって動作するブラウザベースの動画エディター。アップロードなし、サーバーなし——すべての処理はローカルで行われます」と説明し、プライバシーとローカルパフォーマンスを後付けではなく、核心的な設計目標として挙げています。

正直な反論メモです。誇大宣伝は誰の役にも立たないからです：ブラウザのパフォーマンスはデバイスによって異なり、重いマルチトラックのワークロードは低スペックのハードウェアでは不均一になる可能性があります。r/ffmpegの動画エンジニアたちは、ブラウザ編集が最も重い作業を処理できるかどうかを公然と疑問視しており、Show HNのWebCodecs/WebAssemblyスレッドは、ブラウザのサポートがデバイス間で不均一であると観察しています。しかし、手元の特定のタスク——1つのクリップをトリミングすること——にとっては、ローカルのFFmpeg/WASMは、あらゆる現代のマシンで高速かつ信頼性があります。音声だけが必要な場合も同じ論理が適用されます：ポッドキャストのセグメントやサウンドバイトを抽出するには、オンライン音声カッターに専用のローカルツールがあります。

実用的な詳細：無料で、登録不要、ウォーターマークなし、何もインストールしません。MP4、MOV、MKV、その他を扱い、インターフェースは20以上の言語で利用可能です。

ブラウザで動画をトリミングする：ステップバイステップ

これは、VLCがちょうど6ステップと10分かけて行った同じ作業です——5ステップと数秒に圧縮されています。労力を直接比較してください。

1. オンライン動画トリマーを開く。インストールなし、サインアップなし、アカウントなし。読み込まれて準備が整うウェブページです。
2. ファイルをドラッグ＆ドロップまたは選択する。ブラウザに読み込まれ、あなたのデバイスに留まります——ffmpeg-webCLI READMEに記録されているローカル処理の保証と一致して、サーバーには何もアップロードされません。
3. イン点とアウト点を設定する。タイムラインハンドルをドラッグするか、正確なタイムスタンプを入力して、フレーム精度のミリ秒レベルの選択を行います——VLCが手動でフレームを進めて到達させる精度です。
4. 選択をプレビューする。エクスポートする前に開始と終了を確認するので、推測も2回目の試みもありません。
5. 瞬時にトリミングしてダウンロードする。出力は、サポートされている場合はストリームコピーを通じて元の品質を保持し、あなたのデバイスに直接ダウンロードされます。フォルダの探索も、自動命名された謎のファイルもありません。

サポートされる入力には、MP4、MOV、MKV、その他が含まれます。どの時点でもリアルタイムの待ち時間はありません——カットは再生速度ではなくデータストリーム速度で実行されるため、コピーモードトリミングに関するFFmpegのドキュメントに従い、すべてが数秒で完了します。

VLC対ブラウザベースのトリミング：どちらを使うべきか？

どちらのツールもすべての軸で勝つわけではありません。これが正直な内訳です、要素ごとに。

要素	VLC録画トリミング	ブラウザ（FFmpeg/WASM）トリミング
速度	リアルタイム（10分クリップ = 10分）	数秒（データストリーム速度）
出力品質	再エンコード、第二世代	ストリームコピー、オリジナル保持
精度	手動録画/停止 + フレーム送り	正確なタイムスタンプ + ハンドル
インストールの必要性	あり（デスクトップアプリ）	なし（ブラウザで実行）
処理場所	ローカル（デバイス上）	ローカル（アップロードなし）

フォーマット制御とバッチ作業をカバーする2つ目の視点：

要素	VLC録画トリミング	ブラウザ（FFmpeg/WASM）トリミング
フォーマット/コーデック制御	プロファイルで設定、曖昧	選択/保持、明示的
複数セグメント / バッチ	1パスにつき1セグメント	繰り返し可能、正確な選択

比較のためのソース出典：速度はVLCトリミングチュートリアルとffmpeg-webCLIより。品質とストリームコピーはMovaviガイドとFFmpegドキュメントより。精度はMovaviとffmpeg-webCLIより。ローカル処理はffmpeg-webCLIより。フォーマット制御はGuideRealm解説より。

正直に枠組みを示しましょう。VLCは、すでに開いていて、クリップが短く、品質が本当に問題にならないとき——たとえば、同僚に送るための大まかなプレビューカット——には、完全に合理的な選択です。そして、VLCとブラウザツールはどちらもメディアをローカルに保持するので、プライバシーは両者の間の決め手ではありません。それはクラウドアップローダーに対してのみ決め手です。

本当の差別化要因は、速度、精度、品質保持です。タイミングが正確に着地しなければならないもの——ビートに合わせてカットしたソーシャルクリップ、厳密な再生時間にトリミングされた広告枠——や、2回目のエンコードで映像が劣化することを許容できない場合、ブラウザトリマーは同じ作業をより速く、よりきれいに行います。尊重に値する反論があります：VLCやデスクトップFFmpegのようなネイティブツールは、低スペックのハードウェアでの非常に重いまたはマルチトラックのワークロードに対して、まだ優位性を保っています。これは、r/ffmpegの実務経験のあるエンジニアたちが率直に指摘する制限です。しかし、1つのクリップをトリミングすることは重いワークロードではありません。その作業には、オンライン動画トリマーがより速く行います。

VLCがすでに実行中で、大まかなカットだけが必要な場合は、それを使ってください。精度や品質が重要なものには、ブラウザがより速く行います。

VLCトリミングFAQ：品質、保存場所、複数クリップの制限

VLCはトリミング時に動画の品質を低下させますか？
はい。録画ベースのトリミングは、キャプチャされたセグメントを再エンコードし、第二世代のコピーを生成します。品質損失は、再エンコードが既存の圧縮アーティファクトを累積させる、すでに圧縮されたH.264映像で最も顕著です。r/VLCとr/ffmpeg全体の実務経験のある動画エンジニアたちは、これをあらゆる再エンコードワークフローのトレードオフとして一貫して指摘しています。

VLCはトリミングした動画をどこに保存しますか？
オペレーティングシステムのデフォルトメディアフォルダに：Windowsではビデオ、macOSではムービー、Linuxではホームまたはデフォルトメディアディレクトリに。名前を付けて保存ダイアログは使用せず、自動生成されたファイル名を割り当てます。これが、非常に多くのユーザーがトリミングが失敗したと思う理由です。VLCのレコーダーの動作に関するVideoHelpフォーラムのスレッドがこれを記録しており、VLCトリミングチュートリアルがフォルダの慣例を確認しています。

VLCで再エンコードせずに動画をトリミングできますか？
いいえ。VLCにはロスレスのストリームコピーカットがありません——Movaviガイドが説明しているように、そのトリミングは常に録画とトランスコードのパイプラインを通じて再エンコードします。真の再エンコードなしのトリミングには、FFmpegのドキュメントで概説されている方法、コンテナタイムスタンプでストリームコピーするFFmpegベースのツールが必要です。ブラウザベースのオンライン動画トリマーは、ソースコーデックがサポートしている場合、まさにそれを行います。

ブラウザベースのトリミングはプライベートまたは機密性の高い動画にとって安全ですか？
はい、ツールがWebAssemblyを介してローカルに処理する場合は。ファイルはデバイスを離れることはなく、サーバーには何もアップロードされません——生のファイルを先に転送する多くのクラウドエディターとは異なります。ffmpeg-webCLI READMEはサーバーなしの保証を明示しており、ブラウザエディターに関するr/ffmpegの議論がローカル処理の区別を強調しています。

VLCで1つの動画から複数のセクションをトリミングできますか？
1パスではできません。VLCは録画セッションごとに1セグメントをキャプチャするので、複数のカットを取り出すには、毎回完全なリアルタイム録画プロセスを繰り返すことを意味します——3つのクリップ、3つの別々の待ち時間。カット/分割/トリミングチュートリアルは、この複数セグメントの制限を説明しています。正確なタイムスタンプ入力のあるブラウザトリマーは、繰り返しの、正確なカットをはるかに面倒でなくします。これは、VLCの録画による回避策が、節約する以上の時間を費やし始めたら、よりきれいな道です。