nzw.jp

開発ノート 23 ページ（一覧を含む）で読んでいた bh-wanderer.js と bh-ambient.js をやめた。

残すのはアプリ一覧（/apps/）とデザインシステムの 2 ページ。

notes.css にあったトーン調整のうち、アプリ一覧が使い続けている saturate(0.3) は apps.css へ移し、開発ノート用の濃さ（0.34 / 0.22）は消した。

「開発ノートにブラックホールの徘徊は要らない」という本人の判断。2026-09-04 にトップから移したときから、モノクロの紙面に紫の降着円盤が浮く懸念を残し、濃さを下げたうえで「実物を見てから」としていた。

その結論にあたる。

開発ノートの各ページで読む JS が 2 本（計 66KB、gzip で約 21KB）減った。アプリ一覧の見た目（濃さ 0.5 / 0.32・saturate(0.3)）は変えていない。

デザインシステムと Synapse Link のノートにあった「開発ノートでも徘徊している」という説明も直した。

トップの幕 2 と開発ノート一覧で共有しているコミット数の図（activity-chart.js）を、週（月曜〜日曜）の合計で出すことにした。

窓は 90 日から 52 週へ延ばす。1 点が 1 日だったときに引いていた 7 日移動中央値と、中央値の 3 倍に跳ねた日のリングはやめた。

週で足した時点で均されているので、線は点を結ぶだけにする。今日を含む途中の週は図に入れず、最後に終わった日曜までで切る。

幕 1 と quiet 画面の実数も同じ窓（直近 52 週）に揃えた。

日ごとの点を並べると、書いている本人が見張られているように感じる、というのが理由。読む側に「何曜日に休んだか」まで見せる必要は無く、伝えたいのは止めていないことだけで、それは週で足しても残る。

途中の週を入れないのは、必ず低い点が右端に付いて「落ちた」ように見えるのと、「今週ここまで」という見え方がまさに日ごとの図と同じ息苦しさになるため。

窓を延ばしたのは、90 日を週にすると 13 点しか無く線にならないから。

2025-09-15 〜 2026-09-13 の 52 週で 1,054 コミット、手を動かした週は 33 週、最多は 1 週 179 コミット。

JSON は 90 点から 52 点に減った。日ごとの数字はどこにも出なくなり、点にかざして出るのも週の範囲と合計だけ。

全期間の月別は 開発の実測 にそのまま残している。

発売日と「発売予定／発売」の唯一の源を /book/books.json にした。

HTML 側は日付を含む既存の要素に data-book の印を付けるだけで、値は scripts/sync_books.py が書き戻す（deploy.sh が毎回 --fix-html を回す）。

JS で埋める案と、日付だけを <span> で包む案はやめた。

2026-09-16、Vol.4 の発売日を 2026-09-19 から 2026-09-22 へ 3 日ずらした。

手で 10 ファイル 24 箇所を直したのに、6 箇所が古いまま残った（窓辺の札の「9/19 発売」、カードの hero の「9/19」、ハブのバッジ「2026.09.19」、開発ノート 3 行）。

表記が「2026年9月22日／2026.09.22／9/22／2026-09-22」の 4 種に割れていて、grep でも拾いきれない。

3 画面のトップがアプリの版を独立に持つ問題と同じ形で、直す場所が増えるほど必ずどこかが残る。
JS で埋めると JS 無し・JSON 404・値が後から入る CLS が出る（幕 1 の実数と同じ理由でベタ書きを残す）。

日付だけを <span> で包むと、チップやバッジが inline-flex + gap なので flex item が割れて空白が gap に化ける。

だから既存の要素に属性を足し、要素の中の「日付の形をした字」だけを置き換える。

印は 11 ファイル 63 箇所（本文 55・属性 8。zerohalf.jp と開発ノートを含む）。books.json の発売日を 1 日ずらして状態を released にすると 51 箇所が一度に変わり、戻すと元に戻る。

一致していれば書き込まない（mtime 不変）。取りこぼしの 6 箇所は印を付けた時点で機械が直した。

2026-09-22 の発売時は status を released にするだけで「発売予定」が「発売」になる。ハブのバッジのクラス替えと購入ボタン化は手で。

bh-wanderer.js の「前フレームに描いた範囲だけ消す」は残し、1 秒に 1 回は canvas 全面を消して setTransform を当て直すことにした。

あわせて、GPU 側で canvas が作り直されたとき（contextrestored）とタブが前面に戻ったときにも、寸法と変換を当て直して全面を消す。

2026-09-13、「画面を放置すると処理がどんどん重くなる」という申告と一緒に、開発ノート一覧が全体に灰色に曇り、斜めの帯だけ元の明るさというスクリーンショットが届いた。

帯は一辺約 400px（倍率 2）の正方形を、いまブラックホールがいる位置まで斜めにつないだ形で、small の描画範囲（198px）と一致した。

つまりcanvas の中身がどこかの時点で暗く壊れ、部分消しが通り道だけを元に戻していた。開発ノートでは canvas を濃さ 0.34 で本文に重ねているので、黒く壊れるとちょうど灰色の幕に見える。

ヘッドレス Chrome で canvas を黒で塗ると、10 秒後も 91.6% が黒のまま残り、スクリーンショットと同じ見た目になった。

GPU プロセスを落とすと contextrestored は届くのに何もしておらず、変換が初期値に戻って本体が左上寄りの小さな点になったまま戻らなかった。

部分消しをやめて毎フレーム全面を消す案もあったが、全面の clearRect は GPU なら 1 回の塗りつぶしで、1 秒に 1 回なら部分消しの軽さをほぼ失わない。

何が中身を壊したかに関係なく 1 秒で消える形を選んだ。

本番で、黒で塗っても 2 秒後には本体だけに戻る（98.8% → 0.2%）ことと、GPU プロセスを落としても元の大きさで描き続けることを確認した。

実機で中身を壊したきっかけは特定できていない（スリープからの復帰などを疑っている）。「放置すると重くなる」も再現できていない。

トップと開発ノートを倍率 2 で 8 分放置し、描画プロセスと GPU プロセスのメモリ、CPU、コマの間隔、描画ループの回数、イベント監視の数を 30 秒ごとに取ったが、どれも増えなかった。

灰色の幕と同じきっかけで Chrome の描画が遅い方式に落ちている、というのは仮説のまま。

下の「背景を 3 段階に」で決めた「実行時の劣化は下方向へ 1 回だけ、上げ直さない」を撤回した。

濃いが重いと判定されても、その回だけ軽いに替えて、次の番でまた濃いを出す（sessionStorage の nzw:bg-demoted は廃止）。

判定そのものも、1 コマの遅れを 50ms で頭打ちにし、遅い状態が 90 フレーム続いたときだけ落とすように変えた。ウィンドウを狭めたときの「広げ直しても戻さない」も同じ理由でやめ、広げ直せば入れ替えを再開する。

10 秒ごとの入れ替えを出した直後に、「テーマを切り替えたら濃いが出なくなった」と言われた。本番で、濃いの表示中に時間帯テーマを昼へ切り替えると、0.4 秒後に軽いへ落ち、30 秒待っても濃いは戻らなかった。

テーマの切り替えは 8,000px のページを描き直すので、1 コマが 300〜500ms 止まる。

判定は指数移動平均（ema = 0.9·ema + 0.1·dt）が 24ms を超えたら落とす作りで、1 コマが約 90ms を超えるだけで閾値をまたいでいた。

それを「上げ直さない」がタブを閉じるまで固定していた。

「一度カクついた人を滑らかな側へ戻しても得が無い」という仮説で入れた決まりだったが、実際に引っかかったのは重い端末ではなくテーマ切り替えの一瞬で、しかも結果は「片方の絵柄が二度と出ない」だった。

