Excel講座のナレーションを本人の声で一括合成した日

Excel基礎講座（eurekapu-nuxt4）のナレーションは、台本を書き、本人の声で合成し、R2 へ上げるという3工程で作る。 この日は、章2と章3、さらに残りの7ページまでをこの3工程で回した。

途中で、Mac にも合成を分担させることにした。 Mac の速度は Windows の半分くらいだったはずだ、という記憶が頭の隅に残っていた。

台本は5体ずつ下書きさせて、全文を読ませてから差し込む

章2は、動画3本の画面変化の時刻を測るところから始めた。 書式設定の動画は、止める位置（holdAt）が4.5秒、8.0秒、16.3秒、18.4秒に決まった。 章2の25区間のうち、動画のない22区間は台本を JSON にまとめてスクリプトで講座データへ差し込み、動画つきの3区間（検算、書式設定、列幅1）は手で編集させた。

章3は、サブエージェント5体に66区間の下書きを分けて書かせた。 内訳は、絶対参照が13区間、SUMIFS と INDIRECT が12区間、VLOOKUP が10区間、INDEX/MATCH が13区間、残りの1体が18区間である。

下書きが戻るたびに、親セッションの Claude Code に全文を読ませてから、講座データへ差し込ませる。 差し込んだあとは静的検査と、ブラウザでのセレクタ検査を通す。 この順番を崩さなかった。

レビューで引っかかった点もある。 絶対参照の担当が「演習 c01-s00 は動画が2本ある」と申し送ってきた。 差し込みスクリプトは1区間に動画1本の前提で書いていたので、スクリプトを拡張し、作業中の3体にも同じ形で書くよう伝えた。 2拍を直したときは、同じ落とし穴を残りの下書きで機械的に拾えるよう、差し込みスクリプトの検査に1条件足した。

章3の拍つき24区間の111拍は、どれも見えている要素ちょうど1つに当たった。 53区間まで入った時点で、289クリップ、44,128字になっていた。

1回目の学びは共通ルール（BRIEF.md）に書き足し、2回目の5体を残り7ページの86区間に向けて起動した。 2回目もほぼ同じ流れで進んだ。 ただ、最後の演習の3区間は動画が 404（aaa.mp4）を返したため、未完のまま残した。

コミット 48120003 では、差分が 3,274 行あり、Codex レビューは今回もタイムアウトした。

1区間に10分かかっていた

合成は Irodori-TTS で、参照音声には本人の声を使う。 先に合成したⅡページは、6本で通し4分50秒だった。 47文を717秒、1文あたり約15秒で合成したことになる。

章3の合成を回していると、完了数が9分ほど14のまま動かなくなった。 止まっていないか確かめてもらうと、GPU は 99% で、最新の生成ファイルは 09:44:33 に書かれていた。 動いてはいた。 文数の多い区間で10分ほどかかっていて、常駐している音声入力と NVIDIA Broadcast が GPU を取り合っていた。

NVIDIA Broadcast はその場で自分で終了した。 自分では気づかないときがあるので、音声を生成するときは Claude Code が Broadcast を止めてよい、と許可も出した。 合成スクリプトが自動で止めるように変えてもらい、許可したことも記録に残させた。

もっとも、その直後に測ってもらうと、遅さの主因は別にあるという答えが返ってきた。 Broadcast を止めただけで片づく話ではなかったらしい。

章3は、10:02 に17区間、10:21 に21区間、11:19 に41区間まで進んだ。 完了した区間は、すべてグリッド検査を通っていた。

参照音声は Irodori-TTS のフォルダに入っていなかった

Mac に合成を分担させるには、Mac 側にも参照音声（本人の声の元データ）がそろっていなければならない。 そこで、ローカルの Irodori-TTS に参照音声が入っているかを確かめさせた。

入っていなかった。 C:\Users\numbe\Git_repo\Irodori-TTS は作者（Aratako）の公開リポジトリをクローンしただけのもので、remote も Aratako/Irodori-TTS だった。 自分の GitHub にフォークもない。 参照音声は untracked のファイルとして置かれているだけだった。

このフォルダごと自分の private リポジトリとして push する案も出た（ライセンスは Apache-2.0）。 最終的には、参照音声だけを入れた private リポジトリ keikomatsu/irodori-refs を Git_repo 直下に置き、これを正本にした。

