ikuma-t ikuma tadokoro Querying Design System デザインシステムの意思決定を⽀える構造検索 JSConf.jp 2025 Pre Event 2025-11-15 

● ikuma-t ● Webフロントエンドが好き ● 株式会社エス‧エム‧エス ⾃⼰紹介 02 Self-introduction 

構造検索で利⽤状況を調べる 03 01 Investigate usage with structural search 

04 デザインシステムは⼀度作って終わりではなく、継続的に変更する必要がある Design systems require ongoing maintenance and evolution. Component     ‧ ‧ ‧ Instance Instance 今回のユースケースだと 従来の設計に合わない ... このパターンも 追加していいかも？ Instance Instance 提案 提案 

05 提案 設計 実装 調査 どこで‧どう使われているのか Suggest Investigate Design Develop 変更の際には「影響範囲」や「使われ⽅」を知るために既存の利⽤状況を調査する When making changes, investigate the current usage to understand the scope of impact and how it is being used. 利⽤数が多いのですぐに終わらない 

06 例：Buttonのxs sizeを削除する Example: Delete Button ‘xs’ size. Button Button Q. 今どれくらい使われているのか？ xs Button sm md ・ ・ ・ + 300 buttons 🤯 現在の基準に対して ⽂字が⼩さすぎたため廃⽌を検討 

07 例：Buttonのxs sizeを削除する Example: Delete Button ‘xs’ size. Button Q. 今どれくらい使われているのか？ xs A. 3箇所で利⽤されている たとえばast-grepを使って構造検索 

構造検索を活⽤して利⽤状況を調べる テキスト検索 改⾏や順序違いのパターンなど、抽出結果に過不⾜ 08 「構造検索」⾃体はInteliJが 公式Docs（構造検索と置換） で使っているのが出典。ast-grep VSCode: 構造検索と置換の強⼒なツールでも使われている。 Investigate usage patterns using structural search. 構造検索（Structual Search） コードをその構⽂と意味に基づいて検索する

コンポーネントの利⽤状況に特化する 09 Focus on component usage. 02 

10 If the data structure is fixed, it is inefficient to assemble and format queries every time. I want to create a dedicated View. データ構造が決まっているなら、毎回 Queryして整形するのは⾮効率。 専⽤のViewを作りたい 

コンポーネントの情報が事前に構造化されていると、影響調査が簡単 11 When component information is pre-structured, impact analysis becomes easier. Component Instance Code Location Package Props Instance Props Name | Value Name | Value Package Component Instance Props Package 

コンポーネントの情報が事前に構造化されていると、影響調査が簡単（例：Button） 12 When component information is pre-structured, impact analysis becomes easier. Button [email protected] Props Props size | ”xs” size | ”xs” type | ”submit” ??./submit-button.tsx variant | ”secondary” Instance Instance ??./second-button.tsx [email protected] [email protected] 

コンポーネントの情報が事前に構造化されていると、影響調査が簡単（例：Button） 13 When component information is pre-structured, impact analysis becomes easier. Button [email protected] Props Props size | ”xs” size | ”xs” type | ”submit” ??./submit-button.tsx variant | ”secondary” Instance Instance ??./second-button.tsx [email protected] [email protected] size | ”xs” size | ”xs” Q. size=”xs”のButtonはどのくらいある？ どのように使われているか 

[email protected] コンポーネントの情報が事前に構造化されていると、影響調査が簡単（例：Button） 14 When component information is pre-structured, impact analysis becomes easier. Props Props size | ”xs” size | ”xs” type | ”submit” ??./submit-button.tsx variant | ”secondary” ??./second-button.tsx [email protected] [email protected] Button Instance Instance Q. 各コンポーネントはどれくらい使われている？ 2 どこで使われているか 

15 コンポーネント利⽤状況に特化したViewを作成する Make a View focused on how components are being used. Component Instance 

16 コンポーネント利⽤状況に特化したViewを作成する Make a View focused on how components are being used. JSXElement JSXAttributes ImportDeclaration Instance Component ??? Map 

t 17 コンポーネント利⽤状況に特化したViewを作成する Make a View focused on how components are being used. JSXElement JSXAttributes ImportDeclaration Instance Component Map Source parse AST Component Usage Instances collect summarize visualize 

18 次に述べるOmlet とよく⽐較され、Omlet公式のFAQにもOmlet vs. React Scanner | Omlet Docsがある。またレンダリングを検知する React Scan とは別物。 react-scanner（OSS） moroshko/react-scanner Instance を収集し、指定した processor の形式でJSON 出⼒してくれる。カスタムの processor をユーザー側 で追加することもできる。 ● raw-report：収集された情報をそのまま出⼒ ● count-components: コンポーネントの利⽤数 ● count-components-and-props：コンポーネン トの出現回数と Props ごとの出現回数 コンポーネント利⽤状況に特化したViewを作成するツール 

