Communitygithub.com

知識アニメーション動画生成

口述原稿(または録音済み音声)と1枚のスタイル参考画像から、BGMや効果音(字幕オプション)付きの知識アニメーション動画を生成します。

知識アニメーション動画生成 とは?

このスキルは、ユーザーが提供する口述原稿(テキストまたは音声)と1枚のスタイル参考画像を基に、Remotion(Reactベースの動画フレームワーク)、Pythonスクリプト(TTS、音声アライメント、ミキシング)、ffmpegを組み合わせて、プロフェッショナルな知識アニメーション動画を生成するためのものです。ユーザーは最初に動画タイプ(3Dデータ、手描きイラスト、数式、インフォグラフィック、ビンテージアーカイブ、美術館)とアスペクト比(16:9、9:16、1:1)を選択します。このスキルは、テンプレートとコンポーネントライブラリを活用し、各シーンを細かく調整できるコードベースの生成を重視しています。口述原稿の処理、スタイル分析、ストーリーボードの作成、動画レンダリング、納品後の修正といった全工程をカバーし、パブリックドメイン画像の帰属表示やフォントライセンスといった実運用上の注意点も含んでいます。対応プラットフォームはClaude Code、Cursor、Codexなど、SKILL.mdを読み込める任意のAIエージェント環境です。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/newbaisays-aigc/knowledge-animation-video/tree/HEAD

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

知識アニメーション動画生成 は何をしますか?

ユーザーが口述(原稿または音声)+ 1枚のスタイル参考画像を提供します。あなたはテンプレートを選び、ストーリーボードをデザインし、コードを書き、動画をレンダリングします。

技術スタック:Remotion(Reactで動画を記述)+ Pythonスクリプト(ナレーション/アライメント/ミキシング)+ ffmpeg。

基本原則:スタイルがツールを決める。 最初にタイプを決め、そのタイプのテンプレートに従ってツールと映像表現を選択します。

作成者:小白姐姐(Xiao Bai)· GitHub @newbaisays-aigc · MITライセンス プロジェクトURL:https://github.com/newbaisays-aigc/knowledge-animation-video

このスキルは特定のAIツールに依存しません。 ホスト環境が SKILL.md を読み取り、シェルコマンドを実行し、ファイルを書き込める限り、どの環境でも使用できます。 TTSは優先的に components/common/scripts/tts.py(Edge TTS、オンライン必須)を使用します。 環境がPython依存関係のインストールを許可しない場合は、ホストの音声合成機能を使用し、同じ vo.mp3 + 文ごとのタイムテーブルを出力します。 モデルの選択は問いません。コードを書けるモデルであればどれでも使用できますが、コード量が多い場合は推論能力の高いモデルを優先的に使用してください。


ステップ 1:最初の選択(必須、スキップ不可)

以下の4つの質問を一度にユーザーに尋ねてください。プラットフォームがタブ形式の質問をサポートしている場合はそれを使用し、そうでなければ番号付きリストでユーザーに回答を促します。

質問 1:動画タイプ(一言で覚える:インパクト重視なら3D、親しみやすさ重視なら手描き、理論の導出なら数式、構造説明なら情報図、歴史ならアーカイブ、作品鑑賞なら美術館)

番号タイプ適した内容適した人
A3Dデータ具体的なデータがあるもの:データジャーナリズム、製品発表、業界レポート、決算説明金融・テクノロジーブロガー、ニューメディア編集者、マーケティング・プロダクト担当者
B手描きイラスト意見やストーリーが中心:歴史・人文、社会現象、読書ノート、心理学文系教師、知識有料講師、読書ブロガー
C数式抽象的な数学・物理の公式、アルゴリズム、AIの原理理系教師、教材を作る学生、テクノロジーブロガー
Dインフォグラフィックプロセス、方法、システムアーキテクチャ、製品機能、ビジネスフロービジネス報告、企業研修、B2B・SaaS運用担当者
Eビンテージアーカイブ歴史上の人物、歴史的出来事、発明史、ブランドストーリー、古い品々歴史ブロガー、人文科学の普及者、ブランドコンテンツ、旅行業
F美術館名画解説、美術史、文化財、デザイン、建築、写真作品アートブロガー、美術教育者、博物館・旅行業、デザイナー
Gおまかせユーザーが決めかねている場合、あなたが口述原稿を読んでからおすすめを提示—

