なぜMeetやZoomで録らないのか —— 自作ツールで支えるポッドキャスト収録の技術

なぜMeetやZoomで録らないのか

00:08 から再生する

今回はcatatsuyがhentekoに、番組の収録や編集、最近始めた予告編動画の作り方を尋ねる形で進みます。hentekoによると、ポッドキャストの運用は企画・収録・編集・最終確認・配信準備・広報とざっくり6工程に分かれ、意外と手間がかかるといいます。八百万のOSSという番組の性質もあり、hentekoは各工程のツールをできる限り自作しているそうです。

まず話題になったのが、なぜMeetやZoomの録画で済ませないのか、という点です。理由は大きく2つあります。1つは音質の劣化です。Meetで録画すると音源はクラウドにアップロードされ、圧縮された状態でダウンロードすることになるため、ローカルの音源そのものではなくなってしまいます。

もう1つが、より重要な「話者ごとのトラック分離」です。catatsuyの音声、hentekoの音声を別々のファイルとして残したいのだといいます。片方が喋っている最中にもう片方の環境で変な音が鳴っても、分離されていればそのトラックだけを無音にできるため、後の編集がやりやすくなるからです。

catatsuyが「音量の違いや性質の違いで別処理をしたいのか」と尋ねると、hentekoはそこはあまり関係ないと答えます。音量差などは後の編集でAIなどを使って調整できるため、とにかくファイルが分離されていることこそが重要だといいます。

ブラウザ収録ツール「Maycast Room」の仕組み

01:39 から再生する

収録に使っているのが、hentekoが自作した「Maycast Room（メイキャストルーム）」です。特徴は、各話者がブラウザでURLにアクセスするだけで収録できる点にあります。Zoomのようにアプリをインストールしなくてもよく、Meetに近い感覚で使えます。

技術的には、各話者のローカルPCで録音しながら、音声データを細かくチャンク分割して裏でリアルタイムに非同期アップロードしています。そのため録音終了と同時に音源の回収がほぼ完了しているといいます。

内部では映像トラックを持たない「Fragmented MP4」を作り、分割可能なフォーマットで音声トラックだけをアップロードしています。この処理にはWasmを利用しており、JavaScript単体ではCPU的に追いつかない可能性があるためだといいます。MP4の生成にはMediabunnyブラウザ上で音声・動画ファイルを扱うためのライブラリ。MP4などのメディアファイルを生成・分割できる。というライブラリを使っています。

サーバー側の構成は極めてシンプルです。インフラはCloudflareCDNやエッジコンピューティングを提供する企業。個人でも低コストで高機能なインフラを構築できる。を使い、チャンクファイルはブラウザから署名付きURLでR2Cloudflareのオブジェクトストレージ。S3互換のАPIを持ち、データ転送料が無料に近いのが特徴。へ直接アップロードします。サーバーがやることはR2への保存のみで、重い非同期処理は走りません。

チャンクの結合とエンコードもブラウザ側で行い、最終的にM4Aとしてダウンロードします。サーバーで動画ファイルを作ろうとするとFFmpegで頑張ったり時間がかかったりと大変なため、この構成は個人運用として現実的だとcatatsuyも評価します。しかもCloudflareの有料Workersプランなら月5ドル程度ですべて賄えるといい、2人はコストの安さに感心していました。

ブラウザ完結がもたらすセキュリティ上の利点

11:01 から再生する

catatsuyが指摘したのが、ブラウザ完結であることのセキュリティ面の利点です。以前話題にした、あるサプライチェーン攻撃の事例では、音声アプリのインストールを促す手口が使われたといいます。番組では今後ゲスト、特にOSSに取り組む人を呼びたいと考えており、もし収録にMacアプリのインストールを求めるなら、まさに同種のリスクを相手に負わせてしまうことになります。

素性のわからない相手が作ったネイティブアプリをいきなり入れて収録するのは、確かに抵抗があります。その点、ブラウザで完結していればブラウザのサンドボックス内で動くため、セキュリティレベルをそこに合わせられます。ウェブエンジニアである2人は、ブラウザからの攻撃が相当難しいことを知っているため、「ブラウザで完結するなら全然怖くない」と口をそろえます。

ただしhentekoによれば、セキュリティは狙って得た結果ではなく、副産物だといいます。もともとの動機は、ゲストや他のポッドキャスト収録でも使えるように、Mac・Windows・LinuxなどどのOSでも動くようにしたかったからです。ネイティブアプリだと特定OSしか対応できませんが、ブラウザなら誰でも使えます。その結果として、セキュリティ面でも嬉しい「三方良し」になったという流れです。

さらにMaycast Roomには、旧来のワークフローの課題を解決する狙いもありました。従来はQuickTimeなどで各話者がローカル録音していましたが、これには2つの問題がありました。1つは「どのマイクを使っているかわからない問題」です。設定が奥まっていて、ShureのマイクのはずがAirPodsのマイクになっていた、といった収録ミスが起こりがちです。もう1つが「頭が合わない問題」で、各自がボタンを押すためゼロ秒のタイミングがずれてしまい、以前は全員で一斉に手を叩いて波形を合わせていたそうです。