19 価格は$169/month（2025-11時点 年払いの場合）。無料でも制限付きでプロジェクトのスキャンができる。 Omlet（SaaS） ● 有料SaaSだけあってかなり⾼機能 ○ 解析のためのCLIツール（解析はRust） ○ VSCode拡張機能 ○ 解析結果を参照するためのダッシュボード ○ 継続的改善のためのスキャン結果保持 ● ⾒られるレポートも豊富 ○ コンポーネントにStorybookやテストがあるか ○ デザインシステムの採択率の推移 ○ バージョンの採択率の可視化 Omlet · Measure the Success of Your Components コンポーネント利⽤状況に特化したViewを作成するツール 

@ikuma-t/cuin 20 なぜ実装したのか 前述の2つのツールを知らなかったから...😇 画像は https://github.com/shadcn-ui/ui のルートで解析を⾏った結果です。 @ikuma-t/cuin ⚠Under Development 構成 ● oxc_parser と oxc_resolver で Instance を 収集し、napi-rs 経由で結果を返す ● 結果をビューワー（SolidJS） で表⽰ コンポーネント利⽤状況に特化したViewを作成するツール 

21 画像は https://github.com/shadcn-ui/ui のルートで解析を⾏った結果です。 コンポーネントの利⽤状況を⾒る View components usage ● コンポーネントの利⽤数 ○ Component ごとの Instance 数をカウント ○ 例：デザインシステム全体に影響する依存ライブ ラリのアップデート時に、利⽤数の多い順に移⾏ 計画を⽴てる ● コンポーネントごとの利⽤状況 ○ 例：Propsの分布から表現の揺れを確認 ○ 例：API変更時に、影響を受ける利⽤箇所をProps 指定で特定   @ikuma-t/cuin 

22 コンポーネント利⽤状況分析の実装ポイント Implementation points for component usage analysis 基本的には JSXElement をVisitしてInstanceをかき集めていけば良いが、いくつか実装ポイントがある。 1. Componentの収集 2. InstanceのComponentの同⼀性判定 3. Propsの収集粒度 

23 ● 利⽤状況の収集においては必須ではない ● 「使⽤されていないこと」を収集するには必要 ○ Instance は利⽤箇所から⽣成されるので、まった く利⽤されていない情報は上がってこない ● 収集する場合は VariableDeclaration などを ⾒ていく必要がある。 Component の収集 Collect Components コンポーネント利⽤状況分析の実装ポイント VariableDeclaration 

InstanceのComponentの同⼀性判定 24 ● Instance⾃⾝は⾃分が「どのComponentの Instanceなのか」を直接持っていない ● 別ファイル‧別パッケージからのImportの場合 は、ケースごとにルールを設けて同⼀性を判定 する必要があり、ツールによって違いが出る。 ○ 相対パスImport（import “./Button”） ○ Alias（tsconfig、Bundler） ○ Dynamic Import ○ バレルファイル ○ 外部パッケージ Instance Component Identity Check コンポーネント利⽤状況分析の実装ポイント 

Propsの収集粒度 25 ● 単純なLiteralはそのまま値を利⽤する ● 動的な値をどこまでを追跡するか ○ Expression の実際の値まで追跡するのか ○ JSXSpreadAttributesをどこまで展開するのか ● 動的な値は何を出⼒とするか ○ 「静的解析できない」という値として出⼒する ○ 「動的に決まる」という事実と、識別⼦そのもの を分けて出⼒する https://facebook.github.io/jsx/#sec-jsx-attributes Instance Component Identity Check コンポーネント利⽤状況分析の実装ポイント Omletでの表⽰。dynamicとして表⽰ JSXAttributeValueの定義 

まとめ ● デザインシステムは継続的に変更を⾏なっていく必要があり、変更の際に は既存の利⽤箇所を⾒ながら意思決定を⾏う必要がある。 ● 構造検索を活⽤することで、既存のユースケースを効率的に調べることが できる。 ● 特に既存のユースケースから必要な構造のデータを収集しておくことで、 デザインシステムのアセットの変更に役に⽴つ。 26 Conclusion 

27 もっと詳細を知りたい場合は、リンクの動画を⾒るか、あるいはGitHubに⼊社する必要がある   Primer におけるコンポーネントの利⽤状況分析（Primer Query） Every component, everywhere, all at once - YouTube GitHubのデザインシステム（Primer）で利⽤されてい るコンポーネント利⽤状況分析ツール。 ● コンポーネントの採⽤状況がすぐにわかる ● アクセシブルな状況で使われているのかを判断 ● 変更の影響範囲を理解するのに役⽴つ ● 使⽤状況から新しいユースケースやシナリオ、使 い⽅を発⾒できる 参考 スプラッシュゾーン 

ご清聴いただきありがとうございました 28 28 Thank you for your attention.