10 秒ごとの入れ替えを入れたときもこの決まりはそのまま残しており、テーマを切り替えて初めて表に出た。

濃いの表示中にテーマを切り替えて 1 コマ 517ms 止まっても、濃いのまま 10 秒を終えて入れ替わるようになった（本番で確認）。

CPU を 6 倍遅くした状態では、濃いが 1 回軽いに落ち、約 12 秒後にまた濃いが出た。本当に重い端末の保護は残しつつ、誤判定で絵柄を失うことはなくなった。

背景が「自動」で、濃いに耐える端末のときは、最初の 1 枚を濃い／軽いのくじで決め、10 秒ごとに 0.7 秒のフェードで入れ替える。

手で段階を選んだとき、狭い画面・タッチ操作が主の端末など初めから軽いになる端末では入れ替えない。窓辺（quiet.html）は対象外にした。

あちらの段階は「描き込みの量」で、絵柄の出し分けではないため。

2026-09-13、同じマシンで撮った 2 枚のスクリーンショットで「この背景の違いは何か、どのタイミングで 1 枚目になるのか」と聞かれた。

答えは時間帯ではなく段階の違い（漂う粒＝濃い／点を線で結ぶ＝軽い）で、自動判定は端末とウィンドウで決まる。同じ端末なら毎回同じ側が選ばれるので、もう片方は設定を開かない限り見られない。

両方を見られたのは、ウィンドウの高さや重さの判定でたまたま落ちたときだけだった。2 つは作りも見た目もまったく別物なので、どちらも見てもらう側に倒した。

最初は「開くたびにくじ」にし、続けて「10 秒で切り替え」まで進めた。

段階を変えるたびに canvas と描画エンジンを作り直す作り（1 枚の canvas から 2 種類のコンテキストは取れない）なので、1 回きりの切り替えでは表に出なかった後始末の漏れが 10 秒ごとに効くようになった。

軽い版の stop() は resize の監視を外さないので destroy() に替え、bg-field.js は読み込み済みなら <script> を足さず、濃いの読み込み待ちを追い越されたときは世代番号で捨てる。

くじはページを開いたときに 1 回だけ引く（resize のたびに引き直すと、幅を変えただけで背景が入れ替わる）。5 分放置して、canvas は 4 枚のまま、resize の監視の数も増えないことを確かめた。

/ai-workspace の実体は pages/ai-workspace.html の 1 本と決め、html/static/ai-workspace.html は 24 行のリダイレクトに差し替えた。

教材レビュー（Bearise・Certly・Dotpile・声くらべ）の「テストエリア」タブは、複製側にしか無かったものを配信されている側へ移した。

「テストツールが無くなった」という申告から入ったが、消えていたのは導線だけで、4 本とも本番で 200 を返していた。

2026-09-06 にテストエリアを足したのは html/static/ 側で、docs/ai-workspace-features.md に手順として書いてあった pages/ へのコピーが実行されず、以後 2 ファイルが別々に育っていた（3276 行 / 2456 行）。

main.py には /static/ai-workspace.html → /ai-workspace の 301 があるが、nginx が /static/ を /var/www/html から直接返すのでこの 301 は一度も発火していない。

結果、ログイン不要で開ける旧 UI が生き続け、どちらを見ているかで画面が違った。

リダイレクトはハッシュを引き継ぐ形にした（changelog-daygrid.html が #daygrid、changelog-mydictly.html が #langbridge を付けてここを指しているため、meta refresh ではなく JS を先に置く）。

/static/ai-workspace.html#daygrid から DayGrid タブが開くところまで確認。

あわせて、複製側にだけあった旧 id を TAB_ALIASES で受けるようにし、トップページの /ai-workspace#mydictly がホームに落ちていたのを直した。

ホームは design-system.css の --nzw-* を読む専用クラス（.ws-*）で組み、ブレークポイントも @media で自前に持たせた。

そのうえで tailwind.config.js の content に ./pages/**/*.html を足した。

当初は足さない方針で始めたが、作業中に足さざるを得ない事実が出た。

content は ./html/**/*.html と ./html/static/js/**/*.js だけで、pages/ を見ていなかった。

ここに書いたクラスは CSS が生成されず、エラーも警告も出ずに当たらない。

最初は「だから pages/ には Tailwind を足さない」で済ませるつもりだった——tailwind.min.css は deploy.sh、pages/ は deploy-backend.sh と別のスクリプトで本番に出るので、content に足しても片方だけ回した瞬間に崩れる形が残るからだ。

ところが上の複製を畳んだ直後のビルドで、bg-green-500・bg-red-400・bg-slate-50/60・focus:border-sky-400・focus:ring-sky-100・gap-2.5・hover:bg-slate-300・mt-1.5 の 8 クラスが CSS から消えた。

どれも pages/ai-workspace.html が使っているもので、これまで生成されていたのは «html/ 側の複製がたまたま同じクラスを使っていた» という偶然に過ぎなかった。

複製を消すと同時に成り立たなくなる。

走査対象に pages/ を入れて 8 クラスとも戻し、変更前の CSS と比べて失われたセレクタが 0 であることを機械的に確認してから配った。

デプロイが 2 本に分かれている問題は消えていないので、pages/ にクラスを増やしたら deploy.sh も回す、を残した。

今回のホーム自体は新しいユーティリティを 1 つも使っていない。

枠線の色は --nzw-border に統一し、ブランド色はアイコンと hover の枠線だけに残した——5 枚が別々の色で縁取られていると、並べたときにどれが強いのか読めない。

単語帳・DayGrid・Certly・グループチャットの 4 本を src から data-src に変え、タブを開いたときに一度だけ src を入れる形にした。

テストエリアの 4 本は元から同じ作りになっていた。

初期 HTML に src を書くと、ホームを眺めているだけで 4 本とも走る。

LangBridge と Certly の main.dart.js が各 4MB 超、DayGrid は iframe の中でさらに Tailwind の Play CDN を読む。

ここにテストエリア（4 本で 15MB ほど）を足すと最大 8 本になる。postMessage も contentWindow も使っていないことを確認したうえで替えた。

ホームを開いた時点の iframe 読み込みが 4 本から 0 本になった。src を入れ直さず DOM に残す作りにしたので、タブを行き来しても読み直さない（入れ直すと読んでいた場所を毎回見失う）。

副作用が 1 つある。グループチャットは localStorage から前の部屋へ自動再入室するので、これまではワークスペースを開くだけで同室の人の画面に「参加しました／退出しました」が出ていた。

これがタブを開いたときだけになった。

トップだけに出していた起動スプラッシュを、アプリ・技術書・グッズ・開発ノート・デザインシステム・About・zerohalf の 7 画面に広げた。

仕組みは boot-splash.js 1 本のままで、絵だけをページごとに差し替える。JS が毎フレームやるのは --bs-p（0〜1）の書き込みと ％ の文字の 2 回だけで、何がどう動くかは知らない。

絵は /static/css/boot-splash.css が calc() で作る。data-splash の値は各ページが既に持っている data-site-nav-current と同じ語彙を使い、識別子を 2 系統に増やさない。

「1 回だけ出す」の単位も nzw:booted から nzw:booted:<key> に分け、回遊しても «そのページの初回» には出るようにした。

7 画面はどれも独自の視覚言語を持っているのに、開いた瞬間だけは無地だった。

サイトの作りが元々「骨格は 1 種類、皮だけ変える」（design-system.css → 各ページ CSS の上書き）なので、演出も同じ形にすれば新しい仕組みを増やさずに済む。

絵は新しい記号を持ち込まず、そのページが既に使っているものから取った — グッズは極太のタブular数字、開発ノートは 14px ピッチの方眼ドット、アプリはステータスを «形» で区別する点、技術書は低ポリのハチドリ、About は等高線とルート、zerohalf はロゴそのものの数直線。

