トーク

事業拡大に伴い新サービスが次々と立ち上がるフェーズでは、限られたリソースにおけるサービスの立ち上げを加速させていくことが必要です。

この取り組みの一環として、デザインシステムの構築や全社的なUIコンポーネントライブラリを作成する動きが一般的なものになりつつあります。

しかし、多くのプロダクトを抱える企業においては、汎用性を持ったデザインシステムではプリミティブなコンポーネント実装に留まることが多く、画面パターンレベルでは各サービスで同じようなボイラープレートコードを繰り返し書くことになりがちです。

本セッションでは、全社的なデザインシステムの上でブランドに特化したUIパターンライブラリを作成し、プロダクトの共通基盤を構築することで、サービスの立ち上げを加速させるための取り組みについての経緯や事例についてご紹介します。

セキュリティ対策というとインフラやサーバーサイドの領域で重視するイメージが強いかもしれません。
しかしながら昨今、Next.js、Viteなど有名なフレームワークにて脆弱性報告（CVE番号発行など）が相次いでおり
フロントエンドの領域でも軽視できないのではないかと考えます。

本セッションでは、フロントエンド開発で発生しやすい脆弱性の仕組みやリスクを事例を基にお話しします。
「自分の開発でも発生するかも？」を実感してもらい、ライブラリアップデートだけでは防げない、フロントエンド開発で意識すべき点をみんなで考えていけたらと思います。

フロントエンド開発では必ずと言って良いほど利用するnpmパッケージマネージャですが、なんとなく選んでませんか。

本セッションではあなたのプロジェクトに適切なパッケージマネージャをnpm、yarn、pnpm、bunの4種類から
インストール速度、依存関係管理、互換性、セキュリティ、運用コストなど様々な観点で解説します。

【セッション対象者】
・ 普段なんとなくnpm installしてる人
・ プロジェクトのnpmライブラリアップデートで疲弊してる人
・ フロントエンドとバックエンドの両方でnpmライブラリを利用していてパッケージ管理に悩んでる人

スクリーンリーダーは視覚的なUIの見た目だけではなく、DOM構造や設定された文字を頼りに情報を伝えるため
divボタンにonClickだけ付けたパターンや、読み順がぐちゃぐちゃなレイアウト、モーダルのフォーカストラップ漏れなど
視覚的には問題ないのに“読み上げ体験”を壊してしまうことがあります。

本セッションでは、こういった問題を解決するためのHTMLマークアップを実際にスクリーンリーダーで検証した例を交えながら
見た目だけでは測れないUI崩壊に気づくポイントと、改善例をお話します。

Webに掲載した動画に字幕をつけることは「アクセシビリティ対応」や「追加機能」として扱われがちではないでしょうか。

本セッションでは、字幕を視覚的なUIコンポーネントの一部として、「設計段階から組み込む」という視点を軸に
「字幕の表示位置とレイアウト干渉」「切替導線のわかりづらさ」「再生中の音声とのズレ」「ダークモードでの可読性不備」など
よくある落とし穴とUI設計を具体的な実装例を交えて解説します。

字幕を後付けの対応ではなく、標準的なUIコンポーネントとして扱うためのポイントをお伝えします。

Reactでデータフェッチを行う場合、useEffectとuseStateを組み合わせた実装をすることが多いのではないでしょうか。

本セッションではReactのSuspense機能を用いることで、読み込み状態の管理、エラーハンドリングをより簡潔に行う方法を解説します。
また、openapi-react-query-codegen を使いOpenAPIから型安全なクライアントを自動生成、さらにReact Queryとの親和性を活かし
ReactのSuspense機能で「待つ」UIを簡単に表現する実践例を紹介します。
自動生成されたカスタムHooksとReact Suspenseにより、TypeScriptの型安全な読み込み状態制御やエラーハンドリングを実現。
実際の事例をもとに、開発体験の向上とSuspenseの具体的なメリットをお伝えします。

配信者の求める「自分らしい配信画面」を技術的な知識なしで実現できるデザインツールをどのように実現するか。
汎用化された共通コンポーネントとCSSを活用し、複雑GUIでユーザーが簡単にアレンジできる配信画面デザインツール・配信アセットの提供を行ってきました。

このセッションでは、汎用的でありながらテンプレートとしてのベースデザインの拡張性を維持し、ユーザーが追加でいくつかのパラメータでのカスタマイズが行えるようにした手法、可変サイズに対応するために行っている工夫などをお話しします。
また、現在開発中の新サービスにおけるこの手法の変化や拡張とともに、OBS内のブラウザという特殊な環境における事情と制約、配信画面という壊れてはならないものを壊さないために行ってきたこと、安全に壊す技術についても合わせてお話しします

