X で毎日 Claude Code 情報を配信してるコムテです
既存サイトのリニューアル要件が入ったとしよう
Figma デザイン提出を求められた。しかし、一から既存サイトのデザインを再現するのは骨が折れる
自分が最初からデザインするならいいけど、元々あるサイトのデザインをこちらで完璧に再現して作っていくのは苦行である
なので、楽しよう。必要なのはこれ
- Claude Code のスキル
- Chrome DevTools MCP
- Figma MCP
- Claude in Chrome
- スタイルガイドライン
目視の往復が消えて、Figma 側が実装と数値レベルで揃うよ
Chrome DevTools MCP install
Figma MCP と Chrome DevTools MCP をインストールしておく
Figma は、デスクトップ版があるといいね
Chrome DevTools MCP は、Claude Code などの MCP クライアントから Chrome を操作するサーバ。一般には「ライブデバッグ・Lighthouse・スクショ」用途で知られてる
でも本命は別にある。evaluate_script で任意の JS を実サイト上で実行して、結果を JSON で返せることだ
ここが転用ポイントになる。重要なのは computed style を取る専用ツールが無いこと。少なくとも執筆時点では用意されてない
だから自分で getComputedStyle を流す。evaluate_script の中で実行して、欲しい値だけ JSON にして返す。これが実測の核になる
実サイトの寸法は目視でなく実測する
実サイトの寸法・色・フォントは目視でなく getComputedStyle で実測する。Chrome DevTools MCP の evaluate_script で測って、その数値を use_figma で Figma に反映する
これで合わせ込みが一発で決まる。スポイトで色を吸ったり、定規アイコンで測ったりする工程が消える
この記事では実測ワークフロー7ステップと、そのまま使える evaluate_script の実測テンプレを全部出す
use_figma とは
use_figma は Figma 公式 MCP の write-to-canvas ツール。Plugin API 経由で JS を実行して、ネイティブな Figma ノードを直接書き換える
スクショを貼り付けるのとは違う。サイズ・色・variables といった実構造を更新できるのが強い
ひとつ前提がある。書き込みは Figma の有料プラン＋Full seat が要る（Dev seat は読み取りだけ）。ベータ中で条件は変わりうるので、最新は公式を確認してね
なぜ目視じゃダメか
目視は誤差の温床になる。3つの理由で破綻する
- スクショの色スポイトは圧縮やディスプレイで誤差る
- アイコンの実寸・行間・border-radius は目で測れない
- レスポンシブで値が変わり「いつ測ったか」でブレる
目視で「だいたい合ってる」は、実装とデザインの乖離が静かに溜まる原因になる。数値で照合しないと気づけない
getComputedStyle と getBoundingClientRect の基礎
実測で使う2つの API を整理しておく
| API | 取れる値 | 主な用途 |
|---|---|---|
| getBoundingClientRect | レンダリング後の座標とサイズ | box の寸法・位置 |
| getComputedStyle | CSS の最終算出値 | font・color・border |
getComputedStyle は外部 CSS も反映した最終値を返す。だから実装の真の値が取れる
疑似要素は getComputedStyle(el, "::before") で取れる。アイコンを ::before で出してる実装はこれで中身を測る
実測ワークフロー7ステップ
ここが独自性の核になる。毎回この順で回す
- 対象セクションを決め、Figma ノードと CSS セレクタをメモする
- Chrome DevTools MCP で実サイトを開き、viewport を固定する（resize_page で 1920×1080 など）
- evaluate_script で box・style・::before を一括実測する
- styleguide のデザイントークンと照合する
- use_figma で Figma ノードに反映する
- 実サイトと Figma を並べて視覚比較する
- worklog に対象・実測値・反映内容を記録する
ステップ4の照合はこう判断する。トークンと一致したらトークン値を採用、特殊値なら実測値をそのまま使う
ステップ5は反映前に確認がいる。Figma 側に手動編集が入ってないか見てから、サイズ・色・font-size・line-height・border-radius・座標を流し込む
ステップ6でズレたら③〜⑤を繰り返す。ここを面倒がらないと精度が上がる
viewport を固定するのが地味に効く。固定しないとレスポンシブで値が動いて、測るたびに別の数字が返ってくる
実測テンプレ
evaluate_script に流す JS はこれを使う。対象セレクタだけ差し替える
これも一例だから、いい感じにアレンジしてくれ
一点だけ制約がある。返り値は JSON シリアライズ可能にする。DOM ノードや関数をそのまま返さず、必要な値を文字列や数値に落として返す
色は rgb(...) の文字列で返ってくる。HEX が欲しいときは受け取り側で変換する。border のようなショートハンドは空文字が返ることがあるので、longhand で取るのが確実だ
styleguide でブレを固定する
実測値はそのまま使うと危うい。14px のつもりが 13.98px で返ったり、似た色が微妙に違う値で散らばる
そこで styleguide を1枚用意する。既存サイトの CSS から設計トークンを抜き出した、Figma とコーディングの共通基準である
ここで大事なのは、新しくデザインを設計しないこと。あくまで既存サイトに出てくる値をそのまま拾ってトークン化する。だから「このスケールは妥当か」みたいな議論は起きない。サイトの実態がそのまま正解になる
中身はサイトごとに変わるけど、拾う項目はどこも同じ
- 文字サイズ: 出てくる font-size を一覧化して用途を振る
- 行間: line-height の種類を絞る
- 色: 役割ベースのトークンにする
- 角丸: border-radius を用途ごとに数種類へ固定
色だけは役割で名前を付けると効く。実装の意図が名前で分かるようにする
| トークン | 役割 |
|---|---|
| text | 本文の文字色 |
| primary | 主色（リンク・アイコン・枠線） |
| accent | 強調 |
| border | 区切り線 |
具体値はサイトから実測した値で埋める。HEX もサイズもサイト依存なので、ここでは決め打ちしない
ここまで作ると、ステップ4の照合が効いてくる。実測値がトークンに一致したらトークン値を採用、外れ値だけ特殊値として実測値を残す
端数や1色のブレは、styleguide に snap させた瞬間に消える。実測の精度を、設計の一貫性で受け止める形になる
つまずきポイントと対処
実際に回すとここで詰まる。対処をセットで置いておく
色はそのまま使えない。getComputedStyle が返す rgb を HEX に変換すれば正確に揃う。スポイトの目視と違ってディスプレイ依存がない
アイコンは特に厄介だ。フォント版のアイコン（FontAwesome 等）はテキストでなく ::before の擬似要素で描かれることが多い。だから ::before の font-family・font-size・color を測れば実寸が取れる。SVG 版だと ::before が空になるので、その場合は background-image や子の svg を見る
viewport は必ず固定して測る。固定しないと同じ要素でも別の数字が返る
Figma にフォントが無い時もある。その場合は styleguide の代替フォントに置換して、実装値はコメントか worklog に残す。値を捨てずに記録するのが後で効く
プライベートな実サイトの値を扱うときは、クライアント名や URL を成果物に残さない。worklog にも一般化した記述で書く
スキル化して再利用
この7ステップは一度きりで終わらせない。Claude Code のスキルにして毎回呼ぶ
design-tune のような名前でスキル化すると、対象セレクタを渡すだけで実測から反映まで回せる。手順を毎回思い出さなくていい
再現可能な資産になるのが大きい。属人化したコツを、いつでも呼べる形に固定できる
スキル（一例）
例えば、.claude/skills/design-tune/SKILL.md に以下のようなスキルを作る
これは一例だから、君の要件に合うようにアレンジするといいね
終わりに
debug 用と思われてる Chrome DevTools MCP は、実測ツールに化けるね
evaluate_script で getComputedStyle を流すだけで、実装の真の値が JSON で返る
その数値を use_figma で Figma に焼き込めば、合わせ込みは目視を卒業できる
