トーク

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

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

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

概要
サービス開発・運用をする上で最早テストは必須と言って過言ではありません。
私は普段業務でエディター開発を行っているのですが、構成の複雑さが相まって気がついたらとある機能が壊れていた・動いていなかった、画像表示のデザインを修正したらそれとは別の画像表示のデザインが崩れていた、といった事態が起こりやすい環境です。
そんな環境でも自分たちにとって安全に、安心してエディター開発ができるよう実装と共にテストの作成を行っています。

本セッションでは、
・VitestとPlaywrightの両方が必要な理由
・実際にテストで担保している機能の例
をベースにどのようにしてエディターの品質を保っているのかを解説します。

内容：React のアップデートを振り返り、現在の開発環境と比較を行う
対象者：初学者、若手フロントエンジニア、中級者

React は 2013 年の登場以来、Web フロントエンドの在り方を大きく変えてきました。
しかし、自分を含めエンジニアを始めた時には既に React が存在し、多くの開発現場で使用されている環境では、React がどのような歴史を辿って今の開発体験が得られたのか知らない方も多いと思っております。
そのため、本セッションでは、React の歴史的なアップデートを振り返りながら今の開発体験がどれほど快適になったかを見ていきたいと思います。

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 が有力候補となる理由
・主要ライブラリとの比較
・現行プロジェクトでの移行検証と得られた知見

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

業務で Server Component を使った時にハマったことと解決のために工夫したことを共有します。

(1) Suspense 入れたら Storybook が壊れた
パフォーマンス改善のために suspense を使い始めたら、サーバー専用ライブラリ（ex. Prisma）を使っていたため、Storybook がエラーで起動できなくなった。でもサーバー専用ライブラリを空のモジュールにモックすることで解決！

(1) Server Component でもクライアント側の操作をしないといけない
Server Component として設計したトップレベルのコンポーネントで状態管理が必要になってしまった。 でも Renderless Component を使って状態操作だけを分離することで解決！

これから Server Component 触る皆さんのお役に立てたら嬉しいです！

TypeScript は「構造的型付け（Structural Typing）」を採用していると言われます。
つまり、型に定義されていないプロパティが存在しても、それが使用されなければ基本的にエラーにはなりません。

ですが、そうでもない別の型チェックシステムがあるということみなさんご存知でしょうか？
実は構造的型付けとは異なる文脈で働く TypeScript の型チェックの仕組みが存在します。

オブジェクト型のプロパティがすべて任意の場合弱い型（weak type）のチェックと、
オブジェクトリテラルに型注釈をする場合実行される余剰プロパティチェックがその例です。

今回の LT では このように Typescript の基本思想と違う型チェックシステムを紹介します！
Typescript 型システムへの理解をもっと深められる機会になると思います。

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

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

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

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

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

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

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

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

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

Framerについてご存知でしょうか。本LTでは、React開発経験のあるエンジニアが、この注目ツールを実案件で試したリアルな体験談を共有します。
Reactでお手軽にリッチなLPが書けるようになった一方、少し凝ったことをしようとすると顔を出すノーコードツールの壁、そして複雑化するコード。エンジニアが実案件で感じたFramerの良さとその限界をリアルに語ります。
Framer導入を検討しているエンジニアの方、ノーコード/ローコードツールとエンジニアのより良い付き合い方にご興味のある方、ぜひお聞きください！

アプリケーション開発で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などで扱うデータソースへの適切なアクセス制御

ANT+とはロードバイクに代表されるスポーツアクティビティ関連センサーにおける代表的な無線通信規格の1つです。
従来PCとの連携にはUSBタイプの送受信器を通じてシリアル通信する必要があることから、ANT+を用いたアプリ開発はネイティブアプリケーションに限られていました。
一方、ユーザーにアプリを利用してもらうには極力インストール・セットアップ作業を減らし、すぐ使えるWebアプリケーションが有利なことは明白です。
そこで、「セキュリティに難ありで万年Experimental的実装から脱却できない WebUSB APIを使ったら、それできんじゃね？」という安易な考えで数年前に製作したライブラリのお話をします！

Webブラウザの枠を超えよう……！！

Web Bluetooth APIを使えば、ほんの数行のJavaScriptでブラウザから物理デバイスと無線接続できます。
LEDを光らせる、センサーの値を読み取る、ボタンを押したら反応する…そんな世界が、ネイティブアプリなしで、ブラウザだけで実現可能です。

本LTでは、Web Bluetooth APIの概要と、採択されたら作る予定の「Bluetooth早押しボタン」デバイスを紹介します。
うまくいけば、ミニクイズを交えた参加型デモもできるかも…？（失敗したら笑ってください）

「マウスやタッチではできない体験」を、Webだけでどこまで広げられるのか。
その可能性とワクワクを、会場とシェアしたいと思っています。

フロントエンドのログ収集においては、多くの開発者がこのような課題に直面します。

• minify後のエラーログがわかりづらい
• ブラウザ拡張機能による大量のログがノイズになる
• Source Map公開によるコード流出のリスクがある

この発表では、Source Mapを安全に活用しながら効率的なログ収集を実現するアプローチを以下に注目して紹介します。

• CircleCIを使ったRollbarへのSource Mapの安全な配信
• ALBでのリクエストハンドリング

実際の実装では、CI/CDパイプラインと連携したSource Map管理フローを構築し、本番環境でのセキュリティを保ちながら開発者が読みやすいエラーログを実現します。

最後に、導入後の変化と今後の展望について紹介します。
この発表が、より安全で効率的なフロントエンド開発環境の構築に向けた一歩となれば幸いです。

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

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

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