下限は 600ms から 1200ms に伸ばした。静的 HTML は速く、実ロードに連動させるだけでは絵が一瞬で消えて «個性» が見えないため。

時間項の時定数も下限の半分に合わせないと、下限の時点でまだ .63 までしか来ておらず残りが一瞬で飛ぶ。

7 画面すべてで、初回に出る・同一タブの再訪では出ない・戻るでは出ない・6 秒のフェイルセーフが効く（JS と CSS をそれぞれ遮断して確認）ところまで通した。

フックの読み方で 1 度つまずいた。

テーマ側の window.NZW_SPLASH_HOOK を起動時に 1 度だけ捕まえる実装にしていたため、登録する inline script が boot-splash.js より後ろにあるページでは永久に null のままになり、ブラックホールが出なかった。

毎フレーム読む形に変えて解決。もう 1 つ、動きを減らす設定でスクロールをロックしないようにした。

About の動き抑制ブロックは animation-delay まで 0 に潰すので CSS の 6 秒フェイルセーフが即座に発火し、覆いが消えたのにロックだけが最大 4 秒残る — 「見えているのにスクロールできない」という最も質の悪い壊れ方になる。

下の「スプラッシュの絵を虹ラインへ差し替える」で外した canvas のブラックホールを、デザインシステムのページだけに戻した。

描画は既存の bh-wanderer.js をそのまま使い、bounds で画面中央の 420×220 の 暗いパネルの中だけに閉じ込める。

全面 canvas にはしない。VOID: xx.x% のタクティカルタグに読み込みの進捗を入れるため、ライブラリに autoDanger（既定 true）を足し、false のとき danger を外から与えられるようにした。

当時外した理由は 2 つあって、片方しか今回に当てはまらない。

「ブラックホールは Synapse Link 1 プロダクトの絵であって nzw.jp の看板ではない」は今も正しいが、戻す先はサイトの玄関ではなく、ブラックホールを解説しているページ 1 枚なので衝突しない。

もう片方の性能は、原因が «canvas 一般» ではなく「白背景に加算合成を重ねたこと」だった。

降着円盤が RGB 合計 17 しか変えないのに 1 フレーム 99.3ms のうち 75ms を占めていたのは、加算は白に足しても飽和するだけだから。

暗いパネルの中なら同じ絵が «見える» ぶんの仕事になる。加えて当時の 406 行の移植と違い、bh-wanderer.js はスプライト焼きとダーティ矩形が入っていて毎フレームの仕事が桁で違う。

スプラッシュは bh-wanderer.js の到着を待たない作りにした（使えるようになったフレームで初めて作り、読めなければバーだけで成立する）。

覆うはずのものが待ち時間を延ばす側に回らないための線引きで、ここだけは崩さない。

読み込みの置き場でも 1 つ踏んだ: ダウンロードを先行させようと defer で head に移したところ、defer は «body 末尾の非 defer» より後に走るため、ライブ見本の inline script と bh-ambient.js が BlackHoleWanderer 未定義のまま先に動き、どちらも黙って消えた。

実行位置は body 末尾のまま、preload で取得だけ先に始める形に倒した。

About の URL を /about.html から /about/ へ移した。

実体は html/about/index.html、旧 URL は FastAPI のミドルウェアで 301（既に /static/ai-workspace.html で同じ形を使っている）。

あわせて肩書きを「AI活用のチームマネージャー／SaaS開発のプロダクトマネージャー」から 「PoC で終わらせない、AI プロダクトマネージャー」の一行に変え、所属と年数は下の小さい行（.profile-role-sub）へ逃がした。

URL の方は、/apps/・/book/・/goods/・/static/notes/ がすべてディレクトリで、About だけが拡張子付きで残っていたのが理由。

.html は配信の実装であって、読む側には関係がない。
肩書きの方は、元の一行が役割を 2 つ並べただけで、何をする人かが読み取れなかった。

職務経歴書側の芯は「PoC（0→1）で止めず、運用とスケール（10→100）まで持っていく」なので、そこを言い切って一行に置いた。

事実（エンジニア15年 → PjM → SaaS開発チーム マネージャー）を同じ行に足すと読点だらけになって何も残らないので、行を分けている。

サイト内のリンク 36 箇所と zerohalf.jp からの 2 箇所を /about/ に張り替え、canonical と og:url も差し替えた。

本番で /about.html → 301 → /about/ を確認し、旧ファイルはサーバーから削除（deploy.sh は --delete を付けていないので、消すには ssh が要る）。

/about（末尾スラッシュ無し）は StaticFiles(html=True) が 307 で拾う。

肩書きは About だけでなく、書籍 5 ページの著者紹介と zerohalf.jp の自己紹介の計 6 箇所も同じ一行に揃えた（同じ文言がサイト内に散っているので、片方だけ新しいと «どちらが本当か» が分からなくなる）。

ヘッダーの現在地下線を box-shadow: inset 0 -2px 0 で引くのをやめ、background-image の 2px 帯に変えた。

群の先頭（[data-group-start]）だけ background-size: calc(100% - 13px) で短くする。

群の変わり目の縦罫を .site-header-link::before＝リンク自身の子として持たせているので、縦罫 1px + margin-right 12px がリンクの幅に入っている。

inset の影は幅いっぱいに出るため、About（「作り手について」の先頭）では下線が縦罫の下から始まり、アイコンと左端が揃わない。

影は引く幅を指定できないが、background なら指定できる。

ズレていたのは data-group-start が付く 2 項目（開発ノート・About）だけで、他は元から正しかった。

data-group-start は i > 0 の条件付きで付くので、先頭の「アプリ」に 13px の引き算が漏れる心配もない。

4 スキン（紙・白・夜・暗）すべてを本番で撮って確認した。

カード版と 6 幕から雨のオーバーレイをその日のうちに撤去した。雨を絵として持つのは窓辺だけにする。

代わりに、窓辺の「降るもの」（.qt-motes）に大雨の段を足した——雨脚は 1.9 倍の長さで 1.8 倍速く、揺れはさらに小さく、翳りを厚くし、本数は 24 → 60 本（「ふつう」なら 12 → 30 本）。

大雨のボタンは 3 画面とも残す。

「窓辺以外は雨のアニメーションは不要」という指摘。前面のオーバーレイは z-index: 9999 で、粒が本文の上を通る。

カード版と 6 幕は読ませる画面で、窓辺は眺める画面——同じ雨でも置く意味が違う。加えて、窓辺には最初から雨があった（data-qt-weather="rain" で舞うものが細い縦線に変わる）。

雨の実装が 2 系統あることに気づかないまま 3 つ目を前面に足していたのが実際のところで、消すべきは新しく足した方だった。

home.css から 5,978 文字、home-theme.js から雨の生成が丸ごと消えた。

この 2 画面で天気が効く先は背景の線と虹ラインの 2 つだけになり、前面に置く要素はゼロになった（#weather-overlay ごと削除）。

大雨のボタンを 3 画面に残したのは、天気の設定が localStorage で共有されているから——片方だけ選べないと、選んだ状態がもう片方で «どのボタンも押されていない» に化ける。

天気の「雨」を 小雨 / 雨 / 大雨の 3 段階に割った。段階は #weather-overlay[data-rain] が持ち、粒の長さ・太さ・傾き・色は CSS 側に集約して、JS が決めるのは何本・どの層に置くかだけにした。

大雨は粒を 200 本に増やすだけでなく、視界の濁り・風のむら・足元のしぶきの 3 枚を別に重ねる。どの判定にも入らず「無天気」だった雷雨（95〜99）も大雨に寄せて拾う。

