SaaS解説動画の作り方：7ステップのワークフロー

1. 掲載場所、対象者、次の行動を一つずつ決める

機能一覧から始めないでください。まず動画を掲載するページやチャネルを決めます。

ホームページ用の解説動画は、通常次の3点にすばやく答える必要があります。

• 誰のための動画ですか？
• その製品は、どの問題を理解または処理する助けになりますか？
• 視聴後に何をしてほしいですか？

InvoiceFlowのテストでは、複数のツールで請求書を管理するフリーランサーを対象者にしました。物語の役割は一つです。請求書が作成され、支払状況が変わり、月次summaryに入るまでを見せます。CTAは「1か所で1か月を確認する」に固定しました。

この境界があると、動画があらゆるdashboardの紹介になるのを防げます。同時にacceptance testにもなります。視聴者がその流れを理解する助けにならないsceneは、この版には不要です。

掲載場所はテンポにも影響します。ホームページ動画なら製品操作を認識できるよう数秒残せます。広告向けsocial cutでは、より速いscene切り替えが必要かもしれません。onboarding動画では、具体的なcontrolを長く見せられます。目標尺を決める前に掲載場所を選びます。

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とナレーションに構成できます。物語を作れるだけの製品情報を渡しつつ、製品チームが答えるべき空白を補わせないでください。

3. 物語を画面上の状態変化に変える

scene outlineには、ナレーターの発言だけでなく、画面上で何が変わるかを書きます。

InvoiceFlowの物語は5つのbeatで構成しました。

各行に状態変化がある点に注目してください。「dashboardを見せる」だけでは不十分です。「支払いが入ったとき、同じ請求書をSentからPaidに変える」なら完成動画で確認できます。

ナレーションも同じように範囲を絞ります。承認済みscriptの中盤は次の文でした。

1か所で請求書を作成し、送信します。

支払いが入ると、一つのledgerに記録されます。

映像が仕組みを示し、voiceoverが視聴者を案内します。1文のナレーションで3つの製品操作を挙げると、sceneは小さなcardの寄せ集めになりがちです。

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です。

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を正確に確認します。

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を繰り返すより強い指示です。

Composition lock。 読める大きさの目標を指定します。主要interfaceが画面の55〜70%を占め、小さなfloating cardや競合する2件目のrecordを置かないよう指定しました。

有効な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、全編再生を確認してください。

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を作ります。

再利用できる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の隣に置いてください。

実際に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は人が保持してください。それが、生成された詳細を偶発的な主張に変えず、実在の製品を説明できる動画を作る方法です。

よくある質問