はじめに

私はニコニコ動画にて、Minecraftというゲームを合成音声キャラクターに実況させる動画（いわゆるボイロマイクラ）を制作しています。動画シリーズは現在更新中のものも含めて3つ。合計80本の動画を投稿しました。

• おかゆりぞっと - ニコニコ

最近はブログ記事執筆に注力しているのもあって、動画制作からは少し離れていますが、だからこそ、この離れたタイミングでいったん立ち止まって制作プロセスを見つめ直したいと思いました。制作を続けている最中はどうしても手癖で回してしまって、どこが負担でどこが効率的なのかを客観的には把握しづらいため、今のようなブランクはかなり貴重で、ぜひとも活用したいタイミングです。

私のこれまでの制作プロセスは次の通り。実際にこの流れに対応したチェックリストを各動画で作成し、進捗を管理しています。

1. 収録準備・収録
   1. プレイ計画の確認：何をするつもりなのかざっくりと整理
   2. 機材確認
   3. 収録
2. 編集準備
   1. 収録データの10分ごとの分割：動画編集ソフト（AviUtl）に読み込むときのパフォーマンスに直結するため
   2. 収録データのバックアップ
   3. 編集プロジェクトの初期化：テンプレートを活用
   4. 分割済み収録データの読み込み：分割した収録データをタイムラインに並べていく
3. 編集
   1. おおまかな構成案作成：収録データをn倍速で見ながら想像をふくらませる
   2. セリフ入れ：音声合成ソフト上で喋らせたい内容を書いていき、調声し、保存する。保存した内容は自動化ツール（かんしくん）によってAviUtl上に配置される
   3. 字幕改行：字幕テキストの画面端での折り返し
   4. テロップ挿入：字幕とは別に書いておきたい内容を入れる
   5. 立ち絵の表情付け：PSDToolKitを使って表情をデフォルトから変えていく
   6. 立ち絵のモーション付け・エフェクト挿入：立ち絵をかわいらしく動かしたり、立ち絵周辺にエフェクトをおいてにぎやかにしたり
4. 投稿
   1. エンコード
   2. 動画投稿サイトへのアップロード
   3. メタデータ編集
   4. 投稿予約設定
   5. SNS共有

この制作プロセスは、実際に採用してみて悪くはないと感じています。全体を俯瞰すると、難所は収録とセリフ入れの二点に集中していて、他は流れ作業的に勢いで進められるようになっています。

OBS Studio（録画ソフト）やAviUtl（動画編集ソフト）、音声合成ソフトやPSDToolKit（AviUtlのプラグイン）など、扱うツールは多くありますが、制作プロセスで段階ごとに分業化しており、作業は混ざりづらくなっています。音声合成ソフトを使っている間はPSDToolKitでの表情設定はしませんし、逆にPSDToolKitを使っているときに音声合成ソフトは使いません。動画を冒頭から完璧なものとして1秒1秒作っていくのではなく、使用するツールごとに分けて意図的に何周か回す形で非線形的に完成に近づけていくアプローチは、試行錯誤の賜物です。

しかしいくつか課題もあって、それについて今回見つめ直してみます。

どの程度計画的に進めるか

計画をしっかりと立ててウォーターフォール的に制作を進めたいところではあります。動画編集作業は大まかに収録→音声合成→動画編集の流れで行うことになりますが、これを逆転させたり、アジャイル的に「回していく」ことはできません。手戻りが発生するとすべてがズレて大変です。計画通りに事を進められれば、制作は相当楽になります。

しかし問題は、ゲーム実況という不確実性が最大の特徴であるコンテンツゆえに計画の立てようがないところ。ゲームの展開は思ったよりブレるもので、奇跡的なプレイが起きたり、逆に思うようにいかずグダグダになったりして、台本を先に固めてもその通りにはならないことが多いです。あとから合わせようとするとかえって負荷が増えてしまいます。収録をまず一気に進めてしまって、あとから「この素材でどう料理するか」を考える方が現実的なのです。