Maycast Roomでは、管理者が各話者の使用マイクを確認でき、録音をミリ秒単位で一斉に開始できます。catatsuyも仕事のMeetでBluetoothイヤホンにマイクが切り替わってしまう経験があり、最初に選択中のマイクが表示されるのは地味に嬉しいと語りました。

非破壊編集アプリ「Maycast Studio」

19:00 から再生する

編集ツールが「Maycast Studio」で、こちらはすでにOSSとして公開されています。収録ツールと違い編集はhentekoしか使わないため、ブラウザではなくmacOS専用アプリとして振り切って作っているといいます。開発言語はすべてSwiftです。

こだわりは「すべての操作を切り戻し可能にする」点です。編集のたびに変更したファイルをすべてスナップショットとして残していく、いわゆる非破壊的な方式で、ファイル単位で以前の状態に戻せます。catatsuyがストレージの圧迫を心配すると、hentekoは「溜まるし、たぶん大丈夫じゃない」と認めつつ、自分だけが使うので編集後に定期的に消す「パワー運用」で解決すればよいと割り切っています。

そもそも自作した理由は、Logic ProAppleの音楽制作ソフト（DAW）。プロ向けの高機能ツールで、多彩な音声編集機能を持つが操作は複雑。のようなDAWの使い方がまったくわからなかったからだといいます。hentekoが実際にやりたいのは波形を見て不要な部分をカットすることだけで、豊富な機能はほぼ使っていませんでした。それなら自分で作った方がやりやすい、というわけです。

自作の利点として紹介されたのが「スライス」機能です。収録中に「ここ切ります」といった言葉を発すると、Maycast Studioが内部で文字起こしし、GeminiGoogleの生成AI。テキスト理解・生成に用いられ、ここでは文字起こしからカット候補を検出するために使われている。を呼び出して「切る」「カット」などの発言をマーキングし、自動でカット候補として推薦してくれるのです。catatsuyも「めちゃくちゃいい」と驚いていました。

編集後には、音量レベルを合わせたりノイズを削減したりする「音声のクリア化」が必要になります。ここで活躍するのが外部サービスのAuphonic音声の自動調整サービス。音量の均一化やノイズ除去、無音カットなどをAPI経由で処理できる。です。複数トラックのまま無音部分をカットしてくれるのが強みで、他のサービスは一度シングルトラックに統合してから処理するものが多いといいます。マイクごとの雑音を消したいときなど、マルチトラックのまま処理できる方が精度を上げやすいと2人は語ります。Maycast StudioはこのAuphonicのAPIを内部から呼び出しています。

文字起こしとMP3の呪縛

27:33 から再生する

Maycast Studioの内部では、Apple公式のSpeechAnalyzerAppleが提供する音声認識フレームワーク。ローカルのCPUで動作し、無料かつ高精度な文字起こしができる。を使ってローカルで文字起こしをしています。精度がかなり良く、無料でローカルCPUを使うため、Whisperなどを下手に使うより公式APIを使う方がよいとhentekoは推します。マルチトラックのため話者分離もきれいにできる点が大きな利点です。

WWDCで発表された新しいmacOSではSpeechAnalyzerにも話者分離APIが追加されたそうですが、hentekoはその精度に懐疑的です。音質や声質で分ける方式だと推測され、元からトラックが分かれていればそんな処理は不要だからです。「絶対トラックは分けた方がいい」という点で2人の意見は一致します。

最終的に配信用の音源はシングルトラックの1つのMP3として書き出すため、ここだけはFFmpegで結合しています。その背景にあるのが「MP3の呪縛」です。本当はMP4と互換性の高いM4Aで書き出したいところですが、M4Aでチャプター付きの音源をSpotifyなどにアップロードすると、Android端末でチャプターが表示されない問題が発生したといいます。この問題を報告したのはcatatsuy本人でした。

結局MP3にせざるを得ないのですが、ここでもう一つ問題が起きます。Appleの公式の音声書き出しAPIではMP3を出力できないのです。そのため、この部分だけはFFmpegに頼ることになりました。

catatsuyも、ポッドキャスト運営者のブログでは「MP3以外使うな」と書かれていることが多く、おそらく同じような互換性問題を踏んだ結果だろうと共感します。FFmpegに投げてしまえばコマンド実行だけで済み、チャプター対応もできるため、割り切ってしまえばエクスポート処理はかなり楽になったといいます。

なお最終確認には、自分の実装を信頼しないという立場から別実装のツールを使いたいそうです。hentekoはブラウザで動くミニプレーヤーを1時間ほどで作り、MP3を投げれば倍速再生やチャプタープレビューができるようにしています。catatsuyは多様なフォーマットに対応するVLCオープンソースのメディアプレーヤー。ほぼあらゆる音声・動画フォーマットを再生できる定番ツール。を使っていると話しました。