実測が大雨になるのは年に数日なので、表示設定に手で選べる 6 つ目のボタンを足した（天気の行だけ 6 列になる）。

「大雨のアニメーションも考えて」という依頼で開けたら、.rain-drop の CSS がリポジトリのどこにも無かった。

JS は className を付けて色を #a5f3fc で塗るだけで、幅も高さも animation-name も持たない空の div が 100 枚積まれていた——初回コミットから一度も雨は降っていなかった（デザインシステムのページには降る前提で書いてある）。

仮に描けていても、水色を白い下地に置いていたので昼はほぼ見えない。だから大雨の前に、まず雨を降らせるところからになった。

その上で、大雨を粒の量と速度だけで作らないと決めた。粒を増やすと「たくさん降っている」にしかならず、強い雨として読まれるのは視界が濁ること・風でむらが出ること・足元が白く煙ることの方だから。

奥行きも 3 層に分けて速度差（1.55 / 1.0 / 0.72 倍）を距離として読ませる。

粒は小雨 45 / 雨 95 / 大雨 200 本（横 1280px 基準。狭い画面は 0.45 倍まで落ちる。実測 1440px で 200 本、390px で 90 本）。

大雨は落下 0.5 秒・傾き 14 度で、傾きと横流れ（35vh）は必ずセットで動かす——片方だけ変えると粒が自分の向きと違う方向へ滑って見える。

虹ラインは大雨だけ「静か→活発」の 1 軸から外し、周期 60 秒（晴れ寄りに速い）／彩度 0.82（雨より低い）にした。

動きは強いが色は濁る、という別の性格づけ。

背景（Canvas2D / WebGL2）にも大雨のプリセットを足し、判定の境目は 3 か所（home-theme.js の rainTierOf()・bg-synapse.js・bg-field.js）で揃えた。

prefers-reduced-motion では粒を 1 枚も作らない。共通の抑制ルールが animation-iteration-count を 1 にするので、作ってしまうと画面の下端に止まった粒が貼りついたまま残る。

開発ノートに プロダクトの系譜を新設した。縦を時間、横を扱う領域に取り、改名・後継・作り直し・開発中止だけを線で結ぶ。

ノードは全部それぞれのノートへのリンクにして、各プロダクトの中身はいっさい書かない。一覧ページには本数を数えるフィルタの外側に導線を 1 枚置いた。

Socrates → Grizzlingo → Bearise、LangBridge → MyDictly という血縁は、実際には各ノートのメタ表の「出自」「後継」行と、リポジトリのコミットログに散らばっていた。

1 本を読んでいるあいだは、その 1 本の話しか見えない。一覧に戻っても更新日順のカードが並ぶだけで、何が何から生まれたかは読み取れない。

ノートは「なぜそう決めたか」を書く場所なので、ここに系譜を足すと 1 本ずつが重くなる——だから線だけを持つページを別に立てることにした。

導線をフィルタの中に入れなかったのは、チップが数えているのが「ノートの本数」で、系譜図はノートではないから。

ノード 14 個・辺 7 本の 1 枚に収まった。

分かれ道は 4 つ——Socrates からのピボット、Grizzlingo の中止と Bearise への再構築、LangBridge から MyDictly への改名、そして Quick Query Question と DayGrid が名前を残したまま中身を作り直したこと。

最後のひとつは図を描くまで「同じ形の出来事が 2 回あった」と気づいていなかった。色は使わず線種と枠だけで区別している（実線＝同じ血、破線＝知見の受け渡し、破線枠＋✕＝開発を終えたもの、枠なし＝開発ノートが無い）。

図が読み物の幅（768px）だと 7 割まで縮んで読めないので、.fig-wide で図だけ器の外へ出し、狭い画面では縮めずに横スクロールさせている。

通った跡を全部やめた。点の列 → 連続した溝 → 泥の層、と 2 日かけて作り込んだものを丸ごと外し、10〜24 秒に 1 個だけ小さな○を吐くだけにした。

○は本体から離れる向きへ 110px 流れながら 4.2 秒で消える。

「足跡はいらない、稀に小さな○を吐き出すくらいでよい」という指摘。作っている最中は「どう見せるか」ばかり考えて「そもそも要るか」を問い直していなかった。

跡は「どこを通ったか」という情報で、読み物のページに置くと本文より強い意味を持ってしまう。読者が追うべきものは本文であって、装飾の軌跡ではない。

うんこに見えたのも、溝が数珠つなぎに見えたのも、根っこは同じで跡が画面に長く居座りすぎていたことだった。形を直す方向で 2 回作り直したが、直すべきは形ではなく存在の方だった。

実測 3.4 個/分、画面に○が居る割合は 24%。同時に 2 個以上出ることは実質ない。

間隔を毎回引き直すのは、等間隔だと「一定周期で出る装置」に見えてたまたま出会うものにならないため。吐く向きを全周から引いているのは、進行方向の後ろに寄せると尾に見えて、やめたはずの跡に戻るから。

飛距離 110px は重力圏（tiny 60px / medium 130px）を抜けるための値で、短くすると本体の暈に飲まれて出たことすら分からない。

コードは 100 行以上減った——泥の二次曲線、溝の区間ごとの太さ計算、点の位相管理が全部消えた。

ヘッダーの真下にあった8 枚の横スクロールカルーセル（6 秒自動送り）を廃止し、トップを 6 つの幕として組み直した。

①サイトを一言で言う見出しと実数、②直近 90 日のコミット数、③いま見てほしい 3 つ、④やめたことで説明する、⑤つくったもの全部（35 枚）、⑥このページ自身のこと。

以前のデザインは /classic.html として凍結して残し、ヘッダーのボタンでいつでも往復できるようにした。出し分けは Cookie を見て main.py がサーバ側で行う。

既定は従来のデザインのまま置いた。作り替えた側を既定にすると、判断が正しかったかを自分で見比べる前に全員へ配ってしまう。

新しい方は「選んだ人が見る側」にして、ヘッダーのボタンを最初の 5 秒だけ薄く光らせて存在だけ知らせる。索引・canonical・OGP は既定側（classic.html）が持ち、新しい方は noindex にしてある。

きっかけは「もっとインパクトのあるサイトにしたい」という一言だったが、実際に測ると足りないのは派手さではなかった。grep -c "og:" が 0 で、<title> は「nzw.jp」の 4 文字。

SNS に貼っても無地のリンクにしかならない。ページ内にもサイト全体を語るコピーが 1 つも無く、いきなり販促スライドが始まる。

docs/VISION.md 自身が「ならないもの」に挙げた「ただの作ったものリスト」に、トップがいちばん近い状態だった。

カルーセルは書籍・グッズ・アプリ 4 種を平等に扱っており、平等は無印象。しかも読ませる前に流れる。

8 枚のうち 5 枚は下のグリッドにも同じものがあり、情報としては重複していた。
作り替えを「一度きりの入れ替え」にしなかったのは、判断が正しかったか自分で見比べられるようにするため。

移行のための並行ファイルがそのまま恒久の classic になるので、捨てる作業がゼロで済む。

index.html は 8,238 行 → 3,444 行（インライン CSS 1,900 行と JS 2,700 行を外部化、動かない canvas 5 枚と死にコード 650 行を削除、カルーセル 920 行を削除）。

canvas は 11 個 → 2 個。<title>・meta description・OGP・canonical を新設し、OG 画像は scripts/og/home.html を Playwright で撮って作り直せるようにした。

採用担当にいちばん効く数字として「直近 90 日で 477 コミット / 9 リポジトリ」を幕 1 と幕 2 に出した。

図は開発ノート一覧のものを activity-chart.js として切り出して共有している（あちら側が画素単位で変わっていないことを確認済み）。

