別表講座の解説動画46本の音声をMacで合成し、本文の数字を書籍と突き合わせた

本文の 7-5(6)「別表四の総額表示」の表を足し上げると、12,420 になった。 所得金額は 10,000 のはずである。 数字がどこかで狂っている。 本文を書き起こしたときに崩れたのか、動画を作るときに崩れたのか。

この日は、別表講座の解説動画を2つのバッチで並行して作った作業の後始末に追われた。 音声合成は Mac 側の Claude Code に頼み、Windows 側ではマージと片付け、そして本文の数字の確認を進めた。

前日からの持ち越し

動画は全56本の計画で、もとからあった10本に加えて、残りを2つの worktree で作っていた。

• バッチ1：セクション1〜5のうち、まだ無かった24本（dev サーバーは 3240）
• バッチ2：セクション6〜9の22本（dev サーバーは 3250）

どちらのセッションも、コンテキストが埋まると引き継ぎプロンプトを Downloads のテキストファイルへ書き出させ、次のセッションをそこから始めた。 バッチ1は 24/24 本を作り終え、台本のファイルは34本になっていた。 バッチ2の22本も、台本と画面と数字までそろっていた。

バッチ1の worktree では、待機中に dev サーバー（3240）が止まった。 Claude Code がメモリ不足を検知して止めたもので、作業中も空きメモリは 1〜2GB まで減っていた。 メモリがまだ足りないかもしれないので、その場では起動し直していない。

音声合成を Mac に任せる

音声の窓口は、別のセッションに分けた。 Mac で10本の声を合成して R2 に上げてもらい、Windows のプレビューで鳴ることを確かめさせた。 Mac から受け取っているのは動画ファイルではなく、ナレーションの音声（R2 の wav）である。 プレビュー画面が、その音声に合わせて画と字幕を動かす。

ここで、ほかにできている台本も全部 Mac に合成してもらうよう頼んだ。 このときはバッチ2を外し、バッチ1の24本（セクション1〜5）だけを渡した。

最初につまずいたのは、台本の受け渡しだった。 バッチ1の台本は、Windows の手元にしかない。 そこでブランチ beppyo-video と beppyo-video-2 を GitHub に push させ、Mac は main の作業ツリーに触れずに、別の作業フォルダで台本を取り出す形にした。 main には何も入れていない。

連絡の経路にも癖があった。 この時点では、Mac から Windows のセッションへメッセージが自動では届かなかった。 10本の作業が終わったときは、Windows 側から SSH で Mac の画面を読み、内容を受け取っていた。

バッチ1は、1本目の s1-01 がグリッド検査を通ったあと、残りの23本を順番に合成していった。 R2 へのアップロードについては、私が Mac の claude2 に「終わったらR2に上げてOK」と直接返事をしておいた。

しばらくして、セッション間メッセージで「バッチ1の24本の合成と R2 へのアップロードが終わった」と届いた。 バッチ2の音声はどうなっていたか、一瞬わからなくなった。 そっか、バッチ1だけ先にやったのか、と思い出し、セクション6〜9の22本も頼んでもらった。 バッチ2も終わったと報告が来たので、Windows 側でも22本とも音声が R2 から読み込めることを確かめさせた。 計画書とバッチ2の進捗メモも更新させ、e24816bb として push した。

s4-02 の取り直しで、承認が行き違った

s4-02 は、書籍と突き合わせて台本を直したため、合成し直しになった。

Windows から Mac へ依頼を送ろうとすると、LAN ブリッジが 102 と 104 のどちらでも応答しなかった。 いまの IP を探させ、Mac の tmux セッション claude2 が入力待ちなのを確かめてから、依頼を送らせた。

Mac では5文を新しく作り、残りの29文は前の音声を使い回した。 直したのは2文だが、文の番号がずれたぶんも作り直しになった。 尺は 3:02 である。

Windows 側から「R2 に上げ直してよいか」と聞かれ、y と答えた。 ところが Mac には私が直接承認を打っていて、上げ直しはもう済んでいた。 上がっていたのは wav 9本とマニフェストで、R2 から取り直した中身は手元と 10/10 一致した。 Windows から送った同じ依頼は、Mac が入力中だったので届いていないはずだという。 Windows の 3200 でも、台本と音声が一致した状態で 3:02 を再生できた。

セクションを押したらチャプター1を選ぶ

レビューの途中で、ビューアーの操作が手間になった。 セクションを押したあと、チャプターをいちいち押し直さないといけない。 セクションを押したら、チャプター1を自動で選んでほしいと頼んだ。

3250 でセクション8を押すと、1本目の s8-01 に移り、チャプターの1が選ばれた状態になった。 バッチ1側の 3240 にも同じ修正を入れさせ、別のセクションで同じように動くのを確かめてからコミットさせた。

