曖昧な依頼から、既存デザインを活かしたPRまで〜Figma・GitHub・Skillsをつなぐ実務フロー〜

「この画面を、今日中にいい感じにしてください」

と口頭で頼まれても、そのままFigmaやコードを触り始めてはいけません。

依頼者が本当に変えたいのは、色や余白ではなく、「初めての人が次の操作へ進めない」「重要な情報を見落とす」といった利用者の行動かもしれないからです。

急いで新しく作った後に、同じ画面や部品がFigmaとGitHubにあったと分かれば、制作時間だけでなくレビューや保守の負担も増えます。

この記事では、曖昧な依頼を一度入力すると、AIが緊急度を整理し、普段から更新しているデザイン台帳を検索し、FigmaとGitHubの最新状態を確認してから、再利用・一部改修・組み合わせ・新規制作のどれが適切かを提案する仕組みを紹介します。

方針を人が承認した後は、Claude Codeによる実装、検証、Pull Requestの下書きまでをSkillsでつなぎます。

利用者が毎回10個の手順を覚える必要はありません。

人が行うのは、AIだけでは決められない質問への回答、実装計画の承認、最終レビューと公開判断です。

対象は、Webサイト、管理画面、SaaS、アプリなど、Figmaと実装コードの両方を扱うデザイナーやフロントエンド開発者です。

初めてSkillsを作る人でも試せるように、仕組み、作り方、PCでの起動方法を順番に説明します。

FigmaやClaude Codeの機能は更新されるため、この記事の操作情報は2026年8月26日に公式情報を確認した内容です。

見出し画像はAIで生成しました。
プロンプトは下記の記事に掲載中。
毎日プロンプトは増えていきます。

デザイン制作の本当の負担は「制作前後の翻訳」にある

デザイン制作の負担は、画面を作る時間だけではありません。

依頼者の言葉を画面要件へ変え、Figmaを実装者が読める情報へ変え、実装結果を依頼者が判断できる形へ戻す「翻訳」に時間がかかります。

よく起きる問題は次のとおりです。

• 「いい感じに」「今風に」と言われ、何を直せば合格か分からない

• 「今日中に」と言われ、理由や最低限必要な範囲を確認せず全部作り始める

• 依頼者が言った解決案を、そのまま本当の課題だと思ってしまう

• FigmaやGitHubを探す前に、新しい画面や部品を作ってしまう

• PC版のFigmaだけを見て、スマートフォンや長い文章を忘れる

• 通常画面は作ったが、空・読込中・エラー・権限不足の状態がない

• Figmaの色や余白を、既存コードの変数や部品へ結び付けられない

• GitHubから取得したプロジェクトの構造を読まず、新しい部品を増やしてしまう

• AIが広い範囲を書き換え、別の画面まで変わってしまう

• 「Figmaに似ている」だけで合格にし、操作や読みやすさを確認していない

• 修正理由と確認結果が残らず、後から作業する人が同じ調査を繰り返す

この問題を防ぐ合言葉は、「作る前に探す」です。

AIが依頼を受けたら、既存資産を探し、最新状態を確かめ、使える理由または使えない理由を示してから制作方針を提案します。

解決のポイントは、AIへいきなり「作って」と頼まないことです。

先に、変える理由、変えない場所、正しい情報の置き場所、完成の確認方法を決めます。

1回の起動で、ヒアリングからPR準備までつなぐ

手作業を減らすには、作業ごとに別のプロンプトを探すのではなく、入口となるSkillsを一つにします。

Skillsとは、繰り返し使う手順や判断基準を`SKILL.md`へ書き、AIに同じ進め方を再利用させる仕組みです。

この記事で提案する入口は`design-direction`です。

この記事では、`design-catalog`と`design-direction`という二つのSkillsを自分で作ります。

Claude CodeやCodexへ最初から入っている機能ではありませんが、後半に掲載する`SKILL.md`を保存すれば試せます。

以下のコマンドは、Skillsを作成・インストールし、FigmaとGitHubの接続を設定した後に使えます。

Figma公式の接続機能と、この記事で作るSkillsは別のものです。

Claude Codeでは`/design-direction`、Codexでは`$design-direction`と入力し、元の依頼、FigmaのURL、GitHubのURLまたはPC内のプロジェクトフォルダを渡します。

