はじめに
動画を作ると、最後に必ず検品があります。
読み上げが変なところはないか。絵が崩れていないか。字幕の文字は合っているか。私の場合、一本の動画に七コマから十二コマぶんの絵と読みがあって、それを頭から順に見て、聞いて、直すところに印を付けていく。作るところは道具でだいぶ速くなったのに、この最後の工程だけが手作業のまま残っていました。
面倒の中身は、直しそのものではありません。「ここのこの一文字」を伝えるまでが面倒なのです。三コマ目の読みの、長音がひとつ多い。それだけのことを文章にして、相手に渡して、直ったものを確かめる。直すのは一秒なのに、伝えるのに一分かかる。
先日、AI をラジオ形式で扱っている回で、これとほとんど同じ話を聞きました。
チャットで指示を打っている間に、自分で直したほうが早い。だったら画面にボタンを付けてしまえばいい──という趣旨の回です。作った本人が実物を見せながら話していて、中身は本編に譲りますが、聞きながら思い出したのが、まさに自分のこの工程でした。
それで、窓を作りました。検品マネージャーと名づけています。以前に作った VBA マネージャー、ビデオマネージャーと同じ並びです。
作った動画が新しい順に並ぶだけの画面です。この日の時点で 118 本ありました。
以前この連載で書いてきたのは、どれも Excel の中の道具です。直前の二本も、鍵の要らない中継器と、Excel のボタンから AI チャットに仕事をさせる話でした。
しかし今回のものは、Excel を一度も開きません。なぜそれで筋が通るのかは、後ろのほうで書きます。
TL;DR
- 動画の検品用に、ブラウザで開く小さな道具を作りました。左から順に、キャプション・読み・音声の再生ボタン・絵・OK/リテイクのボタンが一行に並ぶだけの画面です
- 判定は、別のファイルに書きません。絵そのものと音声そのものに埋めています。 PNG にも WAV にも、規格の中に「知らない中身は読み飛ばす」という余地があるので、そこへ判定を書き込みます
- 埋めた後も画像は画像のまま、音は音のままです。実測で WAV の PCM は一バイトも変わらず、長さも 7.274667 秒のままでした。判定を消せば元のファイルとバイト単位で一致します
- 私の動画には三つの型があり、三つ目でいちど詰まりました。音声がセクション単位でしか存在せず、字幕と一対一にならないからです。行を分けずに、畳みました
- 全部で 1,612 行と 1,019 行、それに三行のバッチファイル。作業はだいたい見積もりどおり一時間ほどでした
- ただしこの道具は公開していません。自分の動画のフォルダの形に合わせて作ってあるので、そのままでは他所で動きません
台帳を作りたくなかった
検品の結果をどこに書くか。ここが最初の分かれ道でした。
素直に考えれば、判定用のファイルを一枚作って、そこに「三コマ目はやり直し、理由は構図」と書いていけばいい。作るのは簡単です。
ただ、これをやると必ず後で困ります。絵を作り直したのに、判定用のファイルには古い判定が残る。 フォルダごとコピーしたら台帳が付いてこない。逆に台帳だけ残って現物が消える。現物と別に台帳を持つと、その二つは必ずどこかでずれます。
以前、別の道具で同じことをやって、痛い目を見ました。索引用のファイルを外に作ったら、そのファイル自身の面倒を見る羽目になったのです。そのときに決めたのが、データはファイル自身に持たせるという一本の線でした。
紙の世界でいえば、帳簿の話です。検査した品物を帳簿に書いていくやり方は、帳簿と品物が離れた瞬間に意味を失います。だから工場では品物そのものに検印を押す。品物を見れば、検査済みかどうかがわかる。品物を作り直せば、当然その検印も無くなる。
これを、そのままやることにしました。
絵の中に、検印を押す
動画を一本開くと、こうなります。
一行が一コマです。左からキャプション、読み上げの文、音声の再生ボタン、絵、そして OK とリテイクのボタン。上から順に押していけば検品が終わる、それだけの画面です。
リテイクを押すと、行の下に理由が開きます。
よく使う理由は八つに決めてボタンにしてあります。両足が地面に着いていない、仮面が崩れている、ベルトが無い──自分の絵が崩れるときのパターンは、だいたい決まっているからです。当てはまらないときだけ、自由記入に書きます。
さて、この判定をどこに置くか、という話でした。
PNG というファイル形式は、いくつもの「かたまり」が数珠つなぎになった構造をしています。画像の本体もそのひとつで、他に画像の大きさや色の情報が入ったかたまりが並んでいます。
ここで効いてくるのが、規格が「知らない種類のかたまりは読み飛ばしてよい」と決めていることです。つまり自分で決めた名前のかたまりを足しても、世の中の画像ソフトはそれを無視して、今までどおり絵として開きます。
そこへ判定を書きます。中身はこれだけです。
{"v": 1, "verdict": "retake", "reasons": ["構図・角度"], "note": "", "at": "2026-08-08T21:00:00"}
OK を押しただけなら、もっと短くなります。実測で 62 バイト。理由と覚え書きを付けても 110 バイトでした。数百キロバイトの絵に、その程度が足されるだけです。
書き込みは慎重にやりました。かたまりを組み直したあと、もう一度読み直して、画像の本体が元と一バイトも違わないことを確かめてから、はじめて元のファイルと入れ替えます。絵を壊してしまっては元も子もないので、ここだけは念入りにしています。
判定を取り消すと、そのかたまりごと消えます。消したあとのファイルは、元のファイルとバイト単位で一致しました。
三つ目の型で、置き場が無くなった
私の動画には三つの型があります。短い紹介もの、二人のかけあい、それと解説ものです。前の二つは同じ作りで通りました。一行に一つの読みがあり、一つの音声があり、一枚の絵がある。四つが揃っているから、表がそのまま組めます。
三つ目で、これが崩れました。
解説ものは単位が二段になっていたのです。台本は「セクション」で区切られていて、その中に字幕が何枚も入っている。実物を数えたら、セクション 12 個に対して字幕が 84 枚ありました。別の回では 66 枚です。
問題は音声でした。合成された音声ファイルは S01.wav から S12.wav までの 12 個しかありません。セクションまるごとで一本になっていて、字幕一枚ごとの音声が存在しない。
ここで安直にやるなら、84 行の表を作ることになります。見た目は他の型と揃うので、一見きれいです。
しかしそれをやると、再生ボタンが押せない行が七割を占める表ができあがります。押しても鳴らないボタンが並んでいる画面は、揃っているように見えて嘘です。
なので、行を分けませんでした。一行を一セクションにして 12 行。字幕はその行を開いた中に畳む。 再生と判定は行に付き、読みの確認と修正は開いた中でやる。単位が二段なら、画面も二段にする。それだけの話でした。
音にも、検印は押せた
そうすると、解説ものの判定をどこに押すかが問題になります。この型にはセクションごとの絵が存在しないのです。スライドは動画として直接書き出されていて、途中の静止画が残っていません。
残っているのは、セクションごとの音声でした。
WAV も、実は PNG と似た構造をしています。かたまりが数珠つなぎになっていて、規格として知らないかたまりは読み飛ばすことになっている。だとすれば、同じ手が使えるはずです。
ただし、これは実装する前に確かめなければいけないと思いました。音声は動画のビルドで使われます。そこで読んでいる誰かが厳しい作りだったら、動画が作れなくなる。作ってから気づいたのでは遅い。
そこで先に、一時的なコピーで試しました。結果はこうです。
| 確かめたこと | 結果 |
|---|---|
| 音声を扱う標準の部品で読めるか | 読めた。PCM が元と完全一致 |
| 長さ・サンプリング周波数・チャンネル数 | すべて不変 |
| 動画側の道具から見た長さ | 7.274667 秒 で前後とも同じ |
| 実際に変換をかけられるか | 通った |
| 判定を消したら元に戻るか | バイト単位で一致 |
通りました。増えたのは 110 バイトだけです。
ここで一つ、あとから気に入っている性質があります。音声を合成し直すと、判定も一緒に消える。 一見すると不便に見えますが、これは正しい動きです。読みを直して音を作り直したのなら、前の検品結果はもう当てになりません。「作り直したら検品やり直し」が、仕組みとして勝手に成り立つ。狙って作ったというより、品物に検印を押す方式を選んだ時点で自動的にそうなった、という感じです。
取らなかったもの
出発点になった回では、動画を投げ込むところから公開設定まで、工程の全部が一つの画面に畳まれていました。文字起こしをして、どこを切るか AI が候補を出して、人が選んで、台本ができて、画面上で直して、承認すると動画が出てくる。
私が取ったのは、そのうち検品の部分だけです。
理由は、あの回の中で作った本人が弱点を挙げていたからです。要旨だけ書くと、この形は決まった手順の作業には強いが、例外にはとても弱い。候補が全部外れたときに「そうじゃなくて」と言い直す道が、ボタンの画面には無い。例外を全部ボタンにしていくと、複雑で使いにくいものになる──という話でした。
これは自分にも当てはまります。だから、手順がかっちり決まっているところだけを切り出しました。検品は毎回まったく同じことをします。上から順に見て、聞いて、良し悪しを付ける。ここには例外がほとんどありません。
一方、リテイクした絵を実際に作り直すところは、道具の中に入れませんでした。押したら勝手に作り直しが始まる、という作りにはしていない。リテイク一覧を開くと、その動画のぶんのコマンドが並ぶので、それを自分で流します。
面倒に見えるかもしれませんが、ここは例外の巣です。同じ絵をもう一度引き直すだけのこともあれば、そもそも作戦を変えることもある。決まっていない工程をボタンにすると、ボタンが増えていくだけになります。
Excel を一度も開かない道具
この連載でずっと書いてきたのは、仕事の場所を Excel から動かさない、という話でした。表の上でやっている仕事を、わざわざ別の画面へ引っ越させない。画面を切り替えないほうが疲れない。
その連載で、Excel を一度も開かない道具の話を書いています。矛盾しているように見えるので、自分なりの整理を書いておきます。
動画の検品は、もともと Excel に住んでいませんでした。
私の動画は、フォルダとファイルとして存在しています。台本があって、絵が番号順に並んでいて、音声のフォルダがある。表計算の上に一度も乗ったことがない仕事です。これを無理に Excel へ持ち込む理由は、どこにもありませんでした。持ち込めば、フォルダの中身をシートに写す仕事が新しく発生するだけです。
なので、線はここに引けると思っています。
- すでに Excel にある仕事は、Excel から動かさない
- まだ家の無い仕事には、家を建てる
両方やっても、ぶつかりません。ぶつかるのは「今そこで回っている仕事を、新しい画面へ移す」ときだけです。
もうひとつ、今回はっきりしたことがあります。一時間で形になったのは、土台がもう出来ていたからです。動画を組み立てる道具、音声を合成する道具、動画からコマを抜き出す道具──全部すでに手元にありました。今回作ったのは、その上に乗せた薄い窓でしかありません。ゼロから始めていたら、一時間では終わっていません。
だから次に何か作るとしたら、狙い目は「道具は揃っているのに、見る窓だけが無い」ところだと思っています。実際、解説ものがまさにそれでした。全コマを一枚に並べて眺めるための仕組みは前からあったのに、そこに良し悪しを付けて記録する窓が無かった。
作った日に、自分で壊した
正直に書きます。作った当日に、自分でこの道具を使って事故を起こしました。
動作を確かめるために、読みを保存する処理を実際に走らせました。壊さないように、わざと同じ文字列で保存しています。中身が変わらなければ被害は無いはずだ、という理屈です。確かめるために保存の前後でファイルの指紋を取って、一致することも見ました。中身は無傷でした。
ところがしばらくして、一覧の先頭に見慣れないものが上がってきました。五月に作ったテスト用の動画が、今日の日付になって先頭に居る。
原因は自分の書き込みでした。ファイルの中身は変わっていなくても、書き込みという行為そのものがフォルダの更新日時を動かす。一覧はその日時の新しい順に並べているので、五月の案件が先頭へ飛び出したわけです。
指紋を照合して「無傷です」と言い切ったのは、私でした。中身が無事なことと、何も動いていないことは、別の話でした。書き込みで動くものは三つあります。中身と、ファイルの日時と、それが入っているフォルダの日時。三つ目を見ていませんでした。
日時は元に戻しました。厳密な元の秒は復元できないので、そのフォルダで一番新しかった実ファイルの日時に合わせています。そこは正直に書いておきます。
事実と見立ての仕分け
事実として測ったもの。
- 判定を埋めた WAV は、PCM が元と完全一致し、長さも 7.274667 秒で変わらなかった。判定を消せば元のファイルとバイト単位で一致した
- 判定のかたまりの大きさは、OK だけなら 62 バイト、理由と覚え書きを付けて 110 バイト
- 解説ものはセクション 12 個に対し字幕 84 枚。音声はセクション単位で 12 個
- 動画からセクションごとの代表コマを 12 枚抜き出すのに 0.95 秒
- 自己点検 20 項目すべて通過
見立てとして書いたもの。
- 「作り直したら検品やり直し」が仕組みとして成り立つのは良い性質だ、というのは私の評価です。作り直すたびに前の判定が消えるのを不便と感じる人もいると思います
- 「決まった工程はボタン、決まっていない工程はチャット」という線引きは、私が自分の作業に当てはめた結果です。動画以外の仕事で同じ線が引けるかは試していません
- 「道具は揃っているのに窓だけ無い」を次の狙い目と書きましたが、これは今回一回の経験からの見立てです
- 四か月前のバッチが十一行で、今日のものが三行で、構造が同じだったのは事実です。ただしそこから同じように育つだろうというのは、私の予想にすぎません。この道具はまだ一日しか使っていません
正直な線引き
- この道具は公開していません。 自分の動画フォルダの形（台本の書き方、絵の並び方、音声の置き場)に合わせて作ってあるので、そのままでは他所で動きません
- 判定を埋めるのは、私の手元のファイルに対してだけです。他人から預かったファイルに勝手にかたまりを足すのは、やめておいたほうがいいと思います
- 動画の絵を作り直すところは道具の中に入れていません。リテイク一覧に出るコマンドを、自分で流します
- 解説ものの音声は、一つのセクションだけを作り直すことができません。台本まるごと合成し直しになります。既存の道具がそういう作りなので、直すならそちら側の話です
- 判定を埋めても壊れないことは、私が使っている経路（音声を扱う標準の部品と、動画の変換の道具）で確かめただけです。世の中のすべてのソフトで確かめたわけではありません
- 一覧の並び順は、フォルダの更新日時の新しい順です。検品して判定を付けると、その動画のフォルダの日時が動いて、一覧の先頭へ上がります。これは承知のうえでそのままにしています
解説動画
この記事の話は、5分弱の動画にもしてあります。合成音声のナレーションとスライドで、検品の窓を作って、判定を絵と音に押していくまでを追う形式です。
おわりに
窓を一枚付けただけで、検品が座ってできるようになりました。
やってみて一番効いたのは、速くなったことよりも、伝えなくてよくなったことだったと思います。三コマ目の読みの長音がひとつ多い、と誰かに説明する必要がない。その字の上をクリックして、消して、保存する。それで終わる。
判定を品物に押すことにしたのも、結局は同じ話かもしれません。どこかに記録して、それを誰かに伝えて、突き合わせてもらう──その往復を消したかった。品物を見れば済むなら、それが一番速い。
名前を検品マネージャーにしたのは、以前から使っている道具と並べたかったからです。その一本の VBA マネージャーが、四か月前どんな姿だったか気になって見にいきました。**バッチファイルが一本、残っていました。**十一行です。自分の置き場所へ移って、文字が化けない設定にして、Python を呼ぶ。それだけでした。
今日書いた起動用のバッチは、三行です。
@echo off
cd /d "%~dp0"
py server.py
三行と十一行の違いはありますが、やっていることは同じでした。自分の場所へ移って、Python を呼ぶ。四か月前に呼んでいたファイルの名前は menu_launcher.py──献立を出すものです。番号の並んだ画面が出て、番号を打つ。今日のものは、その献立が一覧の画面になって、番号を打つ代わりに押すようになっただけです。
あの道具は、そのあと入口が増えていきました。バッチの献立から始まって、打ち込みで使えるようになって、いまは私が言葉で頼めば動きます。入口は増えましたが、中身は同じ場所に居続けています。
こちらも、そうなるのかもしれないと思っています。いまは画面という入口が一つあるだけですが、判定は品物そのものに埋めてあるので、読み口だけ足せば外からでも拾えます。そうなれば、私が押した赤い印を見て、直しのほうを誰かに任せる、という形もありえます。
ただ、ひとつだけ動かさないつもりでいることがあります。良し悪しを決めるところは、自分で押す。 育つとしたら、画面が縮んでいく方向ではなく、画面の外側に口が増えていく形だと思っています。
まだ道具の無いところが、いくつも残っています。
それでは、また。