mcpField
S
saas-product-demo-production

saas-product-demo-production

github.com/calesthioマーケティング・グロース219128 回インストール15 週間前に更新
リポジトリ

saas-product-demo-production について

saas-product-demo-productionは、ソフトウェア製品の概要をデモ動画の制作計画に変換するスキルです。製品、マーケティング、制作チーム向けに、脚本、撮影指示、編集、納品、QAを整理し、根拠、プライバシー、開示事項にも配慮します。

主な機能

  1. 01デモ動画と脚本の計画
  2. 02撮影と生成メディアの指示
  3. 03編集と納品バージョンの整理
  4. 04デモデータとプライバシーリスクの確認
  5. 05主張と開示事項の検証
  6. 06字幕とアクセシビリティの計画

活用シーン

  1. 01新機能のリリースデモ制作
  2. 02営業用またはウェブ用製品デモ制作
  3. 03ヘルプセンターの操作解説計画
  4. 04複数チャネル向け納品とQAの準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/calesthio/generative-media-skills --skill saas-product-demo-production

インストール後、Claude Code で/saas-product-demo-productionを入力して読み込まれたか確認します。

同梱ファイルEVAL.md

詳細

SaaS 製品デモの制作

このスキルを使って、ソフトウェア製品の概要を、本番に使えるデモ動画の企画、台本、収録指示、生成メディア用プロンプト一式、編集計画、納品形式一覧、品質確認まで仕上げます。特定のプロバイダーに依存しないため、特定のツールを前提とせず、実際の画面収録、ブラウザー自動化、合成画面、モーショングラフィックス、アバターによるナレーション、AI 動画生成に合わせて調整できます。

中心となる目的は「UI を見せる」ことではありません。個人情報を露出したり、製品について誇張したりせずに、適切な視聴者に価値あるワークフローを理解してもらい、証拠を信頼してもらい、次に何をすべきかを知ってもらうことです。

必須事項

以下は提案ではなく、制作上の制約として扱ってください。

  1. 視聴者、ユースケース、実証できる内容から始めます。製品のナビゲーションに沿って構成したデモは、たいてい製品紹介に見えます。一方、購入者の業務に沿って構成すれば、解決策として伝わります。
  2. 承認済みのデモ用テナント、投入済みのモックデータ、合成データ、または明示的に使用許可を得た顧客データのみを使用します。本番環境のアカウント、実在する顧客名、社内チケット、API キー、セッショントークン、メールアドレス、決済情報、未公開のロードマップ、管理者コンソール、またはセキュリティ、法務、クライアントの関係者が承認していない分析データを絶対に収録しないでください。
  3. 客観的な主張をナレーション、字幕、画面上のテキスト、サムネイル、広告コピーに記載する前に、そのすべてを裏付けてください。FTC は、広告の主張は真実で、誤解を招かず、証拠に基づくべきであるとしています。また、その裏付けに関する方針では、明示的および暗示的な客観的主張を公開する前に、合理的な根拠を用意することが求められています。このスキルを法的助言として扱わないでください。規制、比較、性能、財務、健康、安全、プライバシー、AI、価格に関する主張は、適切な審査担当者に確認してください。
  4. 必要な開示は、それが補足する主張のすぐ近くに配置します。FTC の .com 開示ガイダンスでは、開示の明確さと視認性、配置の近さ、目立ちやすさ、表示時間、頻度、理解しやすい表現、広告全体が与える印象が重視されています。プラットフォームや短縮版の動画で開示内容を明確に伝えられない場合は、主張を変更するか、その掲載方法を使用しないでください。
  5. 録音済み音声には字幕を付けます。WCAG SC 1.2.2 では、音声を含む録音済みの同期メディアに字幕を付けることが求められています。セリフ、話者の切り替わり、意味のある効果音、重要な非音声の音声を字幕に含めてください。対応プラットフォームでは別添の字幕ファイルを優先し、常時表示で読み取れることが配信状況上必要な場合に限り、字幕を映像に焼き付けます。
  6. 重要な視覚情報を、映像のピクセルだけに頼らず伝えます。デモが画面上の変化に依存している場合は、ナレーションで説明するか、テキストによる代替を用意するか、アクセシビリティに配慮した納品物には音声解説を追加してください。WCAG SC 1.2.5 では、主音声ですでに重要な視覚情報が伝わっている場合を除き、録音済み動画に対して AA レベルで音声解説を付けることが求められています。
  7. テキスト、コールアウト、字幕、UI、開示オーバーレイは読みやすく保ちます。制作グラフィック全体で WCAG のコントラスト基準を守ってください。通常のテキストは少なくとも 4.5:1、大きなテキストと非テキストの UI 表示要素は 3:1 を目安とし、意味の伝達に色だけを使わないでください。
  8. 制作時点で納品仕様を再確認します。プラットフォームの広告仕様、安全領域、再生時間の上限、字幕への対応、ファイルサイズの上限は変わります。このスキルに含まれるプラットフォーム固有の数値は、恒久的な情報ではなく、2026-07-10 時点で確認された変動する例として扱ってください。

スクリプト作成前にデモの種類を決める

主要な種類を1つ選びます。短縮版では別の種類にアレンジしてもかまいませんが、マスター版では軸となる約束を1つに定める必要があります。

