design-systems-frontend-architecture

デザインシステムのフロントエンドアーキテクチャ

目的

エージェントが UI、UX、プロダクト、ブランドに関する判断を、長期的に維持できるフロントエンドシステムへと変換できるよう支援します。再利用可能なコンポーネント、トークン、レイアウトルール、状態の振る舞い、ドキュメント、ガバナンス、実装ガイダンスを整備し、画面、チーム、デバイス、時間を超えて拡張できるようにします。

実際のプロダクト開発を重視してください。デザインシステムの説明だけにとどめず、ユーザーが行動に移せる判断、デフォルト設定、コンポーネントの契約、実装ガイダンス、評価、次のステップを提示してください。

このスキルを使う場面

ユーザーから次のような依頼があった場合に、このスキルを使ってください。

• デザインシステム戦略、コンポーネントライブラリ、パターンライブラリ、スタイルガイド、デザイントークン、UI キット、コンポーネント監査、インターフェース一覧、ガバナンス。
• UI の評価、再設計、フロントエンド実装計画、コンポーネントの分解、レスポンシブレイアウトのガイダンス、CSS アーキテクチャ、フロントエンドの保守性。
• モックアップ、スクリーンショット、UX フロー、プロダクト要件を、拡張性のあるフロントエンドコンポーネントに変換すること。
• コンポーネント、トークン、アクセシビリティの状態、使用ガイダンス、デザインからコードへの引き継ぎに関するドキュメント。
• UI の表示箇所間の不整合、パターンの重複、場当たり的なスタイリング、コンポーネントの乖離の解消。

このスキルを使わない場面

タスクの主な内容が次のいずれかである場合、このスキルを中心的な視点として使わないでください。

• UI やシステムに関する判断にまだ結び付いていない、広範な UX リサーチ計画、エスノグラフィー、探索的インタビュー、市場調査、プロダクト戦略。
• ビジュアルアートディレクション、イラストのスタイル、キャンペーンクリエイティブ、ブランドアイデンティティの作成。ただし、ユーザーがそれらをシステムルールに変換する場合を除きます。
• バックエンドアーキテクチャ、API 設計、データモデリング、インフラストラクチャのみの作業。
• 再利用性、アクセシビリティ、フロントエンド実装が重要ではない、一度限りの静的なグラフィックデザイン。

基本原則

1. ページではなく、デザインシステムを考えます。 ページ数ではなく、コンポーネント、テンプレート、コンテンツタイプ、状態、統合、振る舞いを基準に作業範囲を定めてください。
2. 部分と全体を同時に考えます。 トークン、アトム、コンポーネント、セクション、テンプレート、実際のページをまとめて評価してください。現実的な構成やコンテンツの中でどう機能するかを確認せずに、コンポーネントを設計しないでください。
3. 機能と知覚を分けます。 機能的なパターンは振る舞いやインターフェースのモジュールとして扱い、知覚的なパターンはプロダクトの個性を生み出すスタイル、トーン、モーション、間隔、色、タイポグラフィの処理として扱ってください。
4. 抽象化する前に目的を定めます。 コンポーネントは、ユーザーやプロダクトの課題を解決するために存在します。見た目が似ているという理由だけで抽象化しないでください。
5. 共通言語をインフラストラクチャとして扱います。 名前、定義、使用ルール、例はシステムの一部であり、周辺を飾るものではありません。
6. 再利用可能なプリミティブを優先しつつ、プロダクトらしさを保ちます。 一貫性はユーザーの負担とチームの無駄を減らすものであり、有用なブランド表現や印象に残る体験を消し去るものであってはなりません。
7. システムを信頼できる唯一の情報源にします。 リリース済み UI を変更したら、適切にコンポーネント、トークン、ガイドラインも更新してください。個別のホットフィックスは避けてください。
8. アクセシビリティをコンポーネントの契約として扱います。 セマンティクス、キーボード操作、フォーカス、コントラスト、ヒット領域、エラー処理、動きを抑える設定への対応を、パターンと併せて仕様化してください。
9. 負債を防げるよう、早い段階でフロントエンドアーキテクチャを選びつつ、変更に対応できる状態を保ちます。 実装が広がる前に規約を定め、プロダクトの進化に合わせて意図的に見直してください。
10. 記録の保存ではなく、実際の利用を目的にドキュメントを作成します。 ドキュメントでは、パターンを使う場面と使わない場面、振る舞い、実装方法、所有者を説明してください。

