2026年8月19日の開発日記 - やり直しの単位を小さくした一日

daily-log

2026年8月19日の開発日記

図を1枚直しただけでも、アップロード用のスクリプトは全部を上げ直しているのではないか。 そう疑ったのが朝の9時台だった。 夕方には、生成スクリプトの残っていない図127枚を作り直させ、ビルド時間を半分に削る設定を見つけていた。

並べてみると、この日に触った問題はどれも形が似ている。 直したいのは一箇所なのに、やり直しの単位が全体になっている。 14のセッションを開いて、そのうちの何度かは、その単位を小さくする作業に費やした。

今日のタイムライン

タイムライン

区分時間セッション数
アプリ開発(eurekapu)14時間06分8
ログ管理6時間18分5
Chrome拡張27分1

今日やったこと

1. 画像のアップロードを、全件から差分へ変える

朝いちばんに前日の積み残しを一覧させ、未コミット分のコミットとデプロイから片づけた。 その途中で、本番の図がリンク切れしているのを見つけた。 前日のアップロード漏れと、エッジに残った404のキャッシュが重なっていた。

再アップロード用のスクリプトを見せてもらって、手が止まった。 図を1枚直すたびに全件を上げ直す作りなら、無料枠の中で回すには重い。 Gitの履歴から変更のあったファイル名を拾えば済む話ではないか。 そう投げたところから検討が始まり、最終的にはETagを比べて差分だけ上げる形になった。

配信側の設定はコマンドではなく、ログイン済みのブラウザから操作させた。 第三者に権利のある図は、本番から下ろすと決めた。

主な成果:

  • 本番のリンク切れの原因を、アップロード漏れとエッジキャッシュの2つに切り分け
  • 全件アップロードから、ETag比較による差分アップロードへ変更
  • 第三者に権利のある図を本番から下ろす方針を確定

詳細: Cloudflare R2の画像を差分アップロードに変え、第三者権利のある図を本番から下ろす


2. 図の直し方を、1枚ずつから規約へ移す

前日に続けて図のレビューを再開した。 1ページ前の図には入っている余白が、次の図には入っていない。 一括で直させたはずなのに、直っていない図が残っていた。

修正のログは時系列で並べてもらっていたが、それだと同じ規約が何度も顔を出す。 規約の単位で並べ直させた。 そのうえで、列見出しは白抜きと下線だけにすると決め、全図へまとめて適用させた。

株主名と持ち株数のようなテーブル型の図では、1件のレコードを列ごとに割る形へ直させた。

そして127枚。 生成スクリプトの残っていない図がそれだけあった。 ピクセル単位で座標を置いている以上、スクリプトがなければ微修正もできない。 作り直しは規模が大きいものの、スクリプトから全部作り直してもらうことにして、その作業は別のセッションへ切り出した。

消費税の図では事業区分のボックスどうしの距離を広げさせ、相続税の図では点線のつなぎ先が違っていたので直させた。 徴収法はざっと目を通して、気になる箇所がなかったのでそこで終わりにした。

主な成果:

  • 列見出しの規約を決めて全図へ一括適用(修正ログを時系列から規約単位へ並べ替え)
  • テーブル型の図で、レコードを列ごとに割る形へ修正
  • 生成スクリプトの残っていない127枚を、スクリプトからの作り直しへ回す判断
  • 本番へのアップロード漏れの有無を確認

詳細: 列見出しは白抜きと下線だけ。SVG図解の規約を番号で管理し、生成スクリプトの無い127枚を作り直した日


3. 設問200問の出どころを確かめてから記事化へ入る

設問が200問に絞られたと聞いて、まずその数の出どころを確かめた。 まだ抽出していない本が残っていないか。 返ってきたのは、2,500問規模を抽出して386問へ束ね、そこから200問という経路で、未割り当ては0だった。 それが確認できればよかった。

一覧に「系統」という列があって、何の分け方なのか読み取れなかった。 重要度の代わりに使っているのなら、出典書籍数と書いたほうが早い。 そう言い換えさせた。