数字は HTML に最終値をベタ書きし、JSON は答え合わせに使う——こうすると「JS 無し」「JSON が 404」「数字が後から入って版が飛ぶ」の 3 つが同時に消える。

CSS の scroll-driven animations（animation-timeline: view()）を「使える環境だけの飾り」として重ねていたが、丸ごと撤去した。

出現は scroll-stage.js の IntersectionObserver 一本にする。content-visibility: auto も同じ理由で撤回した。

view() の進み具合は「スクロールできる量」で決まる。そのためページ下端の要素は animation-range の終わりへ到達できず、永久に半透明のまま残る。

実測で締めの一行が opacity 0.17 で固まった。そもそも Safari は未対応なので、ほとんどの読者は Observer 側を見ている。

読まれない方の経路が、この壊れ方を抱えたまま存在する価値は無い。
content-visibility: auto は中身がレイアウトされない状態になるため、子要素が IntersectionObserver から見えなくなる。

飛び越えたときの掃き出しが矩形を読めず、幕 4 の 5 要素が隠れたまま残った。長いページなので効かせたかったが、出現とは両立しない。

実装しながら 3 つ踏んだ。(1) IntersectionObserver は「飛び越えた」要素に通知を出さない（交差の割合が 0 のまま 0 なので閾値をまたがない）。

どれか 1 つでも通知が来たときに控え全体を掃く形にした。(2) 1 要素に 2 つの監視を掛けると後勝ちでハンドラが消える。

幕 3 は出現と進捗の両方を掛けており、出現側が黙って上書きされていた。

(3) グリッドの札は表示の出し入れを home-cards.js が握っているので、出現もあちらから仕込まないと「もっと見る」で出た分が opacity 0 のまま残る。

いずれもエラーを出さずに静かに壊れる種類で、通しで動かして初めて見つかった。

CSS 側は「JS が属性を立てたときだけ隠す」書き方に統一してある（about/index.html の .reveal は素の状態で opacity 0 なので、IntersectionObserver が無い環境では永久に見えない。あれを繰り返さない）。

背景を 切 / 軽い（Canvas2D）/ 濃い（WebGL2）の 3 段階にした。端末を見て自動で選び、表示設定から手でも変えられる。

軽い方は bg-synapse.js を改造せず設定だけ絞って使い、濃い方は新規の bg-field.js（357 行・依存ゼロ）。

prefers-reduced-motion は段階に混ぜない。

軽い方を作り直さないのは、SynapseBackground が setConfig で粒数も結線距離も絞れるうえ、WEATHER_PRESETS と setWeather が既にサイトの天気系に繋がっているから。

新規実装するとそこを一から書くことになる。
濃い方にライブラリを入れないのは、描くのが draw call 2 回（全面の三角形 1 枚と gl.POINTS 1 回）だけで、シーングラフもカメラも要らないから。

three.js は 150KB gz あり、HTML 全体が 80KB gz のこのページでは単独で最大のアセットになる。

Play CDN の Tailwind をやめた経緯と真逆になってしまう。

点の動きは (種, 時刻) の閉じた関数なので GPGPU も transform feedback も不要で、静的な VBO 1 本と uniform 数個で足りた。

prefers-reduced-motion を「切」にマップしなかったのは、切が上書きできるユーザーの選好なのに対し、あちらは上書きされてはならない OS の設定だから。

同じ値にすると「濃い」を押しただけで OS 設定を蹴破れてしまう。抑制中は設定行そのものを隠す。

自動判定は bh-wanderer.js の _resolveProfile を型にした。写したのは「情報が無いことを理由に降格しない（|| 8 の楽観的な既定）」と「向きが変われば引き直す」の 2 点。

ソフトウェア実装の WebGL（SwiftShader / llvmpipe）も軽い方へ落とす——CPU ラスタライズの WebGL は Canvas2D より遅い。

実行時の劣化は下方向へ 1 回だけで、立ち上がりの 120 フレームは見ない（シェーダのコンパイル・初回ペイント・フォントの差し替え・スプラッシュの退場が最初の 2 秒に固まっているので、素朴な検出器は必ず誤爆する）。

上げ直さない。
踏んだ穴が 2 つ。

1 枚の canvas から 2 種類のコンテキストは取れない——一度 webgl2 を取った canvas に getContext('2d') を投げると null が返り、降格が「背景が消える」に化ける。

段階を変えるたびに canvas を作り直している。もう 1 つは明るいテーマで粒が主張しすぎて本文が読みにくくなったこと。

暗い地と同じ量を乗せると白の上でベージュの斑点になるので、地の明るさで不透明度と大きさを落とす。

ブラックホールの跡を、点を落とす方式から1 本の連続した溝に置き換えた。0.6 秒ごとに本体の位置を記録し、その折れ線を引く。

太さと濃さは新しいところほど大きく、古い側へ向かって細りながら 30 秒で消える。粒のスプライトと、粒ごとの位置・速度・寿命の管理は丸ごと消えた。

「うんこのように見える」という指摘。実物を見ると否定できなかった。

丸い染みが等間隔で並んでいる絵なので、明るい地の上ではそう読める。原因は形ではなく離散させたことにある。

跡というのは「通った」という連続した出来事の記録なのに、点にした時点でその連続性が落ち、あとに残るのは正体不明の丸だけになる。

線にすれば向きと速さがそのまま形に出る。
寿命を 24 秒から 30 秒へ伸ばしたのは、短いと溝が本体の重力圏（medium で直径 300px）の内側で終わってしまい、降着円盤の光に飲まれて跡として読めないため。

線を 2 本重ねているのは、このライブラリが置かれるページの地の明るさを知らないから。太く淡い紫（アプリ一覧の黒地用）と細く濃い黒（開発ノートの紙地用）を常に両方引いて、どちらの地でも片方が残るようにしてある。

区間ごとに太さと濃さが違うので 1 本の Path2D にまとめられず、描画は 1 フレームあたり 51 区間 × 2 本 = 約 100 ストロークになった。

そのかわり消す範囲は溝全体を囲む 1 枚だけにしてある（区間ごとに矩形を積むと、重なった領域を何度も消すことになって割に合わない）。

前の方式が持っていたスプライトの焼き直しと dpr 追従は不要になった。丸い線端が区間の継ぎ目で膨らみ、円が数珠つなぎに並んで見えるのは残った。

あとから、その円と円のあいだを埋める泥の層をいちばん下に 1 枚足して潰している（区間の中点を法線方向へずらした二次曲線を、太さとずれを 2.6 秒周期で揺らしながら引く）。

色は中間調 1 色で足りた——明るい地では暗く、暗い地では明るく転ぶため、芯と縁のように 2 本引く必要がない。位置を止めて時刻だけ 0.65 秒進めたとき、跡の画素の 47% が変わることを確認している。

About の空を作り替えた。(1) 太陽は filter: blur(34px) でぼかした円と、ぼかした三角の光条をやめ、同心円・方位環・細い直線の光条を持つ図に置き換えた。

にじみは CSS の blur ではなく SVG のグラデーション 1 枚。(2) 月は白丸をやめ、同じ半径の円をずらしたマスクで満ち欠けを作り、クレーターを塗りではなく細い輪にした。

欠け具合は今日の月齢から出す。(3) 操作卓にもう 1 群足し、季節（自動／春夏秋冬）の隣で時間帯（時計／朝昼夕夜）も選べるようにした。

「太陽や月のデザインがイケてない」という指摘。見に行くと、どちらもこのページの語彙から外れていた。

About は地形図（等高線・稜線・ルート破線）と 8bit で組んであり、線は細く、形は測れるものとして描いてある。そこにぼかした橙色の塊と白丸だけが、輪郭も情報も持たずに乗っていた。

