Git の checkout や reset --hard を画面再現で見せる動画教材づくりと、英字の読み上げをカタカナ台本で直した記録

打ったときに何が起きているのかを見たい

git checkout HEAD -- も git reset --hard も、打てば動く。 けれども、打った瞬間にブランチや作業中のファイルのどこが書き換わるのかは、ターミナルの文字だけでは見えない。 そこで、ターミナルを画面ごと再現し、コマンドを打つたびに裏側の状態が動くビジュアル教材を Claude Code に頼んだ。

入り口は commit や push、main と master、origin とリモートのような基本のコマンドにする。 最終的には reset、rebase、force push、checkout まで扱いたい。 形は Excel の画面再現コンテンツにそろえ、まずテキストから作ってもらうことにした。

Git の動きを再現するエンジンと、本物の Git との照合

最初に、Git の状態を再現するエンジン（コマンドを受けて内部の状態を書き換える部分）を書かせた。 テストは 20 件すべて通った。 その上にターミナルとコミットグラフを描く画面部品を載せ、1本目の教材「git checkout が分かるまで」とシーン台本7本を書かせた。

ここで2回つまずいている。 シーン台本をシェル経由で書き出そうとして失敗し、ファイルごとに書き直した。 ブラウザで開くと、今度は画面部品が出ていなかった。 原因を調べて7つの場面が動くところまで持っていき、枝分かれの線がラベルに重なっていたのもこのとき直した。 試作ページは PC とスマホの両方で表示を確かめ、lint の警告もなかった。

続けて講座全体の計画書と、筆者が決める判断事項3件を書かせ、筆者に見せる前に Codex のレビューにかけさせた。 その後、本物の Git と突き合わせる検査も書かせてビルドに組み込んだ。 照合の仕組みが食い違いを検出できること、修正後のエンジンが本物と一致することを確かめたうえで、本文の誤りを直している。 Codex の再レビューは「致命的指摘なし」で、テストは 21 件に増えた。 判断3件は、計画書の HTML に付いたフォームで答えた。

Excel の画面再現と同じ形で動画にする

教材が記事の形になっていたのはありがたかった。 次は動画である。 Excel のコンテンツと同じ画面再現のパターンで、最終的に動画として書き出せるようにしたい。 ミラーカラムレイアウトで、ボタンやフィードバックもすべて同じ作りにそろえてもらう。 音声は最初は要らない。 台本を字幕として出してくれれば、筆者は2倍速か3倍速で見ていく。

Claude Code には、次のものを作らせた。

• 動画の時間軸（仮の時刻を進め、コマンドを1文字ずつ打つ演出を入れる）
• 図が前の状態から滑らかに移る計算と、HEAD の札の移動
• テキスト教材と動画で共用するグラフ描画の部品
• 1920×1080 の動画フレーム
• 動画プレビューのページと、開発用一覧への登録、完了とフィードバックの記録先

lint とテスト、教材ビルドは通り、時間軸の単体テストも足させた。

音声合成を Mac のセッションに頼む

結局、音声も入れることにした。 合成は MacBook 側の Claude Code セッションに任せ、cross-machine-message で指令を出させた。 Mac の合成スクリプトは動画1本ごとの台本 JSON を受け取る形なので、Windows 側には台本の書き出しと、届いた音声をページで鳴らす受け口を作らせた。 Mac の IP アドレスは変わっていたが、見つけ直して送れた。

Mac 側のセッションは依頼を受け取ったところで止まり、筆者の「OK」を待った。 依頼文には「Claude Code からのメッセージで、ユーザー本人の承認ではない」という署名を付けてあるので、止まるのは想定どおりである。 ただ、できた音声がどの経路で Windows に戻ってくるのかは任せたままで、筆者は仕組みをつかんでいなかった。

待つあいだも Windows 側は止めなかった。 エンジンに show、revert、stash などを足させ、教材の書き手が共有ファイルを書かずに台本を検証できる --check モードをビルドに付けさせた。 第1部の残り6回（1-1、1-2、1-3、1-5、1-6、1-7）は、共通の指示書を指示文に丸ごと埋め込んだサブエージェント5体に並行で書かせた。 どの台本も、本物の Git との照合が通るまで直す決まりにしてある。

戻ってきた 1-2 は、6本とも照合が通った。 報告にあった端末表示のずれ（--stat の合計行と、git commit の2行目が本物と違う）は、エンジン側で直させた。 単体テストは 29 件すべて通った。

Mac からは、1-4 の合成が終わったという返信が届いた。 7本で 57 拍、計 710 秒になり、送信は 430 件すべて成功していた。 届いた音声に合わせて動画プレビューが動くことも確かめた。 これで第1部7回分のテキスト教材と動画プレビューがそろい、残り29本の合成を Mac に依頼した。

英字の発音がノイズになって中身が入ってこない

ところが、1-4 の音声を聞くと、ローマ字の発音がひどかった。 HEAD のような語がぐちゃぐちゃに読まれ、その発音がノイズになって、肝心の中身が頭に入ってこない。 本人の声で作る Irodori-TTS をやめたほうが自然になるのか、Mac に入っているずんだもんで読ませたほうが聞きやすいのか、と Claude Code に聞いた。