各原則を再利用可能なカードとしてまとめたものについては、references/principle-cards.md を参照してください。

デフォルトの推奨事項

ユーザーが明確に異なる選択を求める状況を提示していない限り、これらのデフォルト設定を使ってください。

プロダクトとスコープのデフォルト

• デフォルトのスコープ： 役立つ最小限のシステムの範囲を定義します。トークン、3〜5 個の主要コンポーネント、代表的なテンプレート 1〜2 個、ドキュメントで構成します。これにより、肥大化した「一括導入」のシステムを避けられます。
• デフォルトの優先順位付け： 使用頻度が高く、リスクも高いパターンを優先します。ボタン、リンク、フォーム、アラート、ナビゲーション、カード／リスト、レイアウトの基本要素、文字サイズのスケール、余白、色の意味、読み込み中／空／エラーの各状態が対象です。
• デフォルトの移行方法： 段階的に改善します。プロダクトが初期段階にある場合や、大規模なプラットフォーム移行がすでに進行中の場合を除き、全面的な再設計よりもコンポーネント単位での置き換えと非推奨化を優先します。

デザインシステムの構造に関するデフォルト

• デフォルトのモデル： 基盤／トークン → 基本要素 → コンポーネント → 組み合わせ／テンプレート → プロダクトの例／ページというレイヤー構造を採用します。
• デフォルトの命名： 見た目ではなく、目的に基づいてパターンに名前を付けます。blue button、big box、right rail thing よりも、Primary action、Course card、Filter panel、Inline validation、Promotion banner を優先します。
• デフォルトのドキュメント： 再利用可能な各パターンに、目的、構成要素、バリエーション、状態、アクセシビリティの要件、コンテンツに関する指針、レスポンシブ動作、実装上の注意点、例、避けるべき例を記載します。
• デフォルトのガバナンス： 適度に管理します。コントリビューションは受け入れますが、新しいトークン／コンポーネントにはレビューを必須とし、バリエーションを追加する際には根拠を求めます。

トークンに関するデフォルト

• デフォルトのトークンカテゴリ： 色、タイポグラフィ、余白、角丸、境界線、エレベーション／シャドウ、モーション、不透明度、z-index／レイヤー、サイズ、ブレークポイント／コンテナー、状態を表すセマンティックトークン。
• デフォルトのトークン構成： プリミティブ値とセマンティックトークンを分けます。例：プリミティブの color.blue.600、セマンティックな color.action.primary.bg、コンポーネント固有のマッピングが必要な場合に限るコンポーネントトークン button.primary.bg。
• デフォルトの命名： 生の見た目ではなく、役割と状態を使います。gray-500-for-labels よりも、text.muted、surface.raised、border.focus、status.error.fg を優先します。
• デフォルトのオーバーライドルール： 例外が 1 つあるだけで新しいトークンを導入しないでください。まず、既存のセマンティックトークン、コンポーネントのバリエーション、またはプロダクト固有の要件で対応できないかを確認します。

レイアウトとレスポンシブ対応に関するデフォルト

• デフォルトのレイアウト戦略： コンテンツを重視し、柔軟なコンテナー、グリッド／フレックスの基本要素、流動的な余白、コンテナーに応じたルールを使って、自然にレスポンシブなレイアウトを設計します。デスクトップ／タブレット／モバイルの画面を、互いに無関係な成果物として別々に設計することは避けます。
• デフォルトのブレークポイント： 可読性、ナビゲーション、タスク完了を守るのに必要な数だけ使用します。ビューポート全体の動きに頼るよりも、コンポーネント／コンテナーの挙動を優先します。
• デフォルトの情報密度： 適度な密度と、内容を見分けやすい余裕のあるレイアウトから始めます。専門的なワークフロー、データ量の多いタスク、または画面領域の制約によって必要な場合にのみ、密度を高めます。
• デフォルトのコンテンツテスト： 長いラベル、画像の欠落、データが空の場合、エラー状態、読み込み中の状態、密度の高いデータ、必要に応じて翻訳済みの文字列などを含め、実際のコンテンツまたは現実的なコンテンツでテストします。

CSS とフロントエンドのデフォルト

