figma-implement-motion

モーションの実装

概要

このスキルでは、Figma のアニメーションとトランジションを、実行可能なコード（motion.dev、CSS キーフレーム、またはフレームワーク固有のライブラリ）に変換する方法を説明します。

Figma は、2 つのツールを通じてモーションを提供します。

• get_motion_context — モーションに関する信頼できる情報源となるツールです。アニメーションが設定されたノードの完全な一覧、事前計算されたコードスニペット（CSS の @keyframes と motion.dev）、スニペットを利用できない場合のフォールバック用キーフレームの割り当て、再帰的なタイムライン調整のヒント（timelineCohorts）を返します。アニメーションデータとアニメーションするノード ID の信頼できる情報源です。
• get_design_context — デザインの構造を返します。レイアウト、サイズ、アセット、スタイル、Code Connect のヒント、スクリーンショットのコンテキストに加え、アニメーションする要素のモーション配置マーカー（data-node-id、分割ノードでは data-motion-keys / data-motion-wrapper-for / data-motion-transform-template）が含まれる場合もあります。アニメーションするノードは、通常の要素（div、p、span など）またはモーション要素（motion.div）としてレンダリングされることがありますが、アニメーションの値は埋め込まれません。

この 2 つはノード ID で連携します。ワークフローはこれだけです。 get_motion_context は、どのノードがアニメーションするか、キーフレームの値、イージング、タイミング、コードスニペットを提示します。get_design_context は、それらのノードの見た目と配置を提示します。get_motion_context.nodes 内の各ノードについて、デザインコンテキスト内で一致する data-node-id を見つけ、その構造にモーションを統合します。構造上の要素が通常の要素であれば、motion.{tag} を追加するか、要素をラップします。デザインコンテキストで Figma コンポーネントが再利用されている場合、モーションノードに fallbackNodeId が含まれることがあります。これを使うのは、正確な nodeId での検索を試した後に限ります。

スキルの範囲

• 成果物がユーザーのリポジトリ内のモーションコードである場合は、このスキルを使用します。
• ユーザーが Figma 内でアニメーションを作成または編集するよう求めている場合は、figma-use に切り替えて、そのスキルに従ってください。
• このスキルが現在対象とするのは、get_motion_context が出力するアニメーションです（スニペットとフォールバック用キーフレームトラック、およびこれらの形式に変換されたプリセット作成のモーションを含みます）。より広範なインタラクティブなバリアントのフローでは、コード内で製品固有の状態処理が必要になる場合があります。

前提条件

• Figma MCP サーバーに接続され、アクセスできること。
• ユーザーが提供する Figma URL から解析したノード ID。URL の形式：https://figma.com/design/:fileKey/:fileName?node-id=1-2 — fileKey（/design/ の後のセグメント）と nodeId（node-id クエリパラメーターの値。例：42-15）を抽出します。
• 対象のコードベース。モーションの出力形式は技術スタックに合わせて調整されます（フレームワークの推奨事項を参照）。

ツールの選択

モーションを実装する際は、役割の異なる 2 つのツールを使用します。

状況	ツール	理由
静的な構造、アセット、スタイル、Code Connect、または視覚的なレイアウトを把握する	get_design_context	アニメーションするノードを適切に配置するために必要な、コンポーネントやページのコード参照とアセット URL が得られます。
任意のノードのアニメーションデータを取得する	get_motion_context	モーションに特化したツールであり、タイミング、イージング、スニペット、キーフレームの信頼できる情報源です。
ノードにモーションマーカー（data-motion-keys、data-motion-wrapper-for）がある	分割された配置にはマーカー、値には get_motion_context	分割マーカーはどのトラックをどの要素に割り当てるかを示します。キーフレーム、イージング、タイミング、アニメーションするノードの一覧は get_motion_context から取得します。

子孫ノードのモーションを 1 回の呼び出しで取得する必要がある場合、get_motion_context では recursive: true を指定できます（上限は 500 ノードです）。

