video-shotcraftとは｜Agent Skill 動画生成を実際にレンダリングして157枚のカードを数えた

Agent Skill 動画、つまりエージェントに映像を作らせる、という話は威勢がいいわりに検証が難しい。プロンプトを投げて出てきた動画が良いか悪いかは主観だし、そもそも環境を整えないと1フレームも出ない。

Vincentwei1021/video-shotcraft は、その検証がしやすい作りになっていた。157枚の「ショット配方カード」と、受け入れ済みのテンプレート1本が同梱されていて、テンプレートは Remotion のプロジェクトとしてそのまま回せる。つまり「エージェントが上手くやるか」とは独立に、道具そのものが動くかを先に確かめられる。

というわけで実際にレンダリングした。36.17秒の1080p動画が出るまでやってから、カードの中身と、出所の表示を読んだ。

Claude Code の全体像はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてある。本記事はその枝として、成果物が目で見えるタイプのスキルを実際に動かして測る。

Agent Skill 動画生成の実体は何でできているか

まず正体の確認から。README の説明はこうだ。

video-shotcraft is an AI agent skill that turns Claude Code or Codex into a motion-design studio

つまりスキル1本であって、アプリでもライブラリでもない。中身は Markdown のカード群と Remotion のテンプレートで、動かすのはエージェントだ。クローンして数えるとこうなる。

README が掲げる「157 shot recipe cards · 214 styles · 214 motion previews」を数え直した。gallery/api/library.json の stats は cardCount 157 / styleCount 214 / previewCount 214 / mediaCount 214 を返し、cards 配列の長さも157、styles を展開すると延べ214・ユニーク214。references/shots/ の .md から ATTRIBUTION.md を除いた数も157だった。3つとも実体と一致する。

カテゴリは10種で、内訳はこうなっている。

1枚が持つスタイル数は、1個が118枚、2個が26枚、3個が10枚、4個が2枚、6個が1枚。平均すると1.36だ。

ひとつ注意がいるのはプレビュー動画がリポジトリに入っていないことだった。クローンした中の .mp4 / .webm / .gif を全検索して0件。gallery/fetch-media.sh を読むと答えが書いてある。

Download the motion-preview MP4s from the gallery-media release into gallery/media/ for local preview. They are not tracked in git

GitHub のリリースアセットに置いて、gh release download で取る構成だ。実際にアセットを1本 curl したところ HTTP 200・741,931バイトで、file コマンドの判定も ISO Media, MP4 だった。配布側は実在し、到達できる。リポジトリを軽く保つ設計として妥当だが、クローンしただけではカードの文章は手に入っても動く見本は手に入らないので、オフラインで使うつもりなら先に取っておく必要がある。

細かい点だが、library.json の generatedAt は 2026-07-19 なのに、同じファイルの stats.newest は 2026-09-01、最終コミットは 2026-09-02 だった。generatedAt が再生成されていない。中身に影響はないが、この値を信じて鮮度を判断すると外す。

テンプレートを実際にレンダリングする

ここが本題だ。カードを読むだけなら誰でもできるが、出力まで通るかは別の話になる。

template/ を複製して依存を入れる。

npm ci                                   # 12秒 / 129パッケージ / 315MB
npx remotion compositions src/index.ts   # → ここで止まる
#   Downloading Chrome Headless Shell https://www.remotion.dev/chrome-headless-shell
#   Error: Received a status code of 403 ...
#   Host not in allowlist: remotion.media.

Remotion は既定で自前のブラウザを remotion.media から取りに行く。外部通信が制限された環境ではここで終わる。手元のブラウザを指定すれば通った。

npx remotion compositions src/index.ts \
  --browser-executable=/opt/pw-browsers/chromium_headless_shell-1194/chrome-linux/headless_shell
#   AiflPromo    30      1920x1080      1085 (36.17 sec)

AiflPromo / 30fps / 1920×1080 / 1085フレーム / 36.17秒。ここまで来れば出力できる。

なお通常の Chromium バイナリを渡すと Old Headless mode has been removed from the Chrome binary. で失敗した。headless_shell のほうを指す必要がある。ここは1回踏んだので書いておく。

まず静止画を1枚。

npx remotion still src/index.ts AiflPromo out/frame300.png --frame=300 \
  --browser-executable=/opt/pw-browsers/chromium_headless_shell-1194/chrome-linux/headless_shell
#   7秒 / 2,108,384バイト

出てきた画像を開いて確認した。3D空間に積層されたカード、パースのついた影、中国語と英語の混在したテキスト——豆腐にならずきちんと描画されている。ヘッドレス環境で CJK が崩れるのはよくある事故なので、ここが通ったのは良い兆候だった。

次に通しで出す。

※ GPU の無い環境・--concurrency=2 での値

36秒の動画に151秒。実時間の約4.2倍だ。GPUを積んだ手元のマシンならもっと速いだろうが、桁として「数分」を見ておけばいい。エージェントに作らせる前提なら、試行のたびにこの時間がかかることになる。

