トーク

文字と画像を並べたいだけなのに縦位置が合わない！ flexboxにしてみても…合わない！
一通りの画面構成ができるようになったと思いきや、インラインレイアウトにはまた違う世界が広がっています。

インラインレイアウトの基本から、フォントに依存する問題やフラグメンテーションについて解説、さらに広がる関連仕様への橋渡しを示します。

とりあえずflexbox、とりあえずgridではない、「なんでこうなるのか」をわかり、インラインレイアウトを活かせるWebフロントエンドエンジニアになるための時間です。

Viteでシンプルなカウンターアプリを作成し、開発サーバを起動したあと、ブラウザに配信されるJSファイルには様々な工夫が施されています。
例えばソースマップの情報が追加されていたり、HMRのための処理が追加されていたり、jsx（<Hoge/>）がjsxDEV関数の呼び出しに変換されファイル名などが追加されていたりします。
このセッションでは、実際に出力されたJSファイルを見ながら、それらが何のために追加・変換され、私たちの開発体験をどのように向上させているのかを説明します。

出力ファイルをフックに、深さより広さを優先して下記の内容について触れる予定です。
初学者の方が、フロントエンドの高い開発体験の裏側にある技術について、興味を持つきっかけになると嬉しいです。

• ソースマップ
• react-refresh
• jsxの変換
• /@_ PURE _/

pnpmを使ってmonorepoでSaaSを管理していたあなた。
しかしある日突然、react-hook-formが動かなくなったり、Reactで不可解なランタイムエラーが起きるようになりました・・。

package.jsonの指定に関わらず、条件によっては同じパッケージが複数インストールされてしまい、正しく動作しなくなってしまうことがあります。
そのメカニズムと解決方法をお話します。 (デバッグ用コマンド公開予定)

JavaScriptでリストをソートする際、多くの開発者は sort() 関数を何気なく使っているのではないでしょうか？

しかし、「ソート」と一言で言っても、複数のアルゴリズムが存在しており、それぞれ特徴や性能が異なります。
また、JavaScriptの内部実装は、使っている実行環境（エンジン）によって異なり、sort()関数もその例外ではなく内部で使用されているソートアルゴリズムが異なるのです。
つまり、同じコードでも、実行環境（エンジン）によって処理速度に微妙な差が生じる可能性があるということになります。

本トークでは、普段何気なく使用しているsort() 関数の裏側に焦点を当てて、実行環境（エンジン）ごとのソートアルゴリズムの違いや処理速度の微妙な違いなどをお伝えできたらと思います。

JavaScript には ES2015 の時代からジェネレーターとよばれる機能が存在しています。
当時は非同期処理を扱うことができる構文として着目を浴びましたが、今日ではこれは Async/Await がデファクトな構文となりました。

ジェネレーターは仕様に取り込まれてから 10 年という歳月が経過しようとしていますが、未だに世の中に浸透したといえるような使い方は皆無といっても過言ではないほど見かけません。
特徴と挙動は知っていても「で、これで何が嬉しいんだっけ？」となってしまうのが現状です。

このセッションでは以下の（特にわかりづらい）特徴からジェネレーターの真価と魅力について解説していきます。

• ジェネレーターはイテレーターでありイテラブルである
• ジェネレーターからジェネレーターを呼び出すことができる
• yield*は全てのイテラブルを消化することができる

Webアプリや入力フォームでよく目にする「〇〇文字以内」という字数制限。
しかし、全角・半角・絵文字などを含めた時にその文字数カウントは果たして正確でしょうか？
本トークでは文字コードと文字数認識の仕組みと実装時におさえておきたいベストプラクティスを紹介します。

本セッションでは、現在開発している医療系 SaaS を事例に、業務系 SaaS におけるフロントエンド品質保証の「現在地点」をご紹介します。

業務系 SaaS では、機能が適切に利用でき、ユーザーの課題が適切に解決できることがより求められます。とくに医療系 SaaS では人の命にも関わってくるため、厳格な品質保証が必要不可欠です。

React で作成されたメインのWebアプリ、サービス間連携機能およびその管理画面、サブ機能としてのモバイルアプリなど、事業上の注力度合いが異なる複数のシステムを運用しています。開発プロセスでは仕様書との整合性チェック、コード生成、テストケースの整理などさまざまな場面で AI が活用され、従来の手法と AI 支援を組み合わせた品質保証を実践しています。フロントエンドエンジニアとしてどのような品質保証アプローチを実践しているのかをお伝えします。