デモの種類最適な対象構成避けるべきリスク
機能リリース既存ユーザー、見込み顧客、アナリスト「従来の不便な方法 新機能 効果の証明 試し方」導入前と導入後を示さずに機能を列挙する
セールスデモ購入者/評価担当者「ペルソナの課題 ワークフロー 差別化を示す証拠 購入に向けた次のステップ」価値が明確になる前に UI の詳細を説明しすぎる
プロダクト主導の成長/ウェブサイトのヒーローファネル上部の訪問者「1つのタスク、1つの成果、1つの CTA」UI が小さい、主張が曖昧、次のアクションがない
オンボーディング新規ユーザー「今すぐこのタスクを完了する 次のタスクへの自信をつける」最初に成功する方法ではなく、あらゆる選択肢を説明する
ヘルプセンターの解説サポート問い合わせの削減「症状/問題 正確な手順 確認 トラブルシューティングの分岐」ユーザーが手順を必要としている場面で、マーケティング用語を使う
社内向けイネーブルメント営業/サポート/カスタマーサクセス「トークトラック 根拠となるポイント 反論への対応 デモの進行手順」未承認の主張を現場に教える

ユーザーの依頼が対象者を指定せずに「デモを作って」だけの場合、素材の掲載先から推測できない限り、ペルソナと利用状況を確認してください。15秒のウェブサイト用ヒーロー動画、90秒のリリース告知投稿、4分のヘルプセンター向け解説、12分のセールスデモでは、それぞれ適切なテンポや根拠が異なります。

ヒアリング:最低限の概要

以下の情報を収集するか、推測してください。

  • 製品と機能:正確な名称、ステータス、リリース日、承認済みのポジショニング、UI が最終版かどうか。
  • 対象者:役職、知識レベル、購入者/ユーザーの区別、業界、地域、言語。
  • ユースケース:達成すべき作業、きっかけとなる出来事、現在の回避策、失敗した場合のコスト、望ましい結果。
  • ファネルの段階:認知、検討、トライアルの利用開始、オンボーディング、継続利用、サポート、拡大。
  • 配信先:ウェブサイトのヒーロー、製品ページ、セールスデッキ、ヘルプセンター、メール、有料ソーシャル、オーガニックソーシャル、アプリストア、アプリ内モーダル、カンファレンスブース、社内向けイネーブルメント。
  • 必要な根拠:承認済みの指標、顧客の声、ベンチマーク、認証、連携一覧、製品の動作、または目視できる UI を超える主張をしないこと。
  • コンプライアンス要件:法務、セキュリティ、プライバシー、ブランド、アクセシビリティ、顧客による承認が必要かどうか。
  • キャプチャ方法:実際のアプリのキャプチャ、ブラウザーを使った演出付きキャプチャ、合成 UI の再現、アニメーション付きモックアップ、アプリ風のシーケンスの生成、またはこれらの組み合わせ。
  • デモ環境:テナント URL、権限、モックデータのソース、リセット手順、「表示禁止」リスト。
  • 納品物:マスター版の長さ/アスペクト比、短縮版、字幕、サムネイル、トランスクリプト、ソーシャル用コピー、ローカライズ版、ソースプロジェクトファイル。

概要が不完全な場合は、慎重な計画を立て、前提を明記してください。製品の機能、指標、顧客の実績、認証、連携、リリース日を創作してはいけません。

ペルソナとユースケースの組み立て

視聴者の具体的な思考を軸にデモを構成します。

「この問題がある。この画面には見覚えがある。この製品でより良い状態になれるとわかる。そして、根拠を信頼できる。」

次のテンプレートを使って組み立てます。

  • ペルソナ:「従業員300人の SaaS 企業の RevOps マネージャー。」
  • きっかけ:「四半期末の予測レビューが明日に迫っている。」
  • 課題:「パイプラインの変更が CRM のメモ、スプレッドシート、Slack に分散している。」
  • 望ましい結果:「何が変わったのか、なぜ変わったのか、どの商談に対応が必要なのかを把握する。」
  • 懸念:「ワークフローが壊れたり、機密データが漏れたりしないか?」
  • 必要な根拠:「UI でのリアルタイム同期、対応する連携、権限モデルの開示、利用可能であれば承認済みの時間短縮指標。」
  • CTA:「トライアルを開始する」「ワークフロー監査を予約する」「セットアップガイドを読む」「機能を有効にする。」

対象者に前提知識が本当に必要な場合を除き、会社の沿革、製品カテゴリーの定義、ダッシュボード全体の紹介から始めてはいけません。

ストーリーラインのパターン

次のいずれかのパターンを使い、内容を調整してください。

問題 ワークフロー 成果

営業デモ、ローンチ動画、ヒーローデモ、PLG ページに最適です。

  1. フック:視聴者自身の言葉で、苦労している作業を明確にします。
  2. 導入前の状態:従来の煩雑さを手短に見せます。
  3. 転換点:製品の機能を紹介します。
  4. ガイド付きワークフロー:各ステップの進捗を見せながら、3~5 ステップで進めます。
  5. 成果:完成した成果物、決定事項、省けた手順、または軽減されたリスクを見せます。
  6. 根拠と制限:承認済みの証拠で裏付け、必要に応じて適用範囲を明確にします。
  7. CTA:次のアクションを 1 つ示します。
