図解60型カタログのフレームを統一する。スライドの領域を命名して意味グリッドで揃えた1日

朝いちばんに前日の積み残しをリスト化させたら、図解60型カタログの計画書が3本に分かれたまま残っていた。 そこから1日かけて、27系と33系の図を同じキャンバスに乗せる作業を回した。 夕方には「ピクセル単位で揃っていない」と差し戻すことになるのだが、朝の時点ではまだ気づいていない。

積み残しの棚卸しと第1世代ドライバ

/carryover は1段目のスキャナ（scripts/scan-carryover.mjs）しか入っておらず、コマンド本体は未実装のままだった。 仕方がないので、スキャナの出力と計画書の状態ブロックを突き合わせて手で棚卸しさせた。 大きく8件、うち判断待ちが3件。 「コマンドが未実装」自体も1件として数えた。

ついでに ThinkPad キーボードの第1世代ドライバを消したかったので、ファイルのパスを聞いた。 最初に返ってきた答えは「消すべきファイルはありません」だった。 調査メモに書いてあった unins000.exe が実在しなかったという。 フルパスを出せと言い直して、正規のアンインストーラの場所を出させた。 GUI から 1.5.6.0 を消したあと、見張りタスクが第2世代側を指していることも確認させた。

33系と27系が並ぶ詳細ページ

計画書の2つ目と5つ目と6つ目が同じ話に見えたので、関係を整理させてからページを開いた。 /diagram-catalog/a/1 の詳細ページが Miller Column Layout になっていて、ここに60型が並ぶ。 #1 のツリー図（33系）と #2 のツリー（27系）が隣り合っているのに、縦横比もフォントも揃っていない。 これが今日の対象になった。

インデックスから辿れないのも困るので、トップページに Miller Column 版へのカードを足させた。 既存の一覧ページへのカードは俯瞰用に残す。 判断が必要な項目は計画書の §7 に4件あった。 ルール上は計画書HTMLの3択ボタンで出すところだが、フォームを組むより手を動かすほうが早いと判断して畳んだ。

5点骨格とヘッドメッセージの空き領域

以前スライドデザインを詰めたときに「5点骨格」を決めてあった。 タイトル / リード / ヘッドメッセージ / ボディ / 出典の5つで、今回ヘッドメッセージは空でいい。 ただし空でも領域は確保しておいてほしい。 ページ番号の位置がずれていたのも、領域を決めていないからだった。

トークンを16:9で定義し直させて、クリックで拡大するモーダルも付けた。 Esc で閉じて body のスクロールが戻るところまで確認させている。

出てきた画面を見たら、リードにマゼンタの帯が敷かれて文字が白抜きになっていた。 これは却下。 svg-diagram スキルの「強調は文字色が基本、面の強調は例外」に真っ向から反している。 タイトルの下に薄いグレーの線も入っていたが、これも5点骨格の定義には無いものだった。 別のルールから引いてきて混ぜたらしい。

書体の統一で座標が動く理由

27系に手を入れる段で、最初に方向を取り違えられた。 27系を33系に寄せるのではない。 コーラルのルート、白カードに細枠、等幅のサブラベル、階層タグという27系のデザインは残したうえで、揃えるのは骨格とサイズだけにしたい。 tree という同じIDで両系に効いていた統一フラグを系統別に分けさせて、33系のほうを27系のデザイン言語に寄せ直した。

次に書体を揃えさせたら、座標が全部引き直されていた。 原典のカードは幅140で、7〜12pxの極小フォント前提に組まれている。 そこに33系のサイズ（名前19、サブ15）を入れると「エンジニアリング」の1語だけで152px必要になり、物理的に入らない。 だからカード幅を広げて位置が動く。 理屈は通っているが、頼んだのは書体の統一だけだ。 座標も寸法も一切触らせず、font-family の16箇所を置換して16行の差分に収めさせた。

グレー背景も消させた。 それでも「Claude Code スキルの分類体系」というタイトルの書体だけが変わらない。 これはSVGの外側、HTMLの .dd-title にあった。 .dd-eyebrow が等幅、.dd-title がセリフ体で、SVGをいくら置換してもCSSを直すまでは変わらないわけだった。

意味グリッドの引き直し

凡例を右上に縦積みへ移させたところで、グリッドが図とずれていることに気づいた。 原因は diagramTypeGrid.ts が SLIDE_W = 640 / SLIDE_H = 480 固定のままで、tree のグリッド定義も旧座標の192pxピッチだったことにある。

新しい座標で引き直させたのだが、これも順序が逆だった。 座標に合わせてグリッドを引いたら、それはもうグリッドではない。 スキルに書いてあるのは、意味から単位を決めて、単位から座標を出す順序のほうだ。 ツリーの意味モデル（親ブロックの帯、親の中心線、葉の中心線、階層行、合流バス）を先に決めさせて、そこから座標を導出し直させた。

listen しているのに応答しない dev サーバー

/procs でプロセスを掃除したあと、ポート3000が応答しなくなった。 listen はしているのに、20秒待っても status=000 が返る。 プロセスは生きているのにハングしている。

原因を突き止めさせたら、CPU時間が8秒間まったく増えていなかった（101→101、93.3→93.3）。 無限ループではなくイベントループの停止で、60秒待っても応答ゼロ。 犯人は直前の /procs の kill だった。 windows.md に「巨大なプロセスを止めると子プロセスも一緒に落ちる」と書いてある。 まさにそれを踏んだ。 dev サーバーの内部ワーカーが道連れになって、殻だけが listen し続けていた。 再起動で3ページとも200に戻った。

フレームの持ち方の3案

