Excel講座の動画図解を作り直す:命名ルールは白い板へ、マインドマップには画面再現をつなぐ
Excel講座の動画図解を作り直す:命名ルールは白い板へ、マインドマップには画面再現をつなぐ
「区切り位置指定ウィザード - 1 / 3」。 朝から続いたセッションで、Excel 講座の動画に出てくるこの題名と下のボタンを、実物の日本語版 Excel にそろえた。 その日の夕方には、別の動画で「Excel の部分をもっと大きくしてほしい」と頼んでいた。 それまでは、Excel を画面から外す作業をしていたのに、である。
区切り位置ウィザードを実物にそろえる
最初のセッションでは、命名ルール章(ファイルとフォルダの名前の付け方、10区間)を画面再現で作り直す計画書を、親の計画から切り離して書いてもらった。 Codex のレビューで「着手可能」と判定されたあと、試作の1区間(タイトル整理の原則)を先に仕上げさせると、2分14秒の動画になった。 残り8区間は、エージェント4体に2区間ずつ割り振って作らせた。
4体の報告がそろってから、9区間すべての静止画を本番の時刻で撮らせ、Claude Code に確認させた。 語りと画面が食い違う箇所は見つからなかった。 ただ、区切り位置ウィザードの下のボタンだけが実物と違っていた。 画面では「OK」と「キャンセル」で、実物は「キャンセル・戻る・次へ・完了」の4つである。 Claude Code は、これをエンジン共通のダイアログの制約として、報告事項に残す扱いにしていた。
これが引っかかった。
共通部品を実物のように変えれば済むのではないか、何が問題なのか、と聞いた。
返ってきたのは「おっしゃるとおりで、共通の部品を直せば済みます。私が慎重になりすぎていました」という答えだった。
了承して直させると、3枚とも下のボタンが「キャンセル・< 戻る(B)・次へ(N) >・完了(F)」になり、題名も実物の表記にそろった(コミット 9cbfb40d)。
そもそも Excel を開く必要があるのか
ボタンがそろったという報告を読んでから、もっと手前の疑問が出てきた。 タイトルの基本ルールを話す区間で、なぜアンダーバーとハイフンで区切ったファイル名を、Excel の区切り位置で分けているのか。 もとの教材に、そういう中身はなかったと思う。
Claude Code の答えは「元の教材にあったからではありません」だった。 計画を書いたときに、ルールを画面で見せる方法として足したものだという。 直前に実物へそろえたウィザードは、その場面にそもそも要らなかったことになる。
そこで、次の方針を伝えた。
- Excel の UI の説明は全部なくす
- 文字列がアンダーバーとハイフンのどこで区切れるかを、真っ白な背景か、スプレッドシート風の枠線くらいの画で見せる
- 内容によっては、エクスプローラーも出さない
作り直した形は、薄いマス目の白い「板」にファイル名を大きく出すものになった。
_ の所で区切れて、- の所はつながったまま残る。
札の色を要素ごとにそろえ直させてから、コミットさせた(91e8a015)。
キャメルケースだけでなくハイフンも
板を見ていて、もう一つ気になった。
キャメルケースでつなぐ話をしている場面で、ハイフンに触れていない。
アンダースコアでつなぐ形はないと思うが、ハイフンなら今回のルールでも成り立つはずである。
触れていない理由を聞くと、「意図して外したのではありません。ご指摘のとおり、ハイフンでも成り立ちます」と返ってきた。
出てきた選択肢から A を選び、ルール4の板を、アンダースコア、ハイフン、キャメルケースの3行に書き換えさせた(9828a898)。
詰め残しを確かめて push
セッションの終わりに、このセッションが何から始まって、何が残っているかを聞いた。 追加の指示を貼り、計画書から MP4 の書き出しを外させ、Windows と Excel の挙動を実機で確かめさせた。 検索「売上報告書」は、実機でも7つのうち3つだけが当たり、台本どおりだった。
最後に、10本のうち Excel を使わなくてよい区間も全部直したいと伝えた。 Excel の画面を区間ごとにどこで使っているか洗い出させてから、引き継ぎプロンプトをダウンロードフォルダーのテキストファイルに書き出させた。 push した範囲は15コミットで、このセッションの7つに加えて、NG 集を直している別セッションの8つも入っていた。
午後は7区間から Excel を外す
引き継ぎファイルを読ませると、直すのは7区間に決まった。 白い板に「表」「タグの札」「名前の組み立て」の3つの形を足した。 既存の項目の意味は変えず、新しい項目を使った台本だけが変わる作りである。
静止画を撮る段階で、一度、描画側のスクリプトがエラーを出した。
原因は、札のタグに付けたクラス名 .tag が、Excel の吹き出し用のレイアウト検査と同じ名前だったことである。
札の側を .ctag に改名させて通した。
タグ要素の列が「…」で切れる、空のセルまで光る、タグの文字が小さい、といった見た目も、静止画を見ながら1つずつ直させた。
全7区間の検査(レイアウトの検査と、登録の検査 229/229)が通ったところで、コミットさせた(4f6f332e)。
Excel が残ったのは2区間だけである。
請求書の一覧を開いて金額を直す区間と、資料を開いて中身を見る区間で、どちらもファイルを開く場面だった。
まとめ以外の区間にはフィードバックを書き込んでいたので、その中身も見てもらった。 画面再現のフィードバックは4区間分あり、直し方の方針が返ってきた。 一旦それでやってみるよう伝えたが、この日はここで切り上げることにした。 翌日(10月3日)の Google タスクに、メモ欄を読めば分かる形で登録させた。 タスク名は「命名ルールの画面再現:フィードバック4件を直す」で、括弧の中に4件の中身(版数を日時に、など)が入っている。
マインドマップに画面再現をぶら下げる
三つ目のセッションでは、Excel 講座のもう一つの見せ方であるマインドマップ(パターンB)の整備を、別の引き継ぎファイルから進めさせた。 画面再現(パターンA)と見比べる仕組みなど、Step 1 の6項目を実装させた。 テストは279件が通り、2件がスキップだった。
この途中で、一度遠回りをした。
新しく作ったファイルが、ディスク上にはあるのに、dev サーバーからは 404 で返ってきた。
ファイル監視のキャッシュが古くなったという見立てで、3200番の dev サーバーをポートで特定して再起動させた。
再起動しても 404 のままだった。
dev のログを見させると、原因はこちらのコードにあった。
説明コメントにそのまま書いた </script> が、SFC の script ブロックをそこで閉じていたのである。
再起動は要らなかった。
公開コンテンツを .gitignore していた理由
状態を日本語で報告させると、残っている問題の中に .gitignore の件があった。 公開用のコンテンツを、なぜ git から外しているのか。 Cloudflare に上げる前提だからなのか、と聞いた。
答えは、public/content/ が丸ごと除外されているわけではない、というものだった。
除外していたのは講座データの TypeScript から自動で作る JSON で、理由は「生成物だから git に入れない」だった。
Cloudflare に上げるためではなかった。
そこで、JSON の書き出しを prebuild、pregenerate、predev に組み込ませた。
差分は3行だった。
JSON を消してから、ビルドの前処理と同じ tsx で作り直せることも確かめさせた。
Excel の操作を語る枝の先
マインドマップの画面を見ていて、方針が一つ固まった。 論点整理なら、マインドマップの形でよい。 ただ、Excel の話をしているときは、Excel の操作を再現できているのだから、パターンA の画面再現で見せてほしい。
そこで、「参照元へジャンプ」の枝から「C8 の合計で押す」が出ているところの先に、パターンA とまったく同じ画面再現をくっつけたらどうかと提案した。 そうすれば、いまのセル操作がマインドマップのどこから出ているかが見える。
Claude Code の返事は「できます」だった。 枝の先に画面再現の画を1つのノードとしてぶら下げ、カメラをそこへ寄せる。 字幕の帯が画の下 180px を占めるので、ノードには上の 1920×900(見出しと Excel 画面)だけを切り出して入れる。 寄ったところで、C8 を選ぶ、C5〜C7 が選ばれる、F5 と Enter で戻る、という A と同じ動きが流れる。
出来上がりを見て、残りの2本(contents と donts-c15-s00)も同じ形で作るよう頼んだ。 あわせて、もっと寄るか、Excel の部分をもっと大きくしてほしいと伝えた。 メインは Excel だからである。 十個の項目を全部開いた場面は縦長になり、字が小さくなっていた。 そこで、「一つ目」の説明に入ったら上の枝へ寄る形に直させた。 寄ったときの字は、1080p の画で約70pxになった。
NG の例が推奨に見える
donts-c15-s00 を再生すると、別の食い違いが見えた。 この区間は NG の例を挙げていて、Excel では INDIRECT を使うことがその一つになっている。 ところがマインドマップの主題が「その他の注意点」で、NG という見出しがない。 これでは「INDIRECT を使うようにしましょう」と読めてしまう。
主題を「やってはいけないこと」に変えさせ、2行目を「その他の注意点・あとで効いてくる十個」にした。 各項目の2行目「代わりに:…」はそのまま残したので、「10 INDIRECTを使う」は「やってはいけないこと」の一つとして読める。
コミットとコードだけの Codex レビュー
「コミットプッシュ」と言いかけて、コミットだけに言い直した。
作業ツリーにはほかの作業の変更も混ざっていたので、マインドマップ関係の41ファイルだけを選んでコミットさせた(1f4c8f5f)。
そのあと、コードだけを Codex にレビューさせた。
指摘は3件で、そのうち2件(見えないノードがクリックを奪う問題と、主題の2行目の文)を直してコミットさせた(b20fb2c5)。
試行錯誤
| セッション | 試したこと | 結果 |
|---|---|---|
| 09:50 | 区切り位置ウィザードのボタンと題名を実物にそろえた | そろったが、そもそも Excel を開く場面ではないと気づき、白い板に作り直した |
| 14:02 | 札のタグにクラス名 .tag を付けた | Excel の吹き出し用の検査と衝突し、.ctag に改名して通った |
| 14:58 | 新しいファイルの 404 をキャッシュのせいと見て dev サーバーを再起動した | 404 のまま。原因はコメント中の </script> で、再起動は要らなかった |
学び
- Excel を画面に出すかどうかは、その場面が Excel の操作を語っているかで分ける。ファイル名の区切りのような文字列の話なら白い板で足り、セル操作の話ならマインドマップの中でも画面再現を大きく見せる。命名ルールで Excel を外したのも、マインドマップで Excel を大きくしたのも、この基準から出た判断だった
- 部品を実物にそろえる前に、その部品が場面に要るかを問う。区切り位置ウィザードは、3枚分のボタンを直したあとで、場面ごと白い板に置き換わった