トーク

プロダクト開発におけるAI活用は、現状コーディングタスクが一般的です。しかしそれ以外の開発タスクにおいても、AIを有効に活用できる可能性があります。
その一例としてユーザービリティテストがあります。

ユーザビリティテストはユーザー体験を改善するために重要ですが、その継続的な実施には多大な時間とコストがかかります。また人間の主観的な評価が求められるため、自動化は困難な領域とされてきました。その一方でAIエージェントを用いてユーザーの行動をシミュレートし、擬似的にユーザビリティテストを行う萌芽的研究が登場しています。

本セッションでは、実際のプロダクト開発現場にAIエージェントによるユーザビリティテストをPoC導入した結果、得られたインサイトを共有します。
また、AIエージェントの活用がユーザー体験の改善に今後どのように貢献できるのか、その課題は何かについても考察します。

DuckDB Wasmの魅力の１つとして、フロントエンドの実装だけで地理空間情報を扱うことができるということがあります
実際、どのような構成となるのか、メリットやデメリットなど、サンプルのアプリケーションを通じてお伝えできればと思います

React でパフォーマンス最適化のために React.memo を使うことがありますが、ちゃんと使うことは意外とトリッキーです。

たとえ React.memo でメモ化しても、props がオブジェクトや関数だと参照が毎回変わるため、再レンダリングが発生してしまいます。その場合は props も useMemo や useCallback を使ってメモ化しないといけません。

何か思いませんか？はい、めんどくさいし冗長です。

この課題を解決するために React チームは2021年に React Forget を発表しました。コンパイル時に依存関係を解析し、自動でメモ化を挿入してくれる仕組みです。そしてその実装である React Compiler は2025 年に RC版として公開されました。

その React Compiler の仕組みや導入方法を紹介したいと思います！

2025年3月、styled-components がメンテナンスモードへ移行することが発表されました。
弊社を含め、多くの開発チームが次に選ぶべきスタイリングライブラリに頭を悩ませているのではないでしょうか。

どの選択肢にも移行コストは伴いますが、できる限りその負担を抑えたいのが理想です。
本セッションでは、コストを抑えつつ次世代の要求を満たす有力候補 「Next-Yak」 にフォーカスし、その可能性を深ぼっていきます。

・Next-Yakとは
・Next-Yak が有力候補となる理由
・主要ライブラリとの比較
・現行プロジェクトでの移行検証と得られた知見

上記トピックを交えながらお話しします。

Kent C. Dodds が提唱した Testing Trophy はWebフロントエンド開発にテストの重要性と、効果的なテスト戦略の基礎となる知見をもたらしました。 Testing Trophy がフロントエンドテストの常識として確立した結果、現代では新たな問題が顕在し始めています。それはテストの実行コストの肥大化やテストの壊れやすさなどの問題です。Testing Trophy ではこれらの問題に対する指針を与えてくれず、そのため現代においては Testing Trophy は叫ばないテストアーキテクチャとなってしまいました。そこで本セッションではGoogleが提唱した Test sizes の分類と関数・UI・E2Eの分類との2つの分類を導入することでテスト設計に対する新たな指針を与えます。より効率的で堅牢なテストについて考えるための叫ぶテストアーキテクチャの実現を目指します。

対象: フロントエンド初心者～中級者向け予定

最近はAIエージェントによるコーディングが急速に発展し、フロントエンドの開発経験がなくても、AIが高品質なコードを生成することができるようになりました。
しかし、プロダクトにバグが発生した際、ユーザーに影響を与える責任を負うのは開発者です。
AIに「何を作ってくれ」と指示するだけでなく、適切な作業計画を立てて実装を進めることで、より高品質で保守しやすいコードを実現できると考えています。

このトークでは、入力フォームの実装という基本的な機能の開発を例に、日頃行っている作業工程を発表したいと思っています。

• 実装の順序
• バリデーションの方法
• テストの設計・実装方法

『それはもっといいやり方がある』『なるほど、そこは取り入れても良いかもしれない』といった議論の叩き台になれば幸いです

