2026年5月28日、Figmaはローカルコード編集、コメント、チャット、Pull Request作成をMac Betaデスクトップアプリから提供すると公式発表しました。公式発表 から判断すると、原型、コメント、チーム確認が中心ならWeb版を使い、ローカルコードやPRまで扱うならMac環境を準備するのが今週の安全な選択です。Windowsユーザーは、まずリモートMacで代表案件を検証し、正式な開発では権限とツールチェーンを確認してください。
この判断は、Figma Makeで素早くインタラクティブな原型を作りたいWindows中心のプロダクトデザイナー向けです。原型をコードベースへ渡すデザインエンジニア、短期案件を抱えるフリーランサーや小規模チームも、担当する納品物に合わせて読み進めてください。
先に分けるべき2つの作業領域
Figma Makeには、デザインの文脈からインタラクティブな原型を生成・編集する領域と、ローカルのコードベースを扱う領域があります。Figma Makeの公式ヘルプ が説明するWeb上の原型作業は、共有リンクやコメントによるレビューと相性がよい機能です。
一方、2026年5月28日の公式発表では、ローカルコード、注釈、チャット、PR作成はMac Betaデスクトップアプリが先行対象です。将来ほかのプラットフォームへ広がる計画は示されていますが、Windowsで正式提供済みという意味ではありません。公式のローカルコード案内 と、ローカルコード連携のヘルプ を確認してから判断します。
したがって、「Figma MakeのローカルコードはWindowsで使えるか」という問いには、Webブラウザでの原型作業は可能ですが、Mac Betaデスクトップアプリを前提とするローカルコードの一連の流れまでWindows対応と見なすことはできません、が現時点の回答です。
注意：Mac Betaへの参加資格、アカウントの権限、チームのリポジトリへのアクセス権は自動で付与されるとは限りません。Macを用意しても、コードを開けることやPRを作成できることが保証されるわけではありません。
原型リンクを納品するデザイナー
画面生成、画面遷移の確認、コンポーネントの文脈付与、チームコメントが目的なら、Web版を第一候補にします。納品物が共有可能な原型リンク、レビューコメント、デザイン判断の記録であれば、ローカルリポジトリへ書き込む必要がないためです。
Figma Makeでは、原型に対してコメントを追加する流れも公式ヘルプに整理されています。コメント機能の説明 を基準に、レビュー担当者が必要な画面を確認できるかを先に見ます。WindowsのWeb版でここまで完結するなら、最初からリモートMacを契約する理由は弱くなります。
確認項目は次のとおりです。
- [ ] 原型を共有リンクとして開ける
- [ ] デザイン文脈を追加して画面を修正できる
- [ ] 主要な操作フローをレビュー担当者へ説明できる
- [ ] コメントと修正内容を同じ作業場所で追える
- [ ] 納品にソースコードやPRが含まれていない
5項目のうち最後の項目にチェックが付かない場合、Web版だけで完了したと判断しないでください。原型から実装へ責任を渡す段階で、別の環境が必要になります。
コードベースへ渡す協作者
デザインエンジニアや実装担当者は、Figma Make内のコードキャンバスと、実際のローカルコードベースを分けて考えます。前者は原型を編集する場所です。後者は既存ファイル、依存関係、ブランチ、認証情報、チームのレビュー規則を含む作業環境です。
公式ヘルプでは、ローカルコードベースを使うための設定と、接続時の注意点が別に案内されています。設定上の注意とトラブルシューティング には、環境設定や権限を確認する必要があることが示されています。
つまり、WindowsのWeb版から原型を編集できても、次の作業まで同じ条件で進められるとは限りません。
- 対象プロジェクトとブランチを決める
- ローカルコードを開くMac環境を準備する
- Figma Makeへデザイン文脈を渡す
- 変更内容をコード上で確認する
- コメントと修正箇所を照合する
- チームの権限で変更を保存する
- PRを作成し、レビュー可能な状態にする
PRは「ボタンを押せば本番へ反映される機能」ではありません。作成後も差分、テスト、レビュー、マージ権限が必要です。Figma MakeがPR作成を支援しても、チームの開発手順を置き換えるものではありません。
Web版、Mac版、リモートMacの分担
| 選択肢 | 向いている納品物 | ローカルコード | PR作成 | 主な確認点 |
|---|---|---|---|---|
| WindowsのWeb版 | 原型リンク、コメント、デザインレビュー | 前提にしない | 前提にしない | 共有範囲、コメント、ログイン |
| Mac Betaデスクトップアプリ | コード編集、注釈、チャット、PR | 対応範囲を公式資料で確認 | 対応機能として案内あり | Beta資格、権限、既存ツール |
| リモートMac | WindowsからMac環境を一時利用 | Mac側の環境で確認 | チーム権限があれば検証可能 | 接続品質、認証、ファイル管理 |
| 固定のMac環境 | 継続的なコード連携 | 継続利用しやすい | チーム運用に組み込みやすい | 保守、費用、物理アクセス |
リモートMacはMacデスクトップ環境を借りる方法ですが、ローカル開発機と完全に同じではありません。接続が切れた際の再接続、認証画面、ファイルの保管場所、キーボード操作、チームのセキュリティ規則を実案件で確認する必要があります。
短期案件でMacを常用するか迷う場合は、MESHLAUNCHのMac環境に関する案内を確認し、まず代表的な1案件だけで作業手順を再現します。長期的に毎日コードを保守するなら、固定Mac環境の選択肢と、リモート利用の管理負担を比較してください。
経験則：原型を作る時間より、認証、ファイル引き渡し、権限確認に時間がかかる案件では、環境選びを機能比較だけで決めない方が安全です。
利用頻度別の判断
| 作業頻度 | 現実的な選択 | 理由 | 回避すべき判断 |
|---|---|---|---|
| 単発の原型作成 | WindowsのWeb版 | 原型リンクとコメントで納品しやすい | コード連携を前提にMacを常設する |
| 数週間の反復改修 | リモートMacを先に検証 | 代表案件で接続、権限、ファイル受け渡しを確認できる | 「Macなら必ずPRまで進む」と考える |
| 継続的なリポジトリ保守 | 固定Macまたは承認済みのMac環境 | 同じツールチェーンと認証を維持しやすい | 個人アカウントだけでチーム運用する |
| 原型と実装を別担当へ渡す | Web版＋チームの開発環境 | 役割分担を明確にできる | デザイン担当が権限のないコードを直接変更する |
自由職の場合、最初に「原型リンク」なのか「編集可能なコード」なのかを依頼主へ確認します。小規模チームの場合は、PRの作成者、レビュー担当、マージ担当を決めます。ここが曖昧なままMacだけを追加しても、納品の責任範囲は解決しません。
代表案件で行う5段階の確認
本番案件へ移る前に、次の順で検証します。
-
同じFigma Makeファイルを用意する
WindowsのWeb版で原型を生成し、ページ構成とコンポーネントの文脈が再現できるか確認します。 -
デザイン文脈を追加する
既存画面、コンポーネント、コメントを渡し、意図した修正が反映されるかを見ます。 -
Mac側でローカルコードを開く
Mac Betaの対象条件、リポジトリ権限、必要な開発ツールが揃っているか確認します。 -
変更、コメント、PRの境界を記録する
どこまでFigma Makeで編集し、どこからコード担当者が確認するかを決めます。PR作成後のレビュー手順も残します。 -
切断と再接続を含めて納品する
リモート接続が途切れた場合に作業状態を復元できるか、ファイルがどこに保存されるか、コメントの同期状態を確認します。
この手順で、単に「画面が表示された」だけでなく、原型生成、編集、コード確認、変更提出、コメント同期、再接続までを一つの業務として判定できます。Beta機能の利用可否が案件ごとに異なる場合は、同じ結果を保証できる機能として扱わないでください。
交付物から決める最終結論
判断基準はプラットフォーム名ではなく、最後に渡すものです。
- 原型リンクが必要なら、WindowsのWeb版を選びます。
- レビュー可能なデザインが必要なら、Web版のコメントと共有範囲を確認します。
- 編集可能なコードが必要なら、Mac Betaデスクトップ環境とローカルコードの権限を確認します。
- マージ可能なPRが必要なら、Mac環境だけでなく、ブランチ、レビュー、認証、チーム権限を確認します。
今のWindows中心の運用は、原型とレビューには手軽です。しかし、ローカルリポジトリを直接開けない、Mac Beta機能の対象範囲を確認できない、コード権限やPRの責任を別途調整しなければならない、という弱点があります。数週間だけコード連携を試すなら、MESHLAUNCHのリモートMacで代表案件を確認する方が、いきなり固定環境を用意するより判断しやすいです。長期の開発運用や物理機器が必要な案件では、固定Macを含めてチームの管理条件を比較してください。