最初は、多くの会社と同じように、既製のデモ動画作成ツールを使っていました。ところが、必要な動画の本数を数えてみると、とても手で録画し続けられる量ではありませんでした。テーマが2種類、言語が複数あり、そのうえ画面はほぼ毎週変わります。そこで、デモ動画を作るための仕組みを自社で作りました。作ったのは開発者1人とAIモデルで、かかったのは数日です。ツールそのものより、この点のほうが大きな意味を持っています。
デモ1本が、動画何本になるか
promptShieldには、ライトとダークの2つのテーマがあり、複数の言語で提供しています。契約書の個人情報を黒塗りするデモを1本作るとしても、テーマの数と言語の数を掛けた本数の動画が必要です。どの動画も同じ操作を見せながら、それぞれの言語で自然に見え、それぞれのテーマで正しく表示されなければなりません。
これを、サイトに載せるすべてのデモに掛けます。さらに、レイアウト、ボタン、余白、機能の変更が毎週のように入ります。変更が入るたびに、古い画面を録画した動画は、実際の画面と合わなくなります。
画面録画型のツールが合わなかった理由
ArcadeやStorylaneのように、画面を記録してデモを作るツールは、得意な仕事をきちんとこなします。アプリを操作すると画面が記録され、見栄えのよいウォークスルーができあがります。これらのツールは、デモを記録した画面の集まりとして扱います。当社の規模では、この考え方が三つの点で合いませんでした。
- 組み合わせの数だけ、手で録画することになる。同じ流れを何十回も録画して、すべてをまったく同じ操作にそろえることは、人にはできません。
- 画面が一つ変わると、録画がまとめて古くなる。ボタンの位置を動かせば、そのボタンが映っている動画はすべて実際の画面と食い違います。そのたびに、影響を受けたデモを、組み合わせの数だけ撮り直すか手直しすることになります。
- 翻訳が別の仕事として増える。録画に映るのは、そのとき画面に表示されている言語です。字幕や説明文を翻訳する機能があるツールでも、十数本のデモを全言語で製品に合わせ続けるには、専任の担当者が1人必要になります。
こうしたツールは、一度作れば何か月も正しいままのデモに向いています。当社のデモは、変わり続ける製品から、すべてのテーマと言語で作り直し続ける必要がありました。
すでに手元にあったもの
当社のウェブサイトの/demoは、デスクトップアプリの本物のフロントエンドをブラウザーの中で動かしています。Reactのコンポーネントも、CSSも、翻訳も同じもので、内部サービスとのやり取りだけを模擬の応答に置き換えています。デスクトップアプリへの変更は、次のビルドでそのまま反映されます。Demo Studioは、この/demoを相手に動画を記録します。製品を実際に試していただく場としては、/demoではなく、無料のブラウザー版を用意しています。
ですから、必要だったのは、アプリを撮影するのではなく、アプリを操作する仕組みでした。アプリはもともと、どのテーマでもどの言語でも表示できます。組み合わせが増えても、追加の手間はかかりません。
作ったもの
この仕組みをDemo Studioと呼んでいます。記録するのは画面の動画ではなく、操作の手順です。
記録：記録モードをオンにして、1つの言語と1つのテーマで、流れを一度だけ操作します。クリック、スクロール、パネルを開くといった操作が一つずつ、対象の要素、前提条件、タイミングとともに記録されます。再生時には、クリックされた要素が一瞬光り、見ている人が目で追えるようにしています。
書き出し：画面を表示しないブラウザーが、手順をテーマごと、言語ごとに再生します。1回の作業で、すべての組み合わせのWebM動画と、対応する静止画ができあがります。日本語のダークテーマ版と英語のライトテーマ版は、まったく同じ操作を見せます。同じ手順が、同じ本物のアプリを動かしているからです。
演出：タイムライン上で、ズーム、操作箇所の強調、字幕を加えます。字幕の翻訳には、Claudeを使っています。
掲載箇所の点検：サイトでデモが表示される場所は、コード上ではそれぞれ<DemoMedia slot="..."/>として書かれています。Demo Studioはコードを読み取り、掲載箇所ごとに、どの言語の動画がそろっていて、どの言語が足りないかを一覧にします。掲載箇所と結びつかないメディアのフォルダーも、別に表示します。
画面を変えるコストがどう変わったか
既製のツールでは、画面を一つ変えるたびに、影響を受けたデモを組み合わせの数だけ手で撮り直していました。Demo Studioでは、もう一度書き出すだけです。手順は操作を記述しているので、その操作が存在する限り、そのまま使えます。手を動かすのは人ではなく、コンピューターです。
言語やテーマを一つ増やすときも、書き出しの設定を一つ加えるだけです。以前の作業量は、テーマ、言語、デモ、リリースの数をすべて掛け合わせた分だけ増えていきました。いまは、操作の流れが何種類あるかで決まります。
契約するより作るほうが安くなった
何十年ものあいだ、道具が必要になったときの答えは、既製のサービスを契約することでした。自分で作るのは高くつき、時間もかかり、本業の妨げになったからです。その結果、一つの仕事をそこそこにこなす、ユーザー数で課金する専用ツールの市場ができました。
いまはAIのコーディングエージェントを使えば、1人でも、自分の問題にぴったり合う道具を作れます。かかる時間は、以前なら製品を比較検討していたのと同じくらいです。Demo Studioは、四半期ではなく、集中した数日でできました。
SaaSの市場の多くは、自分専用の小さな道具を作っても割に合わない、という前提に立っています。だからこそ、利用者は1人あたりの料金を払い続けます。作るのが安くなれば、この前提は揺らぎます。いちばん影響を受けやすいのは、一つの作業を1人単位で売る小さな製品です。
当社がDemo Studioを作ったのは、既製の道具を工夫して使うより、合う道具を作るほうが安くなったからです。これから数年で、多くの会社が同じ計算をするはずです。そのたびに、月額の契約が、自社で持つコードに置き換わっていきます。
よくある質問
画面録画型のデモツールを使わなかったのはなぜですか？
最初は使っていました。しかし、2つのテーマと複数の言語、毎週の画面の変更が重なり、デモ1本ごとに、組み合わせの数だけ手で録画し直すことになりました。
デモ動画の仕組みと、promptShieldの製品には関係がありますか？
同じ考え方から生まれています。既存の部品をそのまま組み込むのではなく、検出エンジンを自社で作り、ブラウザー版で動くモデルも自前で用意しました。汎用の選択肢が、その仕事に合わなかったからです。
画面が変わったら、デモはどうなりますか？
書き出しをもう一度実行します。手順は画面の見た目ではなく操作を記録しているので、その操作が残っている限りそのまま使えます。すべての組み合わせの動画が、1回の作業でそろいます。