上記の課題を予め解消した「Amebaでよく使われるデザインパターン」を提供します。
Reactのコンポーネントとして使う場合は以下のように書けます。
売上データ（2023年第4四半期）
商品名
売上（円）
前年比
商品A
1,200,000
+12%
商品B
980,000
-3%
{/* ... */}
例えば borderTypes や rounded、 striped などのプロパティを用意しています。
このコンポーネントはこのように表示されます。
他にも様々なパターンを用意しているので、詳しくはStorybookをご覧ください。
カスタマイズ性の高い設計
AmebaLIFE事業本部ではAmebaブログをはじめ、Ameba塾探し、Ameba学校探し、Amebaチョイス、ドットマネーなどの様々なサービスを運営しています。
サービスによってテーブルのカラーセットなどのデザイン要件が異なることが多いため、これまでのSpindleコンポーネントではあまりなかったカスタマイズ性の高い設計を念頭に設計しました。
具体的には、CSS Variablesによるスタイル上書きを全面的に許可しています。
以下はその例です。基本的にはプロダクト全体でカスタマイズすることを想定していますが、個別のテーブルでもカスタマイズ可能です。
/* プロダクト全体でのカスタマイズ */
:root {
--Table-head-backgroundColor: var(--color-surface-accent-primary);
--Table-head-color: var(--color-text-high-emphasis-inverse);
}
/* 個別のテーブルでのカスタマイズ */
.custom-table {
--Table-cell-padding: 16px 12px;
--Table-borderRadius: 8px;
}
CSS Variablesは5つに分類して整備しました。
- Surface – 背景関連
- Text – テキスト関連
- Border – ボーダー関連
- Layout – レイアウト関連
- Caption – キャプション関連
これにより、Tableを扱うときのつまづきを解消しつつ、プロダクトごとの要件に柔軟に対応できる共通基盤となりました。
AI活用の実践
ここからが本題です。Tableコンポーネントの開発におけるAIとSpindle MCPの活用の話をします。
開発フロー概要
開発は大きく以下の流れです。
- Design Doc（詳細設計）（Cursor + Spindle MCP）
- 実装（Claude Code + Spindle MCP）
- レビュー・調整
設計時と実装時で期間が空いていたため、使用するAIツールが異なっています。
DesignDocは後述のSpindle MCPの活用もあり、短期間で書き上げることができました。
実装自体もDesignDocからの生成精度がかなり高く、DesignDocのレビュー段階で既に動くものを提示できていました。
もちろん、borderの細かいところなど調整が必要な部分はありましたが、基礎部分はAIが担当してくれたおかげで、デザイン要件との整合性確認やエッジケースの対応に集中できました。
Spindle MCPの威力
Spindle MCPは、SpindleデザインシステムをAIに理解させるためのツールです。
詳細については、Spindle MCP で変わるデザインシステムの開発 ~ Figma 連携で実現する超高速開発 ~をご覧ください。
1. Design Doc作成での活用
Design Doc作成時には、主に以下のSpindle MCPツールを活用しました。
get_component_design_doc_templete
Design Docのテンプレートを取得し、それをベースにAIに初稿を作成してもらいました。
get_design_tokens / get_design_token
Design Docの「CSS Variables リファレンス」セクションにて、CSS VariablesとDesign Tokenのマッピングに活用しました。
AIがDesign Tokenの意図を一定の精度で理解してくれたこと、他のリファレンスを手渡しせずともかなりの精度が出ました。
手動でやっていたらかなりの時間がかかっていたと思います。
get_accessibility_docs
Design Docでは、Ameba Accessibility Guidelinesに則したアクセシビリティセクションの生成およびレビューをAIにやってもらいました。
実装後のレビュー依頼前にも、セルフレビューの一環としてこのツールを活用してアクセシビリティチェックを行いました。
get_components / get_component_info
Design Docから初期コードを生成する際に使用しました。
Spindleならではの書き方やルールがあるので、代表的なコンポーネントを参照するよう指示しました。
AI活用の課題と学び
AIを活用することで高速に開発を進めることができた一方で課題もありました。
DO/DO NOTの生成精度
Design Doc作成時、DO/DO NOTセクションの生成はうまくいかず、手動で調整しました。
うまくいかなかった主な原因は、DO/DO NOTに何をどの粒度で書くかという共通認識が不足していたためと考えています。
Figma MCPの未活用
今回、Figma MCPは使用しませんでした。
FigmaでTableコンポーネントを直接的に表現できない制約があり、デザインデータとしても活用が難しいと考えたためです。
Tableのような構造的なコンポーネントでは、Figmaよりもテキストベースでの設計が適していると感じました。
まとめ
Cursor/Claude CodeとSpindle MCPの併用により、ラクに速く、そして品質を保ったままTableコンポーネントを開発できました。
特にDesign Docからのコードの生成精度が高く、Storybookも自動生成で大きく工数を削減できました。実際、Storybookはパターン数が多くブラウザが固まるほどで、手作業なら日が暮れていたと思います。
AI活用が進む中で、実装の詳細からより抽象度の高い設計へ時間を割けるようになりました。とりわけ、どんなコンポーネントを提供するのが長期的に良いかという観点をより意識できたのが良かったです。
今後もAIやMCPとの協働を通じて、より良い開発体験を追求していきます。
コメント