• デフォルトのマークアップ： まずセマンティック HTML を使用します。ARIA は、ネイティブのセマンティクスを置き換えるのではなく、セマンティクスの不足を補う場合にのみ追加します。
• デフォルトの CSS： コンポーネントスコープで、詳細度が低く、トークン駆動の CSS を使用します。ページ内の深い位置を指定するセレクターによるスタイリングは避けます。
• デフォルトの方法論： 明確な命名規則とレイヤリング規約を選択するか、適用します。BEM に似た命名規則、ユーティリティレイヤー、CSS モジュール、フレームワークスコープのスタイルはいずれも、ルールが明示的で一貫していれば有効です。
• デフォルトの JS： CSS で確実に実現できる効果に JavaScript を使用しないでください。動作、状態、データ、またはアクセシビリティに必要な場合は JS を使用します。
• デフォルトのカスタムコントロール： まずネイティブコントロールを使用します。カスタムスタイルが必要な場合は、ネイティブのセマンティクス、ラベル、キーボード操作、フォーカスの視認性、フォームの動作を維持します。
• デフォルトのビルド／プロセス： リント、フォーマット、該当する場合は型チェック、アクセシビリティチェック、重要なコンポーネントのビジュアルリグレッション、プレビュー／ドキュメントのビルドを自動化します。

アクセシビリティのデフォルト

• デフォルトの目標： ユーザーがより厳しい社内基準を定めていない限り、WCAG 2.2 AA の要件を満たします。
• デフォルトのコントラスト： テキストと意味のある UI インジケーターはコントラスト要件を満たす必要があります。状態の表現を色だけに頼らないでください。
• デフォルトのフォーカス： すべてのインタラクティブコントロールで、フォーカスが視認でき、キーボードで操作できるようにします。
• デフォルトのターゲット： 小さなコントロールには、特にタッチ操作や運動機能のアクセシビリティを考慮し、使いやすいヒット領域を設けます。
• デフォルトのモーション： モーションは目的を持たせ、短くし、可能な場合は中断できるようにし、視差効果を抑える設定を尊重します。

ユーザーへの必須質問

回答によってシステムが実質的に変わる場合に限り、質問してください。日常的なベストプラクティスをユーザーに判断させないでください。

以下の事項が不明で、かつ関連する場合は、焦点を絞った質問をしてください。

• プロダクトの目標、ユーザーのタスク、または対象者が明確でない。
• ユーザーが新しいシステムを求めているが、ブランド／プロダクトの個性、または既存システムの成熟度が不明である。
• 既存のフロントエンドスタック、CMS、コンポーネントフレームワーク、またはトークン形式との統合が必要である。
• プロダクトに、一般的でないアクセシビリティ、規制、パフォーマンス、デバイス、ローカライズ、またはデータ密度の制約がある。
• ガバナンス、チーム規模、リリースプロセス、または貢献モデルによって推奨事項が変わる。
• ユーザーが、アクセシビリティ、実装コスト、ブランドの一貫性、または保守性に影響するデフォルトの変更を求めている。

質問する際は、推奨するデフォルトと選択肢を提示してください。利用可能な場合は、question ツールまたは同等のパターンを使用してください。

references/decision-prompts.md にある、question ツールですぐに使用できるプロンプトを使用してください。

ワークフロー：既存の成果物を評価する

既存の UI、デザインシステム、コンポーネントライブラリ、またはフロントエンド実装をレビューする際は、次の順序で確認します。

1. タスクへの適合性とプロダクトの目的 — UI はどのようなユーザーの目標を解決していますか？ 主な操作とその結果は明確ですか？
2. システムの網羅性 — 既存のトークン、コンポーネント、テンプレート、状態には何がありますか？ 重複しているものや不足しているものはありますか？
3. 情報の階層 — 装飾を過度に使わなくても、主要、二次、三次の要素を区別できますか？
4. 機能パターン — モジュールには名前が付いており、目的が明確で、再利用可能で、動作も明確ですか？
5. 知覚パターン — 色、書体、余白、動き、画像、トーンは、意図された個性と一貫していますか？
6. レイアウトとレスポンシブ対応 — 任意のブレークポイントではなく、コンテンツやコンテナーの要件に応じてレイアウトが適応しますか？
7. インタラクションの明確さ — アフォーダンス、状態、バリデーション、読み込み中、エラー、空の状態、エッジケースが明確に定義されていますか？
8. アクセシビリティ — セマンティクス、キーボード操作の流れ、フォーカス、コントラスト、ラベル、ターゲットサイズ、読み上げ順序、動き、支援技術向けテキストを確認します。
9. フロントエンドの実現可能性 — マークアップの複雑さ、CSS の詳細度、トークンのマッピング、依存関係、パフォーマンスのリスク、テスト容易性を確認します。
10. ドキュメントとガバナンス — 信頼できる情報源、オーナーシップ、コントリビューションの手順、非推奨化のプロセスはありますか？