必須のワークフロー

ステップ 1：静的なデザインコンテキストを利用できることを確認する

get_design_context(fileKey=":fileKey", nodeId="<node-id>")

このノードについて get_design_context がすでに呼び出されている場合は、その出力を再利用します。まだ呼び出されていない場合は、ここで通常どおり呼び出します。

これを構造の基準として使用します。階層、サイズ、スタイル、アセット、Code Connect のヒント、スクリーンショットのコンテキスト、および含まれている場合はモーション配置マーカー（ステップ 3）が対象です。アニメーションするノードの一覧とアニメーションの値は、get_motion_context から取得します（ステップ 2）。

Step 2: 信頼できるモーションデータを取得する

get_motion_context(fileKey=":fileKey", nodeId="<node-id>", recursive=true)

レスポンスの形式（アニメーション対象ノードごとに1エントリ）：

• codeSnippets — 事前生成された CSS @keyframes と motion.dev の文字列です。**これらをそのまま使用してください。**フォールバックのトラックデータから再生成しないでください。
• textAnimations — これらのテキストグループアニメーションは必ず実装してください。codeSnippets も含まれる場合は、両方を適用してください。スニペットは textAnimations の代わりにはなりません。
  • derivedTimingInfo を使用してください。各グループは startMs + orderPosition * staggerStepMs で開始し、groupDurationMs の間再生されます。startMs にはすでに delayMs が含まれているため、再度加算しないでください。presetDurationMs は各グループではなく、スタッガーシーケンス全体の時間です。
  • grouping と order から orderPosition を計算してください。常に文字インデックスを使用するわけではありません（CENTER_OUT では対称のペアが同時に開始します）。Motion.dev 用にミリ秒を秒に変換し、スプリングも含め、指定されたイージングを groupDurationMs に収めてください。
• keyframeBindings — プリセット由来のモーションをトラックデータに解決したものを含む、バインド済みのキーフレームトラックです。両方のスニペット形式が欠落している場合に限り、フォールバックデータとして含まれます。
• motionSummary — アニメーションの各フィールドを1行で説明する自然言語の記述です。スニペットがない場合に限り表示してください（キーフレームバインディングのみのモーションは、コード生成で CSS／motion.dev として表現できません）。存在する場合はこれをもとに実装してください。スニペットがある場合は無視してください。
• fallbackNodeId — コンポーネント化されたデザインコンテキストとの照合に使用する任意のフォールバック ID です。nodeId が I4005:6111;30:8005 のようなインスタンス修飾 ID の場合、D2R は代わりに、4002:3957 のような元のコンポーネント ID を使用して再利用可能なコンポーネント本体をレンダリングすることがあります。その場合、正確な nodeId での検索に失敗したときに探す data-node-id が fallbackNodeId です。

再帰的なレスポンスには timelineCohorts も含まれます。これは同じタイムラインを共有するノードを表すトップレベルの配列（ノードごとの項目ではありません）です。形式は { rootNodeId, durationMs, loopMode: 'once' | 'loop' | 'boomerang', memberNodeIds[] } です。複数ノードが連動するモーションでは、durationMs（秒にするには ÷1000）と loopMode を使い、すべての memberNodeIds を1つの共有ライフサイクルで動かしてください。兄弟ノードの順序からタイミングを推測しないでください。

LLM にとって重要な実装の詳細：

