トーク

あるレガシーな組織から、あるECサービスが 2020年12月 に公開されました。
このサービスは、Webアプリケーションとして開発されましたが、スマートフォンアプリからも利用されるようになりました。
現在ではアクティブユーザー数が27万名を超え、全道の多くの方々に利用されています。

そこから四年。

機能追加、メンバーの変遷、Vue3へのアップグレード、多くの歴史が刻まれています。
気がつくと、 Core Web Vitals の値が赤く輝いています。
そう、今こそ改善のとき。

このセッションでは、レガシー企業で産み出されたサービスを地道に改善した体験をお話しします。
この中で、何が問題になったか、改善の順番をどう考えたか、どのように改善を進めたか、といったことも具体的にお話ししていきます。

フロントエンド開発では切っても切り離せないRegex。
とても便利ですがなかなか覚えられない人も多いのではないでしょうか。
私自身よくド忘れしては屈辱的な思いでググっていました......

最近ではAIエージェントのおかげで丸暗記する必要はなくなってきていますが、基本的な内容まで聞いてトークンを消費するのは少々勿体無い。

そこで、よく使う正規表現のパターンと事例をご紹介いたします！
「正規表現は上手く使うとこんなに便利」ということを伝えつつ、覚えておいた方が良いパターンをお話しできればと思います。

ライブラリの導入や更新時、package.json だけを管理対象にしていると、意図しないUIの崩れや動作不良が発生することがあります。このセッションでは radix-ui の使用中に発生した操作性の不具合を具体例に、lockファイルの不整合が引き起こす問題を紹介し、その原因と対策を考察します。
具体的には、dependabotを活用して問題を未然に防ぐ方法や、package.jsonのoverrides機能を使用して問題の再発を防ぐための管理手法を紹介します。
コードの品質を上げるためにLinterや自動テストの運用が注目を集めています。それらと同じように、依存ライブラリの管理の重要性も再認識し、安定的な運用に取り組むきっかけになれば幸いです。

フロントエンド担当不在で引き継いだアプリは、同じ用途のUIコンポーネントがファイルごとに散在し、モバイル対応もアクセシビリティも手薄でした。改修したい部分は多いものの、かけられる工数は限られています。
そこでコンポーネントコレクションのshadcn-vueを採用。高品質なUIコンポーネントに既存デザインシステムをTailwindトークンで適用し、最小限のスタイル変更で置換。少ない工数でコンポーネント整理と改修を実現しました。本発表では、このshadcn-vueを用い「頑張らない」UI刷新を少ない工数で達成した背景、実践テクニック、導入後の変化を紹介します。

話すこと

・shadcn-vueを選んだ背景と他案との比較
・最小変更でデザインシステムへフィットさせる実践テク
・shadcn-vue導入後の変化

「Webエンジニア」から「フロントエンド」という職域が分化してから、フロントエンドにまつわる領域は広がり続け、覚えておかなければならないことは多くなってきています。
「今、何を学ぶべきか」「代わりに何を後回しにしてもいいのか」と情報の取捨選択に迷う人も多いと思います。

本セッションでは、チームの技術判断を担う立場から、日々の情報収集をどのように技術選定へ繋げているのか、その具体的なプロセスを失敗談も交えてご紹介します。

技術の選択肢が数多くある中で、何を学び、何に注目すべきかの判断は、個人のみならずチームや組織の成長にも直結します。
特に「なんとなくの技術選定をやめたい」「キャッチアップの精度を上げたい」「情報をうまくチームに還元したい」と感じている開発者に向けて、情報との付き合い方を改めて見直すヒントをお届けします。

そのアプリ肥大化していませんか？バックエンドはマイクロサービスなどのライフサイクル改善手法が進んでいますが、フロントエンドはまだ…という企業が多いのではないでしょうか。フロントエンドを単機能アプリに分割、独立して開発・保守・破棄を繰り返す、現代のアプリニーズに合った「マイクロアプリアーキテクチャ」を提案します。
統合認証・認可技術の普及によるシーズ、VUCA時代のアプリ開発の難しさによるニーズ、双方から必要となってくるマイクロアプリ開発の考え方について発表します。

JavaScriptでリストをソートする際、多くの開発者は sort() 関数を何気なく使っているのではないでしょうか？

