トーク

自分がジョインしていた会社は、経験の少ないエンジニアに対して高度な技術力を身につけてもらうことを目的としている事業です。そのため、不要な自走を避け、迷わず学べる環境づくりが重視されています。
フロントエンド育成においてデザインは不可欠ですが、エンジニアの独自のデザインは、学習コストもレビュー側のエンジニアの負荷も高く事業として望んでいることではありません。
そこでプロジェクトの成熟度以上にデザインシステムによる内政化に価値を感じ、デザインシステムを先に構築する意思決定を行いました。
今回は事業判断としてデザインシステムに行き着いた背景と、デザインシステムの構築に至るまでの道のりについて共有します。
プロダクトデザインとは異なる、デザインシステムがもたらす具体的なメリットについても実例を交えてお話しします。

AI によるコード生成が主流になりつつある今、Lint がもたらす決定論的制約は、開発生産性を一段押し上げる強力な手法です。

これまで CSS Linter は Stylelint 一択という状況が続いていましたが、2025年は選択肢が3つに増えました。

昨年、Biome は1周年の節目に Stylelint の推奨ルールの一部を実装し、CSS Lint を stable として公開しました。
今年の2月には ESLint も公式にサポートし、無効なプロパティや At-rules の検出、Baseline のチェックなどコンパクトながら要点を押さえたルールを提供しています。

本セッションでは、各ライブラリの設計思想、プロダクトに沿ったカスタマイズのしやすさ、TailwindCSS / CSS Modules への対応状況などを整理し、最適な選定方法について解説します。

React Server Functions は、ブラウザからバックエンドへのHTTPリクエストを、「関数呼び出し」の形で隠蔽するインタフェースを持っています。一見"魔法"のような仕組みに見えますが、その裏は地道なコード解析・コード変換によって実現されています。

このトークでは、Server Functions に対応するフレームワークの実際のコードを追いかけながら、どのように解析・変換が行われているのかを説明します。実際に Server Functions をサポートしている、waku または parcel（React Router）を題材としたいと考えています。

コード変換の処理を理解し Server Functions の理解を深めることで、「よくわからないけど便利」から「実際の処理を理解して使える」状態になってもらうことが目標です。

Reactで頻繁に登場するuseStateやuseEffectなどのHooks。これらのHooksが、Reactの内部のどこで処理され、どのように保持されているかご存知でしょうか？

「Hooksはトップレベルでのみ呼び出す」「useEffectはレンダリング後に実行される」──これらの基本的なルールは広く理解されています。しかし、これらのルールを支える内部の仕組みについて、全体像をイメージできる開発者は多くないのではないでしょうか。

本セッションでは、Reactのコードを読む会に1年以上参加した経験から、Hooksの動作を理解するための全体像を共有します。React内部でHooksがどのように処理されているのか、その基本的な流れを把握することを目指します。

扱う内容:
・Reactの4つのフェーズ
・Fiber Tree
・useState, useEffectの内部動作

フロントエンド開発におけるコンポーネントの共通化や分割は、保守性や拡張性の観点で重要です。しかし、過度な共通化や粒度の細かすぎる分割は、可読性や変更容易性を損ない、開発効率を下げてしまいます。

本トークでは、機能的凝集という観点から、コンポーネント設計について実践的に紹介します。特に、UI設計（Figma）やAPIスキーマを起点に、論理的凝集された構造を機能的凝集へと見直していくプロセスにフォーカスして解説します。

登壇者のチームでは、複数ロール・多機能を持つシステムにおいて、コンポーネント群をどのように意味のある単位へ構造化するかについて議論・検証しました。その結果、可読性や変更容易性を担保するコードを維持し、チームベロシティを高く安定させました。

コンポーネントの設計判断をワークショップのように体験いただき、プロジェクトごとの制約に応じた設計意思決定の一助となれば幸いです。

Webフロントエンド開発では、そのほとんどがnpmモジュールを中心としたエコシステム上で今でも変わらず開発されています。
npmエコシステムにおいて重要なのが、依存解決（ディペンデンシィレゾリューション）と呼ばれるどのnpmモジュールを使うか、npmモジュール間の依存をどう整理して解決しているのかを決める処理です。

今回のトークでは、Webフロントエンド開発の型システムを支える重要なライブラリであるTypeScriptがnpmモジュールの型解決をどう行い整合性をとっているのか、VSCodeの型補完Intellisenseはどう機能しているのか、d.tsとは何か？ TypeScriptの気持ちになって依存解決（ディペンデンシィレゾリューション）を深ぼっていきます。

Webフロントエンド開発では、そのほとんどがnpmモジュールを中心としたエコシステム上で今でも変わらず開発されています。
npmエコシステムにおいて重要なのが、依存解決（ディペンデンシィレゾリューション）と呼ばれるどのnpmモジュールを使うか、npmモジュール間の依存をどう整理して解決しているのかを決める処理です。

今回のトークでは、Webフロントエンド開発でもう１つ重要なnpmモジュールを１つのアプリケーションにまとめ配布可能な形にするバンドラーがどう依存解決をして、そのアプリケーションをバンドルしているか、バンドラーの気持ちになって依存解決（ディペンデンシィレゾリューション）を深ぼっていきます。

