トーク

フロントエンドエンジニアがこれまで向き合ってきた相手は、人間でした。しかしAIの登場によって、この前提が変わりつつあります。

AIはWebの出力者になりました。ストリーミングで流れるチャットUIが注目を集め、インタラクティブなUIを返せるMCP Appsも登場しています。
同時にAIはWebの消費者にもなりました。AIが効率的に情報を取得できるよう、HTMLの代わりにマークダウンでコンテンツを配信する動きや、AIがWebアプリをツールとして利用するWebMCPの策定も進んでいます。さらにAIが生成したことを示すai-disclosure属性の提案・仕様の議論が進んでいます。

このようにWebフロントエンドは「AIとの接点」として日々進化しています。本セッションではこれらの変化を整理し、AI時代においてもWebが情報をやり取りする手段として重要な役割を果たしていることをお伝えします。

私たちが毎日書くJavaScript
その動作が仕様通りかどうかを検証するテストスイートが存在することをご存知ですか？ ECMAScript公式テストスイート「Test262」は、V8、SpiderMonkey、JavaScriptCoreといった主要エンジンが参照する「共通の物差し」です。
この物差しがあるからこそ、「どのブラウザでも同じ結果になる」当たり前が実現されています。

本トークでは、Test262の役割と必要性をわかりやすく解説します。また、私がV8のコードリーディング中に偶然見つけた「FIXME」コメントが、実はTest262の仕様準拠に関わるものであり、長年放置されていた修正のきっかけとなったエピソードも紹介します。 普段意識することのないJavaScriptの「信頼性の源泉」を覗いてみませんか？

10年以上の運用で15,000行に膨れ上がった「CSS地獄」。
"!important" が飛び交うレガシー環境で、既存システムの開発を止めることなく「Vite + React + Tailwind」の開発体験を手に入れる
そのような都合の良い方法は存在するのでしょうか？

本セッションでは、フルリプレースや完全SPA化ではなく「画面のコンテンツ領域にReactを後付けする」という移行事例を紹介します。
最大の壁となるレガシーCSSの干渉を防ぐために、「iframe」ではなく「Shadow DOM」を採用しました。
Reactを「Shadow DOM」でラップする実装パターンを中心に、この手法に至った経緯や、実運用で遭遇した落とし穴とその対策についても共有します。

「レガシー環境を捨てられないが、開発体験は諦めたくない」 というエンジニアの方へ、新旧UI共存の現実解をお届けします。

業務中、クライアントから奇妙なバグ報告が届きました。「カタカナ入力で文字が二重になる」

調査すると、「ああ」→F8押下で「ああｱｱ」や「あｱ」になる現象が。F7/F9/F10は正常なのに、なぜF8だけ？原因を突き止めた後、「もしや他でも...？」とこのトークのプロポーザルフォームを試すと、案の定同じ問題が...。カンファレンスのフォームですら見落とされているこの問題は、多くのWebフォームで潜在しています。

本トークでは、F8が引き起こす日本語IME特有の挙動、compositionイベントの仕組み、ブラウザ・OS・IME実装による違い、そして堅牢なフォーム設計の実装方法を解説します。

あなたのプロジェクトのフォームは大丈夫ですか？

React/Vue/Svelteは、同じセキュリティリスクに対して同じアプローチで対処しているのでしょうか？ この疑問から、3つのフレームワークのソースコードと公式ドキュメントを読み比べてみました。調査の結果、自動エスケープのように共通の実装がある一方、javascript: URL のブロックのように React19で導入された対策が Vue/Svelte にはないなど、明確な違いがあることがわかりました。その背景には、各フレームワークが持つ設計思想の違いがあります。本セッションでは、XSS対策を中心に、ソースコードの比較結果と設計思想の違いを、公式ドキュメント・GitHub PR・過去の CVE を根拠に共有します。
こちらの記事でまとめたような内容を発表する予定です！ https://zenn.dev/akito_tsukahara/articles/1d15cb875b0f82

私たちフロントエンドエンジニアは日々ブラウザ上で動くアプリケーションやページを開発しています。
一方でみなさんはブラウザがどのように開発され、リリースが行われているかご存知でしょうか。

現代の主要なブラウザブラウザエンジンはすべてOSSとして開発されており、誰でもバグの修正や新機能の実装ができます。

このセッションでは、JavaScriptしか言語が書けなかった私がWeb標準とRustを学び、そしてFirefoxへのコントリビューションに挑戦した過程で得られた学びを共有しつつ、ブラウザの開発はどこか知らない場所の話ではなくフロントエンドエンジニアも参加できるということをお伝えしたいと思っています。

皆さんはVue.jsを作ったことがありますか？
もしかしたら無い人もいるかもしれませんね。

「いやどんな質問だよ！」 そんな突っ込みを横目に、この30分でVue 3のコアシステムをゼロから実装します。

• Proxyによる透過的な依存関係の追跡とReactivityの構築
• VNodeを介した宣言的UIの抽象化とDOMへのマウント
• 仮想DOMのオーバーヘッドを排する「Vapor Mode」という進化の必然性
  30分後、皆さんの手元には「小さいVue.js=chibivue」があるはずです。
  普段Vueを使わない人にこそ見てほしい、モダンフレームワークの裏側に流れる「思想」をライブコーディングで解剖します。