ここで何を検証していないかをはっきりさせておく。レンダリングしたのは同梱テンプレートのプレースホルダ内容であって、ワークフローの中核である「実際のページをキャプチャして差し込む」工程は通していない。自分のフロントエンドプロジェクトを渡して宣伝動画を作らせる、という本来の使い方は未検証のままだ。

カード1枚が持っている情報の密度

157という数字より効いてくるのが、1枚あたりの中身だった。平均3,700バイト、日本語に直せば2,000字弱がカード1枚に入っている。

camera/terminal-3d.md（端末ウィンドウを3D空間に散らしてカメラが飛ぶ）を例にすると、frontmatter に尺と強度が入る。

・尺：約6.0s（180f@30fps；三駅各約1.6sの停留 ＋ 0.85sの飛行）
・強度：中（飛行が動感、タイプが律動。全体は落ち着いた技術的叙述）

本文は「意図」から始まる。端末の出力はそもそも平面スクロールという反映画的な言語である、だからこのカードはそれを空間化する——という書き出しで、なぜその動きが要るのかを説明する。

続く「動効の核」には計算式が直接書いてある。カメラは窓の姿勢の逆変換を取る（translateZ(300-pull) rotateY(-ry) translate3d(-x,-y,-z)）、飛行区間のイージング窓は [0.30,0.44] と [0.64,0.78]、途中の引きは sin(π)*210px——といった具合だ。

そしてパラメータ表に「調節手感」という列がある。これが良い。

失敗の仕方が先に書いてある。これは人間向けのチュートリアルではあまり見ない書き方で、エージェントに渡す文書としては理にかなっている。エージェントは「試して直す」のコストが高いので、踏んではいけない範囲を先に渡したほうがいい。

読み込みの設計も素直だった。常駐するのは frontmatter の description が 799バイトだけ。発火すると SKILL.md 本文の 19,020バイトが入り、157枚のカードと8本の参照は「何時どのファイルを読むか」という節の指示に従って必要なものだけ開かれる。

・毎ターン常駐：799 B
・発火時に読む：19,020 B（参照コーパス723,926Bの 2.6%）
・必要時に開く：704,906 B

当サイトが前日に測ったClaude Skills UI磨き込み2本を突き合わせた｜指定値が食い違う3箇所をブラウザで検証では、索引型の better-ui でも発火時に全体の20%を読んでいた。2.6%はかなり極端な段階開示で、カードが157枚もある以上そうせざるを得ない、という構造になっている。

一方で description 自体は799バイトと長い。前日の計測では emilkowalski/skills が1本平均442バイト、jakubkrehel/skills が160バイトだったので、その1.8〜5.0倍にあたる。英語と中国語の全文を併記しているためで、SKILL.mdのdescriptionは1024字上限｜Claude Skill命名規則と公式19本の検査結果で書いた上限1024字に対して591字——58%を使っている。

言語の話も書いておく。SKILL.md 全文10,240文字のうち漢字4,196文字・かな0文字で、見出しも本文も中国語だ。README は英語・中国語・日本語の3種あるが、エージェントが読む本体とカード157枚、参照8本は翻訳されていない。モデルは中国語を解するので動作上の実害は出にくいものの、中身を人間が検証したり自分用に書き換えたりしたい場合は中国語を読むことになる。

動きの出所をどこまで開示しているか

モーションデザインのレシピ集を見たとき、まず気になるのは「これはどこかの宣伝動画の引き写しではないのか」という点だと思う。このリポジトリはそこを文書にしていた。

references/shots/ATTRIBUTION.md は2026-08に追加した48枚について、13の研究バッチと出所を開示している。anime.js の公式デモ、remotion-bits.dev、X の個人モーション作品が7アカウント、Firecrawl のブランド動画、抖音の2アカウント、ユーザー提供の参考図——といった具合だ。そのうえで「逐卡来源映射」の表に48枚すべてがどのバッチ由来かをカード名で列挙している。数えたら13行で48枚、README の記述と一致した。

線の引き方も明確だ。

抽象的な動効の手法・技法（時序構造、イージングの考え方、編排の論理）は一般に方法とアイデアの範疇に属するが、具体的表現（原片の画面、美術、文案、ブランド要素、識別可能な全体の視聴覚的提示）は著作権や商標等で保護される。本プロジェクトは前者のみを研究し、全面的な書き直し・脱ブランド化・プレースホルダ化によって後者の複製を避けている。

さらにこう続く。

来源作品が「公開発布」されていることは、複刻や二次創作の許諾を与えたことと等しくない。本表が記録しているのは研究の出所であって、許諾の証憑ではない。

そのうえで、Honor のブランド字標を中性的なプレースホルダに置き換えたこと、X と抖音の出所はアカウント単位の記録で個別投稿のURLを残していないという精度の限界、そして権利者が「それでも具体的表現の複製にあたる」と考える場合は issue を立ててくれれば調整・削除する、という連絡先までが書かれている。

この手の文書は「書いてあるだけ」になりがちだが、実装側で確認できる部分は確認できた。リポジトリに原素材の動画は1本も入っておらず（.mp4 全検索で0件）、カードの実装に出てくる文案は Self-healing CI triage router のような中立的なダミーだった。レンダリングした静止画にも、どこかのブランドを思わせる要素は見当たらない。