質問 2:動画のアスペクト比

  • 16:9 横長(1920×1080):Bilibili、西瓜視頻、YouTube、教材
  • 9:16 縦長(1080×1920):抖音、微信動画、小紅書
  • 1:1 正方形(1080×1080):微信朋友圈、情報フィード

質問 3:口述方法

  • 原稿:ユーザーがテキストを提供し、あなたが音声合成(TTS)を行います
  • 音声:ユーザーが録音済み音声を提供し、あなたが文字起こしとアライメントを行います
  • ナレーションなし:映像 + BGMのみ

質問 4:字幕の有無

  • 字幕あり(デフォルト推奨):文ごとに画面下部に表示。スマホのミュール視聴に最適
  • 字幕なし:画面がすっきり。後で剪映などのソフトで自分で字幕を追加したい場合に

注意:口述方法で「ナレーションなし」を選択した場合、字幕が視聴者が内容を理解する唯一の手段となります。その場合は字幕の維持を推奨するようにユーザーに伝えてください。

質問後、ユーザーに素材を依頼するメッセージを個別に送信し、ユーザーの返信を待ちます。2つの素材がそろっていない限り、原稿作成、ストーリーボード作成、生成のいずれも行わないでください。

このメッセージは以下の定型文で送信します(ユーザーが選択したタイプに応じて例を置き換えてください):

わかりました。それでは、以下の2つの素材をお送りください:

素材 1:口述原稿 原稿または録音済みの音声をお送りください。初回は短め、15~30秒(約60~120文字)がテストや消費リソースの節約に適しています。 まだ原稿がない場合は、テーマと長さ(例:「ナポレオンを紹介、20秒」)をお知らせください。こちらで一稿作成し、確認いただきます。

素材 2:スタイル参考画像(重要) スタイルは言葉で説明するより、実際に見せていただくのが確実です。以下のいずれかをお選びください:

  • 画像を1枚または数枚アップロード
  • リンクを送付:Pinterest、小紅書、Bilibili、YouTubeの画像または動画リンク
  • どうしてもない場合は、「デフォルトスタイルで」と返信

参考画像探しのコツ:Pinterestや小紅書で「[タイプのキーワード]」を検索し、一番気に入ったものを選んでください。

各タイプの検索キーワード:美術館 →「museum art documentary motion」;ビンテージアーカイブ →「vintage documentary motion graphics」;3Dデータ →「データ可視化 3D」;手描きイラスト →「手描きアニメーション / doodle explainer」;数式 →「3Blue1Brown スタイル」;インフォグラフィック →「情報図 アニメーション / infographic motion」。