Storybook v9 で大幅に強化されたテスト機能は、コンポーネント開発の品質向上に非常に役立ちます。

しかし、Next.js App Router (RSC 使用)を採用していると、何も考えずにコンポーネントを実装すると Storybook の環境整備につまづくケースがあります。

Storybook では experimentalRSC フラグによる RSC サポートが試みられていますが、現時点（Next.js v15.3.3）では安定して動作しておらず、RSC 依存のコンポーネントは描画できない状況です。

本セッションでは、こうした制約の中でも Storybook のテスト機能をフル活用できるコンポーネント設計を目指し、RSC 依存を最小限にとどめる実践的なパターン・注意点を解説します。
Storybook を活かした堅牢なフロントエンド開発を目指す方におすすめの内容です。

Biome は JavaScript, TypeScript, CSS などの Format や Lint を行うツールチェインで、設定のシンプルさや高速であることから支持が広がっています。
これまで利用者がルールを追加することはできませんでしたが、v2 からは GritQL によるプラグイン定義が可能になり、独自ルールを定義できるようになりました。

しかし、ESLint プラグインが JavaScript で柔軟な記述ができることに対して、Biome がベースとする GritQL は宣言的なクエリを記述するため、表現力には違いがあります。

今回のプラグインサポートによって、ESLint エコシステムにあるライブラリやプロジェクト独自のルールはどこまで Biome に移植可能になるのか、具体例を交えて紐解いていきます。

LLM に外部データを渡したり操作させたりする手段として、Model Context Protocol（MCP）が注目されています。
MCP では当初通信方式として Server-Sent Events (SSE) をサポートしていましたが、3月の仕様改定からは代わりに Streamable HTTP が採用されました。

本セッションではこの仕様変更を出発点に、HTTP ベースのリアルタイム通信の選択肢である

• WebSocket
• Streamable HTTP
• Server-Sent Events
  を整理し、それぞれの仕組みや適切なユースケース、利点・欠点を比較します。

MCP の RFC における議論をヒントに、Web におけるリアルタイム通信をあらためて体系的に理解することを目指します。

ほとんどのスマートフォンには前面カメラ(インカメラ)と背面カメラ(リアカメラ)が付いており、 ブラウザの getUserMedia API からカメラ映像を取得することができます。
しかしカメラというのはデバイス上でただ 1 つのリソースであり、解放や再利用などについては慎重に扱わなくてはなりません。
加えて、スマートフォンというどうしても端末依存の挙動が発生する環境であるため、「手元やレビュワーの端末では問題なく動いたが、 QA フェーズで動かない端末があった」ということが発生しがちです。
このトークでは、スマートフォンでカメラを扱う際に、ナイーブに実装すると起こり得る(端末によっては動かなくなる)処理・実装の例と、これらを回避するためにどのような実装を行うべきかについて話します。

Push APIを活用すれば、Webサイトからネイティブアプリのようにプッシュ通知を送ることができます。
しかし、実際にはFirebaseなどのSDKを使って導入することが多く、内部の仕組みを学ぶ機会は多くありません。

本セッションでは、W3CのPush API仕様を紐解きながら、外部サービスに頼らずにフロントエンド・バックエンドをフルスクラッチで実装します。
通知が届くまでに、フロントエンド、ブラウザ、バックエンドサーバーがそれぞれどのような役割を担い、どう連携して動作しているのかを解説します。

概要

近年、Popover API の登場や Dialog API の進歩によって「Top layer」という新たな概念が身近になり、z-index に依存しない実装が可能になりました。このセッションでは、Top layer の仕様から、実際に触ってみてわかったことやニッチな仕様まで、まるっとスリっとゴリッとエブリシングお伝えします！

背景

私の所属するテックタッチ株式会社では、第三者の Web サイト上に操作ガイドを表示するプロダクトを開発しています。最近では様々な Web サイトで Top layer が利用されるようになり、それを考慮した機能の実装が必要になりました。その実装をするうえで得た学びを共有できればと思っています。

想定聴衆

• Top layer について理解を深めたい方
• Web 標準に興味がある方

株式会社WinTicketではクライアント(Web,App,Server)から送る行動ログを数百行のスプレッドシートで管理しており、閲覧のし辛さ、更新漏れが課題になっていました。
また行動ログのスキーマはクライアント側のコードで独自で定義をしており、期待する行動ログの構造と実際に送るリクエストに不整合が起きることもしばしばありました。
本セッションでは、Protocol Buffersでログスキーマを定義して自作のGo製protocプラグインを用いてログ仕様ドキュメントと型安全なクライアントコード(TypeScript)を自動生成し、ログ実装の保守性・信頼性を向上させた事例をフロントエンドエンジニアの視点で紹介します。

