🧠

フロントエンドカンファレンス東京に行ってきたレポ

に公開

9/21(日)に東京で行われたフロントエンドカンファレンス東京に行ってきたのでレポートします。

フロントエンドカンファレンス東京とは

「フロントエンドを次世代に」をテーマとして開催する技術カンファレンスで、以下のコンセプトでやっているようです。

本カンファレンスは次世代を担うエンジニアに向けて、フロントエンドの第一線に立つエンジニアが知見を共有し、成長の機会を提供します。また、開発現場で活躍するエンジニアが外部発信するきっかけを作るとともに、初心者が実践的なノウハウを学べる場となることを目指します。」

https://fec-tokyo.github.io/2025/

登壇者/一般参加者ともに成長機会を与えることをコンセプトとされており、とても素敵ですね。

聴講したセッション

聴講したセッションのうち、興味深かったものを紹介します。

Bon Voyage! CSS Ecosystem Meets Standards, now? by saku さん

https://sakupi01.github.io/slides/ja/2025_09_21_css-ecosystem-meets-standards-now/

概要

  • CSS のエコシステムは、CSS カスタムプロパティやカスケードレイヤーなど「再利用可能でセマンティックなデザイン」の実現に向けて進化してきた
  • レスポンシブデザインのパラダイムも変化しており、ビューポートサイズに依存する時代から、グリッド、Flexbox、固有のサイズ設定(Intrinsic Sizing)を活用する時代へと移行している
  • 長らく要望されてきたコンテナクエリも広く利用可能となり、これによってコンテナがコンテンツのインラインサイズに依存することをキャンセルしつつ 、コンテンツ側がコンテナのインラインサイズをクエリできるようになった
  • このように CSS はますます宣言的になってきており、CSS を書く人の役割はデザインの意図を宣言的な CSS に翻訳することである

CSS の歴史全体を通して、CSS を書く人の役割を定義するという「Design Technologist」の役職がどのようなものかよくわかるセッションでした。

見た目は動く。でも使えない、、アクセシブルな UI の実装アンチパターン集 by maddy/杉吉真奈さん

スライド探し中

概要

  • アクセシビリティとは、恒常的・一時的・状況的な障害を持つ人を含め、誰でも利用可能にすることであり、ユーザビリティの土台となる
  • 典型的な問題は、非セマンティックな HTML、キーボード操作の不備、目的が不明なボタン、ARIA 属性の誤用など
  • アクセシビリティオーバーレイは技術的・法的に限界があり、ユーザー体験を損なうこともあるため、本質的な解決にはならない
  • ネイティブ HTML 要素(例: button, link)の適切な利用と、必要最小限かつ正しい ARIA の使用が、アクセシビリティと支援技術との互換性を高める
  • アクセシビリティは設計・開発の最初から考慮すべきであり、ユーザーテストや手動チェックが不可欠である

障害者差別解消法の改正で民間事業者の合理的配慮が義務化され、こうしたカンファレンスでも採択されているところを見るに、エンジニアがアクセシビリティから逃れることはもはや不可能になってきているように感じます。

実践 AI チャットボット UI 実装入門 bu syumai さん

https://speakerdeck.com/syumai/practical-ai-chat-bot-ui-implementation

概要

  • AI チャットボットのテキストベースのやり取りは一般的だが、常に最適ではなく、地図や商品画像などの専用 UI が有効な場合がある →UI を含んだインタラクションを返す AI エージェントを作る話をしていきたい
  • AG-UI は CopilotKit に強く結びついたプロトコル兼ライブラリで、エージェントが UI を含んだ応答を可能にする。ただし専用フロントエンドが必要となる
  • MCP UI は MCP プロトコルを拡張し、生の HTML をリソースとして返し iframe でレンダリングできる。幅広いクライアント互換性とツール連携が特長
  • AG-UI は状態同期や高度な機能により表現力が高い一方、MCP UI は汎用性を重視し多様な環境で利用可能

AI チャットボットがテキスト以外を返すという発想がそもそもなかった(gemini などの返答も当然の様に受け入れていた)ので勉強になりました。AI チャットボット実装の幅が広がりそうですね。

"フロントエンドの技術"を移行する技術 by 外松 俊尚さん

https://www.docswell.com/s/toshi_toma/Z44R7Y-frontend-migrations

概要

  • 技術移行は目的ではなく、生産性向上、プロダクト価値の向上、レガシー技術の解消などの背景で発生する
  • リスク評価は、影響範囲、互換性の有無、段階的リリースの可否を整理して行う
  • コンポーネントや画面単位での段階的移行、Feature Flag の活用によりリスクを制御し、問題時の素早い切り戻しを可能にする
  • codemod や AI エージェントを活用できるが、複雑なケースでは人間によるレビューが不可欠
  • 自動テスト、特に VRT や E2E テストが、移行後の挙動保証に有効

技術移行、大変ですよね...フロントエンドの大規模な技術移行を経験したことはまだないのですが、今後そのような業務をする可能性があるのでこのスライドは保存しておこうと思いました。とにかく調査・計画・段階的移行・テストが大事ですね。「自動変換と手動修正のコミットを明確に分け、レビューの効率を高める」「grep や find、ESLint ルールなどを使い、影響範囲を定量化して把握する」などの知見も共有されており、助かりました。

メディアクエリだけではない、レスポンシブ対応の考え方と実装 by yuta-ike さん

short バージョン: https://www.docswell.com/s/4136989/5EYV7D-2025-09-21-fec-tokyo-short
long バージョン: https://www.docswell.com/s/4136989/ZM62R8-2025-09-21-fec-tokyo

  • 従来のレスポンシブデザインは「PC 用・タブレット用・スマホ用」といった固定的な分類が中心だったが、折りたたみスマホやウルトラワイドモニターなど多様なデバイスが登場したことで限界が見えてきている
  • UI 要素は「固定の部分(アイコン、ボタンなど)」と「可変な部分(テキストなど)」に分けられ、可変な部分がサイズ変化を吸収してユーザビリティを保つ役割を果たす
  • コンテナクエリはビューポートではなくコンテナ要素のサイズに応じてスタイルを変えられるため、React などのコンポーネントベースのフレームワークにおけるレスポンシブ対応が容易になる
  • 実装の際は、まずシンプルな方法でサイズ変化を吸収することを優先し、必要な場合のみ複雑な手法を使うのが望ましい(優先度: flexbox, grid > コンテナクエリ > メディアクエリ > js)

レスポンシブ対応の方針に今まさに困っていたので、明確な基準や実装方針を示していただけて学びになりました。やはり先に示した優先度を守り、CSS の複雑性を抑える(特定のスコープに閉じ込める)ことが大事ですね。

まとめ

久しぶりにガッツリ技術のお話を聞くカンファレンスに一般参加者として参加しました。
TSKaigi スタッフを一緒にやっていた方とも久しぶりにお話しできたりして楽しかったです。

Discussion