2026年9月26日の開発日記 - 再現動画のレビュー画面づくりと、メモリで落ちるdevサーバー
2026年9月26日の開発日記
朝いちばんに開いたのは、Googleドライブの通知だった。 更新した覚えがないのに、顧問先の共有ドライブに「更新」の表示が出ている。 気持ち悪いので Claude Code に調べさせたところ、誰もファイルを触っていなかった。
そこから先は、ほぼ一日じゅう Excel講座の画面再現動画に張り付いていた。 表示を直させている最中に、:3200 の dev サーバーが heap out of memory で落ちた。 犯人は、見ていたページではなかった。
今日のタイムライン
今日やったこと
1. 画面再現動画をレビューしやすくする
Google タスクに残っていた「表が全部入る動画はズームをやめてカメラを固定する」を Claude Code に渡した。 関数の活用36本でカメラを固定させ、固定した36本を検査させると、操作セルが画面外に出る場面は5,889件中0件だった。 そのうえで、数式バーの段をカメラのタイムラインに足し、その山の高さを行のへこみとそろえる（round-compare の 0:28 でどちらも 15.5）よう頼んだ。 確認済みの印とフィードバックは、ローカルだけでなく Cloudflare の D1 に保存させた。
主な成果:
- カメラ欄を左右2列に組み替えさせ、高さを 505px から 219px に縮めた
- 「完了」が付いた22本を最終版 MP4 として動画制作ページへ移させ、本番デプロイまで進めた
- xlookup でカメラ欄が出なかったのは、カメラの設定ではなく画面ごと 500 で落ちていたからだった
詳細: Excel講座の画面再現動画をレビューしやすくする：カメラ固定、数式バーの可視化、確認済みステータスのCloudflare保存
2. devサーバーのメモリ落ちとシーン分割読み込み
期日切れの「Excel基礎講座 章2」のタスクを片付けようとした朝、Claude Code が立てた :3200 の dev サーバーは、起動から約2分で heap out of memory（上限4GB）で落ちていた。 原因は、並行セッションが台本を保存するたびに、dev サーバーが読み込みと組み立てをやり直していたことだった。 計画書を Codex にレビューさせてから第一弾の対策を入れ、続く Step 2（開いたシーンの分だけ読み込む）で、初回表示時のメモリの山を3.0GBから2.0GBに下げた。
主な成果:
- 15分で終わらなかった回帰テストは、固まっていたのではなく、もともと数十分かかる重いテストだと分かった
- 章2は R2 に25件を上げて本番にデプロイし、Google Tasks も完了にした
- Codex の認証エラーは手元の設定ではなく、OpenAI 側の障害（「Codex down due to 401 backend key error」）だった
詳細: Nuxtのdevサーバーがheap out of memoryで落ちた原因：再現動画のシーン分割読み込みと終わらない回帰テスト
3. Googleドライブの「更新」通知の正体
更新した覚えがないのに通知が出るので、原因を Claude Code に調べてもらった。 判定の閾値は「変更500件」で、通知は7月17日、7月31日、9月14日、9月16日、9月25日に、別々の顧問先の共有ドライブで出ていた。 ローカルのメタデータDBのコピーを解析させると、共有ドライブAの中身は2026年3月13日以降一度も更新されておらず、削除もゴミ箱行きも0件だった。 デスクトップ版 Google ドライブが自分で数えている「変更件数」から出た通知で、誰もファイルを更新していないと見てよい、というのが Claude Code の結論である。
詳細: デスクトップ版Googleドライブで身に覚えのない「更新」通知が出る原因を調べた：共有ドライブの変更件数と500件の閾値
4. 記事化と小さな調べもの
- 貼り付けた金利の論考（米10年債利回りが2007年夏以来の水準にある、という話）を公開記事にまとめてもらった: FRBの利上げはAI投資ブームの下で逆効果なのか。「利上げがインフレを生む」説を検証する
- 前に記事にした気がした楽天リーベイツは、記事にも memo にも git 履歴にも見つからなかった
- 「macOS なら Kindle をローカルでプレーンテキストにできる」という話が本当か聞いた。答えは「本当。ただし実際はスクリーンショットを自動で撮って macOS 標準の OCR にかける方法がほとんどで、DRM を外す方法は法的にかなり危うい」。Web で最新情報は確かめていない回答なので、規約違反かどうかはまだ分からない
- 朝の /make-diary で、前日分の日記を回した
今日の試行錯誤
| # | テーマ | 試したこと | 結果 | 気づき |
|---|---|---|---|---|
| 1 | 音が出ない（07:11） | round-compare で音が出ない原因を調べさせた | play() が pause() に割り込まれていた。1行の修正で解消 | 症状は音でも、原因は再生の順序だった |
| 2 | カメラ欄の幅（08:24） | 列と行のゲージを半分にさせた | 半分では動画がまだはみ出し、左右2列に組み替えてようやく収まった | 幅を削るより、並べ方を変えるほうが効いた |
| 3 | xlookup の台本（08:24） | Enter の間隔を 0.06→0.08 にずらした | 0.04 秒しか稼げず失敗。打つ動きを 0.35→0.30 秒に縮めて解消 | 間隔ではなく、動きの長さのほうに余地があった |
| 4 | devのメモリ（07:13） | 計画書を書かせて Codex にレビューさせ、第一弾の対策を入れた | 台本を保存してもメモリがほぼ増えなくなった（42457103） | 落ちた瞬間に開いていたページより、ファイルを書き換えているものを先に見る |
| 5 | 回帰テストの遅さ（07:13） | cfws-step1 の1本だけを単独で測らせた | 変更前30.5秒、変更後32.0秒で約5%のぶれの範囲。「31.2秒→43.5秒」は2つのテストが同時に走って出た数字だった | 遅くなったように見える数字は、並走が作ることがある |
| 6 | Codex の認証（07:11） | 自分で codex login を打ち、PowerShell 経由でログインし直した。そのあと Claude Code に mise、資格情報マネージャー、codex doctor を順に疑わせた | どれも原因ではなく、OpenAI 側の障害だった | 手元を疑う前に、公式の稼働状況ページを見る |
| 7 | ドライブの通知（06:42） | ドライブのログとメタデータDBのコピーを解析させ、途中で解析スクリプトを直して再実行した | 中身の更新は3月13日以降なし、削除もゴミ箱行きも0件 | 通知とファイルの更新は別物だった |
今日の学び
- 「計算で全本確かめた」と「画面で見た」は別物だった。基本的に問題ないかと聞いたとき、Claude Code は1本しか画面で見ていないことを理由に言い切らなかった。そのあと、5,889件の検査で0件を確かめた。
- dev サーバーが落ちた原因は、見ていた章2のページではなく、並行セッションの台本保存だった。
- Googleドライブの通知がなぜ毎回ドライブの起動直後に出るのかは、まだ確かめていない。
明日やること
- 画面再現のカメラの倍率上限（maxScale 1.6）をどうするか決める
- 関数の活用 段⑥の残り（19本のプレビュー確認）を進める