• スニペットがある場合、ペイロードを小さくするために motionSummary、timelineDurationMs、transformOrigin が省略されることがあります。スニペットにはすでに duration と transform-origin が含まれており（motion.dev の duration／style={{ transformOrigin }}、または CSS の animation／transform-origin）、コホートには durationMs が含まれます。フィールドが欠落していても、「アニメーションなし」を意味するわけではありません。
• 再帰的なレスポンスでは、完全に同一のスニペットは重複排除されます。スニペットが、同じモーションを持つ最初のノードを示すコメントに置き換えられている場合があります。2つ目のアニメーションを書くのではなく、同じコンポーネント、バリアント、クラス、または定数を再利用してください。
• MCP サーバーは clientFrameworks から CSS と motion.dev のどちらのスニペットかを推定します。レスポンスに一方の形式しか含まれていない場合は、もう一方の形式が失敗したと決めつけず、ユーザーのスタックに合わせてその形式を調整してください。

Step 3: 静的コンテキストとモーションコンテキストを統合する

• 可視状態の静的な JSX 内にある motion.* タグではなく、get_motion_context.nodes を起点にしてください。返されるすべてのノードがアニメーション対象です。 まず、正確な nodeId / data-node-id で各モーションノードを get_design_context に照合します。完全一致がない場合に限り、fallbackNodeId / data-node-id を試してください。両方の ID で一致しなかった場合のみ、ノード名／型とスクリーンショット上の位置を使ってください。
• fallbackNodeId よりも完全一致の ID を優先します。 fallbackNodeId は、再利用可能なコンポーネント内で D2R が出力することのある、元となるコンポーネントの ID を指します。この ID はそのコンポーネントのすべてのインスタンスで共有されます。デザインコンテキストに完全一致する nodeId がある場合は、そこにモーションを適用し、フォールバックは無視してください。これはルートインスタンスのアニメーションで重要です。同じコンポーネントのインスタンスでも、別々に回転したり移動したりすることがあり、そのモーションを共有コンポーネント本体に適用すると、すべてのインスタンスが誤ってアニメーションすることになります。
• 各モーションノードを、data-node-id をキーとして対応するデザインコンテキストの構造に適用します。 対応する data-node-id は構造上の基準点であり、常にモーションが適用される最終的な DOM 要素とは限りません。スニペットの形状と配置マーカーを確認して、モーションを該当要素自体、ラッパー、内部要素、またはインライン SVG のパスのどこに適用するか判断してください。get_design_context が値を除いた motion.{tag} をすでに出力する場合も、通常の構造要素（div、p、span、コンポーネントのルートなど）を出力する場合もあります。通常の要素で、スニペットがその要素自体を対象としている場合は、適切な motion.{tag} に変換するか、モーション用ラッパーを追加してください。その際、ノードのテキスト、子要素、クラス／スタイル、属性、data-node-id は保持します。このマージ手順の例は、references/examples-and-anti-examples.md を読み込んで確認してください。
• コンポーネント化された子要素のモーションは、通常フォールバックで照合します。 デザインコンテキストが Figma のインスタンスを再利用可能な React コンポーネントに抽出すると、そのコンポーネント本体内の子要素は、元となるコンポーネントの ID（4002:3957）を持つことが多い一方、モーションコンテキストでは実際のインスタンス ID（I4005:6111;30:8005）が報告されます。この場合は、fallbackNodeId を使ってコンポーネント本体の data-node-id を特定します。ただし、モーションは実装対象のレンダリング済みインスタンスに限定してください。複数のインスタンスがあり、そのうち一つだけルートモーションが異なる場合は、完全一致の ID によってインスタンスごとのモーションが分離されます。
• 分割されたノードには、data-motion-keys / data-motion-wrapper-for マーカーが付いています。詳しくは、以下の Handling interleaved transforms を参照してください。
• グループ自体がアニメーションする場合を除き、display: contents のラッパーを保持してください。 レイアウトに影響しないグループラッパーは contents（Tailwind の contents）として出力され、通常は効果のない absolute / inset-[…] も併記されます（contents ボックスには何の効果もありません）。静的な グループでは display: contents を維持し、子要素を最も近い実要素の祖先に対して配置してください。ラッパーの inset を位置指定ボックスに変えると、子要素はより小さなボックスを基準に配置されるため、表示が小さくなったり内側にずれたりします。アニメーションする グループ（グループノード自体にモーションがある場合）では、display: contents にトランスフォームを適用できないため、実際の位置指定ラッパーに置き換え、そのラッパーにグループのモーションを適用してください。このケースを実装する前に、references/gotchas.md を読み込んでください。
• get_motion_context はアニメーション対象ノードの完全な一覧です。 アニメーション対象ノードの中には、通常の（motion ではない）要素としてレンダリングされるものもあります。たとえば、コンポーネントインスタンスのルート（位置指定用の通常の <div>）、テキスト（<p>）、マスクなどが該当し、これらにも data-node-id が付いています。モーションレスポンス内のすべてのノードを確認し、必要に応じてラップまたは変換して、対応する data-node-id を持つ要素にモーションを適用してください。アニメーション対象ノードに出力内の要素がまったくない場合（たとえば、アニメーションするマスクが静的な mask-image に平坦化されている場合）は、黙って省略しないでください。// TODO: <nodeId> motion unsupported コメントを残し、概要でもその旨を明記してください。
• ノードがモーションコンテキストに存在し、静的 JSX に存在しない場合は、それを表現するために必要な要素を追加してください。デザインコンテキストのコードは参照用であり、アニメーション対象の完全な一覧ではありません。
• デザインコンテキストとモーションコンテキストの内容（タイミング／イージング／アニメーション値）が競合する場合は、get_motion_context を優先してください。
• SVG のパスレベルのモーションでは、SVG をインライン化して実際の <path> をアニメーションさせます。 get_motion_context がベクターのパス（PATH_TRIM、motion.path、stroke-dasharray）を対象としている一方、デザインコンテキストが <img> としてレンダリングしている場合は、SVG をインライン化し、レイアウト用ラッパーを維持したまま、スニペットを <path> に適用してください。このケースの詳しい手順（motion.path、pathLength="1"、ラッパーとパスのレイヤー構成、CSS の path-trim）は、references/svg-and-path-motion.md を読み込んで確認してください。