タスク 手順 確認

オンボーディングやヘルプセンターの動画に最適です。

  1. ユーザーの目標を伝えます。
  2. 前提条件を示します。
  3. 飾り立てずに手順を実行します。
  4. 成功した状態を見せます。
  5. トラブルシューティングの分岐、または「これが表示されない場合」の注記を加えます。
  6. CTA:次のタスク、ドキュメントへのリンク、またはサポートへの問い合わせ方法を示します。
懸念 根拠 次のステップ

エンタープライズ営業、セキュリティ重視の製品、管理者向け機能に最適です。

  1. 懸念を尊重する姿勢で取り上げます。
  2. 制御機能、監査証跡、権限、または証拠を見せます。
  3. 適用範囲と制限を明確にします。
  4. 購入検討者が確認できる資料、または次回の打ち合わせでのアクションを提示します。

機能の優先順位付け

短いデモでは通常、主要なワークフローを 1 つと、それを補足する要素を 2 つ取り上げられます。次の順で優先します。

  1. 製品の約束を実証する場面。
  2. 視聴者が自分の業務で見覚えのある画面の状態。
  3. 成果に至る最短の道筋。
  4. 主張するだけでなく、目に見える差別化要素。
  5. 最も多い懸念に答える機能。

次の要素は省きます。

  • セットアップが主題でない限り、設定画面。
  • ナビゲーションの寄り道。
  • 価値を示した後の、空の状態についての説明。
  • 別途説明が必要になる二次機能。
  • 短い動画で安全に扱うには、長い開示説明が必要な主張。

複雑な製品では、「スパインデモ」のマスター版に加え、モジュール式の挿入パートを作成します。統合、セキュリティ、管理者向け、モバイル、価格・パッケージ、業界別の各パートです。

データとプライバシーに配慮したデモ環境

文書化された事実:NIST SP 800-122 は、PII を不適切なアクセス、使用、開示から保護すべきとしています。NIST SP 800-188 は、非識別化を識別データとデータ主体との関連付けを取り除くことと定義し、マスキングだけでは非識別化に不十分な場合があると警告しています。

本番環境でのルール:すべての承認が明示され、文書化されていない限り、デモで実際の個人データや顧客データを使用しないでください。

次の優先順位に従ってください。

  1. 架空のアカウント、組織、日付、メッセージ、支払い、ドキュメント、分析データを用意した、デモ専用のテナント。
  2. 実在の人物や顧客に紐付かず、実際のワークフローを再現する合成データセット。
  3. プライバシー/セキュリティの承認と再識別リスクのレビューを得た後に限り、匿名化または非識別化されたデータ。
  4. 顧客の書面による許可、セキュリティ/プライバシー/法務の承認、キャプチャ用チェックリストがそろっている場合に限り、実際の顧客データ。

キャプチャ前に以下の情報を消去してください。

  • 氏名、顔、アバター、メールアドレス、電話番号、自宅住所。
  • 顧客のロゴ、ドメイン、ファイル名、Slack チャンネル、Jira チケット、サポートケース。
  • API キー、トークン、シークレット、OAuth 同意画面、ブラウザー拡張機能、ブックマーク。
  • 内部ホスト名、ステージング URL、機能フラグ、管理者 ID、デバッグオーバーレイ。
  • 売上、健康、人事、法律、セキュリティ、または財務に関する記録。
  • 通知ドロワー、自動入力の候補、タイミングが重要な場合はシステム時計。
  • ブラウザーの履歴、OS のメニューバー、デスクトップの壁紙、ローカルファイルのパス。

物語上の目的に沿ってデモデータを作成してください。表示される各行がストーリー展開に役立つようにします。理解の助けになる架空の顧客名、タスク名、ワークフロー名がある場合は、意味のないダミーテキストを避けてください。現実的な名称が混乱を招く可能性がある場合は、「Northstar Robotics Demo Co.」や「Sample Customer」のような、明らかに架空の名称を使用してください。

セキュリティ担当者および法務担当者へのエスカレーションが必要となる条件:

  • 実際の顧客、ロゴ、引用、ベンチマーク、セキュリティ認証、規制対象のワークフロー、または AI に関する主張が含まれる。
  • デモに管理者向けコントロール、権限、監査ログ、データのエクスポート、削除、プライバシー設定、暗号化、認証、またはコンプライアンスのワークフローが表示される。
  • 法令遵守、節約額、創出される収益、リスク低減、医療/財務上の成果、雇用に関する判断、公共部門での利用、子ども、または規制対象の業界に関する主張が含まれる。
  • 録画に本番環境へのアクセスまたは昇格された権限が必要となる。

キャプチャと合成画面のプランニング

プロダクトの価値を実証できる方法のうち、最もリスクの低いキャプチャ方法を選びます。

