トーク

最近注目され、便利な UI を簡単に実装できる Popover API ですが、その手軽さの裏にはアクセシビリティの落とし穴が潜んでいるかもしれません。特に、新しい WCAG 2.2 の達成基準を考慮すると、これまで見過ごされてきた問題がクリティカルになる可能性があります。
このセッションでは、 Popover API を利用する際に特に注意すべき WCAG 2.2 の達成基準をピックアップし、具体的なコード例を交えながら、よくある実装のつまずきどころと、それを乗り越えるための実装のヒントを共有します。

多くの生成AIサービスは、クラウド上で動作する大規模言語モデル（LLM）を利用しています。そのため、金融など機密性が特に重視される分野では、生成AIの導入に大きな障壁があります。

本セッションでは、限られたリソースでも動作するローカルLLMの現在地を知り、ローカルLLMを利用してどのような体験を作ることができるのか、フロントエンドエンジニア目線で探ります。

具体的には以下のトピックについてお話しします

• ローカルLLMの紹介と、実用性のあるユースケース、具体的な利用方法
• スマホでも利用できるSLM（Small Language Model）の紹介と、その現実

ローカルLLMでどのようなサービスを作ることができるか、考えるきっかけになれば良いなと思っています。

（注: 本セッションはLLMのモデル構造の解説、定量的なモデルの比較は含みません。）

CSSにおけるレイアウトは、ボックスをどのように並べるかという営みです。
FlexboxやGridは、枠組みを決めてから余白を分け合う、外側からのアプローチです。
一方、実際のWebコンテンツのレイアウトをしていると、コンテンツに基づく寸法、Intrinsic Sizeの姿が浮かび上がります。

Intrinsic Sizeの周りの寸法は min-content max-content fit-content() といった表現で参照できるようにもなっており、
Interop 2024の結果、FlexboxやGridの主要ユースケースを満たすようになりました。

周辺で生じる問題の個別対策テクニックから一歩進んだ理解をつかみ、
外側ばかりでなく内側からも、勘ではなく論理で捉えるレイアウト力を身につけましょう。

対象：中級〜リーダー級

Feature Flagとは、機能のオン/オフを切り替えるスイッチのような仕組みであり、活用すれば本番環境において問題が発生した場合でも、迅速に問題のあった機能を無効化することで安全なリリースが実現できます。Yahoo! 知恵袋のフロントエンドチームでは、昨年からFeature Flagを導入しており、本発表ではその背景、導入方法、運用の実例をご紹介します。また、本番環境上で自分だけ問題を再現する方法や、Feature Flagを管理するサーバーに障害が発生した場合の対処法など、実際の運用を通じて得られた知見についてもあわせて紹介します。Feature Flagの導入を検討している方への参考情報として、また既に導入済みの方には運用改善のヒントとして役立つことを目的としています。

現代のウェブアプリケーション開発において、セキュリティは単なる追加機能ではなく、開発の初期段階から組み込むべき必須要件といえます。Agentic CodingやVibe Codingと呼ばれるような生成AIを活用したコーディングの現場においても、静的解析ツールでのリンティングがより重要視されるだろうと考えます。
このトークでは、特にWebフロントエンドにおけるセキュアコーディングをサポートするESLintプラグインに焦点を当てます。それらのルールセットがセキュリティリスクをどのように検出するかを紐解き、フロントエンド開発の文脈でどのように応用可能かを示します。

新卒フロントエンド開発者の私が、最新のCSS機能（if/else文、:has()、@supports、CSS変数、コンテナクエリ）を駆使し、「JSを書かずにどこまでインタラクティブUIを作れるか」を徹底検証。
モーダル、アコーディオン、タブなどのJS不要コンポーネント実装とアクセシビリティ配慮、CSSだけによる動的スタイル切り替え技術を紹介。他にもCSSの限界やパフォーマンス・互換性最適化ポイントを解説。
さらにJS実装とのレンダリング時間・初回ロードサイズ比較を行い、「ここはCSSで実現可能か」「JSを併用すべきか」の判断軸を提供。新卒ならではの試行錯誤を通じて、最新CSSを学びやすいロードマップを示します。CSSによるプロトタイピングや「JS以外の選択肢」に興味がある方に最適なセッションです。