2011年頃にBaaS(Backend as a service)という言葉が流行り、「バックエンドエンジニアが不要になる未来」のようなことが言われたりしましたが、2025年現在、全然バックエンドエンジニアは不要になっていません。かくいう私も「もしかしてReactを書ければサービス開発全部1人でできるのでは？」と夢見て勉強した1人でして、「フロントエンドうおお！」と意気込んできましたが、そのような夢は見事に砕かれました。ビジネスが大きくなるにつれ、サービス連携やデータ連携やセキュリティなどの都合でクラウドに寄せた設計をせざるを得なくなりました。しかし世の中には夢を追いかけた同志や自分が残したBaaS前提のサービスは稼働し続けています。2025年からすると正解ではなかったと言えることもあるので、クラウドやAIなどのトピックから学んだプラクティスで、現在の正解を作っていきます。

昨今AIエージェントが実用レベルに到達し、フロントエンド領域において新たな変化が起きています。AIをインターフェースとして活用することで、アプリケーション開発の設計可能性が大きく広がったと感じています。

実際に取り組んだ2つのプロジェクトでは、非エンジニアチームがAIエージェントを通じリポジトリを直接更新し、より柔軟な修正を実現。Ruby on RailsからBraze(CRMツール)移行では、従来のドラッグ&ドロップエディターでは対応できないユーザーカスタマイズ部分を、AIで修正できる環境に整えメール修正範囲を拡張。Next.jsページでは、ヘッドレスCMSに代わりリポジトリ管理とVRTによる更新フローで、セクション・コンポーネント単位での柔軟な変更を可能にしました。

AIをインターフェースとして設計する考え方、チーム普及戦略、新しい協働モデルの可能性について実践知見を共有します!

事業拡大に伴い新サービスが次々と立ち上がるフェーズでは、限られたリソースにおける開発を加速させていくことが必要です。この取り組みの一環として、デザインシステムの構築や全社的なUIコンポーネントライブラリを作成する動きが一般的なものになりつつあります。

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

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

2018年から5年間、フロントエンドエンジニアが不在で保守がほとんど行われていなかったプロダクトのフロントエンドの技術的負債脱却のため、2023年にフロントエンドチームが結成され、負債脱却プロジェクトを進行していくことになりました。
この5年間でフロントエンド技術は大きく変化し、モダンな開発体験やチーム開発の効率化に繋がる多くのプラクティスが一般化しました。しかし、メンテナンスが止まっていたこのプロダクトには、古いツールや設計思想がそのまま残されており、技術面でも運用面でも多くの課題が蓄積されていました。
本セッションでは、現在もなお進行中であるこのプロジェクトについて、私たちが直面した失敗や得られた学びを交えながら、「なぜその選択をしたのか」「どんな工夫で乗り越えたのか」といった意思決定のプロセスも含めて、現場の視点からご紹介できればと思います。

複雑なUIを作ろうとすると、どんな技術スタックでも状態管理が大きな課題になります。
Reactでは長年にわたって Redux や Recoil など多くの状態管理ライブラリが登場してきましたが、本当にライブラリが必要なケースはどのくらいあるのでしょうか？

本セッションでは、Reactの組み込みAPIである useReducer を軸に、ライブラリを導入せずに複雑な状態管理を実現する方法を紹介します。
Reduxの全盛期から useState の普及、そして Recoil のような“便利だけど依存の大きい”選択肢の登場まで、Reactにおける状態管理の変遷を俯瞰しながら、「なぜ今あえてuseReducerなのか？」という視点で語ります。

状態管理に悩んだことのあるすべての開発者に向けて、フレームワークを問わず通じる考え方のヒントを共有します。

複数のフロントエンドアプリを運用する中で、コードの重複、責務の曖昧さ、変更時の影響範囲の広さに悩んでいませんか？

本セッションでは、4つのフロントエンドアプリケーションを1つのMonorepoに統合した事例をもとに、統合がきっかけとなって進んだリアーキテクトを紹介します。

パッケージの責務の境界を見直し、共通コンポーネントやデザインシステムを整理する過程で、開発体験を大きく改善しました。
さらに、静的解析やAIコーディングの適用範囲も拡大し、チーム全体の生産性にも変化がありました。

以下の観点からお話しします：

• Monorepoへの統合プロセスとツール選定
• 責務分離を軸にしたアーキテクチャ再設計の手法
• 技術的な変化がもたらしたチームの変化

複数のアプリケーションを抱える開発チームや、既存システムのリアーキテクトに取り組む方々へ、実践的なヒントをお届けします！