インターリーブされたトランスフォームの処理

静的なベーストランスフォームとアニメーション付きトランスフォームの両方を持つノードは、両者が競合せず正しく合成されるよう、ネストした要素に分割されます。data-motion-wrapper-for="<nodeId>" を持つ ID なしの motion.div（外側のラッパー）が、静的トランスフォームの div（例：rotate-45 と hypot() によるサイズ指定。あるいは、ラッパー自体が data-motion-transform-template="<css>" を持つ場合もあります）を包み、その div が内側のノード（data-node-id）を包みます。wrapper > static-transform div > inner のネストを維持してください。これをまとめてしまうと、サイズ指定とベーストランスフォームが壊れます。

• data-motion-keys に従ってトラックを配置します。 ラッパーの data-motion-keys（トランスフォームのトラック：x／y／rotate／scaleX／scaleY／skewX）は外側のラッパーに配置し、内側の要素の data-motion-keys は内側の要素に配置します。
• data-motion-transform-template を再適用します。 ラッパーがこれを持つ場合は、transformTemplate={(_, generated) => "<css> " + generated} を設定して、アニメーション付きトランスフォームをその静的なレイアウトトランスフォームの上に合成します。
• アニメーション付きトランスフォームを静的なベースの分だけオフセットします（二重回転を避けます）。 get_motion_context が返すのはノードの_絶対_トランスフォームで、これには各 div が適用する静的なベーストランスフォームがすでに含まれています。rotate-45 をベースとする場合、[45, 125, 125] の rotate スニペットでは、ラッパーがアニメーションするのは絶対値ではなくオフセット [0, 80, 80]（＝絶対値 − 45）です。絶対値を使うと 45° が二重に適用され、静止時に要素が 90° になります。静的なベースがないトラック（例：0 から始まる x／y）はそのまま使います。インターリーブされたトランスフォームの例を参照してください。
• レイアウトトランスフォームと Motion トランスフォームを分離します。 rotate、scale、または skew をアニメーションするすべての motion.* 要素について、中央揃えや位置指定に -translate-x-1/2 や -translate-y-1/2 などの Tailwind レイアウトトランスフォームも依存していないことを確認してください。これらのユーティリティは、Motion.dev がインラインで書き込む CSS の transform プロパティを共有するため、Motion のトランスフォームによってレイアウトの translate が消えることがあります。両方が必要な場合は、中央揃え／位置指定のトランスフォームを持つ静的なレイアウトラッパーと、アニメーション付きの rotate／scale／opacity を持つ内側の motion.* 要素に分割するか、レイアウトのオフセットを Motion 自体に指定し（x: "-50%"）、すべてのキーフレームで維持してください。

