そのアプリ肥大化していませんか？バックエンドはマイクロサービスなどのライフサイクル改善手法が進んでいますが、フロントエンドはまだ…という企業が多いのではないでしょうか。フロントエンドを単機能アプリに分割、独立して開発・保守・破棄を繰り返す、現代のアプリニーズに合った「マイクロアプリアーキテクチャ」を提案します。
統合認証・認可技術の普及によるシーズ、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 の利用者をはじめ、プラットフォームに依らず応用頂けます。

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

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

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

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

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

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

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

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

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

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

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

Reactのフレームワークといえば、Next.js？
いいえ、ReactベースのWebフレームワークはNext.jsだけじゃありません。
このトークではNext.js以外のフレームワークとして、 React Router（Remix）やWakuなどさまざまなReactベースのWebフロントエンドフレームワークに触れ、その結果と個人的な感想について話をします。

デプロイのしやすさ、フレームワークの機能、レンダリングの挙動 etc...できるかぎり多くの観点で比較に挑戦します。

※このプロポーザルは執筆（2025/5/27）時点の情報を多く含みます。当日トーク内容の詳細部分に変更が入る可能性があります。

Webフロントエンド開発において、グローバルでの状態管理は常について回ってきます。
特にクライアントサイドにおいては、バックエンドや外部のサービスから取得した状態をグローバルに持ち、バックエンドと同期を取りながら画面を更新していくことが前提となっています。
とはいえ、グローバルでの状態管理は開発が進むにつれて、認知負荷が高くなりやすかったり、全体像を把握しづらかったり、はたまたライブラリを扱うためのコードで見通しが悪くなったりするなど課題も多いのが現状です。

このトークでは、極力グローバルでの状態管理を避けていかに「取得⇨更新/同期⇨取得」のサイクルを実現するかについて紹介した後に実際の事例としてReact x useSWRでの実現例、CQRS的な実装（オレオレCQRS）を取り入れることによって解決できた事柄について紹介します。

next/imageを触ったとき、「widthとheightの数値指定が必須！？widthを親要素の100%でアスペクト比を維持したいな。。。」と悩んだことはありませんか？
そこに現れた救世主、fill=true。なんとこの要件をいとも簡単に満たしてくれます。
これで表示されているし一件落着。。。しかしここには１つ落とし穴があります。

next/imageを採用する理由の1つは、画像サイズを表示領域に合わせるように最適化して配信してくれることです。
しかし、fill=trueだと事前に取得したい画像サイズが不明であり、多くの場合では表示領域より巨大な画像が取得されてしまいます。

本トークでは起こりうる状況・原因・解決策を、imgタグ、devicePixelRatioの話を絡めつつお話します。

ClineやGitHub Copilotのようなコーディングエージェントの登場により、エンジニアが従来のチャットによるLLMとの対話からAIエージェントを使用する機会は増えてきていると思います。
一方で、生成AIアプリケーションの開発という点でも、業務をワークフローとしてAIエージェントに実行させるAgentic Workflowアプリケーションの開発というのも増えてきています。
本トークではAgentic WorkflowアプリケーションのUI実装をする際に発生した複雑な状態管理に立ち向かうために行ったことについてお話しします。

話すこと

• チャットアプリケーションとAgentic WorkflowアプリケーションのUI実装における違い
• Agentic Workflowの状態管理を行う際の複雑さ
• XStateを使用した解決策の提案