ちょっと今回は、自分が henteko さんに聞いてみたいんですけど、いいですか?
はい、もちろんです。話していきましょう。
はい。我々、なんかこうやってポッドキャストを始めたじゃないですか。
はい。
それで、今もまさに henteko さんが作ったウェブサービスで録音してるし、
あと、録音者データの編集とか、あと最近なんかツイッターで動画もなんか出してるじゃないですか。
はい。
この辺、なんか何が必要で、どうやってるのかって、自分もちゃんと知っておきたいなと思ってるんですけど、
この辺り教えてもらっていいですか?
はい、もちろんです。
まず最初何から話していこうかなってとこなんですが、
ポッドキャストの運用って、結構いろいろ工程あったりするんですけど、
すごいざっくり言っていくと、企画、収録、編集、最終確認と、
あと配信準備、広報みたいな形で、全部で6つぐらいかな。
6つぐらいの、ざっくり分けると6つぐらいの工程に分かれてたりするんですが、
結構意外とめんどくさいんですよね。
いろいろやることがあるなと思う。
いろいろあるなという感じで。
各工程において、ちょっと自分の性格上、あとはこのYaoyorozのOSSという性質上ですね、
いろいろOSSとしてできる限り自作していきたいなというような感じで、
企画運営をやってたりしますね。
この中の、特に今話しにあがった収録のツールみたいなところも自作していたりするんですけど、
ここら辺から話しできればいいかなという感じですかね。
そうですね。
まずこの今まさに撮ってる収録ツールなんですけど、
ちょっと名前つけてて、Meycastroomって名前でやってるんですけど、
これは収録ツールの特徴としては、
各話者の僕とヘンテコと片杉さんのブラウザ上で動作するようなサービス、
URLにアクセスしてもらってという感じですね。
アクセスするだけで収録ができるよというような、
Meetどっか、あとはZoomの場合はアプリ入れてもらわないと収録できないのかなと思いますけど、
Meetみたいな感じですね、ざっくり言うと。
各話者のローカルPCで録音しつつ、音声データを細かくチャンク分割して、
裏でリアルタイムで非同期でアップロードして、
録音終了と同時にはもうすでに音源回収ができてるみたいなツールを自作していたりしますね。
Meetだと音質悪くなるじゃないですか。
それでローカルで録りたいっていう意図なんですか、これは。
そうですね、Meetの場合は基本的に、Meetでももちろんバックアップとして録音録画してるんですけど、
そうしてしまうとやっぱりローカルの音源ではないんですよね。
JavaScript単体だったら結構難しいのかなというのがあって、そういった形にしているという感じがあります。
このWASMって元にFFMPEGとかそういうのをコンパイルしているんですか?
もうちょっとだけ具体的な話をすると、内部でMediaBunnyというライブラリを使っていまして、
そのMediaBunnyでMediaBunnyというライブラリでMP4を生成しているというような形になっています。
フラグメントとMP4を作っていくみたいな形になっています。
そういうのが便利に作れるようなライブラリがあってという感じです。
それって言語Cとかラストとかどれ使っているんですか?
これは今ちょっと調べたんですけど、さっきWASMを使っていると言ったんですけど、
もしかしたら内部でTypeScript Pureで書かれている気がしますね。
ちょっとここまだ調べられていないんですけど。
なるほど。
そういったものを使ってやっています。
どっちもあり得るようなと思っていて、JavaScriptのAPIを使っている可能性もあるし、
例えばGoogle Meetとかも確か背景を変える機能とかあるじゃないですか。
バーチャル背景みたいなの。
バーチャル背景みたいなの。
あの辺はWASMらしいんですよね。
なのでこの辺りってうまく組み合わせて使っている気がするので、
いろいろ使っているサービス多いと思うので、どっちもあり得そうだなとは思っていますね。
そうですね。基本的にはどっちも組み合わせて、
どっちか単体という話ではないかなと思っています。やっています。
なるほど。
それでJavaScript、ブラウザー側で頑張ってMPEG-4を作って、
それをどんどん定期的にサーバーに上げていくという形ってことですよね。
基本的にはそのアーティテクチャで収録の方はしていますね。
結果的にそのチャンク5というのを分かれたやつを最終的にダウンロードするときに、
ブラウザ側でもっかい結合して、M4Aという形でダウンロードさせるという形にしています。
それもブラウザでやるんですね。
そうです。チャンクを全部ダウンロードしてきて結合して、
エンコードし直すということをブラウザ側でしていますね。クライアント側で。
なるほど。サーバー側はどうなっているんですか?
サーバー側はファイルをインフラはCloudflareを使って、
チャンクファイルは全部R2にそのままアップロードする形にしているんですよ。
アップロードのときに、これはDevToolsとか見てもらうと、
リアルタイムに見てもらうと分かるんですけど、
R2に直接S3のサインドURLみたいな感じの機能があるので、
それで直接R2にアップロードして、サーバー側はもうそれのみなんですよ。
R2に保存するのみと。
そうですね、セキュリティ的な観点で言うと、
どこの誰が作ったっていう、信頼性がない人からのネイティブアプリを入れて、
いきなり入れて収録しましょうみたいなの、かなり抵抗ありますよね、普通に。
自分が逆の立場になったら嫌だって言うと思うんですよね。
分かります。
だからブラウザで完結してるのすごいいいなって思ってて、今のロックオンシステム。
ブラウザのセキュリティレベルに合わせられるっていうようなところですよね。
セキュリティのサンドボックスの中で動くので。
我々やっぱりウェブエンジニアなんで、
ブラウザからの攻撃って相当めんどくさいというか相当難しいの分かってるじゃないですか。
なのでブラウザで完結するんだったら全然怖くないなっていうのは結構大きいですね。
いや、でかいですよね。
ぶっちゃけここに関してはそれを意図していたわけではなくて、
アクシオスのサルプライチェーン攻撃があるからブラウザでやろうなんて全く思ってなくて、
全然違うことで、単純にいろんな人にゲストだったりとか、
あとは他のポッドキャストの収録とかでも、
僕のこのメキャストルームっていうのは使ってるんですけど、
その時に音を録るっていう収録ツールっていう観点に立つと、
例えばMac使ってる人とかWindows使ってる人とかLinux使ってる人とか、
いろんなOSがいるわけですよね。
ネイティブのアプリを入れてもらうっていう形にしてしまうと、
単純に使えないんですよね。
Macだけ対応しましたみたいな感じだとWindowsの人使えないしみたいな。
そういった観点があるので、ブラウザだったら誰でも使えるよねっていう観点で、
そっちでブラウザで使えるような形にしたっていうのがあるので、
その結果こうなったよねっていうような。
結果としてみんなが使えるし、かつセキュリティ的にも嬉しいみたいな感じになったって感じですかね。
そうですね。なんで三方良しって感じがしますね。
答えだいぶいいなと思ってますね。
ちょっと余談で他のポッドキャストがどうやって収録してるのかみたいな話なんですけど、
この収録ツール、そもそも作ろうとしたきっかけが他のポッドキャストの運営とかしている中で、
既存のワークフローがあったわけですよ、他のポッドキャストの収録ワークフローでは。
そっちでは各話者ごとにローカルの例えばMacだったらQuickTimeだったりとか、
あとはWindowsだったらちょっと名前わかんないですけど標準の録音、録画システムアプリとかを立ち上げて、
各話者ごとに全部ローカルのアプリ起動して録音開始してくださいねみたいな感じでやってたんですよ。
そうすると何が問題かって、例えば今片杉さんだったらマイクあるじゃないですか、
今MacBook Airのマイク使われてるかなと思うんですけど、
このマイクを使いたいとか、あとは逆にポッドキャストのプロデューサーの立場からこのマイク使ってください、
手話のこのマイク絶対にセットアップしてくださいとかあるわけじゃないですか、音質気にしたい場合は。
ローカルでそういった独自というか各話者のローカルで動いてるようなシステム、
QuickTimeとかだとそのマイクがどれ使って設定してるかってわかんないですよね。
ちゃんと見に行かないとわかんないですね、結構奥の方の設定見に行かないと。
全然間違ってることあるんですよ。
そうですよね。
手話のマイク使うはずだったのにAirPodsのマイクになってましたよみたいな。
それで収録ミスると痛いんですよかなり。
全然押して違いますからね。
これ使ってほしくなかったみたいなのがあると。
っていうのが1点と、デバイスがわかんない問題ですね。
使ってるデバイスがわかんない問題が1点と、
あともう1個地味にデカいのが頭が合わない問題です。
収録をするって各自がボタンをポチッと押すんで収録の音源が頭が合ってないんですよ。
0秒のタイミングが合ってないので、
これどうするかっていうと後で編集で頑張って波形を合わせるみたいなことをするんですけど、
物理的なやり方としてみんなで一斉の背でパチンって手で音を鳴らすっていうことをしてたんですよ。
その場では。
これなんだろうな、なんかテクノロジーで解決できるわなっていうような感じがあったので、
ブラウザで全員同じ部屋に入って、
ディレクターというか管理者がちゃんと使われてるマイクが、
どのマイクをこの人は設定してるっていうのが見れる状態で録音を一気に開始できる。
ミリ秒単位で合わせられるっていうようなシステムが必要だったんですよ。
っていうのでこのMakestreamを作ったっていうのがあります。
確かに結構嬉しいなと思ってて、
自分もたまにあるんですよね、仕事とかでも、
Google MeetでBluetoothのイヤホンしてるとそっちのマイク使えるんですけど、
やっぱBluetoothのイヤホンって基本的に音質悪いからMacのマイク使いたいんだけど、
なんか気づいたら切り替わってることがあって、
それでなんか音声悪いってなって、
あ、ごめん間違ってましたみたいな、結構やるんですよ。
けど今使ってるMakestreamだと最初にどのマイク選択されてるか出てるから、
Podcastの編集さんがいたりするようなところだと、
例えば普通にLogic ProとかそういうDAWって呼ばれる
商用ツールみたいなのも結構使われてるところとか結構あるかなと思うんですよね。
編集ツールって。
ただこれは僕の問題なんですけど、そういうLogic ProとかいうDAW、
全く使い方がわかんないんですよ。
この手の動画編集とかも有名なソフトはいくつかあるんですけど、
結構プロ用なんですよね基本的に。
だから使うの普通に難しいですよね。
難しいですね。何をしたらいいかわかんないですもん、そもそも。
自分もちょっと見たことあるんですけど、マジでわかんないですね。
気持ちわかります。
そういうLogic Proとかを一時期使ってたんですけど、
やってることって音声の波形を見てただ単にカット、
ここの部分はカットしたいからカットするみたいな感じなんですよ。
それしかやってないんですよ。
すごい機能とか多分あるとは思うんですけど、全く使ってないんですよね。
なので、だったら自分で作っちゃった方がやりやすいかなと思って
作ったっていうのが経緯としてありますね。
なるほど。
ここを作ったからこそいろいろできているところがあるなというのがあって、
カット編集ももちろんスタジオの方ではサポートしてますし、
このスライスのスライスっていう中で読んでるんですけど機能としては、
この機能もちょっと最近入れたのが、
ちょこちょこさっきとかこの収録の本番音源ではきっとカットされてるところなんですけど、
カットとか切ってここ切りますとか、さっき言ったかなと思って片杉さんにしかこれ伝わらないと思うんですけど、
ここ切りますとか、こういうワード入れてるかなと思うんですけど、
これも全部スタジオの方で自動で検知して、
ここの部分を切る候補にしますみたいな感じでやってたりします。
それも推薦されるってことですか?
推薦されます、はい。
え、すご。
内部で文字起こしして、その文字起こしからジェミニンを呼び出して、
カットとか切るとかそういうことを言ってるところをマーキングして、
ここ切ったほうがいいですよみたいな感じで推薦してたりしますね。
めちゃくちゃいいじゃないですか。
かなり便利になりました、それ入れて。
逆にそういうのが入れられるのが自作ツールの利点かなと思いますね。
自分のワークフローに合わせる形で。
なるほど。
これがSwiftで作ってるって感じですか?
やっぱりちゃんと元の音源から消えてほしいなっていうのはすごい思ってるんですよね。
そもそもちゃんとしといてほしいですよね。最低限は。
最低限やってほしいなと思ってて、やってほしいことちゃんとやってくれるからすごい嬉しいなと思いますね、このAPI。
ほぼほぼこいつなんですよ、オーフォニックさんがいい感じにしてくれるという、オーフォニックに全て任せろという感じなんですけど、なんかいい感じになります。
なるほど。
っていうのが大体ざっくりした編集ツールのところかなと思いますね。
他にはこの内部でAppleの公式のスピーチアナライザーとかを使ってローカルで文字起こししてたりするんですけど、
そのAppleの公式のスピーチアナライザーの文字起こし精度がかなりいいぞというような話はあったりするんですけど。
なるほど。スピーチアナライザーだと無料で使えるんですよね。
無料でローカルのCPU使うので、しかもかなり早いんですよ。
ウィスパーとか使うよりか全然公式のAPI使っちゃった方が絶対いいと思いますね。下手にやるよりか。
意外とその手のAPI使うと意外と精度悪かったりとか結構お金かかっちゃったりとかするんで、これめっちゃいいですね。
かなり精度がいいし、ちゃんとトラック分離もマルチトラックなのでしているからこそ、
変でこの和写、文字起こし、形の文字起こしみたいな感じでちゃんと分けられるんで、かなりいいなと思いますね。
逆にシングルトラックになっていると和写分離できないんですよ。Appleの公式のスピーチアナライザーだと。
この間のWWDCの2026の発表で新しくAPIが追加されて和写分離が入ったんですけど、このスピーチアナライザーには新しいmacOSでは。
ただ精度どうなんだろうなというのはちょっと怪奇的ではありますね。
たぶん音質とか声質で頑張って分けるんですよね。もともとトラック分かれたらそんなことやる必要ない?
そうなんですよ。絶対にトラックはここでも分けてとかいいんですよ。
そうですね。絶対分けた方がいいですね。
というような感じがあったり。最終的にはそのシングルトラックにして一つのMP3でエクスポートするので、最終的にはFFMPEGでガッチャンコしてます。
そこだけFFMPEGなんですね。
そうですね。ここが結構肝なところで。
Podcastって最終的にMP3でアップロードしているんですけど、MP3の呪縛から離れられないというような問題が実はありまして。
本当はM4aでアップロードしたいんですよね。
M4aの方がMP4の形式とほぼ互換性があるので、同じ実装で全て叶えるんですけど、MP3だけちょっと違うというような形で。