重要度が高く出典書籍数の多い上位5問を、試しに記事にしてもらった。 執筆方針を読んでいて引っかかったのは、事実確認の順序だった。 執筆時は書籍本文を読まず、書いたあとに該当箇所だけ確認するとある。 それでは書いた内容に合う箇所を探しにいくことになる。 先に出典を全部読んでから書く順序へ直させた。 夕方には、2本目から5本目までを1セッションで続けて書かせた。

主な成果:

  • 設問数の経路(2,500問規模 → 386問 → 200問)と未割り当て0を確認
  • 一覧の「系統」列を出典書籍数へ差し替え
  • 執筆と事実確認の順序を入れ替え(出典を読んでから書く)
  • パイロット記事を5本まで作成

詳細: 設問200問の出自を確かめてから記事化に入った日。指標の列名を直し、執筆と事実確認の順序を入れ替えた記録


4. クリック領域を直したら、ボタンが消えた

動画のついた投稿でリポストを押すと、動画のダウンロードが走る。 ダウンロードボタンの当たり判定が広がりすぎているのだろうと当たりをつけ、クリック領域を実測させた。 原因は投稿側のクラス名の変更で、判定はボタン本体だけに限定させた。

直した直後に、今度はボタンごと画面から消えた。 同じ修正の副作用かと思ったが、そうではなかった。 拡張がエラー状態で無効化されていて、原因は拡張フォルダの直下に落ちていた __pycache__ だった。 Chromeはアンダースコアで始まるディレクトリを拡張の中に置けない。

再発防止として、リロード用の手順に注意を書き足させ、issueを1本残させた。 拡張のリポジトリに元からあった未コミット分は、内容を見て3つに分けてコミットさせた。

主な成果:

  • クリック判定をボタン本体だけに限定(原因は投稿側のクラス名変更)
  • 拡張が無効化される原因を __pycache__ と特定し、手順書とissueに記録
  • 未コミット分を内容ごとに3コミットへ分割

詳細: Chrome拡張のクリック領域が行全体に広がるバグと、__pycache__ で拡張が無効化される罠


5. ビルドは半分になったが、縮まなかった工程が残った

タスクに積んでいた「Defenderの除外を入れて2回目を測る」に着手した。 除外の設定だけを変えて pnpm generate を測り直すと、21分44秒が11分30秒になった。

ただし縮んだのは、ファイルを大量に開く工程のほうだった。 記事のプリレンダーは16%しか縮まず、Macとの差はそのまま残っている。 切り分けのために、プリレンダー用バンドルの localFetch で記事のSSRだけを単体で測るハーネスを作らせた。 Mac側の計測はまだ回していない。

夕方は、直近1か月で変更したリポジトリを全部走査させ、リモートへ未反映のものをコミットしてプッシュさせた。 その途中でGitの資格情報を飛ばした。

主な成果:

  • Defenderの除外による2回目の計測(21分44秒 → 11分30秒)と、工程別の内訳の記録
  • 記事のSSRを単体で計測するハーネスを追加
  • 直近1か月に変更したリポジトリのプッシュ漏れを解消

詳細: Windows Defenderの除外でNuxtのビルドは半分になったが、記事のプリレンダーは16%しか縮まなかった


6. 日本語は、丁寧語で終わると韻が止まる

ビート整列を検証するページを、ずんだもんの声でも作らせた。 文末の母音を2文ずつそろえた12文を読ませてみて分かったのは、日本語の制約のほうだった。 「ます」「です」で終わる限り、そろうのは語尾であって韻ではない。

英語なら音がつながるぶん楽なのではないかと思って、そちらも作らせた。 聞いてみたら何を言っているか聞き取れない。 英語版だけ削除させた。

主な成果:

  • ずんだもんの声によるビート整列の検証(母音をそろえた12文)
  • 日本語の文末表現がライムに与える制約を確認
  • 英語版は聞き取れず削除