方法使用する場面強み注意点
実画面の録画UI が完成しており、動作の真正性が必要な場合プロダクトの実態を最も忠実に伝えられますデモ用テナント、安定したネットワーク、プライバシー情報のマスキング、撮り直しが必要です
ブラウザー自動化によるキャプチャフローが決定的で、ウェブベースの場合繰り返し可能で、カーソルが見やすく、バリエーションを再利用できますセレクター、アプリ状態のリセット、レスポンシブなビューポートの確認が必要です
合成 UI の再現実データにリスクがある場合や、UI が未完成の場合プライバシーに配慮でき、演出を細かく調整でき、ヒーロー動画でも鮮明に見せられます未提供の機能があるように見せてはいけません。必要に応じてシミュレーションであることを明示します
モーショングラフィックスによる抽象表現ワークフローが概念的、または複数のデバイスにまたがる場合小さな UI に頼らず、メリットを伝えられます実際のプロダクトによる証明がなければ、曖昧になりがちです
AI 生成のアプリ風映像正確なプロダクトの動作ではなく、雰囲気づくりや概念的な B ロールが必要な場合雰囲気のある映像を素早く作れますUI の幻覚を避け、実際のプロダクトの動作を正確に再現したものとして見せてはいけません

録画の前に、キャプチャシートを作成します。

  • フロー名と目的。
  • ビューポート:デスクトップ 16:9、デスクトップ 4:5 のクロップセーフ、モバイル 9:16、タブレット、またはレスポンシブセット。
  • ブラウザー/アプリの状態:ログイン中のロール、シードデータ、有効なフラグ、ズームレベル、リセット済みの Cookie。
  • 各クリック後に想定される画面状態を含むステップ一覧。
  • カーソルの動き:一時停止する場所、クリックする場所、ホバーしない場所。
  • コールアウト:テキスト、表示タイミング、対象の UI 要素、ナレーション、グラフィック、またはその両方のどれで示すか。
  • セーフゾーン:キャプション、CTA、プロダクトナビゲーション、プラットフォームの UI オーバーレイを配置する場所。
  • プライバシー上のリスクと、情報をマスキングする方法。
  • 撮り直しの条件:スピナー、通知、誤字、誤った日付、実データ、カーソルのぶれ、意図しないホバー、フレーム落ち、ネットワークの遅延。

高解像度でキャプチャし、バリエーション向けに縮小します。デスクトップ UI では、1440p または 4K でキャプチャするとズーム用の余裕が生まれます。最終出力が 1080p の場合は、ズームしたテキストが鮮明に見えるようにします。モバイルファーストのデモでは、後からデスクトップ画面をクロップするのではなく、9:16 で直接キャプチャするか、9:16 向けに構成します。

カーソル、ズーム、コールアウトの演出

カーソルとズームは、スクリプトの一部です。

  • 視聴者が次の操作を予測できるくらい、ゆっくり動かします。マウスを細かく不規則に動かすのは避けます。
  • 視聴者がクリック対象を確認できるよう、クリックの前に一時停止します。
  • ズームは装飾ではなく、意図を伝えるために使います。ステップを実証するフィールドや結果にズームしてから、全体の表示に戻します。
  • 1 つのビートにつき、コールアウトは 1 つを基本にします。矢印を 3 つ同時に出す必要があるなら、そのシーンには要素を詰め込みすぎている可能性があります。
  • コールアウトは具体的な行動を伝えるものにします。「連携」よりも「Salesforce から自動入力」のほうが効果的です。
  • コールアウトは UI 要素の近くに配置しつつ、キャプション、プラットフォームのボタン、開示情報の表示領域には重ねないようにします。
  • 一貫したビジュアル表現を保ちます。機能ラベル、警告/開示情報、CTA にはそれぞれ異なるスタイルを使います。
  • モバイル向けのバリエーションでは、親指での操作とプラットフォームのオーバーレイを考慮してコールアウトを設計します。一般的なソーシャル UI に隠れる可能性がある画面の上端・下端には、重要なテキストを配置しないでください。TikTok によると、セーフゾーンの寸法はフォーマット、キャプションの長さ、追加要素によって異なるため、最終書き出しの前に最新のセーフゾーンテンプレートを確認してください。

3 段階の明瞭さテストを行います。

  1. 無音テスト:音声をオフにしても、UI、キャプション、コールアウトからフローを理解できますか?
  2. 小画面テスト:スマートフォンの画面サイズでも、重要な UI の状態と CTA を読めますか?
  3. 音声のみのテスト:映像がなくても、ナレーションから重要な成果が伝わりますか?

ナレーションと台本

すべてのクリックを逐一読み上げるのではなく、UIのそばで案内するナレーションを書きます。

優れたデモナレーション:

  • 視聴者が何をしたいのかを示します。
  • その手順が重要な理由を説明します。
  • 見れば分かるクリックは読み上げません。
  • UI上の具体的な名詞を使います。
  • 視覚的な証拠を見せる場面に余裕を持たせます。
  • 必要に応じて制限事項を率直に伝えます。
  • ファネルの段階に合ったCTAで締めくくります。

避けること:

  • 重要な点を説明せずに「ここでご覧いただけるように」と言うこと。
  • すべてのボタン名を繰り返すこと。
  • 根拠のない最上級表現。
  • 短いマーケティングデモでセットアップを過度に説明すること。
  • 購入者へのメリットとユーザー向けの手順を同じ文に混在させること。

台本のビート形式:

00:00-00:04 Hook
Visual: Split before-state of spreadsheet + inbox + CRM card.
Narration: "Forecast changes should not take three tools to explain."
On-screen text: "Know what changed before forecast review."
Claim/proof: No quantified claim.