ステップ 4：コードにモーションを適用する

• スニペットに motion.dev が含まれていますか？ React ターゲットでは motion.dev のコードをそのまま使います。コードベースがすでに別のモーションライブラリ（Framer Motion、React Spring、GSAP）を使用している場合を除き、motion/react からインポートしてください。その場合は、スニペットをそのライブラリに適合させます。別のスタックに適合させる場合やライブラリを選ぶ場合は、references/framework-recommendations.md を読み込んでください。
• CSS キーフレームが含まれていますか？ vanilla／非 React ターゲット、またはコードベースに React のモーションライブラリがない場合に使用します。
• スニペットがありません（keyframe-bindings-only）か？ keyframeBindings と motionSummary から同等の motion.dev／CSS を構築し、コホートの durationMs／loopMode からループのタイミングを取得して、構造化フィールドから transformOrigin／duration を読み取ります。これはまれなケースです。通常、SwiftUI／iOS 用を含め、スニペットが存在します（これらには CSS 形式が使われます）。

ステップ 5：検証する

• 新しいインポートを追加する前に、コンポーネントで既存のモーションのインポートや規約を確認します。ユーザーがすでに Framer Motion／React Spring／anime.js を使用している場合は、motion.dev を無理に使わず、既存のものに適合させてください。
• 多数のノードに変更をまとめて適用する前に、アニメーションを 1 つ抜き出して、最初から最後まで動作することを確認します（リロードし、動作を観察して、反復します）。
• Figma のモーション出力で見られた具体的なバグやエッジケースをまとめた references/gotchas.md を読み込み、生成されたコードに該当するケースがあれば修正してください。

重要なルール

これらは一般原則です。回転の支点、HOLD の意味、色の補間など、具体的な注意点は分類されたリファレンスに記載されています。このスキルの説明でリンク先のリファレンスに言及しており、該当する状況であれば、続行する前にそのファイルを読み込んでください。

