プロトタイピングの再定義：Figma VariablesとConditional Logicによる「カート機能」の極限実装
Figmaのプロトタイピングは、かつて「遷移のシミュレーション」に過ぎなかった。しかし、VariablesとConditional Logicの登場により、我々はついに「ロジックを内包した実行環境」を手に入れた。
本稿では、単なる画面遷移の再現を超え、Eコマースにおける「動的なカート機能」を、コンポーネント指向の極致として構築するアーキテクチャを解説する。これは単なるデザインではない。プロトタイプという名の「ソフトウェア実装」である。
—
1. 条件分岐（Conditional Logic）がもたらすパラダイムシフト
従来のプロトタイプは、状態遷移図をなぞるだけの「線形的な体験」だった。しかし、Conditional Logic（If/Else）の導入により、プロトタイプは「状態保持（State Management）」を獲得した。
ここで重要なのは、「FigmaをUIツールではなく、ステートマシンとして捉えること」だ。
カート機能において、ユーザーが「追加」ボタンを押すたびに、変数は以下の計算を行う必要がある。
- `item_count`++
- `total_price` += `product_price`
- `is_empty` = `item_count == 0`
この「計算」をデザインファイル内に実装することで、エンジニアは「ここから先はサーバーサイドのロジックで制御」という阿吽の呼吸を、プロトタイプ段階で共有できる。
—
2. カート機能のアーキテクチャ：Variablesの正規化
高度なプロトタイプほど、複雑な変数管理で自滅する。まずは、変数を「論理層」と「UI層」に分離し、グローバルで管理すべき。
推奨する変数構成
- `cart_quantity` (Number): カートに入っている総数
- `cart_total` (Number): 合計金額
- `is_max_reached` (Boolean): 在庫上限判定（UXの制約条件）
実装手順：動的カートのロジック
1. コンポーネントのプロパティ化: ボタンコンポーネント内に「価格」という変数をバインドする。
2. Conditional Actionの連鎖:
「ボタンクリック」→「If (cart_quantity < 99)」→「cart_quantity + 1」→「cart_total + product_price」というアクションのスタックを構築する。
3. 表示のリアクティブ化:
Figmaはリアクティブではない。しかし、`cart_total`変数をテキストレイヤーにバインドすることで、擬似的な双方向バインディングを実現できる。
—
3. DevOps的アプローチ：自動化とパフォーマンス最適化
我々エキスパートにとって、Figmaはあくまで「フロントエンド実装への橋渡し」に過ぎない。手動での変数構築はバグの温床だ。
Figma APIによる変数自動構築（TypeScriptスクリプト）
複雑なカートロジックをGUIでポチポチ設定するのは非効率だ。Figma Plugin APIを使い、外部のJSONスキーマから変数を生成せよ。
// カート変数を一括定義する内部スクリプトの例
const createCartVariables = async () => {
const collection = await figma.variables.createVariableCollectionAsync(“CartLogic”);
// カートの計算ロジックを管理する変数を自動生成
const qVar = await figma.variables.createVariableAsync(“quantity”, collection.id, “NUMBER”);
const pVar = await figma.variables.createVariableAsync(“total_price”, collection.id, “NUMBER”);
console.log(`Cart Architecture Initialized: ${qVar.id}, ${pVar.id}`);
};
// 実行することで、手作業によるIDの不整合を排除する
createCartVariables();
パフォーマンスハック：メモリ消費の抑制
プロトタイプの挙動が重くなる原因の9割は、「過剰なレイヤーのネスト」と「不要な変数監視」にある。
- レイヤーのフラット化: カートの計算結果を表示するテキストレイヤー以外は、Auto Layoutの階層を極力浅くする。
- 変数スコープの限定: 必要のないページにまでグローバル変数をバインドしない。不要な依存関係はブラウザ上の描画コストを増大させる。
—
4. ユーザーテストで「震えるほど」リアルな挙動を再現する
ユーザーテストでは、以下の「エッジケース」を実装したプロトタイプが勝つ。
- エラーハンドリングの可視化: 在庫切れ商品を追加した際、`cart_quantity`を増やさず、かつ「在庫上限に達しました」というトースト通知を出すトリガーを実装する。
- トランジションの非同期化: 数値が更新される際に、CSSの`transition`を模した「微細なスケーリングアニメーション」をプロトタイプに加える。これだけで、ユーザーは「動いている」ではなく「動くプロダクトに触れている」と錯覚する。
—
結びに：デザインはエンジニアリングの延長である
プロトタイプとは、「動くドキュメント」である。
デザイナーがLogicを理解し、エンジニアがその変数の命名規則を理解し、APIを通じて設計資産を共有する。このプロセスこそが、プロダクト開発における最強のDevOpsだ。
Figmaはもはや「お絵描きツール」ではない。君たちの手元にあるのは、ブラウザ上で走る最高精度のシミュレーションエンジンだ。さあ、ロジックでデザインを支配せよ。
—
注：本稿の技術知見は、Figmaのバージョンアップに伴う仕様変更を前提としています。常に`figma.mixed`や`VariableMode`の最新ドキュメントをチェックし、自身の設計思想をアップデートし続けること。