Figma Makeのクレジットをより効率的に使うための7つのヒント

1年前にFigma Makeをリリースして以来、繰り返し見えてきた傾向があります。AIを活用したプロトタイピングで最も良い成果を上げているチームは、必ずしも最も長いプロンプトを書いているチームではありません。成果を上げているのは、作業環境を適切に整え、変更範囲を的確に絞り込み、コラボレーションに合わせてコンテキストを効果的に管理・活用できているチームです。

これらの7つのヒントは、Makeでも同様に役立ちます。

1. 最初のプロンプトで土台を作り切る

最初のプロンプトは、プロジェクトの構造を定義し、制約条件を設定する役割を持ちます。スタート時点がより完全であるほど、後から修正に費やす時間は少なくなります。

目安としては、最初のプロンプトを「ブリーフ」として扱い、その後のすべてのやり取りを「差分」と考えることが有効です。つまり、最初のプロンプトには以下の内容を含めるべきです:

• 目標
• コンテキスト
• すべての主要な要素、挙動、および制約
• 最終的に「完成」となる状態がどのようなものか

しっかりした土台ができていれば、その後のプロンプトはより小さくできます。良いものは通常、一般的に次の3つを含みます:

• 何を変更するか
• どのように変更するか
• 何をそのままにしておくか

大規模な構築では、作業を段階に分けることを検討します。まずはコンテンツの詳細にあまりとらわれずに、プロジェクトの構造を正しく設計します。構造は、開発が深く進んでからでは最も変更しにくい要素になりがちです。次にインテリジェンスや振る舞いを追加し、その後にコンテンツや仕上げの調整を行います。

フォローアッププロンプトでは、複数の変更を1つにまとめすぎないようにします。ただし、同じロジックやUIに対する関連した修正であれば例外です。もし3つの編集が同じコンポーネントに影響する場合は、それらを1つのリクエストにまとめた方が、複数回に分けるよりも効率的です。

いずれにしても、フォローアッププロンプトはできるだけスコープを絞った方がうまく機能します。Makeに対してどの部分をどう変えたいのかを具体的にするほど、効率は高くなります。例えば、「カレンダーコンポーネントを更新する」「この画面に新しい状態を追加する」「あるいは tokens.ts ファイルを編集する」といった指示は、「それは違うのでやり直してもらえますか?」よりもはるかに明確にMakeへ意図を伝えます。具体的なプロンプトは、Makeに対して「どこを見て、何をすべきか」を正確に伝えます。一方で曖昧なプロンプトは、Makeが意図を解釈し、最適な方法を推測する必要があるため、余分なコストが発生します。

2. 一部の変更は手動編集を優先する

Makeを最大限活用しているチームは、いつプロンプトをやめて直接編集に切り替えるべきかも理解しています。余白の微調整、要素の削除、テキストの調整といった小さなビジュアル変更では、編集ツールが最も素早い手段になることが多いです。これにより、問題全体を再度開き直すことなく、ピンポイントで調整を行うことができます。それが重要なのは、多くのフォローアッププロンプトが実際には新しいデザイン課題を解決することを求めているわけではなく、すでにほぼ正しくできているものを少し調整することを求めているだけだからです。

コードでも同じことが言えます。Makeにおける最も効率的な変更のいくつかは、ソースに直接ジャンプし、関連する値を編集することで実現されます。これは特に、プレビューだけでは編集できない動的な要素において有効です。たとえば、繰り返しコンポーネント内のテキストを更新する必要がある場合や、同じフォルダ内のリストから取得されているデータを変更する場合などです。プロンプトで望む出力に近づけていく代わりに、ソースへ移動を使ってコードを検索し、そのデータが存在する場所で直接変更を加えることができます。

この恩恵を受けるために、必ずしも開発者である必要はありません。Makeのコードは十分に読みやすく設計されているため、特にすでにどの要素や挙動を調整したいか分かっている場合は、必要な箇所を見つけることができます。