近年はフロントエンド領域でも自動テストを導入することが一般的になってきています。
私はコーディングの中でも特にテストが好きで、よく自動テストの導入などを手伝っていたりします。

そんな自分が今からテストが書かれていないReactアプリケーションに対して、テストを導入するならどうするかをテーマにテストの導入方法や向き合い方などについて紹介させていただきます。

• フロントエンドのテストは何のために存在するのか
• テストをどこから始めるか
• テストしやすいように設計を変更する
• テストが書けないなら、常にテストを書くべき理由

最新のChromeでは、オフラインでも生成AIを使える機能が搭載されており、その機能をJavaScriptから呼び出すことができます。
このGemini Nano in Chromeについては以下参考資料の頃の情報から更新しつつ、5月に発表されたGemini in Chrome（Chromeから直接AIを使う機能の方）も踏まえてお話しできればと思います。
ブラウザ上で動くAIのことを知って、ユーザーのブラウザ体験が生成AIによってどう変わるか想像できるようになりましょう！

ターゲット: Webアプリケーションを開発しているフロントエンドエンジニア
伝えたいこと: Chromeに搭載されている・される予定の生成AI機能の情報をキャッチアップしてほしい！
参考資料: https://www.docswell.com/s/gatchan0807/ZN1V6G-2024-11-23-110000

昨今話題のMCP（Model Context Protocol）について、概要を知っている方やプラットフォームが提供しているものを利用したことがある方は多いかと思います。
ですが、「自分でMCPサーバーを立ててみる」という経験をされた方はまだまだ少ないのではないかなと思い、今回の発表を聞いて実際にやってみよう！と思えるようにお話しします！
この技術自体はこれまでフロントエンドに関わって仕事をしてきた方にとって、意外とそんなにハードルが高くないものなので、ぜひ触ってみましょう！
合わせて、私が実際に触ってみてわかったハマりどころ・注意点も含めてお話しできればと思っています！🙌

ターゲット: 生成AI時代に取り残されたくない（自分のような）フロントエンドエンジニア
伝えたいこと: フロントエンドエンジニアの土壌があれば、これに手を出すことは怖くないし、キャリアの糧になる

文字と同じく数千年の歴史を誇る「改行」。あまりに身近なものなので、文章を読む時はその存在を意識することすらありません。しかし、開発の場面で改行を扱うとなると、「改行コードが複数パターンある」「CSSに似たような改行系プロパティが色々ある」といったややこしい事実に直面するうえ、挙動が思いのほか複雑なので表示崩れをはじめ様々な観点で思わぬトラブルを招く厄介な側面があります。

本セッションでは、テキストデータ・HTML・CSSのそれぞれにおける改行周りの厄介ごとを文字入力の歴史やタイポグラフィの知識などと絡めて紹介。さらにテキストデータにおける改行の扱い方から改行を制御する多種多様なCSSプロパティの使い分けまで、実務に役立つ改行のアレコレを扱います。

たった20分で、「なんとなくの実装」から脱却し、改行と自信をもって向き合えること間違いなし！

既存の物件検索サイトは保存できる検索条件の上限や、価格の変更を手動でチェックするなど、業務効率を阻む制約が多く、SaaS単体では解決が困難です。
そこで、私たちは拡張機能を前提にSaaSを設計しました。
拡張機能があることで既存のWebサイトを拡張したり、管理画面と連携することができます。

管理画面にログイン中なら拡張側も自動認証できるスマートログイン。
ダウンロード直後のPDF図面をService Workerが捕捉し管理画面へ登録するスマートアップロード。
content-scriptが埋め込んだ UI 要素と拡張機能のlocalStorageをstorageイベントで双方向同期するなど、
普段のフロントエンド開発ではなかなか取り組めない技術の組み合わせを紹介します。

当日はライブデモを交えてWebを “壊さず拡張する” 次世代フロントエンドの実践知を共有します！

フロントエンド開発の品質とスピードを保ち続けるためには要望の本質をとらえた設計と実装が重要ですが、実際の開発では目立つ要素である画面の実装や瑣末な文言に気を取られがちです。

Why「なぜ必要か」→How「どう実現するか」→What「何が出来たか」の観点でPRを段階的にレビューするという概念自体は特別新しくありません。しかし、フロントエンド開発の現場で実践してみると期待以上の効果がありました。当初はレビューの負荷を下げる目的で始めた取り組みが、チーム全体に「表層ではなく土台から積み上げる」文化をもたらしたのです。

• 誰もが知るWhy→How→Whatという枠組みが、なぜフロントエンドのPRレビューで特に有効だったのか
• どう導入すれば同じ効果を得られるのか

このトークでは、これらについて実践的な知見を共有します！