ライブラリやSDKをメンテナンス/品質保証する際、ある特定バージョンや配布形式、またそれらの任意の組み合わせによってデバッグや動作確認をしたいケースはしばしばあります。 もしそれがnpmパッケージであれば、個別にビルドするのでは手間がかかり、また幾つものバージョンを事前にバンドルするとアプリケーションサイズが膨大になってしまうことが容易に想像できます。
この課題は、Dynamic ImportとViteのビルド設定をうまく組み合わせることで解決することができます。

このトークでは、Viteの具体的なビルド設定の内容を踏まえ、実際にビルドが実行されてからランタイム上でパッケージが解決されるまでのフローも解説しながら、この課題に取り組むにあたり工夫が必要だった点や実装時の注意点を紹介していきます。

長年にわたり、フロントエンド開発の現場を支えてきたSass。
その登場の背景には、当時のCSSが抱えていた課題を解決したいという強いニーズがありました。

それから時が経ち、CSSそのものも大きく進化を遂げています。
Sassが提供してきたような機能も、モダンなCSSで標準的に利用できるものが増えてきました。

このトークでは、モダンCSSの機能を、Sassでおなじみの機能と比較しながら紹介します。
さらに、CSSの進化を俯瞰的に眺めることで、今後のCSSがどのような方向に向かうのかを考察してみます。

想定する参加者

• モダンなCSSの機能を知りたい方
• Sassを知っている・知りたい方
• CSSの未来に興味がある方

LLM 時代に急増した「死んだexport」をKnip×ESLintでゼロ化する提案です。
ESLintだけでは検出できない、テストやStorybookで利用されている関数にも対応し、
私の担当するプロダクトでも10以上の関数を削除しています。

内容

1. Knip設定 & ESLint連携
2. Storybook・テスト用のexportへの対処
3. GitHub Actionsで再発を防ぐCIフロー
4. Claudeによる削除候補レビュー PoC

対象

プロダクトの信頼性を高めたいフロントエンド開発者

持ち帰れるもの

明日の30分で完了できる設定。それ以降は不要な関数とコンポーネントがゼロに。

—

ライブデモ込みの30分です。
私も以前、不安感を持って開発をした経験があり、そんな思いをする方を減らしたいと考えて提案をしています。

私のチームは現在、長年利用されているレガシーシステムの移管プロジェクトに取り組んでいます。

アプリからインフラ、組織体制まであらゆる面で見直しと再設計が必要となり、当然フロントエンドも大規模なマイグレーションが必要となりました。

しかし蓋を開けば遠い昔に見たMarionette.jsやUrushiなど古のフレームワーク群が数多く登場。
フロントエンドエコシステム黎明期に作られたスクリプト群に対し、現代の静的解析はまともに機能しませんでした。

当然ながらAIエージェントも適切に回答できることが少なかったため、自力で解読して再設計することから始めました。

ステップ数は1ファイルあたり3000〜10000強。
それらをモダンな構成へ移行する試行錯誤のなか、巨大フロントエンドをモダンに仕上げる「ツボ」があることに気がつきました。
それらについて、私たちの挑戦と共にご紹介いたします。

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

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

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

エンジニアアサインを、「1人1案件の専任制」から「全員で全案件担当」の体制にしたら
成長を楽しむタイニーチームに育ちました。

コミュニケーションし、同じことに取り組む。
そのシンプルな積み重ねが
プロンプトを構造化するように、思考をI/Oする力を鍛えます。

• いつでも言語化・情報整理・メタ認知の訓練。
• 暗黙知が暗黙知のままで伝わり、形式知ナレッジも自然に充実。
• 余白のコミュニケーションも侮れない。「人の考え方に触れる」成長。

1年半つづけてみたリアルな手応えを語ります。
ひとりで何でも作れてしまう時代に、チームで戦って成長する楽しさ。ぜひ聞いていただきたいです。

HTML属性のcontenteditableは要素内のテキストを編集可能にします。主にリッチテキストエディターの実装で使われますが、テキストが編集可能になるという点以外は通常の要素と変わらないため、文字装飾だけではないさまざまなUI表現の可能性があります。

その例として、画像を自由な場所にドラッグアンドドロップで配置できるスクラップ帳エディターを実装しました。その実装をもとに、エディターの挙動に影響させずにVueを使う方法などの役立つ話や、ブラウザーごとの挙動の違いや日本語入力時のつらみなどの泥臭い話をします。

contenteditableを使ってちょっとおもしろいUIを作ってみたい方にはもちろん、アプリ開発の泥臭い話が好きな方にも楽しんでいただけるセッションになると思います。