法的な評価は当方の役目ではないし、本記事は法的助言ではない。ただ自分が参照したものを列挙して、その列挙が許諾ではないと先に断っているOSSはそう多くない。使う側としては、少なくとも「何を踏んでいるか」を判断する材料が揃っている状態になる。

納品したあとに何が起きるか

測っていて意外だったのが、書き出して終わりにしていないことだった。SKILL.md の「交付收尾（納品の締め）」という節が、すべてのモードで共通の後処理を定めている。

ひとつめはモーションワークベンチを勝手に開くこと。エージェントは成果物を渡したあと、ユーザーに聞かれる前に次を実行するよう指示されている。

# 引数は成果物のプロジェクトディレクトリ
node workbench/scripts/open.mjs ./out/my-promo
# → プロジェクトをリンクし、dev server（ポート5198）を起動してブラウザで成果物を読み込む

workbench/ は67ファイルの別プロジェクトで、出来上がった動画をショット／トランジション／字幕／効果音の多トラックに分解して読み込む。文字カードの文案・色・サイズ・位置・速度変更を画面上で直せて、直したら「導出成片」で書き出す、という流れだ。分解して読み込むにはプロジェクト側に src/workbench.ts のマニフェストが要るが、テンプレート経由なら最初から入っている。

ふたつめが剪映（CapCut 国内版）への書き出しだった。jianying-export/ に4本の Python スクリプトがあり、Remotion のタイムラインを剪映の草稿ファイルに変換する。ユーザーは使い慣れた GUI で字幕や速度やBGMを触り続けられる。エージェントが作ったものを人が引き取って仕上げる、という前提が設計に入っているわけだ。

ここで感心したのは、できないことを先に書いている点だ。

镜头内部动效（逐帧程序渲染）超出剪映的素材+关键帧模型，只能烘焙。 （ショット内部の動効は逐フレームのプログラム描画で、剪映の素材＋キーフレームのモデルを超えるため、焼き込むしかない）

つまりカード由来の動きそのものは剪映側で編集できず、映像として焼き付いた状態で渡る。編集できるのは字幕・尺・音まわりだ。これを期待させずに最初に書いてある。

検証状況の書き方も同様だった。

Mac 版剪映专业版 11.2 实测通过（jianying-export/mac_draft.py）；Windows 版按上游支持路径实现但未真机验证（windows_draft.py）

実測で通ったものと、実装しただけで実機確認していないものを分けて表示している。当サイトも「未検証」は未検証と書く方針でやっているので、この書き方には好感を持った。なお本記事の環境に剪映は無いため、この書き出し経路自体は未検証のまま残している。

Agent Skill 動画づくりに導入するかの判断材料

向いている場面

・フロントエンドのプロダクト紹介動画を作りたいが、モーションデザインの語彙が無い場合。157枚のカードは「どう作るか」以前に何という動きが存在するかの目録として効く
・動画編集ソフトを開かずに作りたい場合。Remotion なので成果物はコードで、差分管理もレビューもできる
・エージェントに任せる前に自分で1本組んでみたい場合。テンプレートは単体で完結していて、本記事のように素のまま回せる

向いていない場面

・GPUも時間も惜しい場合。本記事の環境では36秒に151秒かかった。試行錯誤の回数ぶん積み上がる
・外部通信が制限された環境で、--browser-executable を自分で解決できない場合
・中国語を一切読みたくない場合。動作はするが、カードの中身を精査する道が閉じる
・実写やナレーション中心の動画。守備範囲は「ウェブ／デスクトップ製品の宣伝片」と README 自身が限定している

何を代替するかは、モーションデザイナーへの発注と、After Effects を学ぶ時間だ。ただし置き換えるのは語彙と実装であって、判断ではない。どのカードをどの順に並べるか、尺をどう配るかは結局人が決める——というより、カードの「調節手感」欄が延々と語っているのはまさにその判断の部分で、道具は判断を代行しないという前提で書かれているのが読み取れる。

検証していて好印象だったのは、公称値が全部合っていたことだった。157も214も、48枚の出所も、数えたら書いてあるとおりだった。当サイトでは「READMEの数字をそのまま書かない」を原則にしているが、今回は数え直した結果が一致したので、そう書いておく。

残しているのは肝心の部分でもある。自分のページを撮って差し込む工程、エージェントに実際に作らせる工程、そして出来上がった映像が良いかどうか。最初の2つは環境と時間の問題で、最後のひとつはそもそも測れない。

参照ソース

・Vincentwei1021/video-shotcraft（GitHub） — 本記事の計測対象。Apache-2.0・star 10,500
・SKILL.md — エージェントが読む本体。265行
・references/shots/ATTRIBUTION.md — 48枚の出所と法的な線引きの原文
・オンラインギャラリー — 214本のモーションプレビュー

計測値は data/measurements/runs/2026-10-07-video-shotcraft-skill.json に記録した。環境は Ubuntu 24.04 / x86_64 / node v22.22.2 / Remotion 4.0.484 / Chromium headless shell 1194、GPU なし。実ページのキャプチャを伴うワークフロー本体と、エージェントに実際に制作させる工程は未検証。