新卒フロントエンドエンジニアの私が学生時代に、Web構築の現場で叩き込まれたTailwind CSSのユーティリティファースト思想を活用し、デザインカンプ通りのピクセルパーフェクトUIを効率的に組み上げるワークフローを20分でがっつり解説します。
・デザイン理解→クラス設計：Figmaで作成されたデザインカンプの寸法をvw/vh基準に落とし込む方法
・レイアウト制御：グリッド・フレックス×コンテナクエリでレスポンシブ調整
・メンテナンス性向上：カスタムプラグインで独自ユーティリティ生成
・パフォーマンス最適化：PurgeCSS＋JITモードで無駄なスタイルを削除
デザインからTailwindクラスへの落とし込み、ブラウザ検証、ビルド後サイズ比較までを実践。モダンCSS運用の「最短ルート」と「現場で役立つテクニック」をお届けします。 Tailwindで高速かつ精密な実装を目指す方必見です！

新卒フロントエンド開発者の私が、最近ブラウザに導入されたif()/else、:has()、@supports、コンテナクエリといった最新のCSS機能を紹介しつつ、「JavascriptなしでどこまでインタラクティブUIを作れるか」を5分で解説するセッションです。
モーダルやアコーディオン実装などCSSだけで実現可能なUIパターンを見せながらJavascriptを使わない選択肢があるということをお伝えします。またパフォーマンス＆互換性の最適化ポイント、CSSとJavascript実装それぞれのサイズ＆速度比較もコンパクトにお届けします。
最新CSS機能がどういう風に使われてるのかを知りたい方や、CSSプロトタイピングやJavascript以外の選択肢に興味がある方に最適です。

新卒としてフロントエンド開発に飛び込んだ私が、スピードと1px単位で再現する丁寧さを掛け合わせたTailwind CSSのユーティリティファースト思想を武器に、Figmaで作成されたデザインカンプ通りのピクセルパーフェクトUIを実現するワークフローをご紹介します。
複雑なカスタムCSSを極力排除し、すべてのレイアウト・余白・カラーをユーティリティクラスで厳密に制御することで、保守・管理しやすいコードを実現。vw/vhベースのレスポンシブサイズ指定や、ブレイクポイントごとの細かな微調整、各ブラウザ間のレンダリング差異検証と補正対応など、プロダクション品質のUIを効率よく丁寧に構築するためのベストプラクティスを学ぶことができます。
新卒だからこそ試行錯誤して実現した、モダンCSS運用の最短ルートをお伝えします!

昨今のWebフロントエンドは非常に高機能化し、一つの画面で多数のリッチな機能が提供されることが多くあります。
各機能が適切に動いているかを担保するため、ついE2Eテストに甘えたくなることもあるでしょう。

しかし、E2EテストはAPIなどの外部システムに依存するため、低速で不安定になりやすいことから、運用は修羅の道です。
一方、単体テストで担保する場合、状態や副作用を多く抱えるモジュールの単体テストのためには複雑なセットアップが必要で、本質的でなく良くわからないテストが増えて惰性で運用しがちです。

そのような課題に対して、APIをモックした状態でPlaywrightを活用する、E2Eテストと単体テストの良いとこ取りを実現した「フロントエンド統合テスト」を導入しました。OpenAPIに基づいて型安全にAPIをモックしたり、AIによって自動生成するといった工夫についても紹介します。

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

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

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

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

みなさん、タプルを map() にかけると戻り値が普通の配列型になることをご存じでしょうか？

Promise.allSettled() で複数の API を並列実行し、成功なら value、失敗なら null に変換しようとした際にこの落とし穴にハマりました。 TypeScript の実装で map() の戻り値は常に U[] になるように型定義されているため、タプル長と要素型が失われてしまうのです。

そこでタプルを map() にかけても返り値をタプルにするために、mapped type と Awaited を組み合わせ、引数に渡したタプル型から戻り値の型を動的に生成し、map() 後でもタプル型を維持する関数をつくりました。

今回はその工夫の詳しい内容を共有します！Typescript で開発されている方にはお役に立てると思います！！

セキュリティ対策というとインフラやサーバーサイドの領域で重視するイメージが強いかもしれません。
しかしながら昨今、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内のブラウザという特殊な環境における事情と制約、配信画面という壊れてはならないものを壊さないために行ってきたこと、安全に壊す技術についても合わせてお話しします

近頃、V8やJavaScriptCore、SpiderMonkeyのようなメジャーなJSエンジン以外にも新しいJSエンジンのプロジェクトがいくつか進んでいます。

また、自作のJSエンジンを含めた自作ブラウザを作るような書籍も出版されており、JSエンジンへの興味を持ちやすく、理解への敷居も多少は下がりつつあると思います。

そして、JSエンジンを（拙いなりに）自作できるということは自分の「推しプロポーザル」も実装出来るということです！

このトークでは、最小の実装で自分の「推しプロポーザル」であるIntl.MessageFormatの初歩的な機能が動くまでのポイントを紹介し、JSエンジンやJSの仕様・プロポーザルへ興味を持ってもらえるきっかけとすることを目指します。

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

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

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

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