批評は、最もリスクの高い問題 → 重要である理由 → 推奨する修正 → システムへの影響 → 実装上の注意、の順で提示します。視覚面の意見を長い箇条書きで列挙するのは避けます。

ワークフロー：システムを作成または改善する

新たな提案を作成する際は、次の順序で進めます。

1. 機能またはユーザーの課題を明確にする。 主なタスク、対象ユーザー、プラットフォーム、既存の制約、成功基準を特定します。
2. 役に立つ最小限のシステムの範囲を選ぶ。 網羅的なコンポーネントカタログから始めないでください。
3. 既存のパターンを棚卸しする。 繰り返される機能やスタイル、重複コード、一貫性のない名称、頻出する状態を探します。
4. 機能パターンを定義する。 UI を目的と動作によってグループ化し、コンポーネントにはその役割が分かる名前を付けます。
5. 知覚パターンを定義する。 書体、色、余白、形状、動き、画像、トーン、状態表現など、プロダクトを特徴づける表現を抽出します。
6. トークンを整備する。 繰り返し使われる知覚上の判断を、必要に応じてプリミティブ、セマンティック、コンポーネントレベルのトークンに変換します。
7. コンポーネントの契約を定義する。 各コンポーネントについて、構造、バリエーション、状態、コンテンツのルール、アクセシビリティの動作、レスポンシブ動作、実装ガイダンスを記述します。
8. 実際のコンテンツを使ってテンプレートを構成する。 実際のフローやページ単位の構成でコンポーネントを検証します。
9. 実装アーキテクチャを計画する。 セマンティックなマークアップ、CSS 戦略、コンポーネントの境界、ビルド／テストパイプライン、配布方法、移行手順を選びます。
10. ドキュメントを整備し、ガバナンスを確立する。 オーナーシップ、コントリビューション、レビュー、リリース、非推奨化、導入のワークフローを定義します。
11. 検証する。 最終決定の前に、品質、アクセシビリティ、レスポンシブ対応、パフォーマンス、保守性を確認します。
12. 判断の理由を説明する。 推奨事項を、ユーザーの目標、システムの一貫性、アクセシビリティ、保守性、実装コストに結び付けます。

意思決定のフレームワーク

パターンやアーキテクチャを推奨する前に、次の順序で検討してください。

1. 目的： どのような問題やユーザーのタスクを解決しますか？
2. 再利用： 複数の機能、製品、状態にわたって繰り返し使われますか？
3. バリエーション： 本当に必要なバリエーションと、偶発的な一度限りのバリエーションは何ですか？
4. コンテンツ： パターンをさまざまなコンテンツの種類、長さ、状態、ローカライズのケースに対応させる必要がありますか？
5. アクセシビリティ： 必要なセマンティクス、フォーカス動作、キーボード操作、ラベル、コントラスト、ターゲットサイズ、動きに関するルールは何ですか？
6. 実装： セマンティックなマークアップ、詳細度の低い CSS、トークン、最小限の JS で実装できますか？
7. システムとの適合性： 既存のトークン、コンポーネント、名前、ドキュメントと整合していますか？
8. ガバナンス： 誰が所有し、どのように変更され、ユーザーはどのバージョンを使うべきかをどのように把握しますか？

これらの制約を満たす、最も複雑さの低いソリューションを推奨してください。製品の状況に応じて必要な場合にのみ、複雑さを加えてください。

実践的なルール

コンポーネントのルール

• コンポーネントには、単なる見た目の形ではなく、目的が必要です。
• スクリーンショットだけをもとにコンポーネントを作成しないでください。まず、ユーザーのタスク、コンテンツモデル、状態、レスポンシブ時の動作を特定してください。
• 類似したコンポーネントを多数作るより、明確に定義されたバリエーションを持つ少数のコンポーネントを優先してください。
• バリエーションは、目的、重要度、状態、またはコンテキストにおける意味のある違いを表す必要があります。
• コンポーネントが公開する API や props は、任意のスタイルを変更するための抜け道ではなく、システム上の判断に対応する、安定したものである必要があります。
• すべてのコンポーネントに、現実的なコンテンツを使った例と、少なくとも1つのエッジケースを用意してください。

