フリーランスがFigmaで開発者にデザインを渡す場合、Viewerとして招待するだけで追加料金は発生しません。この記事では共有方法の選び方から権限設定、Dev Mode対応まで実務フローを解説します。
▶ 3日で初案件PR
この記事でわかること
Viewer招待なら開発者を何人招待しても追加料金ゼロで運用できます。ファイル単位の招待でチーム全体に公開せず案件ごとにアクセスを完全分離できます。Dev Modeは2段階アプローチで無駄なコストを発生させずに対応できます。
今の仕事について、一番近いものは？
この記事の結論
フリーランスが開発者にFigmaファイルを渡す場合、ほとんどのケースでViewerとしてのリンク共有またはメール招待だけで完結します。EditorやDevシートを追加しなければ費用は増えず、ファイル単位の招待を使えばチーム全体に公開せずに案件ごとのアクセス管理が可能です。迷ったらまずViewer招待で試し、コード確認が必要になった段階でDev Modeの要否を判断するのが最も無駄のない進め方です。
今日やるべき1つ
共有したいFigmaファイルを開き、右上の「共有」ボタンをクリックして開発者のメールアドレスを入力し、権限を「閲覧可能」に設定して招待を送る（所要3分）。
状況別ショートカット
| 状況 | 読むべきセクション | 所要時間 |
| 共有方法の種類と違いを知りたい | Figma開発者共有は3種類で使い分ける | 3分 |
| ViewerとEditorのどちらか迷っている | Figma共有権限はViewerとEditorの2択で判断 | 3分 |
| 追加料金が発生するか確認したい | Figma共有の料金はViewer招待なら無料 | 2分 |
| Dev Modeの扱いが分からない | Figma Dev Modeは2段階で対応 | 3分 |
| 誤編集や情報漏えいを防ぎたい | Figma共有を5項目で安全管理 | 3分 |
| フリーランスの実務フローを知りたい | Figma共有は5つの仕組みで効率化 | 5分 |
Figma開発者共有は3種類で使い分ける
Figmaには共有方法が3種類あり、用途を混同すると意図しないアクセスを与えるリスクがあります。複数の開発者や複数案件を同時に動かしているフリーランスほど、この違いを最初に把握しておくことで後のトラブルを防げます。
リンク共有はURLを知っていれば誰でも閲覧できる
リンク共有は、共有モーダルから生成したURLを開発者に送る方法です。URLを知っている人であれば誰でもアクセスできるため、素早く渡せる反面、URLが意図せず拡散するリスクがあります。権限を「閲覧のみ」に設定したうえで送ることで、閲覧範囲は維持しながら編集リスクを排除できます。信頼できる相手への速攻共有には向いていますが、不特定多数との連携には不向きです。
リンク共有の設定は、ファイル右上の「共有」ボタンをクリックし、「リンクを知っているすべての人」を選択したうえで権限を「閲覧可能」に設定します（Figmaヘルプ：ファイルとプロトタイプを共有する）。
メール招待はファイル単位でアクセスを絞れる
メール招待は、特定の開発者のメールアドレスを指定してアクセス権を付与する方法です。招待した相手だけがアクセスでき、チームや他のプロジェクトには影響しません。複数案件を並行しているフリーランスには最も安全な選択肢です。
招待する際、「ファイルへのアクセスを招待したユーザーのみ」に限定することで、チームメンバー全員に公開せずに1案件の開発者だけに渡せます（Figmaヘルプ：共有と権限のガイド）。案件ごとにメール招待でアクセスを絞ることで、引き継ぎ時の誤操作を減らせます。
プロジェクト共有は長期案件や複数ファイルに向いている
プロジェクト共有は、複数ファイルをまとめて管理する単位でアクセスを付与する方法です。継続的にファイルが増えていく長期開発案件に向いています。一方で、プロジェクト内のすべてのファイルに一括でアクセス権が付与されるため、共有範囲が広くなるリスクがあります。短期案件ではファイル単位の招待を優先し、プロジェクト共有は関係が長期化してから検討するのが現実的です。
CHECK
▶ 今すぐやること: 次の案件で共有する際、リンク共有かメール招待かを先に決めてから共有ボタンを押す（30秒の意思決定）
Q: リンク共有とメール招待、どちらを優先すべきですか？
A： 原則としてメール招待を優先してください。URLの拡散リスクを排除でき、誰がアクセスしているかをFigma上で管理できます。急いでいる場合のみリンク共有を使い、共有後に招待方式に切り替えてください。
Q： ファイル単位・プロジェクト単位・チーム単位の違いは何ですか？
A： ファイル単位は招待した相手が1ファイルのみ閲覧できます。プロジェクト単位はそのプロジェクト内のすべてのファイルにアクセスできます。チーム単位はワークスペース全体の公開ファイルにアクセスできるため、外部の開発者にはファイル単位かプロジェクト単位を推奨します。
Figma共有権限はViewerとEditorの2択で判断
ほとんどの実務ではViewer権限で十分です。権限の差を理解しておくと、誤編集のリスクを防ぎながらスムーズなハンドオフが実現できます。
ViewerはコードやCSSの確認まで可能
Viewerは閲覧専用の権限ですが、単に見るだけではありません。Figmaのインスペクトパネルでは、Viewer権限でもフォントサイズ、カラーコード（HEX/RGB）、余白、コンポーネント名などの実装情報を確認できます。コメントの追加もViewerで可能です。開発者がデザインを読み取って実装するという一方向のハンドオフであれば、Viewerで完結します。
EditorはFigmaの有料席コストが発生する
Editorはファイルの編集が可能な権限で、プロフェッショナルプランではEditorシートが有料です。開発者がデザインに直接手を加えるケースは稀で、ほとんどの場合はコメントで修正要望を伝えるフローで対応できます。Viewer招待の場合、招待される側のアカウントが無料プランであっても閲覧は可能なため、開発者側にコストは発生しません（Figmaヘルプ：プロフェッショナルプランの権限）。
編集が必要な例外ケースは3パターンのみ
開発者にEditor権限が必要になるのは、プロトタイプのフローを開発者自身が整理する場合と、スペックのメモをデザインファイルに直接書き込む場合と、デザインシステムのトークンを開発者側が管理する場合の3つに限られます。これ以外であれば、Viewerを維持したままコメント機能で対応するほうが安全です。Editor権限を付与する前に「コメントでは解決できないか」を必ず確認してください。
CHECK
▶ 今すぐやること: 現在Editorとして招待している開発者のリストを確認し、Viewerで代替できる人を特定する（5分）
Q: Viewerのまま開発者がコメントを追加できますか？
A： はい、Viewer権限でもFigmaファイルにコメントを追加できます。修正依頼はコメント機能で集約する運用にすることで、メールやSlackに分散するコミュニケーションを一元管理できます。
Q： 開発者がコードをコピーするにはどの権限が必要ですか？
A： Viewer権限で十分です。Figmaのインスペクトパネルから、フォントや色のCSSコードを確認・コピーする機能はViewer権限でも利用できます。
Figma共有の料金はViewer招待なら無料
Viewer招待であれば追加の席代は発生しません。料金体系の仕組みを把握しておくことで、コストを気にして共有を先送りにする必要がなくなります。
Viewerを招待しても席代は増えない
Figmaの料金体系では、課金対象となるのはEditorシート（編集権限を持つ席）です。外部の開発者をViewerとして招待した場合、招待した人数に関係なく、フリーランスが契約しているプランの席数分のコストしか発生しません。開発者10人をViewerとして招待しても、月額料金は変わりません。
DevシートはDev Mode専用の有料オプション
プロフェッショナルプランには、Dev ModeをメインにFigmaを利用する開発者向けの「Devシート」が用意されています（Figma公式：プロフェッショナルプラン料金と機能）。DevシートはEditorシートよりも低価格で設定されており、コードの確認やアセットの書き出しが中心の開発者に向いています。ただし、Dev Mode自体はViewer権限でも一部機能が利用可能なため、必ずしもDevシートが必要なわけではありません。
フリーランス1人のプランで複数の開発者と連携できる
フリーランスが1人で契約しているプロフェッショナルプランで、複数の開発者にViewerとしてアクセスを付与することは問題ありません。Figmaでは外部コラボレーターをより柔軟に扱えるよう料金体系の改善が継続的に行われています（Figma公式ブログ：フリーランサーとエージェンシー向け改善）。まずViewer招待で運用を始めてください。
CHECK
▶ 今すぐやること: Figmaのワークスペース設定で現在のメンバーリストを開き、Editorになっている開発者がいれば権限をViewerに変更する（5分）
Q: フリーランスの無料プランでも開発者と共有できますか？
A： はい、Figmaの無料プランでもファイル共有は可能です。ただし、無料プランでは編集者を2名までしか招待できないなどの制限があります。開発者をViewerとして招待するだけであれば無料プランでも対応できますが、複数案件を同時進行するフリーランスにはプロフェッショナルプランの利用を検討してください。
Q： Devシートは必須ですか？
A： 必須ではありません。開発者がコードの確認とアセットの書き出しをViewer権限内で行える範囲であれば、Devシートを追加しなくても連携は成立します。Dev Modeのより詳細な機能が必要になった段階で追加を検討するのが費用対効果の高い進め方です。
Figma Dev Modeは2段階で対応
まずViewer権限の範囲でDev Modeを試し、不足があった段階でDevシートを検討する2段階アプローチが最も合理的です。
Viewer権限のDev Modeで確認できること
Figmaでは、Viewer権限でもDev Modeの一部機能にアクセスできます。具体的には、フレーム・コンポーネントのプロパティ確認、カラーコードやタイポグラフィの書き出し、アセット（画像・アイコン）のダウンロードが可能です。多くのフリーランス案件では、この範囲で実装に必要な情報は揃います。
Devシートが必要になる3つの条件
DevシートはDev Modeの全機能を使う場合に必要です。変数（Figma Variables）の確認をコード側で詳細に行う場合と、注釈やアノテーションを開発者が追記する場合と、デザインシステムとのコード連携を本格的に整備する場合の3条件に当てはまるときに追加を検討してください。それ以外の標準的なハンドオフであれば、Viewer権限のまま進めることで費用を抑えられます。
CHECK
▶ 今すぐやること: 現在進行中の案件ファイルをDev Modeで開き、開発者がViewer権限で必要な情報を取得できるか確認する（10分）
Q: Dev ModeはViewerとEditorで何が違いますか？
A： Viewer権限でもDev Modeの基本機能（プロパティ確認、アセット書き出し）は使えます。Editor権限またはDevシートがあると、注釈の追記やVariablesの詳細確認など、より高度な機能が利用できます。
Q： 開発者側がFigmaアカウントを持っていなくてもアクセスできますか？
A： Figmaアカウントがない場合でも、リンク共有のURLからゲストとしてファイルを閲覧することは可能です。ただし、コメントの追加やDev Modeの利用にはFigmaアカウントが必要なため、実務では開発者にアカウント作成を依頼したうえでメール招待してください。
PR提供: 日本デザインスクール（デザスク）
Figma共有を5項目で安全管理
共有後に「意図しない編集がされていた」「古いファイルが残ったまま共有されていた」というトラブルは、事前のルール設定で防げます。最初に仕組みを作ることで、後からの修正コストをゼロに近づけられます。
共有前にラフ案を別ファイルに切り出す
開発者に渡すファイルには、検討中のラフ案や未確定のデザイン案が混在していることが多いものです。共有前に最終確定したページのみを別ファイルとして複製し、そのファイルを共有することで、開発者が正しいデザインを参照できます。ファイルを丸ごと共有する前の5分の確認で、「見せたくないページが入っていた」という事態を防げます。
ファイル名・ページ名を命名規則で統一する
開発者が迷わずファイルを見つけられるように、ファイル名とページ名に命名規則を設けてください。たとえば「プロジェクト名-画面名-v1.0-FINAL」のように状態を末尾に付けることで、最新版と途中版の混同を防げます。命名規則がない案件では、開発者が旧バージョンを実装してしまい、修正に多くの時間を要するリスクがあります。
コメントはFigmaに集約し、メールやSlackに分散させない
修正依頼や質問をメールとSlackとFigmaに分散させると、情報を追うだけで時間が取られます。原則としてFigmaのコメント機能で連絡を完結させると、誰がどのフレームに対してどんな意見を持っているかが一目で確認できます。開発者にも最初に「このファイルでのやり取りはFigmaコメントに集約する」とルールを伝えてください。
招待後は定期的にメンバーリストを見直す
案件終了後も開発者のアクセスが残ったままになるケースは少なくありません。案件終了から2週間を目安にファイルの共有設定を確認し、不要なアクセスを削除することで情報漏えいリスクを管理できます。Figmaの共有設定画面ではメンバーリストをすぐに確認できるため、月1回の棚卸しを習慣にしてください。この月次の棚卸し習慣は、複数案件の情報管理を効率化する仕組みとして機能します。
リンク共有のURLは案件終了後に無効化する
リンク共有を使った場合、URLを無効化しないと案件終了後もアクセス可能な状態が続きます。案件終了後は共有設定を「リンクを知っているすべての人」から「招待されたユーザーのみ」に変更するか、共有自体を無効にすることで、URLの流出リスクをゼロにできます。
CHECK
▶ 今すぐやること: 過去3ヶ月以内に終了した案件のFigmaファイルを開き、共有設定でアクセス権が残っているメンバーを削除する（10分）
Q: 誤編集が起きた場合、Figmaで復元できますか？
A： プロフェッショナルプラン以上であれば、Figmaのバージョン履歴から過去の状態に復元できます。ただし、誤編集後に複数の変更が重なると復元の手間が増えるため、開発者にはViewer権限を付与して編集の機会そのものをなくす設計が最も安全です。
Q： クライアントと開発者を同じファイルで共有しても問題ありませんか？
A： 技術的には可能ですが、クライアントに見せたくない実装メモや開発者向けの注釈が混在するリスクがあります。クライアント向けとハンドオフ用でファイルを分けるか、ページを分けて権限の見通しを明確にしてください。
Figma共有は5つの仕組みで効率化
【対象】: 開発者を複数案件で使い回すフリーランス全般
【手順】: 共有モーダルを開く（30秒）。メールアドレスを入力し、権限を「閲覧可能」に変更してから招待を送信する（1分）。招待後に相手がEditorを要求してきた場合のみ、個別に必要性を確認する（随時）。
【コツと理由】: Viewer権限でコードの読み取りからアセットの書き出しまで完結できます。Viewerのままであれば席代の追加は一切発生しないため、料金を気にして共有を先送りにする必要がなくなります。まずViewerで招待して試す習慣をつけることで、不要なコストを積み上げる前に問題の所在が明確になります。
【注意点】: Editor権限を「とりあえず」付与する必要はありません。後から権限を下げると開発者に誤解を与えることもあるため、最初からViewerで始めることが最も合理的です。
ハック2: ファイル単位招待で案件ごとのアクセスを独立させる
【対象】: 複数の開発者・複数案件を同時進行しているフリーランス
【手順】: 共有したいファイルのみを開いた状態で「共有」ボタンをクリックする（30秒）。共有モーダルで「ファイルへのアクセスをこのユーザーのみに限定」を選択する（30秒）。招待後、別案件のファイルからは今回の開発者がアクセスできないことを確認する（1分）。
【コツと理由】: チーム共有にするとワークスペース内の他ファイルにも意図せずアクセスできてしまいます。ファイル単位で招待することで、案件終了後のアクセス削除も1ファイル分で済み、管理コストを最小化できます。案件数が増えるほど、この差が積み重なります。
【注意点】: プロジェクト共有やチーム共有を先に設定してしまうと、後からファイル単位に戻すのに手間がかかります。初回から「ファイル単位の招待」を原則にしてください。
ハック3: 共有前に最終稿を複製して渡すファイルを専用化する
【対象】: ラフ案や検討中のデザインが混在したまま開発者に渡してしまったことがあるフリーランス
【手順】: 共有直前に対象ファイルを「複製」する（1分）。複製したファイルから不要なページ（ラフ案・ボツ案）を削除する（3〜5分）。複製したファイルのみを開発者に共有し、元ファイルは自分のワークスペースに保管する。
【コツと理由】: 実務では作業途中のページや非公開の検討案がファイルに残っていることがほとんどです。複製ファイルを共有用として専用化することで、開発者が参照すべきデザインが明確になり、「どのページが最新ですか？」という確認コストを削減できます。
【注意点】: 複製後に元ファイルを修正した場合、複製ファイルへの反映が必要です。「ハンドオフ用ファイルは更新のたびに再複製する」というルールを自分の中で決めておかないと、開発者が旧バージョンを参照し続けるリスクがあります。
ハック4: コメント機能に連絡を集約して往復を削減
【対象】: FigmaとSlackとメールで開発者とやり取りが分散しているフリーランス
【手順】: 開発者への共有時に「このファイルに関するやり取りはすべてFigmaコメントで行う」とメッセージで伝える（1分）。コメントは該当するフレームの上に直接付けるよう依頼する（ルール周知：1分）。メールやSlackで修正依頼が来た場合、「Figmaコメントで同じ内容を入れてください」と誘導する（随時）。
【コツと理由】: ツールをまたいで情報が分散すると、確認漏れの温床になります。FigmaはコメントがフレームやオブジェクトのXY座標に紐づくため、「AとBの間のパディングについて」という曖昧な表現が不要になります。やり取りをFigmaに集約することで、連絡の往復を削減できます。
【注意点】: Figmaコメントへの移行を強制しすぎると、開発者との関係が悪化することがあります。最初の案件では柔軟に対応しながら、2案件目以降で標準ルールとして定着させてください。
ハック5: 命名規則を最初に決めて引き継ぎコストをゼロにする
【対象】: ファイル名やページ名の管理が属人的になっているフリーランス
【手順】: 案件開始時に「プロジェクト名-画面名-状態（WIP/FINAL）」の命名規則を決める（5分）。ファイル・ページ・フレーム・コンポーネントすべてに命名規則を適用する（設定時間：案件規模による）。共有時に命名ルールを開発者に共有し、コメントでも同じ名称を使うよう依頼する。
【コツと理由】: 命名規則は最初の1ファイル目から始めるほど整理の負荷を抑えられます。開発者が実装中に「このコンポーネントはどこにありますか？」と確認する手間がなくなるため、案件内の問い合わせ回数を削減できます。
【注意点】: 命名規則を細かくしすぎると、規則自体の管理が負担になります。「プロジェクト名-状態」の2要素から始め、必要に応じてバージョン番号を追加するシンプルな構成から始めてください。
CHECK
▶ 今すぐやること: 現在進行中のFigmaファイルを開き、コンポーネント名とページ名に命名規則を適用できているか5分で確認する
Q: 命名規則はFigma公式で推奨されているものがありますか？
A： Figma公式では特定の命名規則を強制していませんが、Figma公式のデザインハンドオフガイドでは、開発者との一貫性確保のためにコンポーネント名を明確にすることが推奨されています。チームや案件の規模に合わせて独自のルールを設計してください。
Figma開発者共有を3分でセルフ診断
以下の診断で自分のケースに合った対応を3分で確認できます。
Q1: 開発者はデザインファイルを「見るだけ」ですか、「編集もする」必要がありますか？
見るだけ → Q2へ。編集も必要 → Q2へ（ただしEditor付与の前にQ3も確認してください）。
Q2: 共有するのは単発案件（3ヶ月以内）ですか、長期継続案件ですか？
単発案件 → Result A（ファイル単位のViewer招待）。長期継続案件 → Result B（プロジェクト単位のViewer招待）。
Q3: 開発者がコードの詳細確認（Variables・注釈追記）をFigma上で行いますか？
コードの詳細確認が必要 → Result C（Devシートの追加を検討）。必要ない → Result A または Result B で十分。
Result A: ファイル単位Viewer招待（単発・標準案件）
メール招待でViewerとして招待し、対象ファイルのみにアクセスを絞ります。案件終了後は招待を削除して完了です。所要5分以内で設定できます。
Result B: プロジェクト単位Viewer招待（長期・複数ファイル案件）
プロジェクトにViewerとして招待し、ファイルが増えるたびに再招待の手間をなくします。プロジェクト内の全ファイルに一括でアクセスが付与されるため、共有したくないファイルは別プロジェクトに移動しておきます。
Result C: Devシート追加（本格Dev Mode運用案件）
開発者の作業量と費用対効果を確認したうえで、Devシートの追加を検討します。まずViewer権限で運用を開始し、機能が不足する場面が出た段階でアップグレードします。
CHECK
▶ 今すぐやること: 上記の診断を現在進行中の案件に当てはめ、Result A〜Cのどれが適切か確認して共有設定を見直す（3分）
Q: 診断結果がAとBで迷う場合はどうすればいいですか？
A： 迷う場合はResult Aを選んでください。ファイル単位の招待はプロジェクト単位より管理範囲が狭く、意図しないアクセスのリスクが低いためです。長期案件に移行した段階でプロジェクト単位に切り替えることは、後からでも対応できます。
Q： 複数の開発者に異なる権限を付与することはできますか？
A： はい、可能です。同じファイルに複数の開発者を招待する際に、それぞれの権限（ViewerとEditor）を個別に設定できます。誰にどの権限を付与しているかを管理表に記録しておくことをおすすめします。
Figma開発者共有はViewer招待で完結する
フリーランスがFigmaで開発者にデザインを渡す場合、Viewer招待から始めることで追加費用なく、安全にハンドオフを完了できます。
共有方法は「メール招待でViewer・ファイル単位・最終稿のみ」の3原則で運用し、コメントをFigmaに集約することで確認コストを最小化できます。Dev Modeが必要な場合もまずViewer権限で試し、機能が不足した場合のみDevシートを検討するという順序が費用対効果の高い進め方です。
1度ルールを作っておけば次の案件からは5分以内で共有設定が完了します。ファイル名の命名規則とViewer招待の原則を決めるだけで、開発者との往復コミュニケーションは大幅に減らせます。なお、外注費の管理や源泉徴収の扱いについても、開発者との契約前に確認しておくことで後のトラブルを防げます。
| 状況 | 次の一歩 | 所要時間 |
| まだ開発者を招待していない | メールアドレスでViewer招待を送る | 3分 |
| Editorを付与してしまっている | 共有設定でViewerに変更する | 2分 |
| 案件終了後のアクセスが残っている | メンバーリストから削除する | 5分 |
| Dev Modeを試したい | Viewer権限のままDev Modeタブを開いて確認する | 10分 |
Figma開発者共有に関するよくある質問
Q: Figmaで開発者を招待するとき、相手にFigmaアカウントは必須ですか？
A： リンク共有でゲストとして閲覧するだけであればアカウントなしでも可能です。ただし、コメントの追加やDev Modeの利用にはFigmaアカウントが必要です。スムーズな連携のため、メール招待と合わせてアカウント作成を依頼してください。
Q： 無料プランのFigmaで開発者と共有できる範囲はどこまでですか？
A： 無料プランでもファイルのリンク共有とメール招待は利用できます。ただし、無料プランではバージョン履歴の保存件数やプロジェクト数に制限があります。複数案件を本格的に管理する場合は、プロフェッショナルプランへの移行を検討してください。
Q： Figmaのリンク共有URLは後から無効にできますか？
A： はい、共有設定でアクセス権限を「招待されたユーザーのみ」に変更することでリンクを無効化できます。案件終了後は必ずこの設定を確認し、不要なURLアクセスを遮断してください。
【出典・参照元】
Figmaヘルプ：ファイルとプロトタイプを共有する – リンク共有・メール招待の手順と権限設定
Figmaヘルプ：共有と権限のガイド – 共有範囲（ファイル/プロジェクト/チーム）の説明
Figmaヘルプ：プロフェッショナルプランの権限 – ViewerとEditorの席代の違い
Figma公式：プロフェッショナルプラン料金と機能 – Devシート・コラボシートの料金体系
Figma公式：デザインハンドオフツール – 開発者との連携設計の前提
Figma公式ブログ：フリーランサーとエージェンシー向け改善 – 外部コラボレーション機能の拡充方針