2026年8月3日の開発日記 - 壊れていたのは、思い込みのほうだった
2026年8月3日の開発日記
この日は、確かめずに持ち歩いていたものが2つ外れた。
ひとつは本番の投稿ヒートマップ。壊れていると思って調べさせたら、数字は最初から合っていた。もうひとつは「権限が広すぎるからあの方式を避けた」という自分の説明だった。記録に当たらせたら、そもそも検討していなかっただけだ。どちらも筋の通った話に聞こえるぶん、確かめないまま次の判断の土台にしていた。
残りの時間は、下書きを抱えたまま本番から外す仕組みを家業の鍵屋サイトに入れ、支援先の資料回収を手順ではなく線引きとして残し、ログイン済みのブラウザに繋がるまでの往復をやっていた。
今日のタイムライン

今日やったこと
1. 家業の鍵屋サイトに、下書きを抱えたまま育てる仕組みを入れた
前日までに入れたエリアページと施工事例3本が、ビルドには乗るのにどこからもリンクされていなかった。人間には見えず、検索エンジンからだけ見えている状態だ。動線の確認から始め、ヘッダーの項目を5つに絞った。
ただし事例のページは写真が届いていないし、聞き取りも3ケース中1ケースしか終わっていない。そこで下書きのまま本体に置き、本番のビルドからだけ外せるようにした。半分しか埋まっていないページを、人に見せずに手元で育てられる。
主な成果:
- 下書きフラグで本番から外す仕組みを実装(デプロイ事故の防止と手元での確認を両立)
- ヘッダーを5項目に整理し、エリアページと施工事例3本の動線を確保
- 施工事例をモデルケース3本として設計(金額・所要時間・ビフォーアフターの枠)
- トップの動画素材を差し替え、ウェブ表示用に軽量化してデプロイ
詳細: 本番に出さない下書きを抱えたまま、家業の鍵屋サイトを育てる
2. 専門書を出典に出さず、ファクトの照合先として使った
公開済みの歴史ページに事実の誤りが3件あった。生成AIに書かせた文章をそのまま通した結果だった。いちばん大きいのは、ある錠前を「日本独自」と書いていた箇所だ。
誤りを潰すために、OCR して全文検索に入れたばかりの専門書を照合先に使った。ただし書名は記事に出さない。読者の興味が本そのものに向くのは都合が悪く、技術的に踏み込んだ内容も含むからだ。事実だけを淡々と書く。
同じ日に、鍵が回る仕組みの図でも似たことをやった。「鍵を回す」ボタンを押すと部品が横にずれる。断面図で回転を描けないので横ずれでごまかしていたのを見つけ、奥行き方向の回り込みとして描き直させた。
主な成果:
- 公開済みページの事実誤り3件を、文献照合で修正
- 出典を出さない判断とその理由を明文化
- 図の軸の取り違えを、指摘 → 修正 → まだ違う → 描き直しの往復で解消
詳細: 専門書を出典に出さずファクトの照合先に使う、断面図で回転を描けなかった話
3. Mac にクローンし直したら、書き込みだけが通らなかった
APIトークンを発行するつもりで手順を聞いたところ、CLI のログインだけで済むと分かって発行をやめた。図版1,464枚を8並列で置いて、成功1,463枚・失敗1枚。
途中で「権限が広すぎるからあの方式を避けたのか」と自分で聞いてみたら、記録に当たらせた答えは違った。そもそも検討していなかっただけだった。よくできた推測ほど、確かめないまま事実として持ち歩く。
主な成果:
- 読み取り専用キーで書き込もうとして 403 になっていた原因を特定
- A案(従来どおりの経路)を採用し、B案は将来の改善案として保留
- Mac ではこの経路に倒れるとソースコードから読める形に寄せ、コミットとプッシュまで完了
詳細: Mac にクローンし直したら、Cloudflare への書き込みだけが通らなかった
4. 支援先の資料回収を、手順ではなく線引きとして残した
支援先の計画書をクラウドストレージから回収した。認証コマンドが120秒でタイムアウトしたので一度は失敗だと思ったが、プロセスは生きていて、ブラウザでの同意を待っているだけだった。
原本687ファイル・3.4GB を落として、原本には一切触らず、コピーの上でだけ整理した。更新日時とファイル名から最終版を突き止めるところまでやって、この流れをプロジェクトレベルのスキルに固定した。同じことを次の事業者でも繰り返すからだ。
主な成果:
- 原本687ファイル・3.4GB を取得漏れゼロで回収
- 原本を消さずコピー上で整理する方針を、スキルの線引きとして明文化
- 置き場所をユーザーレベルからプロジェクトレベルへ修正
詳細: クラウドストレージから資料を回収し、原本を消さずに整理する流れをスキルにした
5. ログイン済みのブラウザに繋がるまでの往復
支援先が使う会員管理システムの画面を見せようとしたが、繋がらない時間が続いた。原因は単純で、ログインしていない別のプロファイルを見ていた。
決め手になったのは「許可のダイアログが出ていない」という一点だった。繋がっているつもりで設定をいじり続けるより、これを接続できていない証拠として使ったほうが早い。繋がってからは、画面操作を積み重ねる代わりに内部APIの命名規則を調べ、入力から更新までを実際に通して確かめた。
主な成果:
- 接続できない原因をプロファイルの取り違えとして切り分け、実ブラウザに接続
- ID・パスワードの入力は自分でやる線引きを維持
- 音声から議事録を起こす既存案から、手元の資料を渡して把握させる方向へ転換
詳細: ログイン済みのブラウザに DevTools で繋ぐまでの往復
6. 投稿ヒートマップは壊れていなかった
本番のトップで直近1年の草が壊れていると思って調べさせたら、1658本出ていて、記事数とも整合していた。手元だけ空白だったのは dev サーバーが落ちていたからだ。
たどっていくと、別のノートPCで進めた10コミットが未取得のまま残っていた。さらに、デプロイは master に連動しているのではなく、デプロイした端末の作業ツリーがそのまま本番になる。端末を2台使い分けている限り、この勘違いは繰り返す。
主な成果:
- ヒートマップの数字を実データと突き合わせ、正常であることを確認
- 未取得の10コミットを安全な手順で取り込み(別セッションで日記生成を回したままだったため)
- 「master がそのまま本番」という思い込みを訂正
詳細: 壊れて見えた投稿ヒートマップと、別マシンに置き去りだった10コミット
7. Mac の細かい引っかかりを、その場で潰した
音声入力のショートカットが絵文字パレットを呼び出す。ターミナルの1行が選択できない。左のパネルが消せない。ひとつずつは小さいが、そのたびに手が止まる。
主な成果:
- 修飾キーの2回押しで絵文字パレットが開く設定を無効化
- ターミナルの多重化と1行選択(トリプルクリック)を習得
- 左のパネルは設定項目ではなく Esc で抜けるものだと判明
今日の試行錯誤
| # | テーマ | 試したこと | 結果 | 気づき |
|---|---|---|---|---|
| 1 | 図版の書き込み | 手持ちのキーでアップロードした | 403 | 図の配信用の読み取り専用キーだった。従来の経路に戻した |
| 2 | 避けた理由の確認 | 「権限が広すぎるから避けた」を記録と突き合わせた | 外れ | 検討していなかっただけ。筋の通る説明ほど疑わずに済ませる |
| 3 | 資料の回収 | CLI の認証コマンドを叩いた | 120秒でタイムアウト | 失敗ではなく同意待ち。プロセスの生死で区別が付く |
| 4 | 共有領域の一覧 | 認証後に一覧を取った | 空で返る | フラグ1つで見えたり見えなかったりする |
| 5 | 業務システムの画面 | DevTools で繋ごうとした | 別プロファイルを見ていた | ダイアログが出ないこと自体が接続できていない証拠 |
| 6 | 鍵の回転の表現 | 断面図で横ずれとして描いていた | 左の図が止まった | 奥行き方向の回り込みとして描き直した |
| 7 | 崩れの検出 | 隙間 → 実距離 → はみ出し量と3回変えた | 幻の崩れ | ヘッドレスの実ビューポートが500pxだった |
| 8 | ヒートマップ | 壊れていると思って調べさせた | 数字は合っていた | 犯人は落ちた dev サーバーと未取得の10コミット |
| 9 | 本番の同期 | master が本番だと思って確認した | 違った | デプロイした端末の作業ツリーが本番になる |
今日の学び
- もっともらしく出てきたものを、そのまま通さない。本の照合も、図の軸も、自分の記憶も同じだった
- 下書きを本体に置いたまま本番から外せると、半分しか埋まっていないページを手元で育てられる
- 原本を消さないと最初に決めておくと、整理の判断が軽くなる
- 許可ダイアログが出ないことは、接続できていない証拠として使える。設定をいじり続けるより早い
- 端末を2台使い分けるなら、「どのツリーが本番になったか」を覚えるしかない
明日やること
- 正規の料金表に差し替える
- 金庫の事例に合わせて料金表の粒度を直す
- 現場の職人に記事の内容を見てもらう
- 支援先の未了5系統の続き