太陽と月も同じ「測る道具」の側に寄せれば、装飾ではなくページの一部になる。
時間帯をヘッダーに出したのは、16 通り（山 4 × 時間帯 4）で作ってあるのに、訪問者は自分の時計が指す 4 通りしか見られなかったため。

季節はボタンで選べるのに時間帯だけ ?time= を手打ちしないと見られないのは、作りの非対称だった。月齢を本物にしたのは、季節を訪問者の暦から、時間帯を訪問者の時計から出しているのと揃えたかったから。

今夜の形と合っている月のほうが、毎回同じ形の飾りより面白い。

ぼかしを SVG のグラデーションに替えたので、毎フレーム合成していた blur が 3 枚ぶん消えた（輪郭も締まる）。

時間帯を動かせるようにしたぶん --sun-* / --star-o を @property に登録し、季節と同じ 1.4 秒のクロスフェードに乗せた。

--sun-size だけは min() を含むので登録せず（解決に失敗した環境で initial-value に落ちて絵が壊れる）、大小は数値の --sun-scale で付けている。

手こずったのは「昼」の置き場所。真上＝画面上端は、帯（110px）とヒーローのカード（185px）に挟まれた 75px しか空いていない。

輪を持たせたぶん前より場所を食うので、芯をカードの上端に重ねて上半分だけを出す置き方に変えた。狭い画面では操作卓が 2 段に折り返して帯が 165px まで伸びるため、そこだけ別に下げている。

2 つ決めた。

(1) 開発ノートのブラックホールだけトーンを落とす — 濃さを 0.8/0.65 → 0.34/0.22、彩度を saturate(0.3)、6 層目（VOID タグと本体まわりのフレア）は data-label="false" で切る。

適用は notes.css の末尾と各ノートの script タグだけで、レンダラには手を入れない。アプリ一覧とデザインシステムは素のまま。

(2) 通った跡の粒を本体の半径に対する比にする — debrisSize: 2.6px（固定）を debrisSizeRatio: 0.13 に置き換えた。

(1) は前回のログで「紫がノートのモノクロから浮く」と書いて保留にしていた件。実物を見たら、いちばん邪魔だったのは色より本文の上に重なる「VOID: 12.7%」の文字だった。

読んでいる行の上に別の書体で数字が乗ると、意味を持った情報だと思って一瞬読んでしまう。彩度と濃度は下げるだけで済むが、これは消すしかない。

完全な grayscale にしなかったのは、紫がわずかに残るほうが「Synapse Link のあれだ」と分かるため。

(2) は固定 px だったのが単純に間違いだった。tiny（半径 10px）でも medium（35px）でも同じ 2.6px の粒が落ちるので、大きい個体ほど跡が相対的に細って見える。

跡は「何がここを通ったか」の手掛かりなのに、大きさの情報がそこだけ落ちていた。

粒は tiny 1.3px / small 2.6px（据え置き）/ medium 4.6px。0.13 という比は、それまでの 2.6px がちょうど small（半径 20px）ぶんだった値を採った。

絵そのものは触っていない——層数も係数も分割数も原典のまま、変えたのは粒の大きさの決め方と、ページ側の CSS 2 行だけ。

検証中に副産物として分かったのが、headless Chrome では rAF がほとんど回らないこと（20 秒待っても elapsed=0.0s）。

フレームを手で送り、toDataURL() で焼いてから撮る形にして、ようやく尾の見た目を確認できた。canvas の絵を CI で撮るときはこれが要る。

トップページ（index.html）からブラックホールを外し、アプリ一覧（/apps/）・開発ノート 18 ページ・デザインシステムへ置き換えた。

index.html に直書きしていた 140 行の起動処理は /static/js/bh-ambient.js に切り出し、canvas・当たり判定・CSS までそのファイルが差し込む形にしたので、ページ側は <script> を 2 本読むだけになる。

同時に、時間帯ごとの出現抽選と天気ごとの 4 通りの周期も落とした。

「トップページに動くブラックホールがあるのは不気味」という指摘。トップページは判断の場で、来た人はヒーローと製品カードを見比べて次にどこへ行くかを決めている。

その真上を黒い球が横切ると、意味の読めない動きに視線が引かれ、決めるための時間を削る。一方でアプリ一覧・開発ノート・デザインシステムは腰を据えて読むページで、視線は本文の列に固定されている。

同じ絵でも、視線の外側をゆっくり通り過ぎるだけなら邪魔にならない。しかも「Synapse Link のレンダラを移植した」という話そのものがこの開発ノートに書いてあるので、書いてある場所に現物が居るほうが筋が通る。

抽選をやめたのは、置き場所を狭めた以上「たまに出会う」を二重に掛ける必要が無くなったため（出現確率は data-chance で戻せるようにしてある）。

トップページから canvas 2 枚ぶんの CSS（76 行）と起動スクリプト（140 行）が消え、bh-wanderer.js の読み込みも 1 本減った。

移した先では 1 匹だけが手前（z-index: 30）と奥（z-index: -1）を 24 秒周期で往復する。地との相性は移した先で分かれた。

アプリ一覧は黒地の製図台なので、絵としてはトップに置いていた頃より馴染む。逆に開発ノートはモノクロ（Dot Matrix）に組み直したページなので、紫の降着円盤が浮く懸念が残っている。

ページ側から --bh-front-opacity / --bh-behind-opacity で濃さを下げられるようにして、判断は実物を見てからにした。

開発ノート一覧の頭に置く図を、ノート 16 本の最終更新日から直近 90 日のコミット数に差し替えた。

ノートが扱う 9 リポジトリ（nzw.jp / DayGrid / Bearise / Certly / Engly / MyDictly / Synapse Link / Quick Query Question / 書籍）の git log を scripts/gen_notes_activity.py が数えて activity.json に落とし、deploy.sh が毎回作り直す。

図は点＝その日のコミット数、線＝7 日移動中央値。

最初に置いたのは「ノートの最終更新日」の分布だったが、ノートは 16 本しかなく、点も 16 個しか出ない。しかも中身は各カードに書いてある日付の焼き直しで、図にした分の情報が増えていなかった。

開発ノートの頭に出すべきなのは「ノートをいつ触ったか」ではなく「その裏で何をどれだけ作っていたか」のはず。手元にあって嘘のつけない数字はコミット数だったので、そこから読む形にした。

生成 AI との対話時間も測れた（37 日で 137.3 時間）が、Claude Code の履歴保持が 37 日ぶんしか無く、放っておくと過去から消えて窓が前に滑るので採らなかった。

90 日で 466 コミット、手を動かした日は 65 日、最多は 1 日 53 コミット。最初は線形の縦軸で描いて失敗した——中央値が 2 なのに最大が 53 なので、普段の日が全部下端で潰れて死んだ図に見えた。

縦軸を平方根目盛に変え（ラベルは実数のまま）、跳ねた日は中央値の 3 倍以上のときだけリングで囲う形にして読めるようにした。

2 倍にすると 18 日が囲まれて「目立たせる」意味が消える。データはリポジトリ側にあるので、ノートを足しても図の面倒は増えない。

開発ノート 18 ページが各自持っていたページ内 <style>（合計 4,488 行）を捨て、/static/css/notes.css 1 枚に統合した。

同時に見た目を作り直し、罫線・箇条書き・進捗・時系列・区切りをすべて「点」で描くことにした。プロダクトごとのブランド色（--brand / --topic-brand、実数 14 色）は全廃し、色で意味を運ぶのをやめている。

例外は 3 つだけ：ヘッダー最上部のレインボーライン（サイトの識別子）、アプリアイコンとスクリーンショット（既定はモノクロ、hover で戻す）、カラーパレット見本（色が内容そのもの）。

きっかけは見た目の不満ではなくコピーの劣化。ノートを 1 本足すたびに 250 行前後の CSS を隣のページから貼っていたので、同じ .meta のラベル幅が 1% / 30% / 34% / 38% の 4 通りに分裂していた。

