Excel講座の「AIの活用」章を作り直す

朝、dev 環境で Excel 画面再現の「AIの活用」の区間を開き、Claude Code に計画づくりを頼んだ。 注文は三つだった。 計画を作ること、上位の本計画と相互にリンクを張ること、その区間に付いているフィードバックを確かめること。

計画そのものは、決裁フォームの4問に答えて決まった。 手間取ったのはそのあとである。 音声合成はメモリ不足で止まった。 合成を MacBook に任せると、今度は Mac から報告が届かず、SSH もつながらなかった。 最後には、全コマを照合する回帰テストが CPU を約830秒使い続けていた。

AI活用の計画書と、相互リンク

フィードバックは、シーン用の別 API に保存されていた。 Claude Code はそこから取り直し、4区間の今の中身と、以前の修正計画の書式を読んでから計画書を書いた。 判断事項は Decisions JSON にまとめ、図も添えさせた。

Codex のレビューでは指摘が2点出た。 どちらも妥当だったので反映させ、承認をもらってから本計画との相互リンクを入れた。 ブラウザで表示を確かめると、図が本文の幅をはみ出していたので、それも直させた。

判断は4つあり、Chrome の決裁フォームで答えた。 4つとも推奨の A を選び、コメントは付けなかった。 回答は、AI活用の計画書と本計画の両方に書き込まれた。

台本を書き、実物の Excel と突き合わせた

着手の合図を出すと、Claude Code は Step 1 の事実確認をサブエージェントに任せ、その間に台本の手引きと部品を読み始めた。 作業はおおむね次の順に進んだ。

• 計算エンジンに TRIM、ASC、SUBSTITUTE を足す（使う区間にしか影響しない）
• AI の欄を表示する部品（DeskAiPane、ExcelAiFrame）を作り、ページへ差し込む
• 4区間の台本を s00 から順に書く（s01 もらったブックを読ませる、s02 データを整えさせて確かめる、s03 集計表を作らせて検算する）

事実確認の結果は台本に反映した。 「エージェントモード」という名称は使わず、Ctrl+Z で戻せるとも言い切らない。

AI の欄を出すと、表の列見出しが欄の上に透けて見えた。 重なり順（z-index）を直させ、章の表が途中で切れる問題も一緒に片づけた。 s02 では、AI がまだ作っていないはずの表の濃い見出しと灰色の行が先に見えていたので、それも直させた。

ブックは実物の Excel で4区間とも照合した。 結果は 7/7、24/24、23/23、28/28 で、台本の AI が最初に出す間違った答えまで含めて一致した。

音声合成とテストが、メモリ不足で止まった

次は、本人の声で台本を読み上げる音声合成だった。 合成を裏で回すと、GPU は100%に張りついた。 その横では、ユニットテストも走らせていた。

そこで PC のメモリが足りなくなった。 裏の処理は Claude Code が自動で止めた。 音声は1本もできず、テストの結果も出なかった。 この報告が英語で返ってきたので、日本語で返すよう頼んだ。

メモリをひどく食っている Python スクリプトも見つけて、自分の手で止めていた。 これが Claude Code の回していたものか尋ねると、このセッションの Python はもう止まっていて、まだメモリを使っている Python は別のセッションのものだという答えだった。 止めた時点では、その Python が誰のものか見分けがついていなかった。

MacBook のセッションに合成を任せる

合成は MacBook 側の Claude Code に任せることにし、指示書を送らせた。 手順は、2台の間でメッセージを送るスキルにまとめてある。

Claude Code は、合成した wav を Windows へどう戻すかを先に確かめた（音声ファイルの置き場は git の管理外である）。 4区間の台本の一覧は Dropbox に置かせた。 Mac の受信サーバーは応答し、Mac の Claude Code は同じリポジトリで待機していた。

指示書の中身は絞った。

• Mac でやるのは、Irodori-TTS で4区間の wav を作ることだけ（1区間ずつ、全部で26本）
• Mac のリポジトリには書き込まず、出力は Dropbox に出す
• git の操作と R2 へのアップロードは禁止

Mac からの報告が届かない

しばらくすると、Mac のセッションから報告を送れない現象が見つかった。 そこで、Windows 側から報告を取りに行く方法を Mac に伝えさせた。

Mac が返信すると、その返信はブリッジのサーバーに1時間保管される。 Windows からは、次のように MSG-ID を指定して取りに行ける。

send-to-mac.sh --fetch-reply <MSG-ID>

最初の報告も、この方法で回収できた。 報告が届かないときに備えて、Mac の Downloads 配下の受け渡しフォルダにも REPORT.md を書いてもらうよう頼んだ。