目まぐるしく移り変わる web フロントエンドの世界において最も重要な要素とはなんでしょうか。ずばり「互換性」です。

ライブラリの提供する API や体験、運用されているコードのインターフェースやプロダクトの提供する価値に至るまで、私達 web フロントエンドエンジニアは常に「互換性」と向き合っています。

本トークでは、そんな「互換性」の重要性について紐解き、このトークを通じて皆さんの「互換性」に対する考えが変わることを期待しています。

• 互換性ってなんだ？
• 互換性に裏切られた例
• 互換性に救われた例
  • webpack から rspack への移行など…
• 互換性との向き合い方

アプリケーション開発でSVGのイラストを使う場面は多いですが、中身については実は見逃されがちです。このセッションでは、SVGの基本的な構造から、光る・動く・触れるイラストの実装方法、さらに情報可視化の応用まで、SVGの多彩な表現力と実用性を紐解きます。
line要素やcircle要素、path要素といった基本的な要素から、動的なイラストを定義できるanimate要素を使ってイラストを光らせたり動かしたりする方法にも触れます。tabindex属性を使ってキーボードでも操作可能にしたり、多言語に対応したりして、アクセシブルなイラストを作る方法も提案します。
後半では、SVG要素の機能と簡単なCSSを使って作る地図機能の実装の一例を紹介します。この実装は、天気予報図など、イラストと連動する情報を提供したい場面に応用できます。
SVGの魅力を再発見して活用の幅を広げましょう！

CSSは、変数や関数、様々な擬似クラスや制御文(if else)などの登場で、UI実装をマークアップで完結できるような進化を遂げています。
便利な構文が増え、JavsScriptが介在しない軽量なUIを組みやすくなった反面、複雑な記述を生み出しやすくもなっています。

本セッションでは、これまではJavaScriptが必須だったが、今ではCSSで実装できるUIと、これに対するテスト手法を検討し、CSSによる堅牢かつ軽量なUI実装の可能性を探ります。

・どのようにすればCSSを安全に活用できるのでしょうか？
・CSSで果たしてどこまでフロントエンドを開発できるのでしょうか？
・CSSは今後のフロントエンドの開発で、どういった立ち位置になるのでしょうか？

以上の問いに対する答えとなるようなセッションとなっています。

AIエージェントは、ユーザー体験を劇的に変える可能性を秘めています。タスクの非同期実行や、データに基づいた最適なアクション提案など、その恩恵は計り知れません。しかし、これまでのアプリケーションとは異なる特性を持つAIエージェントにおいて、セキュリティ、特に認証・認可の設計は十分に考慮されているでしょうか？

本セッションでは、セキュアなAIエージェントアプリケーションを開発するにあたり重要な認証、認可の4つの観点について取り上げます。

• ユーザー認証: アプリ利用者（ユーザー）の安全な識別と信頼性確保
• AIエージェントによる外部API呼び出し: 外部サービスアクセス時の認証情報管理
• バックグラウンドのAIエージェント認可: 非同期・自律的なAIエージェントが処理を行う際の同意取得
• 外部データへのきめ細かなアクセス権の制御: RAGなどで扱うデータソースへの適切なアクセス制御

HTMLにおける“品質”って何でしょうか？
私の所属する会社では、HTMLに対する品質基準が明文化されておらず、lintツール導入時にも「何をもって良いHTMLとするか」「良いHTMLを担保するためにどんなルールが必要なのか」が定まっていない、そもそもHTMLの仕様理解にばらつきがある、などの課題がありました。

本トークではHTMLの品質ってどうやって担保できるんだろう？から深堀りしてHTMLクライテリアを作成した話やクライテリアの結果を元に行った改善活動について紹介します。

話す予定の内容

• HTMLの品質について
• HTMLクライテリア策定のプロセス
• クライテリアの構成と内容
• クライテリアの結果を元に改善した活動

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

そこから四年。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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の、甘い誘惑に人は耐えらえない────。

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

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