FigmaコメントをLinearイシューに連携する方法
FigmaコメントをLinearイシューに連携して、タブ間のコピペなしにデザインフィードバックとエンジニアリング作業を橋渡しする方法。
By Ellis Keane · 2026-03-31
デザイナーが詳細なFigmaコメントを残し、3メートル先に座っているエンジニアが2日後にほぼ同じLinearイシューを作成するのを4回目に目撃したとき、私はこれをコミュニケーションの問題だとは思わなくなった。これは配管の問題だ。この2つのツール間のパイプは、誰もが思うような形では存在していない。
ネイティブのFigma Linearインテグレーションでは、リンク埋め込みとフレームからイシューを作成するプラグインが利用できる。これは本当に便利だ。しかし、ボタンのホバー状態に関するFigmaのコメントスレッドが静かに2週間のエンジニアリングのウサギ穴になり、スプリントレトロまで誰も点と点を結ばない部分 – それは誰のツールも実際には解決していないギャップだ。この記事はそこについてのものだ。誰かの記憶に頼らずにFigmaコメントをLinearイシューに連携する方法。
LinearのFigmaインテグレーションが実際にできること(とできないこと)
ネイティブインテグレーションが得意なことは2つだけで、それ以外は何もしない。
LinearにおけるFigmaリンク埋め込み。 FigmaのURLをLinearのイシューやコメントに貼り付けると、インタラクティブなプレビューに変換される。注意点として、Linearのドキュメントには、アプリ内インタラクティブプレビューは公開共有されたFigmaファイルにのみ機能すると記載されている。プライベートなデザインファイル(つまりほとんどのファイル)は、サムネイル付きの静的リンクとしてレンダリングされる。
FigmaのLinearプラグイン。 Figmaの中から、特定のフレーム・ページ・セクションに自動的にリンクされたLinearイシューを作成できる。チーム・ステータス・担当者・プロジェクトをタブを切り替えずに設定できる。既存のイシューにリンクすることもでき、デザイン変更が既に進行中の作業に触れる場合に便利だ。
LinearのFigmaインテグレーションは一方通行の橋だ。デザインのコンテキストをLinearにプッシュするのを助けるが、エンジニアリングのコンテキストをFigmaに引き戻すことはなく、2つのツール間でコメントスレッドを接続することもない。
できないこと:
- FigmaコメントはLinearイシューを自動的に作成しない。毎回誰かが手動でプラグインを使う必要がある。
- Linearイシューの更新はFigmaに反映されない。エンジニアがステータスを変更したり、ブロッカーを追加したり、作業をリスコープしたりしても、デザイナーは自分でLinearを確認しない限り気づかない。
- クロスツール検索はない。「ナビゲーションリデザインはどこで議論したか?」という問いは、Figmaのコメント・Linearのイシュー・あるいは(神よ)両方を意味するかもしれない。
FigmaからLinearへのワークフローの設定
設定には約3分かかる。詳細はLinearのFigmaインテグレーションのドキュメントにあるが、短縮版はこちら:
- [ ] Linearワークスペースの設定でFigmaインテグレーションを有効にする(両方の管理者権限が必要)
- [ ] Figma CommunityからLinear公式プラグインをインストールする(サードパーティの代替は避ける – APIアップデートで壊れる傾向がある)
- [ ] テスト:フレームを選択し、Linearプラグインを実行して、イシューを作成する。フレームへのリンクが確認できることを確認する。
- [ ] テスト:FigmaファイルリンクをLinearイシューに貼り付けて、埋め込みがレンダリングされることを確認する
- [ ] デザインファイルの共有設定を確認する – プライベートファイルはインタラクティブプレビューではなく静的リンクを表示する
これで明確なパスは対応できる。デザイナーがタスクを認識し、イシューを作成し、エンジニアがコンテキストを得る。問題はタスクがコメントを書いた時点では明確でない場合に始まる。
分類の問題
これが私が見てきたすべてのFigmaからLinearへのワークフローを壊すシナリオだ:
デザイナーがフレームにコメントする。「このローディング状態は私たちが話し合った空の状態を考慮していない。スケルトンスクリーンを追加すべきか?」3人がFigmaスレッドで返信する。決定が下される。そのコメントはタスクというよりデザインの議論のように感じられたため、誰もLinearイシューを作成しない。
2スプリント後、エンジニアはスケルトンスクリーンなしで機能を構築する。QAがフラグを立てる。全員がSlackで20分かけて、これが以前に議論されたかどうかを調べようとする。議論されていた – Figmaで。コメントスレッドはまだそこに座って、解決済みで忘れられている。
title: "Figmaコメントがスプリントブロッカーになるまでの経緯" 10:14 AM|ok|デザイナーがFigmaでホバー状態にコメントする 10:32 AM|ok|Figmaスレッドで2件の返信、チームがアプローチに合意 10:33 AM|missed|Linearイシューは作成されず – デザインの議論のように感じられた Day 3|ok|エンジニアが変更なしで機能を構築する Day 8|amber|QAが欠落している動作をバグとしてフラグを立てる Day 8|missed|Slackで20分かけてFigmaスレッドを再発見する
問題は人々がLinearプラグインを使うのを忘れることではない。デザインフィードバックはスペクトル上に存在し、「あれはタスクだったか?」という分類は遡って行われる。通常は誰かがそれが実行されていないことに気づいたときに。
役立つ3つのヒューリスティクス: Figmaコメントスレッドをレビューするとき、それが(a)既存のLinearイシューの受け入れ基準に影響するか、(b)まだ誰もファイルしていない新しい作業を説明しているか、(c)スコープを変える決定を含んでいるかを確認する。これらのどれかに該当すれば、追跡されたイシューになるべきだ。これですべてを捕捉できるわけではないが、「このコメントは重要だ」というチームの共通語彙が得られる。
実際に機能すること(と機能しないこと)
推奨のセットアップ:ネイティブプラグイン+軽量な規約+セーフティネット。 デザイナーが明確な作業を特定したときは常にFigmaのLinearプラグインを使う – コンポーネントの更新・バグの申告・新しい画面の構築など。シンプルなコメント規約(チームでは「Action:」のプレフィックスや関連するエンジニアへのタグ付けを使っている)を重ねて、重いプロセスなしに意図を示す。そしてどうしてもすり抜けるものがあることは受け入れる – スプリントボードと一緒に最近のFigmaコメントスレッドをスキャンする週次レビューを設け、1週間以上経過した未解決のスレッドで既存のイシューにマッピングできるものを探す。これはFigmaコメントをLinearイシューに繋ぐための完璧なシステムか?いや、手動の応急処置だ – しかし私が見つけた中で最も信頼できる手動の応急処置であり、分類レイヤーを自動化できるまでの時間を稼いでくれる。
機能すること
- 明確なタスクへのネイティブプラグイン – デザイナーが何かがタスクだとわかっているとき、Linearプラグインは速くて直接的だ
- コメント規約 – 意図を示す
Action:のような簡単なタグやエンジニアへのメンション
- 週次コメント・ボードレビュー – スプリントボードに対して未解決のFigmaスレッドをスキャンする
機能しないこと
- スケールでの手動ルーティング – すべてのコメントを分類することを人間に頼ることは忙しいスプリント中に機能しなくなる
- キーワードベースのZapier自動化 – FigmaコメントのWebhookはすべてのアクティビティ(返信・解決・リアクション)で発火し、常にフィルターのメンテナンスが必要なノイズを生成する
- ギャップを完全に無視する – 「とにかく両方のツールを確認する」という期待は戦略ではない
代替案:ZapierまたはMake。 新しいFigmaコメントにトリガーを設定してLinearイシューを作成できる。実際の問題は、FigmaのWebhookが大量のコメントイベントを生成する可能性があることだ – 返信・解決済みのスレッド・絵文字リアクションがすべて発火する。慎重なフィルタリングなしでは、誰かがサムアップでコメントに反応するたびにLinearが新しいイシューで溢れる。これはキャリアの選択を疑問視させる類の進歩だ。フィルタリングを行うと、チームが実際にコメントを書く方法と同期がずれていくregexルールのメンテナンスをすることになる。予測可能なコメントパターンを持つ小さなチームには対応できるが、誰かのパートタイムの仕事になる。
代替案:セマンティックなシグナルインテリジェンス。 個々のコメントをイシューとしてルーティングする代わりに、両方のツールをセマンティックレベルで理解するシステムは、FigmaのコメントスレッドがLinearの既存のイシューと重なっていることや、新しいコメントが追跡されていない作業を示唆していることを認識できる。これはSugarbugで構築しているアプローチだ – FigmaとLinearの両方のネイティブスクレーパーがシグナルを分類し、ナレッジグラフを通じて接続を表示する。デザインの議論とエンジニアリングタスクの間のリンクが誰かがボタンをクリックすることを覚えることに依存しない。
目標はすべてのFigmaコメントをLinearイシューにすることではない。コメントが作業を示唆しているとき、その接続が誰かの記憶に依存しないようにすることだ。 attribution: Chris Calo
よくある質問
シグナルインテリジェンスをメールに届けましょう。
Q: FigmaコメントからLinearイシューを直接作成できますか? A: はい、ただし自動ではありません。FigmaにLinearプラグインをインストールする必要があり、毎回手動で実行する必要があります。特定のフレームにリンクされたイシューを作成し、チーム・ステータス・担当者・プロジェクトをタブを切り替えずに設定できます。ギャップは、コメントが当時明確なタスクのように感じられない場合、誰もこれを実行しないことです。
Q: SugarbugはFigmaコメントをLinearイシューに自動で連携しますか? A: SugarbugはFigmaとLinearの両方をネイティブにスクレイピングし、それぞれのシグナルを分類してナレッジグラフを通じてリンクします。FigmaのコメントがLinearで追跡されている作業を参照している場合、Sugarbugは手動のリンク設定なしにその接続を表示します。
Q: FigmaのコメントはなぜLinearに通知として表示されないのですか? A: インテグレーションが一方通行だからです。LinearはFigmaのデザインプレビューを埋め込み、プラグインからイシューを作成できますが、Figmaのコメントスレッドは通知としてLinearに流れません。更新も双方向には反映されません – エンジニアがイシューのステータスを変更した場合、デザイナーはLinearを確認しに行く必要があります。
Q: どのFigmaコメントをLinearイシューにすべきか、どうやって判断しますか? A: 3つのヒューリスティクスを使ってください。そのコメントは既存のイシューの受け入れ基準に影響しますか?まだ誰もファイルしていない新しい作業を説明していますか?スコープを変える意思決定が含まれていますか?これらのどれかに「はい」であれば、Linearで追跡すべきです。