「自動化は、作り終えた瞬間がピークだ」
作っているときが一番楽しくて、完成した翌週にはもう起動していない。そういうスクリプトが手元にいくつも転がっています。
ただ、ひとつだけ例外がありました。毎朝ニュースを集めて原稿を書き、音声にして配信するパイプライン。これだけは61日間、通勤の車の中で聞き続けています。
この記事は作り方の解説ではありません。61日・41本・12.2時間を実際に運用して、何が壊れ、何が続いたかの記録です。台本の20.8%が英語のまま読み上げられていた話も、そのまま書きます。
実行環境: MacBook Pro（Apple M5 / 10コア / メモリ 16GB）、macOS 26.5.2、Python 3.14.5、ffmpeg 7.1.1、Irodori-TTS v4.1-Small（MPS・fp32）。配信先はVPS（nginx）。数値はすべて2026年8月26日時点の実測値です。
61日で41本・12.2時間。まず数字を出す
2026年6月27日に最初のエピソードを生成してから、8月26日までの実測値です。
| 指標 | 実測値 |
|---|---|
| 稼働期間 | 2026-06-27 〜 2026-08-26（61日） |
| 総エピソード数 | 41本（日本語33本 + 英語8本） |
| 総音声時間 | 733.5分（12.2時間）※日本語のみで589.0分 |
| 平均の長さ | 17.9分（直近10本の平均は22.2分） |
| 最長 / 最短 | 29.4分（7/15） / 1.2分（初回 6/27） |
| 台本の総文字数 | 173,399字（平均5,255字/本） |
| 総発話チャンク数 | 3,169 |
| 中間wavキャッシュ | 6.4GB |
毎日ではありません。平日中心で、61日のうち33日ぶんです。ここは正直に書いておきます。
この表で一番意味があるのは平均値ではなく、7月14日の断層です。
20260713 6.7分 台本 1,975字
20260714 22.0分 台本 6,354字 ← ここ
20260715 29.4分 台本 8,305字
日本語版33本の実測。7月14日以降は20〜25分で安定している
前半（6/27〜7/13）は見出しを読み上げるだけの自動生成で、4〜6分でした。7月14日から、その日のニュースを実際に調べて「見出し＋中身2〜3文＋なぜ重要か」まで書く原稿執筆を挟むようにしました。それだけで1本が20分を超え、直近3本は24.6分・25.9分・24.9分で安定しています。
聞く価値が出たのはこの断層より後です。前半の見出し読み上げ番組は、正直2回で飽きていました。
既製品で足りるはずだった。なぜ自分で組んだのか
「日本語に対応していないから自作した」という話ではありません。
調べ始めた当初、私は「NotebookLMのAudio Overviewsは英語のみ」という情報を見つけて、それを自作の理由にしかけました。再確認したら間違いでした。Audio Overviewsは2025年4月30日に日本語対応済みで、現在は50言語以上に対応しています（英語限定なのは対話モードのみ）。NotebookLM自体も2026年7月16日に「Gemini Notebook」へ改称されました（リネームで、既存ノートは引き継がれます）。※2026年8月時点
言語は理由になりませんでした。候補を順に落とした結果が下の表です。
| 候補 | 落とした理由 |
|---|---|
| NotebookLM / Gemini Notebook | 資料を毎回手動でアップロードする必要がある。毎朝それをやる自信がなかった |
| ElevenLabs | 品質は高いが従量課金。台本173,399字という規模を毎月積むと課金が読めない |
| castmake / Lisnify などのSaaS | 入力がRSSに限定される。私のソースは自分のObsidianに溜まった収集結果 |
残った要件は3つです。①ソースが自分の集めたものであること ②毎朝自分が何もしなくてもその日のぶんができていること ③積み上がっても追加コストが増えないこと。
効いたのは3つ目でした。61日で12.2時間ぶん生成していますが、TTSはローカルなので追加料金はゼロです。従量課金だったら途中で「今日はいいか」と止めていたと思います。
構成は4つに分かれている
パイプラインは意図的に4つに割ってあります。
破線がクラウドとローカルの境界。重い処理が右側にあることが、課金されない理由になっている
分けている理由は、動く場所が違うからです。
収集はネットワークとテキスト処理しか要らないのでGitHub Actionsのcronに載り、私のMacが起動していなくても毎朝走ります。一方で音声生成はMPS依存で、GitHub Actionsのランナーには載りません。
この制約は当初、不便だと思っていました。「全部クラウドで完結させたい」と考えていたからです。結果的にはこれが効きました。重い処理がローカルにあるおかげで、課金される部分が存在しない構成になったからです。
音声エンジンは Aratako/Irodori-TTS-v4.1-Small（2026年8月11日公開、約7.7億パラメータ）。ローカルで動く・商用利用可・参照音声1つでゼロショットのボイスクローンができる、の3点で選びました。※2026年8月時点
実行はこれだけです。
python3 podcast.py <date> --deploy # TTS → mp3連結 → VPS配信 + RSS更新
台本の20.8%が英字のまま読まれていた
ここが61日間で一番痛かった発見です。
日本語TTSは生の英単語をうまく読めません。だから台本には英字を残さずカタカナに直す、というルールを最初から決めていました。決めていたはずでした。
8月に全台本を機械的に監査したところ、2,443チャンク中509件（20.8%）に英字が残っていました。 以下は実際に配信済みの音声に混入していたものです。
Markdown→ 「マンクガンドゥ」Secure Enclave→ 「セルンエンクライブ」npx→ 「エヌエックスピー」（N・P・X の順序が入れ替わっている）
車の中で「マンクガンドゥ」と聞こえたときは、何の話か本気で分かりませんでした。
さらに悪かったのは、遵守率が回ごとに0%〜89%まで振れていたことです。原因ははっきりしていて、ルールが書き手（この場合はClaude）の記憶に依存していたからです。長い原稿を書いているうちに、ルールが後ろへ流れていく。
対策として、TTSの前に機械的なゲートを置きました。
python3 lint_script.py <date> # ERRORが出ているうちは音声生成へ進まない
検査しているのは、①生の英字の残存 ②略語の逐字カナの誤り ③1発話が110字を超えていないか、の3点です。読み方の正解は reading-dict.json に貯めていき、辞書にない語は追記してから使うルールにしました。
学んだのはTTSの話というより、運用の話でした。注意力に依存するルールは守られない。 機械で止めるところまで作って、はじめてルールになります。
生成は音声長の2.5〜3倍かかる
もうひとつ、素朴に間違えていたことがあります。「25分の音声なら生成も25分くらいだろう」と思っていて、ドキュメントにもそう書いていました。
実測したRTF（実時間比）は2.56〜2.90。8月14日の回では22.5分の音声を作るのに19:16から20:13まで約58分かかりました。3倍近いです。
気づいた時点でドキュメントを訂正しました。「1時間前後かかる」と最初に言えるかどうかで、待っている間の体感がまったく違います。
この重さがあるので、中間のwavはテキストと声のハッシュでキャッシュしています。原稿を直しても、変わったチャンクだけ作り直せば済む設計です。代償として、キャッシュは現在6.4GBまで膨らみました。定期的に古い日付を捨てる必要があります。ここは自動化できていません。
配信範囲について
ひとつ補足します。このPodcastは自分だけが購読する非公開フィードです。ニュース記事の要約を音声にして不特定多数へ配信することは、引用の範囲や権利関係の判断が別途必要になります。私はその判断を避けるために、最初から自分専用に閉じました。同じ構成を公開向けに使う場合は、ここは各自で確認してください。
61日続いた理由は、意志ではなく構造だった
冒頭の話に戻ります。私が作って捨ててきた自動化と、これとの違いは何だったのか。答えはおそらくこれです。
完成したあとに、自分へ毎日結果が返ってくるかどうか。
捨てた自動化には共通点がありました。完成した時点でやることがなくなるのです。動いているかどうかは、確認しに行かなければわからない。だから確認しなくなり、壊れても気づかず、そのまま忘れる。
このパイプラインは違いました。聞くという行為が、そのまま動作確認を兼ねています。 生成が失敗していれば無音で気づくし、読み方がおかしければ耳が拾う。「マンクガンドゥ」に気づけたのも、毎日聞いていたからです。
続けるための意志は必要ありませんでした。必要だったのは、完成後に結果を強制的に受け取る導線のほうです。車の中という、他にやることがない20分がそれでした。
自動化を作るとき、今後は着手前にこれを決めておこうと思っています。「これが完成したら、自分は毎日どこでその結果を受け取るのか」。答えられないなら、それはおそらく完成した週に死にます。
まとめ
- 61日で41本・12.2時間。効いたのは仕組みの完成度ではなく、7月14日に原稿執筆を挟んだこと（1本4分→22分）
- ローカルTTSを選んだ理由は言語ではなく課金されないこと。積み上がってもコストが増えない構成だから止まらなかった
- ルールは注意力ではなく機械で止める（英字残存20.8%は人間の記憶では防げなかった）
- 生成時間は音声長の2.5〜3倍。先に知っていれば体感が変わる
- そして一番大きかったのは、完成後に毎日結果が返ってくる導線があったこと
作り方そのものは、正直なところ既製品でも近いことができます。NotebookLMでもn8nでも組めます。61日ぶんの差が出たのは、そこではありませんでした。
コメント