Excel講座の画面再現動画をレビューしやすくする:カメラ固定、数式バーの可視化、確認済みステータスのCloudflare保存
Excel講座の画面再現動画をレビューしやすくする:カメラ固定、数式バーの可視化、確認済みステータスのCloudflare保存
朝、Claude Code に Google タスクを見てもらうと、前日に登録した1行が今日の期日で残っていた。 「表が全部入る動画はズームをやめてカメラを固定する」。 Excel 講座の関数の章では、語りに合わせて Excel の画面が動く再現動画を作っている。 表がまるごと画面に収まる動画では、ズームをやめようという趣旨である。
このタスクを渡したのをきっかけに、この日はそのまま /dev/excel-scene のレビュー画面を触り続けることになった。 カメラを止めた画面を見るたびに、次の注文が一つずつ出てきた。
表が全部入る動画はカメラを止める
Claude Code には、シートの設定に「このシートはカメラを固定する」という指定を足してもらった。
手で直した値(overrides.json)があれば、そちらを優先する。
関数の活用37本のうち35本(52シート)が、この指定で固定になった。
ところが、確かめに開いた round-compare では音が出なかった。
調べてもらうと、画面に The play() request was interrupted by a call to pause(). というエラーが残っていた。
再生を始める途中の処理に、止める処理が割り込んでいたのである。
excel-scene.vue の1行を直し、読み込み中の割り込みで出るエラーは無視して再生を続けるようにしてもらった。
再生ボタンを押してもらうと、4秒で 0:00 から 0:07.8 まで進んだ(2倍速で、音声を時計にして進む作り)。
match-multi を見た自分は「これぐらいだったら大丈夫」と伝え、今回の修正で基本的には問題ないのかと聞いた。
Claude Code の返事は「まだ言い切れません」だった。
カメラが固定されたことは計算で全本確かめたが、画面を目で見たのは round-compare の1本だけだったからだ。
結局、自分の指摘で match-multi も固定に加え、固定した36本すべてに検査スクリプトを回してもらった。
操作しているセルが画面の外に出る場面は、5,889件を確かめて0件だった。
行のへこみと数式バーの山をそろえる
固定した画面を見ていて、カメラのタイムラインで行の段が下にへこむところに目が留まった。 関数を入力するセルがあると数式バーが開き、その分だけ見える行が減っている。 それなら、カメラ欄に数式バーの状態も並べてもらえば、へこみの理由がパラメーターを見ただけで分かる。
Claude Code に、タイムラインへ「数式バー」の段を足してもらった。 行の段がへこむ時刻に、数式バーの段が緑の山になって並ぶ。 一度は新しい段が画面に出なかった。 dev サーバーが再起動した影響でタブの自動更新が途切れていただけで、読み込み直すと表示された。
並んだ画面を見て、もう一つ欲が出た。
行のへこみと数式バーの山の高さを、そろえられないだろうか。
実装が複雑になるなら今のままでもよい、と前置きして聞いた。
返事は「難しくありません」だった。
山の高さを「数式バーに押し出されて見えなくなった行の数」にし、行の段と同じ縮尺で描けばよい。
round-compare の 0:28 で、山の高さとへこみの深さはどちらも 15.5 で一致した。
数式バーが2行、3行に広がる動画では、それだけ深いへこみと高い山になる。
この2つの変更は 6614e23f と fd42722b でコミットした。
Codex のコミットレビューは、OpenAI 側の障害(稼働状況ページに「Codex down due to 401 backend key error」と出ていた)で動かず、どちらもレビューなしで入っている。
確認済みの印を Cloudflare に残す
1本ずつ見ていくうちに、どこまで確認したかを画面に残したくなった。 自分の注文は4つある。 確認して OK なら「完了」の状態を付けられること、それをローカルだけでなく Cloudflare に保存すること、タイムスタンプを付けること、画面の下にフィードバック欄を置くことだ。 フィードバック欄の中身は、動画制作ページで使っているものとほぼ同じでよい。
Claude Code には、Cloudflare の D1 に表と API を作らせ、既存のフィードバック部品を URL を渡して使い回せる形に直してもらった。 記録がクラウド側にあるので、Windows と Mac のどちらから開いても同じ状態が見える。 完了を付け、試しのフィードバックを保存し、両方を取り消すところまで、画面で通してもらった。
画面を見て2点を指摘し、完了ボタンは再生ボタンの行の上へ移った。
幅 3440px の広い画面で横並びの配置になることも、確かめてもらっている。
このときサーバーは「完了にする」、ブラウザは「読み込み中…」と描いていたため、ハイドレーションの警告が出た。
この2か所は <ClientOnly> で包んでもらった。
レビュー画面を1画面に収める
次に引っかかったのは、カメラ欄の大きさである。 列(B から L)と行(1 から 11)のゲージが領域を取りすぎて、自分の PC の画面では肝心の動画がはみ出す。 1行の高さの最大値を今の半分ぐらいにしてほしい、と頼んだ。
半分にしてもらったが、それだけでは動画の下のほうがまだはみ出した(916eeb3c)。
もう一度画面を見せて、カメラ欄を左右2列に組み替えてもらった。
左にグラフ、右に操作欄と縦に並べたボタンを置き、倍率、列、行の段はさらに半分にした。
カメラ欄の高さは 505px から 219px になった。
自分の画面と同じ 1515×1100 で、動画が字幕の下端まで収まる。
段を低くしたせいで目盛りの文字がぶつかったので、各段の最初と最後のラベルだけを出す形に変えてもらった。
そのあとも細かい注文が続いた。 カメラ欄の右に出ていた時刻と台本の1文は、動画の字幕で見えているので消してもらった。 「自動/手直し」の区別だけは残した。 そのカメラを手で直したかどうかは字幕からは分からないためで、印は倍率の行の頭へ移った。 入力欄とボタンのあいだの空きも、右の列を中身の幅にして 14px まで詰めてもらった。
xlookup にカメラ欄が出なかった理由
xlookup を開くと、カメラ欄がない。
理由を聞くと、カメラの設定ではなく、画面そのものが 500 エラーで表示できていなかった。
台本の中で、打つ動きが終わる前に Enter が押されていたのである(打ち終わりは 34.54 秒、Enter は 34.49 秒)。
エラーでも画面は表示しておいてほしい、と伝えた。
まず、途中で失敗しても再生を続ける処理を足してもらった。
全57シーンを調べると、この問題を抱えていたのは xlookup だけだった。
途中、Claude Code は「別セッションに直しをお願いした」と報告していた。 ところが当の別セッションから「こちらの担当ではない」と返事が来て、その報告は誤りだったと訂正が入った。 台本の直しは誰も引き受けていなかったので、こちらで直してよいかと聞かれ、お願いした。
台本の直しは、一度ではうまくいかなかった。 最初は Enter の間隔を 0.06 から 0.08 へずらしたが、文が見積もりより短く、0.04 秒しか稼げなかった。 代わりに打つ動きを 0.35 秒から 0.30 秒に縮め、Enter の前に打ち終わるようにした。 これで警告の帯が消えた。
保存すると Bad Gateway、そして B 列から始まる画
カメラの値を直して保存すると、「Bad Gateway」が出た。 画面を見せて、カメラが B 列から映っていることもあわせて伝えた。
調べてもらうと、保存自体は通っていた。 失敗していたのは、保存のあとの読み込み直しだけである。 ページからシーン API への要求に再試行を足し、テストも書いてもらった。 再試行を外すと 502 で落ち、入れると通ることまで確かめている。 コミット時の Codex レビューからは、Linux で使えないオプション、秒単位の粗いサンプリング、NaN のすり抜けの3件を指摘された。 サンプリングは0.25秒おきに細かくし、NaN のすり抜けも直した。
関数の活用36本は、A 列から映るようになった。 CF精算表の動画には、まだ B 列から映るところが残った。 自分は、会計ソフトAの取り込み用シートを除く全シートで、左端の A 列と上端の1行目を余白として持たせ、A1 から映すように指示した。
CF精算表20本の画面の中身をハッシュで記録し直す作業は、2回に分けてもらった。
1回目は今回の規則を外して計算し、これまでの記録と全本一致することを確かめた。
画が変わった理由は、この規則だけだと言える。
いったんは Codex のレビューにコミットを止められた(Codex の判定も Claude Code の判定も high)。
自動カメラが「すでに画面にあるか」を判定する範囲が、実際に映す範囲(余白を含む)とずれていた。
直したあとの計算では、20本のうち5本の画が変わった。
4b3d174c のレビューは指摘なしで通っている。
確認済みの22本を動画制作へ移す
昼前、if-keep-simple に書いたフィードバックを読んでもらいながら、そもそもこの画面再現を何のために作っていたのかを聞き直した。
販売用の動画講座の MP4 で、Web 記事の本文を映していた画面を、語りに合わせて動く Excel に替えるためである。
それなら、確認が済んだものから動画制作ページへ移していけばよい。
「完了」が付いていた22本を、最終版の MP4 に書き出してもらった。 1本40秒ほどで、失敗は0本だった。 書き出しを待つあいだに、動画制作ページにも注文を出した。
- 動画を差し替えたら、前の版に書いたフィードバックは「前の版」の印を付けて閉じる
- 速度は1倍、1.5倍、1.75倍、2倍のボタンを並べて切り替える(ボタンを展開してクリックを減らすため)
- 再生が終わったら次の動画へ自動で進む。前後へ移るボタンも付け、再生中なら移った先でも再生を続ける
- マウスを乗せると秒数が出る表示をやめ、画面再現ページと同じシークバーで移動する。音量も要らない
目次は「セクション|チャプター|区間」の3列に組み替えてもらい、閉じると 306px まで縮む。 動画制作の一覧は、200件中161件が再生でき、押せないのは MP4 がまだ無い39件だけになった。
最後に、画面再現ページの目次も同じ3列にし、区間の列も閉じられるようにしてほしいと頼んだ。 見出しの高さもそろえる。 チャプターの見出しだけが 43px に縮んでいたので、縮まないよう固定してもらった。 そのうえでコミット、R2 へのアップロード、本番デプロイまで指示した。 R2 に足りなかったのは新しい MP4 の22本だけだった。 デプロイ後は本番でも再現動画が再生できることを確かめてもらった。
並行セッションとの行き来
この日は、同じリポジトリで別の Claude Code セッション(eurekapu-nuxt4-0c)も動いていた。
朝、向こうの計測で、再現動画のデータを保存するたびに dev サーバーのメモリが一時的に1〜3GB増えると分かった。
シーンの API が再現動画のデータ全体(7.8MB)を読み込んでいるためで、既定の上限4GBのままだと何度か保存すると落ちる。
今朝 dev サーバーが落ちた原因はこれだった。
向こうとのあいだでは、ほかにも次のことが起きた。
- 向こうの本番デプロイのあいだ、dev サーバーが約7分止まった(本番ビルドが dev と同じ
.nuxtを使うため) - 向こうが直したい
scripts/excel-scene-dev-server.tsにこちらの未コミット分が入っていたので、先にこちらをコミットしてほしいと頼まれた - 10:37ごろ、向こうが検証中にプロセスを取り違え、こちらのシーン API を約1分止めた。そのあと向こうは、自分の了承を得て、3秒おきに API をのぞき、3回続けて応答がなければ起動し直す見張りを足した
- 再現動画のテストが15分以上終わらないと言われ、こちらの変更が原因かを調べた。カメラのテストは単独で6秒、7件とも通った。向こうの測り直しでも、CF精算表 Step 1 の11160コマが変更前 30.5 秒、いま 32.0 秒で、ぶれの範囲だった
学び
- 「計算で全本確かめた」と「画面で見た」は別物だった。基本的に問題ないかと聞いたとき、Claude Code は1本しか画面で見ていないことを理由に言い切らなかった。そのあと5,889件の検査を回して、画面の外に出る場面が0件だと確かめた
- 「カメラ欄がない」という症状だけを見ると、カメラの設定を疑いたくなる。
xlookupは画面ごと 500 で落ちていた
残っていること
午前中、動画の倍率が 1.60 から上がらない理由を聞いた。 G 列まで寄せたかったのに、それ以上拡大できなかったのである。 シートごとに倍率の上限(maxScale)が決めてあり、この「作業」シートは上限が 1.6 だった。 この上限をどうするかは、この日のうちには決めていない。