00:04-00:13 Product turn
Visual: Open Acme Pipeline Monitor demo tenant. Filter to "changed this week."
Cursor: Pause over filter, click once, no hover wandering.
Narration: "In Pipeline Monitor, RevOps sees every deal that changed this week in one review queue."
Callout: "One queue for changes"
Claim/proof: Observable UI only.

テキスト読み上げの場合は、読み上げやすい句読点を使います。短い文、明示的な間、製品名の発音メモを含めます。人間のナレーションの場合は、強調する箇所と速度の指示を含めます。アバターデモでは、長い間画面が変わらない状態を避け、頻繁に画面に戻します。

根拠と主張の取り扱い

すべての主張を分類します。

主張の種類例必要な対応
観察可能な製品の動作「オーナーで絞り込む」、「CSVをエクスポートする」、「チームメイトを招待する」UIで実際の動作を見せる。現行の製品と照合してQAを行う
説明的なポジショニング「ローンチ計画のためのワークスペース」承認済みのメッセージングと照合する
定量的なパフォーマンス「週6時間を削減」、「2倍高速」、「稼働率99.99%」根拠資料、日付、適用範囲、承認を必須とする
比較表現「スプレッドシートより優れている」、「Vendor Xより高速」エスカレーションする。根拠と慎重な表現が必要
セキュリティ/プライバシー/コンプライアンス「SOC 2 ready」、「HIPAA compliant」、「デフォルトでプライベート」セキュリティ/法務部門にエスカレーションし、承認済みの正確な表現を使う
AIの機能「リスクを検出する」、「正確に要約する」、「意思決定を自動化する」製品の動作を検証する。該当する場合は、人間による確認や制限事項を開示する
お客様の声/導入効果「お客様が100万ドルを削減」使用許可、一般性/開示に関する確認、情報源の承認を必須とする

主張の台帳を作成します。

Claim: "Cuts weekly forecast prep from hours to minutes."
Where used: 60s launch video narration 00:42, end card, LinkedIn copy.
Type: Quantified/implied performance.
Evidence: Approved customer study? Internal benchmark? None yet.
Status: Not approved. Rewrite to "shortens the handoff from scattered updates to one review queue" unless evidence is supplied.
Reviewer: Marketing/legal.

主張に開示が必要な場合は、その主張と同じビートの動画プランに開示内容を入れます。広告単体でも誤解を招く全体的な印象を避けられる場合を除き、ソーシャルキャプションやランディングページ任せにしないでください。

デモプランを生成メディア用プロンプトに変換する

生成メディアは製品デモを補助できますが、製品の事実を捏造してはなりません。「正確なUIキャプチャ」と「概念を補助するメディア」を分けてください。

合成または生成シーン向けのプロンプト構成:

Intent: Explain the benefit of [feature] for [persona] without pretending to show real product UI.
Scene: [screen/device/environment], [composition], [motion].
UI fidelity rule: Use abstracted panels and generic labels; do not invent real buttons, customer data, metrics, logos, or certifications.
Narrative beat: [problem / workflow / outcome].
Privacy rule: Use fictitious names and domains; no real brands unless approved.
Text overlays: [exact approved overlay text].
Camera/motion: [zoom, pan, cursor, callout, transition].
Accessibility: Leave lower caption band clear; high contrast; no color-only meaning.
Negative constraints: no real customer logos, no API keys, no unreadable microtext, no fake dashboards implying unsupported analytics.

正確な製品のウォークスルーでは、提供されたスクリーンショットやキャプチャ映像を参照として使用し、UIの事実を忠実に保つようツールに指示します。モデルがUIテキストを確実に保持できない場合は、製品の根拠を示す用途には使わず、背景の動きにのみ使用します。

曖昧さが問題になる場合は、シミュレーションであることを明記します。

  • 「シミュレーションデータを表示」
  • 「概念を視覚化したもの」
  • 「ワークフローの例」
  • 「分かりやすさのため、画面を短縮しています」

編集のペース配分

ペースは視聴者の状況に合わせます。

  • Webサイトのヒーロー動画:10~30秒。ワークフローを1つ印象づけ、ほぼ無音でも内容が伝わるようにし、CTAを早い段階と終盤に表示します。
  • 有料/オーガニックソーシャル:15~45秒。最初の1~3秒で視聴者の関心を引き、5~8秒までに製品の価値を示し、見やすい字幕とセーフゾーンを確保します。
  • 機能のローンチ:45~90秒。導入前後の比較、3~5つのワークフローの場面、価値の証明、CTAを含めます。
  • オンボーディング:タスクごとに30~180秒。カーソルの動きをゆっくりにし、正確な手順を示し、成功を確認します。
  • ヘルプセンター:必要な長さにしますが、セクションに分けます。タスクの完了を遅らせるようなマーケティング向けの演出は避けます。
  • 営業用資料:2~5分。ペルソナに応じた価値、懸念への対応を示す根拠、チャプター分けしたセクションを含めます。

