Excel講座の動画シーンをセクション別フィードバックで直す

動画講座のシーン画面（dev の /dev/excel-scene）には、区間ごとにフィードバックを書き込める欄がある。 この日は朝から、セクションを一つずつ選んでは、返したフィードバックをもとに直す計画を作るよう Claude Code に頼んだ。 対象は、ファイルとフォルダの命名ルール、基本機能を覚える、Excelの設計の原則（readable-sheets）の3セクションである。

流れはどのセクションも同じだった。 修正計画書を別に作らせて本計画と相互リンクでつなぎ、Codex のレビューを通してから、判断フォームで方針を選ぶ。 そのあと台本を直させ、本人の声で合成し、静止画で確かめる。

ところが基本機能の途中で、チェック欄の数字に引っかかった。 値が入っていないはずの列で、借方と貸方に差が出ている。

命名ルールのセクション：5件のフィードバックと7区間

最初は命名ルールのセクションだった。 返していたフィードバックは5件で、計画書の判断4件には ①A、②A、③A、④C と答えた。

Claude Code には7区間の台本を直させた。 発行と受取の区間では、実機の検索窓を撮らせて並びを確かめた。 「請求書」の部分一致で6件とも出て、並びは更新日時の新しい順だった。 前回の記録とは違っていたので、台本のほうを実機に合わせた。

静止画を見ていくと、拍3で付けた名前の注記が、検索結果の画面まで残っている区間があった。 字幕が2行に折り返す箇所もあり、そこは文を2つに分けて、その区間だけ合成し直させた。

全部見終えて「非常に良いと思います」と返し、計画書を閉じた。 10区間すべてに完了の記録が付いていることも確かめさせた。

コミットでは一度つまずいた。 一時インデックスを作った直後に別のセッションがコミットしたため、最初のコミット（4ed5fa96）は、そのセッションの変更10ファイルを打ち消す形になっていた。 push 前だったので、相手のコミットを土台に作り直させた。 最終的なコミットは 4672be4f で、自分の15ファイルだけ、1733行追加と194行削除である。

基本機能のセクション：ワークツリーで他の作業と分ける

次の基本機能では、取りかかる前に迷った。 ほかのセッションも、同じリポジトリに次々と修正を入れている。 ワークツリーを作れば被らずに済みそうだが、作るとメインブランチが切り替わってしまうのではないか。 細かいところが分かっていないまま、Claude Code に聞いた。

答えは、前例（eurekapu-nuxt4-excel-filter）があるので作れる、というものだった。 ブランチ basic-feedback で eurekapu-nuxt4-basic-feedback というワークツリーを作らせ、確認用の dev サーバーを 3220 番で立てた。 main 側の 3200 番は、その間もふだんどおり動いていた。

フィードバックが付いていたのは6区間で、うち1区間は閉じるだけで済み、5区間を作り直させた。 台本を直すたびに、実物の Excel で検算させている。 数字は区間によって「27/27」「14/14」「88/88」のように出て、どれも一致した。

途中で二つ失敗している。 一つは、Claude Code に計画書へ perl で追記させたとき、-CSD を付けて use utf8 を付けていなかったことである。 §7-3 の6行が文字化けし、コミット時に Codex のゲートで止められた。 もう一つは、main へ載せ直す前に、生成スクリプトが改行コードだけを変えた2ファイルを Claude Code が git checkout -- で戻そうとして、許可されなかったことだ。 そこで --autostash（rebase の前に変更を一時退避して、終わったら戻す）に切り替えさせた。

main へ取り込んだあと、Claude Code が c00-s02 のフィードバックを閉じても、未対応が1回残っていた。 作業中に、自分が第2回のフィードバックを付けていたためである。 「日付と得意先は黒、青は数字だけ」という指摘で、これもワークツリーで直させた。

空の列のチェック欄に、なぜ差が出るのか

c04-s01 の画面を見ていて、引っかかった。 修正が入る前なのに、チェックの借方と貸方で差が出ている。 値が入っていないのだから、0 になるはずではないか。

Claude Code の返事は、列によって扱いが違うというものだった。 E列（まだ空の列）は、指摘どおりおかしい。 空の列なのに、チェックが ▲64,000 と出ていた。 実物の Excel なら、チェックの式は C列の式と一緒にコピーして初めて入るので、空の列のチェック欄も空のはずだという。 一方の D列は、意図した動きだと説明された。

そこで E列はコピーするまで空にさせ、D列はコピーした瞬間にチェックの式が入る形にした。 このとき回帰テストも、対象の区間を選んで流せる形に作り直してもらった。 1区間だけなら約1分で終わる（全部だと30分以上かかっていた）。

これを OK としてデプロイを頼んだが、画面を見直すと、D列の差がまだ気になった。 このチェックは仕訳の貸借を見ているだけのはずだ。 それなら 0 ではないか。