大きなビジュアル変更を行う場合は、Figma Designのキャンバスを使うことをおすすめします。デザインをコピーを使えば、Makeのプレビューを編集可能なレイヤーとしてFigma Designに取り込み、使い慣れたツールで変更を加えた後、その変更内容を1つのプロンプトでMakeへ反映できます。このようなハイブリッドなワークフローは、ビジュアルの調整を何度もプロンプトで指示するよりも、はるかに効率的な場合があります。例えば、デザイナーアドボケイトのMiggi Cardonaは、ダークモードで生成された機能的なオーディオアプリをキャンバスにコピーし、そこでライトモード版を作成した後、そのデザインをコンテキストとしてMakeに戻し、プロトタイプを更新しました。必要だったのは1つのプロンプトだけ。解釈や推測に頼る必要はありません。シンプルで効率的です!

重要なのは、プロンプトを最も適した用途に限定することです。つまり、生成・推論・大きな変換といった作業に使い、作業がよりビジュアル中心になる場合は手動編集を選ぶことです。

3. 繰り返しのプロンプトをルールやワークフローに変える

同じ指示を何度も繰り返している場合は、その内容をプロンプトから切り出すタイミングです。ここで重要になるのが、guidelines.mdのようなマークダウンファイルです。AIを活用しているチームの多くは、これらを「あると便利なもの」ではなく、「プロジェクト要件」として体系的に扱っています。

適切なguidelines.mdファイルには、プロジェクト全体でMakeに従わせたいルールがまとめられています。

• デザインシステムに含まれるもの
• 従うべき命名規則
• 優先すべきパターン
• 目指すべき品質基準
• 共通の判断における正しい参照元がどこにあるか

再利用可能なプロジェクトメモリのように考えます。Makeが常に参照すべきルールや参照情報を保持しておく場所です。毎回再学習する必要がないため、得られる効果は二重です。プロンプトの繰り返しが減り、初回の出力精度も向上します。

ここでは構造が重要です。単一の巨大なマークダウンファイルが常に最適な解決策とは限りません。多くの場合、1つの主要なガイドラインファイルと、コンポーネント、モーション、トークン、コンテンツパターンなど特定のトピックごとに分けた小さな補助的な .mdファイルを用意する方が、より整理されます。これらのファイルがモデルにとって読みやすいほど、その有用性は高まります。明確なセクション見出し、一貫したラベル、セマンティックな命名、そして冗長性の削減がすべて役立ちます。

Skills.mdファイルは、繰り返し発生するものが単なるコンテキストではなく、ひとつのワークフロー全体になっている場合の次のステップです。Guidelines.mdとskills.mdは、どちらもマークダウンファイルであるため混同されやすいですが、本質的にはどちらもMakeがより信頼性の高い出力を行うためのプレーンテキストの指示です。違いは、それぞれが果たす役割にあります:

• ガイドライン: Makeプロジェクトがバックグラウンドで常に保持する、常時有効な環境的なプロジェクトメモリ
• スキル: 特定のタスクが必要とする場合に呼び出すオンデマンドのワークフロー

ガイドラインがMakeに「何を知っているべきか」を伝えるものだとすれば、AIスキルは「何をすべきか」を伝えるものです。スキルは、繰り返し行うタスクのための手順書のようなものです。たとえば、画面をデザイン基準に照らしてレビューすること、製品開発ロードマップ(PRD)をもとに構築すること、プロダクトのコピーをチェックすること、あるいは特定の種類のインターフェースを生成することなどです。毎回同じような長いプロンプトを書き直す代わりに、そのプロセスをスキルとして定義し、必要なときに呼び出すことができます。

4. 外部コンテキストは必要に応じて取り込む

guidelines.mdが常に参照する指示を保存する場所だとすれば、MCPコネクターは、タスクの実行に必要な外部コンテキストを取得するための仕組みです。

コネクターは、Makeがプロジェクト自体の情報だけではなく、ライブ仕様書、チケット、デザインシステムのリファレンス、技術文書、バグレポート、他ツール上のワークスペース、あるいは社内の独自システムなどにアクセスする必要がある場合に最も効果を発揮します。ただし、コンテキストは多ければ多いほど良いというわけではありません。