「開発ノートは判断の記録であって宣伝ではない」と書いておきながら、ページごとにブランド色を足していたのも噛み合っていない。

ステータスや警告を色で示していた箇所も、色を抜いたときに情報が消えるなら、そもそも色にしか意味を載せていなかったということになる。

だから色を抜くのを目的ではなく検算として使い、消えた分は点の塗り／中抜き／密度に置き換えた（公開中＝二重丸、β版＝中抜き、開発終了＝薄い中抜き、注意＝点の網）。

4,488 行 → 1 ファイル 1,471 行。以後ノートを足すときに CSS は書かない。

figure.fig の図版は --nzw-* トークンで描いてあったため、トークンを差し替えただけで図まで自動でモノクロになった。

逆に色を直書きしていた 2 枚（ブラックホール・重なり順）は .fig--ink として切り出し、hover でだけ元の色を出している。

cdn.tailwindcss.com（Play CDN）の読み込みと、index.html に直接書いていた tailwind.config を捨てた。

設定はリポジトリ直下の tailwind.config.js に一本化し、npm run build:css が吐く /static/css/tailwind.min.css を <link> で読む。

ビルドは deploy.sh に組み込み、流し忘れて「新しく足したクラスだけ効かない」が起きない形にした。

「トップが重い、とくに画像が出ない」という体感の原因を、最初は画像の重さ（15.5MB）だと思っていた。ところが本番をヘッドレスブラウザで実測すると、DOMContentLoaded まで 39.4 秒かかっていた。

同じ回線で about.html は 3.98 秒、/goods/ は 3.07 秒。違いは 2 つで、トップだけが 499KB あることと、トップだけが Play CDN を読んでいること。

Play CDN は DOM の変化を監視して JIT コンパイルを回すので、8,000 行の文書が流れ込む間じゅう全走査が繰り返される。

画像が出なかったのは帯域ではなく、先読みスキャナが画像を取り終えているのに DOM が組み上がらないためだった。30 秒経過時点で本文はまだ 838 要素しかできていなかった。

本番の DOMContentLoaded は 39.4 秒 → 31.6 秒（同時に測った about.html は前後とも 3.7〜4.0 秒で、計測環境が同条件だったことは確認済み）。

期待したほどは縮まなかった。ローカルの切り分けでは 56 秒 → 15 秒という大きな差が出たが、あとで uptime を見たらロードアベレージが 22（10 コア）まで上がっており、その値は計測マシンの負荷で汚染されていた。

信用できるのは本番で前後を同じ手順で測った 2 割の短縮のほうだけ。

ただし切り分け自体は残った: インライン <style> 16 個はほぼ無コストで、残りの支配項はインライン <script> 26 個の実行時間（スクリプトを全部外すと同条件で 4.66 秒 → 1.29 秒、つまり 7 割強）。

12 個の canvas の初期化を可視化まで遅らせるのが次の一手で、宿題として残す。

なお package.json には以前から build:css が書かれていたが、出力先が html/ の外で content グロブもトップを含んでおらず、一度も配信されていなかった。

写真・スクリーンショット系 15 枚を表示サイズに合わせて縮小し WebP へ置き換え、元ファイルは消した。ロゴ・アイコン 4 枚は拡張子を変えず PNG のままリサイズ（参照を書き換えずに済む）。

<img> 22 枚に loading="lazy" を入れ、ヒーロー第 1 パネルだけ eager + fetchpriority="high" を残した。

ただし og:image に使っている 2 枚だけは、リンクプレビューの互換性を優先して従来形式を維持した。

初回表示で 15.5MB を一斉に取りにいっていた。

内訳の偏りがひどく、blackhole2.png が 4.74MB（1290x2796 をカードのサムネイルに使用）、zerohalf-logo.png が 2.97MB（1626x1622 をヘッダーで 20px 表示、しかも全ページ共通）。

加えて loading="lazy" が 1 箇所も無く、プロジェクトカード 36 枚が全部マークアップにあった。

「9 枚だけ表示」は JS がパース後に display:none を付けているだけなので、先読みスキャナは既に 36 枚ぶん取り終えている。

派生ファイルを足す案もあったが、同じ絵が 2 つある状態は必ず片方が腐るので置き換えを選んだ。

15.5MB → 0.74MB（blackhole2 は 4.74MB → 26KB、ヘッダーロゴは 2.97MB → 23.8KB で全ページに効く）。

作業中に、書籍ページには既に <picture> + WebP の仕組みが入っていたのにトップだけが生の PNG を直接読んでいたことが分かり、そちらは既存の webp を指すだけで済んだ。

書籍ページ自体には手を触れていない。

起動スプラッシュから canvas を落とし、ヘッダー下とフッター上に敷いてあるのと同じ虹のライン 1 本だけにした。中央にサイトのアイコン、その下に LOADING、その下に虹の帯。

進捗の作り（実際の準備度に連動・0.92 で頭打ち・4 秒のハードタイムアウト・CSS 6 秒のフェイルセーフ）は一切触っていない。

差し替えたのは絵だけ。

「ブラックホールにこだわらず、サイトデザインに合ったものにしてほしい」という指摘。ブラックホールは Synapse Link という 1 プロダクトの絵であって、nzw.jp の看板ではない。

サイト全体で共有している視覚要素は虹のラインのほうで、これは既に全ページのヘッダーとフッターに敷かれ、デザインシステムにも .nzw-rainbow-line として載っている。

起動時にそれを見せれば、ページが出た瞬間にヘッダー下の同じ帯へ視線が繋がる。

boot-splash.js が 406 行 → 214 行。層 1〜7 の描画・飲み込み・白フラッシュがまるごと不要になり、毎フレームの仕事は transform: scaleX() の書き込み 1 回だけになった。

幅ではなく transform で伸ばすので、進捗が動いてもレイアウトを作り直さない。

下の「白背景では RGB 合計 17 しか変えていないのに 1 フレームの 75ms を占めていた」という問題は、間引きではなく絵そのものを差し替えたことで消えた。

トップに起動スプラッシュを置いた。

描画は Synapse Link の _LoadingBlackHolePainter の 7 層をそのまま Canvas 2D へ移植し、フェーズ（load → hold 200ms → expand 600ms easeInQuint → 白フラッシュ 400ms）も原典どおり。

進捗は固定タイマーではなく実際の準備度に連動させ、0.92 で頭打ちにして ready のときだけ 1.0 へ詰める。表示はタブのセッション中 1 回だけ。

ページを速くしても、この規模だと待ちはゼロにならない。それなら白画面のまま黙って待たせるより、このサイトが何を作っている場所かを見せる時間に変えるほうがいい。

徘徊するブラックホールは既に移植済みだったので、同じ絵を起動時にも使えば説明が要らない。固定 2 秒にしなかったのは、速い回線で無意味に待たせたくないから。

逆に遅いときにバーが止まって見えないよう、シグナルが全部滞っても時間だけで進む項を入れた。毎回出さないのは、ページ内リンクで戻るたびに待たされるのが最も嫌われるため。

スプラッシュ自身が待ち時間を延ばしていた。ページのパースと 26 個のインライン script と同じメインスレッドを 60fps の rAF で奪い合うので、覆うつもりのものが原因側に回る。

画素で測ると、降着円盤（3 層 x 60 セグメントの加算合成）は白背景では最大でも RGB 合計 17 しか変えていないのに、1 フレーム 99.3ms のうち 75ms を占めていた。

加算合成は白に足しても飽和するだけなので、当然といえば当然だった。読み込み中は円盤を描かず、飲み込みが始まって背景が黒くなってからだけ描くようにし、canvas の更新自体も 30fps に間引いた。

