Claude Opus 5.5で動画生成はできる?仕組みと実測
Opus 5.5の出力はテキストだけです。動画は、モデルが書いたコードをブラウザで1コマずつ撮ってMP4にしたもの。図解やテロップ向きで、実写風には動画生成モデルが要ります。
目次

Claude Opus 5.5は動画ファイルを出力しません。Anthropicのモデル一覧は、現行のClaudeモデルすべてについて、入力はテキストと画像、出力はテキストだと説明しています。2026年9月22日の公開以降にXやYouTubeで見かける「Opus 5.5で作った動画」は、モデルが書いたHTMLやJavaScriptなどのコードを、ヘッドレスブラウザ(画面を表示せずに動くブラウザ)で1コマずつ撮影し、ffmpegでMP4にまとめたものです。
この違いが、作れる動画と作れない動画を分けます。画面の中身をコードで書ける映像、つまり図解、UIの動き、テロップ、グラフ、ロゴアニメーションは守備範囲です。実写のような人物や風景、自然なリップシンクはコードでは描けないので、動画生成モデルが必要になります。
手元での確認もそれほど重い作業ではありません。Opus 5.5がClaude Codeの中で一度で書いた12秒のシーンを、Apple M4のMacで約50行のスクリプトにかけたところ、360フレームの撮影は11.5〜26秒で終わり、できたMP4は約0.9〜1.1MBでした。条件と数字は後半にまとめてあります。
Opus 5.5が出しているのはコードで、映像を描くのはブラウザ
「Opus 5.5が動画を生成する」という言い方には、2つの意味が混ざっています。モデルが生成しているのはテキスト、具体的にはシーンを描くコードです。映像そのものは、そのコードを実行したブラウザやレンダラーが描画しています。
Anthropic自身はこの使い方を製品機能として打ち出していません。Opus 5.5の発表ページには、動画やアニメーション、モーショングラフィックスについての記述がありません。公開後に利用者が見つけて広めた使い方です。考え方の土台は以前からあり、Claudeのヘルプセンターは画像について、Claudeは画像生成ツールのように写真やイラストを生成するわけではないが、HTMLとSVGで図やチャート、インタラクティブなビジュアルを作れると説明しています。静止画での線引きはClaudeは画像を生成できる?Claudeの視覚機能完全ガイドにまとめてあります。動画はその延長で、コードで描いた絵を時間に沿って動かし、連続して撮っているだけです。
公開されている実装のなかで、仕組みがいちばん読み取りやすいのがLaunchVideoです。リポジトリ名はdiggerhq/shipvideoで、製品名と名前が違います。READMEは冒頭で「No video model」と書き、流れを次のように説明しています。
- Opus 5.5が、1920×1080のHTML文書1枚として映像全体を書く。
- 撮影の前に、複数の時刻でページを読み込み、JavaScriptのエラーと画面に出ている文字を確認して直す。
- ヘッドレスのChromiumで全フレームを1枚ずつ撮り、JPEGをffmpegに流し込む(libx264、crf 18、yuv420p)。
レンダリング時間について、同じREADMEは「ほぼ実時間で、30秒の映像に30〜40秒」としています。
ブラウザ以外の描き方も使われています。公開事例を集めたopus-video-promptsは、描画にHTML Canvas、p5.js、Three.js、Remotion、Manim、Blenderのスクリプトが使われていること、音楽はWeb AudioやPythonで合成し、ナレーションは音声合成(TTS)をつなぐ例が多いことをまとめています。どの場合も、モデルの出力がコードである点は同じです。
コードで描ける動画と、動画生成モデルが要る動画
判断の軸は1つで、画面に映るものを図形・文字・数値・既存の素材から組み立てられるかどうかです。
| 作りたい映像 | 向く方式 | 理由 |
|---|---|---|
| 仕組みの図解、解説アニメーション | コードで描く | 図形と文字と動きのタイミングだけで成り立つ |
| 製品紹介、UIの動き、ロゴやテロップ中心のショート動画 | コードで描く | 文字とレイアウトをコードで指定でき、直しはコードの修正で済む |
| グラフ、数式、データの可視化 | コードで描く | 数値からそのまま描ける |
| 手描き風・線画風のアニメーション、歌詞動画 | コードで描く | p5.jsなどの描画ライブラリを使った公開事例がある |
| 実写風の人物・風景、自然なリップシンク、実写の質感 | 動画生成モデル | コードで描いた絵は実写の質感にならない |
| 実写風のカットにテロップや図解を重ねる | 併用 | 素材は動画生成モデル、構成と重ねる要素はコード |