編集の指針:

  • ログインページではなく、成果や課題から始めます。
  • 速度そのものが価値の証明となる場合を除き、待機中の画面は取り除きます。必要に応じて、目立たないジャンプカットを使い、「処理中」と表示します。
  • UIを読みやすく保つためにズームカットを使いますが、見ていて戸惑うようなカメラの動きは避けます。
  • 複雑な画面では、コールアウトを表示した後に少なくとも1拍分の時間を取ります。
  • 理解の助けになる場合に限り、チャプターカードを使います。
  • 適切な場合は、音声、画面上のテキスト、エンドカードでCTAを伝えます。
  • 字幕とテキストで「音声なしでも理解できる」流れを用意します。

モバイル、デスクトップ、短縮版のマトリックス

録画前にアスペクト比を計画します。安全にトリミングできないマスタータイムラインは、修正にコストがかかります。

SaaS デモでよく使われる納品形式:

バリエーション用途備考
16:9 横向きYouTube、Webサイト、営業資料、ヘルプセンター、ウェビナーのフォローアップ情報量の多いデスクトップ UI や長めの操作説明に最適です
4:5 縦向きフィードLinkedIn/フィード掲載UIの読みやすさとモバイルフィードの高さのバランスが良好です
1:1 正方形フィードとの互換性、サムネイル簡素化した UI には適していますが、ダッシュボード全体の表示にはあまり適しません
9:16 縦向きShorts/Reels/TikTok/モバイルアプリのデモコールアウトの再設計が必要で、多くの場合、モバイル専用の UI が必要です
GIF/ループ製品ページの短いデモ、メール音声なしでも伝わるテキストと非常に短いループを使い、ファイルサイズに注意します
静止画営業資料、ドキュメント動画から価値を示す重要な場面をキャプチャします

2026-07-10 時点で確認済みの例:

  • LinkedIn の動画広告仕様では、横向き 16:9、正方形 1:1、縦向き 4:5、縦向き 9:16 の各オプションについて、最小/最大寸法とアスペクト比の許容誤差 5% が定められています。
  • Google Ads API の Performance Max アセット要件では、YouTube 動画のアスペクト比は 16:9、1:1、9:16、長さは 10 秒以上とされています。
  • TikTok のインフィード広告ガイダンスでは、セーフゾーンのサイズは寸法、キャプションの長さ、追加要素によって異なると説明されており、ダウンロード可能なセーフゾーンファイルが提供されています。

プラットフォームの最新の公式ガイダンスと、広告/製品の具体的な掲載面を再確認せずに、これらを最終納品物に固定しないでください。

キャプション、アクセシビリティ、ローカライズ

以下を用意します。

  • タイムコード付きキャプション:プラットフォームやプレーヤーに応じてSRTまたはWebVTTを使用します。WebVTTは、キャプション、字幕、説明、チャプター、その他の時間に同期したメタデータに対応するW3Cのテキストトラック形式です。
  • トランスクリプト:リンク、手順、関連する開示事項を含む、読みやすく整えたテキストです。
  • SNSでの配信時に常時テキストを表示する必要がある場合は、キャプションを動画に焼き込んだバージョンを用意します。
  • プラットフォームがアクセシビリティ対応のサイドカーペションをサポートし、クライアントがクリーンなアーカイブを必要とする場合は、キャプションなしのマスターを用意します。
  • 重要な視覚情報がメイン音声で伝わらない場合は、音声解説版またはナレーションで内容をすべて説明する版を用意します。

キャプションの品質チェックリスト:

  • 読みやすさを意図して編集した箇所を除き、キャプションは発話内容と一致しています。
  • 必要に応じて、話者の切り替わりが分かるようになっています。
  • 意味のある効果音が含まれています。
  • キャプションが重要なUI、カーソルの操作対象、開示事項を覆っていません。
  • 意味のまとまりに沿って改行されています。
  • 想定するプラットフォームと視聴者にとって、快適な速度で読めます。
  • 製品名、頭字語、専門用語が正しく表記されています。
  • UIや動きの上でも、キャプションを読みやすく表示できます。

ローカライズの計画:

  • ナレーション、キャプション、UI、デモデータ、CTA、法務関連のテキストや開示事項のうち、どれをローカライズするか、またはすべてをローカライズするか決めます。
  • スクリーンショットにローカライズ済みのUIを表示する必要があるか、または原文言語のUIに翻訳済みキャプションを重ねてもよいか確認します。
  • 慣用表現や文化に特有の例は置き換えます。単語をそのまま翻訳するだけでは不十分です。
  • レイアウトに余裕を持たせます。翻訳後の文字列は長くなる場合があります。
  • 地域ごとに、主張、価格、提供状況、コンプライアンスに関する記述を再確認します。
  • デモデータでは、その地域に適した日付、数値、通貨、住所、氏名の形式を使用します。
  • 規制対象または比較に関する主張については、現地レビュアーの承認を得ます。

CTAの設計

視聴者の検討状況に合わせてCTAを設定します。

  • 認知段階:「ワークフローを見る」「デモの全編を見る」「テンプレートを確認する」。
  • 比較検討段階:「デモを予約する」「プランを比較する」「セキュリティ概要を読む」。
  • トライアル/オンボーディング段階:「最初のプロジェクトを作成する」「ワークスペースを接続する」「サンプルデータをインポートする」。
  • 利用拡大段階:「連携機能を有効にする」「チームを招待する」「高度なルールを試す」。
  • サポート:「セットアップガイドを開く」「サポートに問い合わせる」「権限を確認する」。