合成音声を使った動画制作には多くのメリットがあります。収録が自分のコンディションと切り離されていて、必要な分だけ必要なタイミングで作ることができるのは気楽です。聞き取りやすさや聞いた感じをパラメータで調整できるというのも大きなメリットで、生声では気を抜くとすぐ聞き取りづらくなったり、テンションにばらつきが出たりします。合成音声の安定感と再現性の高さはとても魅力的なのです。

しかし、合成音声を使うがゆえの、「収録とセリフ入れを別々に行う必要がある」ことには特有の難しさもあります。代表的なものが、収録データを見返したときに「このプレイをしていたときって何をどうするつもりだったんだっけ」と、忘れてしまっているという問題。あとから料理していくということはつまり、あとから思い出す必要があるということ。プレイ中のメモがほんの少しでもあると後工程は段違いに楽になりますが、プレイが盛り上がっている最中にメモを残すことは大変です。

プレイ中の感情や意図をどう情報として残しておくか考えることは、計画が崩れがちだけれども、どうしてもアジャイル的にはできない制作プロセスにおいて非常に重要です。

後工程のことを考えた情報の残し方

基本的な制作プロセスについてはこれまで通りにするとして、後工程のことを考えた情報の残し方について検討していきます。

以前、動画のメタデータとしてタイムスタンプ付きでメモを残せたら便利だろうと考えてみたことがありました。収録に使っているOBS Studioというソフトウェアには、チャプターマーカーという機能があり、配信・録画中に任意の箇所、任意の内容でマーカーを残しておくことができます。

これをうまくゲーム内から機械的に扱えないかと、MODを開発し、そこからWebSocket APIを呼び出すことを試してみたことはありました（当時のSNSへの投稿）。ゲーム内の特定のイベントやチャットのやり取りを元にOBS Studioを自動操作できたらとても便利でしょう。しかし開発難易度が高く諦めてしまいました。

とはいえ、チャプターマーカーにこだわる必要はさほどありません。これは極端な話ですが、「メモをSNSに残す」なんていう方法でも、面倒というだけで大きな問題があるわけではないのです。情報が残せたらよし、残せなかったらだめ。つまり考えるべきは、いかにして情報を残す＆残した情報を活用する際の面倒を減らすか、というところです。

生声収録について

そこで考えたのが、「プレイ中に軽く生声も録っておく」というものです。

後工程が求めているのはそれほど厳密な情報ではなく、収録中の気づきや感情がタイムスタンプとセットになったものです。淡々と必要なことだけ音声メモとして残していき、後から必要なところだけ拾えるようにしておくというのは、悪い選択肢ではないはずです。プレイ中にキーボードを操作してメモを残す必要がないというのも良いところでしょう。

とはいえ実際に音声メモを残していくとなると、いくつか乗り越えなければならないハードルはあります。

• 生声配信などではないとはいえ、ある程度情報としてちゃんとした内容を話す必要がある。
• マイクを所有していないため何らかの方法で調達する必要がある。
• OBS Studioの設定をうまく調整してゲームの音声と音声メモが別々に保存されるようにする必要がある。
• （もしツールを使って文字起こしをするなら、そのツールを見繕う必要がある。）

マイクとしてはAndroidスマホを使うという方向で検討しています。scrcpyというツールを活用すれば、スマホのマイクで拾った音声をパソコンに取り込むことができます。

• scrcpyを使ってAndroidスマホのマイクで拾った音声をパソコンで流してみる | okayurisotto.net

淡々と必要な情報だけ口に出して残していくスタイルなら、音質にこだわる必要はありません。専用のマイクを購入する場合と比べ若干手間はかかりますが、スマホ上にボイスレコーダーアプリを入れてファイルをやり取りするよりはずっと楽でしょう。スマホ運用の手間に疲れたら、そのタイミングでなんらかのマイクを買うことになるでしょうか。

