目次
- この記事の立ち位置
- 最初に確認するのは技術ではなく規約
- なぜ規約を要約しないのか
- 業務で使うときに見落としやすい点
- 配信先ごとに要件が違う
- 背景音と効果音も条件を確認する
- 全体の構成
- 段階1：記事から台本を作る
- 台本の形式を決めておく
- 段階2：音声を合成する
- 段階3：音量を整える
- なぜ音量の正規化が効くのか
- 段階4：動画としてレンダリングする
- 口の動きを合わせる
- 日本語の改行
- 全自動にしていない理由
- 所要時間を書けない理由
- 自動化して初めて分かった落とし穴
- 効果をどう測るか
- 向く題材と向かない題材
- 実行環境について
- 導入するときの順序
- まとめ
この記事の立ち位置
合成音声のキャラクターを使った解説動画は、短時間で作れて、内容を絞れば視聴されやすい。採用の案内、製品の説明、社内向けの手順解説といった用途で使われている。
編集部は、記事のテキストを入力すると縦型の解説動画が出力される仕組みを運用している。この記事は、その構成と、業務で使う前に確認すべきことの記録である。
先に書いておくと、技術的な難所より、規約の確認のほうが重要である。 作ってから使えないと分かるのが最も高くつく。
最初に確認するのは技術ではなく規約
合成音声のキャラクターを使う場合、確認すべき条件は1つではない。
少なくとも2系統ある
キャラクターそのものの利用条件。 見た目、名前、声の扱い。キャラクターの権利者が定めている。
音声合成ソフトの利用条件。 ソフトウェア自体の使用と、生成された音声の扱い。ソフトウェアの提供者が定めている。
この2つは別々に定められている。 片方だけを読んで判断すると、もう片方の条件を見落とす。
一次情報の所在
編集部が参照しているのは次である。
キャラクター側は、東北ずん子・ずんだもんのキャラクター利用の規約と、音源利用の規約。
ソフトウェア側は、VOICEVOXの利用規約。実装は音声合成エンジンのリポジトリで公開されている。
クレジット表記の要否を確認する
多くの場合、生成した音声を使う際にクレジットの表記が求められる。表記の書式まで指定されていることがある。
動画の説明欄に書くのか、動画内に表示するのか。条件に書かれている場所を確認する。
なぜ規約を要約しないのか
この記事では、規約の内容を要約しない。理由を書いておく。
条件は改訂される
利用条件は更新される。記事に書いた要約は、書いた時点のものである。 読まれる時点で古くなっている可能性がある。
法令に関する記事でも同じ問題があるが、私的な規約はより頻繁に変わる。
要約は判断を歪める
「商用利用可」と要約すると、読んだ人はそれで判断してしまう。実際には条件が付いていることが多い。
要約は必ず何かを落とす。 落ちた条件が、その人の使い方に該当する条件かもしれない。
判断の責任が移らない
記事の要約を根拠に使って問題が起きても、責任は使った側にある。 そうである以上、使う側が原文を読む必要がある。
迷ったら聞く
判断に迷う使い方であれば、公式の問い合わせ窓口に確認する。 多くの権利者は、利用の可否について問い合わせを受け付けている。
「たぶん大丈夫」で進めて、後から止めるのが最も高くつく。
業務で使うときに見落としやすい点
一般論として、確認しておくべき観点を挙げる。該当するかどうかは原文で確認してほしい。
広告として使う場合
自社の案内と、広告出稿は扱いが違う場合がある。広告に使えるかを別に確認する。
有料の商品に含める場合
無料で公開する動画と、有料の教材や商品に含める場合で、条件が違うことがある。
顧客の案件で使う場合
自社の用途と、受託した案件で使う場合は別である。顧客が権利を持つ成果物に含める場合は、特に確認が要る。
キャラクターの印象を損なう内容
多くの利用条件には、キャラクターの印象を損なう使い方を禁じる項目がある。何が該当するかの判断は主観を含むため、際どい内容では事前に確認する。
音声だけを取り出して使う場合
動画から音声を取り出して別の用途に使う、といった二次的な利用も、条件の対象になる。
配信先ごとに要件が違う
作った動画をどこに出すかで、要件が変わる。先に決めておかないと作り直しになる。
縦型と横型
短尺の縦型動画は、多くの配信先で扱いが分かれている。YouTube ショートの要件では、縦型であることと長さの上限が条件になっている。
編集部が1080×1920で作っているのは、この形式に合わせるためである。
同じ素材から複数の形式を出す場合
縦型と横型では、入る情報量が違う。 縦型では1行あたりの文字数が少なくなり、図表は縮む。
レイアウトを形式ごとに作り分ける必要がある。 同じ配置を引き伸ばすと、どちらかが破綻する。
現実的には、最初に出す形式を1つ決めて作り、必要になってから2つ目を作る。
字幕の扱い
音を出さずに視聴される割合が高いため、画面上の文字が実質的な本体になる。
編集部の仕組みでは、台本の本文を画面に表示している。加えて、配信先が字幕ファイルに対応している場合は、そちらも用意できる。
台本が文字として存在する構成にしていると、字幕ファイルの生成は追加の手間がほぼかからない。
説明文とサムネイル
動画そのものより、説明文と最初の画面が視聴されるかを左右する。サムネイルの仕様は配信先ごとに決まっている。
自動生成の仕組みを作るなら、説明文と最初の画面も同じ工程で出す。 後から手で作ると、そこが律速になる。
検索結果に動画として表示させたい場合は、動画の構造化データの要件も確認する。
背景音と効果音も条件を確認する
見落としやすい点である。
音源にも権利がある
背景に流す音楽、場面の切り替えに入れる効果音。これらにも利用条件がある。
無料で配布されているものでも、商用利用の可否、クレジットの要否、改変の可否は個別に定められている。
配信先の自動検出
主要な配信先には、音源を自動的に照合する仕組みがある。条件を満たしていても、自動的に申し立てが入ることがある。
その場合、権利者から得た許諾を示して解除する手続きになる。許諾の記録を残しておく必要がある。
編集部の運用
使用した音源と、その取得元、確認した条件を、動画ごとに記録している。後から「これはどこから取ったか」を辿れるようにする。
自動化すると音源の選択も機械的になるため、記録を自動で残す仕掛けを入れておく。
全体の構成
ここから技術の話に移る。編集部の仕組みは4段階である。
| 段階 | やること |
|---|---|
| 1 | 記事のテキストから台本を作る |
| 2 | 台本の各行を音声に変換する |
| 3 | 音量を整える |
| 4 | 動画としてレンダリングする |
各段階は独立して実行できる。 台本だけを作り直す、音声だけを作り直す、といった部分的なやり直しができる。
これは運用上かなり効く。全部やり直すと時間がかかるため、失敗のたびに最初からになると続かない。
段階1：記事から台本を作る
記事のテキストを生成AIに渡し、台本の構造を出力させる。
対話形式にする
編集部の台本は、2人の話者による対話の形を取っている。一方が質問し、もう一方が答える。
理由は2つある。説明が単調にならないことと、視聴者の疑問を先に言わせられることである。
感情の指定を含める
台本の各行に、話者と本文に加えて感情の指定を持たせている。考えている、驚いている、説明している、といった区分である。
この指定に応じて、表示するキャラクターの表情を切り替える。編集部が用意している画像は54点ある。
台本の形式を決めておく
生成AIに自由な文章で返させると、後続の処理が壊れる。構造化された形式で出力させる。
1行の構成
話者の識別子、本文、感情の指定。この3つを持つ要素の並びとして出力させる。
形式を守らせる仕組み
「この形式で出してください」と指示するだけでは、守られないことがある。出力形式を指定できる機能があるなら、そちらを使う。
指示は破られることがあるが、仕組みで制約すれば守られる。
指示の書き方をどう設計したかはプロンプトは足しても良くならないで扱っている。
本文の長さを制約する
1行が長いと、画面に収まらず、音声も長くなる。1行あたりの文字数の上限を、台本の段階で決める。
動画にしてから長すぎると分かると、台本まで戻ることになる。
段階2：音声を合成する
台本の各行を、音声合成ソフトに渡して音声ファイルにする。
話者を指定する
音声合成ソフトは複数の話者を持つ。編集部の仕組みでは、話者を番号で指定する形になっている。既定値は1つに固定しつつ、実行時に変更できるようにしている。
対話形式にしているため、2人の話者を使い分けている。
行ごとに別のファイルにする
台本の1行を1つの音声ファイルとして出力する。まとめて1つにしない。
理由は、行ごとに画面を切り替えるためである。音声の長さが分かれば、その行を表示する時間が決まる。
音の発生タイミングを取得する
音声を合成する際、どの音がいつ発声されるかの情報も取得している。 これを口の動きに使う。詳細は後述する。
段階3：音量を整える
ここを省略すると、視聴時の印象が明らかに落ちる。
合成した音声をそのまま使うと、行によって音量が揃わない。静かな行と大きい行が混ざり、視聴者が音量を調整することになる。
実際に通している処理
編集部が使っている設定は次の3段である。音声処理のツールで一括して適用している。
低域を切る。 80Hz以下を落とす。この帯域には内容が無く、環境によっては不快な低音になる。
音量差を圧縮する。 しきい値を-20dB、圧縮の比率を4対1とし、反応を5ミリ秒、戻りを50ミリ秒に設定している。大きい音を抑え、小さい音との差を縮める。
全体の音量を揃える。 目標を-16LUFS、上限を-1.5dBTP、音量の変化幅を11LUに設定している。
-16LUFSという値
LUFSは、人の聞こえ方に近い形で音量を表す単位である。配信サービスごとに推奨される値があり、-16LUFSは動画配信でよく使われる値である。
この値に揃えておくと、配信側で自動調整された際の変化が小さくなる。
処理にはFFmpegを使っている。
なぜ音量の正規化が効くのか
技術的には地味な処理だが、視聴の継続に最も効く部分である。
音量が揃わないと離脱する
視聴者は、聞き取りにくい音声に対して、音量を上げるより先に視聴をやめる。内容を判断する前に離脱する。
映像の品質より効く
映像が多少粗くても、音声が聞き取りやすければ視聴は続く。逆は成立しない。音声のほうが優先度が高い。
合成音声は特に揃いにくい
人が読んだ音声なら、読み手が無意識に音量を調整する。合成音声は、文字列に応じて素直に出力するため、行ごとの差がそのまま出る。
だから正規化が必要になる。人の録音より、合成音声のほうが後処理が要る。
段階4：動画としてレンダリングする
画面の構成と、音声の並べ方を定義して、動画ファイルにする。
使っている道具
編集部はRemotionを使っている。Webの技術で動画を組み立てる仕組みで、画面の構成をコードで書ける。実装は公開されている。
コードで書けることが要点である。台本の内容に応じて、表示する要素を機械的に決められる。
設定値
縦型の動画として、幅1080、高さ1920で出力している。1秒あたりのコマ数は定数で管理し、各行の表示時間は、その行の音声の長さから計算している。
音声の長さが決まれば、画面の切り替えのタイミングが決まる。 手で合わせる作業が不要になる。
場面の切り替え
行と行の間に切り替えの効果を入れている。切り替えの時間だけ全体が伸びるため、合計時間の計算でその分を差し引いている。
この種の細かい計算を間違えると、音声と画面がだんだんずれる。最後の行で1秒ずれる、という形で現れる。
口の動きを合わせる
キャラクターの口を、音声に合わせて動かす。
音の単位で取れる
段階2で取得した、どの音がいつ発声されるかの情報を使う。文字単位ではなく音の単位で取れるため、日本語でも自然に合う。
編集部が用意している画像は、口を開いた状態と閉じた状態の組み合わせを5種類持っている。表情ごとに、開と閉の2枚がある。
完全に合わせる必要はない
実務的な話として、口の形を音ごとに変える必要はない。 開閉を切り替えるだけで、視聴上は十分に成立する。
編集部の実装では、音が出ている間、一定の間隔で開閉を切り替えている。毎秒6回程度である。
合わせすぎると不自然になる
むしろ、機械的に正確に合わせると違和感が出ることがある。ある程度おおまかなほうが自然に見える。
ここに時間をかけるより、音量の正規化に時間をかけるほうが効果が大きい。
日本語の改行
見落としやすい点である。
日本語には単語の区切りに空白が無い。 そのまま表示すると、意味の切れ目と無関係な位置で改行される。
「生成AIを業務で使う」が「生成AIを業務で使/う」のように折り返されると、読みにくい。
対処
編集部はBudouXを使っている。日本語の文を意味の切れ目で分割する仕組みで、改行の位置を制御できる。
短い時間しか表示されない動画の字幕では、1行の読みやすさが理解に直結する。
全自動にしていない理由
この仕組みは全自動で回せるが、台本の確認は人が行っている。
間違いが動画に焼き付く
記事の内容を誤って要約した台本がそのまま動画になると、修正には作り直しが必要である。公開後に気づいた場合は、差し替えの手間がかかる。
文章なら該当箇所だけ直せるが、動画はそうならない。
確認する項目を絞る
全文を精読すると続かない。編集部が見ているのは3点である。
数値が正しいか。 記事にある数値と、台本の数値が一致するか。
結論が反転していないか。 「効果があった」が「効果がなかった」になっていないか。
固有名詞が正しいか。 会社名、製品名、人名。
この3点なら、1本あたり数分で確認できる。
人の確認を前提に設計する
確認の工程を後から足すのは難しい。 最初から、台本を人が見る前提で工程を分けておく。
編集部の仕組みでは、台本の生成と音声の生成が別の段階になっており、台本を確認してから音声に進める。
所要時間を書けない理由
正直に書く。1本あたりの所要時間を、この記事では示せない。
計測していない
編集部の仕組みには、工程ごとの所要時間を記録する仕掛けが入っていない。実行のログは残るが、時間の記録がない。
測っていない数字を書かないという方針のため、ここでは示さない。
同じ方針で書いた実測はAIライティングで726記事を運用した結果やSearch Consoleの数字を5倍間違えたにまとめている。
書けたはずのものが書けない
これは記録の設計の問題である。動くものを作るときに、計測を一緒に入れておかないと、後から出せない。
過去の実行時間を後から復元することはできない。その時点で測っていなければ、その時点のデータは無い。
これから作る人への助言
最初から、各段階の開始と終了の時刻を記録する。 数行の追加で済む。
これがあると、どこが遅いかが分かり、改善の対象を決められる。無いと「なんとなく遅い」で終わる。
自動化して初めて分かった落とし穴
手作業では起きなかった問題が、自動化すると出る。
台本が長すぎて動画が伸びる
生成AIは、指示しないと長く書く。台本が長いと、音声が長くなり、動画の尺が伸びる。
短尺の形式には長さの上限があるため、超えると投稿できない。台本の段階で行数と文字数に上限を設ける必要がある。
出来上がってから長いと分かると、台本まで戻ることになる。
読み方が意図と違う
音声合成は文字列を素直に読む。英字の略語、単位、固有名詞で、意図しない読み方になることがある。
対処は2つある。台本の段階で読み仮名を含めて書くか、音声合成側の辞書に登録するか。前者のほうが手軽だが、台本が読みにくくなる。
数字の読み方も揃わない。「1,000」を「いっせんきゅうひゃく」と読むといった形で現れる。
同じ表情が続く
感情の指定を生成AIに任せると、同じ指定ばかりが並ぶことがある。結果として、全編ほぼ同じ表情の動画になる。
対処として、直前の行と同じ指定が続いた場合に別の指定を選ぶ処理を入れるか、台本の段階で分布を確認する。
切り替えの累積でずれる
前述したが、実際に踏んだ問題である。行ごとの切り替えに時間を使う場合、その分を合計から差し引かないと、後半になるほど音声と画面がずれる。
1行あたりのずれは小さいが、20行あれば目に見える。最後の行で1秒ずれるという形で現れるため、途中まで見て確認すると気づけない。
失敗したときに途中から再開できない
最初に作ったときは、全工程を一度に実行する形にしていた。途中で失敗すると最初からになる。
工程を分けたのは、この経験による。時間のかかる工程の後に、失敗しやすい工程を置かない。
一時ファイルが残る
行ごとに音声ファイルを作るため、1本作るごとにファイルが増える。消す処理を入れていないと、ディスクが埋まる。
地味だが、運用を止める原因になる。
効果をどう測るか
作った動画が効いているかを、何で判断するか。再生数だけを見ると判断を誤る。
再生数は入口の数でしかない
短尺の動画は、画面をめくる過程で自動的に再生が始まる形式が多い。「再生された」は「見られた」を意味しない。
見るべきは、どこまで見られたかである。配信先の管理画面には、視聴が継続した割合を示す指標がある。
最初の数秒で決まる
編集部が観測している範囲では、離脱の大半は冒頭で起きる。 冒頭で何の話かが分からないと、そこで終わる。
台本の構成で「まず結論を言う」ことにしているのは、この理由による。前置きを入れると、前置きの間に視聴が終わる。
本数と成果は比例しない
これは動画に限らない。編集部は記事で同じことを実測している。
726記事の検索実績を測ったところ、上位1本が表示の39.2%、上位50本（全体の6.9%）で84.6%を占め、209本（29%）は表示が1回もなかった。
分布は極端に偏る。 動画でも同じ形になると考えておくほうがよい。
記事側の実測はAIライティングで726記事を運用した結果にまとめている。
だから、量産の前に1本を測る
仕組みを作ると、量を出したくなる。しかし量を出しても、効くのは一部である。
先に1本作り、どこで離脱するかを見る。その1本を改善してから、量を考える。
記録を残す
どの題材で、どの構成で、どれだけ見られたか。動画ごとに記録する。
記録がないと、「なんとなく良かった」で終わる。編集部が所要時間を書けないのと同じ問題が、効果の測定でも起きる。
記事を動画にするとき、向く題材と向かない題材
すべての記事が動画に向くわけではない。編集部が運用して分かった傾向を挙げる。
向く題材
手順があるもの。 順番に説明でき、画面の切り替えと対応する。
比較があるもの。 2つを並べる構成は、画面で示しやすい。
数値が少数あるもの。 1つの画面に1つの数値なら、印象に残る。
結論が短く言えるもの。 冒頭で結論を言い、理由を続ける構成にできる。
向かない題材
条件分岐が多いもの。 「ただし〜の場合は」が続く内容は、音声では追えない。文章で読むほうが理解しやすい。
数値が大量にあるもの。 表を画面に出しても、短時間では読めない。
正確さが要求されるもの。 法令や契約の話は、要約すると条件が落ちる。動画の尺に収めようとすると、必ず何かを削ることになる。
前提の説明が長いもの。 本題に入る前に視聴が終わる。
判断の目安
記事の見出しを3つ以内に絞れるかで判断できる。絞れないなら、動画にすると情報が落ちすぎる。
絞った結果が元の記事と別物になるなら、動画は動画として作り直したほうがよい。 記事の要約として作ると、どちらも中途半端になる。
1本の記事から複数本作る
長い記事を1本の動画にするより、節ごとに分けて複数本にするほうが成立する。
編集部の仕組みは記事全体を入力に取るが、実際には節を抜き出して渡すことが多い。 入力を絞ったほうが、台本の質が上がる。
実行環境について
構成上の注意を1つ書いておく。
動画をコードで組み立てる仕組みは、Node.jsの上で動く。音声合成ソフトは別のプロセスとして立ち上がる。音量の処理は別のツールを呼ぶ。
複数の実行環境が絡む。 それぞれのバージョンが独立して上がるため、片方の更新で組み合わせが壊れることがある。
版を固定して記録する
編集部では、動画を組み立てる仕組みの版を設定ファイルで管理している。ただし、上位互換を許す指定は、破壊的な変更を引き込むことがある。
別のツールで実際にそれが起きており、指定した版より新しいものが入って、使用しているOSに対応する実行環境が無くなった、という状態になった。
動いた組み合わせを記録しておく。 動かなくなったときに戻せる。
ライセンスの確認先
使用する道具自体のライセンスも確認が要る。業務での使用に条件が付くものがある。リポジトリのライセンス表記を、導入の判断の前に読む。
導入するときの順序
1. 規約を読む
作る前に読む。使えないと分かるのは早いほどよい。
2. 手作業で1本作る
自動化する前に、手で1本作る。どの工程に時間がかかるかが分かる。
自動化すべきなのは、時間がかかる工程である。手で作らずに自動化すると、たいてい間違った工程を自動化する。
3. 音量の正規化を最初に入れる
技術的に最も簡単で、効果が最も大きい。
4. 工程を分ける
台本、音声、映像を別々に実行できるようにする。部分的なやり直しができないと運用が続かない。
5. 計測を入れる
各工程の所要時間を記録する。後からは取れない。
6. 人が見る箇所を決める
全自動にしない。確認する項目を3つに絞る。
まとめ
記事から解説動画を自動生成する仕組みの記録である。
最初に確認するのは技術ではなく規約。 キャラクターの利用条件と音声合成ソフトの利用条件は別に定められている。本記事では内容を要約せず、一次情報の所在だけを示した。条件は改訂されるためである。
構成は4段階。 台本の生成、音声の合成、音量の正規化、動画のレンダリング。各段階は独立して実行できるようにしている。
音量の正規化が最も効く。 低域を切り、音量差を圧縮し、-16LUFSに揃える。合成音声は行ごとの音量差が出やすいため、人の録音より後処理が要る。
縦型は1080×1920。 各行の表示時間は音声の長さから計算する。切り替えの時間を差し引かないと、最後の行でずれる。
日本語の改行は意味の切れ目で行う。 短時間しか表示されない字幕では、1行の読みやすさが理解に直結する。
全自動にしていない。 台本の確認を人が行う。数値、結論の向き、固有名詞の3点に絞れば数分で済む。
所要時間は書けない。 計測を入れていなかったため。作るときに一緒に入れておくべきだった。
明日から試せる3つ
1つ目は、規約の原文を開いて読むことである。要約された解説ではなく、公式が示している文を読む。
2つ目は、手で1本作ってみることである。どの工程に時間がかかるかが分かってから自動化する。
3つ目は、既存の動画の音量を測ってみることである。揃っていなければ、正規化を入れるだけで視聴の継続が変わる。
編集部では、AI導入の支援と、こうした制作の仕組みづくりも行っている。内製化したいが何から始めるか分からない、という段階の相談については、サービス案内を参照してほしい。
参考にした一次資料
- 東北ずん子・ずんだもん キャラクター利用の規約 — キャラクター側の条件
- 東北ずん子 音源利用の規約 — 音源側の条件
- 東北ずん子プロジェクト — 権利者の公式サイト
- VOICEVOX — 使用している音声合成ソフト
- VOICEVOX 利用規約 — ソフトウェア側の条件
- VOICEVOX エンジンのリポジトリ — 実装
- Remotion — 動画をコードで組み立てる仕組み
- Remotion のリポジトリ — 実装とライセンスの確認先
- FFmpeg — 音量の正規化に使用
- BudouX — 日本語の改行位置の制御
よくある質問
ずんだもんを業務で使ってよいですか。
キャラクターの利用条件と、音声合成ソフトの利用条件は別に定められており、それぞれを確認する必要があります。本記事では条件の内容を要約せず、一次情報の所在のみを示します。条件は改訂されるため、要約された解説ではなく、公式が示している原文を確認してください。判断に迷う使い方であれば、公式の問い合わせ窓口に確認するのが確実です。
記事から動画を自動生成できますか。
編集部では、記事のテキストを入力すると縦型の解説動画が出力される仕組みを運用しています。構成は、生成AIで台本を作り、音声合成で読み上げ、音量を整え、動画としてレンダリングする4段階です。全自動ではなく、台本の確認は人が行っています。
音声合成した音はそのまま使えますか。
そのままだと、場面によって音量が揃いません。編集部では出力後に音量の正規化を行い、放送や配信で使われる基準に合わせています。具体的には、低域を切り、音量差を圧縮し、全体の音量を一定の値に揃える処理を通しています。この処理を入れるかどうかで、視聴時の印象が大きく変わります。
動画の形式はどうすればよいですか。
配信先によります。編集部が使っている縦型の設定は1080×1920です。横型が必要な場合は別の設定を用意します。同じ素材から複数の形式を出す場合、レイアウトを形式ごとに作り分ける必要があるため、最初に出す形式を決めてから作るほうが手戻りが少なくなります。
口の動きはどう合わせていますか。
音声合成の際に、どの音がいつ発声されるかの情報を取得し、それに合わせて口の開閉を切り替えています。文字単位ではなく音の単位で取れるため、日本語でも自然に合います。ただし完全に一致させる必要はなく、開閉を一定の間隔で切り替えるだけでも視聴上は成立します。
1本作るのにどれくらいかかりますか。
編集部の仕組みには工程ごとの所要時間を記録する仕掛けが入っておらず、正確な値を出せません。実測していない数字は書かないという方針のため、ここでは所要時間を示しません。導入を検討する場合は、自社の環境で1本作って計測してください。レンダリングの時間は、動画の長さと解像度と機材の性能で大きく変わります。