トークンのルール

• トークンは、単に値を保存するのではなく、判断を表現する必要があります。
• 意味にはセマンティックトークンを、パレットやスケールの管理にはプリミティブトークンを使ってください。
• セマンティックな判断が可能な場合、プロダクトチームがプリミティブを直接使わないようにしてください。
• 繰り返し発生するニーズかどうかを確認する前に、単発のニーズを解決するためだけにトークンセットを拡張しないでください。
• 該当する場合は、ホバー、アクティブ、フォーカス、無効、選択済み、成功、警告、エラー、読み込み中の各状態に対応するトークンを含めてください。

ドキュメントのルール

• 実装の細部より先に、使用ルールを記載してください。
• 主要なパターンごとに「使用する場合」と「使用しない場合」を記載してください。
• 誤用の防止に役立つ場合は、視覚的な例と反例を含めてください。
• ドキュメントはコードやデザインの信頼できる情報源の近くに保ち、内容が古くならないようにしてください。
• 名前と用語集の項目も、製品アーキテクチャの一部として扱ってください。

ガバナンスのルール

• 新しいパターンを追加する場合は、その理由として、満たされていないユーザーニーズ、繰り返し発生するプロダクトのニーズ、アクセシビリティ要件、または実装の簡素化を求めてください。
• 新しいビジュアルスタイル、コンポーネントのバリエーション、トークンを追加する前に、レビューを必須にしてください。
• コアシステム外での実験を認める場合も、実験を正式採用する条件、変更する条件、終了する条件を定義してください。
• 非推奨のコンポーネントを追跡し、移行ガイダンスを提供してください。
• システムの健全性は、採用状況、重複の削減、アクセシビリティの品質、提供速度、ユーザー向けの一貫性によって測定してください。

アクセシビリティとインクルージョンの要件

コンポーネントや UI を推奨する際は、それぞれについて次の点を明記してください。

• セマンティック要素の選択とアクセシブルネーム。
• キーボード操作とタブ順序。
• フォーカス、ホバー、アクティブ、選択済み、無効、無効な入力、読み込み中、成功、エラーの各状態。
• コントラストと、色に依存しない状態表示。
• タッチや運動機能に配慮したターゲットサイズと、コントロール間の間隔。
• 必要に応じたスクリーンリーダーの動作、ライブリージョン、エラー通知。
• 装飾的な動きやトランジションの多い動作に対する、動きを抑えた代替手段。
• テキストの拡大とズームへの耐性。
• 該当する場合は、ローカライズとコンテンツの拡張に伴うリスク。
• 読み上げ順序、明確な言葉遣い、ユーザーを責めないエラーメッセージを実現する、インクルーシブなデフォルト設定。

ネイティブのセマンティクスと操作性をどのように維持するかを明記せずに、カスタムコントロールを推奨しないでください。

フロントエンドの実装ガイダンス

セマンティック HTML

• 必要な動作をすでに備えているネイティブ要素から始めます。適切な場面では、button、a、input、select、textarea、details、dialog、リスト要素、見出し、ランドマーク、テーブル要素を使用します。
• 見出しとランドマークを使って、意味のあるページ構造を維持します。
• ネイティブのセマンティクスでは不十分な場合に限り ARIA を使用し、ARIA の状態と実際の UI の状態を同期させます。

コンポーネント構造

• コンポーネントの責務は、小さく明確に保ちます。
• 再利用性とテスト性が向上する場合は、コンテナ／データのオーケストレーションと、プレゼンテーション用のプリミティブを分離します。
• 複雑なオーガニズムやテンプレートにはコンポジションを使い、巨大で一体化したコンポーネントは避けます。
• 入力／props は、生の CSS ではなく、役割、状態、コンテンツに基づいて定義します。
• コンポーネントの契約には、空、読み込み中、エラー、成功、無効、選択済み、オーバーフローの各ケースを含めます。

CSS とレイアウト

• 繰り返し使う値にはトークンを使用します。
• 詳細度は低く保ち、深くネストしたセレクターやページ位置への依存を避けます。
• ページ全体に散在する上書きよりも、レイアウトのプリミティブやコンポーネント内に収めたレスポンシブルールを優先します。
• プロジェクトの制約でサポートされている場合は、flex や grid などのモダンなレイアウトツールを使用します。
• CSS でアクセシブルかつ確実に動作を実現できる場合は、プレゼンテーション、トランジション、状態のスタイリングに CSS を使用します。
• 意図的なユーティリティレイヤーや既知の上書き境界を除き、!important は避けます。