OBS Studioの設定は、生声専用のオーディオトラックを作ってしまえばいいだけです。初期セットアップの敷居こそあれど長期的な重荷にはなりません。AviUtlは複数のオーディオトラックを持つ動画をうまく扱えないようですが、さほど大きな問題ではないでしょう。

文字起こしツールに関しては……現代ではWhisperのようなAIベースの高性能なものがありますが、Whisperは環境構築が大変なため、導入についてはよく検討する必要があるでしょう。今少しfaster-whisperを試してみたところ、CUDAがうまく使われないために処理が非常に遅くなってしまっていました。基本的に無音区間も長いことを考えると、文字起こしの自動化は開発コストがかさみそうです。別の沼に踏み込みかねませんし、本来の目的からどんどん離れてしまいます。今回の「収録時の自分の意図や感情を残したい」というところに立ち返ると、文字起こしそのものはあくまで補助であって必須ではありません。

構成について

しかし、他にもボトルネックはあります。

構成の作成とセリフ入れは、最もクリエイティビティが発揮される箇所であり、逆に言えばクリエイティビティに依存してしまう箇所です。技術的な効率化は効きづらく、省力化しにくいです。音声メモがあることでいくらかスムーズになることを期待するしかありません。

構成案をまとめていく際には、構成をどれだけ具体化しつつ「伸縮可能」なものにできるかが肝心でしょう。実際のセリフ量と時間はセリフを書いてみないことにはわからず、いくら合成音声だからといって考えた構成がうまく動画1本の長さにハマるかはわかりません。文字数と秒数の関係を計測し捉えられるようにしたとしても、セリフ同士の間隔やゲーム中の展開の速さなどが絡んできてしまいます。構成がどれだけ洗練されていても、最終的な長さは「作ってみないとわからない」のです。動画1本あたりの長さをある程度揃えたいとなると、これは問題です。

ゆえに、構成をユニットの集合として、伸縮可能なものとして設計すると良いのではないかと考えます。それぞれがある程度独立して破綻しないユニットをいくつか持っておいて、実時間に合わせて削りやすくするのです。ユニットの具体例としては、「挨拶」「前回のあらすじ」「今回の概要」「解説」「作業風景」「振り返り」「次回予告」などがあるでしょうか。これらユニットを常に意識して構成を作れるよう、テンプレートを作ることを検討します。

テンプレート化の利点は、何を語るかの選択肢があらかじめ整理されていることで、収録素材の見返しと構成案の作成に明確な目的を持って向き合えるところでしょう。いきなり一本まるごと設計しようとすると気が重くなってしまいますが、テンプレートとしてユニットが選択肢として列挙されていれば、いくらか楽になってくれるでしょう。編集の最初の一歩の抵抗を弱めてくれる効果が期待できそうです。

まとめ

音声メモが残されているというだけでも、状況は相当改善されているはずです。ゲームプレイ自体の不確実性をなくすことはできなくても、その不確実性が後の作業を損ねないようにするという意味で、改善策として意義があるのではないかと思います。

とはいえ、後から聞きたい箇所をすばやく見つけられる仕組みを整備しておきたいところです。無音部分を飛ばせるか、もしくは波形を頼りに発話箇所だけ拾えるようになっていれば、情報としての価値は十分にあり、全体を聞き返す必要もなくなります。

そのような仕組みは、すでに動画編集ソフトのラウドネス計測プラグインの音量波形を見るなどすれば、（扱いやすいかはさておき）済ませることはできます。試験的に使う分には問題ありません。あとはこれがどの程度役立つか試してみないことには、といったところでしょうか。

いざ本格的に使い始めれば、自分の声のクセやメモの頻度も見えてきて、そこから初めて「ここは自動化したい」とか「やっぱり文字起こしが欲しい」という判断につながっていくはずです。

あとは実際に手を動かして試すだけ。2026年は頑張っていきたいですね。