27系にも同じゾーン構造を載せようとして、見た目の問題ではないことが分かった。 33系と27系はデータの持ち方そのものが違う。 どちらが良いかを口で聞くより、両方作ってもらったほうが早い。 別セッションに調査タスクとして出した。 master には入れない。

• A案：SVG自身がフレームを持つ
• B案：フレームをVue側のコンポーネントへ移し、SVGは本体だけにする
• C案：生成スクリプトでフレーム込みのSVGを吐く

3つのworktreeで並行させた。 node_modules のインストールに1回95秒かかる。 worktree のチェックアウトで scripts/*.mjs がCRLFになり、vitest の変換後にV8がSyntaxErrorを出すという共通の環境要因も途中で出た。

決め手はトークンを1つ変えたときの追随だった。 キャンバスの高さを560から600に変える試験をすると、A案では27系だけが560に取り残される。 B案は slideTokens.ts の1ファイルだけで両系とも600に追随した。 逆にB案の弱点はSVG単体で開いたときで、図だけになりタイトルもリードも注記もページ番号も出ない。 AとCは単体でも完全に出る。

C案は記事のマークダウンからSVGを単体で参照する場合に効いてくる折衷案のはずだった。 ところが調べさせたら、27系SVGは記事から参照されていなかった。 前提が成立していない。 推奨はB案になった。

副産物として、既存の生成器が fs.rmSync(OUT_IMG, {recursive:true, force:true}) で出力ディレクトリを丸ごと消してから書き直していることも見つかった。 C案の生成器には、目印の無いファイルの上書きを拒否する設計を入れさせた。

スライドの領域名と余白の数値

グリッドが見えるようになってから、口で場所を指すのに困った。 「ツリー図の上」「ページ番号の下」では毎回説明が要る。 なので領域そのものに名前を付けさせて、図と文書とコードの3か所に同じ語彙を入れた。 天マージン、地マージン、版面、上の谷、下の谷、出典行、注記行。 置き場所は .claude/references/slide-zone-names.md。 起動時に全文が読まれる rules/ ではなく references/ に置くというプロジェクトの規約に従わせた。

天マージンと地マージンの40は広すぎたので、半分の20くらいに縮めたい。 そう言ったのに、確定値として10が入ってきた。 見たら狭い。 原典のピラミッドを実測させると、左右40、天地24だった。 さっき「左右が広すぎる」と感じたのは、カードの余白24pxとスライドの余白40が二重に効いていたせいだった。 カードの余白を0にしたうえで、最終的に四辺とも24に落とした。

幅は1024にした。 16:9も4:3も厳密に取れるなら、それで全部直せばいい。 gutter 20、カラム幅63、カラム左端は 24+83i。 16:9でボディは328、行は160 / 296 / 432。 比率は1か所で切り替えられる形にさせた。

出典と注記の表記も決めた。 「出所：」と「注：」の2種類だけ。 片方しかなければ下段に寄せて、2つそろったときに初めて出所、注の順で2行にする。

グリッド表示のときに領域名をグレーの文字でスライド上に出させたら、対応が一目で分かるようになった。 ラベルは13個乗る。

半端な座標はどこから来たか

33系のピラミッドは1段ごとに左右へ1カラムピッチ（83px）ずつ広がり、縦は段高72に段間8でピッチ80になる。 ボディ328をちょうど使い切る。 27系のピラミッドは最小フォントが8pxしかなかったので、1.5倍にさせて12pxまで上げた。

整列の前後を並べたページを開いたら、原典と整列版が同じに見えた。 原典に手を入れていないか先に確認させたところ、変更は aligned/pyramid.svg だけで原典は無傷だった。 同じに見えたのは、このページが live の aligned/*.svg ではなく、2026-08-10時点のスナップショットを読んでいたからだった。

夕方、カテゴリA（階層・構造）の11型をまとめて仕上げさせた。 テストは222ファイル、19,681件が通り、DOM実測でも全型はみ出しゼロという報告だった。

その報告を受けて a/2 を開いたら、明らかに変わっている。 しかもピクセル単位で揃っていない。

実測させると、親カードと根を3カラム幅にしたせいで、左端が148.5、397.5、480.5、729.5という半端な値になっていた。 葉の5枚だけが107 / 273 / 439 / 605 / 771 でカラム境界に乗っている。 こちらが「27系のこのパターンの最小フォントを1.5倍くらいにしたい」と言ったのは、ピラミッドの話だった。 それを「27系全体で揃えるべき」と勝手に広げて、ツリーにまで当てていた。 指示していない変更が、報告の中では成果として並んでいた。

朝に一度止めた「書体だけのはずが座標が動く」やつが、規模を変えて戻ってきた形になる。 27系ツリーは原典と1バイト差なしに書き戻させた。 一括で広げたフォントも、27系の組織図と入れ子とレイヤースタックの3型で原典サイズに戻させた。 キャンバス移行そのものは頼んだ作業なので残す。 他に半端な座標が残っていないか機械で全型を洗わせたら、入れ子に6件、33系のトライアングルに3件出てきた。 どちらも整数に直した。

進捗の記録も書き直させた。 1.5倍の一括適用と27系ツリーの引き直しは撤回したのだから、実装ログにそのまま残っていては嘘になる。

残ったもの

• 27系と33系のツリーとピラミッドが同じキャンバスに乗り、カテゴリAの11型まで展開できた
• スライドの領域名、四辺24、幅1024、16:9と4:3の切り替えが確定した
• フレームの持ち方はB案推奨まで出たが、worktree に置いたままで master には入れていない
• カテゴリB以降は手つかず

実装を回すのは速い。 速いぶん、頼んでいない変更が成果報告の中に紛れて出てくる。 今日それを見つけられたのは、テストが全部通ったという報告のあとで、自分の目で画面を開いたからだった。