Deepgramと予告編動画の作り方

36:38 から再生する

配信準備では、hentekoが文字起こしをした上でClaude CodeAnthropicが提供するコーディング支援AI。「スキル」として定型作業を登録し、コマンドから呼び出せる。のスキルを使い、タイトルや概要欄のメタデータを生成しています。その結果をクローズドのGitHubリポジトリにプルリクエストとして出し、catatsuyがレビューする流れです。catatsuyは自分の作業をCodexに丸投げしていると話し、2人とも生成AIを組み込んだワークフローに慣れてきたといいます。

ここで使うのがDeepgramクラウド型の音声認識サービス。文字起こしの速度が非常に速いのが特徴。です。SpeechAnalyzerは精度は高いものの、50分の音源で2分ほどかかり、Claude Codeのスキルから呼び出すにはバイナリの用意も必要で面倒でした。そこでhentekoは「deepgram-cli」を自作し、配信準備の文字起こしにはDeepgramを使っています。精度は若干落ちるものの、とにかく速いのが魅力です。

catatsuyも「10秒でいけるのはやばい」と驚きます。さらにDeepgramは新規登録で200ドルのクレジットがもらえ、これまで50分×約50本を文字起こししてもなお170ドルほど残っているといい、実質無料で運用できているそうです。生成したメタデータはcatatsuyの確認を経て、最終的にSpotifyへ手動で登録します。Spotifyには公式のアップロードAPIがまだなく、非公式APIは存在するものの使わない方針です。

そして最近始めた予告編動画です。映画の予告編のようにポッドキャストの内容をかいつまんで見せられれば、聞かれるまでのハードルを下げられます。catatsuyも「ポッドキャストは聞かれるまでのハードルがめちゃくちゃ高い」と、この取り組みを高く評価します。

予告編はRemotion前述のとおり、Reactで動画を生成できるOSSツール。公式がClaude Code用のスキルを提供している。で作っています。RemotionはReactのコンポーネントのアニメーションをヘッドレスブラウザで1フレームずつレンダリングして動画化するツールで、公式がClaude Code用のスキルを公開しています。hentekoはそこに自分が溜めた知見を織り込んだ「ポッドキャストトレーラースキル」を作り、音源ファイルと文字起こしデータを渡せば、いい感じの箇所を切り抜いた動画を作れるようにしています。

catatsuyが評価したのは、最終的にReactのコードになる点です。AIに動画をポン出しさせると日本語フォントが崩れたり、特定の文字だけ直せなかったりしますが、Remotionなら文字をソースコードとして渡せます。使う文言はmanifest.jsonで管理されており、これをcatatsuyに共有することで細かい用語修正ができるようになっています。

切り抜き箇所の抽出はAIに任せています。冒頭にフックとなるシーンを置き、最後に山場を持ってくるといった予告編の「型」を加味しつつ、1分に収まるよう1.8倍速ほどで詰めてもらうそうです。catatsuyによると知り合いに一番聞かれるのは動画の作り方だといい、実際にTwitterでも作り方を尋ねるコメントが来たとのこと。hentekoはこの仕組みが定まったらOSSとして公開したいと話します。

失敗した切り抜きツールが予告編につながった話

45:57 から再生する

最後に、うまくいかず捨てたツールの話です。3ヶ月ほど前、hentekoは「Maycast Caption」というツールを作っていました。音源をアップロードすると全文を文字起こしし、GeminiなどのLLMでいい感じの箇所（ハイライト）を自動抽出、その部分をカットした音源をダウンロードできる、というものでした。切り抜き音声を作れると考えたのです。

しかし、結局使わなかったといいます。技術的な問題ではなく、ハイライトを自動抽出しても「それがどうした」という感覚になり、シンプルに面白くなかったからです。応用イメージも湧かず、ツール自体はなくしてしまいました。

ただ、この経験が予告編につながりました。AIでハイライトを自動抽出できるという発見は残り、単なる切り抜きから「映画の予告編にした方が面白いのではないか」というアイデアへと転じたのです。hentekoは「これをやっていなかったら、たぶん予告編もできていなかった」と振り返ります。失敗したツールが次の成功の種になった、という好例です。

まとめ

今回は、hentekoが八百万のOSSを支える自作ツール群をざっくばらんに解説する回でした。ブラウザ収録の「Maycast Room」、非破壊編集の「Maycast Studio」、SpeechAnalyzerとDeepgramの使い分け、そしてRemotion製の予告編動画まで、ポッドキャストの裏側が一通り見えてきました。

共通して流れているのは、「自分のワークフローに合わせて自作する」「できる限りコストをかけない」「割り切るところは外部ツールに任せる」という思想です。catatsuyも番組の裏側を知る良い機会になったと語り、これから自分でポッドキャストを始めたい人にとっても実践的なヒントの詰まった回となりました。