# Claude Code
/design-direction
依頼：案件が0件の画面を、初めての人にも分かりやすくしたい
Figma：対象フレームのURL
GitHub：リポジトリのURL

# Codex
$design-direction
依頼：案件が0件の画面を、初めての人にも分かりやすくしたい
Figma：対象フレームのURL
プロジェクト：PC内のフォルダ

`direction`は、方針を定め、関係する工程を指揮するという意味です。

`design-catalog`は、普段からFigmaとGitHubの既存資産を調べ、ローカルのデザイン台帳を更新します。

`design-direction`は、依頼を受け、台帳と最新データを確認し、制作方針からPR準備までを進める司令塔です。

`design-direction`の内部では、次の5工程を順番に動かします。

1. 依頼整理：曖昧さ、緊急度、目的、最低限必要な範囲を整理する

2. 資産確認：デザイン台帳を検索し、候補をFigmaとGitHubで再確認する

3. 方針提案：再利用、一部改修、組み合わせ、新規制作を比較する

4. 実装：承認された方針を、既存ルールに合わせて最小差分で実装する

5. 検証とPR準備：画面、状態、コード差分を確認し、説明文を作る

`design-catalog`だけは、`design-direction`から分けておく方が実用的です。

依頼の有無に関係なく定期更新する仕事と、依頼を受けて動く仕事では、開始条件と権限が異なるからです。

利用者が普段覚える入口は`design-direction`だけで構いません。

処理の流れは「知る・考える・行う・確かめる」の4段階です。

知る
依頼者、利用者、現行画面、Figma、コード、制約を確認する
        ↓
考える
本当の課題、変更範囲、状態、完成条件を変更票へまとめる
        ↓
行う
Figmaまたはコードを、既存の部品とルールを使って直す
        ↓
確かめる
画面、操作、状態、端末差分、コード差分を人がレビューする
        ↓
Pull Requestで変更理由と確認結果を共有する

`design-direction`は、`design-catalog`が作った台帳を読み、候補となるFigmaの部品とコードの部品を結び付けます。

その結果から制作方針と実装計画を作り、同じ完成条件を使って実装とレビューを進めます。

保存先は、例えばプロジェクト内の`.design-work/案件名/`に統一できます。

依頼原文、変更票、調査結果、確認記録を同じ場所へ残せば、作業を中断したときや別の人へ引き継ぐときも、最初から説明し直す必要がありません。

`.design-work/`は案件ごとの記録、後で作る`.design-library/`は複数案件で再利用するデザイン台帳です。

ただし、Skillsだけで何でも自動化するのは危険です。

停止条件は、次の5つに統一します。

1. 不足情報を推測すると、目的や変更範囲が変わるとき

2. ファイルを初めて変更する前に、実装計画と変更範囲を承認するとき

3. 承認した対象以外へpush、コメント、Pull Request作成などの外部書き込みを行うとき

4. 基準ブランチへの取り込み、公開、納品を行うとき

5. 権限不足、未コミットの変更、競合、テスト失敗、台帳候補の最新状態を確認できない、Figmaとコードの矛盾が見つかったとき

作業ブランチへのpushとPull Request作成は、対象リポジトリ、ブランチ、説明文を事前に示せる場合に限り、一つの承認へまとめられます。

基準ブランチへの取り込みと公開は、その承認に含めません。

これら以外は、与えた権限とプロジェクトのルールの範囲でAIに連続処理させられます。

ここで大切なのは、Figmaとコードを別々の仕事にしないことです。

同じ変更票に、利用者の課題、対象フレーム、対象コード、変えない範囲、完成条件を書きます。

Skillsは作業手順を再利用するためのもので、FigmaやGitHubへ接続する権限そのものではありません。

外部サービスへ接続するときは、自分がアクセスを認められた対象だけを選びます。

管理されたアカウントを使う場合は、その管理者が定めた権限と保存ルールにも従います。

普段から、既存デザインを台帳へまとめておく

AIに既存デザインを把握させる方法は、過去の会話を覚えさせることではありません。

FigmaとGitHubの場所、用途、状態、更新日を記録した「デザイン台帳」を作り、必要なときに検索できるようにします。

最初は、対象プロジェクトの中へ次のフォルダを作ります。