Figmaの渡し方でAIコーディングの精度は変わる
この記事でわかること
先日、Figmaのデザインファイルを受け取ってコーディングする機会がありました。
渡されたのは .fig ファイル。Figmaから書き出したファイルです。URLではありません。
作業を進めるうちに、ひとつ気づいたことがあります。
同じデザインでも、渡され方によってコーディングの精度が変わる。
今回は実際に手を動かして分かったことを、失敗も含めて書いておきます。
.figファイルは、実は完全に読める
まず意外だったのがここです。
.fig ファイルはFigmaの独自形式なので「Figmaで開かないと中身は見えない」と思っていました。でも実際は違いました。
中身はただのZIPファイルです。展開すると、こういう構造になっています。
| ファイル | 中身 |
|---|---|
| canvas.fig | デザインの全データ（バイナリ） |
| images/ | 使われている画像すべて |
| meta.json | ファイル名・画面サイズなど |
| thumbnail.png | サムネイル |
このうち canvas.fig を解析すると、デザインの情報がほぼ全部取り出せます。
今回のファイルから実際に取れたものがこちらです。
- 画面サイズ 393 × 6464px
- 要素272個の座標・サイズ（小数点以下まで）
- 画像53点（元解像度のまま）
- テキストの実データ全文
- フォント名・文字サイズ・行間・字間
- 色（
#614d3cのような具体的な値）
つまり Figmaを開かなくても、デザインの数値は完璧に分かるということです。
ここまでは順調でした。
そして失敗しました
数値が全部あるので、あとは組むだけ。そう思って作業を進めました。
ところが完成後、ブラウザで表示して確認したところ、こうなっていました。
見出しの「News」という文字が、装飾の葉っぱイラストで完全に隠れていた。
座標は間違えていません。カンプ通りの位置に配置していました。それでも結果は「文字が読めない」状態でした。
原因は単純です。重なりの前後関係が分からなかったから。
デザインデータには「葉っぱは x=160 の位置」という情報はあります。でも「葉っぱは見出しの後ろに敷く飾り」なのか「見出しの横に置くアクセント」なのかは、数値だけでは判断できません。
もし完成イメージを見られていれば、一目で分かったはずでした。
なぜ見た目を確認できなかったのか
.fig ファイルにはサムネイル画像も入っています。だからそれを見れば良さそうなものですが、開いてみたらこのサイズでした。
24 × 395ピクセル。
親指の爪ほどの大きさです。何が描いてあるか判別できません。
結局、私は数値だけを頼りに組み立てて、レンダリングして初めてバグに気づいた、という流れでした。
.figファイルとURL、どちらが正確か
この経験から整理したのがこちらです。
| .figファイル | 共有URL | |
|---|---|---|
| 座標・サイズの正確さ | ◎ 完全一致 | ○ 整形される |
| 画像の質 | ◎ 原本のまま | ○ 書き出し依存 |
| 見た目の確認 | × ほぼ不可 | ◎ スクショで確認できる |
| アクセス権限 | ◎ 不要 | × 必要 |
数値の正確さだけなら .fig の勝ちです。Figmaが内部で持っているデータそのものなので、丸められることがありません。
それでも私の結論はこうです。
総合的にはURLの方が正確に作れる。
理由は、今回の失敗そのものです。数値が完璧でも、それが正しく組めているか確認できなければ意味がありません。
一番いいのは「両方」
とはいえ、URLには権限の問題があります。他社が作ったファイルだと、そもそもアクセスできないことも多いです。
なので現実的にはこうなります。
- URLを渡せるなら URLが一番いい
- 渡せないなら
.figファイル ＋ 画面のスクショ数枚
スクショはFigmaの画面をそのまま撮ったもので構いません。これが1枚あるだけで精度が変わります。今回それがあれば、葉っぱの件は最初から正しく組めていました。
ファイルの中身の整理も効きます
もうひとつ、渡し方で効いてくるのがファイル内の整理です。
Figmaには「Page」という機能があります。左サイドバーの上部にあるリストで、1つのファイルの中に複数のキャンバスを作れます。
ここが整理されていると、こう変わります。
| 整理されていない | Pageで分けてある |
|---|---|
| 1つのPageにトップ・コース・没案・旧デザインが混在 | Top / Course / Access / Components に分割 |
| どれが最新の正解か判断できない | 作る対象が一発で決まる |
混在していると「このボタン3種類あるけど、どれが採用版ですか？」という確認が発生します。その分だけ手戻りが増えます。
ちなみに1ページだけのファイルなら、Page分けは不要です。分ける意味が出てくるのは下層ページが増えてからです。
PC版とSP版は同じPageに並べる
レスポンシブ対応がある場合は、これが効きます。
今回のファイルには、見出しのコンポーネントにこういうデータが入っていました。
device=sp… 見出し30pxdevice=pc… 見出し40px
同じコンポーネントのバリアントとして定義されていたので、「見出しはSP30px→PC40pxに変わる」と即座に判断できました。CSSで書くとこうなります。
.blockTitle__en { font-size: 30px; }
@media (min-width: 768px) {
.blockTitle__en { font-size: 40px; }
}
もしPC版が別のPageにあって、別コンポーネントとして作られていたら、これが「同じ見出しの別サイズ」なのか「まったく別の見出し」なのか判断できません。
並べておくだけで、対応関係が構造として伝わります。
渡すときのチェックリスト
まとめると、こうなります。
| 項目 | おすすめ |
|---|---|
| 渡し方 | 共有URL（権限が渡せない場合は .fig ＋ スクショ） |
| ファイル構成 | 1サイト = 1ファイル、Pageでページ分け |
| PC/SP | 同じPageに横並び |
| 一度に依頼する範囲 | 1ページずつ |
| あると助かる情報 | ブレイクポイント、今回作る対象、無視していい要素 |
「まとめて作っておいて、渡すときは小分け」というイメージです。
ファイル全体を一度に読ませると情報量が膨大になり、今作っているページへの精度がかえって落ちます。今回はトップページ1枚だけで要素が272個ありました。5ページ分なら1000個を超えます。
おわりに
AIにコーディングさせる時代になって、「デザインデータの渡し方」が新しい論点になってきたな、と感じています。
人間同士なら「ここは飾りだから文字の後ろね」と一言で済むことが、データだけだと伝わりません。逆に言えば、その一言を添えるだけで精度が上がるということでもあります。
今回の私の失敗も、スクショ1枚あれば防げたものでした。
デザイナーさんとやり取りする機会がある方は、「Pageで分けてもらえますか」「PC版とSP版を並べてもらえますか」と伝えてみてください。Figmaを使う人には一般的な整理方法なので、特殊なお願いにはなりません。
その一手間が、あとの手戻りを減らします。