もう一度聞くと、Claude Code はチェックの中身を説明した。 今のチェックが比べているのは、その列の借方と貸方の合計が、2行目の見出しにあるシート（修正2）の借方と貸方の合計と合うかどうかだった。 D列には修正1の仕訳がそのまま入っているので、貸借は合っていても差が出る。 「check 借方／貸方」という名前では仕訳の貸借チェックに見えるのが自然だ、とも認めた。

ここで、ずれの正体が見えた。 自分は、修正仕訳の貸借が合っているかを見ているつもりだった。 画面のチェックが見ていたのは、2行目の見出しのシートとの一致のほうだった。 修正仕訳だけを検証するのか、修正1と精算表で集計した内容が合っているかを見るのか。 チェックの方向性が、最初から2つあったわけだ。

それなら表現を変えて、チェックを分ければいいと伝えた。 Claude Code に、見るものごとに2行へ分けさせた。

• check 貸借一致：その列の修正仕訳の借方と貸方が合っているか（=SUM(C$3:C$9) がゼロ）。コピー直後の D列もゼロになる
• check 修正シートと一致：修正シートで集計した合計と合っているか

2行目のラベルは B列に収まらず切れていたので、B列を広げて撮り直させた。 合成し直し（198秒、グリッド検査 OK）、Excel の検算 27/27 を確かめて main に入れた（a4e65f86）。

デプロイは 10:05 に終わった（163秒）。 c02-s00 の解答ファイルだけ CDN が古いものを返していたので、その1件のキャッシュ削除を承認して消させた。

設計の原則のセクション：完了の印が付いていない

3つ目の設計の原則でも、同じくワークツリー（ブランチ readable-feedback、dev サーバーは 3221 番）を作らせた。 台本の書き換えは3つのエージェントに分けて派遣させ、残りの3区間は Claude Code 本体に直させた。

途中で、別のセッション（財務諸表の動画）からメッセージが届いた。 音声合成を再開してよいという知らせで、やり取りの結果、そちらの合成も共有のロック（irodori）を通すことになった。 これで、2つのセッションが同時に合成することはなくなるはずだ。

エージェントの報告にあった和暦の記述も、実物の Excel で確かめさせた。 「令和8年4月3日」は日付（46115）になり、「R8.4.3」は文字のまま残る。 c09-s02 の表の例は間違っていたので、略記の形に直させた。

テストの待ち時間が長く、何分で終わるのか聞いた。 答えは、12:02 ごろ、あと6分ほどだった。

待っている間に、もう一つ気づいた。 フィードバック欄に「完了」が付いていない。 聞くと、印を付けたのはまだ2区間（c00-s01 と c01-s00）だけで、わざとそうしているという。 この2つは前から直っていたので閉じたが、残りはまだ閉じていなかった。

しばらくして「まだですか？」と聞くと、テストの実行が22分間なにも出力せずに止まっていた。 Claude Code は、ワークツリーの vitest のプロセス2つだけを PID 指定で止め、関係するテストファイルを直接流し直した。 結果は 486 件が通過した。

main に取り込んだあと（0f0fc698）、8区間の新しい音声を main 側へ写させ、3200 番で新しい版が出ていることを確かめさせてから、フィードバックを閉じさせた。 10区間、12回のフィードバックがすべて閉じ、3200 番の画面でもフィードバック欄が「完了」になった。

ワークツリーの片付け

片付けは、2回ともすんなりとは終わらなかった。

基本機能のワークツリーは、Git の登録とブランチは消えたが、フォルダの一部が残った。 自分で削除を流したところ、PowerShell のターミナルだったため、Claude Code の入力欄専用の書き方である ! が通らなかった。 PowerShell 用の1行をもらって自分で消し、フォルダが無くなったことを Claude Code に確かめさせた。

設計の原則のほうは、最初から「削除のプロンプトではなくコマンドを教えて」と頼んだ。

git worktree remove --force ../eurekapu-nuxt4-readable-feedback

これを流すと、sqlite のファイルが掴まれていて止まった。 原因は、止めたはずの 3221 番の dev サーバーの子プロセス（node、esbuild、workerd）が残っていたことだった。 Claude Code にワークツリーのプロセスだけを PID で止めさせ、3200 番はそのまま動かしておいた。 最後に、node_modules などが入ったフォルダを自分で消し、フォルダ、ワークツリーの登録、ブランチの3つとも残っていないことを確かめさせた。

学びメモ

• チェック欄に「借方／貸方」とだけ書くと、仕訳の貸借を見ているのか、別シートの集計との一致を見ているのかが読めない。自分と Claude Code の理解は、ちょうどこの2つに分かれていた。見るものごとに行を分けて名前を付けたら、コピー直後の D列も「check 貸借一致」はゼロになった
• 直したことと、フィードバックを閉じたことは、別々に確かめる必要がある。設計の原則では2区間しか閉じておらず、基本機能では閉じたあとに第2回が付いていた
• 自分で起動した dev サーバーは、止めたつもりでも子プロセスがワークツリーのファイルを掴んだまま残ることがある