Figma流プロンプト術TC-EBCで品質UP

この記事の注目ポイント
Figmaの公式記事「Cooking with Constraints: A Designer’s Framework for Better AI Prompts」は、AIに“いい感じでやって”と言うのをやめて、出力の再現性を上げるためのプロンプト設計フレームワークを提案しているよ。
名前はTC-EBC（Task / Context / Elements / Behavior / Constraints）。要件をこの5つに分解して渡すと、AIの出力がブレにくくなる、という話。

ここからは、フロントエンド・PM・デザイナー混在の日本の現場向けに、3分で「なぜ効くの？どう使うの？」を噛み砕くよ。
結論：AI活用の勝負は“プロンプトのうまさ”じゃなく、制約（Constraints）を言語化できるかに寄ってきてる。

深掘り解説
まとめ
1. 参考リンク

深掘り解説

まずTC-EBCの中身をざっくり。
Task＝何を作る？
Context＝どんな状況で誰が使う？（背景）
Elements＝必要なUI要素は？（部品）
Behavior＝どう動く？（状態/バリデーション/エラーなど）
Constraints＝守るルールは？（触らない場所/制約/トーン）

専門用語メモ：
Constraintsは「制約」って意味。デザインで言う“グリッド/余白/アクセシビリティ”、開発で言う“フレームワーク/実装ルール/禁止事項”みたいなやつだよ。
ここが弱いと、AIは普通に暴走する（それっぽいけどズレたものを出す）。

このフレームが現場で強い理由は2つ。

要件の抜け漏れが減る
PMが曖昧に投げがちな「状態（loading/error/empty）」が、Behaviorに自然に入る。
デザイン⇄実装の翻訳がラクになる
Elements/Behavior/Constraintsが揃うと、デザイナーの意図が“仕様”として残る。

さらにFigmaの記事は「prompt engineering」だけじゃなく、文脈を整えるcontext engineeringにも触れてる。
Figma Makeみたいな“プロンプト→UI生成”だと、スクショよりFigmaのフレーム（構造化データ）を渡す方が精度が上がりやすい、という考え方だね。

ここから実践。まずはそのまま使えるテンプレを置いとくよ。
（PMはこのままチケットに貼ってもOK）

Task: 何を作る？（1行）
Context: 誰が/いつ/なぜ使う？
Elements: 必要なUI要素（箇条書き）
Behavior: どう動く？状態・バリデーション・エラー
Constraints: 守るルール（触らない所/デバイス/トーン/技術制約）

フロントエンド向けに、Constraintsの例をもう少し具体化するとこんな感じ。

Constraints:
- React + TypeScript- Tailwindを使用（CSSファイルは作らない）
- a11y: ボタン/入力にaria属性、ラベル必須
- レイアウトは8ptグリッド、角丸12px
- 既存のデザイントークン（--ds-)を必ず使う
- 触らない: 既存のHeaderコンポーネントは変更禁止

これを入れると、AIが「勝手にCSS書き出す」「意味不明なコンポーネントを増やす」「トークン無視で色を決める」みたいな事故が減る。
つまり、AIを賢くするんじゃなくて、現場のルールをAIが守れる形にするのがコツ。

もう1つ、地味に効くのが“修正プロンプト”。
AIに直してもらうときは、何を変えるかだけじゃなく、何を変えないかもConstraintsに書くと安定するよ。

変更してほしい:
- ボタン文言を「保存」に
- 無効状態（disabled）を追加変えないでほしい:
- 余白とフォントサイズ
- 既存コンポーネント階層
- 色トークン（--ds-)

PM/ビジネス側にも嬉しい話で、TC-EBCは「要件をちゃんと書けるチーム」ほど伸びる。
AIを入れても遅いチームって、だいたいここが曖昧で手戻りが増えてるんだよね。

まとめ

FigmaのTC-EBCは、プロンプトの小手先テクじゃなくて、要件定義をAI向けに再設計するフレームだよ。
Task/Context/Elements/Behavior/Constraintsで分けるだけで、出力のブレが減って、手戻りも減る。

まずは次の1タスクだけでOK。
いつもの依頼文を、TC-EBCで書き換えて投げてみて。
“それっぽいけど違う”が減って、チームの速度が一段上がるはず。

参考リンク

※内容の正確性には万全を期していますが、最新の仕様や公式情報については、必ず上記の参考リンク先をご確認ください。