しかし、「ソート」と一言で言っても、複数のアルゴリズムが存在しており、それぞれ特徴や性能が異なります。
また、JavaScriptの内部実装は、使っている実行環境（エンジン）によって異なり、sort()関数もその例外ではなく内部で使用されているソートアルゴリズムが異なるのです。
つまり、同じコードでも、実行環境（エンジン）によって処理速度に微妙な差が生じる可能性があるということになります。

本トークでは、普段何気なく使用しているsort() 関数の裏側に焦点を当てて、実行環境（エンジン）ごとのソートアルゴリズムの違いや処理速度の微妙な違いなどをお伝えできたらと思います。

・「新しいESLintルールを導入したいけど、既存のコードで大量のエラーが出てしまう…諦めよう」
・「ESLintを導入したけど、既存のエラーが多すぎで心が折れそう…」

このような挫折を経験された方も多いのではないでしょうか？（私も経験者です）

このような状況で、ESLintのルールを新たに導入したいけど既存のコードが邪魔をしている、という悩みはよくあります。

このトークでは、ESLintの新機能であるbulk suppressionsを使って、既存のコードに対して段階的にルールを適用し、品質改善を進める方法を紹介します。

ESLintは、JavaScriptやTypeScriptのコード品質を維持するための重要なツールです。
理想的には最初からESLintを導入して品質を保つことですが、現実には既存の大規模コードベースで数千、数万のESLintエラーが発生しているケースが多々あります。

私たちも同様の課題に直面し、効果的な段階的解消戦略を開発・実践しています。

改善はまだ道半ばですが、これまでの経験から得られた知見と戦略をお話しします。

以下のような課題をお持ちの方に特に参考になると思います：

• 「ESLintを導入したいが、既存コードのエラーが膨大で手がつけられない」
• 「ESLintエラーを解消したいが、効率的な進め方がわからない」

私たちと同じ悩みを抱える方々に向けて、段階的な解消戦略の具体例と実践方法を紹介します。

社内デザインシステムをMCPサーバー化し、AI エージェントに UI 実装を生成させる取り組みが話題になりました。指定のルールに従った精度の高いコードをAIに書かせられる一方、MCPサーバーの保守や提供情報の整備といった課題もあります。

そんな中、「Storybook に代表される UI コンポーネントカタログにMCPサーバー機能を搭載すれば、追加投資なしに AI 活用できるのでは？」と思いつきました。UI コンポーネントカタログは、コンポーネントの一覧、パラメータ、使用例、といった、AI が必要とする情報を既に持っているからです。

本トークでは、実際に自作のカタログアプリケーションにMCP機能を追加してみたので、その結果を共有させて頂きます。
これは .NET/C# による Web フロント開発の事例ですが、Storybook の利用者をはじめ、プラットフォームに依らず応用頂けます。

Dateに代わる新たな日時操作標準APIとして、長らくTC39のプロポーザルだった Temporal がついに標準化間近。
Dateに苦しみ、多くのライブラリを用いて日時操作と格闘してきた我々フロントエンドエンジニアの福音となるか！？
2022年よりpolyfillを用いて先行利用してきた中で得られた知見とつらみを共有します！

RSC (React Server Components) が登場してから数年、React本体と周辺フレームワーク（Next.jsなど）の境界はよく分からなくなってきました。

RSCはReact本体の機能のはずですが、フレームワークが無いと使えないし、なんだかNext.jsと密結合しているようにも見えます。

そこで、このトークでは、Reactや周辺フレームワークの実装を見ながら、両者の境界がどこにあるのか、そもそもはっきりした境界があるのか、ということを明らかにします。

"use client" は誰が実装してどういう仕組みで動いているのか？　 "use server"は？　といった疑問を解消しましょう。

TypeScriptの型を使い倒す「type-challenges」は有名ですが、その裏にある Compiler API（TSC API）は、実はVSCodeやVolarでも密かに活用されています。
このLTでは、TSC APIの面白さとその学習を目的に作っている問題集「tsc-challenges」を紹介します。
ASTから一歩進んで「型の意味を読み取る」世界を、楽しく学びましょう。

Viteを使用した開発では、ファイルを編集すると、アプリケーション全体のリビルドを伴わずに、変更がブラウザで動作しているアプリケーションに反映されます。
このような仕組みを Hot Module Replacement (HMR) といい、モダンなビルドツールが提供する開発体験の基本的かつ重要な要素のひとつとなっています。

