Web制作のデザイン工程で、Figmaプラグイン おすすめを探している人向けに、私が実案件で使っている定番だけに絞って書きます。プラグインは入れすぎるとファイルが重くなり、チームメンバーが同じ環境を揃えられなくなる。だから「全部入れる」ではなく、工程ごとに役割を決めるのが先です。
先に結論
- 向いている人: FigmaでUIデザインから実装引き渡しまでやる人、チームでファイルを共有している人、命名やアクセシビリティで毎回手戻りが出る人
- 向いていない人: 図面1枚だけ作って終わる人、プラグイン導入より手作業の方が早い超小規模案件だけの人
- 私のおすすめ: まず Rename It（命名）→ Stark（アクセシビリティ）→ Iconify（アイコン） の3つ。画像素材は Unsplash、フローは Autoflow。デザインシステム案件なら Tokens Studio を追加
私が触っているのは主にクライアント向けのWeb UI案件です。以下のプラグイン名・機能は、執筆時点（2026年9月・日本時間）のFigma公式の説明と、私の制作フローでの使い方を混ぜて書いています。バージョンでメニュー位置が変わることがあります。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
プラグインを選ぶ3つの軸
| 軸 | 目的 | 代表例 |
|---|---|---|
| 品質・ルール | 実装前にミスを減らす | Stark、Contrast |
| 速度 | 素材・命名・配置の手間を削る | Unsplash、Iconify、Rename It |
| 引き渡し | 開発者・クライアントが読みやすい | Autoflow、Tokens Studio |
品質系を先に入れるのが、後からの修正コストを抑えやすいです。速度系だけ増やすと、最初は速いのにレビューで色やコントラストを直す時間が増えるパターンになりがちです。
関連の入口は、Figma制作フローの柱記事にもまとめています。プラグインはあくまで補助で、Auto Layoutや変数の整理が先という考え方は変わりません。
命名整理：Rename It
レイヤー名が Frame 427 のまま増えると、Dev Modeで実装者が迷います。Rename Itは、選択したレイヤーに一括で命名ルールを当てられるプラグインです。
私の案件では、次のような接頭辞をテンプレに保存しています。
btn/… ボタンtxt/… テキストimg/… 画像icon/… アイコン
実案件での一例: ランディングページのヒーローセクションで、ボタンと見出しだけ先にリネームしてからコンポーネント化すると、あとから複製したときの検索が楽になります。全フレームを一度に直すより、セクション単位で回す方が安全です。
入れすぎ注意: 命名規則がプロジェクトごとに違うときは、テンプレを案件フォルダごとに分けておく。1つの共通テンプレに固めすぎると、別クライアントの既存ルールとぶつかります。
アクセシビリティ：Stark
Starkは、コントラスト比やフォーカス順のチェックができる定番です。Web制作では、ボタン文字色と背景色の組み合わせをデザイン段階で確認しないと、実装後に「読めない」と戻されることがあります。
私は次のタイミングで使います。
- カラーパレットを仮置きした直後
- ボタン・リンクの状態（hover相当）を増やしたあと
- クライアントレビュー前のセルフチェック
WCAGの基準値は案件の要件で変わります。公的な基準の解釈は公式ドキュメントを正とし、Starkは目安のフィルターとして使うイメージです。医療・金融など厳しい案件では、専門家レビューを別途入れる前提で書いておきます。
アイコン：Iconify
アイコンを1つずつSVGで探すのは地味に時間がかかります。Iconifyは、MaterialやFeatherなど複数セットから検索して、Figmaに配置できるプラグインです。
向いている場面:
- ワイヤーフレーム〜UI初稿で仮アイコンが欲しいとき
- ナビ・フッターのアイコン行を揃えたいとき
注意点: 最終稿ではクライアントのブランドガイドに合わせて差し替える前提で使う。Iconifyの見た目のまま納品すると、ライセンスやトーンがズレることがあります。私は「仮」ラベルを付けたフレームにだけ入れ、確定後に差し替える運用です。
画像素材：Unsplash（Figma内）
Unsplashプラグインは、Figmaから直接ストック写真を置けるツールです。LPのダミー写真やブログ風モックを作るときに便利です。
- 向く人: クライアントに「写真は後で差し替え」と伝えたい段階のモック
- 向かない人: 実写真のトーンがブランドの核になる案件（この場合は撮影素材か購入素材を先に揃える）
配置した写真は、実装引き渡し時に「差し替え予定」とコメントを残します。画像の最終権利はクライアント側で確認するのが安全です。
フロー図：Autoflow
サイトマップや画面遷移を、矢印付きのフローとして素早く描くなら Autoflow が定番です。仕様書が別ドキュメントの案件でも、Figma内に遷移図があるとレビューが早いです。
私は次の構成にしています。
- ページ一覧フレーム（PC / SPを横並び）
- Autoflowで主要導線だけ矢印
- 例外パス（エラー、ログイン後）は色を変えた矢印
矢印を増やしすぎると読めなくなるので、最初のユーザージャーニー1本に絞るのがコツです。細かい分岐は表や箇条書きに逃がします。
デザインシステム：Tokens Studio
コンポーネントと変数を使っている案件では、Tokens Studioでトークン（色・余白・タイポ）をJSONとしてエクスポートできるのが強みです。フロント実装でCSS変数やTailwindの設定に落とし込むとき、手入力の転記ミスが減ります。
- 入れる目安: 同一ブランドで複数ページを継続制作する案件
- 見送る目安: 1ページLPだけ、変数も使っていないファイル
Tokens Studioは学習コストがあります。チーム全員がFigma変数に慣れていない段階では、Figmaオートレイアウト設定の記事でレイアウトの型を固めてから入れた方が混乱が少ないです。
案件タイプ別のおすすめセット
同じプラグインを毎回入れる必要はありません。私は案件の尺で次のように分けています。
| 案件タイプ | 入れるプラグイン | 見送るもの |
|---|---|---|
| 1ページLP | Rename It、Stark、Unsplash | Tokens Studio |
| コーポレート複数ページ | 上記＋Iconify、Autoflow | 自動レイアウト生成系 |
| デザインシステム構築 | 全定番＋Tokens Studio | 仮素材系は最終段階で外す |
LPだけの案件で Tokens Studio を入れると、設定ファイルの管理だけで半日溶けることがあります。逆に、コンポーネントライブラリを育てる案件では、最初の1週間でトークン設計を終わらせないと、あとから色の名前がバラバラになります。
具体例: サービス紹介サイトを6ページ作ったとき、Rename Itで sec-hero / sec-feature の接頭辞を揃え、StarkでCTAボタンのコントラストだけ先に合格ラインに寄せました。写真はUnsplashの仮置き、納品2週間前にクライアントから正式素材が届いて差し替え——この流れだと、プラグインは「速度」と「品質」の両方に効きます。
入れない・控えるプラグイン
全部が悪いわけではありません。私の環境では次を控えています。
| 種類 | 控える理由 |
|---|---|
| 見た目だけ変えるUIテーマ系 | ファイル共有時に表示差が出る |
| 同機能の重複（複数のリネーム系など） | ショートカットとメニューが増えて迷う |
| 外部API連携の多い自動生成系 | クライアントデータを渡すリスク |
AIでレイアウトを一括生成する系は、試作には使えますが、納品物の著作・仕様の責任は人間側に残ります。生成結果をそのままコンポーネント化しないルールを、プロジェクトREADMEに1行書いておくと安心です。実装側でAI補助を使う場合は、Cursorなどでも同様に、差分レビューを必須にしています。
チームで揃える導入手順
- プロジェクトの
READMEまたはFigmaの最初のページに「推奨プラグイン一覧」を5行以内で書く - 全員が同じ3〜5個だけ入れる（それ以上は個人の好みで追加可と明記）
- 週次でプラグイン更新を確認し、動かなくなったものは外す
- クライアント共有ファイルでは、プラグイン必須の操作を避け、ネイティブ機能で再現できるか確認
レビュー運用は Figmaデザインレビュー手順 とセットで見直すと、プラグイン導入の効果がはっきりします。
失敗しやすい点
- プラグイン前提でしか編集できないファイルを納品する（クライアント環境で開けない）
- 命名規則が人によってバラバラ（Rename Itを入れただけでルール文書がない）
- アクセシビリティチェックを最後に1回（色を何度も変えたあとだと手戻りが大きい）
価格やプランは執筆時点の情報です。Figmaの料金・機能は変わることがあるので、導入前に公式を確認してください。
よくある質問
Q. 無料プランでもプラグインは使えますか？
A. 多くの公開プラグインは無料プランでも利用できますが、ファイル数や共同編集の制限はプラン側の条件が優先です。チーム案件では、まずFigmaの公式プラン比較で編集者数と履歴の要件を確認してから、プラグインを選ぶのが安全です。
Q. プラグインを入れすぎて重いときの対処は？
A. 使っていないプラグインをアンインストールし、残すのは「命名・アクセシビリティ・アイコン」の3分類に1つずつに絞るのが早いです。ファイル内の未使用コンポーネント削除と、画像の解像度見直しもセットで行うと、体感が変わることが多いです。
Q. 開発者に渡すときプラグイン情報も必要ですか？
A. 基本は不要です。Dev Modeで見えるプロパティと、命名・コメントが整っていれば足ります。Tokens StudioでエクスポートしたJSONを渡す案件だけ、別途共有ルールを決めます。
Q. FigJam用プラグインも同じですか？
A. 別カテゴリです。ワイヤーフレームやブレストはFigJam、UI確定はFigma本体、と分けている場合は、プラグインも用途ごとに分けた方がメンバーが迷いません。
Q. Dev Modeとプラグインはどちらを優先しますか？
A. 実装引き渡しが主なら、Dev Modeで取れる情報（サイズ・色・余白）を先に整える方が効果が大きいです。プラグインはデザイン中のミス防止が主役です。Figma Dev Modeの運用記事と併せて読むと、どの工程で何を使うかがはっきりします。
まとめ
Figmaプラグイン おすすめは、Rename It・Stark・Iconifyの3つから始め、案件の継続性に応じて Unsplash・Autoflow・Tokens Studio を足すのが失敗しにくいです。今日やることは、いま開いているファイルで Rename It を1回実行し、ボタンと見出しだけ命名規則に揃える——これだけでも実装引き渡しが楽になります。
関連記事: Figma制作フローの入口 / Figmaデザインレビュー手順
デザインツールの契約やチーム運用を見直す場合は、Figmaの公式サイトでプラン比較を確認できます。実装まで一気通貫で進めるなら、Cursorとの併用も選択肢のひとつです。