2025年に報告されたCVE-2025-55182は、RSCのデコード処理の欠陥を突き、未認証でRCEを許すという、現代のフロントエンド開発における「安全神話」を揺るがす重大な事案でした。
本セッションでは、この脆弱性のメカニズムを深掘りします。。

1. 攻撃の再現と解析：信頼できないペイロードがどのようにデシリアライズされ、コード実行に至るのかを図解
2. 攻撃面の棚卸し：意図しない「サーバー関数実行境界」の露出を特定する手法
3. 多層防御の実装：実装レベルでの多層防御（バリデーション/到達制御）
4. 検知とインシデント対応：不審な挙動のログ検知
5. 継続的なセキュリティ運用：フロントエンドチーム主導で「緊急アップデート」を完遂するための、SLAとロールバック戦略

「便利さ」の裏に潜むリスクを正しく理解し、堅牢なフロントエンド基盤を構築するための知識を凝縮してお伝えします。

新卒入社して半年——フロントエンドの正社員エンジニアが、自分一人になりました。フロントエンドには課題が山積み。でも事業のための開発もあるし、自分にはまだ力が足りない。いつか経験豊富なエンジニアが来て、一緒に刷新を進めてくれるだろう——そう思っていました。
でも気がつけば、事業の開発で信頼を積み重ね、デザイナーと一緒にデザインシステムを育て、PdMやバックエンドと連携しながら小さな検証から新しいアーキテクチャを導入してきました。
自分には解決できないと思っていた課題を分解し、理想のシステムを描いて議論し、事業の開発プロジェクトにうまく重ねて提案する。周りを巻き込みながら一つずつ改善を積み上げてきた5年間の、泥臭い努力と試行錯誤から得た実践知を共有します。

どんな人向けか？

• システムの大規模改善したいけど、燻っている人
• 少人数のフロントエンドで、事業用の開発で精一杯何とか回している人

ある日、次のミッションが舞い込んできました。

「1,500ページ以上あるヘルプサイトのフロントエンド基盤をひとりで全部刷新できない？」

数年前なら「ひ、ひとりで？面白い冗談ですね、ははは...」となりますが、
結果としては、AIをフル活用することで数カ月の作業期間で全ページの刷新およびリリースが完了し、
Hugo をベースに書かれていたものが、Astro を中心としたモダンなフロントエンドスタックに置き換えられました。

コードの理解・別アーキテクチャへの書き換え・大量ファイルのマイグレーション・ナレッジ蓄積など、
「AIを使って結局何を達成したのか？」という具体的な事例をご紹介します。

加えて発展的な話題として、自分が所属するフロントエンドの横断的な支援チームでの活動も踏まえ、
刷新で得られた知見から、組織でのAI活用に向けた取り組み、今後の展望についてもご紹介します。

Web標準化団体であるW3Cが行っている国際的な標準化会議であるTPACが2025年11月に日本で行われたので参加してきました。
そこで、まだ新卒1年目だった私はWeb APIの標準化の議論を見て、「Webは自分達も作っていく側」なのだと意識が変わりました。

上記をきっかけに自分が出来ることはなんだろうと考えた結果、まずは知るところだと思い、MDNにあるWeb APIについて全部読んでみました。

皆さんはどのようなWeb APIがあるかご存知ですか？
例えば、DOMに挿入される際に不要な要素や属性などをフィルタリングする「HTML Sanitizer API」などがあります。

単純に面白いWeb APIや技術的にすごいけれど使われていないWeb APIがあることをそこで知ることが出来ました。
皆さんにTPACの現場の様子やWeb APIの面白さを可能な限り伝えたいと思います。

React 19はServer Components・Actions・Suspenseの刷新により、データフェッチからレンダリングまでの体験を一変させました。しかし同時期、Rust製のoxfmtをはじめとする「高速・単機能」ツール群が既存エコシステムを塗り替えつつあります。見落とされがちな問題があります。ライブラリ本体の進化とツールチェーンの進化は同じ速度では進まないということです。新しいレンダリングモデルに最適化されたlintルールはまだない、CIの前提が変わっているのにパイプラインは旧来のまま──こうした「ズレ」がチームの開発体験を静かに蝕みます。本セッションでは、この1年のReact周辺とフロントエンドツールの動向を俯瞰し、両者のギャップをチーム開発・モノレポ構成・CI設計でどう埋めるかを具体事例とともに考えます。「最新を追う」だけでは得られない地に足のついた設計指針をお届けします。

「重い計算処理の速度もメモリ効率もWasmが良い」という直感から、zip圧縮モジュールをWasm（Rust）で自作をしました。しかし、実際に使ってみると、既存のJSライブラリ（JSZip）のほうが使い勝手が良いという結論に達しました。
なぜJSライブラリのほうが良かったのか？というところをWasmの制限を絡めて紹介をします。
最後に、それでも私がWasmを使いたい理由についても語ります。

