Figma Makeのローカルコードを開こうとしても、Mac版アプリや利用資格の条件で作業が止まっていませんか。
まずアカウントの利用資格、Mac版Betaアプリ、リポジトリ権限を確認してください。条件がそろえば、リモートMacで既存ウェブ画面を修正し、ブランチからPRへ進められます。変更は必ずチームの審査に回します。
対象は、利用資格を得て既存画面を直したいデザイナー、Windowsを主な作業端末とする協力者、レビュー責任を持つエンジニアやプロダクト担当者です。新規アプリ開発やバックエンド構築の手順ではありません。
最終更新：2026年10月7日。確認先はFigma公式のベータ機能案内、ローカルコードの設定・トラブルシューティング情報です。利用条件は変わる可能性があるため、作業開始前にも公式のベータ機能一覧を確認してください。
作業前の利用条件とタスク範囲
Figma Makeのローカルコード機能は、すべてのアカウントに常時使える一般提供機能ではありません。公式案内では段階的に開放されるベータ機能として扱われ、利用には対象アカウントとMac版Betaデスクトップアプリ、対象リポジトリへのアクセスが必要です。Figmaの機能紹介とローカルコード設定ガイドで、開始前に最新条件を照合します。
利用資格がなくても、リモートMacを用意すれば使えますか。
いいえ。リモートMacはMac環境を用意する方法であり、Figmaの利用資格を付与するものではありません。アカウントが対象外なら、資格が確認できるまで既存のデザイン確認やチームへの修正依頼に切り替えます。
| 開始前に確認する項目 | 作業開始の条件 | 条件がそろわない場合 |
|---|---|---|
| アカウント | ローカルコード機能の利用対象である | Figma公式の案内を確認し、対象になるまで待つ |
| Mac環境 | Mac版Betaデスクトップアプリを利用できる | 対応するMac環境を用意する。リモート利用時はアプリの提供状況も事前確認 |
| コードとチーム | 対象リポジトリへのアクセスがあり、レビュー担当者が決まっている | エンジニアにアクセス権と担当範囲を確認する |
今回の対象は、既存ウェブプロジェクトの小規模な画面調整です。新しいアプリの立ち上げ、サーバー構築、認証やデータ処理などのバックエンド変更は別の技術判断が必要です。画面の見た目だけを頼りに、変更範囲を広げないようにします。
注意：ベータ機能の対象アカウント、対応アプリ、提供範囲は固定とは限りません。過去に使えた場合でも、今回のアカウントと作業環境で再確認してください。
リポジトリの権限とPR経路
リポジトリは、画面のコードや関連ファイルをチームで共有する保管場所です。ブランチは、共有中の本流を直接変更せずに作業するための分岐です。作業開始前に、対象プロジェクトの読み書き権限と、レビュー担当者が求めるブランチ運用を確認します。
Figma公式の設定案内ではGitHub、GitLab、Bitbucketを扱いますが、PRの操作場所は同じではありません。GitHubはアプリ内でPRを作成できる機能が案内されています。一方、GitLabとBitbucketでは、それぞれのサービス上でPRに相当するマージリクエストを作成します。GitLabの作成手順とBitbucketのPR手順も確認してください。
| リポジトリの場所 | 変更の共有とPR作成 | デザイナー側で確認すること |
|---|---|---|
| GitHub | Figma MakeからPRを作成できる場合がある | アプリ内に表示される対象ブランチとPR情報を確認 |
| GitLab | 変更を共有した後、GitLab上でマージリクエストを作成 | 作業ブランチ、変更内容、作成先プロジェクトを確認 |
| Bitbucket | 変更を共有した後、Bitbucket上でPRを作成 | レビュー担当者と対象ブランチを確認 |
既存のGitHubコードをつなぐには、何を先に準備しますか。
まずエンジニアに、対象リポジトリのアクセス権、プロジェクト固有の初期設定、起動に必要な手順を確認します。Figma側の接続でエラーが出たときは、画面編集を疑う前に、権限とリポジトリの設定を切り分けます。設定時の注意点はFigma公式のトラブルシューティングも参照してください。
Macアプリで開き、対象画面を確認
準備ができたら、Mac版アプリで対象プロジェクトを開きます。ローカルにあるリポジトリを接続する方法と、リモートにあるリポジトリを複製して開く方法があります。画面が表示されても、意図したコードのプレビューとは限らないため、対象ページとプロジェクト名を照合します。
WindowsからリモートMacを使って作業できますか。
Mac版Betaアプリがその環境で利用でき、Figmaの資格とリポジトリ権限がそろう場合に限り、作業候補になります。サービス側で必要なアプリを利用できるか、プロジェクトをどう開き、変更ファイルをどう受け渡すかは個別に確認します。ここでは、MESHLAUNCHの特定環境でのアプリ利用可否や動作を実測したとは扱いません。
| 接続方法 | 向いている状況 | 確認点 |
|---|---|---|
| ローカルリポジトリを接続 | Mac環境に対象プロジェクトがすでにある | 開いているフォルダーが作業対象と一致している |
| リモートリポジトリを複製 | 対象コードをこれからMac環境に用意する | アクセス権、複製先、プロジェクトの起動手順が分かっている |
プレビューが起動しない場合は、依存ファイルの準備、開発サーバーの起動方法、アクセス権を順に確認します。エラーが出たからといって、デザイン修正が失敗したとは限りません。プロジェクト固有の手順が不明な場合は、工程担当者に起動方法を確認してから続けます。
小さな画面変更と差分確認
最初の変更は、対象がはっきりしていてレビューしやすいものに絞ります。たとえば余白、文字サイズ、ボタン配置など、依頼内容とプレビューを照合しやすい範囲です。属性パネルや画面上の注釈、自然な言葉での指示を使った場合も、生成されたコードがデザインシステムに沿うとは限りません。
変更後は、プレビューとコード差分の両方を確認します。対象外のファイルまで変更されていないか、既存コンポーネントや共通スタイルに影響していないかを見ます。Figmaの紹介するワークフローも、変更をそのまま公開してよい保証ではありません。公式のワークフロー事例を参考にしつつ、チーム内の確認手順を優先してください。
ブランチからチームレビューへの引き継ぎ
作業内容を共有する前に、変更を独立したブランチにまとめます。コミットは、その時点の変更を記録する単位です。後から何を変えたか確認しやすいよう、画面の目的に沿って内容を整理します。
変更後に、アプリから直接公開してもよいですか。
いいえ。PRはチームに変更を提案し、レビューを受けるためのものです。テスト機能がコードを変更したりPR作成を助けたりしても、コードレビューやチームの公開手順を代替しません。GitHubでも、PRの内容をレビュー担当者が確認するプロセスが案内されています。GitHubのレビュー手順に沿って、責任者の確認を受けます。
作業完了前に、次の項目をチェックしてください。
- [ ] 変更が依頼された画面と範囲に収まっている
- [ ] プレビューと実際のコード差分を照合した
- [ ] プロジェクトで必要な確認を、工程担当者と合意して実行した
- [ ] 変更を作業ブランチにまとめ、コミット内容を確認した
- [ ] GitHubではアプリ内、GitLab・Bitbucketでは各サービス上のPR作成経路を確認した
- [ ] エンジニアにブランチ名、変更概要、未確認事項を引き継いだ
条件別の進め方と環境選択
- 利用資格、Mac版Betaアプリ、リポジトリ権限がそろっている場合は、既存ウェブ画面の小規模修正から始めます。
- Windowsが主端末で、必要なMacアプリを使える遠隔環境を確認できる場合は、リモートMacを候補にします。接続方法とファイル受け渡しは契約前に確認します。
- 利用資格がない場合は、リモートMacを契約しても解決しません。資格が確認できるまで、通常のデザインデータでレビューを依頼します。
- 毎日長時間使う、物理ポートが必要、常時同じ端末で作業する場合は、自分でMacを用意する選択も比較します。Mac miniの購入情報は、継続利用を検討する際の比較材料になります。
- バックエンドやインフラの変更が中心なら、デザイナー主導の画面修正フローでは進めず、担当エンジニアに作業範囲を移します。
Windowsだけで進める場合はMac版Betaアプリの条件を満たせず、同僚のMacを借りる方法では利用時間やファイル共有の調整が必要です。Macを購入すれば自由度は高まりますが、短期の画面修正のために端末を確保する負担も残ります。資格とリポジトリ権限がすでにあり、Macアプリが利用できることを確認できたなら、必要な期間だけMESHLAUNCHのリモートMacを比較する方法もあります。まずはMESHLAUNCHの案内で利用環境を確認し、資格取得やコードレビューまで解決できると誤認せず、チームの承認フローを維持してください。