8月に Mac で録音した分もここに入れた。 合成のキャッシュの鍵にファイルの更新時刻が入っているため、更新時刻を保ったまま入れ直してもらった。 Irodori-TTS の中のフォルダをリンクに置き換える作業は、合成がそこを読んでいる最中だったので後回しにした。

Mac 側からは、record.sh と 読み上げ台本.md を refs-mac-2026-08/ に足して push した（master 53c4c03）という報告が届いた。 Mac が報告してきたハッシュと Windows の原本を突き合わせ、GitHub 上の中身も直接見て、渡せていることを確かめた。

Mac は本当に半分の速さなのか

Windows から Mac へは、cross-machine-message の LAN 直送で指示を送る。 最初に送ったときは Mac 側のブリッジが応答せず、タイムアウトした。 11:31 に Mac から疎通テストが届き、ここから経路がつながった。

分担は、Mac が donts 以降のページを合成して R2 へ上げ、Windows はその到着を監視して取り戻す形にした。 Mac の速度は Windows の半分くらいではなかったか、と聞いたときの答えは、半分でも248クリップなら2〜3時間で終わるので割り振る価値はある、というものだった。 Mac 用のアップロードと、Windows 用の取り戻しのスクリプトを1本ずつ書いてもらった。

Mac からの完了報告は、ページごとに届いた。

どのページもグリッド検査の NG は0件だった。 Windows 側で取り戻したあと、通し時間が manifest の秒数と一致するか（Stream Deck なら 3:04 と184秒）を確かめ、再生位置が進むことまで見てもらった。

Stream Deck の時点で出た Mac の速度は、1文5.5秒だった。 朝のⅡページは Windows で1文約15秒だったので、数字の上では半分どころではない。 ただ、Ⅱページは GPU の取り合いがあった時間帯の値で、条件がそろった比較ではない。

連鎖スクリプトが止められた

分担を決める前、Windows では、章3のあとに残りのページも続けて合成する chain-synth.sh を走らせていた。 章3の完了後に R2 へ上げるだけの縮小版 chain-functions-only.sh は、11:48 から動かしてあった。 Mac に donts 以降を任せたので、古い連鎖は自分で kill 40311 して止めた。

その縮小版が、システムのメモリ不足を理由に Claude Code 側で停止された。 処理自体が失敗したわけではない。 章3の合成自体は exit code 0 で終わっており、R2 へのアップロード（436 ファイル、979MB）はその後に進めてもらった。

章3の実測は 370 クリップ、2時間57分44秒で、推定の2時間56分とほぼ一致した。

字数と長さを表にまとめる

計画書の表に「字数」と「長さ（実測・推定）」の2列を足してもらった。 合計は 161,140 字、約7時間44分である。 表が狭かったので、表だけ max-width を外してもらい、幅は 812px から 1100px に広がった。 11列が横 1076px に収まることを Chrome で確かめた。

完成した音声は、Stream Deck の時点で 948 本、ai-tools の時点で 992 本になった。 最後の exercises が届いて、Mac 担当の7ページはすべて R2 に上がった。 記録のコミットでは、197 区間の本数にⅡページの6本が混ざっていると Codex に指摘され、集計範囲を分けて書き直した（d8d01448）。

学びメモ

• 台本の下書きは5体ずつに分けても、差し込む前に親セッションへ全文を読ませる手順を外さなかった。申し送りで動画が2本ある区間が見つかれば差し込みスクリプトを拡張し、レビューで直した落とし穴は検査条件に足して、残りの下書きでも機械的に拾えるようにした。
• ローカルの Irodori-TTS は公開リポジトリのクローンで、自分の声はそこに入っていなかった。コードは借り物として置き、参照音声だけを private の irodori-refs に集めたので、Mac は clone するだけで同じ声を使える。
• 9分動かない進捗は、止まっていたのではなく1区間に10分かかっていた。GPU の使用率と最新ファイルの時刻を見れば、止まったかどうかは判断できる。

Mac は半分の速さだという記憶は、1文5.5秒という数字の前でぐらついた。 ただ、同じ条件で両機を測った値はまだない。