解説動画プロンプト調査：33件のブリーフを分析

01

私たちが分析したこと

ソースは、TapVid が内部で厳選した Good Case ライブラリの凍結された 9 月 1 日の 2026 エクスポートでした。完全なプロンプト、パブリック共有 URL、生成 URL、および MP4 添付ファイルが含まれている場合にのみ、レコードを含めました。これにより、64 ブリーフの厳密なコーパスが生成されました。タグは重複する可能性があるため、1 つのレコードが複数の分析スライスに属することができます。この記事では、説明者としてタグ付けされた 33 レコードを使用します。

各プロンプトには、10 個の明示的なフィールドに対する決定論的なキーワード辞書を使用してコーディングしました。

このメソッドは、フィールドがプロンプト テキストに表示されるかどうかを測定します。作成者が製品設定で同じフィールドを選択したか、アップロードを通じて指定したかどうかは測定されません。また、出力品質をランク付けするものでもありません。ライブラリには、各世代のランダムなサンプルではなく、選択された例が含まれているため、結果は厳選された出力間の計画パターンを説明します。因果関係や成功率を確立するものではありません。

ここでは、個人顧客へのプロンプトは再現されません。調査結果は集約されたもので、後で示すケースは既存の公開共有ページにリンクされています。

02

解説ビデオプロンプトのベンチマーク結果

Inspect image

中央値のプロンプトには、3,621 文字が含まれていました。この数字は説明的なものであり、目標ではありません。アセット、承認されたコピー、および出力設定が個別の構造化フィールドを介して到着する場合は、短い概要が機能します。長い準備書面でも、雰囲気を詳細に説明していても、どのスクリーンショットがどの主張に属しているのかを特定していない場合は失敗する可能性があります。

製品チームにとって 3 つの発見は重要です。

まずビジュアルディレクションは表現しやすいので一般的です。色、カメラ、タイポグラフィ、モーション、雰囲気はすべてプロンプトに自然に適合します。第 2 に、プロダクトの真実の層の一貫性が低くなります。事実を明示的に明らかにしている準備書面は半分にも満たない。第三に、多くの場合、視聴者のコンテキストが想定されます。 33 ブリーフのうち、同じ機能でもバイヤー、オペレーター、技術レビュー担当者に対して異なる説明が必要な場合があるにもかかわらず、明示的に対象者を指定しているのは 8 つだけです。

これらは、すべてのプロンプトに 10 段落を追加する理由にはなりません。これらは、明示的でなければならない決定を、他の場所で提供できる設定やアセットから分離する理由になります。

03

欠けている層は事実と視覚の契約です

Inspect image

公開されている説明プロンプト ガイドのほとんどは、トピック、スタイル、タイミング、シーンに焦点を当てています。たとえば、Ngram の説明ギャラリーでは、正規化された実際のプロンプトが読者に提供され、一般的な期間やソース添付動作などの製品固有のパターンがレポートされます。 Golpo は、サンプルとプロンプト、スクリプト、および音声を組み合わせています。これらのページは、読者がインスピレーションを必要とするときに役立ちます。これらは、実稼働システムに、何が文字通りのままである必要があり、各ステートメントをどのような視覚的に証明するかを指示する契約に代わるものではありません。

事実とビジュアルの契約は 5 つの部分で構成されます。

• クレーム： 承認された文、番号、名前、または仕様。
• ソース： それをサポートするファイル、画面、ドキュメント、または URL。
• 視覚的結合： 主張が述べられている間に表示される正確な画像、UI 状態、またはデモンストレーション。
• 許可される変換： ソースを再描画せずに、トリミング、サイズ変更、ハイライト、注釈付け、アニメーション化を行うことができます。
• レビューテスト： 承認前に人間が検証しなければならないもの。

以下は、架空の分析製品の簡潔な例です。

この契約により、よくある失敗が防止されます。ナレーションでは 1 つの機能について説明しますが、視覚的には似ていますが間違った画面が表示されます。そのため、TapVid の精度モデルには、提供されたアセットの保持、リテラル情報の保持、およびスクリプトと正しいビジュアル間の対応関係の保持という 3 つの部分があります。これはレビュー規律であり、絶対的な保証ではありません。

04

ベンチマークから解説動画 プロンプトを作成する方法

次の順序で使用してください。装飾的な方向性よりも製品の真実性を保ちます。

1. 1 人の聴衆と 1 つの決定事項を挙げます

`Explain our platform to everyone` は避けてください。役割、状況、質問を使用します。

チームメイトが同じフィルタリングされたビューを再利用できるかどうかを評価する、保存されたレポートのワークフローを運用マネージャーに説明します。

オーディエンス フィールドは私たちのコーパスでは一般的ではありませんでしたが、用語、証明、ペース、および CTA を変更します。技術レビュー担当者は、実際の UI 状態を検査する必要がある場合があります。ビジネスバイヤーは、前後のワークフローが必要になる場合があります。 1 つのビデオで、シーンごとに別々のメッセージを表示して両方を満たそうとするべきではありません。

2. ソースパケットを添付します

ビジュアル スタイルをリクエストする前に、承認されたアセットと文字通りの事実をリストします。各項目を次の 3 つのタイプのいずれかとしてマークします。

• 提示する必要があります： 正確なスクリーンショット、ロゴ、製品画像、またはデモ。
• 必ず入力してください： 正確な名前、番号、仕様、または法律上の語句。
• 生成される可能性があるもの： 装飾的な背景、トランジション、抽象的なメタファー、または製品以外の接続的なビジュアル。