CTAは目立たせ、具体的な内容にします。遷移先が明確で、コンテンツの目的が幅広い認知獲得である場合に限り、「詳しく見る」のような曖昧な表現も使用できます。

ステークホルダーによるレビュー

リスクに応じてレビューを依頼します。

  • プロダクト:UIの正確性、機能の提供状況、ロードマップ/リリース時期。
  • プロダクトマーケティング:ポジショニング、対象者、CTA、競合に関する主張。
  • 営業/カスタマーサクセス:反論への対応、購入者との関連性。
  • ブランド/デザイン:ビジュアルシステム、トーン、ロゴ、モーションスタイル。
  • 法務/コンプライアンス:主張、開示事項、推薦コメント、規制対象のコンテンツ。
  • セキュリティ/プライバシー:データの露出、デモ用テナント、管理者/セキュリティ画面。
  • アクセシビリティ/ローカライズ:キャプション、コントラスト、トランスクリプト、代替テキスト/音声解説、地域や言語に応じた品質。
  • 顧客/パートナー:ロゴ、引用、連携機能、共同マーケティングへの言及。

レビューパケットを使用します。

Video link:
Transcript:
Claims ledger:
Disclosure list:
Demo data source:
Do-not-show checklist:
Delivery matrix:
Open questions:
Approval requested from:
Deadline:

タイムコード付きのフィードバックを必須にします。「もっと力強く」のようにタイムコードのないフィードバックは、実施前に具体的な編集内容へ落とし込みます。

デモのQA

レンダリング済みファイルとアップロード/プレビュー画面でQAを実施します。

コンテンツと正確性:

  • デモの流れが現在の製品と一致していること。
  • 裏付けのない機能、指標、連携、認証、価格、リリース時期が含まれていないこと。
  • UIの表現が承認済みのメッセージと一致していること。
  • カットをまたいで製品の状態に矛盾がないこと。
  • CTAが正しい遷移先を指していること。

プライバシーとセキュリティ:

  • 実際のPII、顧客データ、シークレット、内部URL、デバッグログ、管理者限定の危険情報、通知漏れが含まれていないこと。
  • 必要な箇所で、モックデータが明らかに架空のものであること。
  • 機密性の高いワークフローに必要な承認があること。
  • アップロードのメタデータ、ファイル名、サムネイル、キャプションもサニタイズされていること。

主張と開示事項:

  • すべての客観的な主張がクレーム台帳に記載されていること。
  • 根拠に、担当者/日付とともにリンクまたは参照が付いていること。
  • 必須の開示事項が、十分に近い位置に、十分な大きさと表示時間で、理解しやすい言葉で表示されていること。
  • 短縮版でも、全体として誤解を招かない印象を与えること。

アクセシビリティ:

  • キャプションがあり、同期され、読みやすく、完全であること。
  • テキストのコントラストが十分であること。
  • 色だけに意味を担わせていないこと。
  • 重要な視覚情報のみの内容が、ナレーション、説明、またはトランスクリプトで確認できること。
  • ウェブページやインタラクティブなランディングページで使用する動き続ける/点滅する/自動更新される要素は、必要に応じて一時停止/停止/非表示にできること。WCAG SC 2.2.2では、動き続けるコンテンツや点滅するコンテンツは注意をそらし、利用を妨げる可能性があると警告しています。

技術面:

  • 配信先ごとに、正しいアスペクト比、解像度、フレームレート、コーデック、音声ミックス、ラウドネス目標、ファイル名、ファイルサイズであること。
  • フレーム落ち、カーソルのカクつき、圧縮アーティファクト、読めない極小テキスト、キャプションの切れ、安全領域との重なりがないこと。
  • 最初のフレーム、サムネイル、タイトル、キャプション、トランスクリプト、ソーシャル投稿文が動画と一致していること。
  • プラットフォームのアップロードプレビューが書き出しファイルと一致していること。

例:PLG機能のローンチ

例の目的:カスタマーサクセスマネージャー向けに、AI会議要約機能の60秒のローンチ動画を作成します。

ブリーフ:

  • ペルソナ:40アカウントを担当するCSM。
  • ユースケース:通話メモをフォローアップタスクに変換する。
  • 主な実証内容:観察可能なUIで要約とタスクが作成されること。時間短縮に関する定量的な主張は承認されていない。
  • キャプチャ:デモテナントでブラウザー自動化を使用。
  • 納品物:16:9のウェブサイト/製品ページ用マスター、4:5のLinkedIn用短縮版、9:16のソーシャル用ティーザー、キャプション、トランスクリプト。

ストーリーライン:

00:00-00:04 Hook
Visual: Calendar call ends, inbox and CRM tasks are empty.
Narration: "After the call, the real work is remembering every promise."
Text: "Turn calls into follow-up tasks"
Claim: Descriptive only.

00:04-00:12 Before state
Visual: Demo account "Northstar Robotics Demo Co." with recent call transcript.
Narration: "Instead of rewriting notes by hand, open the account timeline."
Cursor: Pause on "Latest customer call" then click.

00:12-00:28 Workflow
Visual: Click "Generate follow-up." Summary appears; tasks are suggested.
Narration: "The assistant drafts the summary, pulls out next steps, and keeps the account owner in control before anything is saved."
Callouts: "Draft summary", "Suggested tasks", "Review before saving"
Disclosure: If AI output can be inaccurate, include approved wording such as "Review AI-generated content before use."