リファクタリングによるデグレーションは、機能は正しく動いているのに体験が劣化するという、テストでは捕捉しにくい領域で起こります。
ユーザーからの問い合わせが届く前に検知したい。しかし、すべての指標を監視するのは現実的ではありません。
本LTでは、「ユーザーの体験に悪影響を与えるか？」を基準に監視対象を絞り込む設計指針と、その基準をもとに筆者が実際にどのように指標を選定し運用したのかを紹介します。
特定の技術スタックに依存しない設計思想の話なので、どなたにも持ち帰れる内容です。リファクタリングに限らず、日々の開発で「何を監視すべきか」を判断するためのヒントになればと思います。

モバイルアプリユーザーの約25〜35%が、OS設定で文字サイズを標準以外に変更していると言われています。
この設定で文字サイズを変更している場合に、アプリ内のWebViewだけ文字サイズが変わらないことがあります。

実は、iOSならCSSの font: -apple-system-body;、Androidならネイティブ側の textZoom 設定を橋渡しすることで、Web側にもOSの文字サイズ設定を反映できます。

このとき重要なのが、文字サイズの変化を前提としたレイアウトです。 rem によるスケーリングはもちろん、文字量に応じて高さが伸びる設計や、要素が溢れた際の柔軟な折り返しなど、拡大を許容する実装が必要になります。 OSの設定をどう受け止め、UIを最適化するか。 境界を越えた実装Tipsを共有します。

ライブラリを使わず <input type="file"> を用いて実装されたファイルアップロード機能を扱った際、 macOS から送信されたファイル名だけがサーバー側の検索と一致せず、データ取得に失敗する問題に遭遇しました。

見た目は同じ文字列でも、 OS や入力経路（フォルダ選択・テキスト入力）の違いによって内部表現（NFC / NFD）が異なる場合があります。今回の問題は、その差異がブラウザを経由してアプリケーション層まで持ち込まれていたことが原因でした。

本トークでは実際の再現手順を示しながら、この不整合がどのように発生するのかを整理します。その上で、ブラウザ標準APIでファイルアップロードを実装する際に、どの境界で正規化や比較責務を持つべきかという設計判断を取り上げます。

環境差異に依存しない、堅牢なアップロード実装のプラクティスを持ち帰っていただくことを目指します。

約10年間frontend開発をメインターゲットにしたVisualTestingツールreg-viz/reg-cliのメンテナンスを行っています。
reg-viz/reg-cliは画像を比較し差分をとることで予期しない変更を検出することを目的としたツールです。
やはり長い間メンテナンスすると様々な悩みが発生するものです。
それらの悩みを解消することを目指し、Rust/WebAssembyに書き換えを行うことを決断しました。
今回は、その意思決定を行った理由、書き換え戦略やアーキテクチャ、得られたもの、思ってたんと違ったもの、お話できればと考えています。

https://github.com/reg-viz/reg-cli

Reactコンポーネントのテストで広く使われるJSDOMは、ブラウザ環境の代用品であり、レイアウト・イベント・非同期処理などで実ブラウザと差異があります。「テストは通るのに本番で動かない」問題が起こり得ます。
Vitest Browser Modeは実ブラウザ上でテストを実行するアプローチです。本トークでは、Testing Libraryからの移行を通じて見えた技術的な違いを深掘りします。

非同期アサーション: expect.element()とリトライ設計の関係
userEventのAPI設計: setup()が不要になった背景
イベント処理の違い: JSDOMで見逃される実ブラウザ特有の挙動
レンダリングと副作用: DOM APIやイベントループにより異なるuseEffectの振る舞い

JSDOMの限界、実ブラウザテストのトレードオフ、選択基準を実例とともにお話しします。

リセットCSSは、ブラウザが標準で持っている要素ごとのデフォルトスタイルを揃えるためのプラクティスとして広く知られています。
一方で、一度組み込むと見直す機会が少なく、古い指定がそのまま残ることもあります。

歴史あるアプリケーションのアクセシビリティ向上に向き合う中で、デザインシステムの適用でも漏れがちな古い画面の改善策を考えた結果、リセットCSSの「たった1行」を削除するだけで改善につながった、という出来事がありました。
このトークでは、なぜその指定が入っていたのかを整理しつつ、現在のブラウザ事情では何が問題になりやすいのか、そしてリセットCSSを見直すときの観点を紹介します。

ZodをフォームバリデーションやAPIレスポンスの検証に使っているチームは多いと思います。そんなZodですが、近年はバリデーション専門というより、データ変換ライブラリとしても進化してきました。私もパイプラインを書いたのをきっかけに、「バリデーションのついでにデータ整形もやってしまおう」という考えが加速しました。

しかし便利さに頼るうち、スキーマ定義のチェーンがビジネスロジック化したり、スキーマを読むだけでは処理の全容が追えないコードになってしまいました。チームから「処理の流れが追えない」「便利そうだけどよく分からん」と言われたこともありました。

本発表では、フロントエンドのスキーマ定義で便利だった実装と、苦しくなった実装を、実際の声と共に紹介します。スキーマに書くべきことと、普通の関数に切り出すべきことの判断基準を、自分なりの失敗から共有します。