この区別により、生産システムは、製品の証拠を創造的な書き換えから保護しながら、解釈が歓迎される生成的なビジュアルを使用できるようになります。

3. 説明ユニットを中心にシーンを構築する

各シーンは、質問、メカニズム、証明、またはアクションの 1 つの単位を完了する必要があります。シーンは、カメラ アングルが異なるというだけでは役に立ちません。

45 の 2 番目のソフトウェア説明の概要は次のようになります。

• 現在のレポートの問題を表示します。
• 承認されたダッシュボードのスクリーンショットを表示し、保存されたレポート機能に名前を付けます。
• フィルターが保存されたビューの一部になる方法を示します。
• チームメイトが同じレポート状態を開いていることを示します。
• 正確な評価アクションを閉じます。

シーン構造は、33 説明ブリーフの 24 に表示されます。説明は順序に依存するため、このパターンには意味があります。観客が仕組みを理解する前に証拠が出てしまうと、それは証拠ではなく飾りになってしまいます。

4. 真実レイヤーの後にスタイルを追加します

視覚的な方向は、コーパス内で最も一般的な明示的なフィールドでした。そのままにしておきますが、説明には役立つようにしてください。階層、読みやすさ、動作の動作、製品映像と生成されたコンテキストの違いを指定します。

良い方向性：

抑制されたテクニカル ビジュアル システムを使用します。提供された UI スクリーンショットをそのままにしておきます。生成されたモーション グラフィックスは、トランジションと抽象的なデータ フローにのみ使用します。画面、メニュー ラベル、指標、製品の状態を発明しないでください。

弱い方向：

未来的、プレミアム、映画的、バイラルなものにしましょう。

弱いバージョンでは、レビュー基準なしで好みの単語が生成されます。

5. 検証可能な CTA で終了します

33 プロンプトのうち、明示的に CTA が含まれていたのは 8 つだけでした。説明者は必ずしも販売を終了する必要はありませんが、説明が裏付ける次の決定で終了する必要があります。例には、`Review the saved-report workflow`、`Compare the two input files`、または `Build one draft from your approved script` が含まれます。

05

コピー可能な解説動画 プロンプト テンプレート

[1 つの決定] を決定する必要がある [1 人の視聴者] 向けに、[期間] の解説動画を作成します。

これらの提供された資産を信頼できる製品ソースとして使用します。
- [アセット名] は [申請またはワークフロー ステップ] を証明します
- [アセット名] は [申請またはワークフロー ステップ] を証明します
- [ロゴまたはブランド資産] はトリミング/サイズ変更できますが、再描画はできません

この文言はそのままにしておいてください。
- 【商品名】
- [番号、仕様、価格、モデル、または承認された文言]

次のシーンで説明を作成します。
1. 【観客の状況と目に見える軋轢】
2. [正しい付属のビジュアルを備えた製品メカニズム]
3. [2番目のメカニズムまたは比較]
4. [観察可能な証拠または変化した状態]
5. 【具体的な次のアクション1つ】

視覚システム:
- [構図、タイポグラフィー、動き、色、照明]
- 生成されたビジュアルは [許可された装飾的な役割] をサポートする場合があります
- 製品の画面、ロゴ、ラベル、指標、事実を発明したり、再描画したりしないでください。

オーディオ:
- [声、ペース、音楽、音のルール]

納品前に確認してください:
- すべての主張は承認された情報源と一致します
- すべてのナレーション セリフが適切な製品ビジュアルと組み合わされています
- リテラルテキストは変更されません
- サポートされていない結果、価格、仕様は追加されません

テンプレートは意図的にモジュール化されています。継続時間とアスペクト比がすでにインターフェイスで制御されている場合は、それらをそこに保持し、プロンプトを長くするためだけにそれらを複製しないでください。

06

事例： 技術的な説明者にはスタイル以上のものが必要です

公開されている TapVid ケース Vera CPU 技術解説者モーション グラフィックス アニメーション は、技術的なトピックがシーン構造と制御された視覚システムから恩恵を受ける理由を示しています。その概要は 8,486 文字ですが、長さは重要ではありません。便利な点は、制作ディレクションが 1 つの映画クリップを要求するのではなく、複数のシーンの技術的な説明を調整することです。

公開 TapVid ケースを開く または 生成されたビデオを開く。

この事例は生産構造の一例であり、その中に示されている技術的主張を独立して検証するものではありません。製品に関する事実には依然として独自の承認された情報源が必要です。

07

何を短くし、何を明示するか

このベンチマークは、プロンプトが長いほど優れているというルールをサポートしていません。詳細のより適切な割り当てをサポートします。

構造化フィールドがすでにアスペクト比、実行時間、または音声を制御している場合は、散文を短くしてください。エラーによって製品のアイデンティティ、事実の意味、または視覚的な対応が変わる場合は、詳細を明示してください。カメラの形容詞を最後に置きます。ソースアセット、ロックされた文言、シーンの目的、およびレビューテストを最初に置きます。

すでに製品のスクリーンショットと承認されたスクリプトをお持ちの場合、TapVid はそれらの資料をレビュー可能な説明ワークフローに変えることができます。 製品デモ ビデオ ワークフロー から始めるか、制作概要を構築する前に 解説動画 スクリプト ガイド を使用してください。

08

よくある質問