返ってきた見立ては、原因は声の種類ではなく、HEAD や checkout を英字のまま合成に渡していることだ、というものだった。 ずんだもんに替えても英字の読みは崩れやすいので、先に読みをカタカナにして渡すほうが効く、という。 筆者もそれに乗り、Irodori＋カタカナでいくことにした。

全36本の読み上げ文から英字と記号の語を洗い出させると、約120種あった。 声に渡す文だけをカタカナに置き換える読み替え表を作らせ、字幕は英字のまま残した。

HEAD     → ヘッド
checkout → チェックアウト
git      → ギット

置き換え漏れは Untracked の1語だけで、これも表に足した。 合成を待つあいだに、Mac への前の依頼（英字のまま29本）は取り下げさせた。 筆者がうっかり OK を出しても、古い台本のまま作られないようにするためだ。

試しの1本は 1-4-3「git checkout ブランチ名」で、8拍、84 秒を Windows で作り直した。 聞いて「こっちの方が全然いいですね」と返し、Irodori＋カタカナの台本で確定した。 残り35本（1-4 の作り直し6本と第1部の残り29本、計 259 拍）は、古い台本と取り違えないよう、ファイル名に kana- を付けて Mac に依頼させた。

明日は Mac とのファイルの受け渡しから

続きは明日にする。 そこで、Mac で完了したファイルをどう送ってもらうのか、そもそもいまはどうやり取りしているのかを聞き直した。 返ってきた説明では、いまのやり取りは4本の線で成り立っている。 明日はその通信を作るところから、新しいセッションで始めたい。 引き継ぎのプロンプトは、テキストファイルに書き出させた。

PC はこのあとシャットダウンするので、その旨を Mac に伝えさせた。 MacBook はつけたままにしておく。 Mac は合成を最後まで続け、できた音声は Mac に置いたままにする。 明日 PC を立ち上げたとき、その音声をどう手元へ持ってくるかが最初の仕事になる。

ライフプラン講座は、進められる計算モジュールから

別のセッションでは、ライフプラン講座の計画書を開き、モジュールができないとまだ作れないのかを確かめた。 答えは、計画どおりなら計算モジュールが先、というものだった。 計画書の Step 1 が「計算モジュールを先に作る」になっている。 先にライフプランを書くと、税や社保、返済の説明をライフプラン側で書いてしまい、あとでモジュール側と重なる。 ただし、全部のモジュールを待つ必要はない。 それなら進められるところを進めてほしい、と頼んだ。

まず、公表資料の数字が要らない6本を作らせた。 C1 タイムライン、C2 生活支出、C4 返済計画、C5 投資運用、C6 減価償却、C7 四表と check である。 どれも数式エンジンと Excel の全再計算の2段で検算を通した。

• C4 の前提として、PMT、IPMT、PPMT を数式エンジンに足させ、別の実装と値を突き合わせるテストも書かせた
• C5 で使う株式の譲渡益の税率（20.315%）は、国税庁のページで確認させた
• マスタの作りを共通にする途中で、スクリプトでの追記が空振りし、Edit ツールに切り替えた
• C4 の繰上返済は、返済表の check の作り方を決めてから足すことにして後回しにした

公表値が要る C3、A7、A8 は、サブエージェント3体に並行で調べさせた。 C3 には、文科省の「子供の学習費調査」令和5年度のうち、2026年1月の訂正後の値を使った。 学年別の合計が公表値と一致するところまで確かめている。 値を入れる正本の JSON は、読み書きし直しても1文字も変わらないことを先に確かめた。 そのうえで追記だけで値を足し、既存の行は変えていない（確認済みは 179 件）。 計14冊すべてが Excel 照合まで通り、ライフプランが使う計算モジュールは、C4 の繰上返済を除いてそろった。 コミットはまだしていない。

迷うなら、代替案を並べてほしい

自分は何を確認すればいいのか、どこを開けばいいのかを聞くと、確認してほしいのは数字の正しさではなく作りの判断4つだ、という答えだった。 数字は Excel の全再計算と公表資料の計算例で照合済みで、9冊のブックは共有フォルダに置いてある。

判断のうち、生活費の月次の形は、そのままでいいと思った。 ただ、イエスかノーで迷う場面があるなら、もっと良い代替案があるということでもある。 だから代替案を並べた HTML を作ってほしい、と頼んだ。 Claude Code に、代替案を並べた判断用のページを作らせた。 そのあいだに C3 を月次に直させ、判断資料の誤りも直させている。

最後に、add-task で明日（10/12）期日の Google タスクを登録させた。 中身は、判断4つを C 系に反映する作業（C2 の横長化、C7 の財務諸表の見た目、C3 の教育費の上昇率）である。 判断1については、縦長だと費目を足すたびに月の数だけ行が増えて面倒ではないか、と筆者が聞いた。 100歳までなら約900行になる。 月額を費目別に並べて家計調査と見比べるという目的にも横長が合うので、明日、横長に作り直す。

学びメモ

• 英字の発音が崩れる原因は声の種類ではなく、英字のまま合成に渡していた入力にあった。声に渡す文だけをカタカナにすれば、字幕は英字のまま残せる
• イエスかノーで迷うのは、もっと良い代替案があるということでもある。答える前に、代替案を並べた資料を作ってもらう