worktree を main へマージして片付ける

私のレビューは、まだ終わっていない。 それでもブランチを main に入れてしまい、レビューはメイン側でやることにした。

バッチ1の24本は、それより前に main へ入れていた。 beppyo-video には直前に main を取り込んでいたので、新しいコミットを作らず main を afe7456e まで早送りするだけで済んだ。 変わったのは32ファイルで、本線で作業中の別セッションの未コミット変更とは重なっていなかった。

バッチ2のマージでは、共有している5つのファイルがぶつかり、両方の内容を残す形で解けばよいらしいと聞いていた。 そのとおりに頼むと、実際にぶつかったのは4ファイルだった。 Mac 側の「バッチ1は合成済み」という記述は新しい事実なので、そこは origin 側の行を採用させた。

テストは全件で 5,744 件が通った（27件はスキップ）。 そのあいだに main へ別セッションのコミットが2つ増えていたので、それも取り込んでから main を早送りした。

片付けは、すんなりとはいかなかった。

1. worktree とブランチを消すコマンドが許可されず、止まった
2. バッチ1側に残っていた2ファイルは、dev の起動時に作り直された改行コードの差だけだったので、私が git checkout -- で捨てた
3. push を許可すると、main の push と、2本のブランチの削除（手元と origin の両方）が済んだ
4. 作業場所は git から外れたが、フォルダが消し切れずに残った
5. 私が git worktree remove を打つと、is not a working tree で失敗した。すでに git から外れていたので、このコマンドは要らなかった
6. 最後に、私が rd /s /q でフォルダを1つずつ消した

これで作業場所のフォルダは2つとも消え、main は origin と同じ状態になった。 レビューは本線の 3200 でできる。

本文と書籍、どちらが正しいか

本文は、参考書をもとに書き起こしたものである。 いったん書籍の数字を正とする前提を置き、食い違いはすべて書籍と突き合わせてもらうことにした。

バッチ2では、判断事項を決裁フォームにまとめて答えた。 判断1と2は書籍どおりに、3〜7は回答どおりに直させた。 いちばん大きかったのは 8-6（s8-05）の例の作り直しで、当期利益 200,000 から仮計 △204,200、所得金額 0 へと流れるように組み直させた。 別表の動画のテスト281件が通り、全体テストも 5,601 件が通った（27件はスキップ）。 変更した12ファイルだけを、88031ac2 としてコミットさせた。

突き合わせの結果は、次のとおりだった。

• 判断1〜3は書籍が正しく、本文を書き起こしたときに誤っていた
• 判断4は書籍の数字に抜けはなく、2020年当時の制度で書かれた例を、本文が中途半端に書き換えていた

バッチ1側でも、3件を書籍の PDF と突き合わせてもらった。 こちらは逆で、本文の数字はどれも書籍どおりだった。 たとえば 140 は、仮払経理の 133 と損金経理の均等割 7 を足した数である。 誤っていたのは動画 s4-02 のほうで、書籍に合わせて直させた（テスト709件が通過、537ca61a）。 そのあと本文も直してよいと伝え、2か所を書籍どおりに直してもらった（ffa15ef1）。

冒頭の 7-5(6) は、本文の誤りだった。 減算額の 450 を、書籍 p.182 どおりの 2,870 に直させた。

7,280 ＋ 2,200 ＋ 220 ＋ 3,170 − 2,870 ＝ 10,000

450 のままだと 12,420 になり、所得金額の 10,000 と合わなかった。 コミットのときは、Codex のレビュー側が差分を読み込めずに失敗した。 指摘の中身はなかったので、もう一度通した（80882bf2）。

再起動の前に引き継ぎを残す

この日は、Windows の再起動をかけようとするたびに、計画書と進捗メモを更新させ、次のセッションのプロンプトを Downloads のテキストファイルに書き出させた。

音声の窓口のセッションでは、続きのプロンプトが beppyo-audio-handoff-2026-10-07.txt という名前になった。 beppyo-video-handoff-2026-10-07.txt は、バッチ1のセッションが同じ朝に書いた引き継ぎなので、上書きしないよう名前を分けてくれた。 再起動後は、台本の手直しをバッチ1の引き継ぎで、Mac との連絡と音声の受け入れをこちらの引き継ぎで進める。

バッチ2のプロンプトは、決裁フォームを開くところから始められるように書き換えさせた。

試行錯誤のまとめ

学び

• 本文と書籍が食い違ったとき、誤りは本文の書き起こしにも、動画の側にもあった。書籍を正として1件ずつ突き合わせて初めて、どちらを直すかが決まった。
• Mac に直接承認を打つと、Windows 側が出す確認と行き違う。

レビューのフィードバックは、最後に確かめた時点で、バッチ1もバッチ2もまだ0件だった。