見た目は前後で区別がつかない。
もう一つ、フェイルセーフの検証のほうが設計より重かった。

当初スクロールロックを html:has(#boot-splash:not(.is-done)) という CSS だけで持たせ、「外し忘れる class が無いから安全」と考えていた。

ところが JS を 404 させて試すと、is-done が付かないのでロックだけが永久に残り、ページがスクロール不能になった。

CSS 側のフェイルセーフは opacity と visibility しか戻せない。結局 overflow は JS が付け外しする形に変え、スクリプトが読めない場合はロックも掛からない、という非対称に倒した。

「CSS だけで完結するから安全」は、CSS で戻せない性質のものには通用しない。

徘徊ブラックホールの low プロファイル（粗いポインタ / 短辺 700px 未満 / コア 4 以下）で、ビューポート大の canvas を捨てた。

canvas 自体を本体ぶんの正方形まで縮め、位置は transform: translate3d() で動かす。絵は一切落としていない。

分割数も層数もぼかしも原典のまま。減らしたのは描き直す回数と、描く場所の大きさだけ。

以前このライブラリを最適化したとき、分割数や層を削る案は「見た目が損なわれるわりに 1 秒あたり 45ms しか稼げない」として却下してある。

その判断を今回もひっくり返したくなかった。

一方で、本体は最大でも 300px 角しか塗っていないのに、毎フレーム画面全体ぶんの clearRect と drawImage を回し、430x932 の端末で 6.4MB のバッキングストアを抱えていた。

位置の更新をコンポジタに渡せば、絵に一切触れずに費用だけ下げられる。

バッキングストア 6.4MB → 0.91MB、毎フレームの CPU 描画は「文字列比較 1 回とスタイル書き込み 1 回」になった。

副次的に、モバイルで URL バーが開閉するたび innerHeight が変わって走っていた全画面ぶんの再確保も no-op になった。

移植できなかったのは VOID タグだけで、画面基準のクランプが成り立たないため「画面端では本体の反対側へ折り返す」に変えた。

またこの変更で、デザインシステムのデモが canvas モード前提の _resize を上書きしていることが露見し、スマホで開くと壊れる状態だったので quality: 'high' の明示で塞いだ。

zerohalf.jp だけ standalone だった証明書の認証方式を nginx に寄せ、3 枚すべてを同じ方式に揃えた。

今後ドメインを足すときも --nginx と --cert-name の明示を必須とし、standalone は使わない。

2026-08-30 に zerohalf.jp が証明書失効で開かなくなった。失効は 08-25 で、5 日間気づかなかった。

原因は standalone が 80 番を bind できず更新に失敗し続けていたことだが、本当の問題は「同じサーバーの証明書なのに 1 枚だけ更新経路が違う」状態を放置していたこと。

方式が混在していると、動いている証明書を見て安心してしまい、壊れている 1 枚に気づけない。揃えること自体が監視の代わりになると考えた。

再発行後、certbot renew --dry-run が 3 枚すべて success。有効期限は 2026-11-28 まで回復した。

一方で、certbot が pip / apt / snap の 3 系統入りタイマーが 2 本並走していること、nzw.jp-0001 という未使用の重複証明書があること、retrieval.nzw.jp が DNS も SAN も欠けたまま設定だけ残っていることが判明し、宿題として残った。

更新失敗が誰にも通知されない点は、同日に期限監視（後述）を入れて塞いだ。

夜は必ず出していたのをやめ、時間帯ごとの抽選にした。朝・昼・夕は 1/3、夜は 1/2。

大きさも原典の blackHoleSizes から tiny / small / medium を等確率で引き、速度は表どおり大きいほど遅くする。

さらに z-index を 30 と -1 で往復させ、コンテンツの前後を行き来させた。

毎晩かならず同じ大きさで同じように横切るものは、2 回目には目に入らなくなる。実際、実装直後に見たときの「何か動いている」という驚きが、翌日にはもう無かった。

出るかどうか・どの大きさか・手前か奥かが毎回変わるなら、見つけたときにだけ嬉しいものになると考えた。ずっと手前にいると読む邪魔になる問題も、同じ仕組みで解ける。

確率・サイズ・速度・奥行きの入れ替わりをヘッドレスブラウザで実測して検証した（抽選 2000 回で 0.32〜0.36 と 0.52、速度は表と 1% 以内で一致）。

副産物として、classList.remove() が属性を無条件に書き直すことに起因する MutationObserver の無限ループを検出でき、公開前に潰せた。

No.02「おつかれ！アクリルキーホルダー」を追加し、トップのヒーローでは No.02 を No.01 より前に置いた。

No.01（いくぞ！）を下げるのではなく 2 枚並べ、カルーセルは 7 枚から 8 枚に増やしている。絵柄は「おつかれ！」「山頂達成！」の文字が先に読める配置で、キャラクターは言葉の下に置いた。

No.01 は「準備は雑だけど、とりあえず行く」という自分に向けた絵だった。実際に持ち歩いてみると、人に見せたときに反応が返ってくるのは絵柄ではなく文字のほうで、キーホルダーは「自分の気分の表明」より「相手に言う一言」として機能していた。

2 点目は最初からその用途で設計したほうが素直だと考え、のぼり切ったあとをねぎらう絵にした。トップで新しい方を先に出したのは、グッズ導線が 1 本しか無い以上、最新でないものが先頭にあると「更新が止まっている棚」に見えるため。

ラインナップは .goods-card を 1 枚、詳細は .item を 1 ブロック足すだけで済み、goods.css は 1 行も触っていない（.item + .item の区切り線がそのまま効いた）。

ひとつ前の goods の項に書いた「2 点目以降はカードを複製するだけ」という想定は、実際に成立した。

No.02 の商品写真はキーホルダーがど真ん中に写っていて、そのまま全面に敷くと左に置く文字と重なった。

トリミングでも右に寄せられないため、写真の左端（ピントの外れた山と空）を反転して横に引き伸ばし、画面そのものを左へ拡張した 1800x1004 を書き出して使っている。

さらに最小幅では横に切ると 2 体のうち片方が必ず欠けるので、上に空を足した縦位置（900x1200）を <picture> で出し分けた。

候補は「文字を右に逃がす」「写真を小さく置く」「画を広げる」の 3 つ。前 2 つは No.01 のパネルと作りが変わり、同じ棚の商品が別レイアウトで並ぶことになる。

元の背景がもともとボケているので、引き伸ばしてぼかしても嘘にならないと判断した。反転してから引き伸ばせば継ぎ目の色が完全に一致するので、合成跡が出ない。

被写体が幅の 67% に来て、既存の scrim（左 0.90 → 右 0.00）をそのまま使い回せた。CSS はクラス名を .goods2-* に変えただけで、パネルの構造は No.01 と同一。

写真の都合でレイアウトを変えないという形に落ち着いた。

アクリルキーホルダーを作ったタイミングで /goods/ を新設し、トップのヒーローと Labs & Prototypes の両方から導線を張った。

EC・カート・価格表示は一切作らず、ステータスは「試作 / 構想」の 2 段階だけを持たせている。配布・販売の可能性は残すが、決まるまでは「未定」と明記する。

キーホルダーは 1 個しか手元になく、売る算段も配る算段も無い状態で出来上がった。この段階で「SHOP」を名乗ると、買えないものを並べた店になって信頼を落とす。

一方で置き場所を作らないと、アプリや書籍の副産物として生まれたキャラクターがどこにも残らない。「作ったものの延長線上にある記録」という枠なら、売れる前でも嘘にならないと判断した。

ページは静的 HTML（本番は nginx が直接配信）で高速に見せつつ、トップのカードは /v1/content-cards API から公開中のものを動的注入。

API 停止時は静かにスキップして静的閲覧を維持する。