Makeに大規模な外部情報源を指定しながら、どこに注目すべきかを明示しないことは、タスクを必要以上に難しくしてしまう最もよくある原因の一つです。膨大なNotionページ、広範囲なJiraやLinearのクエリ、あるいはコネクタ経由でワークスペース全体を対象とした曖昧な検索は、いずれもノイズを増やしてしまいます。その結果、モデルは「何をすべきか」だけでなく、「どのコンテキストがそのタスクに本当に関連しているのか」まで判断しなければならなくなります。

より良い方法は、取得するコンテキストをできるだけ限定することです。参照すべきドキュメントを正確に指定し、該当するチケットへのリンクを示し、対象となるファイル、エラー、コンポーネントを明確に伝えます。Makeが必要とするのが1つの段落や1組の要件だけであれば、答えを探させるのではなく、その該当箇所を直接貼り付けることも検討してください。

このような場合には、ファイル添付も有効です。作業にライブソースが必要であれば、コネクターを使うのが適しています。一方で、すでに手元にある特定のファイルをもとに作業するのであれば、それらをプロンプトに直接添付した方が、より効率的です。リサーチ結果をまとめたPDFを添付すれば、Makeはその内容をもとに作業できます。CSVデータセットを添付すれば、ダッシュボードやテーブル、プロフィール画面などに実際のデータを反映できます。動画やメディアアセットを添付すれば、プレースホルダーを生成する代わりに、実際の素材を埋め込むことができます。

いずれの場合も目的はシンプルです。Makeができるだけ効率よく作業できるよう、元となる情報をそのまま提供することです。ここでもAIスキルが役立ちます。コネクター、カスタムMCP、ファイル添付を利用する際の具体的な手順をMakeに与えることで、より制御しやすく、予測可能で、効率的な出力を得られます。重要なのは、コンテキストをできるだけ増やすことではなく、Makeに適切なコンテキストを与えることです。

5. 再利用できる土台を作り、スケールさせる

Makeで最も効率よく開発を進める方法は、毎回同じUIをゼロから作り直さないことです。Makeキットとテンプレートは、あらかじめコンテキストや再利用可能なパターン、さらには動作する基本構造まで備えた出発点を提供します。これは、不要な手戻りを減らす最も簡単な方法の一つです。再利用可能な土台を用意しておけば、何もない状態からプロンプトを書く必要がなくなり、ハルシネーションのリスクも抑えられます。また、チームのより多くのメンバーが、すぐにしっかりとした出発点から作業を始められるようになります。

Makeキットは、共有できるシステムの構成要素と考えると分かりやすいでしょう。Makeでゼロからプロジェクトを立ち上げる際に、基盤、トークン、コンポーネント、guidelines.mdなどをチーム全体へ展開し、再利用しやすくするための仕組みです。Reactコンポーネントがnpmパッケージとして提供されているチームでは、この仕組みは特に強力です。Makeキットを使うことで、開発チームが本番環境で使用しているコンポーネントやパターンをプロジェクトに取り込むことができ、一から近いものを生成する必要がなくなります。

一方、テンプレートは、プロダクトの基本構成、推奨レイアウト、さらにはスタータープロンプトなど、チームが繰り返し利用できる出発点を提供します。これは、AIの習熟度が異なるメンバーや複数のプロダクト領域にまたがってMakeを展開する大規模なチームにとって、特に有効です。例えば、デザイナーアドボケイトのLaura Fehreが公開しているオープンソースのSAPテンプレートには、すべてのプロダクトで共通して使用される固定UI要素(ヘッダーやナビゲーション)に加え、それらがプロンプトによって簡単に変更されないようにするための厳格なガイドラインが含まれています。さらに、このテンプレートには、必要に応じて特定のテーマやレイアウトをすばやく生成できる「レシピ」も用意されています。これらのレシピは、テンプレートのUI内にコードベースのプロンプトとしてあらかじめ組み込まれており、クリックしてコピーし、そのままMakeに貼り付けて使用できます。

