Excel講座の動画制作：精算表の再現動画20本に列固定の切り替えを入れ、動画制作ページをMP4なしのプレビューに変えた
Excel講座の動画制作：精算表の再現動画20本に列固定の切り替えを入れ、動画制作ページをMP4なしのプレビューに変えた
5分10秒まで、語りは表の上半分にいる
朝6時すぎ、キャッシュフロー精算表の再現動画（Step 7 の3本目、cfws-step7c）を見ていて引っかかった。
5分10秒前後まで、語りはずっと精算表の上側、だいたい32行目までの話をしている。
それなのに、画面の固定は D 列（期首残高）までだった。
そこで、説明している場所に合わせて固定する列を切り替えてほしいと Claude Code に頼んだ。 上半分の話をしているあいだは増減の H 列まで固定し、キャッシュフロー計算書の話に入ったら D 列までの固定に切り替える、という案である。
Claude Code は、シートの状態を丸ごと差し替えると全セルの再計算が走るため、その時点で効いている固定設定だけを上書きする仕組みを足した。 切り替えの位置は「下半分が、キャッシュフロー計算書です。」の一文にした。
この決まりを計画書にまとめ、Codex にレビューさせた。
指摘は1件で、SUM 式を読む部分が Step 7 のブックを直接見ている、というものだった。
「いま動いているブックから読む」を必須条件として書き足し、再レビューは通った。
回帰テストで変わったのは 7c だけで、狙いどおりだった（103d6fa4）。
引き継ぎのプロンプトはターミナルに出してもらっていたが、ダウンロードフォルダにテキストファイルで置き直してもらった。
Step 7 から Step 2 へ、1ステップずつ広げる
8時36分、そのテキストファイルを渡して新しいセッションで続きを始めた。 計画書には筆者の判断待ちが4件あった。 回答を待つあいだに、判断に左右されない共通部品化から Claude Code に進めてもらった。
Step 7 の残り（7b〜7f）は、切り替え前後のカメラの動きを数値で比べてから、静止画で確かめた。 7b と 7e は、カメラの往復が大きく減った。 7d と 7f はわずかに増えたので中を見ると、7f の「下半分が〜」の文だけ左端が E 列になっていた。 空いた列が画に入るおそれがあるので、ここだけ左端を D 列に移した。
途中で3回つまずいている。
- 静止画を撮っている最中に、API の子プロセスが編集に反応して再起動した。7c 以降の時刻が取れていなかったので、復旧後に 7b〜7f を並列で撮り直した
- 確認用ページが開かなくなった。nitropack のファイルが node_modules から消えており、Claude Code は別のセッションが依存を入れ直した可能性を疑った
- カメラのテストが1件落ちた。見出しに
frozen: trueが付いた固定列を、テストの側が勘定に入れていなかった
Step 7 の記録を取り直してから、Step 6、5、4、3、2 と1ステップずつ進めた。 6b は下半分のズームが 0.65 から 0.88 に上がり、上半分は変わらなかった。 前面タブに開いてもらった 6b を見て、問題ないと判断した。 Step 4 は下半分が 0.59 から 0.70〜1.0 に、Step 2 は 0.65 から 0.88〜1.0 になった。 Step 4 を push したときには、Excel ショート動画を作っている別セッションのローカルコミット2件も一緒に出ていった。
ここで判断待ちの4件に答えた。 演習ファイルにも同じ固定を入れる案（判断4）を選び、下半分では D 列の見出しを「合計」に差し替える案（判断3）も入れてもらった。 あわせて縦線も細くしてもらった。
ダウンロード用のブックは、画面とは別の書き出しスクリプトで作っている。
そのため、画面の表示用に置いた C 列と D 列の写しが、意図せず紛れ込むことはない。
演習ファイルには写しと固定（I4、つまり H 列と3行目まで）を入れ、実物の Excel で検算した。
Step 1 から Step 6 までは、全セルが一致した。
最後に Step 7 の検算を待ってから push した（1f467424）。
本当に20本全部に入ったのか
完了の報告を受けて、聞き直した。 連結精算表ではなく、キャッシュフロー精算表のステップ学習の Step 1〜7 全部に修正が入ったのか。
答えは「20本すべてが対象で、連結には手を入れていない」だった。 ただし、実際に画面が変わったのは14本だけである。 残りの6本は、キャッシュフロー精算表のシートを一度も開かない動画で、直す場所がなかった。
計画書の進捗を更新してもらい、自分の目での確認は翌日の Google タスクに積んだ。
並行して開いた別のセッションでは、Google タスクから今日が期日の4件を確かめ、リポジトリごとにセッションを分けるかを相談した。
Claude Code は分けるほうを勧めた。
理由の一つは、ここから作業するとほかのリポジトリの CLAUDE.md やルールが読み込まれないことだった。
午後：関数の活用と、動画制作ページの MP4
区間が選ばれないまま前の画面が残る
14時20分からは、関数の活用の作業に移った。
画面再現ページでセクションかチャプターを切り替えても、区間が何も選ばれず、右側に前の区間が残っていた。
先頭の区間に必ず合わせてほしいと頼み、ブラウザで実際にクリックして直ったことを確かめてもらった（564f7d54）。
悪い式を先に見せるナレーション
iferror-ex-consolidation にフィードバックを書き足し、台本とナレーションの修正を頼んだ。
手本にしたのは、別の区間（text-comment）を初めて直したときの型で、まず間違った式を作ってから正しい式に書き換える流れである。
Ctrl+[ の読みは「Ctrlを押しながら、開き角かっこ」に揃えた。
台本の検査（1文に句点1つ、70字以内）に2文が引っかかり、分割した。
実物の Excel での検算は 120/120 で一致した。
本人の声での合成は、10クリップ、272秒になった。
その直後にプレビューが開かなくなった。
原因は nuxt.config.ts の読み込みエラー（fileURLToPath is not defined）で、別セッションが memo ビューアの設定を編集している途中だった。
import 行はすでに足されていたので、読み直すだけで直った。
書き出し時間の見積もりを止める
画面再現で OK にした区間を、動画制作ページにも移してほしいと頼んだ。 Claude Code の突き合わせでは、関数の活用は62区間ある。 画面再現の完了記録は37本すべてに付いていたが、動画制作側には24本が古い MP4 のまま移り、13本はまだ移っていなかった。
報告に MP4 の書き出しの話が出てきたところで、待ったをかけた。 動画制作ページはプレビューで、MP4 は読み込んでいないと思っていたからだ。 コードで確かめてもらうと、MP4 を読まずにその場で描いているのは画面再現ページのほうで、動画制作ページは MP4 を読み込んでいた。
修正のたびに古い MP4 を捨てて書き出し直していたら、時間が足りない。 GPU もメモリも無駄に使う。 講座に載せるには MP4 が要るが、それは最後でいい。 画面再現と同じ仕組みで、その場で描いてプレビューすれば足りるはずだ、と伝えた。
Claude Code は、画面再現ページに埋め込み用の表示（embed=1）を足し、動画制作ページでは <video> の代わりにそれを出すようにした。
最初は、埋め込み枠が表示を拒否された。
応答ヘッダーは狙いどおりで（/dev/ 配下だけ埋め込みを許し、講座ページは従来どおり DENY）、確かめ直すと表示できた。
再生が終わり近くからではなく頭から始まる不具合も出た。
Claude Code は、枠の要素も中の window も同じままなのに、中のページだけが描き直されていることを突き止めた。
最終的に、動画制作ページでも画面再現の区間は MP4 を読まずにその場で描くようになった。
MP4 は、講座へ載せる最後の段階で書き出せば足りる（53d82b1a、9a0ac8e6）。
計画書の更新では、Claude Code が一度「組5の組み込みスクリプトはまだ無い」と報告した。
確かめ直すと batch5.mjs はあったので、計画書の該当2か所を直してもらった（9fc77cf4）。
受け皿の章を作る
受け皿の章が無ければ作っておくよう頼んだ。
章の作り方は、組5の組み込みスクリプト（batch5.mjs）にあった。
章づくりとスクリプトの手直しでは、3か所で引っかかった。
エスケープが崩れた2か所は batch5.mjs の行をそのまま写して直し、罫線の文字を含む行の突き合わせに失敗したところは短い目印に置き換えた。
生成した行に改行が実際の改行として入ってしまった箇所は、Edit で直接直した。
batch5.mjs は、章がすでにあれば解答側の会話に動画だけを足し、目次の行が足してあれば飛ばすように直した（20e06cfa）。
ROUND の演習ファイル2つは R2 に上げ、中身が手元と一致することを確かめた。 ただ、CDN のキャッシュを消すトークンがこのシェルに無く、公開 URL は21時ごろまで 404 のまま残る見込みになった。
memo ビューアの画像
14時35分のセッションでは、関数の活用のチェックのタスクを完了にしようとした。
Google タスクでは、関連する3件が朝8時48分ごろにすでに完了になっていた。
memo ビューアで計画書の画像が出ない件は、Claude Code に直させた。
直した正規表現は正しく動いていたので、dev サーバーが変更を拾っているかを確かめ、画像が表示されるところまで確認してもらった。
計画書の進捗は実装と突き合わせて更新し（関数の活用の再現動画は確認36/37本、Web 公開22本）、計画書の中の相対リンク9本も開くようにした（ccc333f5）。
チェックマークは何の印か
15時すぎ、動画制作ページの目次にある緑の ✓ の意味がわからなくなった。 Claude Code の答えは「MP4 を書き出し済み」で、手元の出力フォルダに 1080p の MP4 があるかどうかを見ているだけだった。
最初は ✓ を「MP4」という文字に置き換えてもらった。 しかし、全区間が完了になるまでは、講座の配信先へ登録することも MP4 を書き出すこともない。 書き出し済みかどうかを目次に出す意味がない、と気づいた。 印を外し、目次は「完」（完了）と「フ」（フィードバックあり）の2つに絞った。
スライドを読み上げるだけの冒頭
functions-ref-ex-ratio を開くと、スライドの文章をひたすら読み上げていた。
Excel の画面で見せられる内容なのに、なぜ計画から漏れたのかを Claude Code に調べさせた。
理由は、9/24 の見直しでこの区間が優先度 B と判定されたことだった。 計画は優先度 A の区間だけを再現動画にしている。 見直しは冒頭の語りを「演習の導入としては許容範囲」として、優先度に数えていなかった。 同じ作りの区間は7本あり、どれも冒頭の12〜68秒は文章のスライドだけで、操作動画が出てこない。
7本それぞれに2案を作ってもらった。 A は既存の「問題の動画」を引き継ぐ案、B は画面再現で作り直す案である。 B の台本はサブエージェント4体に並行して書かせ、実物の Excel で全本を検算した（構成比27/27、SUMIFS 224/224 など）。 合成は、構成比が220秒、VLOOKUP の2本が174秒と238秒になった。 B の7本は、本人の声での合成と実物の Excel での検算まで済んだ。
見比べていて、構成比の A の動画に見覚えがなかった。 Claude Code が作ったのかと聞くと、上司との会話の場面に付いていた、もともとある2024年9月の動画だという。 それなら、Claude Code が作った B のほうがずっといい。 たぶん解像度も合っている。 プレビューには A を残したまま、採用は7本とも B にすると決めた。 7本の確認は、翌日の Google タスクに積んだ。
学びメモ
- 「20本すべてを対象にした」と「20本すべての画面が変わった」は別の報告である。聞き直したことで、14本が変わり、6本は直す場所がなかったという区別がはっきりした
- 動画制作ページが修正のたびに MP4 を求めていたのは、プレビューと完成品の役割が混ざっていたからだった。MP4 は講座へ載せる最後の段階だけで作り、目次の ✓ もその判断に合わせて外した
- 冒頭7区間が計画から漏れたのは、9/24 の見直しが冒頭の語りを評価に入れていなかったからだった。優先度の判定を読むときは、何を数えなかったかまで確かめたい