system-fit

システムとの適合性

既存コンポーネントですべての課題を解決しようとすることなく、デザインシステムが不用意に拡大するのを防ぎます。

常に守ること

• コンテキスト — ユーザーに同じことを繰り返し尋ねる前に、すでにわかっている情報を確認します。製品の目的や成果によって答えが変わり得る場合は .ux/INTENT.md を参照し、タスクに必要な追加のプロジェクトコンテキストだけを読み込みます。
• ユーザー — 影響を受ける人々、その目標、タスク、状況、利用可能な根拠に基づいて作業します。ユーザーのニーズ、行動、ペルソナを捏造しません。
• 根拠 — 既知の情報、推測、仮定、不明点、矛盾する情報は、その違いが重要な場合に明確に区別します。
• システム — 新しいものを考案する前に、製品で確立されている用語、コンポーネント、パターン、ルールを優先します。
• 明確さ — 役立つ要点から始め、必要最小限の構成を使い、ありきたりな AI の水増し表現を取り除きます。
• 信頼 — 根拠、要件、理由、実装状況、コンプライアンスを捏造しません。
• 成果 — 複数の手順を含む重要な作業では、意図を常に念頭に置き、継続性の確保が必要な場合に限って簡潔な .ux/STATE.md を使い、仕上げに入る前に影響の大きい未解決事項を優先し、完了を宣言する前に実際の体験が意図に沿っているか確認します。

これらのルールが回答に実質的な影響を与えない限り、ユーザーに繰り返し説明しないでください。

ユーザーとタスクがすでに明確な場合や、不足情報によって作業が実質的に変わらない場合は、調査の質問、ペルソナ、発見プロセスを持ち込まないでください。

実際のシステムを調べる

利用可能な場合は .ux/DESIGN-SYSTEM.md を参照し、Storybook、コンポーネントパッケージ、トークン定義、デザインドキュメント、実装例、コントリビューションルールなど、信頼できる情報源を調べます。システムとの適合性の判断を左右する場合に限り、ほかのプロジェクトコンテキストも読み込みます。

Figma、Storybook、コードが信頼できる唯一の情報源だと決めつけないでください。プロジェクトで文書化された優先順位に従うか、曖昧さを明示します。

適合性を分類する

次の順序を優先します。

1. 再利用 — 既存のコンポーネントまたはパターンで、すでにニーズを解決できます。
2. 組み合わせ — 確立された方法で組み合わせれば、既存のプリミティブで解決できます。
3. 拡張 — 既存のコンポーネントに、妥当な新しい状態、動作、バリエーション、またはドキュメントの更新が必要です。
4. 新規作成 — ニーズが明確に異なり、新しいシステム資産を作成する価値があるほど再利用可能です。
5. 機能内に限定 — 解決策が特定の機能に特化しすぎており、共有システムコンポーネントにするべきではありません。

見た目の配置が新しいというだけで、新しいコンポーネントを作成しないでください。

ギャップを確認する

既存のシステムでほぼ対応できる場合は、何が不足しているのかを具体的に特定します。状態、アクセシビリティ動作、データ規模、レスポンシブ動作、コンテンツルール、インタラクション、API などです。

ギャップは実装ではなく、ドキュメントの不足ではないかも検討します。

出力

分類と推奨事項から始めます。関連する既存資産、ギャップ、機能に伴って行うべきデザインシステムへの貢献を明示します。

システムの情報源を検証できない場合は、確実であるかのように装わず、条件付きで推奨します。

対比例

悪い例：

デザインシステムに現時点でまったく同じコンポーネントがないため、新しい SearchableStationPicker コンポーネントを作成します。

良い例：

組み合わせ。 既存の Autocomplete で駅を検索でき、既存の選択／チップのパターンで選択済みの値を扱えます。足りないのは新しいコンポーネントではなく、検索結果がない場合、非同期読み込み、キーボードでの選択に関する動作の文書化です。新しいシステムコンポーネントを提案する前に、既存のパターンにこれらの状態を追加してください。

理由：良い回答は、実際に不足している動作を特定し、コンポーネントを増やすよりも組み合わせを優先しています。

例

• 「新しいコンポーネントが必要ですか？」
• 「既存のデザインシステムにあるもので構築できますか？」
• 「この状態を Storybook に追加すべきですか？」