得意・不得意の線引きは、opus-video-promptsが2026年9月22〜25日の公開事例から整理したもので、ベンチマークではありません。同じリポジトリは、実写風の画面が必要なときの一般的なやり方として、Opus 5.5にSeedanceやRunwayなどの動画モデルを呼び出させ、Opus 5.5自身は構成と編集を受け持つ形を挙げています。
実際に何が作られているかは、Xの投稿を集めたawesome-opus-5-5-videosが参考になります。2026年9月26日までに集めた動画ファイル1,401本のうち、分類器がOpus 5.5の関与を「あり・おそらくあり」と判定したのは1,119本。様式別ではモーショングラフィックス・UIが350本、3Dレンダーが324本で、合わせて60.2%を占めます。Xのプレビューの長さは中央値で39.20秒です。ただしラベルは投稿文と9枚のフレームから別のAIモデルが付けたもので、リポジトリ自身が、モデルの呼び出しや作者を証明するものではないと断っています。どんな映像が多いかの目安として読む数字です。
実写風の映像が必要なら、費用の考え方も変わります。動画生成モデルは秒数や本数で課金されるので、AI動画生成の料金相場:1秒あたりと1本あたりのコストで単価を確認してください。コードから呼び出す場合の手順はSeedance 2.5 API実装ガイド、まず無料で試せる範囲を知りたい場合は無料の動画生成AI APIはある?無料で試せる範囲と最安の方法が入口になります。
自分のマシンで最初のMP4を作る
必要なものは、Node.js、インストール済みのGoogle Chrome、ffmpegの3つです。opus-video-promptsも、手元にNode.js・Chrome・FFmpegを用意し、Claude CodeでOpus 5.5を選んでeffortをhighかxhighにする構成を出発点として紹介しています。
シーンに持たせる2つの約束
撮影スクリプトとシーンの間で、次の2つだけを決めておきます。
window.DURATION:映像の長さ(秒)。window.seek(t):時刻t(秒)の画面を描く関数。画面のすべてがtだけで決まるように書く。
骨組みはこうなります。乱数を使いたいときは、種(シード)を固定した自前の乱数にします。
<!doctype html>
<meta charset="utf-8">
<style>html,body{margin:0;background:#0b1020}canvas{display:block}</style>
<canvas id="c" width="1920" height="1080"></canvas>
<script>
window.DURATION = 12; // 映像の長さ(秒)
const ctx = document.getElementById("c").getContext("2d");
// シード付き乱数:何度レンダリングしても粒子の配置が同じになる
function rng(seed) {
return () => { seed = (seed * 1664525 + 1013904223) >>> 0; return seed / 4294967296; };
}
const r = rng(55);
const dots = Array.from({ length: 140 }, () => ({ x: r() * 1920, y: r() * 1080 }));
// 画面はすべて t(秒)だけから計算する
window.seek = async (t) => {
ctx.clearRect(0, 0, 1920, 1080);
// 背景、タイトル、図を t から計算して描く
};
window.seek(0);
</script>Opus 5.5に頼むときは、この約束をそのまま条件として渡します。たとえば次のように書けます。
1920×1080のCanvas 2Dで、12秒の解説アニメーションをscene.htmlの1ファイルに書いてください。
内容:(伝えたいことを3〜4項目で)
条件:
- window.DURATION に尺(秒)を入れる
- window.seek(t) を定義し、時刻 t(秒)の画面を毎回ゼロから描く
- requestAnimationFrame、performance.now()、Date、CSSのtransitionで時間を進めない
- 乱数はシードを固定した自前の関数を使い、Math.random()は使わない
- 外部の画像やフォントを読み込まない最後の3行は、LaunchVideoがシーンに課している制約と同じ向きです。同プロジェクトはvideo・audio・iframeの各要素、CSSトランジション、Math.random、外部画像を禁じ、理由を「レンダリングを決定的に保つため」と説明しています。決定的(deterministic)とは、同じ入力なら何度撮っても1コマ残らず同じ映像になる、という意味です。
約50行の撮影スクリプト
次の render.mjs は、playwright-coreでインストール済みのChromeを動かし、1フレームごとに seek(t) を呼んでスクリーンショットを撮り、ffmpegに流し込みます。Chromiumを別途ダウンロードする必要はありません。
// node render.mjs scene.html out.mp4 [fps] [png|jpeg]
import { chromium } from "playwright-core";
import { spawn } from "node:child_process";
import { once } from "node:events";
import path from "node:path";
import { pathToFileURL } from "node:url";
const [scene, out, fpsArg = "30", type = "png"] = process.argv.slice(2);
if (!scene || !out) throw new Error("Usage: node render.mjs scene.html out.mp4 [fps] [png|jpeg]");
const fps = Number(fpsArg);
const browser = await chromium.launch({ channel: "chrome", headless: true });
const page = await browser.newPage({ viewport: { width: 1920, height: 1080 }, deviceScaleFactor: 1 });
await page.goto(pathToFileURL(path.resolve(scene)).href);
await page.waitForFunction(() => typeof window.seek === "function");
await page.evaluate(() => document.fonts.ready);
const total = Math.round((await page.evaluate(() => window.DURATION)) * fps);
const ff = spawn("ffmpeg", ["-y", "-loglevel", "error", "-f", "image2pipe", "-framerate", String(fps), "-i", "-",
"-c:v", "libx264", "-pix_fmt", "yuv420p", "-crf", "18", "-movflags", "+faststart", out],
{ stdio: ["pipe", "inherit", "inherit"] });
const shotOpts = type === "jpeg" ? { type: "jpeg", quality: 92 } : { type: "png" };
const started = Date.now();
for (let i = 0; i < total; i++) {
await page.evaluate((t) => window.seek(t), i / fps);
const buf = await page.screenshot(shotOpts);
if (!ff.stdin.write(buf)) await once(ff.stdin, "drain");
}
ff.stdin.end();
const [code] = await once(ff, "close");
await browser.close();
if (code !== 0) throw new Error(`ffmpeg exited with ${code}`);
console.log(`${total} frames, capture ${((Date.now() - started) / 1000).toFixed(2)} s`);実行は次のとおりです。
npm init -y
npm install playwright-core
node render.mjs scene.html out.mp4 30 jpeg
ffprobe -v error -show_entries stream=codec_name,width,height,nb_frames,duration out.mp4できあがりの確認には、途中の1コマを抜き出すのが早道です。ffmpeg -ss 9.5 -i out.mp4 -frames:v 1 check.png のように時刻を指定して画像にし、その時刻に出ているはずの要素が映っているかを見ます。シーンの隅にフレーム番号と時刻を描かせておくと、ずれがすぐ分かります。
12秒のシーンを撮った結果
計測は2026年10月1日、Apple M4(10コア)・メモリ16GB・macOS 26.1のMacで、Node 24.11.0、playwright-core 1.63.0、Google Chrome 154(ヘッドレス、1920×1080)、ffmpeg 8.0.1という構成で行いました。対象は、Opus 5.5がClaude Codeの中で一度で書いた12秒のCanvas 2Dアニメーション1本で、人の手による修正はなく、音声もありません。
| 撮影形式 | フレーム数 | 撮影時間 | 1フレームあたり | 映像の長さとの比 | MP4のサイズ |
|---|---|---|---|---|---|
| PNG(1回目) | 360 | 25.93秒 | 約72ミリ秒 | 約2.2倍 | 915,183バイト |
| PNG(2回目) | 360 | 25.80秒 | 約72ミリ秒 | 約2.2倍 | 915,183バイト |
| JPEG(品質92) | 360 | 11.51秒 | 32ミリ秒 | 約0.96倍 | 1,093,045バイト |
ブラウザの起動からエンコード完了までの全体では、PNGの2回が33.46秒と27.24秒でした。ffprobeで見た出力はH.264、1920×1080、30fps、360フレーム、12.000秒です。9.5秒の位置で抜き出したコマには「frame 285 / 360、t = 9.500 s」と表示されていて、映像の時刻とシーンの時刻が一致しています。
読み取れることは3つあります。
- PNGの2回は完全に同じ映像でした。 撮影したフレームのハッシュが一致し、ファイルサイズも1バイト単位で同じ、MP4をデコードして比べても同じです。同じシーンなら撮り直しても結果が変わらないので、直した箇所だけを確かめられます。
- JPEGで撮ると撮影時間は半分以下になります。 1フレーム72ミリ秒が32ミリ秒になり、12秒の映像をほぼ実時間で撮れました。LaunchVideoがJPEGを使って「30秒の映像に30〜40秒」としているのと同じ水準です。代わりにMP4は19%大きくなりました。
- 試作はJPEG、仕上げはPNG、という使い分けが成り立ちます。 何度も撮り直す段階では速さを取り、最終版でサイズと画質を取る形です。
この数字は1台のマシンで単純な2Dシーン1本を撮った結果です。3DやWebGLを使う重いシーン、フォントを読み込むシーン、音声付きの映像の速度までは示していません。日本語テロップについても同じで、文字をコードで指定するので誤字や崩れが起きにくい、という利点は仕組みから期待できますが、上のシーンの文字は英字だけです。日本語を載せるときは、撮影するマシンに入っている日本語フォントを指定し、抜き出したコマで表示を確かめてください。LaunchVideoも、サーバー側の実行環境にNotoフォントを入れてから撮影しています。
実時間の時計で動くシーンはコマ撮りで壊れる
ふつうのWebアニメーションは requestAnimationFrame と performance.now() で、つまり実時間の時計で進みます。ブラウザで再生する分にはそれで正しく動きますが、コマ撮りとは相性がよくありません。1フレームを撮るのにかかる時間が、映像の1フレーム分(30fpsなら約33ミリ秒)と一致する保証がないからです。
同じスクリプトで、わざと seek(t) を無視し、実時間の時計とシードなしの Math.random() で動く3秒のシーンを2回撮ると、次のようになりました。
| 確認した項目 | seek(t) で描くシーン | 実時間の時計で動くシーン |
|---|---|---|
| 2回のフレームのハッシュ | 一致 | 不一致 |
| 2回のMP4のサイズ | 915,183バイトで同じ | 115,816バイトと131,033バイト |
| 抜き出したコマの時刻表示 | 映像9.5秒で「t = 9.500 s」 | 映像1.5秒で「t = 1.572 s」 |

実時間の時計で動くシーンは、撮るたびに違う映像になり、画面の中の時刻が映像の時刻から72ミリ秒ずれていました。それでも速度が大きく狂って見えなかったのは、このときの撮影がたまたま1フレーム33.6〜38ミリ秒で、実時間に近かったからです。
ここから先は計算による推定です。撮影に1フレーム72ミリ秒かかる条件、たとえば上のPNG撮影と同じ速度だったとすると、シーンの中では1フレームごとに72ミリ秒が進み、映像では33.3ミリ秒しか進みません。72÷33.3で、動きは約2.2倍速になるはずです。マシンが遅いほど、シーンが重いほど速回しになる、という壊れ方です。
対策は2通りあります。
- シーンを
seek(t)で書く。 上の約束を最初から条件に入れる方法で、撮影スクリプトは単純なままで済みます。 - 撮影側で時計を差し替える。 LaunchVideoは仮想の時計を注入し、
requestAnimationFrame、タイマー、Date、CSSアニメーションとWeb Animations APIをまとめて自前のシーク関数で動かしています。シーンは書きやすくなりますが、撮影側の実装は複雑になります。
Opus 5.5が書いたシーンをそのまま撮って動きが速すぎる、撮るたびに粒子の位置が違う、といった症状が出たら、まずシーンの中に performance.now()、Date.now()、Math.random()、CSSのtransitionが残っていないかを確かめてください。
レンダリング方式は人数と書き方で決める
撮影と書き出しの方法は、自作スクリプト以外にもあります。上の計測で動かしたのは表の最初の行だけで、残りの行は各プロジェクトの公開情報に基づきます。
| 方式 | 書き方 | 条件・ライセンス | 向く場面 |
|---|---|---|---|
| 自作スクリプト(Playwright+ffmpeg) | HTML1枚と seek(t) | Node.js、Chrome、ffmpegがあれば動く | 仕組みを理解したい、数十秒の2D映像を試す |
| LaunchVideoの構成 | HTML1枚。仮想時計つきで撮影 | 公開リポジトリを自分のOpenComputerアカウントにデプロイ | URLや一文から20〜40秒の紹介動画を作る流れを組みたい |
| HyperFrames | HTML、CSS、シーク可能なアニメーション(GSAP、Lottie、Three.jsなど) | Apache 2.0。レンダリングごとの料金や商用利用の閾値なし。Node 22以上 | 組織の規模を問わず使いたい、Claude Codeのプラグインで進めたい |
| Remotion | Reactコンポーネント | 個人、従業員3人以下の営利組織、非営利組織は無料。それ以外はCompany Licenseが必要 | Reactに慣れていて、部品化して量産したい |
HyperFramesは、各フレームをヘッドレスChromeでシークしてFFmpegでエンコードするので同じ入力から同じ動画ができる、と説明しています。Claude Code用のプラグインもあり、claude plugin marketplace add heygen-com/hyperframes、claude plugin install hyperframes@hyperframes の順に入れて /hyperframes:hyperframes で呼び出します。
Remotionは、ライセンスが組織の人数で変わる点だけ先に確認が要ります。従業員が4人以上の会社で業務に使うなら、Company Licenseの対象です。
選び方をまとめると、こうなります。
- 1本作って仕組みを確かめたいだけなら、自作スクリプトで足ります。
- 会社で継続的に使う予定があり、ライセンスの確認を減らしたいなら、HyperFramesから検討します。
- すでにReactで開発していて、4人以上の会社ならライセンスを取る前提があるなら、Remotionが候補です。
- 実写風の素材が必要なら、どの方式でも動画生成モデルを別に用意します。
1本あたりの費用はトークン数から計算する
APIを従量課金で使う場合、Opus 5.5の定価は100万トークンあたり入力$4、出力$20です。キャッシュを使わないときの1回の費用は次の式になります。
費用 = 入力トークン数 × $4 ÷ 1,000,000 + 出力トークン数 × $20 ÷ 1,000,000何トークンかかるのが普通か、という実測に基づく典型値は公開されていません。出回っている数字は、作った本人の申告です。
- LaunchVideoの作者は、1本あたり約4分、入力約9万トークン、出力約1.5万トークンと報告している、と伝えられています。Hugging Faceのコミュニティ記事を経由した伝聞で、プロジェクトのREADMEにはこの数字がありません。
- opus-video-promptsによると、Deedy Das氏は一文のプロンプトで作った紹介動画について、約1分・約2ドルと述べています。
- 同じリポジトリの事例一覧には、歌に合わせたアニメーションの初版に45分・約200ドルかかったというLinux.doの投稿者の例も載っています。
1つ目の数字を式に入れると、こうなります。
入力 90,000 × $4 ÷ 1,000,000 = $0.36
出力 15,000 × $20 ÷ 1,000,000 = $0.30
合計 $0.66$0.66、約2ドル、約200ドルという幅が、そのまま実態です。自分の費用を見積もるときは、次の点で数字が動きます。
- やり直しと修正のたびに同じ計算が繰り返されます。 3回直せば、おおよそ3回分です。
- 思考に使ったトークンは出力として課金されます。 Opus 5.5は思考が常に有効で、既定のeffortはmediumです。highやxhighに上げるほど出力側が増えます。
- 長い映像や要素の多い映像は、書くコードが増えた分だけ出力トークンが増えます。
- レンダリング、ナレーションの音声合成、音楽、動画生成モデルの素材は別の費用です。 手元のマシンで撮るなら、レンダリングにかかるのは時間と電気代だけです。
いちばん確かなのは、最初の1本を作ったあとに自分の使用量を見て、式に入れ直すことです。APIならレスポンスに含まれる入力・出力トークン数、Claude Codeならセッションの使用量表示が材料になります。
ProやMaxといったサブスクリプションでは、費用は1本いくらではなく、利用枠の減り方として現れます。opus-video-promptsの事例一覧には、約156秒のミュージックビデオを2回通して作り、Max 5xの週の枠の10%を使ったという作者の報告があります。単価と枠の仕組みはClaude Opus 5.5の料金と上限リセット権:API単価、使える枠、確認手順で確認できます。
よくある質問
Opus 5.5にプロンプトを送れば、MP4が返ってきますか
モデルの応答としては返ってきません。返ってくるのはコードです。MP4になるのは、そのコードを実行して撮影する環境があるときです。Claude Codeのようにコマンドを実行できる環境では、Opus 5.5がシーンを書き、撮影スクリプトを動かし、ffmpegで書き出すところまでを続けて進めるので、結果として「頼んだらMP4ができた」ように見えます。
Sonnet 5.5や以前のOpusでも同じことはできますか
仕組みの上では、コードを書けるモデルならどれでも同じ方法が使えます。出力がテキストだけという点は現行のClaudeモデルすべてに共通です。ただし、同じ指示でどこまで見栄えのする映像になるかはモデルによって変わり得るので、仕組みが同じだから結果も同じ、とは言えません。費用を抑えたい場合は、Sonnet 5.5とOpus 5.5の使い分け:半額が効く仕事の考え方で、まず短いシーンを両方に書かせて比べるのが現実的です。
音声やBGMは付けられますか
付けられますが、映像とは別の工程です。公開事例では、ナレーションは音声合成、音楽はWeb AudioやPythonでの合成で作り、最後にffmpegで映像と合わせる流れが多く見られます。上の撮影スクリプトは映像だけを書き出すので、音声を合わせる処理は別に用意する必要があります。
何秒くらいの動画が現実的ですか
公開されている例は数十秒が中心です。LaunchVideoは20〜40秒の紹介動画を対象にしていて、awesome-opus-5-5-videosが集めたXのプレビューは中央値が39.20秒でした。長くすること自体に仕組み上の上限はありませんが、シーンのコードが長くなるほどトークン数と確認の手間が増えるので、場面ごとに分けて作り、最後につなぐほうが直しやすくなります。