詳細: ずんだもんの声をBPM120に乗せる。日本語ラップの制約と、削除した英語版


7. 1か月前の疑問を、公開記事に落とす

別のセッションでは、子どもが自由研究に立てた「なぜプロペラを回すと電気が起こるのか」という一行の経過を、公開記事にまとめさせた。 チャットの履歴を全部読ませ、SVGの図を足し、磁石のS極とN極がプラスとマイナスのどちらへ対応するのかを書き加えた。 同じセッションに紛れ込んでいた別件は、記事から落とさせた。 スマホの幅で図が小さく見えるのは左右の余白のせいだったので、そこも外させた。 実験道具の買い物リストも足した。

詳細: 「なぜプロペラを回すと電気が起こるのか」— 自由研究の一行が、ファラデーの日誌に届くまで


今日の試行錯誤

#テーマ試したこと結果気づき
1本番の図のリンク切れ前日のアップロード漏れを疑って本番を確認原因を特定アップロード漏れとエッジの404キャッシュが重なっていた
2画像の再アップロード全件を上げ直す作りを疑い、Gitの履歴から変更ファイルを拾う案を出す差分アップロードへ変更ETagを比べれば、履歴に頼らず変わったファイルだけ上げられる
3図の列見出し1枚ずつ指摘していたものを、規約にして全図へ一括適用成功修正ログは時系列より規約単位で並べたほうが横展開できる
4生成スクリプトの無い127枚手直しで済ませるか、作り直すかを検討作り直しを選択ピクセル単位で座標を置く図は、スクリプトがないと微修正ができない
5設問200問数の出どころと、抽出漏れの本の有無を質す経路を確認未割り当てが0なら、絞り込みの過程は追える
6「系統」という列名何の分類かを聞き、出典書籍数へ言い換えさせる変更代理指標を出すより、元の数をそのまま出したほうが読める
7記事の事実確認の順序執筆後に確認する方針を、執筆前に読む方針へ差し替え変更あとから確認すると、書いた内容に合う箇所を探しにいく
8拡張のクリック領域クリック領域を実測させるボタン本体だけに限定原因は投稿側のクラス名の変更だった
9拡張のボタンが消えた直前の修正の副作用を疑う別の原因拡張フォルダ直下の __pycache__ でChromeが拡張を無効化する
10デプロイ速度Defenderの除外を入れて2回目を計測21分44秒 → 11分30秒縮んだのはファイルを大量に開く工程。記事のプリレンダーは16%止まり
11記事SSRの単体計測プリレンダー用バンドルの localFetch でハーネスを作らせる作成Mac側が未計測で、残る差はまだ説明できていない
12日本語ラップ母音を2文ずつそろえた12文を読ませる制約を確認丁寧語で終わる限り、そろうのは語尾であって韻ではない
13英語版のラップ音のつながる発音で作らせる削除聞き取れないものは残さない

今日の学び

  • やり直しの単位が全体になっている箇所は、直したい単位まで小さくできることが多い。全件アップロードはETagの比較へ、1枚ずつ直していた図は規約の一括適用へ、それぞれ移せた
  • 単位を小さくできない場所もある。生成スクリプトの残っていない図は、127枚まとめて作り直すしかなかった。出力だけをコミットして生成元を置き去りにすると、支払いはこの形で来る
  • 直した直後に別の症状が出ると、直前の修正を疑うのは自然だが、そこで止まると原因にたどり着かない。ボタンが消えた原因は、クリック領域とは無関係の __pycache__ だった
  • 計測は、全体の数字が動いたところで止めない。半分になっても、内訳を見れば縮んだ工程と縮まなかった工程に分かれる

明日やること

  • Mac側でも記事SSRのハーネスを回し、残っている差がどの工程から来ているかを突き止める
  • 消えたままのGitの資格情報を入れ直す
  • 127枚の作り直しの進捗を、比較用のビューアで確認する

関連記事