トーク

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ライブラリを利用していてパッケージ管理に悩んでる人

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 に移植可能になるのか、具体例を交えて紐解いていきます。

フロントエンドのテスト、うまくいっていますか？重いE2EテストやVisual Regression Testの偽陽性など、やったことがある人にしかわからない落とし穴があるのがフロントエンドのテストです。このLTでは、私が現場で直面したフロントエンドのトラブルとその解決策をノンストップでお送りします。

例えばこんな話：

• Visual Regression Testの偽陽性をガッツリ減らす方法
  • placeholder画像の読み込みタイミングによるブレを軽減する自作npmパッケージもご紹介
• テストフレームワークを段階的に移行した話
• APIの仕様変更にAPIモックを確実に追従させた話
• テストコードを後回しにして失敗した話と解決策
• などなど…

単なる「あるある」では終わりません。現場で実証済みの解決策を10連発でお届けします。

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 フェーズで動かない端末があった」ということが発生しがちです。
このトークでは、スマートフォンでカメラを扱う際に、ナイーブに実装すると起こり得る(端末によっては動かなくなる)処理・実装の例と、これらを回避するためにどのような実装を行うべきかについて話します。

概要

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

背景

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

想定聴衆

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