トーク

フロントエンドエンジニアがこれまで向き合ってきた相手は、人間でした。しかし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の面白さを可能な限り伝えたいと思います。

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

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