プロポーザル

振る舞い駆動開発（BDD：Behaviour-Driven Development）は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、認識のズレを防ぎやすくなります。

本セッションでは、TypeScriptでBDDを始めるための基本的な考え方と実践方法を紹介します。Cucumber.jsなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。

TypeScriptでテストを書いて、これからBDDを始めたい方に向けてわかりやすく解説します。

React Server Functions をインラインで定義した場合、コンポーネントのレンダリング時の値にアクセスすることができます。

しかし、Server Functionsは実際はただのAPIエンドポイントであり、ステートレスな存在のはずです。

ステートレスなのに、なぜレンダリング時の値にアクセスできるのか、実際のフレームワークの実装を参照しながら説明します。

const Component = () => {
const now = new Date().getTime()
const fn = () => {
"use server"
console.log(now) // ここでnowにアクセスできるのはなぜか？
}
...
}

「フロントエンドのセキュリティ」と聞くと、XSSやClickjackingを思い浮かべるかもしれません。

しかし本来はもっと色々なことを気にしてもよいはずです。
「他のタブで開かれたサイトが攻撃してこないだろうか」
「リンク先のサイトが牙を向いたら」

あるいはユーザーとして、こんな心配をしたことがあるかもしれません。
「変なサイトを開いてポップアップが止められなくなったら」
「端末が特定されて追跡されたら」

そして、ブラウザは実際にこれらの脅威に立ち向かってきました。

このセッションでは、ブラウザが「フロントエンド」領域で繰り広げるセキュリティの攻防を、UI SpoofingからXS-Leaks、Fingerprintingなどなど、原理や歴史とともに追いかけます。

ブラウザは何をどこまで守っているのでしょうか。
私たちは何をどこまで自力で守らなければならないのでしょうか。

多くのプロジェクトで、index.tsを用いてexportやimportを管理していると思います。

デフォルトで多くのプロジェクトに入っているため、議論の対象になりづらいですが、index.tsは複数のモジュール・コンポーネントを一括でエクスポートするために使われる以上に、モダンなフロントエンドのディレクトリ構成による設計の表現を成立させるために重要な役割を担っています。

特に、循環参照を発生させないように参照を容易に管理したり、ディレクトリの外から呼び出されるコンポーネントと、ディレクトリ内部でのみ使用されるコンポーネントを適切に分離しカプセル化を行うために有用です。

本トークを通して、index.tsを切り口としてディレクトリの設計思想へ触れる糸口になれば幸いです。

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

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

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

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

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

JavaScriptの「Proxy」objectは非常に強力です。
objectに存在しないプロパティの値を取得したり、存在しないメソッドを呼び出したりなど、objectに対するあらゆる処理に介入し、通常のobjectでは不可能な柔軟な処理を実現できます。

本発表では、発表者が業務でiframeとmain window間のRPC機構を構築した経験をもとに、以下の内容について解説します。

• JavaScriptのProxyの基本
• Window間通信の基本
• 別Window上のメソッド呼び出しのProxyによる実装
  • Window間通信のProxyによるWrap方法
  • 別Window上のメソッドの型情報の利用
• Window間のRPC実装として有名なComlinkの実装の簡単な解説
• Window間通信以外の応用例

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

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

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

折り紙の折り方、分かりづらくないですか？
私たちのプロダクト「OriCube」は、この課題を解決します。

OriCubeは、折り紙の折り方を3Dモデルを用いて視覚的に表現したwebアプリケーションです。
折り紙の折り方を確認するだけでなく、ユーザーがweb上で折り紙の折る手順を投稿することができます。

本LTでは、「折り紙を折る」という体験をweb上で再現することで得られた、ReactとThree.jsを組み合わせたインタラクティブな3D表現のノウハウをお伝えします。
特に、3Dモデルの動的制御の実現、複雑な3Dシーンにおけるパフォーマンス最適化に関して話します。

OriCubeは、JPHACKS2024で最優秀賞, 聴衆投票1位を獲得しました。

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

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

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

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

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

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

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

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

みなさんlint,formatはpre-commitに入れていますか？
commitに時間がかかるのは生産性がとついついCIのみになっていてlint,formatのコミットが生えるなん、レビュー待ちだと思ったら落ちていたなんて悩みはありませんか？
私はエンジニアとして2社3プロジェクトでPrettier＋ESLintからRust製高速ツールBiomeへ移行し、この悩みを解消しました。
PrettierをBiomeのformatterに、ESLintルールのうちBiome対応分だけを置き換えるハイブリッド構成を用いてこの悩みを解消した経緯や結果についてお話しします
カスタムルールなど移行困難な部分はESLintを残しましたが、formatは従来比10倍超、lint全体も約5倍高速化し、CIとpre-commitの待ち時間を大幅に短縮。発表では移行手順、運用上の注意点を事例を元に共有します。

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の型システムで不正状態を型レベルで防ぐ設計パターンを紹介し
フロー状態を維持しながら型安全な開発を進める具体的なテクニックにより、聴講者は集中力を維持しながら効率的に開発できるスキルを確実に身につけられます