RemotionとFFmpeg — フレームワークとコマンドラインの使い分け
RemotionとFFmpeg — フレームワークとコマンドラインの使い分け
「コードで動画を生成したい」と考えた開発者が最初に行き着く先は、たいていFFmpegです。インターネット上の動画の多くを支えているツールであり、どこでも動き、しかも無料です。すると自然にこんな疑問が湧いてきます——FFmpegだけでコマンドラインから動画のカット・連結・オーバーレイ・エンコードができるのに、なぜRemotionのようなフレームワークをわざわざ持ち出す必要があるのか、と。
結論から言えば、FFmpegとRemotionは解いている問題が違い、しかもRemotionは内部でFFmpegを使っています。FFmpegはメディア処理とエンコードのエンジンです——既存のフレームや音声を加工します。一方Remotionはコンポジション（構成）を担うレイヤーで、Reactを使って新しいフレームを 記述し、描画 したうえで、それをエンコーダに渡します。アニメーションやデータドリブンなビジュアルを設計したいならフレームワークが必要です。既存の映像をトランスコードしたり繋ぎ合わせたりしたいならコマンドラインが正解です。そして現実のパイプラインの多くは、その両方を使っています。
本記事では、どちらの道具がどこに向いているのかを整理します。片方の道具にもう片方の仕事を無理やり押し付けるのではなく、意図を持って選べるようになることがゴールです。
FFmpegとは何か
FFmpegは、音声・動画の録画・変換・ストリーミングを行うコマンドラインツール群です。メディアを読み込み、フィルタを適用し、結果をエンコードします。その真価は「すでに存在するメディア」の変換にあります。
- コーデック・コンテナ間のトランスコード（H.264、VP9、AV1、MP4、WebM）
- クリップのトリミング・連結・リマックス
- スケーリング・クロップ・フレームレート調整
drawtextフィルタやoverlayフィルタによる画像・テキストの重ね合わせ- 音声の抽出・無音検出・サムネイル生成
FFmpegは ストリームとフィルタグラフ という発想で動きます。入力メディアに対する一連の処理をチェーンとして記述すると、FFmpegがそのパイプラインにフレームを流し込みます。極めて高速で、実戦で鍛え上げられており、ほぼあらゆるプラットフォームで利用できます。
一方でFFmpegはデザインツールではありません。イージングカーブの効いたアニメーション付きイントロ、2秒かけて伸びていくデータ連動の棒グラフ、入力文字列ごとにレイアウトが組み変わるキネティックタイポグラフィ——こうしたものをFFmpegで作ることは、原理的には可能でも、密で壊れやすいフィルタ式を書くしかなく、すぐに保守不能になります。
Remotionとは何か
Remotionは、ReactとTypeScriptで動画を構築するためのフレームワークです。各フレームは、特定の時点でレンダリングされる1枚のReactコンポーネントです。アニメーションは useCurrentFrame() で現在のフレームを読み取り、interpolate() でそれをビジュアルプロパティにマッピングすることで表現します。
import { useCurrentFrame, interpolate, AbsoluteFill } from "remotion";
export const Intro: React.FC<{ title: string }> = ({ title }) => {
const frame = useCurrentFrame();
const opacity = interpolate(frame, [0, 20], [0, 1], {
extrapolateRight: "clamp",
});
return (
<AbsoluteFill style={{ justifyContent: "center", alignItems: "center" }}>
<h1 style={{ opacity, fontSize: 90 }}>{title}</h1>
</AbsoluteFill>
);
};
RemotionはこれらのコンポーネントをヘッドレスのChromiumでフレームに描画し、その後 FFmpegを使ってそれらのフレームを動画にエンコードします。つまりFFmpegは、壁の向こう側に立つ競合相手ではなく、Remotionが依存しているエンコーダそのものなのです。役割分担は明快です——Remotionがピクセルを描き、FFmpegがそれをファイルに変換します。
中核となるモデルはこうです。コンポジションはコードであり、データはpropsとして流れ込みます。ブラウザで描画できるもの——SVG、CSS、canvas、WebGL、リアルタイムに取得したデータ——は、そのままフレームになります。
両者の関係
ライバルとして捉えるより、レイヤーとして考えると理解しやすくなります。
| レイヤー | 役割 | ツール |
|---|---|---|
| デザイン / コンポジション | 各フレームの見た目とアニメーションを記述する | Remotion（React） |
| ラスタライズ | 記述をフレームごとの実ピクセルに変換する | ヘッドレスChromium（Remotion内部） |
| エンコード / マックス | フレームと音声を再生可能なファイルに圧縮する | FFmpeg |
| 後処理 | 完成したファイルのトランスコード・トリム・連結 | FFmpeg（直接） |
データから 新しい モーショングラフィックを生成する必要が出た瞬間、あなたは最上位レイヤーで作業しており、そこはRemotionの領域です。逆に 既存の メディアを処理する必要が出た瞬間——クライアントのMOVをMP4に変換する、クリップから10秒切り取る、ラウドネスを正規化する——それは最下位レイヤーであり、FFmpegを直接呼ぶのが正しい選択です。
FFmpeg単体の方が良い場面
タスクがデザインではなくメディア処理であるなら、フレームワークを挟まずにFFmpegを直接使いましょう。
- トランスコードとフォーマット変換。 フォルダ内の動画をまとめてWeb向けコーデックに一括変換する。
- シンプルな連結。 事前にレンダリング済みのクリップを1つのファイルに繋ぎ合わせる。
- トリミングとクリッピング。 タイムスタンプ指定でソース映像から区間を切り出す。
- 音声の抽出と解析。 音声トラックを抜き出す、無音を検出する、ラウドネスを測定する。
- 基本的な静的オーバーレイ。 固定のウォーターマークやタイムスタンプを映像に焼き込む。
これらはまさにFFmpegが作られた目的そのものです。Reactフレームワークで包んでも、オーバーヘッドが増えるだけで価値は生まれません。実際、多くのRemotionパイプラインは、レンダリングの前後処理としてFFmpegを直接呼び出しています。
Remotionの方が良い場面
動画の 中身 があらかじめ存在するのではなく、生成・アニメーションされるものであるなら、Remotionを選びましょう。
- アニメーション付きモーショングラフィック — 本物のイージングを効かせたイントロ・ロワーサード・トランジション。
- データドリブンな動画 — 与えた数値に応じて形が変わるチャート・カウンター・レイアウト。
- パーソナライズ／テンプレート動画 — 同じコンポジションを異なるpropsで何千回もレンダリングする。
- タイポグラフィやデザイン主体のコンテンツ — キネティックテキスト、組み変わるレイアウト、CSSによるブランド一貫したスタイリング。
- 条件によって構造が変わるあらゆるもの — シーン数の増減、データに応じて表示・非表示が切り替わるセクション。
スプリングイージングの効いたデータ連動アニメーションをFFmpegのフィルタグラフで表現しようとすると、開発者は壁にぶつかります。同じものをReactコンポーネントとinterpolate()で表現すれば、自然で、テスト可能で、バージョン管理下に置けます。
Remotionでは造作もないのに、生のFFmpegでは苦痛になる典型例がこれです——同じデータに連動して、数値がカウントアップし、バーが伸びていくものです。
import { useCurrentFrame, interpolate, useVideoConfig } from "remotion";
export const StatBar: React.FC<{ value: number }> = ({ value }) => {
const frame = useCurrentFrame();
const { fps } = useVideoConfig();
const progress = interpolate(frame, [0, fps], [0, 1], {
extrapolateRight: "clamp",
});
return (
<div>
<div style={{ fontSize: 72 }}>{Math.round(value * progress)}</div>
<div style={{ height: 24, background: "#e5e7eb", width: 600 }}>
<div style={{ height: 24, width: 600 * progress, background: "#0B84FF" }} />
</div>
</div>
);
};
なお、RemotionではCSSトランジションやキーフレームアニメーションは決して使いません——これらは決定論的にレンダリングされないためです。すべての動きは useCurrentFrame() と interpolate() で駆動され、それによってどのフレームも再現可能であることが保証されます。
レンダリングとスケール
FFmpegは、それを呼び出したマシン上で単一のプロセスとして動きます。高速ではありますが、長尺あるいは複雑なエンコードは、その1台のマシンの性能に縛られます。
Remotionは @remotion/renderer によってローカルでレンダリングするか、@remotion/lambda（AWS）や@remotion/cloudrun（Google Cloud）によって1本の動画を多数のワーカーに分散させます。各ワーカーがフレームのチャンクを並列にレンダリングし、Remotionがそれらを結合するため、長尺のコンポジションでも数秒で仕上がります。その内部では、フレームのエンコードに依然としてFFmpegが使われています——Remotionはそれをワーカー群の上でオーケストレーションしているにすぎません。詳しくはサーバーサイドレンダリングのドキュメント remotion.dev/docs/ssr を参照してください。
ライセンスとコスト
FFmpegは無料のオープンソースであり（ビルド構成に応じてLGPL/GPL）、企業向けライセンスは不要です。
Remotionのフレームワークはオープンソースですが、企業による商用利用にはライセンスが必要です。価格はシート課金やレンダー課金ではなく企業単位で設定されているため、ビジネス用途で採用する前に remotion.dev/docs/license で最新の条件を確認してください。レンダリングインフラのコスト（AWS Lambda、ストレージ、egress）は別途、クラウドプロバイダから請求されます。
FFmpegだけで完結するメディア処理タスクなら、検討すべきフレームワークライセンスはありません。デザインされたアニメーション動画なら、そのライセンスは、保守不能なフィルタ文字列の代わりに、保守可能なオーサリングモデルを手に入れる対価になります。
比較サマリー
| 項目 | FFmpeg | Remotion |
|---|---|---|
| 主な役割 | 既存メディアのエンコード / 処理 | 新しいフレームのデザイン & アニメーション |
| オーサリングモデル | コマンドラインのフィルタグラフ | React / TypeScriptコンポーネント |
| アニメーション | 難しい（フィルタ式） | ネイティブ（useCurrentFrame + interpolate） |
| データドリブンなレイアウト | 非常に困難 | 素直に書ける |
| もう一方を使うか？ | いいえ | はい——RemotionはFFmpegでエンコードする |
| 並列レンダリング | 単一プロセス | Lambda / Cloud Run へのファンアウト |
| ライセンス | 無料（LGPL/GPL） | オープンソース。商用利用は企業ライセンス |
| 向いている用途 | トランスコード・トリム・連結・オーバーレイ | モーショングラフィック・データ動画・テンプレート動画 |
FAQ
Q: RemotionはFFmpegを置き換えるものですか？ いいえ。RemotionはFFmpegの上位に位置します。ReactとChromiumでフレームを描画し、その後FFmpegを使ってエンコードします。純粋なトランスコードやクリッピングが目的なら、FFmpegを直接使ってください——フレームワークを足す理由はありません。
Q: FFmpegでアニメーションテキストやチャートは作れますか？
技術的には可能です。drawtext フィルタや複雑なフィルタグラフを使えば作れますが、すぐに保守不能になります。イージングカーブもレイアウトエンジンもコンポーネントの再利用もありません。デザインされたアニメーションには、フレームワークの方が適した道具です。
Q: Remotionを使うにはFFmpegを知っている必要がありますか？ いいえ。Remotionがレンダリング時にあなたの代わりにFFmpegを呼び出します。前後処理のステップ（たとえばソース映像を取り込む前に変換するなど）でFFmpegを直接呼ぶことはあっても、レンダリング自体にFFmpegの知識は必要ありません。
Q: FFmpegはRemotionより速いですか？ 既存フレームの純粋なエンコードだけなら、FFmpegはそれしかしないぶん極めて高速です。Remotionのレンダリングは、まず全フレームをブラウザで描画する工程を含むため、より多くの作業が発生します——しかしその作業こそがアニメーションを生み出します。Remotionはレンダリングを多数のワーカーに並列化することで、その負荷を相殺します。
Q: 両方を同じパイプラインで使えますか？ 使えますし、実際に多くのチームがそうしています。よくあるパターンは、デザインされたセグメントをRemotionでレンダリングし、その後FFmpegを直接使って既存映像と連結したり、最終出力を追加フォーマットにトランスコードしたりするというものです。
Q: どちらを先に学ぶべきですか？ 自分のタスクが必要とする方を学びましょう。ユーザーがアップロードしたメディアを処理するならFFmpegを、ブランド動画・アニメーション動画・データドリブンな動画を生成するならRemotionを学んでください——そしてRemotionを学べば、エンコード工程を支えているFFmpegの基本も自然と身についていきます。
RenderCompでもっと速く作る
デザインレイヤーにRemotionを選ぶなら、RenderComp が「白紙のキャンバス」というフェーズをまるごと省いてくれます。RenderCompはプロダクション品質のRemotionテンプレートライブラリです——イントロ、ロワーサード、SNSフォーマット、データビジュアライゼーション、商品紹介など、いずれも型付きpropsを備えて出荷されるため、自分のレンダリングパイプラインから駆動できます。あなたはデータとFFmpegによるレンダリングを持ち込み、RenderCompがコンポジションを提供します。
コレクションは rendercomp.com でご覧いただけます。初日からレンダリングを始めましょう。