トーク

フロントエンド担当不在で引き継いだアプリは、同じ用途の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の共通化やルールの整備を思い浮かべる方が多いかもしれません。
でも実際には、それを「どう運用していくか」「どうやってチームに根づかせるか」のほうが、ずっと悩ましかったりします。

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

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

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

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

ロジスティクス関係で働く人には、おじいちゃんが沢山います。
おじいちゃん達は、年齢による症状（老眼、認知負荷）や長年ちから仕事をしているため、指が太く細かい操作がしにくいなどの問題がありました。
それらを解決するために、webエンジニアがおじいちゃんに優しいUIを作ってみたお話です。
（硬く言うと、シニア世代に向けたアクセシビリティのお話です）

Webサイト制作の際に気を付ける点のひとつに、リソースの容量があります。
読み込み速度を意識しつつ、さらにWebGLを用いたカロリーが高いサイトはモバイル環境でも快適に動作させなければなりません。
画像圧縮にもお作法があるように、3Dモデルの圧縮にもお作法があります。

本LTでは、私が実際に3Dモデルを用いたWebサイトやWebARコンテンツ案件を実装する上で学んできた知見を活かし、
WebGL製サイトがモバイルでも快適に動作するのに欠かせないモデル圧縮の基礎と応用をお伝えします。

【話すこと】
・Webに最適な3Dモデルデータ形式とは？
・テクスチャとポリゴン、それぞれの最適化法
・アニメーション付きモデルの最適化法
・スマートフォンでも快適に動作させるコツ
・フロントエンドエンジニアがモデラーへ3Dモデルを外注する際のコミュニケーションのコツ

「改行が消えた」「謎のタグが混入した」…
WYSIWYGエディタにありがちな壊れやすさに悩まされたことはありませんか？

本LTでは、Tiptap を用いてHTMLの一貫性・拡張性・テスト可能性を兼ね備えた堅牢なリッチテキストエディタをどのように設計・開発するかを紹介します。

• ProseMirrorのスキーマ定義を活用したHTML構造の強制と正規化
• Reactコンポーネントの組み込みやプラグインによる拡張性
• TiptapのExtension単位での単体テストによる機能ごとの信頼性担保

について話します。
WYSIWYGエディタの扱いに課題を感じている方や、Tiptapを本格的に活用したい方にとって実践的なヒントとなる内容をお届けします。