🦊

フロントエンドカンファレンス東京2025 参加レポート（当日）

に公開
CSS
TypeScript
frontend
アクセシビリティ
idea

はじめに

2025年9月21日に開催されたフロントエンドカンファレンス東京にオンラインで参加しました。多様なセッションが展開され、フロントエンド技術の最新動向と深い知見を得ることができました。
本記事では、各セッションの要点を紹介します。

1. Bon Voyage CSS Ecosystem Meets Standards now

登壇者：saku

要点

  • レスポンシブデザインの逆転: これまでの「コンテンツが外部に応じる」から「外部がコンテンツに応じる」イントリンジックウェブデザインへ
  • コンテナクエリがついに実現: 10年前から欲しかった機能がcontain: inline-sizeで無限ループを回避して実現。たった2週間で主要ブラウザに実装されたのがすごい
  • CSSは命令じゃなくて提案: CSSはブラウザに「こうしろ」じゃなくて「こういう意図です」と伝える宣言的な言語
  • Figmaとの溝は深まる一方: CSSが宣言的になるほど、命令的なFigmaとの差は広がる。デザインシステムがますます重要に
  • 結局やることは変わらない: 新機能が出てもデザインの意図をCSSに翻訳する仕事は変わらない

2. 見た目は動く。でも使えない、、アクセシブルなUIの実装アンチパターン集

登壇者：maddy/杉吉真奈

要点

  • まずはちゃんとしたHTMLを使う: <div>じゃなくて<button>、<span>じゃなくて<a>。これだけで基本的なアクセシビリティは確保される
  • みんな当事者になりうる: 障害って「永続的」「一時的」「状況的」がある。赤ちゃん抱っこしてたら片手しか使えないとか、みんな経験ある
  • カーブカット効果: 車椅子のために作った歩道のスロープが、結局みんなに便利。アクセシビリティもそういうもの
  • ARIAの第一ルール: ネイティブHTMLでできるならARIAを使うな。複雑なUIの最後の手段
  • 1行で解決とか嘘: 「JavaScript1行追加で完全アクセシブル」みたいなツールは逆に使いにくくなる
  • HTMLのセマンティクスを軽視するな: 「動く」だけじゃダメ、「使える」まで考えよう
  • アクセシビリティに特効薬はない: 地道に一つずつ対応していくしかない
  • あなたのコードで変わる: 誰かの「使えない」を「使える」に変えられるのはあなたのコード

3. LLMとPlaywright/reg-suitを活用したjQueryリファクタリングの実際

登壇者：kinocoboy

要点

  • レガシーコードは功労者: 「クソコード」とか言わない。今もお金稼いでる大事なコード
  • なぜ辛いのか: IDEの便利機能が全部使えない。jQueryセレクターはただの文字列だから
  • LLMは偵察機として使う: コード書かせるんじゃなくて、構造を調べる係として活用。「このコード何してるの？」みたいな
  • VRTは個人ツールとして: CI/CDに組み込まず、自分のローカルで使う安全装置として
  • ビッグバンリリース回避: LLMで確信を持って、VRTで安全を確認して、少しずつリリース
  • 万能じゃない: VRTは見た目だけ、LLMもたまに嘘つく。根本的な解決にはならない

4. フロントエンドパフォーマンスチューニングで Web 技術を深掘り直す

登壇者：progfay

要点

  • HTTP/2が遅くなる時: パケットロス多いとTCPレベルでブロックされてHTTP/1.1より遅い
  • WebPが遅くなる時: CPU弱いとデコードが重くてJPEGより遅い場合がある
  • ボトルネックは移動する: ネットワークからCPUに変わったりする
  • 学び方を変える: 興味のあることだけじゃなくて、パフォーマンスという軸で学ぶ
  • 知識じゃなくて知恵: 実際に手を動かすことで使える知恵になる
  • 知らないことを知る: 自分が何を知らないかすら分からない領域に気づける

5. "フロントエンドの技術"を移行する技術

登壇者：外松 俊尚

