claude-real-video（crv）レビュー: シーン検出で動画をLLMに読ませる
Let Claude (or any LLM) actually watch a video — scene-aware, deduplicated frames + transcript, from a URL or local file. Runs locally, MIT.
ひと目でわかる
- これは何？
- 固定fpsでフレームを抜くのではなく、シーン変化を検出して重複を捨てる。処理はローカルで完結し、出力は任意のLLMに貼れるフォルダになる。MITのPython製CLIを、採用判断の観点から整理する。
- 誰に向いている？
- ローカルの録画や講義、スクリーンキャストをLLMに読ませたいが、クラウドに動画そのものを上げたくない人には向いている。逆に、動画の内容を自前で解析したいだけの用途や、Whisperのモデルを一切ダウンロードしたくない環境には重い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 5 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
動画をLLMに渡すときの、フレーム選択というボトルネック
多くのツールは動画を固定間隔でサンプリングする。READMEは、Geminiがネイティブに動画を読める場合でもデフォルト1 fpsでフレームを間引くと説明しており、その結果として速いカットが抜け落ちると指摘している。ChatGPTにYouTubeリンクを貼った場合は映像ではなく字幕を読む、Claudeは動画ファイル自体を受け取らない、というのがREADMEの主張だ。
crvが解こうとしているのはこの2点である。第一に、映像のどこを見るかを固定レートではなくシーン変化に委ねる。第二に、抽出したフレームと文字起こしを、クラウドに動画を預けずにローカルで組み立てる。READMEの例では、58秒のクリップに対して固定1 fpsなら58枚、crvなら実際に変化した26枚だけを残し、--gridで3枚のコンタクトシートにまとめるとしている。トークン量の話として提示されているが、数値はあくまでこの例のもので、一般化されたベンチマークではない。
処理の流れ: ffmpegでシークし、Whisperで聞き、フォルダに落とす
パイプラインはREADMEの記述からおおよそ次のように読める。入力はURLまたはローカルファイル。ffmpegがデコードを担当し、シーン変化の検出と類似フレームの除去を経てキーフレームを書き出す。音声はWhisperで文字起こしする。出力は crv-out/ 以下に frames/*.jpg、フレームごとのタイムスタンプを持つ frames.json、transcript.txt と transcript.json、そして MANIFEST.txt という構成になる。
部分抽出の設計が具体的だ。--from 28:00 --to 43:00 を指定すると、ffmpegはファイル全体をデコードせずシークし、Whisperはその窓の音声だけを聞き、フレームの割り当ても窓の内側で消費される。READMEは、それでもcrvが報告するタイムスタンプは元動画のタイムコードのままだと述べている。90分の会議のうち10分の画面共有だけを見たい、という場面を想定した作りである。
もう一点、処理の境界が明示されている点は評価できる。解析と出力生成はローカルで動き、元動画はアップロードされない。ただし抽出後のフレームや文字起こしをクラウドLLMに貼れば、そのデータはその提供元に渡る。READMEはこの線引きを隠していない。
インストールと実行: pip、skills、プラグインの3経路
基本は pip install "claude-real-video[whisper]" で、extrasのwhisperを付けるかどうかで文字起こしの依存が変わる。CLIだけなら crv "<url>" がそのまま動く。コーディングエージェントから使う場合は npx skills add HUANGCHIHHUNGLeo/claude-real-video を実行すると、Claude Code、Cursor、Codex、Copilot、Gemini CLIなどのagentskills.io互換ホストにスキルが入る。手動ならリポジトリをcloneして skills/claude-real-video を ~/.claude/skills/ にコピーする。
Claude Codeのプラグインとして入れる経路も用意されている。/plugin marketplace add HUANGCHIHHUNGLeo/claude-real-video の後に /plugin install claude-real-video@claude-real-video を実行する。ターミナルを避けたい場合は crv-web を起動するとローカルページが開き、繁体字中国語、簡体字中国語、英語のUIでURLかファイルパスを貼って解析できる。
オプションは目的別に分かれている。--viewer は video とキーフレームグリッドと文字起こしを含む viewer.html を書き出し、ネットワークも追加インストールも不要でダブルクリックで開ける。--frame-width 1600 はターミナルや表計算、IDEのような小さな文字を読ませたいときに使う。READMEは、640pxでは1920幅のスクリーン録画から正しい瞬間を見つけても、その瞬間を価値あるものにした細部が失われると説明している。
--adaptive はフレームを固定しきい値ではなく移動する近傍と比較する。2〜3秒のスクワークアンドストレッチのように、単一フレームが突出しない緩やかな変化を拾うための指定だ。--text-anchors は字幕キューに合わせてフレームを強制挿入する。講義スライドやトーキングヘッドの解説向けで、サイドカー .srt/.vtt か埋め込み字幕トラックが必要になる。焼き込まれた字幕は検出できない。強制挿入は最大1秒に1枚で、シーン検出自体には手を入れないとされている。--speakers は文字起こしの各行に [SPEAKER_00] のようなラベルを付け、45MBのローカル話者分離モデルを一度だけダウンロードする。アカウントもトークンも不要で、pip install "claude-real-video[speakers]" で入る。
LLMを使わない用途と、有料版との境界
crvは汎用のキーフレーム抽出器としても使える。シーン変化検出と重複排除だけを行い、MLモデルのダウンロードは発生しない。Whisperも話者分離も不要な人にとっては、この使い方が最も軽い。
一方でREADMEは、無料版とcrv Proの差を明確に線引きしている。無料版はAIに映像を見せる。Proは撮影のされ方（カットのリズム、カメラの動き）と、フレームからは分からない情報（ジェスチャー、表情、声のピッチ変化、感情、音イベント）のタイムスタンプ付きタイムラインを加える。ProはCapafy上の「llm-real-video Pro」というリスティング名で売られており、$29の買い切りと記載されている。ここは評価の分かれる設計だ。コアの抽出機能をMITで公開し、撮影意図や音の解釈を有料側に置く。無料版だけでは「なぜその画角なのか」までは取れない、という制約を利用者は理解しておく必要がある。
向かない場面と、確認できない部分
第一の制約は、字幕が焼き込まれた動画では --text-anchors が機能しないことだ。サイドカー字幕か埋め込みトラックが前提になる。日本語のテレビ番組や、字幕を映像に乗せただけのアーカイブはこの条件を満たさない。
第二に、--speakers は45MBのモデルを初回にダウンロードする。ネットワークが制限された環境や、モデルの取得自体を許可していない現場では使えない。同様にwhisper extraも文字起こし用のモデル取得を伴う。
第三に、READMEには処理時間やCPU・GPU要件の記述が見当たらない。長い動画や高解像度のスクリーン録画でどれだけ時間がかかるかは、この資料からは判断できない。導入前に自分の手元の代表的な動画で一度計測するしかない。
第四に、対応するURLの範囲は明示されていない。YouTubeとReelsの例が挙がっているが、それ以外のサイトでどこまで動くかはREADMEからは読み取れない。v0.10.2のリリースノートには「URL実行はソース自身のキャプションを使う」とあり、URL経由の場合は取得元の字幕に依存する挙動が示唆される。
最後に、これは検証ではなく資料の限界の話だが、筆者はこのツールをインストールも実行もしていない。挙動の記述はすべてREADMEとリリースノートに基づく。
代替手段との違い: 固定サンプリングか、シーン検出か
比較対象として最も分かりやすいのは、Geminiのネイティブ動画入力だ。動画をそのまま渡せて文字起こしも内部で処理される点は楽であり、自前でパイプラインを組む必要がない。ただしREADMEの説明では、フレームはデフォルト1 fpsの固定間隔でサンプリングされ、動画はGoogleに送られる。速いカットの多い映像では、サンプリング点の間に山場が落ちる可能性が残る。
crvのアプローチは逆で、レートを固定せず、変化のあったフレームだけを残す。58秒で58枚ではなく26枚という例がその象徴だ。加えて、動画本体はローカルから出ない。代わりに、抽出後のフレームと文字起こしをLLMに渡す作業は利用者自身が行う。MANIFEST.txt を含めて貼る、という手順がREADMEに書かれている。
つまり選択基準は「手間を取るか、フレーム選択の制御を取るか」である。会議録画や講義のように、特定の瞬間の画面が結論を左右する素材では、後者の価値が出る。逆に、雑談的な動画の要約をさっと得たいだけなら、ネイティブ入力のほうが速い。
ffmpegのシーン検出フィルタを自分で書くという選択肢もある。crvはその上に、重複排除、文字起こし、話者ラベル、部分抽出のタイムコード整合、viewer.htmlの生成を載せている。自前スクリプトとの差はこの積み上げ分であり、シーン検出そのものではない。
メンテナンスとライセンスの見取り図
ライセンスはMITで、リポジトリはアーカイブされていない。最終pushは2026-08-31、直近のリリースはv0.10.3（同日）、v0.10.2（2026-08-28）、v0.10.1（2026-08-27）と、この資料の範囲では短い間隔で更新が続いている。パッチ番号が並んでいることから、細かな修正を頻繁に出す運び方だと推測できる。ただし更新頻度そのものは、このツールが自分の用途に合うかどうかの根拠にはならない。
依存の面では、ffmpegが外部プロセスとして必要になる。Python側は3.10以上。whisper、speakersはextrasとして分離されているので、使わない機能のモデルを抱え込まずに済む。
ライセンス上の注意として、本体がMITだからといって、生成した文字起こしや抽出フレームの権利まで自由になるわけではない。動画の権利は別に存在する。またcrv Proは別売りの商用アドオンであり、MITの範囲には含まれない。ここは法的助言ではなく、構成の整理として述べておく。
導入時の確認手順としては、まずffmpegがPATH上で解決できることを確かめ、次に対象動画で crv "<url>" --viewer を一度走らせて viewer.html を開き、キーフレームが期待した瞬間を捉えているかを見る。文字が多い素材なら --frame-width 1600、変化が緩やかなら --adaptive、字幕があるなら --text-anchors を足して比較する。この順序なら、有料版に進む前に無料版の限界がどこかを自分の目で確かめられる。
編集部の結論
ローカルの録画や講義、スクリーンキャストをLLMに読ませたいが、クラウドに動画そのものを上げたくない人には向いている。逆に、動画の内容を自前で解析したいだけの用途や、Whisperのモデルを一切ダウンロードしたくない環境には重い。導入前に確認すべきは、ffmpegがPATH上にあるか、Whisper用のモデル取得を許容できるか、そして対象動画に字幕が焼き込まれていないか（--text-anchorsはサイドカーまたは埋め込み字幕トラックしか検出できない）。
コミュニティノート