Figma Code Layersのプロトタイプは、操作や画面状態を確かめるために使い、画面上で動くことだけで本番コードやブラウザー対応まで検収済みとは判断しないでください。開発へ渡す前に、状態の抜け、GitHub上の変更、対象ブラウザーを確認し、Safariが要件に含まれる場合だけMacでの確認を検討します。
対象となるのは、Figmaのデザインをコード原型にして、開発前に見た目や操作を確認したいUI・プロダクトデザイナーです。
空状態やエラー状態までレビューしたいプロダクト担当者、原型とリポジトリの責任範囲を整理したい小規模チームにも役立ちます。
最初に決めるのは、原型で合格とする範囲です
Figmaの説明では、Code LayersはFigma Designのキャンバス内でコード駆動のインタラクティブなプロトタイプを作る機能です。Figmaのヘルプでは公開ベータとして順次提供中と案内されています。利用資格や画面上の機能は変わり得るため、作業開始前にCode Layersの公式ヘルプと最新の製品更新履歴を確認してください。
ここでの検収対象は、現在動かせるプロトタイプが設計意図を伝えられるかどうかです。実際の製品に必要なデータ処理、権限、エラー処理、各ブラウザーでの品質まで保証するものではありません。まず「デザイン方向の確認」「操作のレビュー」「開発への説明」のどれを目的とするか決め、目的外の項目は未確認として残します。
| 確認したいこと | Figma Code Layersの原型で確認する範囲 | 別途必要な確認 |
|---|---|---|
| 見た目と画面の流れ | 原型上で表現されたレイアウトや操作 | 実装後の表示、実データでの崩れ |
| 状態と操作 | 作成済みの操作経路や状態 | 未実装の状態、異常時の挙動 |
| コードの変更 | GitHub連携で扱うファイルや変更内容 | チームのレビューと本番向け品質判断 |
| ブラウザー対応 | 実際にプレビューできる環境での確認 | 対象ブラウザーごとの動作確認 |
視覚の検収では、代表画面と差分を記録します
最初に、レビューで判断材料になる代表画面を選びます。画面を一枚だけ静止画で見比べるのではなく、主要なページを実際に開き、見出し、本文、ボタン、余白、コンポーネントの順序がデザイン意図と合っているかを確認してください。
差があれば「雰囲気が違う」で終わらせず、画面名と差の内容を記録します。例えば、文字の折り返しでボタンが押し下げられる、長いラベルが枠からはみ出す、視線を集めたい要素より補助情報が目立つ、といった形です。Figmaのデザインから自動的に無損失で変換される保証ではなく、検収するのは現在実行できる原型の表示です。
色のコントラストも、見た目の印象だけで合否を決めない項目です。WCAG 2.2の通常テキストの最低基準は4.5:1、大きな文字は3:1です。数値はW3Cのコントラスト基準に基づきます。基準に達していない場合は、画面上の色の組み合わせを記録し、デザイン側で修正が必要か確認します。
操作と状態は、成功経路だけで閉じません
ボタンやリンクを一度押して画面が変わることは、操作をひと通り検収できた証拠にはなりません。利用者が最初に見る画面から主要な完了画面まで進み、戻る操作、入力のやり直し、失敗時の表示など、レビューの目的に必要な状態を確認します。
空状態、読み込み中、エラー状態は、原型に表現されていないこと自体も確認結果です。未作成の状態を「問題なし」と扱わず、誰が判断するかを添えて未確認項目に残します。コード原型を見せる場では、この区別がないと、単なるデモの成功が実装要件の合意として受け取られるおそれがあります。
原型に表現されていない挙動は、推測で合格にせず「未確認」と記録します。レビューで合意できた範囲と、開発時に決める範囲を分けてください。
画面幅と内容の変化を、実際の利用条件で試します
レスポンシブ表示は、特定の幅で一度開いただけで全端末への対応を判断できません。製品が対象とするウィンドウ幅や、実際に入り得る長い見出し・入力値を使い、要素の重なり、横方向のはみ出し、予期しない改行を確認します。どの幅を試すかはプロジェクトの要件から決め、確認していない幅やブラウザーにまで結果を一般化しないでください。
Safariのレスポンシブデザインモードは、Safari上で表示を切り替えて確認するための手段です。利用できる機能や操作はWebKitの説明を参照し、実際の対象環境に合わせて選びます。画面幅の確認とブラウザー互換性の確認は別の検収項目です。
GitHub連携は、変更の承認と切り分けます
GitHubリポジトリを使う場合は、まず対象リポジトリとブランチを特定します。FigmaのGit連携に関する説明を確認したうえで、変更されたファイルと、その変更が原型のどの画面・操作に関係するかを照合してください。
次に、比較画面で差分を見て、チームのレビュー手順へつなぎます。GitHubではコミット間の比較で変更を確認でき、Pull Requestのレビューでレビュー担当者が内容を確認できます。保護ブランチを使うチームでは、ブランチ保護の設定も承認条件に関わります。
これらの機能は、変更を確認・レビューするための仕組みです。Figmaとの接続やPull Requestの作成だけで、変更が本番コードとして承認されたり、そのままマージ可能になったりするわけではありません。
レビュー記録は、次のように画面名、条件、結果、次の担当をひと続きで残すと、未確認事項を引き継ぎやすくなります。
画面：
確認条件：
確認した操作：
見つかった差分：
未確認の状態：
次の確認担当：
FAQ：原型の引き渡しと確認環境
Figma Code Layersの原型は、そのまま開発へ渡せますか？
操作や画面の意図を伝える素材としては渡せます。ただし、本番実装の品質確認とは分け、未確認の状態、実装が必要な要件、コード変更のレビュー担当を添えてください。
Code Layersで操作状態を確認するには、どこから始めますか？
主要な操作経路を起点からたどり、成功後の画面に加えて空状態、読み込み中、エラー時の表示も確認します。原型にない状態は未確認として記録し、実装時に誰が判断するかを明確にします。
Safariでの確認が必要なプロジェクトには、何を用意しますか？
Safariが製品の対象ブラウザーに含まれる場合、またはSafari固有の表示を確認する要件がある場合は、Safari上で対象ページを確認します。別ブラウザーの結果だけで互換性を推定せず、必要ならMac環境を用意します。
GitHubに接続した後、変更内容をどう確認しますか？
対象のブランチを確かめ、コミットの比較で変更ファイルを確認します。Pull Requestがある場合はチームのレビュー規則に従い、承認前の変更を本番向けの検収済みとして扱わないようにします。
ブラウザーの検収は、要件にある環境で行います
手順は、まず対象ブラウザーを製品要件やサポート方針で確認し、次に同じ画面・操作をその環境で開くことです。そのうえで、文字の表示、レイアウト、主要操作に差がないか記録します。Safariが対象外で、Mac固有の確認要件もなければ、確認のためだけにMacを用意する必要はありません。
WindowsとFigmaのプレビューだけではSafariの実表示を直接確認できず、別ブラウザーの結果を代用すると差分を見落とす可能性があります。一方、Macへのリモート接続で画面が遅く感じられる場合も、それはブラウザー互換性とは別の問題です。遠隔操作の体感だけで、ページの表示品質を合否判定しないでください。
検収の記録を残してから、開発へ引き継ぎます
最終的には、確認した画面、操作、画面幅、ブラウザー、GitHubの変更、未確認項目をひとつの引き継ぎ記録にまとめます。項目に抜けがあれば「合格」とせず、担当者と次の確認場所を決めてから開発チームへ渡します。
WindowsとFigmaだけの確認は、Safariの実表示を直接確かめられないこと、別環境の結果を推定に頼りやすいこと、ブラウザー差分を再現できないことが弱点です。反対に、Safari確認が要件にない、またはMacを継続的に使う場合は、手元のMacを用意するほうが適切なこともあります。必要な期間だけSafariを確認したい場合は、NodeMiniのMac利用方法を確認し、週・月・季の利用が検収期間に合うか比較してください。購入前に機種情報も調べる場合は、Mac miniの案内も参照できます。
最終更新：2026年10月18日。Code Layersの公開ベータ状況はFigmaのヘルプと製品更新履歴で、GitHubの作業範囲は公式のGit連携説明で確認しています。Safari確認が必要な場合に限ってMac環境を選び、短期間の検収ならレンタルも比較対象に加えてください。