要点

  • スコープの変化が難易度を決める: 技術的な良さより、責務が増えるかどうかが重要
  • 数える: ESLintで移行対象を正確にカウント。感覚じゃダメ
  • 進捗を見える化: グラフにするとチームのモチベが上がる
  • AIとCodemodを使い分ける: 大量の修正は決定論的なCodemod、調査はAI
  • コミット分ける: 自動修正と手動修正を別コミットにするとレビューが楽
  • プロダクトKPIも見る: 技術指標だけじゃなくてビジネス指標も監視
  • Props Down, Events Up: データの流れを一方向にして分かりやすく

6. TS - Type = JS ?

登壇者：Jxck

要点

  • コンパイルじゃなくて型消去: tscは型チェックして型情報を消すだけ
  • JSDocの糖衣構文: TypeScriptの型はJSDocを書きやすくしただけとも言える
  • 言語拡張は使わない: enumとかnamespaceとかスーパーセットの機能は非推奨
  • 仕様書がない: 型チェックのルールはchecker.tsのコードが仕様
  • ツールが分かれてる: 高速ツール（SWC）と正確な型チェック（TSC）で分離
  • 欲しかったのはDX: 新しい言語じゃなくて、安心できる開発体験

7. Playwright はどのようにクロスブラウザをサポートしているのか

登壇者：nus3

要点

  • 翻訳してる: 同じAPIでもブラウザごとに全然違うコマンドを送ってる
  • ブラウザ改造してる: FirefoxとWebKitは特別にパッチ当てた改造版。WebKitは21,000行のパッチ
  • メンテが大変: ブラウザごとにパッチ管理するのめちゃくちゃ大変そう
  • WebDriver BiDiに集約: 将来は個別パッチが不要になる標準プロトコル
  • みんな対応してる: Puppeteer、WebdriverIOとかも対応表明

8. 意外と知らない input[type=number] の仕様と、全角対応について

登壇者：Kyouhei Horizumi

要点

  • 数値と識別子は違う: type="number"は計算する数字用。電話番号とかは文字列
  • セマンティックが大事: HTMLもTypeScriptの型と同じで意味を考えて使う
  • 日本では使えなかった: IMEオンで全角数字入れると消える。「日本では使い物にならない」状態
  • 本人が直した: 登壇者がChrome 140とSafariに全角→半角変換機能を実装

9. 先進的なCSS関数で実現する動的スタイリング

登壇者：斉藤賢悟

要点

  • CSSで条件分岐: if()関数でif (条件) { A } else { B }ができる
  • 3つの条件: media()（メディアクエリ）、supports()（機能サポート）、style()（要素の状態）
  • progress()関数: 範囲内の現在位置を0-1で返す。流体タイポグラフィとかに使える
  • scroll()関数: スクロール連動アニメーション。animation-timeline: scroll(root)
  • calc()が進化: Chrome 140から異なる単位の掛け算割り算ができる
  • JavaScript不要: 今まではJSでやってた動的な処理がCSSだけでできる

10. ブラウザストレージを活用した、複数アプリをまたぐ永続化とリアクティブな同期

登壇者：てつを。

要点

  • LocalStorageはイベントバス: ただのデータ保存場所じゃなくてタブ間通信の仕組み
  • 変更したタブでは発火しない: storageイベントは他のタブでだけ発火する不思議仕様
  • リアルタイム同期: OBSのAlive Studioみたいに複数ウィンドウ間で同期できる
  • セキュリティ注意: XSSで盗まれる、開発者ツールで改ざんされる
  • 機密情報は入れない: サーバー側で必ず検証する
  • 型安全に: Zodで検証、リポジトリパターンで抽象化
  • 責務分離: コンポーネントが直接触らないようにして保守性アップ

お礼

時間の都合により全てのセッションを視聴することは叶いませんでしたが、非常に多くの学びを得ることができ、大変有意義な時間を過ごすことができました。
学んだことを今後のフロントエンド開発にしっかり役立てていきます。
登壇された方々、スタッフ、スポンサーのみなさま素敵な機会をありがとうございました！

Discussion