クライアント確認のたびにメインファイルを直接直して、前の版と混ざってしまった経験はありませんか。私はフリーランスでデザイン当て込みとディレクションを兼ねているので、Figma ブランチ クライアント確認の線を一本にしたい場面が多いです。本記事は、新機能の紹介記事ではなく、すでにFigmaで画面を作っている人が、確認用の枝を切って戻すまでの実務手順に絞ります。Figma制作フローの入口やDev Modeの使い方と並べて読むと、実装前の承認がスムーズになります。
この記事でわかること
- ブランチを切るべき案件と、小さすぎて不要な案件の見極め
- クライアントに渡す共有リンクの種類と、コメント権限の設定
- 差し戻しを反映してメインへマージする前のチェック項目
先に結論
- 向いている人: 複数ページのWeb制作で、確認ラウンドが2回以上ある案件。デザイナーとディレクターが同じファイルを触るチーム。修正版を「前案と並べて」見せたいとき。
- 向いていない人: 1画面だけのバナー差し替え。クライアントがFigmaアカウントを持たず、PDFだけで完結する案件。ブランチ機能がプラン上使えない環境。
- 私のおすすめ: 確認用ブランチは「1ラウンド＝1ブランチ」 に近づける。メインは常に「承認済みの正」に保ち、試し置きは枝に逃がす。
私は「メインを触る＝承認に近い」という感覚で運用しています。迷ったら枝に逃がす方が、あとから説明しやすいです。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
Figmaの契約・プランは執筆時点の情報です。ブランチや高度な共有の可否は、利用プランと組織設定で変わるので、作業前に公式のFigmaで最新を確認してください。
ブランチが効く場面と、切らなくてよい場面
| 状況 | ブランチ | 理由 |
|---|---|---|
| トップ＋下層5ページの初回提出 | 推奨 | 全体差し戻しと部分OKが混ざる |
| 文言だけの微修正 | 不要 | 履歴コメントで足りることが多い |
| A/B案を2つ並べて選ばせる | 推奨 | メインを二重化しない |
| 実装済みサイトのピクセル合わせ | 状況次第 | スクリーンショット比較なら枝が安全 |
ブランチは「版を分ける」道具です。デザイン探索のラフ置き場には向きません。ラフは別ページや別ファイルに置き、クライアントに見せる版だけ枝に載せる方が、承認の線がはっきりします。
クライアントが「どこが変わったか」を一目で知りたいとき、ブランチとメインの比較ビューは説明コストを下げます。逆に、修正が1フレームの色変更だけなら、ブランチを切る手間の方がストレスになることもあります。
作業前に揃える3つ（ファイル・命名・権限）
-
メインファイルの役割を固定する
メイン＝承認済み、ブランチ＝確認中、とチーム内で言葉を揃えます。フリーランス単独でも、自分へのルールとして書いておくと後から迷いません。 -
ブランチ名のルールを決める
例:review-20260921-topのように日付と対象ページを入れます。fixだけの名前は、1週間後に意味が消えます。 -
共有リンクの権限を先に決める
コメントのみ／閲覧のみを案件ごとに固定します。編集権限をクライアントに渡すと、意図しないマージや上書きのリスクが上がります。
権限はケチる派です。コメントできれば十分、という前提でリンクを出しています。
プロジェクトのオーナー権限が誰にあるかも、ブランチ作成前に確認してください。オーナーがクライアント側だけだと、枝の作成やマージが止まることがあります。契約段階で「デザイン作業用の編集者枠」をどうするか決めておくと、後工程が楽です。
具体例として、コーポレートサイトの「採用ページだけ全面リニューアル」案件では、メインには旧デザインを残し、枝 review-recruit-2026 に新レイアウトだけ載せました。クライアントは採用セクションのURLだけを見比べられ、他ページのブックマークを壊さずに2週間の確認が終わりました。トップのヒーローだけ差し替えるような小修正なら、同じ枝に載せずメインでコメント対応に留めた方が、マージ作業は短く済みます。
ブランチを切る手順（デザイナー側）
- Figmaで対象ファイルを開き、ブランチ作成から新しい枝を作る
- 枝の名前にラウンド番号と対象（例:
r2-news-list）を入れる - 確認用に変えるフレームだけ枝上で編集する（メインは触らない）
- 自社内で一度プレビューし、リンク切れや未翻訳のダミーを消す
- クライアント向けリンクを発行する
枝上で大規模な構造変更をすると、マージ時にコンフリクトが増えます。レイアウト変更はメインで承認してから枝に載せる、という順番の方が安全なことが多いです。
クライアントに渡すリンクとコメントの運用
クライアント確認では、次の2点をメールやチャットのテンプレに入れておくとトラブルが減ります。
- このリンクは 第○回確認用 であること
- コメントは フレーム名または番号 を指定してほしいこと
「ここ直して」だけのコメントは、実装時に迷子になります。私はスクリーンショット付きコメントを推奨する一文を添えています。
共有時にFigmaのプランで使える閲覧者数に達していないかも、ラウンド前に見ておきます。ゲスト閲覧の期限が切れると、確認途中でリンクが死ぬことがあります。
差し戻しを反映してメインに戻す流れ
- クライアントコメントを枝上で消化し、未対応リストをゼロにする
- デザイナーとディレクターで枝を目視確認（スマホ幅を忘れない）
- メインへのマージ（または承認済み内容の反映）を行う
- メイン側でバージョン名またはコメントに「○月○日承認」を残す
- 実装担当へDev Modeの確認ポイントを渡す
マージ後は、枝を残すか削除するかをルール化します。履歴として残す案件は、マージ済みブランチをアーカイブ扱いにし、名前に merged- を付けると一覧が読みやすくなります。
よくあるつまずきと対処
コンフリクトが出た
同じコンポーネントをメインと枝の両方で触っているときに起きます。片方を正として、もう片方を手で合わせます。大きいコンフリクトは、一度メインを正に戻して枝を切り直す方が早いこともあります。
クライアントがメインを直接見ている
古いブックマークでメインを見続けると、「直っていない」と言われます。リンクを渡すたびに「このURLが今回の確認版です」と明記してください。
実装側が枝のURLを参照している
実装は常にメイン（または指定したデザインシステムファイル）を正にします。枝は承認プロセス用で、本番CSSの参照元にはしない、とREADMEに一行書いておくと安全です。
実装が枝URLを掴む事故、一度で十分でした。今はメイン固定をチャットで太字にしています。
コンポーネントとデザインシステムがある案件での注意
ライブラリファイルを別に持っている案件では、ブランチ上でコンポーネントを編集すると、メイン側のライブラリと食い違うことがあります。確認用の枝では ローカルオーバーライド を増やしすぎない方が、マージ後のメンテが楽です。ボタンやカードのバリアントを試すときは、枝専用のテストページフレームを1枚用意し、そこにだけバリアントを並べる運用にしています。
色やタイポのトークンは、変数がプロジェクトにリンクされているかをマージ前に確認します。枝でだけ色を直して、変数を更新し忘れると、実装側のCSSトークンとズレます。変数とデザインシステムの整理を先に固めている案件ほど、ブランチは「レイアウト差分」に集中できて効率的です。
フリーランス向けの請求・納品メモ
ブランチ運用は、見た目の作業量より ラウンド数 が増えやすいです。見積もりでは「確認回数の上限」を契約に書いておくと、ブランチが増えすぎたときの説明が楽になります。納品物リストに「FigmaメインファイルURL（承認済み）」を明記し、枝は参考リンクに格下げするか削除するかを納品時に決めます。
制作全体のチェックリストはWeb制作納品前の確認もあわせて見てください。デザインと実装の境界がぶれないように、ブランチ上のコメントをPDFにエクスポートして残す案件もあります。
よくある質問
ブランチとバージョン履歴はどう使い分けますか
履歴は自動で積み上がる記録、ブランチは意図的に分けた「確認用の版」です。クライアントに見せる単位がはっきりしているならブランチ、自分だけの試行錯誤なら履歴で十分なことが多いです。
クライアントがFigmaを使えない場合は
ブランチで作った画面をPDFまたは静止画で出し、コメントはメールやスプレッドシートで受けます。その場合もメインは触らず、枝に反映してからマージする流れは同じです。
小さな制作会社でも運用できますか
人数が少ないほど、メイン＝正のルールが効きます。オーナーが1人なら、ブランチ名とマージ日をコメントに残すだけでも、後からの説明がかなり楽になります。
実装前にデザインがまた変わったときは
実装着手後の変更は、新しい枝を切るか、メインで承認後に実装チケットを分けます。枝と実装ブランチ（Git）を混同しないよう、チャットで「Figmaは○、コードは○」とリンクを分けて書きます。
台風や長期休暇で確認が止まったときは
リンクの有効期限と、ブランチ上の未読コメントを再開前に棚卸しします。休み明けにメインと枝のどちらが最新か分からなくなるので、チャットに「再開時の正URL」を1つだけ貼るルールを決めておくと安全です。急ぎの差し替えが入った場合は、新しい枝を切り直し、古い枝には obsolete- を付けて触らない印を付けます。
まとめ — 今日やること
- 進行中案件のメインファイルを開き、未承認の試し置きがないか確認する
- 次のクライアント提出からブランチ名のルール（日付＋ページ）を1つ決める
- 共有リンクの権限をコメントのみに揃え、テンプレ文に「今回の確認URL」と明記する
ブランチは難しい機能ではありませんが、メインを正に保つ習慣が効きます。まずは1案件だけ試し、マージまで通してから他案件に広げるのがおすすめです。
デザインから実装へ渡す流れ全体は制作フローの柱にまとめています。Figmaの契約更新や席数の見直しは、Figma公式から行えます（執筆時点のプラン・価格は変動します）。
