Figmaに移行してからまだ日が浅いんですが、Figma MCPを使ってClaude Codeと一緒にコーディングを進めるのは、もうすっかり当たり前になってきました。
ただ実際に手を動かしていると、AIとの分業が進んだからこそ気づく「地味なギャップ」もいくつかあって、今日はその中でも、実装してみて初めて「あれ、思ってたのと違う」と感じた場面を、ゆるっと書いてみようと思います。
放っておけない類の話です。
どちらも派手な不具合ではなく、放っておいても誰かに怒られるような話ではありません。ただ、気づかずに数をこなしていると、じわじわ地味な手戻りが積み重なっていくタイプのギャップだと感じています。
要素の間隔をそのまま数値化すると、余白が広く見える
最初に気づいたのは、コーディングしてもらったページをブラウザで開いたときでした。
パッと見て「なんか間延びしてるな」という違和感があって、Figma側と並べて見比べてみたところ、要素同士の間隔そのものは指示した数値通りなのに、実際の見た目の余白はそれより広く見える、という状態でした。
FigmaでもXD時代でも共通して便利だったのが、要素と要素の間隔を測れる機能です。
Figma MCP経由でこの数値をClaude Codeに渡すと、そのままmarginやpaddingの値としてコーディングしてくれます。数値を目視で拾う手間が減るのは、素直にありがたいです。
ただ、この「そのまま数値化してくれる」便利さが、今回はちょっと裏目に出ました。
皮肉なものです。
原因を辿っていくと、テキスト要素の見た目上の高さにすでに含まれていたline-height分の余白。
💡 Tips: line-heightとは
テキストの行の高さを指定するCSSのプロパティです。文字そのものの大きさより広めに設定するのが一般的で、その分、テキストの上下には見えない余白が自動的に生まれます。
テキストって、文字そのものの大きさより一回り大きい「行の高さ」の分だけ上下に見えない余白を持っていて、文字がぎっしり詰まっているように見えても、実際のテキストボックスの外枠はline-heightの分だけ広がっているんですよね。
盲点でした。
Figma上で計測した「要素と要素の間隔」は、あくまで見た目のピクセル数です。でもその数値には、テキストのline-height由来の余白がすでに半分ほど含まれています。
そこにさらにmarginやpaddingを同じ数値で足してしまうと、line-height分が二重にカウントされて、実装した余白がデザインより広く見えてしまう、という理屈でした。
Claude CodeはFigmaから取得した数値をそのまま忠実にコーディングしてくれるので、この「数値には見えない余白が混ざっている」という前提までは汲み取ってくれません。
当然です。
以前書いたFigma MCP×Claude Codeの記事では、コーディングルールを事前に渡しておくことの大切さを取り上げましたが、今回のズレはそれ以前の話でした。
順番が違いました。
そもそも「Figma上の数値が、そのまま実装の数値にはならない」というデザインツール側の仕様を、自分自身がちゃんと言語化できていなかったのが原因です。
最終的には自分の目でブラウザ表示とFigmaを見比べて、広く見える箇所がないかを確認し、line-height分を差し引いて微調整する、という一手間が必要でした。
XDなら一瞬だったのに、Figmaだと地味に手間な操作
操作面でも、XDとの違いに戸惑う場面がありました。
XDだと画像やアイコンの書き出しはCmd+E一発で完結していたんですが、Figmaには同じような単発ショートカットが見当たりません。
「画像を選択→メニューからエクスポートを開く→倍率や拡張子を選ぶ→エクスポートを実行」という手順を毎回踏む必要があって、地味に手間が増えました。
面倒です。
1つのアイコンだけならまだしも、ページ内に書き出したい画像が何個も並んでいると、この手順をその枚数分繰り返すことになるので、体感の作業時間もじわじわ伸びます。
地味だけど、確実に効いてくる差。
グラデーションの色を拾うときも同じような感覚があって、グラデーション編集パネルを開いて、各ストップを1つずつクリックしながら数値を確認していく必要があり、こちらもひと手間かかる印象でした。
まだ移行して間もないので、単純に自分が慣れていないだけの部分もあるとは思います。
それはそうです。
とはいえ、XD時代との比較でいうと、今のところ地味に面倒に感じる場面の方が多いです。
移行コスト、侮れません。
要素間の間隔をAIに渡せば数値通りに実装してくれる、というのは間違いなく便利になった部分です。
ただ、その数値の「意味」まで含めて解釈するのはまだ人間側の仕事なんだな、と実感しました。
AIがどれだけ数値を正確に拾ってくれても、その数値が何を意味しているデザインなのかを翻訳するのは、結局のところ自分の役目なんですよね。
まとめ
今回気づいた「line-height分の余白の二重取り」も、「XDと比べたときの操作の手間」も、どちらも派手な失敗ではなく、実装を進める中でじわじわ気になってくる類の話でした。
Figma MCP自体はコーディングの初速をかなり上げてくれる仕組みですが、便利になった分だけ、数値の裏側にある意味を確認する人間側の役割がむしろはっきりした気がします。
地道な仕事です。
Figmaへの移行はまだ途中なので、また新しい気づきがあれば追記していこうと思います。
この記事が参考になったら、応援クリックをお願いします