このような仕組みには、2つの効果があります。テンプレートをすぐに活用できるようにすると同時に、使い方そのものをユーザーに自然と学んでもらえることです。その結果、手戻りや行き詰まりが減り、チームが本当に作りたいプロトタイプへ、より確実にたどり着けるようになります。

6. 用途に応じて適切なモデルを選ぶ

すべてのMakeワークフローに最適なAIモデルは1つではありません。適切なモデルは、タスクの内容によって異なります。たとえば、複雑さ、必要な推論の量、添付するビジュアルコンテキストの量、そして求められる出力の完成度などによって変わります。

ひとつの目安として、そのタスクを十分にこなせる範囲で、できるだけ軽量なモデルを選ぶことをおすすめします。

小さな変更や定常的な反復作業であれば、Gemini Flashのような軽量モデルがより適しています。一方で、より曖昧な要件を含む作業、難易度の高いデバッグ、強い推論能力が必要なケース、あるいは高いビジュアル忠実度を維持する必要がある場合には、Claude Opusのような高性能モデルの方が、コストは高くなるものの、より早く良い結果に到達できることがあります。そのようなケースでは、最初に少し多めに投資することで、弱い初期出力を何度も修正するよりも結果的に効率的になることがあります。

これは特に、新しいMakeファイルを立ち上げるときや、リッチなビジュアルコンテキストをプロンプトに添付する場合に当てはまります。既存の方向性にMakeを揃えたい場合、デザインモックアップの添付は非常に有効です。ただし、デザインファイルが複雑になるほど、Makeはその内容を解釈する必要が増えます。大量のコンテキストを一度にMakeへ投入する場合は、複雑さを十分に処理できるモデルを使うか、あるいは現在のステップに本当に必要な情報だけにコンテキストを絞ることが重要です。

また、長く続くMakeプロジェクトほど、時間とともに重くなるという点にも注意が必要です。チャット履歴が蓄積されるにつれて、各ターンでMakeが参照するコンテキスト量は増えていきます。その結果、特に高コストなモデルを使っている場合は、コストが累積的に増加する可能性があります。そのような場合には、チャットコンテキストをクリアすることで、プロジェクトを中断したり新しいファイルにすべて移行したりすることなく、Makeによりクリーンな状態を与えることができます。

7. 自動化する価値のあるものを見極める

最後に、Makeから最も価値を引き出しているチームは、単に個人に使い方を教えることにとどまっていません。彼らは、チームとしてどこにMakeを組み込み、どこでは使わないのかを一緒に判断しています。

それは、Makeを既存デザインの具現化に使うことに限定し、曖昧さや試行錯誤が価値を持つ0→1の探索には使わない、という判断かもしれません。また、プロトタイピングの加速には使う一方で、チームがすでに素早く確信を持って進められている領域では、手作業の設計を置き換えないという判断もあり得ます。さらに、テンプレートやガイドライン、キットへの投資を重視するのも一つの選択です。なぜなら、その効果は時間とともに複利的に積み上がっていくからです。

すべてのタスクが同じように自動化の恩恵を受けるわけではありません。優れたチームは、Makeがレバレッジを生む領域、人間の精度が最も重要な領域、そして事前の少しの準備が後の大きな手間を減らす領域を見極めています。

目的はすべてを自動化することではなく、何をどのように自動化するかをより良く判断することです。ときには、少し多めの初期投資こそが最も効率的な選択になります。より良いテンプレート、明確なガイドライン、整理されたプロンプト、あるいはチーム共通のプレイブックといったものです。その結果として、すべてのプロジェクトがより強い土台から始められるようになります。

Figma Makeのクレジットを活用するためのプロンプト最適化について詳しくは、ヘルプセンターをご覧ください。Makeをより効果的に使うための他のアプローチがあれば、ぜひ教えてください。オンラインやFigma Forumで、ぜひあなたの取り組みを共有してください。