1. ツールの出力は、レイアウトではなく、そこに含まれる値を尊重してください。 codeSnippets のタイミング、イージング、キーフレームの値、transformOrigin をそのまま保持してください。スニペットがある場合、keyframeBindings や構造化フィールドから値を再生成してはいけません（再生成すると、カスタムベジェイージング、スプリングの近似値、オーバーシュートの値が正確に再現されません）。transformOrigin は要素ごとに設定します。外側のラッパーだけでなく、ネストされたスケーラーも含め、スケーリングまたは回転する各ノード固有の値を適用してください。そうしないと、要素はデフォルトの中心を支点にするため、誤った隅を起点に拡大したり回転したりします（要素ごとのtransformOriginの例を参照してください）。ただし、スニペットは1つのノードのデータであり、そのままコピーして使うテンプレートではありません。多くのノードで同じ内容を使う場合は、ブロックをN回貼り付けるのではなく、ルール7に従って共通化してください。
2. ユーザーがすでに使っているモーションスタックに合わせてください。 依存関係を追加する前に、コンポーネントのインポートと、同じ階層にあるアニメーションを確認してください。ユーザーがすでに Framer Motion、React Spring、anime.js、GSAP を使っている場合は、motion.dev を無理に導入せず、出力を既存のスタックに合わせてください。
3. prefers-reduced-motionを尊重してください。 追加するモーションはすべて、@media (prefers-reduced-motion: reduce)の設定時に控えめにするか、無効にする必要があります。通常はanimateを省略して初期状態または静止状態を表示するか、再生時間をほぼゼロにします。これはオプトインではなく、アクセシビリティのデフォルト設定です。
4. まとめて適用する前に、アニメーションを1つ最後まで検証してください。 ビルドして再読み込みし、タイムラインを最初から最後まで1回再生します。各アニメーションノードが、キーフレームトラックで指定されたタイミングで表示されることを確認してください。「エラーなしでレンダリングされる」ことと「正しくレンダリングされる」ことは異なります。まとめて適用すると、モーションの不具合が重なります。1つのノードのイージングの誤りなら簡単に見つけられますが、同じバグが20個のノードに及ぶと、原因の特定に何時間もかかります。
5. モーションを捏造しないでください。 レスポンスにノードのモーションデータがない場合は、静止状態のままにしてください。デザインの別の箇所にあるイージングや再生時間のデフォルト値を流用したり、「コンポーネントの他の部分がアニメーションするから」という理由で自動的にアニメーションを追加したりしてはいけません。
6. アセットをダウンロードし、ローカルファイルを参照してください。 get_design_context / get_motion_context は、有効期限付きURL（/api/mcp/asset/...）でアセットを返します。アセットはSVGであることがよくあります。curl -Lを使って各アセットをプロジェクトにダウンロードし、ダウンロードしたファイルを参照するか、内容をインライン化してください（例：SVGをインライン化して、SwiftUIでNSImage(data:)を使ってレンダリングします）。一時的なアセットURLをアプリケーションコードで参照してはいけません。パス単位のSVGモーションでは、SVGをインライン化し、<img>の背後に残すのではなく、実際のパスをアニメーションさせてください。ダウンロードしたSVGファイルを画像としてReadツールに渡してはいけません。SVGは対応する画像形式ではないため、読み込みに失敗したり、停止したりすることがあります。
7. 繰り返されるモーションは共通化し、要素ごとにスニペットをコピーして貼り付けないでください。 多くの場合、多数のノードが同じアニメーションを共有し、異なるのはスタッガーの遅延、オフセット、目標値だけです。共通のモーションは、再利用可能なアニメーションコンポーネント、または異なる値をパラメーター化したvariantsオブジェクトとして一度だけ実装します。マップされた配列（items.map(...)）からレンダリングし、再利用されるリテラル値（再生時間、イージング配列、オフセット）は名前付き定数にまとめてください。アニメーションの値はスニペットどおりに保持します（ルール1）。一方、コードはDRYにしてください。同じtransitionオブジェクトを15回以上貼り付ける（本来150行で済むものが800行になる）のは品質の低い結果です。忠実さと保守性の両方が評価されます。

フレームワークの推奨事項

ルール 2 では、基本方針としてユーザーが既に使用しているスタックを優先します。既存のスタックがない場合は、次をデフォルトとします。

• React：motion.dev（motion パッケージ）。ツールが motion.dev のコードを直接返すため、そのまま使用してください。
• Vanilla／React 以外の Web：CSS の @keyframes と animation のショートハンド。ツールがそのまま返します。
• SwiftUI：ネイティブの .animation(...) モディファイア。CSS スニペットを SwiftUI 向けに変換します（get_motion_context は SwiftUI コードを出力しませんが、SwiftUI／iOS クライアントにも CSS 形式が提供されます。スニペットがない場合に限り、keyframeBindings／motionSummary／コホートにフォールバックしてください）。実在する SwiftUI API のみを使用してください。Figma／CSS のイージングを直接受け取るモディファイアはないため、references/framework-recommendations.md を読み込み、イージングを SwiftUI の同等のものに対応付け、独自に作り出さず検証してください。この手順は現在も進化中です。不明な場合はユーザーに確認してください。

