Figma Make でワイヤーフレームを作る前の下準備：4つの .md ファイルで AI の揺らぎを抑える

AIDD デザイン室の岩野です。Figma Make でワイヤーフレームを作成するとき、いきなり画面を作らせるのではなく、rule.md や question.md といった .md ファイルを先に用意しています。この記事では、その下準備の中身と、AI と対話しながら小さく進める作成フローを紹介します。

---

ワイヤーフレームの位置づけ

前提として、ワイヤーフレームで何を確認したいのかを先に決めています。目的は次の2点です。

• 画面ごとの情報設計を確認したい
• 画面遷移を確認したい

ワイヤーフレームは検証用のツールと位置づけ、デザインには引き継ぎません。デザイン作業に入る時点で破棄する前提です。ワイヤーフレームをそのままデザインに進化させる考え方もありますが、ここでは採用していません。

また、ワイヤーフレームを作る時点では、要件定義書のような詳しい資料はまだ揃っていないことがほとんどです。要件定義の前段くらいの資料しかない状態から作り始めるイメージで読んでください。

全体のワークフロー

イメージしているワークフローは次の6ステップです。

1. Figma Make に資料を読み込ませる
2. Figma Make に .md ファイルを作成してもらう
3. Figma Make でワイヤーフレームを作成する
4. 作成中に不明だった点を開発メンバーやお客様に質問する
5. 回答をもとにワイヤーフレームを修正する
6. 手順3に戻って繰り返す（必要になれば .md ファイルも追加する）

ポイントは、作り始める前に .md ファイルという「AI に守ってほしいルールと記録の置き場」を用意しておくことです。

下準備で用意する4つの .md ファイル

Figma Make はチャットで「こういう内容の .md ファイルを作ってほしい」と頼むと作成してくれます。最初に用意しているのは次の4つです。

必要に応じて actor.md や layout.md なども追加します。

flow.md には、機能を作って画面遷移を確認し「この流れで FIX」と判断したものを記録します。あわせて rule.md に「flow.md で FIX した画面遷移は勝手に変えない」というルールを入れておきます。

word.md は用語の揺らぎ対策です。AI の出力はデザインにも揺らぎが出ますが、いちばん気になるのは用語の揺らぎなので、プロジェクト内で使う文言をここで定義します。

question.md は質問と回答のログです。rule.md に「不明点はあなたの想像で補完せず、私に質問してください」と書いておき、AI が質問してきた内容とそれへの回答をすべて記録してもらいます。

rule.md に書いている基本原則と禁止事項

rule.md の基本原則は4つです。

• 段階的実装: 一気に実装せず、指示を受けて分割で実装する
• ドキュメントファースト: 実装前に必ず添付資料や他の .md ファイルを参照する
• 一貫性の維持: CSS Variables・コンポーネントルール・命名規則を遵守する
• 拡張性の確保: 「こういう場合はこの .md ファイルを参照する」という形で、ルール自体を後から追加できるようにしておく

禁止事項は3つです。

• ドキュメントを参照せずに独自実装すること
• flow.md で FIX された画面遷移を無断で改変すること
• CSS Variables を使わず、色やサイズをハードコードで指定すること

この辺りは、プロジェクトに合わせて増やしていけばよいと思います。

実際のワイヤーフレーム作成フロー

下準備ができたら、次の流れで作成を進めます。

1. 指示出し: 資料を添付し、作りたい機能を伝え、プロンプトの最後に「rule.md を読んでから作業を開始して」と添えます。こう言わないと rule.md を読まないことがあるため、最初の画面を作成するときと大規模な修正をするときは必ず付けています
2. AI への回答: 不明点は AI が質問してくるので答えます。仕様が固まっていない部分も「多分こういう仕様だろう」という想定でいったんすべて回答し、後で確認して直す前提にします。このやりとりは question.md に記録されます
3. 確認・記録: できあがった画面遷移を確認し、問題がなければ「この一連の流れを flow.md に記録して」と頼みます
4. 質問の抽出: その日の終わりに「本日の質問事項を出力して」と頼むと、question.md からその日の質問と回答の一覧が出てきます。その中から、開発メンバーやお客様に確認しないと分からないものを抜き出してスプレッドシートにまとめ、確認を依頼します
5. フィードバック反映: 回答が想定と違っていたらワイヤーフレームを修正し、手順1に戻ります

AI と対話しながら小さく進めるのが基本方針です。.md ファイルをしかるべき場所に置いておけば大きく任せても大丈夫、という考え方もありますが、LLM は推論しながら作っていくため、一気に作らせすぎない方がよいと感じています。

AI で作業するメリット

作業が速いという分かりやすいメリットに加えて、個人的に便利だと感じているのは次の2点です。

• AI は、自分（AI）が分からないことをすぐに答えられる。人間だと「何が分からないのかが分からない」ことも多いですが、AI に対して「今分からないことは何？」と聞けば具体的な質問が返ってきます
• AI は、作業の進捗や残りのタスクをすぐに答えられる。ディレクターとして進行を把握するうえで助かっています

AI で作業する際の注意点

メリットと表裏一体の特性として、次の点には注意が必要です。

• AI は変にデザインしようとすることがあるので、細かな指示やルール設定が必要です
• AI は統一の優先度が低い場合があるため、layout.md や word.md による明示的な指定が欠かせません
• LLM の推論モデルという特性上、ページごとのアウトプットは揺らぐため、導線チェックと flow.md への記録が必要です
• AI は時々 rule.md の存在を忘れます。「rule.md って何ですか？」と返ってきたら、焦らずに「あなたが持っているはずだから検索してみて」と促すと、見つけて読んでくれます

このあたりは、今後ツールが進化すれば解消されていくかもしれません。

まとめ：小さく試してから広げましょう

最後に、Figma Make に限らず AI と作業するうえで意識していることを3つ挙げます。

• タスクの再細分化: 自分が抱えるタスクを細分化し、どの部分を AI に任せればよいか考える。「そもそもなぜこの作業をやっているのか」も合わせて考えると、作業自体が不要だったり、他と統合できたりという発想にもつながります
• AI への的確な指示: AI は命令が適当だと出力も適当になります。解釈の余地が大きい指示は、意図しない解釈をされることがあるためです。質の高いアウトプットには、事前の資料やルールを AI が分かりやすい形で読み込ませる必要があります。AI には .md ファイルを渡し、人間が見るものは HTML で書く、という流れができつつあるように思います
• コンテキストの共有: 「いつ・誰が・どこで・どういうフローで使うのか」「現在の課題は何か」「それに対してどうあるべきか」を伝えると、アウトプットの質が上がります

みなさんも是非、小さく試すところから始めてみましょう！