修正の方向は分かっているのに、チケットしか書けないなら
Figmaの仮想ミュージアム事例では、合成ペルソナからのフィードバックにより、コントラストの低い日付ピッカーや目立たないCTAなどが明らかになりました。その後のチームレビューでは、画面上のテキストとスクリーンリーダー用ラベルを一致させること、キーボードフォーカスがCTAまで届くことも具体的な要件になりました。問題と修正の方向がこれほど明確でも、チケットに渡した瞬間、実装の順番は開発バックログ次第になります。小さく見える変更ほど、機能開発や障害対応の後に回されがちです。
Figmaが公開したWorkflow Labは、この待ち時間を別の形に変えます。デザイナーが既存コードベースで共有コンポーネントを見つけ、別ブランチで修正し、GitHub PRを提案します。エンジニアのレビュー権限とマージ権限はそのままです。実装を依頼するチケットを、レビュー可能なコード変更に変える流れです。
ただし、これを実際の顧客成果として読むべきではありません。MOSFはFigmaが設定した仮想ミュージアムであり、Workflow Labもサンプルワークフローです。原文にある「四半期中に後回しになる仕事を1日でデプロイした」という場面も、サンプルや測定方法が公開された生産性指標ではなく、事例内の物語です。
一つの画面の色ではなく、共有コンポーネントを直します
このサンプルから得るべき発見は、速度より修正範囲です。問題の日付ピッカーは、展示ページ、イベントカレンダー、会員登録フローの3か所で再利用される共有コンポーネントでした。デザイナーが現在のコード上の関係を確認したため、一画面だけを直すのではなく、コンポーネント自体への変更を提案できました。
チームがレビューしたアクセシビリティの意図も具体的でした。画面テキストとスクリーンリーダー用ラベルの一致、日付ピッカーのaria-label、CTAまで続くフォーカス順序、検索結果がないときに読み上げる空状態メッセージを確認しました。デザイナーがPRを提案した後は、エンジニアがコードをレビューし、承認・マージしました。
最初の対象は小さく、境界が明確であるべきです。既存の共有コンポーネント内で解決でき、変更ファイルと影響画面をレビューアーが狭い範囲で確認できる項目が適しています。ラベル、コントラスト、フォーカス順序、空状態の案内が候補です。状態管理やアーキテクチャを再設計する必要がある問題は、このサンプルが示した範囲を超えます。
通常のGitHubプッシュとは異なるクローズドベータです
既存リポジトリをクローンしてブランチとPRを作成するMake in your local codebaseは、限られたユーザー向けの無料クローズドベータです。承認メールを受け取ったFigmaアカウント、macOS 12以降を実行するMac、Mac向けFigma Betaデスクトップアプリ、AI機能が有効なFigma組織、アクセス可能なGitリポジトリが必要です。ウェイティングリストへの登録だけでは参加は保証されません。
通常のFigma MakeのPush to GitHubは代替手段ではありません。この機能はMakeが新規作成した専用リポジトリに結果をプッシュするため、すでに運用している製品リポジトリを選択したり、ブランチを管理したりできません。既存リポジトリをクローンして作業ブランチとPRを作る流れは、ローカルコードベースベータの対象です。
| 区分 | 通常のPush to GitHub | ローカルコードベースベータ |
|---|---|---|
| 開始点 | Makeが生成したコードと専用リポジトリ | アクセス権のある既存Gitリポジトリ |
| Git作業 | 同じリポジトリのデフォルトブランチへプッシュ | リポジトリのクローン、ローカルブランチ、プッシュとPR |
| 必須条件 | 通常のMakeにおけるアカウント別の利用条件 | 承認済みアカウント、macOS 12以降、Mac向けBetaアプリなどのベータ条件 |
最初のPRはOSと承認済みアカウントの確認から始めます
以下の手順はMOSFの結果を再現する保証ではなく、現在の公式ドキュメントに基づいて小さなアクセシビリティ変更を1件PRまで送るための最初の練習です。実行コマンドと環境変数はリポジトリごとに異なるため、設定レビューにはエンジニアが参加する必要があります。
- 承認メールを受け取ったアカウントを確認します。
ローカルコードベースの公式ガイドにあるウェイティングリスト申請確認とベータ承認メールは異なります。承認メールを受け取っていない場合は、ウェイティングリストに申請して承認を待つ必要があり、ドキュメントから機能を直接有効化することはできません。 - macOSのバージョンを確認し、Figma Betaアプリをインストールします。
Macの「このMacについて」で、まずmacOS 12以降かどうかを確認してください。12未満の場合、現在の公式最小条件を満たさないため、対応するOSバージョンへ更新するか、対応Macを用意する必要があります。続いて、公式デスクトップアプリガイドからmacOS向けBetaインストーラーをダウンロードしてインストールします。Betaアプリを開いた後、必ず承認メールを受け取ったFigmaアカウントでログインしてください。通常アプリとBetaアプリは別のインストールであり、Betaアプリを入れただけではベータ権限は付与されません。 - 組織とリポジトリのアクセス権を確認します。
該当Figma組織でAI機能が有効か確認し、使用するGitHubリポジトリURLをブラウザで開いて自分のアカウントのアクセス権を確認してください。GitHub組織所有のリポジトリであれば、公開・非公開を問わず、組織管理者がその組織にFigma GitHubアプリをインストールしたか、インストール範囲に使用するリポジトリが含まれるかを確認します。別途ターミナルアクセスやSSHキーを用意する必要はなく、最初のブランチプッシュまたはPR作成時にMakeが表示するGitHub認証を完了すればよいです。 - Betaアプリでリポジトリをクローンします。
DraftsでMakeファイルを作成し、Clone a repositoryを選択します。アクセス可能なGitHub HTTPSリポジトリURLとローカル保存フォルダを指定してから、Cloneを実行してください。クローンできない場合は、まず自分のリポジトリアクセス権と、Figma GitHubアプリが正しい組織に接続されているかを確認します。 - 実行設定と必要な認証値をエンジニアと準備します。
まずMakeで設定用の新規ブランチを作成して切り替え、現在のブランチ名を確認してください。実行設定の追加を求められたらRunを押します。すでにmainで設定ファイルが生成されている場合は、変更を保持したまま設定用の新規ブランチへ移してから進めます。Makeは通常、リポジトリルートの.figma/make配下にsetup、install、dev、verify、envファイルを自動生成します。各ファイルがリポジトリの実際のランタイムに合うかを確認し、envに必須のPORTとFIGMA_MAKE_URLを設定してください。
アプリがAPIキー、セッション、またはデータベース認証情報を必要とする場合は、先にリポジトリのローカル開発ドキュメントと既存のシークレット管理方法を確認する必要があります。シークレット値をリポジトリにコミットせず、チームが承認した方法でdevプロセスに渡してください。必要な値や読み込み方法が不明確なら、エンジニアが設定を終えるまで次の手順に進みません。 - プレビューとGitの状態を確認します。
依存関係のインストール、開発サーバーの起動、verifyが成功した後、実際のプロジェクト画面がMakeプレビューに読み込まれることを確認してください。別のプロジェクトが表示される、または実行されない場合は、ポート競合、対話型の起動コマンド、不足している環境変数、各設定ファイルの失敗段階を調べます。プレビューが表示された後もバックグラウンドビルドが続く場合があるため、30〜60秒待ってから、Gitの変更に想定外の一時ファイル・生成ファイルが大量に含まれていないか確認してください。この時間は固定の性能保証ではなく、公式トラブルシューティングガイドの待機範囲です。 - 検証済み設定をリモートmainに反映します。
設定用ブランチで検証済みの.figma/make変更をコミットし、そのブランチをプッシュして、main向けの設定PRを開きます。エンジニアが設定PRをレビュー・マージします。この過程でMakeがGitHub認証を求めた場合は、そのアカウントで認証を完了してください。リモートへの反映が終わったら、ローカルmainを最新状態に更新します。設定をmainに反映することで、以後のブランチや他のユーザーが同じ実行環境を引き継げます。 - 更新したmainからアクセシビリティ修正用ブランチを作ります。
最新のmainを基準に、別の作業ブランチを作成して切り替えます。最初の練習は、共有コンポーネント内で完結し、変更ファイルと影響画面を狭くレビューできる項目1件に限定します。 - 修正する実際の画面を指定してから、入力例を送ります。
プレビューで日付ピッカーのある画面を開き、正確なパスと要素名を記録してください。下の2つの角括弧をその値に置き換えて入力します。日付ピッカーがない場合は、実在する小さなUI問題とそのパスを指定してください。この文はMOSFで実行結果が検証された命令文ではなく、公式事例のレビュー項目を基に編集部が構成した最初の入力例です。
プレビューの[実際の画面パス]にある[日付ピッカーの名前または位置]を対象にしてください。指定した要素が見つからない場合は、推測して修正せず、位置を確認してください。見つけた要素が他の画面でも再利用される共有コンポーネントかを先に確認してください。画面テキストとスクリーンリーダー用ラベルが一致しているか、キーボードフォーカスがCTAまで届くかも確認してください。変更対象ファイルと影響を受ける画面を要約した後、現在の作業ブランチに範囲の小さい修正案を作成してください。
- 変更ファイルと実際のプレビューを確認します。
現在のブランチ、生成されたローカルコミット、修正ファイルを確認し、プレビューで影響を受ける画面を開いてください。依頼していないファイルまで変更された、または変更が共有コンポーネント外へ広がった場合は、PRの前に範囲を狭めます。 - 作業ブランチをプッシュしてPRを開きます。
最初のブランチプッシュまたはPR作成時にGitHub認証画面が表示されたら、認証を完了してください。企業で制限された認証ブラウザやハードウェアキーのためMake内で認証を完了できない場合は、組織管理者にサポート可能な認証経路を確認する必要があります。
最初の成功基準は自動デプロイではありません。実際のリポジトリのアプリがプレビューで動作し、別ブランチに意図した範囲のコミットが作られ、変更ファイル・影響画面・アクセシビリティの意図をエンジニアがレビューできるGitHub PRが開いていれば十分です。
PRはアクセシビリティ検証の出発点です
MOSFサンプルが実際のキーボードのみのナビゲーション、特定のスクリーンリーダー、自動化されたWCAG検査まで通過したかは公開されていません。コードに適切な属性があることや、合成ペルソナが問題を見つけたことだけでは、実際の使いやすさは証明されません。
マージ条件を別途決めてください。エンジニアのコードレビューと既存CIを通過した後、変更箇所をキーボードのみで操作し、チームがサポートするスクリーンリーダーで読み上げを確認してください。共有コンポーネントなら、代表的な利用画面も併せて確認する必要があります。
この方法の現実的な価値は、デザイナーがエンジニアを代替することにはありません。デザイナーは意図が明確な小さなUI修正を実行可能な変更として提案し、エンジニアは実行環境、コード構造、品質基準、マージ判断を担います。アクセシビリティチケットが長く滞留するチームなら、権限を一度に広げる前に、この境界内で小さな変更1件をPRまで送ってみてください。
さらに深掘りするなら
Workflow Lab: Deploying Designs Directly with Figma Makeでは、MOSFが仮想サンプルである点、共有日付ピッカー、アクセシビリティのレビュー項目、エンジニアによる承認・マージまで、全体の物語を確認できます。figma.com
Make in your local codebaseは、承認条件、対応リポジトリの範囲、設定のmainへの反映、GitHubアプリ、最初のプッシュ・PR認証手順を確認するための公式開始ドキュメントです。help.figma.com
Make in your local codebase: Setup, gotchas, and troubleshootingは、自動設定が失敗した場合や、開発サーバー、環境変数、ポート、バックグラウンドビルドによりプレビューが正常に開かない場合に参照する資料です。help.figma.com