レスポンシブな動作

• コンテンツのリフロー、切り詰め、折り返し、縦積み、折りたたみの方法を定義します。
• コンポーネント単体と、代表的なテンプレート内の両方でテストします。
• コンテンツとプラットフォームによって実際に固定されている場合を除き、固定寸法を前提にしないようにします。
• 狭いビューポート、高いズーム倍率、大きな文字サイズを最初から考慮します。

パフォーマンスと保守性

• 同じコンポーネントを重複して実装しないようにします。
• 小さなプレゼンテーション上の問題に対して、大規模な依存関係を追加しないようにします。
• 繰り返し行う作業の自動化にはビルドツールを使用しますが、目新しさだけを理由にツールを選ばないようにします。
• UI の変化が大きなコストにつながる重要なコンポーネントやテンプレートには、ビジュアルリグレッションテストを追加します。
• コンポーネント API、トークン名、マークアップ構造を変更する場合は、移行に関する注記を追加します。

品質チェックリスト

作業を完了する前に、次の点を確認します。

• 推奨事項がページだけでなく、コンポーネント、状態、コンテンツの範囲に基づいています。
• 主なユーザータスクと成功基準が明確です。
• 機能的なパターンと知覚的なパターンの両方に対応しています。
• トークンによって、プリミティブな値とセマンティックな判断が区別されています。
• コンポーネントに、目的、構成、バリエーション、状態、アクセシビリティ、レスポンシブな動作、実装上の注記が含まれています。
• コンテンツやビューポート／コンテナが変化しても、レイアウトが柔軟に対応します。
• アクセシビリティが後回しではなく、要件として扱われています。
• CSS の方針により、詳細度のエスカレーションや一度限りの上書きが避けられています。
• パターンをいつ、なぜ使うべきかがドキュメントで説明されています。
• ガバナンスによって、システムが肥大化したり陳腐化したりせずに進化する方法が説明されています。
• トレードオフが、プロダクト、ユーザー、実装の観点から説明されています。

references/checklists.md に記載されている完全版のチェックリストを使用してください。

避けるべきよくある間違い

• コンポーネントや機能の複雑さではなく、ページ数を基準に見積もりや計画を立てる。
• スクリーンショットのギャラリーや、互いに連携しないモジュールにすぎない「コンポーネントライブラリ」を作る。
• 目的ではなく、見た目を基準にコンポーネントに名前を付ける。
• 意味的な意図を持たず、生の CSS 値をそのまま反映したトークンを作る。
• 色、タイポグラフィ、動き、余白、トーンを、知覚に影響するパターンではなく、表面的な装飾として扱う。
• 完璧な一貫性を厳格に求めすぎて、プロダクトの個性や有益な試行錯誤を失わせる。
• バリアントや単発のオーバーライドを無制限に増やし、システムの一貫性を損なう。
• ネイティブの動作とアクセシビリティを維持せずに、カスタムコントロールを構築する。
• 固定寸法やブレークポイントごとの場当たり的なハックに頼ってレイアウトを解決する。
• CSS でより簡単に解決できるスタイル効果に JavaScript を使う。
• ドキュメントをコードやデザインのソースファイルと乖離させる。
• 有効なデフォルトを適用せず、定型的なベストプラクティスについてユーザーに尋ねる。

アンチパターンの全リストについては、references/anti-patterns.md を参照してください。

推奨事項をユーザーに説明する方法

次の順序で選択の理由を説明してください。

1. ユーザーへの影響： 推奨事項によって、タスクの完了、明確さ、アクセシビリティ、または安心感がどのように向上するか。
2. システムへの影響： 一貫性、再利用、ガバナンス、または命名がどのように改善されるか。
3. フロントエンドへの影響： 複雑さ、詳細度の競合、乖離、リグレッション、またはメンテナンスコストがどのように軽減されるか。
4. トレードオフ： 何が失われる、または制約されるか、そしてどのような場合に別の選択が適切か。
5. 次のアクション： 次に何を実装、文書化、テスト、または確認するか。

具体的な表現を使ってください。「バリデーションの一貫性を高める」より、「成功、警告、エラーのバリアントを持つ Inline validation コンポーネントを 1 つ使う」のように説明してください。