素材収集時のルール:

  • ユーザーがテーマのみで原稿を提供しなかった場合:まず原稿を作成し、ユーザーに個別に送信して確認を得てから、次のステップに進みます。
  • ユーザーが口述原稿のみで参考画像を提供しなかった場合:再度参考画像を依頼します。ユーザーが明確に「デフォルトスタイルで」と回答した場合のみ、テンプレートのデフォルトスタイルを使用します。
  • ユーザーがリンクを提供した場合:まずリンクを開き、実際の画像または動画を取得します(Pinterestリンクの場合は https://widgets.pinterest.com/v3/pidgets/pins/info/?pin_ids=<Pin ID> で画像や動画のURLを取得します)。動画の場合は、均等に8~10フレームを抽出し、1枚の画像にまとめて確認します。 APIが開かない場合は、立ち止まらず、リンクのテキストからスタイルを推測しないでください——直接ユーザーにスクリーンショットまたは画像のアップロードを依頼してください。ユーザーが明確に「デフォルトスタイルで」と回答した場合のみ、テンプレートのデフォルトスタイルを使用します。

ユーザーがG(おまかせ)を選択した場合、口述原稿を読んだ後に以下のルールでおすすめを提示し、理由を一言添えてユーザーの確認を待ちます:

  • 原稿に数字、パーセンテージ、ランキング、成長が多く含まれる → A 3Dデータ
  • 作品(絵画、文化財、建築)の詳細な見どころを解説 → F 美術館
  • 実在の歴史上の人物、出来事、発明、ブランドの来歴を解説 → E ビンテージアーカイブ
  • 意見、ストーリー、心理的概念が中心で数字が少ない → B 手描きイラスト
  • 公式、定理、導出、アルゴリズムのステップが登場 → C 数式
  • ステップ、プロセス、フレームワーク、モジュール間の関係を説明 → D インフォグラフィック

ステップ 2:テンプレートの読み込み

タイプが決まったら、対応するテンプレートファイルのみを読み込みます。すべてを読み込まないでください:

  • A → templates/3d-data.md
  • B → templates/hand-drawn.md
  • C → templates/math-formula.md
  • D → templates/infographic.md
  • E → templates/vintage-archive.md(同時に components/vintage-archive/README.md を読み、コンポーネントライブラリを直接再利用します)
  • F → templates/gallery.md(同時に components/gallery/README.md を読み、コンポーネントライブラリを直接再利用します)

各テンプレートは以下の7つのブロックで構成されています:仕様でサイズを決定、スタイルで外観を決定、リズムで時間を決定、映像で動作を決定、音楽で感情を決定、ツールで実装を決定、納品でチェックを決定。

調整ルール:

  • 仕様、納品:基本的に変更しません。アスペクト比のみユーザーが選択したものに変更します。
  • スタイル、リズム、映像、音楽:ユーザーの内容と参考画像に基づいて調整します。
  • ツール:テンプレートに従います。他のテンプレートのツールと混在させないでください。

コンポーネントライブラリ: components/ ディレクトリには、調整済みの再利用可能なコンポーネントが格納されています。対応するテンプレートにコンポーネントライブラリがある場合は、必ずそのREADMEを読み、コンポーネントとスクリプトを優先的に再利用し、この動画のために新しく独自の映像を記述するだけにします。これにより、効果が安定し、エラーも減少します。現在存在するもの:

  • components/common/:すべてのテンプレートで共有されるスクリプト。ナレーション(tts.py)、録音音声のアライメント(align.py)、3バージョンのミキシング(mix_audio.py)、エクスポート(export_versions.sh)を含みます。ステップ4とステップ7ではこれらのスクリプトを直接使用します。
  • components/3d-data/:3Dデータの参考実装(SpaceX決算速報のソースコード)。3D中国語テキスト、発光軌跡、グリッド地面、ホログラムボディ、マスクトランジションを含みます
  • components/gallery/:美術館(WebGLリキッドガラスレンズキャンバス、カメラビュー数学、作品カルーセル、拡大鏡、作品アーカイブカードと詳細レイアウト。モナリザの完全な例を含む)
  • components/vintage-archive/:ビンテージアーカイブ(紙ラベル、フォトカード、リボン、スタンプ、赤丸、真鍮ネームプレート、ページめくり、真鍮拡大鏡、全画面名画、木製テーブル、フィルムオーバーレイ。さらに画像取得、経年加工、ナレーション、ミキシングスクリプト。ナポレオンの完全な例を含む)

新しい満足のいく効果を作成したら、汎用部分をコンポーネントライブラリに還元してください。


ステップ 3:参考画像の分析

参考画像を注意深く観察し、以下の項目を抽出して書き留めます(以降のすべてのシーンはこれに従うこと):

  • メインカラー 3~5色(カラーコードを記述、例:#0B1E3F)
  • 背景:単色 / グラデーション / テクスチャ / ダークまたはライト
  • 質感:フラット / 立体光陰 / ガラス / 紙 / 線画
  • フォントの雰囲気:太ゴシック / 丸ゴシック / 手書き / セリフ
  • 構図の特徴:余白の量、要素の密度、中央揃えかオフセットか
  • 参考画像が動画の場合、さらに:カメラの動き方、トランジションの種類、テキストの現れ方、リズムの速さ

参考スタイルと選択したテンプレートが競合する場合(例:手描きを選択したのに、3Dガラス質感の画像を提供された)、まずその競合をユーザーに伝え、2~3の融合案を提示してユーザーに選んでもらい、それから進みます。自分だけで勝手に決めないでください。


ステップ 4:口述原稿の処理とタイムラインの確定

原稿モード:

  1. まず原稿を軽く整理します:誤字脱字や読み上げに適さない記号(例:~ * #)を削除します。ユーザーの意図は変更しません。
  2. components/common/scripts/tts.py を使用してナレーションと文ごとのタイミングを生成します(数字はアラビア数字で記述します。環境がPython依存関係をサポートしない場合は、ホストの音声合成機能を使用し、同じ vo.mp3 と文ごとのタイムテーブルを出力します)。

音声モード:

  1. components/common/scripts/align.py [音声ファイル] [原稿] [出力ディレクトリ] でアライメントを行います。原稿がある場合は字幕に原稿の原文を使用します。原稿がない場合は認識されたテキストを使用します。
  2. 原稿がない場合、または類似度が60%未満の場合は、結果をユーザーに確認してもらいます。

ナレーションなしモード:

1秒あたり4~5漢字の割合で各文の長さを推定します。

最終的に文ごとのタイムテーブルを取得し、これをストーリーボードの基礎とします。動画の総尺はナレーションの長さを基準とし、映像はナレーションに合わせます。


ステップ 5:ストーリーボード案の作成とユーザー確認(直接レンダリングしない)

ストーリーボードを表で示します。各シーンを1行とします:

シーン時間対応する口述映像内容動き・エフェクト効果音

要件:

  • 通常、1つの口述文は1つのシーンに対応します。長い文は2つに分割することもできます。
  • 各シーンには必ず「主役となる要素」が存在し、それがどのように動くか(どこから来て、どこへ行き、どれくらいの時間がかかるか)を明確に記述します。
  • 口述内の数字やキーワードは必ず画面上に表示されなければなりません。
  • シーン間のトランジション方法を明確に記述します。

ストーリーボードを送信したら、ユーザーに「この案でよろしいですか?修正したいシーンはありますか?」と尋ねます。ユーザーが確認してからステップ6に進みます。 このステップにより、方向性の誤りによる無駄な消費を防ぐことができます。


ステップ 6:動画の生成

テンプレートの「ツールで実装を決定」の要件に従って、プロジェクトをセットアップし、コードを記述し、レンダリングします:

  1. Remotionプロジェクトを初期化します(環境に既にある場合はそれを再利用します)。ユーザーが選択したアスペクト比に従って幅と高さを設定し、フレームレートは30にします。
  2. 各シーンを独立したコンポーネントとして記述します(Scene01、Scene02……)。これらをメインのCompositionにまとめ、時間順に配置します。これにより、後であるシーンを変更する場合、そのファイルのみを変更すれば済みます。
  3. 参考画像から抽出したカラーリングを公開テーマファイルとして記述し、すべてのシーンがここから色を取得します。
  4. 字幕(ユーザーが質問4で字幕ありを選択した場合のみ):文ごとに表示し、ナレーションのタイミングと同期させます。ユーザーが字幕なしを選択した場合は、字幕レイヤーをレンダリングしませんが、映像のキーフレーム同期のために文のタイムテーブルは保持します。横長の場合は画面下部(下端から約8%)に配置します。縦長の場合は画面中下部(下端から約25%)に配置し、プラットフォームのボタンやテキスト領域を避けます。
  5. BGMと効果音:テンプレートの「音楽で感情を決定」の要件に従って生成または選択します。BGMの音量はナレーションの15%~25%に抑え、ナレーションがある場合は自動的に低減します。
  6. まず3~5フレームのキーフレームスクリーンショットをレンダリングしてセルフチェックします(構図、テキストのはみ出し、色が参考画像に合っているか)。問題がなければ、完全なMP4をレンダリングします。

エラーが発生した場合、まずエラーメッセージを読み、該当するシーンを特定します。そのシーンのみを修正し、全体を書き直さないでください。

パッケージデザインは必須要件です。 画像とテキストを単色の背景に配置するだけではいけません。各シーンは参考画像から「パッケージ要素」を抽出し、それらを再利用可能なコンポーネントとして作成する必要があります。例:机やシーンのテクスチャ、印画紙やカードの枠線、ちぎれ紙のラベル、リボンのバナー、スタンプ、手描きの赤丸、真鍮のネームプレート、本のページめくり、フィルムグレイン、ビネット、フリッカー。数字やキーワードは、これらのパッケージ要素上に登場させ、裸のテキストとして表示してはいけません。

素材の出典とライセンス(必須要件)。 実在の画像(歴史上の人物、名画、文化財)が必要な場合、components/vintage-archive/scripts/fetch_commons.py を使用してウィキメディア・コモンズからダウンロードします。このスクリプトは同時に ATTRIBUTION.md を生成し、各素材の作者、ライセンス、出典ページを記録します:

  • Public domain(パブリックドメイン):クレジットは不要ですが、動画の最後に出典を記載することを推奨します
  • CC BY / CC BY-SA:クレジット表記が必須 —— 動画の最後または説明文に「作品名 · 作者 · 出典ページ · ライセンス名」を記載します
  • CC BY-SA:クレジット表記に加え、二次創作作品も同じライセンスで公開する必要があります

ダウンロード後は、シーンを記述する前にまず画像を確認します(ステップ7の落とし穴1参照)。納品前に ATTRIBUTION.md を参照し、クレジット表記が正しく行われているか1つずつ確認します。フォントは setup_assets.sh でダウンロードされ、すべてOFL 1.1 / Apache 2.0ライセンスであり、商用利用や埋め込みが可能ですが、成果物とともにライセンス声明を保持する必要があります。

テキスト可読性のルール:すべてのテキストはパッケージ要素の内部に配置されなければなりません。紙片やバナーの外側にテキストが浮いていてはいけません。スタンプや強調ラベルにはハイコントラストな配色(例:黄色の背景に赤い文字、暗い背景に明るい文字)を使用し、半透明の赤い文字を紙に直接重ねないでください。

音楽と効果音: ユーザーがローカルの素材ライブラリ(例:Dドライブの効果音ライブラリ)を持っている場合は、まずそのパスを尋ね、感情に応じてライブラリからBGMを選び、アクションに応じて効果音(ページめくり、紙、インスタントカメラ、鉛筆、風切り音トランジション、ドラムヒット、重低音、波の音など)を選びます。BGMは、動画の最後で自然に終わることができるセグメントを選ぶ必要があります。素材ライブラリがない場合にのみ、プログラムで合成します。


ステップ 7:納品と修正

エクスポートバージョン: レンダリング前にユーザーにどのサウンドバージョンをエクスポートするか尋ねます(複数選択可、効果音はすべてのバージョンで保持されます):

  • 完全版:ナレーション + 音楽 + 効果音
  • ナレーションなし版:音楽 + 効果音(ユーザーが自分でナレーションを録音し直す場合に適しています)
  • 音楽なし版:ナレーション + 効果音(ユーザーがプラットフォーム上で自分で著作権フリーの音楽を設定する場合に適しています)

方法:映像は1回だけレンダリングし(無音)、その後異なる音声トラックを合成します。複数回レンダリングしないでください。components/common/scripts/ には既存のスクリプトがあります:mix_audio.py は1回の実行で3つの音声トラックを出力し、export_versions.sh が合成とエクスポートを担当します。他のテンプレートも同じ考え方で実装します。

納品時にユーザーに伝えること:

  • 完成品のファイルパス、尺、アスペクト比、字幕の有無、エクスポートしたサウンドバージョン
  • 使用したテンプレート、メインカラー
  • 一言アドバイス:「どのシーンが気に入らなければ言ってください。例えば『最後の地球を別のスタイルにしたい』など、その部分だけ修正します。」

ユーザーから修正依頼があった場合:

  1. まず何番目のシーンかを確認します(不明な場合は、説明された内容からストーリーボードを逆引きします)。
  2. 該当するシーンのコンポーネントファイルのみを修正します。他のシーンは一切変更しません。
  3. 修正後、まずスクリーンショットをユーザーに見せて確認を得てから、完全な動画を再レンダリングします。

このスキル自体を更新する場合

ユーザーがスキルの内容(テンプレートの追加、コンポーネントの追加、ドキュメントの修正)を変更し、GitHubにプッシュするよう要求した場合:

  • プッシュのたびに必ず新しいタグを打つ必要があります。バージョン形式は vMAJOR.MINOR.PATCH で、frontmatterの metadata.version と一致させます。
  • git tag / git push / gh release を手動で実行せず、tools/release.py を統一して使用します:
python tools/release.py --bump minor --note "今回の更新内容"

これにより、以下の処理が順に実行されます:バージョン番号の変更 → CHANGELOG.md の更新 → .skill の再パッケージング → コミット → タグ付け → プッシュ → GitHub Releaseの作成(配布パッケージ付き)。

修正後、ユーザーに「公開しますか?」と尋ねる必要はありません。上記のコマンドをそのまま実行してください。


実測で判明した落とし穴リスト(初回27秒ビンテージアーカイブ完成品から抽出。これに従えば多くの手戻りを省けます)

素材の取得

  1. ウィキメディア・コモンズのファイル名に騙されるな。 タイトルに Winged Victory of Samothrace と書いてあっても、ダウンロードしたら壁の刻字だったということがあります。画像を取得したら、まず画像を見てからシーンを記述すること。 ファイル名で映像を割り当てないでください。
  2. 縦構図の写真は全画面に詰め込まないこと(FullPainting / objectFit:cover は被写体を切り取ります)。縦位置の画像は必ずフォトカード(PhotoCard)を使用します——ビンテージアーカイブテンプレートはそもそも「机の上に写真を置く」スタイルであり、全画面に画像を敷き詰めるものではありません。

映像の記述

  1. 曲線または異形の底を持つコンテナに複数行のテキストを配置する場合、flexの中央揃えを当てにしないこと。リボンバナー(Ribbon)の紙面の下端は中央が上に弓なりになった曲線であり、サブタイトルが紙の外に落ちてしまったことがあります。曲線の最も狭い部分の高さで校正するか、単一フレームをレンダリングしてから2倍に拡大してトリミングし、余白を目視確認してください。
  2. 要素の登場には十分な安定時間を確保すること:当該シーンが60フレーム未満の場合、Drop スプリングで登場する要素は、落ち着く前にシーンが切り替わってしまうことがあります(紙片が画面右端から飛び出していく)。登場する紙片のatフレームの後、少なくとも30フレームの静止時間を確保してください。

スクリプトの実行

  1. export_versions.sh のエントリーパラメータは、必ず registerRoot() を含むファイル(通常は src/index.ts)でなければなりません。Root.tsx を渡すと「does not contain registerRoot」エラーが発生します。
  2. レンダリング前にまず3~5枚のキーフレームでセルフチェックし、一度で完全にレンダリングしようとしないこと。セルフチェックの方法は、局所を拡大トリミングしてテキストのはみ出しがないか確認することです。全体のサムネイルだけ見ても、10pxのはみ出しはわかりませんが、拡大すれば一目瞭然です。

納品前チェックリスト(完全な動画をレンダリングするたびに必ず確認すること)

  • アスペクト比と解像度がユーザーの選択と一致している
  • 動画の総尺がナレーションの長さと一致し、最後に黒画面や無音の余白がない
  • (字幕がある場合)各字幕がナレーションと同期し、誤字脱字がなく、画面からはみ出していない
  • 口述で言及されたすべての数字が画面に表示され、数値が正しい
  • 配色が参考画像に適合し、すべてのシーンのスタイルが統一されている
  • BGMがナレーションを圧迫しておらず、冒頭と最後にフェードイン・フェードアウトがある
  • 縦長の場合、重要な情報が上部10%および下部15%の領域内にない
  • すべてのパブリックドメイン画像を肉眼で確認し、該当シーンのテキストと一致している
  • 縦構図の写真は全画面に敷き詰められておらず、フォトカードを使用している
  • すべての紙ラベル / バナー / リボン / ネームプレート内のテキストが境界内に収まり、周囲の余白がフォントサイズの0.3倍以上ある(2倍に拡大して目視確認)
  • 登場要素は当該シーン内で少なくとも30フレームの安定時間があり、シーンカットで途切れていない

関連スキル