StartupXO
言語設定

Language

開発ツール・インフラ

デモ動画は昨日のデプロイでもう古い:製品メディア自動更新の空白

公開日: 2026-07-06

デモ自動化E2EテストCIツール製品マーケティングスクリーンショットのずれ

解決すべき課題

ランディングページ、ドキュメント、アプリストアのスクリーンショット、オンボーディング動画はすべて製品のUIを映すが、製品は毎週出荷されるので、数日で古いボタンや消えた機能を見せてしまう。更新を担う部署が明確でなく、顧客が苦情を言うかリブランディングが迫るまで放置される。

なぜ今なのか

PlaywrightやCypressはすでに動画とトレースを記録し、AIによるコーディングで出荷速度が上がってUIがかつてないほど早く古くなる今、通過したテストから最新のデモメディアを自動で作り出すCI層が空いている。

推薦人材

CIと開発インフラを作った経験のあるエンジニア、ヘッドレスブラウザで動画やスクリーンショットをプログラムでレンダリングできる人、マーケティングやPMMのデモ更新の痛みを知り、開発チームとマーケティングの両方に売れるB2Bの感覚を持つ人。

どんな問題か

会社のウェブサイト、ドキュメント、アプリストアのスクリーンショット、オンボーディングのGIF、セールスデモはすべて製品の画面を映す。問題は、製品が毎週デプロイされるのに、これらの資産は静止した一枚だということだ。ボタンの位置が変わり、価格表が更新され、機能が消えると、デモは数日で現在の製品とずれる。ところが、この資産を最新に保つ責任がどのチームにも明確にない。エンジニアはコードだけを見て、マーケティングは再撮影の費用が高くて先送りする。結局、見込み客はライブの製品とは違う画面をデモで見る。手作業の再収録は高くて退屈なので、チームは投資を惜しみ、デモは古いまま回り続ける。リブランディングや大きな改修が迫ってようやく一気に撮り直す、それが今のやり方だ。

なぜ今か

三つが重なった。第一に、PlaywrightやCypressのようなE2Eフレームワークが今や標準で動画とトレースを記録し、ほぼどのチームにも入っている。デモに使う元のフローが、すでにCIの中で毎日回っているということだ。第二に、AIによるコーディングで出荷速度が急に上がった。UIが以前よりずっと早く変わるので、メディアのずれもその分ひどくなる。第三に、ヘッドレスブラウザとプログラムによる動画レンダリング、つまりPlaywrightのビデオやRemotionのようなツールが成熟し、人手なしで清潔なデモを作れる。メルカリやfreeeのように毎日デプロイするチームほど、この空白は大きい。今は、通過したテストという元素材と、それをメディアに変えるパイプラインの間が空いている。

どう作るか

既存のE2Eスイートに接続する。デモに使うフローにタグを付けさせ、CIでビルドがグリーンになるたびにそのフローを高解像度で再収録する。カーソルの揺れを整え、キャプションとズームを入れ、スクリーンショットのセットと短いデモクリップに後処理する。成果物は安定したURLでCDNに公開し、マーケティングが埋め込んだリンクが常に最新のビルドを指すようにする。ブランドに敏感な資産は、変更検知で人間の承認ステップに回す。

flowchart LR
  A[E2Eテスト通過] --> B[クリーン収録: 動画とスクリーンショット]
  B --> C[後処理: キャプション・ズーム・カーソル整理]
  C --> D[CDNに安定URLで公開]
  D --> E[マーケティングとドキュメントに埋め込み]
  C --> F[変更検知と人間の承認]

参入は狭く取る。ひとつのフレームワーク向けプラグインとして始め、設定数行で終わるようにし、次にドキュメント・アプリストア・セールスデッキへの公開先を足し、最後にマーケティングCMS連携へ上がる。課金はプロジェクト単位のサブスクリプションに、承認ワークフローとブランド審査を上位プランとして乗せる。

成功の条件

第一に、デモスイートがすでにグリーンのチームを狙う。テストが回らないチームには売る物がない。第二に、資産の鮮度を指標にする。メディアがNビルドより古くならないという約束(SLA)が製品の核だ。第三に、買い手をエンジニアではなくマーケティングやPMMに定める。費用を節約する話ではなく、古いデモで失う転換を止める話であって初めて予算が開く。

一緒に作りましょう

一緒に作る人材を見る