このトークは、Vue Fes Japan 2024で発表した「Demystifying Vite Internals」 (https://speakerdeck.com/nozomuikuta/demystifying-vite-internals) に関連して、
Viteの内部実装のうち、Hot Module Replacementに関わる部分を解説します。

202X、私はボタンコンポーネントのスタイルを調整していた。修正は軽微で開発も快調。
しかし動作検証をした時に悲劇は起こった。表示崩れしているのである。
ありえない、原因はコンポーネント外部から指定されているCSSだ。

狂った声を上げると同時に、「またか」と心の中で呟いていた。

素早く変更履歴をチェックすると、そのCSSを書いたのは私だ。
書き捨てCSSの、甘い誘惑に人は耐えらえない────。

様々な顔をみせる悲劇の分析、そして悲しみを繰り返さないためのプラクティスとは────。

皆さんは游ゴシックというフォントを知っていますか？

このフォントはかつてWebサービスのデフォルトフォントとして（消去法的に）それなりに有力な選択肢となっていました。
そして2025年夏現在、選ぶ理由は実質なくなりました。

本LTでは游ゴシックを見捨ててNoto Sans JPを選定するまでの経緯と、稼働中のクラウドサービスでのフォント切り替えで行った具体的かつ泥臭い知見をお話しします。

発表者はフォントにそんなに詳しくないので暖かな目でお楽しみください。

デザインシステムは「らしさ」を再現するための仕組みだと定義すると、「らしさ」の部分を設計する行為がブランディングです。
この「らしさ」をきちんと設計することで他プロダクトと差別化でき、顧客のロイヤリティも向上させることができます。
しかしブランディングを担当する部署とプロダクトの開発をする部署は離れている場合が多く、その接続に課題がある組織も多いでしょう。
このトークではプロダクトブランディングからデザインシステム、フロントエンド開発を一気通貫で接続するための手法について、事例を交えながら解説します。
デザインシステムの技術だけでなく、組織やワークフローの設計、フロントエンド開発への適用についてもお話するつもりです。

SSR（Server Side Rendering） と Server Components って何が違う？と…過去の私は思いました。
だってどっちも名前にサーバー入ってるしサーバーでなんかやるし（？）

ということで調べました。
SSR と Server Components はそもそも目的が違います。

SSR は HTML を事前に生成し、SEOや初期表示速度を改善します。
RSC は JavaScript のバンドルサイズを削減し、クライアント側のパフォーマンスを改善します。

それを踏まえ、本LTでは以下の疑問を解消していきます！

• それぞれの目的をどう達成しているのか
• 何ができて何ができないのか
• SSR と RSC を一緒に使ったらなぜいいのか

Typescript の型って複雑だと思ったことありませんか？
でも型を値の集合だと考えると、実はそんな難しくありません。

本セッションでは集合の観点から Union (和集合)、 Intersection (共通部分)を解説します。
集合の観点だと never (空集合)や unknown (全体集合)、 any (世界観クラッシャー) も分かりやすくなります。

しかし、JavaScript の Structure Typing を理解していないと集合の観点だけでは理解し難いところもあります。
オブジェクト型の Intersection って共通部分なのに何でプロパティ増えるんだ！？
逆にオブジェクト型の Union だとプロパティ減ってるんだが！？
戸惑うかもしれません、でも大丈夫！その理由もはっきり解説します。

TypeScript 型への理解がもっと深まる機会を提供しま！

デザインシステムというと、UIの共通化やルールの整備を思い浮かべる方が多いかもしれません。
でも実際には、それを「どう運用していくか」「どうやってチームに根づかせるか」のほうが、ずっと悩ましかったりします。

このトークでは、デザインシステムを導入・運用してきた中で見えてきた

• 再利用と柔軟さのバランスを取るコンポーネント設計の考え方
• 一貫性を保ちつつ変更に強くするための構造づくり
• チーム内の共通理解を育てるレビューやドキュメントの工夫
• 属人化しないための設計

など、エンジニア視点での実践と気づきを紹介します。

「とりあえず作って終わり」じゃなくて、「ちゃんと使い続けられるデザインシステム」を目指す。
そのために実践してることを紹介します！