SSH の鍵は、すでに登録してあった

次に「Windows の SSH キーが Mac に未登録のため SSH は使えない」という説明を受けた。 鍵を Mac に登録するか、登録を依頼するかを Claude Code に相談した。

調べると、新しく登録する必要はなかった。 Windows には Mac 向けに作った鍵がすでにあり、Mac にも登録済みだった。 接続に失敗したのは、そのとき鍵を指定していなかったからだった。 -i で鍵を指定すると Mac に入れ、Mac の ~/Downloads/ も見えた。

これで、wav は Windows から scp で取りに行けるようになった。 Mac で tar にまとめたり、一時サーバーを立てたりする必要もなくなった。 Mac への訂正のメッセージは、Mac が合成待ちで手がふさがっていたため、その時点では届かなかった。 代わりに、SSH で直接見に行く見張りを裏で立てさせた。

合成済みの本数は、一度多く数え間違えていた。 数えた中に途中のファイルが混ざっていて、実際に終わっていたのは s00 だけだった。 s00 を取り込むと、プレビューの API が受け入れ、文の数も一致した。 音声付きで静止画を描かせると、字幕と画面の動きは揃っていて、レイアウト検査は120時点すべて通った。

「音声なし」と「動画が変わりました」の出どころ

途中で、画面の表示が気になった。 どこかのセッションが書き換えたらしく、音声が全部「なし」になり、「動画が変わりました」とも出ていた。 どのセッションが何をしたのか、自分では分からなかった。

Claude Code の答えは、どちらの表示もこのセッションの作業（AI活用の4区間の作り直し）が原因で、ほかの区間は正常だというものだった。 3221番のポートで動いている dev サーバーの出どころも確かめた。 これは、設計の原則のフィードバックを直している別のセッションが、別のワークツリーで10:51に起動したものだった。 そのワークツリーの .nuxt の更新時刻も10:51で、起動時刻と一致した。

まもなく Mac が4区間すべてを合成し終えた。 s01 の古い音声をよけてから s01 から s03 を取り込むと、4区間とも音声の表示が正常に戻った。 本物の音声のタイミングで静止画を描かせ、どれも問題がないことを確かめてから、Mac には止めてよいと伝えさせた。

全コマを照合する回帰テストを止めた

内容を見て、及第点だと判断した。 ここでいったん終わりにし、このセッションの分も含めて進捗を更新するよう頼んだ。 s01 のフィードバックは D1 上で閉じ、レビューの結果も記録させた。

残りはテストだった。 空きメモリは5.4GBあった（別のセッションの1.9GBの合成はまだ動いていた）ので、計算エンジンと回帰テストをまとめて裏で流させた。

ところが、なかなか終わらない。 聞くと、12:02に始めたテストが CPU を約830秒使い続けていた。 重いのは回帰テストで、既存の全区間の全コマの画面を計算し直して照合していた。

今回直したのは AI活用の4区間だけなのに、なぜ全コマを回すのか。 変更がなかったことを確かめるには毎回全部を回すしかないのなら、生成するスクリプトの側が分割されていないことが問題ではないか。 そう尋ねて、修正した部分だけに絞るよう指示した。

Claude Code はまず、import をたどって影響のある区間を選ぶ既存の仕組み（scripts/test-scene-regression.mjs --changed）を挙げた。 そのうえで重い回帰テストは止め、全コマの照合をしない軽いテストだけに切り替えた。 5ファイル448件がすべて通り、かかったのは39秒だった。 中身は、数式の計算、登録の食い違い、カメラ、空き列である。

コミットと、翌日のタスク

コミットは一度はじかれた。 レビューを回している間に、別のセッションが先にコミットしていたからである。 ステージした内容はそのまま残っていたので、やり直して 287b860f（20ファイル）で通った。

続けて、明日の引き継ぎファイルを作らせた。 Google タスクにも入れたかを確かめると、まだだった。 その場で追加させ、登録されたことも確かめた。 タイトルは「Excel画面再現の回帰テスト: 流す区間の選び方を細かくする実装計画（Codexレビューまで）」である。

学び

• Mac から報告を送れなかったときは、Windows から取りに行く形に切り替えて回収できた。報告はブリッジのサーバーから、wav は SSH と scp で取った。
• 「SSH キーが未登録」に見えた失敗は、接続時に鍵を指定していなかっただけだった。鍵を新しく作る前に、既存の鍵を -i で試す。
• 全コマを照合する回帰テストは、直した範囲が小さくても CPU を約830秒使い続けていた。影響のある区間だけを選んで流す仕組みを細かくすることを、翌日のタスクとして Google タスクに登録した。