ウェブフロントエンド開発において切っても切り離せない存在であるウェブアクセシビリティ。

対応したことのある方であればアクセシビリティ対応の大変さをご存じでしょう。
従来の方法では静的に解析できない項目も多く、人間の手によるチェックが不可欠です。

そこで本セッションでは AI エージェントを活用したアクセシビリティ試験と試験結果の出力の自動化に取り組んだ事例についてデモを交えてお話しします。

• Playwright MCP Server x A11y MCP Server の組み合わせによるアクセシビリティ試験自動化
• Notion MSP Server によるアクセシビリティ試験結果のレポート管理

これからアクセシビリティ対応に向き合う方・継続可能なアクセシビリティ試験の仕組み化に取り組みたい方の一助になれば幸いです。

私が参画していた会社では経験の浅いエンジニアを育成する教育を主とする事業を行っています。
教材兼サービスとしてWebアプリを開発しており、Next.js Pages Routerを基盤にApp Router、独自BFF、SSRとCSRが混在し、設計指針の分散とドキュメント・レビュー負荷の膨張により、成長機会を阻害していました。
要件を洗い直しSSRやRSCが必須でないこと、学習コストと実装一貫性を最優先するべきと判断し、評価軸を学習量・運用負荷・内製化容易性・将来拡張性に定め、決断としてReact + Viteを選定しました。
本セッションでは事業判断として技術の刷新に至った経緯と、それによる効果を取り上げ意思決定を起点に技術選定の振り返りと今後の展望についてお話しします。
元々使っていた重いフレームワークを軽量なフレームワークへと移行するに至った経緯を元に、今後の方針について模索します。

生成AIが当たり前になった2025年。
クライアントワークを主軸とする我々受託フロントエンドエンジニアには、ただ技術ができるだけでは通用しない時代がやってきました。
求められるのは「速さ」と「柔軟さ」の両立。それをどう実現するか──。

私のトークでは、実務経験をもとにした次のような実践知を、再利用可能なナレッジとして提供します。
・受託における「技術の陳腐化」と「コスト圧」の最新トレンド
・長寿命サイト・サービスを支える柔軟なデザインシステムの構築と運用
・AIを活用した技術戦略立案とテクニカルディレクションの型

「コードを書く」から一歩進み、プランニングをしリードするポジションへ。
フロントエンドエンジニアが、デザインやビジネス領域に越境しながら価値を最大化する考え方と実践のステップを、失敗談や学びも交えて、明日から使える「受託フロントエンドの生存戦略」としてお届けさせてください。

大規模ReactアプリケーションでビジネスロジックとUIが密結合し、テストが困難で変更コストが高くなっていませんか？
コンポーネントにビジネスルールが散在し、同じロジックが複数箇所に重複する問題は多くのチームが直面しています

このトークでは、Monorepo環境でReactアプリケーションにClean Architectureを導入し、ドメイン層を分離する手法を解説します
Value ObjectパターンでEmailAddressやUserStatusなど不正値を型レベルで排除し、UseCaseレイヤーでビジネスロジックをUIから独立させます

実装例でReact Context、カスタムフック、依存性注入を活用したパターンを解説
TypeScriptの型システムと組み合わせた「不正状態を型レベルで防ぐ」設計手法を具体的なコードで紹介し、保守性の高い設計スキルについて考察します

フロントエンド・バックエンド間の型不整合によるランタイムエラーに悩んでいませんか？
API仕様書とコードの乖離、手動での型定義メンテナンスは開発効率を大きく下げています

このトークでは、Zod-Firstアプローチによる型安全な開発ワークフローを考えます
一つのZodスキーマから @anatine/zod-openapi でOpenAPI仕様書を自動生成し、TypeScript型定義、APIクライアント、バリデーション関数まで完全に連携させる手法を解説します

実装例を通じてZod活用パターンを紹介し、条件分岐を含むAPIスキーマ設計、フロントエンドでのリアルタイムバリデーション、エラーハンドリングの実装パターンを具体的に解説
Zodスキーマの設計方針から自動生成されるコードの活用方法まで、聴講者が型安全な開発環境を構築できる手法について解説します

フロントエンド開発で設定やビルドエラーに時間を取られ、肝心のコーディングに集中できない経験はありませんか？
認知心理学の研究では、開発者の生産性は中断回数と認知負荷に大きく左右されることが分かっています

このトークでは開発手法「VibeCoding」とViteの高速HMRによる即座フィードバック、DaisyUIセマンティック設計による直感的UI構築、TypeScript+ESLint統合による認知負荷軽減を組み合わせた開発フローを実演します。

実装例としてログイン画面構築を通じて、中断のない開発サイクル「思考→実装→確認→改善」の最適化手法と、TypeScriptの型システムで不正状態を型レベルで防ぐ設計パターンを紹介し
フロー状態を維持しながら型安全な開発を進める具体的なテクニックにより、聴講者は集中力を維持しながら効率的に開発できるスキルを確実に身につけられます

多くの生成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の導入を検討している方への参考情報として、また既に導入済みの方には運用改善のヒントとして役立つことを目的としています。

新卒フロントエンド開発者の私が、最新の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で高速かつ精密な実装を目指す方必見です！

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

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

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

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

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

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