デザイナーがアクセシビリティの問題を見つけます。チケットを切ります。バックログに入ります。そして埋もれます。今期も、来期も。 Figmaが最近公開した事例は、その慣れた結末を逆転させたんです — デザイナーが直接コードに入って、ブランチを作って、修正して、PR を上げたんですよ。 1日で。
なんでその修正、まだバックログにあるんですか
アクセシビリティ問題って、ほとんど小さく見えるんですよね。コントラストが低い日付ピッカー、スクリーンリーダーが読めないボタン、曖昧なナビゲーション ラベル。でも実は "小さいから直さない"じゃなくて"手をつける人がいないから直せない"んですよ。2026年2月のWebAIM 調査では、大手ホームページの95.9%がWCAG 基準をクリアできず、ページあたりの平均エラーが56.1個で前年比10.1%増。6年ぶりに数字が悪くなったんです。
なんでこんな細かい修正が永遠に積み重なるんでしょう。チケットベースのワークフローの構造的な限界なんです。デザイナーが "この画面のコントラスト直してください"と上げると、エンジニアはその画面だけ見るんですよ。でも実際には、その日付ピッカーがチェックアウトページ、イベントページ、設定ページ — 3箇所で再利用されている共有コンポーネントだったりするんです。1箇所だけ直すと、残りの2箇所は壊れたままで、このこと知ってるのはコードを実際に開いた人だけなんですよ。
アクセシビリティ技術債は、ただ積み重なるだけじゃなくて利息がつくんですよ。アクセスできないコンポーネントが広がるほど、担当者が変わったら文脈が失われて修正が遅くなるし危険になって。ユーザーが増えるほど同じ壁にぶつかる人も増えるんです。 バックログに放置されたバグ1個の修正費用は、開発段階で潰してた時より$2,480高いって分析もあるんですよ。 つまり放置する方が最後は高くつくってことです。
Figmaが実験したやり方 — MOSF 事例
Figmaが紹介した事例は、仮想の博物館サイト 'Museum of Speculative Futures(MOSF)' です。Figmaのエージェントが初来訪者、会員、スクリーンリーダー利用者といった合成ペルソナとしてサイトを事前テストして、問題を見つけたんです — ナビゲーションラベルが不明確、日付ピッカーのコントラストが低い、CTAボタンが目立たない。
ここまでは普通のQAレポートです。違ったのはそのあとなんですよ。デザイナーがGitHub リポジトリをFigma Make に接続して、現在のサイトコードから新しいブランチを作りました。そしてその日付ピッカーが3ページで使われている共有コンポーネントだってことをコードレベルで直接確認したんです。1画面だけ修正する代わりに、コンポーネント自体を一度に修正したんですよ。
| 従来のチケットワークフロー | Figma Make PRワークフロー | |
|---|---|---|
| 問題範囲の把握 | 画面単位でしか確認できない | コードレベルで共有コンポーネント まで発見 |
| 待機時間 | 期単位でバックログ積載 | 1日で配信 |
| アクセシビリティ仕様 | チケットのテキストで説明、漏れがち | aria-label ・フォーカス順序をPRで直接コメント |
| 変更記録 | チケットとコードが分離して文脈が喪失 | PR1本に意図・レビュー・決定が全部残る |
修正そのものより注目すべきはチームレビュー段階で付くコメントですね。デザイナーが作業物をチームに渡すとき、aria-label を指定して、スクリーンリーダーが読むテキストと画面に見えるテキストを一致させて、CTAまで到達できるようにフォーカス順序を直して、空状態にスクリーンリーダー用の案内文句を追加したんですよ。これ全部がコード横のコメントで残ったんです。
その次がPRですよ。デザイナーがMakeからGitHub に直接PRを上げて、エンジニアが承認してマージしたんです。Figmaのブログ表現を借りると、"PRは何が変わったかだけじゃなくて、その変更がどうやって起きたかの記録になる"ってことですね。 本来なら1期をバックログで使ったはずの修正が1日で配信されたんですよ。
なぜこれが今、できるようになったのか
このワークフローは真空から出てきたわけじゃないんですよ。Figmaは2026年6月のConfig カンファレンスで 'コードレイヤー' 機能を発表して、"コードをデザイン素材と同じように扱う"っていう方向を公式化したんです。デザインレイヤーをワンクリックかプロンプトでインタラクティブなコードレイヤーに切り替えて、既存のGitHub リポジトリをFigma Designに持ってきてデザインレイヤーと実際のGitコードを双方向で連動できるようになったんですよ。 Figma Make自体は5月末に公開されて、デザイナーがキャンバスから出ずに実際の本番コードベースをビジュアルに編集して、ブランチを作って、PRを開くまでをサポートしてるんですよ。
でもこれは "デザイナーがもうエンジニアになる"ってことじゃないんですよ。Figma自身も デザイナーがエンジニアになったり、エンジニアがデザイナーになったりする必要なく、それぞれの立場からコードにアクセスすることを目標に説明してるんです。 アーキテクチャを一から組み直す大きな作業はやっぱりエンジニアの仕事で、デザイナーは既存のコンポーネント の中で改善作業を抱えるっていう役割分けなんですよ。PRを自動マージしないでエンジニア承認を通すようにしたのも同じ文脈ですね。
うちのチームに当てはめるとしたら
- まずバックロ グを眺めてください
何期も動かないアクセシビリティチケットのうち、"画面単位では小さく見えるけど共有コンポーネント の可能性がある"っていう項目を選んでください。最初の実験対象に向いてますよ。 - リポジトリ接続権限からまず整理してください
デザイナーがGitHubブランチを作れるようにするには、リポジトリアクセス権限、ブランチ保護ルール、PR承認ラインをチーム内で先に合意しなきゃいけないんですよ。権限がないとツールが使えません。 - デザイナー側とエンジニア側の仕事をあらかじめ線引きしてください
コンポーネント再利用範囲を超えたアーキテクチャ変更はエンジニアが、スタイル・ラベル・フォーカス順序みたいな改善作業はデザイナーが — この境界線をワークフロー開始前にドキュメント化してくださいね。 - PRにアクセシビリティコメントを標準項目として入れてください
aria-label、スクリーンリーダーテキスト一致の有無、フォーカス順序、空状態案内文句 — この4つをPRテンプレート のチェックリストにするとレビューが早くなりますよ。 - 小さい事例で先に検証してください
全社ロールアウト前に、MOSFみたいに1つのプロダクト領域でアクセシビリティ修正1件を最後まで配信してみて、かかった時間とレビュー負荷を測定した上で拡大してくださいね。
もっと深く掘り下げたいときは
Workflow Lab: Deploying Designs Directly with Figma Make この記事の元になった事例が載ってるFigma公式ブログ記事です。MOSF ケースの全工程が見られますよ。figma.com
Accessibility Debt: How to Measure It and Pay It Down アクセシビリティ技術債がなぜ複利で膨らむのか、費用をどう計算するのかをまとめた記事です。testparty.ai
Web Accessibility Statistics 2026 WCAG失敗率、ページあたりのエラータイプ、米国訴訟統計まで載ってる年間リポートです。digitalapplied.com
Figma Launches Code Layers & Motion at Config 2026 Figma Make の背景にあるコードレイヤー機能の発表をまとめた記事です。cmswire.com
figma/actions-create-pull-request FigmaチームがPR自動生成に実際に使ってるGitHub Action リポジトリです。ワークフロー内部の仕組みが気になったら参考にしてみてください。github.com
本当に使えるデザインシステムを作る旅 化粧品レビューのHwahaeがレガシーコンポーネント技術債をデザインシステムに整理した国内事例です。blog.hwahae.co.kr