確立されたエフェクトの種類では、独自に CSS を組み立てるよりライブラリを優先してください。 グラス／グラスモーフィズム、紙吹雪、パーティクルシステム、物理ベースのインタラクション、スクロール連動モーションなどのエフェクトには、クロスブラウザーの差異、アクセシビリティ、パフォーマンスに、生成されたキーフレームよりもはるかに適切に対処できる、実績のあるライブラリ実装があります。エフェクトの種類ごとのライブラリ一覧は、references/framework-recommendations.md を読み込んで確認してください。これらは必須ではなく推奨事項として提示し、判断はユーザーに委ねてください。

例

具体的な使用例や失敗パターンが必要な場合は、references/examples-and-anti-examples.md を読み込んでください。シンプルなマージの流れ、motion.* の追加が必要なプレーンテキスト要素、静的変換とアニメーション変換が交互に使われるケース、SVG のパス単位のモーションを解説しています。また、DOM の再構築、ノード ID／位置のずれ、要素ごとの transformOrigin の指定漏れといった、避けるべき例も掲載しています。

参考資料

必要に応じて読み込む、詳細な解説が6つあります。パフォーマンス、単位、アクセシビリティの仕組みなど、フロントエンド全般に関する懸念事項は上記の重要なルールで扱っています。これらの参考資料は、Figma 固有の情報に焦点を当てています。このスキルのインライン指示でいずれかのファイルが指定されている場合は、その作業に進む前にファイルを読み込んでください。

• references/examples-and-anti-examples.md — 実例と失敗パターンを示します。マージのワークフローを適用する場合、交互に入り混じった変換を扱う場合、または生成された実装で DOM が再構築されていないか、ノードの位置が入れ替わっていないか、transformOrigin が削除されていないかを確認する場合に読み込んでください。
• references/gotchas.md — Figma 固有のモーションの不具合と修正方法を説明します。ネストされたグループにおける回転／スケールの原点、HOLD イージングのセマンティクス、CUSTOM_SPRING の保持、独立した軸スケーリングの曖昧さ、色の補間を扱います。予期しないランタイム動作をトラブルシューティングする場合に読み込んでください。このファイルと併せて、必ず references/motion-lint-rules.md も読み込んでください。問題点の項目では、ユーザーに提示する必要がある特定の lint ルールを参照しています。
• references/svg-and-path-motion.md — SVG のベクターパスを対象とするモーションの実装方法を説明します（アセットのインライン化、motion.path、pathLength="1"、ラッパーとパスのレイヤー構成、CSS のパストリミング）。ベクターのスニペットがラッパーの変換ではなくパスを対象としている場合に読み込んでください。
• references/framework-recommendations.md — motion.dev、CSS キーフレーム、SwiftUI のデフォルト、効果の種類別のライブラリ表（グラス、紙吹雪、パーティクル、物理演算、スクロール連動）を説明します。効果を独自に実装する前に読み込んでください。
• references/unsupported-and-fallbacks.md — 現時点で Figma から適切にエクスポートできないモーション機能（テキストアニメーション、パスアニメーション、マスク／ブーリアン、バリアント／トランジション）を説明します。動画／Lottie へのフォールバックに関するガイダンスも含まれます。ツールの応答が不完全に思われる場合に読み込んでください。このファイルと併せて、必ず references/motion-lint-rules.md も読み込んでください。未対応機能の項目では、ユーザーに提示する必要がある特定の lint ルールを参照しています。
• references/motion-lint-rules.md — lint ルール：ユーザーに提示する必要がある、既知のエクスポート上の制限（エラーと警告）を説明します。モーションコードを生成する際に、適用される制限がないか確認するために読み込んでください。