TL;DR
SaaS解説動画を作るには、承認済みのソースbriefを固定し、対象者とCTAを一つに絞り、各主張を画面上の状態変化に対応させ、scene planを確認してから、書き出したファイルの尺、データの一貫性、文字の可読性、字幕、CTAの表示時間を検証します。TapVidの実測では、初版がサンプル顧客を変更し、未承認の数値を追加しました。修正版は記録を直しましたが、指定した35秒ではなく16.83秒で書き出されました。成功メッセージではなく、実際の成果物を承認してください。
このガイドでは、生成を始めるpromptだけでなく、制作の全工程を紹介します。例に使うInvoiceFlowは、このテストのためだけに作った架空のSaaS製品であり、実在する企業、顧客、推奨を示すものではありません。TapVidはExplainer Video Engineとして機能します。既存の製品文言、script、記事、その他の承認済みソースを渡し、何が事実か、視聴者に何を理解してほしいか、完成版がその内容を証明できているかを人が判断します。
01
1. 掲載場所、対象者、次の行動を一つずつ決める
機能一覧から始めないでください。まず動画を掲載するページやチャネルを決めます。
ホームページ用の解説動画は、通常次の3点にすばやく答える必要があります。
- 誰のための動画ですか？
- その製品は、どの問題を理解または処理する助けになりますか？
- 視聴後に何をしてほしいですか？
InvoiceFlowのテストでは、複数のツールで請求書を管理するフリーランサーを対象者にしました。物語の役割は一つです。請求書が作成され、支払状況が変わり、月次summaryに入るまでを見せます。CTAは「1か所で1か月を確認する」に固定しました。
この境界があると、動画があらゆるdashboardの紹介になるのを防げます。同時にacceptance testにもなります。視聴者がその流れを理解する助けにならないsceneは、この版には不要です。
掲載場所はテンポにも影響します。ホームページ動画なら製品操作を認識できるよう数秒残せます。広告向けsocial cutでは、より速いscene切り替えが必要かもしれません。onboarding動画では、具体的なcontrolを長く見せられます。目標尺を決める前に掲載場所を選びます。
02
2. 信頼できる唯一のソースbriefを作る
ソースbriefでは、承認済みの事実とcreative directionを分けます。一本の長い説明promptよりも、動画システムが説明してよい内容と、作り上げてはいけない内容が明確になります。
SaaS解説動画には、次の項目を含めます。
- 対象者と掲載場所。
- 承認済みの製品操作。
- 正確なCTA。
- 一貫性を保つ必要があるサンプルデータ。
- 表示してはいけない主張、数値、interface label。
- 形式、言語、voiceover、おおよその尺。
このテストで承認した製品の仕組みは、意図的に小さく限定しました。
フリーランサーが1か所で1枚の請求書を作成して送信します。支払いが入ると、同じ請求書が一つのledgerに入ります。月次summaryには支払済みと未払いの仕事が表示されます。
サンプルrecordもClient A、INV-001、$1,200に固定しました。この3つを一つのidentityとして扱うことが重要です。後のsceneで顧客名や請求書番号が変われば、視聴者は同じrecordを追えなくなります。
ここで画面表示コピーのwhitelistが役立ちます。motion graphicsに表示してよい語句と数値の短い一覧です。blacklistは避けるべき一部の内容しか伝えませんが、whitelistなら境界を明確に設定できます。
TapVidのSaaS解説動画作成ツールは、提供された素材をsceneとナレーションに構成できます。物語を作れるだけの製品情報を渡しつつ、製品チームが答えるべき空白を補わせないでください。
03
3. 物語を画面上の状態変化に変える
scene outlineには、ナレーターの発言だけでなく、画面上で何が変わるかを書きます。
InvoiceFlowの物語は5つのbeatで構成しました。
| scene | ナレーションの役割 | 必要な画面上の変化 |
|---|---|---|
| 問題 | 作業が分散している状態を見せる | 別々のcardが一つの流れにつながる |
| 作成と送信 | 一つの請求書操作を見せる | Client A、INV-001、$1,200を表示し、送信操作を完了する |
| ledger | 支払いが一つのrecordに入る様子を見せる | 同じ請求書がSentからPaidに変わる |
| 月次summary | 同じrecordの到達先を見せる | 架空の合計を加えず、支払済みと未払いのcategoryを表示する |
| CTA | 次の行動を一つ示す | 製品名と正確なCTAを読める状態に保つ |
各行に状態変化がある点に注目してください。「dashboardを見せる」だけでは不十分です。「支払いが入ったとき、同じ請求書をSentからPaidに変える」なら完成動画で確認できます。
ナレーションも同じように範囲を絞ります。承認済みscriptの中盤は次の文でした。
1か所で請求書を作成し、送信します。
支払いが入ると、一つのledgerに記録されます。
映像が仕組みを示し、voiceoverが視聴者を案内します。1文のナレーションで3つの製品操作を挙げると、sceneは小さなcardの寄せ集めになりがちです。
04
4. レンダリングを使う前にplanを確認する
動画を生成する前に、scene tableとscriptを一緒に確認します。尺、連続性、根拠のない表現、文字密度をチェックしてください。
このpre-render checklistを使います。
- 各sceneの主要なideaは一つですか？
- sceneをまたいでもサンプルデータは同じですか？
- 発話した各主張を裏付ける画面上のactionがありますか？
- 割り当てた秒数に対して長すぎる文はありませんか？
- CTAは言い換えではなく正確ですか？
- 埋め込み表示でも読めるよう、主要interfaceが16:9画面で十分な大きさを占めていますか？
今回、最初に提案された問題提起のナレーションは、6秒のsceneに約39語ありました。通常の速度では明瞭に読めません。そこで「請求書と支払状況が別々のツールに散らばることがあります」に置き換えました。
締めのナレーションも正確なCTAに置き換えました。これらのscript修正は反映され、最終transcriptには承認済みの5文が正しい順番で入りました。
それでもrenderが正しいとは限りません。script承認とvideo承認は別々のgateです。
05
5. 動画を生成し、実際のcutを確認する
生成されたcutは1280×720、30 fps、mono AAC audioでした。実測尺は16.83秒です。ナレーション5文はすべて入っていましたが、予定したtimingは1.9〜4.9秒の5 chapterに圧縮されました。
作成・送信sceneは一見きれいでした。主要cardは読める大きさで、承認済みの顧客、請求書、金額、buttonも表示されていました。
詳しく見ると、sceneにはDraft、field label、animation途中の$0.00も含まれていました。これらは画面表示コピーのwhitelist外です。映像全体が使えないわけではありませんが、承認済みデータ境界には従っていません。
より重大な連続性の問題は次のsceneで発生しました。ledgerのrecordがAcme Corpと#INV-2024-001に変わっています。
金額は$1,200のままでしたが、一つの値が一致するだけでは不十分です。視聴者には別の請求書に見えます。作成、送信、支払済みへ続く因果関係が切れています。
月次summaryには、$0、FULLY SETTLED、NO OUTSTANDINGという未承認の結果も追加されました。
一見問題なさそうな追加ですが、主張の意味が変わります。「支払済みと未払いの仕事を見せる」ことは、未払いがゼロであることや、すべて決済済みであることを証明しません。
完成したexplainerは、魅力的な静止画の集合ではなく、sequenceとして確認する必要があります。まず止めずに一度見てから、各mechanism sceneの名称、数値、状態変化、transitionを正確に確認します。
06
6. 弱い出力を却下し、render固有の修正指示を書く
問題のある初版に対する正しい指示が、常に「もっと良くして」とは限りません。その指示では、systemがscript、style、dataを再び変更できてしまいます。
修正内容を4つのlockに分けます。
Timing lock。 各sceneに固定の尺を割り当てます。次の版では6、8、8、9、4秒、合計35秒を指定しました。最後の4秒はCTA用です。
Identity lock。 表示してよい唯一のrecordをClient A、INV-001、$1,200と明記します。同じ行をSentからPaidへ変えるよう求めます。
Visible-copy lock。 表示してよい語句と数値を列挙し、実際のcutで見つけた誤ったcopyを明示的に削除します。観察した失敗に対応するため、元のbriefを繰り返すより強い指示です。
作曲ロック。 ** 読み取り可能なサイズの目標を設定してください。 私たちは、フレームの55〜70%を占めるプライマリインターフェースを、微小なフローティングカードや注目を争う第2レコードは使用しないよう依頼しました。
有効なpatternは次のとおりです。
現在のtranscriptは変更しない。同じ5 sceneを固定尺で再renderする。使用するrecordは[client]、[invoice]、[amount]の一つだけ。同じrecordで[state A]から[state B]への変化を見せる。表示するcopyは[whitelist]のみ。観察された誤り[actual incorrect labels and values]を削除する。正確なCTAを[seconds]秒保持する。
CTA frame自体は明瞭でしたが、chapterは1.9秒しかなく、指定したholdより短いものでした。
最後のframeが良いだけでcutを承認しないでください。全体の流れが正確で読みやすい場合だけ承認します。
次のrenderは、修正版にも独自のacceptance checkが必要な理由を示しています。修正cutでは請求書作成sceneに承認済みrecordを残し、そのidentityをledgerまで引き継ぎました。
ledgerも別の架空顧客に変えず、同じ請求書を使いました。修正版の月次summaryでは、承認済みrecordがPaid workに表示され、Outstanding work categoryも架空の合計や「fully settled」という主張なしで残りました。
これは有意な改善です。visible-copy lockとidentity lockは機能しましたが、timing lockは機能しませんでした。
TapVidのproject chatは、6、8、8、9、4秒のsceneで合計35秒にしたと説明しました。しかしdownloadしたMP4は16.833秒で、playerにも圧縮された5 chapterが残っていました。checksumとfile sizeが前版と異なるため、新しいfileであり古いdownloadではありません。revision engineは映像を変更しましたが、指定したpacingは反映しませんでした。
したがって最新版はrevision evidenceとしては有用ですが、最終承認済みのhomepage explainerではありません。editorが制約を適用したと報告しても、publishableと判断する前に、書き出し尺、chapter timing、全編再生を確認してください。
07
7. 書き出して掲載場所でテストする
content reviewを通過したら書き出し、実際のfileを確認します。editorのlabelだけに頼らず、尺とresolutionを調べます。
publish前に次を確認します。
- aspect ratioが掲載場所に合っている。
- voiceoverと字幕の内容が一致している。
- 字幕が同期し、重要なcontrolを隠していない。
- 実際のembed sizeで製品labelが読める。
- すべてのsceneで同じサンプルデータが維持されている。
- CTAの文言が正確で、認識できるだけの表示時間がある。
- watermark、字幕、resolutionの設定が対象channelに合っている。
収録済みmediaのaccessibilityでは、字幕が発話情報を表し、同期している必要があります。W3C Web Accessibility Initiativeの字幕ガイドでは、音声を聞けない人にとっての字幕の役割を説明しています。
最後に、実際に掲載するpage上で動画を見ます。大きなeditorで読めるsceneでも、homepageのcolumnやmobile viewportでは小さすぎることがあります。interfaceが読みにくければ、compositionを簡略化するか、掲載場所専用のcutを作ります。
08
再利用できるSaaS explainer brief
次のprojectでは、この構造をコピーしてください。
この承認済みソース素材[貼り付けまたは添付]を使い、[specific audience]向けの[duration]・[aspect ratio]のSaaS explainerを作る。視聴者が[one product path]を理解し、[CTA]を実行できるようにする。画面上では[scene actions]の状態変化を見せる。使用できるサンプル名、数値、statusは[whitelist]のみ。主張、合計、integration、outcome、customer dataを追加しない。render前にscene planとナレーションを返してreviewを受ける。
その後、source brief、scene action、ナレーション、初回render、全編再生、file metadata、掲載場所の順にreviewします。この順序なら、問題がsource、script、rendererのどこで生じたか判断しやすくなります。
製品文言やscriptがすでにある場合は、TapVidのAI解説動画generatorから始め、review中は信頼できる唯一のソースbriefをprojectの隣に置いてください。
09
実際にpublishできるSaaS解説動画の作り方
最も安全なworkflowは単純です。書き出したfileがscriptと同じcheckを通過するまで、生成動画をdraftとして扱います。source briefで製品情報を制御し、scene planで重要な主張をすべて画面に示します。最終reviewでは、実際のMP4についてidentity、状態変化、尺、copyの可読性、字幕、CTA文言を確認します。
このテストは、試行回数よりrevision qualityが重要であることも示しました。2回目のrenderはサンプルrecordを修正し、根拠のないoutcome labelを削除しましたが、指定した35秒のtiming planは無視しました。この結果から、各revisionにも完全なartifact QAが必要だと分かります。
SaaS explainer video creatorを使うなら、承認済みソース素材と明確な制約を渡し、editorial approvalは人が保持してください。それが、生成された詳細を偶発的な主張に変えず、実在の製品を説明できる動画を作る方法です。
10
よくある質問
| 確認項目 | 安全なdefault |
|---|---|
| ソースは承認済みですか？ | 製品の事実とサンプルデータが固定されるまでrenderしない。 |
| scriptは正しいですか？ | ナレーションを動画とは別に承認する。 |
| renderは正しいですか？ | publish前に書き出したfileをsceneごとに確認する。 |
SaaS解説動画には何を含めるべきですか？
視聴者の問題を一つ、画面で確認できる少数の製品操作、一貫したサンプルデータ、CTAを一つ含めます。各sceneで製品の流れの新しい部分を一つ理解しやすくしてください。
SaaS解説動画の長さはどのくらいが適切ですか？
掲載場所と画面で見せる操作数から尺を決めます。単純な物語をきりのよい秒数まで不必要に延ばさず、label、状態変化、CTAが読めなくなるほどsceneを圧縮しないでください。
SaaS解説動画作成ツールはナレーションも書けますか？
提供した製品素材をナレーションに構成できますが、render前に用語、主張、尺、最終CTAを確認してください。ソース素材を常に最優先の基準にします。
scriptが正しくても、なぜ弱い動画になることがありますか？
visual rendererがinterface copyを追加したり、サンプルデータを変えたり、scene timingを圧縮したり、ナレーションが原因を説明する前に完了状態を表示したりするためです。承認済みscriptとは別に実際の動画をreviewしてください。
画面収録とmotion graphicsのどちらを使うべきですか？
正確なinterface操作自体が証拠になる場合は画面収録を使います。製品の流れや関係を説明することが主目的ならmotion graphicsを使います。hybridは、各形式の役割が明確な場合に有効です。
revision promptには何を含めるべきですか？
失敗したscene、観察した誤り、必要な置き換え、固定データ、尺、表示してよい正確なcopyを書きます。transcriptやvisual directionなど、すでに合格した部分は維持してください。
一つのsceneが悪い場合、動画全体を作り直す必要がありますか？
必ずしも必要ではありません。対象者、物語、CTAが有効ならscene単位で修正します。対象視聴者、製品promise、因果関係が変わった場合は全体を再構築します。
