トーク

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

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

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

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

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

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

業務で 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の魅力を再発見して活用の幅を広げましょう！

某動画配信サービスのWebブラウザ向けプレイヤーにおいて、大規模なリプレイスを実施しました。
案件PRの最終的なファイル変更数は260を超え、リプレイスの対象領域もCSSフレームワークやグローバル状態管理ライブラリの刷新、利用しているOSSのメジャーバージョンアップの対応、パフォーマンス改善の一環としてのリファクタリングや非同期処理フローの見直しなど多岐に渡ります。

本セッションでは、主に以下の技術的観点について詳しく掘り下げます。

・なぜプレイヤーの全面的なリプレイスが必要だったのか（リリース当初に発生した課題）
・複数のブラウザやOS、ユーザー環境に依存するゆえのトラブルシューティング（再生環境や端末依存の不具合への対応）
・リプレイス前後で開発体験やパフォーマンスにどの程度ポジティブな効果があったか

本リプレイスに約半年間取り組んだ中で得た知見と学びについてお話しします。

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だけでどこまで広げられるのか。
その可能性とワクワクを、会場とシェアしたいと思っています。

アクセシビリティって難しそう...」そんな声をよく耳にします。
確かにWCAGガイドライン、スクリーンリーダー対応など専門用語が飛び交い、敷居が高く感じられるのも無理はありません。

しかし、2024年にiPhoneに搭載されたEye Tracking機能を触ってみると、驚くほどシンプルにアクセシビリティの恩恵を感じることができます。視線だけでアプリを操作する体験は、「使いやすさとは何か」を直感的に教えてくれるのです。

この発表では、実際にEye Tracking機能を使いながら、アクセシビリティの基本概念を体感的に学びます。

技術的な実装例も交えながら、Eye Tracking機能を通じて自然と身につくアクセシブルな設計思考を紹介します。

アクセシビリティは特別なものではなく、すべてのユーザーにとっての「当たり前の使いやすさ」なのだということを、一緒に体感してみませんか？

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

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

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

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

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

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

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

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

話す予定の内容

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