00:28-00:42 Outcome
Visual: Save tasks; CRM timeline updates.
Narration: "Now the handoff is attached to the account, not buried in a private note."
Claim: Observable UI only.

00:42-00:53 Objection proof
Visual: Permission note or admin setting if approved.
Narration: "Admins can control who can use AI summaries for customer calls."
Claim: Security/admin; requires product/security approval.

00:53-00:60 CTA
Visual: End card with product UI behind it.
Narration: "Enable AI summaries for your team from workspace settings."
Text: "Try AI summaries in Workspace Settings"

コンセプトを示すオープニング用の生成メディアプロンプト:

Create a clean SaaS motion-graphics opener for customer success managers after a video call.
Show abstract panels representing a calendar, CRM account, and task list converging into one organized workflow.
Use fictitious labels only: "Northstar Robotics Demo Co.", "Renewal follow-up", "Demo workspace."
Do not show real brand logos, real customer data, measurable time-saving claims, or exact product UI.
Leave the lower 20% clear for captions. Use high-contrast text and do not rely on color alone.
Motion: quick but readable 3-second transition from scattered notes to organized task cards.

この方法が有効な理由:製品の動作を根拠として示し、未承認の「時間を節約」という指標を避け、AIによるレビューに関する制限に対処し、セキュリティに関する表現は承認まで保留します。

例:ヘルプセンターの操作ガイド

例の目的:適切なロールでユーザーを招待する方法を管理者に示す、2分間のサポート動画を作成します。

計画:

  • タスクのステップから検証までを使います。
  • デモテナントで正確なUIをキャプチャします。
  • 操作説明の妨げになる場合は、音楽を使用しません。
  • カーソルの動きをゆっくりと一定にします。
  • サイドカーファイルのキャプション、トランスクリプト、記事への埋め込みを納品します。

スクリプトの概要:

00:00-00:08 Goal and prerequisite
Narration: "This video shows workspace admins how to invite a teammate and assign a role. You need admin access before you begin."
Visual: Settings page already open; no login sequence.

00:08-00:35 Open member settings
Narration: "From Settings, choose Members, then Invite teammate."
Cursor: Pause on Members, click; pause on Invite teammate, click.
Callout: "Settings  Members"

00:35-01:05 Enter safe demo data
Narration: "Enter the teammate's work email. In this demo, we'll use a sample address."
Visual: [email protected] or other reserved/demo-safe domain approved by the team.
Privacy note: No real email addresses.

01:05-01:35 Choose role
Narration: "Choose the least-permissive role that fits the work. Viewer can read projects, Editor can make changes, and Admin can manage billing and members."
Visual: Role dropdown.
Callout: "Use least-permissive access"
Claim: Product behavior; verify role definitions.

01:35-01:55 Verify invite
Narration: "After sending, confirm the invite appears as Pending. If it does not, check your permission level or contact your workspace owner."
Visual: Pending invite row.

01:55-02:00 CTA
Narration: "For bulk invites, open the CSV import guide linked below."

QAの重点項目:ボタン名が正確であること、ロールの定義、ドロップダウンにキャプションが重ならないこと、実際のメールアドレスが含まれていないこと、トランスクリプトがサポート記事と一致していること。

例:エンタープライズ営業デモへの挿入動画

例の目的:監査ログを評価しているセキュリティ重視の購入者向けに、45秒の挿入動画を作成します。

アプローチ:

  • 承認されていない限り、「エンタープライズ級のセキュリティ」のような広範な表現は使用しません。
  • 正確なコントロールと、購入者が検証できる内容を示します。
  • 主張の範囲を絞り、「管理者は監査イベントをエクスポートできます」とし、「完全に準拠しています」とはしません。

ビートプラン:

00:00-00:06 Objection
Narration: "Security teams need to know who changed access before a review."
Visual: Abstract lock-to-audit-log transition, not a real incident.

00:06-00:26 Product proof
Narration: "In the admin demo workspace, filter audit events by member, action, and date range."
Visual: Audit log filters in demo tenant.
Cursor: Click filter fields slowly.
Callout: "Member", "Action", "Date range"

00:26-00:37 Export
Narration: "Export the filtered events for your review process."
Visual: Export modal with synthetic data only.
Disclosure: "Example data shown" if needed.

00:37-00:45 CTA
Narration: "Ask your account team for the security review packet."
Text: "Request security review packet"

関係者が「SOC 2準拠」「GDPRを満たす」「HIPAA対応」「ゼロトラスト」「侵害を防止」などの表現を追加したい場合は、エスカレーションしてください。これらの主張には、正確な承認済みの表現と裏付けが必要です。

参照元と確認に関する注記

文書化された制約の確認にあたり参照した情報源です。2026-07-10に確認しました。

変動する情報:プラットフォームの仕様、アップロード制限、広告掲載ルール、セーフゾーン、字幕ファイルのサポート、主張や開示に関するガイダンスの適用は変更される可能性があります。公開前に、実際に配信する媒体に適用される公式のプラットフォーム、法律、アクセシビリティに関する情報源を再確認してください。

コメント