本稿はJCB Advent Calendar 2025の12月22日の記事です。
こんにちは！10月にJCBに入社したデザイナーの谷口です。
JCBではシステムの内製化をより効率的かつスピーディに進めるため、社内デザインシステムとして「SHIMA Design System」を構築しています。
SHIMAを用いて実装されている案件はまだ数件とわずかですが、今後SHIMAを用いた開発はさらに増えていくことが予想されます。
また社内でもAIを用いた開発手法が徐々に取り入れられているため、デザインシステムもAIがコンテキストを理解しやすい形に整備されていること、すなわちAIフレンドリーであることが求められると考えています。
まだ入社して数ヶ月かつデザイナーという職種ではありますが、
- フロントエンド領域を理解したデザイナーを目指したいこと
- SHIMA Design Systemは出来て間もないため、AI連携のための仕組みは未整備であったこと
- 叩き台となるプロトタイプを作成することで、今後のエンジニアとの議論をスムーズに進められるようにしたかったこと
という理由から、まずはできるところから少しずつ進めてみようと考えました。
デザイナーがデザインシステムをAIフレンドリーにするために様々な社外事例を調査し、時にはバイブコーディングを行いながら社内環境で試行錯誤している状況と、今後の抱負をお話しいたします。
※下記内容はデザイナーが独自に調査し、実験的な取り組みとして試行錯誤している内容となります。そもそも設定や調査内容が間違っている可能性も大いにあり得るためご了承ください。
はじめに
JCBの技術スタックは案件ごとで採択されており、JavaやReactが入り混じっている状況です。
上記を考慮し、元々Reactで実装していたデザインシステムも、社内のさまざまな技術スタックに柔軟に対応するため、現在はWeb Componentsでの実装に切り替えています。
そして、現在デザインシステムとして保持している資産は
- Figma
- GitLabで管理されているWeb Components
- Storybook
の3つがあります。 そのような状況の中でデザインシステムをAIフレンドリーにするため、いくつかのことを調査し試してみました。
Figma Code Connect
JCBではGitLabを採用しているため、「Schema 2025」で発表されたCode Connect UIは現状使うことができません。
そのためCode Connect CLIの公式ドキュメンテーションを見ながら、セットアップにチャレンジしてみることにしました。
ところが進めていくにつれ、大きな壁に出くわします。
SHIMA Design SystemはWeb Componentsのため、どうやらReactを用いたデザインシステムのように対話型セットアップやAI prop mappingを使うことができないということが判明しました。
Getting started with Code Connect CLI | Developer Docs
そこで手動でローカルに設定ファイルを用意し、一部のコンポーネントのみ切り出して試してみましたがエラー、エラー、エラー…。
何度設定してもエラー続きなのと、AIに言われた解決策の通りにやってみても上手くいきません。
引き続き私が一人でここに注力しても時間を無駄にしそうなのと、頑張ったとしても今後の運用が手動になる可能性が高そうなため、
- そもそも何の目的でどういうことにトライしているのか
- 何を実施し、どのような点で上手くいかなかったのか
といった内容を、まずは資料としてまとめるようにしました。
そして、これらのトライした内容を開発メンバーにも共有し、開発メンバーの手が空いた時にスムーズに議論に移れるまでの材料を準備した上でしばらく温めることにしました。
デザインシステムのMCPサーバー化
上記の背景から、Code Connectとは別の解決策を考え始めました。
さまざまな社外事例などを集めている中で、デザインシステムのMCPサーバー化を行っている資料をいくつか拝読しました。
- Storybookの情報をMCPサーバー化する - Speaker Deck
- 社内デザインシステムをMCPサーバー化したらUI実装が爆速になった
- MCPとデザインシステムに立脚したデザインと実装の融合 - Speaker Deck
SHIMA Design SystemでもStorybookを保持していますが、SHIMA Design Systemができる前に内製化がスタートした案件でも、独自コンポーネントライブラリとしてStorybookを作成していると聞いています。
そのため、Storybookの情報をMCPサーバー化する手段が社内で確立できれば、SHIMA Design Systemだけでなく独自のコンポーネントを用いた他案件でもさらに開発が加速し効率化するかもしれないという未来が見えてきました。
これは早速試すしかない！と思い、作ってみることにしました。
MCPサーバーを小さく作ってみる
さまざまな資料を拝読したところ、デザインシステムのMCPサーバーを立てる理由として
コンポーネントに関する情報をより精度高く取得できる
そのためAIで実装する場合のコードの品質を高く保てる
などが挙げられます。大体のデザインシステムはコンポーネント数が多く、全てを読み込ませるとその分ノイズが増えやすいためです。
そこで、まずはコンポーネントの情報を取得できるようなMCPサーバーをローカルに作ってみることにしました。
AIに丸投げしてみる
MCPサーバーを作ること自体が初めてなので、どこにどう作るかが全く分からず、とりあえずAIに丸投げするところからスタートしました。
ところがAIに全て任せると、何度プロンプトを試してもやたら複雑な構造になり、何が何だかまったく分からない状況に…。
よく分からないものを、よく分からないままAIに実装させると、本当に訳が分からなくなるというループに陥りました。
そこでまずは何を作りたいのか、何を小さく実現したいのか、どういう手順が必要なのかをちゃんと理解するところからやり直すことにしました。
大枠を理解した上でAIに実装させてみる
MCPサーバー構築の大枠を理解するため、上記の資料に加えて他の資料も熟読しました。
上記の事例はReactのためreact-docgenかreact-docgen-typescriptを用いてコンポーネント情報を取得していますが、今回はWeb Componentsなので@custom-elements-manifest/analyzerを使用しており、custom-elements.jsonから取得する形に変更しました。
「custom-elements.jsonからどのような情報を取得してくるのか」「どのようなフォルダ構成にするのか」などを明確にした上でバイブコーディングを行い、数多くのエラーを修正し、ついにそれっぽいものを作ることができました！
全ファイルを参照してコンポーネントの情報を取得するという無駄がない分、スピードも速いように感じます。
また、コンポーネント全体のdescriptionも取得する形にすれば、目的に応じたコンポーネントの提示も行なってくれるようになりました。
実際にMCPサーバーを構築し自ら操作してみることで、実装時にどう役立てられそうかがイメージしやすくなり、非エンジニアによるUI検討の壁打ちに活用できそうなことも体感できました。
小さな進歩ですが、大きな達成感です。
実現のための仕組みや構造をおおよそ把握できたので、今後デザインシステムをAIフレンドリーにしていくための相談材料として、上記を活用できるのではないかと考えています。
今後の抱負
AIが凄まじい勢いで進化し、精度が高まってきている中で
- 組織観点：AI活用を最大化し、より大きな価値に繋げていくための環境整備やルールを自ら考えていく必要があること
- 個人観点：職域の境界が融けて制作や試行の幅が広がっているため、技術の進化や世の流れを能動的にキャッチアップし、常に試し続けていく必要があること
といった内容を日々感じています。
もちろん、上記はデザイナーとしての専門性も高めていくことを前提としています。
今回の試みも開発チームと協力してデザインシステムでのAI活用を促進し、ゆくゆくは社内へ展開できるような施策にしていくための、最初の小さなステップに過ぎません。
実際に社内で活用するためには実現性の判断やセキュリティ面でのリスク管理、今後の運用観点でも問題がないかを調査し、判断していく必要があります。
これらは様々な分野でAIを活用する上でも同じことが言えるように思います。
エンジニアやデザイナーが職域を超えて試した内容をそのまま全て使えるわけではなく、様々な観点で人間による慎重な判断や細かい調整が求められるはずです。
だからこそ環境整備や技術のキャッチアップも行いつつ、大前提として自身の専門性もより一層高めていきたいと考えています。
終わりに
デザインシステムをAIフレンドリーにするために実践した内容と、今後の抱負についてお話しました。
デザイナーとして新しい領域にチャレンジしたことが、少しでも皆さまの参考になれば幸いです。
また、JCBでは私たちと一緒に働きたいという方を募集しています。 詳しい募集要項等については採用ページをご覧ください。
