LayerX バクラク事業部 Enabling チームでスタッフエンジニアをしている izumin5210 です。
Ubie さんの「社内デザインシステムをMCPサーバー化したらUI実装が爆速になった」を拝見し、悔しかった感動したので、自分でも試してみました。
以下に引用する Ubie さんのスライドで解説されているとおりですが、現行モデルでは全コンポーネントのコードやルールを一気に渡してもノイズが多くなりすぎるためか、満足のいく性能は出ませんでした。
これは MCP サーバ化したとしても同様で、Tool 1回の呼び出しで全コンポーネントの詳細情報をすべて返すとやはり情報がぼやけてしまいます。
これらを踏まえると、以下のような2つのツールに分けて提供するのがよさそうだと判断しました。
（RESTish な API における List API / Get API の分割と同じような考え方になりますね。ちょっとおもしろい。）
弊社バクラク事業部でも React 製 webapp 向けに共通 UI コンポーネントを整備しており、かつコードコメントと Storybook による簡易なドキュメント・用例集をメンテナンスしています。それを AI Agent が活用できれば生産性がグッと高まることが期待できます。
MCP は公式で TypeScript SDK を公開しています。TypeScript や React のエコシステムを活用しつつ MCP サーバを実装することが比較的容易にできます。
Storybook をブラウザで開くときに Chrome DevTools などで通信を見てみると、最初に index.json というファイルをフェッチしています。
これは名前そのままで、提供されている Story の一覧が記述されたファイルです。
{
"v": 5,
"entries": {
"button--docs": {
"id": "button--docs",
"title": "アクションUI/ボタン Button [ready]",
"name": "Docs",
"importPath": "./src/components/Button/Button.stories.tsx",
"type": "docs",
"tags": [
"autodocs"
],
"storiesImports": []
},
}
}
コンポーネントの一覧を取得する方法は色々ありますが、「外部からの利用が想定された共通 UI コンポーネントの一覧」と捉えると Storybook の Story 一覧が手っ取り早いかなと思い、この JSON を加工して MCPサーバから返すようにしてみました。
公開 API ではないので仕様が変わって壊れる可能性もありますが、社内ツールならなんとかなるだろ！の精神で勢いよくやっています。
先程もかるく触れましたが、エディタの hover や Storybook などで参照できるようにするため、各コンポーネントには TSDoc(コメント) で簡単な説明や利用例を記述していました。
type ButtonProps = {
disabled?: boolean;
disabledReason?: ReactNode;
};
export function Button(props: ButtonProps) {
}
なので、この情報を MCP サーバから返すことができればよさそうです。最も単純には、このコンポーネントが実装された .tsx ファイルを渡すことが考えられます。
しかし、バクラク事業部で利用する共通コンポーネント実装では cva を利用してスタイルを記述していたり、複数ファイルにまたがる多少複雑なコンポーネントがあるなど、コンポーネントが1ファイルしないことも多いです。かといって関連する全てのファイルを渡してしまうと情報の密度が下がってしまいます。
そこで、最低限かつ詳細なコンポーネント情報を取得するために、Storybook に着目しました。
Storybook は TypeScript の型情報やコンポーネントのコメントからドキュメントを生成してくれます。
Button コンポーネントの Storybook。
型定義と TSDoc（コメント） から Props のドキュメントを生成してくれている。
この Props のドキュメントは内部的には react-docgen あるいは react-docgen-typescript というパッケージを用いることで実現されています。
ということは、これらのパッケージを使うことで Props の詳細情報が取得できるはずです。
できました。
Cursor Agent に Button の Props を聞くと答えてくれる
Cursor Agent に Button の使い方を聞くと答えてくれる
この記事で紹介した MCP サーバの実装はやっつけプロトタイプですが、これだけでも AI による開発支援の恩恵の向上はそれなりに感じることができました。他にも Storybook を Playwright で解釈させる、API 上重要な実装だけを何らかの手段で抜き出して読ませる、あるいはコンテキストが拡大したら全部読ませる… など、さまざまなアプローチや改善の方法が考えられそうです。
また、「デザインシステム（共通 UI コンポーネント）」というアセットはもちろんですが、ドキュメント・コードコメントや Storybook などもいままで以上に開発生産性を高めるツールとして有効になりそうです。
また、個人的にはコードや API スキーマを静的解析してアレコレすることが好きなのですが、AI 時代においても決定的な形で情報を圧縮する手段として有効活用できる道もあるのかな？と感じています。
自分は MCP をプロトコルの仕様以上のことはすごく浅い理解しかしていなかったのですが、実際に手を動かしてみたことで意義が腹落ちした感じがしたのもよかったです。
AI による開発支援の世界はまだまだ進化し続けている・なにが起きるかわからないですが、それでも手を動かし解像度を高めていくことのは大事だし楽しいのでやっていきます。
Be the first to comment
