トーク

React19.2で新しいHooksであるuseEffectEventが追加されました。
これにより古い状態を参照し続ける「stale closure問題」にメスが入り、イベントハンドラの貼り直しなど余分な処理をEffectとして実行する必要がなくなりました。
一方、どのようにして最新の状態を取得しているのかご存知でしょうか？
なぜ、依存配列に含めていないはずの最新の状態を持ってくることができるのでしょうか？

本セッションではReactのソースコードを紐解き、useEffectEventが内部でどのように「関数の同一性」と「最新状態の維持」を両立しているのかを解説します。

こちらの延長線の話となります。
https://zenn.dev/maguro_alterna/articles/17a0938c5b02a3

React Server Components（RSC）の登場によって、サーバーサイドでのデータ取得やレンダリングが可能になり、GraphQLが解決してきた課題の一部をRSCでもカバーできるようになりました。 一方で、ReactのRFCでは「Server ComponentsはGraphQLに取って代わるものではない」と明言されており、Meta社内ではRelayとRSCを併用する取り組みも進められています。

では実際のところ、GraphQLとRSCはどう使い分ければいいのか、あるいは併用するのがいいのでしょうか。

本セッションでは、まずGraphQLとRSCがそれぞれ何を解決する技術なのかを整理した上で、類似点と相違点を解説します。 そして、RFCや公式の発信情報も参照しつつ、併用で得られるメリットとそれに伴う複雑性のトレードオフについて、実務での経験も交えながら紹介します。

現在携わっているプロジェクトでは、 Next.js を利用しています。
プロジェクト開始当初、私は React / Next.js の開発経験がありませんでした。
そのため、ほぼ知識ゼロから実務を通してキャッチアップを進めてきました。

本トークでは、 Next.js 未経験者が 1年半の実務で得た経験を、以下のトピックを中心にお話します。

• 知識ゼロから実務利用するまでの習得プロセス
  • Next.js と React Hook Form, Zod などの周辺ライブラリの習得
• 利用経験のある Vue.js / Nuxt.js との対比
• 実務を進める上でつまづいた点
  • 多様な React Hooks の役割の理解と実用方法の習得
  • サーバーコンポーネントとクライアントコンポーネント

本セッションの内容が、未経験の技術で開発を進める方に少しでも参考になれば幸いです。

JavaScriptでの日付操作は、ブラウザの実装や実行環境のタイムゾーンに強く依存するため、フロントエンド開発における「鬼門」となりがちです。

実際に私のプロジェクトでも、日付フォーマットの違いによってタイムゾーンの解釈が変わったり、
toISOString を通した際に「1日のズレ」が生じたりと、Dateオブジェクトを正しく扱えなかったことによるバグが発生しました。

本LTでは、JavaScriptの仕様に基づいてバグの原因を深堀りつつ、環境に左右されない「堅牢な日付操作」の指針についてお話しします。

aタグを使ったLinkButton実装において、disabled状態にもかかわらずフォーカスが当たり、Enterキーで操作できてしまうケースに遭遇しました。

本LTでは、この挙動がアクセシビリティの観点でどのような点が問題になり得るのか、HTML要素の役割（セマンティクス）、W3C仕様、ARIA属性の考え方を踏まえながら見ていきます。
さらに、主要なUIライブラリの実装例を参考にしつつ、LinkButtonにおけるdisabled状態をどのように実装・表現するのがよいのかを考えていきます。

アプリケーションのフルリニューアルや大規模リファクタリングを経験したことはありますか？１ヶ月から長ければ６ヶ月近い時間をかけて、既存のアプリケーションを新しく作り直す。技術負債の解消や最新のデファクトスタンダードを採用でき、モダンなユーザー体験の提供なども期待できる大掛かりなプロジェクトになりがちな取り組みです。

しかし一度挑戦すると、道中さまざまな苦難に遭遇します。既存アプリへの機能追加への追従や不具合対応の反映、そしてそれに伴うコンフリクト解消作業。。そして膨れ上がった巨大なコードベースのテスト工数やデプロイ準備タスクに目を回す・・・

継続的デリバリーは、このような大きな開発とデプロイの苦痛を軽減するためにあります。古くから読まれている・実践されているソフトウェア開発手法から何を学べるのか。CI/CDのエキスパートとして、またPaaS企業でのフルリニューアル経験を元に、紹介します。

生成AIを利用したコーディング、AI駆動開発は2026年における不可避な流れです。しかしこれまでのチーム開発とは異なり、課題の解決から先送りしていた問題の顕在化まで、良い点も悪い点も全てが高速で開発チームに押し寄せることになります。

AI駆動開発において「何をAIに委ね、何を人間が決めるか」は、多くの開発者が直面する権限委譲の問題です。
本セッションでは、Vibe Coding（AIを完全に信頼）とSpec駆動開発（仕様で制約）
という両極端なアプローチを、ジョハリの窓を用いて整理します。

「わからないことについてどう向き合う、折り合いをつけるか」
「わかっていることを確実に遂行させるために何ができるか」

変化の激しい時代における「変わらないもの」と「不可避な変化」への向き合い方についてみんなで考えましょう。

近年の Web における UI は装飾性の高いものが増えてきています。
a タグも例外ではなく、見た目や情報量に配慮した「装飾されたリンク UI」を求められる場面が多くなってきました。

こうしたリンク UI では、文字だけでなくアイコンや画像など様々な要素を a タグの中に含めることがあります。
これらの要素をレイアウトするために div タグを使うこともありますが、本当にそれは問題ないのでしょうか。

「a タグはインライン要素だから div タグを入れてはいけない」という認識を改め、現在の HTML 仕様ではなぜそれが可能になっているのか、その仕組みについて 透過的コンテンツモデル を中心に解説します。

Tailwind CSSによって色の指定は効率化されましたが、ブランドカラーなど一色だけが決まっている状態から50〜950までの色をすべて用意する作業は、依然として手間な作業です。その難しさは、単に多くの色を用意することではなく、Tailwindの既存カラーパレットの濃淡やコントラストの変化を理解しなければならない点にあります。

この課題に対してTailwindの全既存色を対象に、色相レンジごとにモデル化し、テスト駆動で検証することで、その変化を支えるカラーカーブを自動生成する関数を実装しました。この設計を成立させるためには、RGB や HSL では不十分で、知覚的に連続した補間が可能な OKLCH を用いることが不可欠でした。本セッションではそのモデリングや実装の過程を紹介します。

この仕組みによって、一色だけ決まっている状態でも違和感のないテーマ作成を進められるようになります。

実務に入りたての未経験エンジニアである私が、React Hook Form（RHF）とSWRを組み合わせた開発中に遭遇した「編集後に古いデータが残る」という不可解なバグ。その原因は、両ライブラリが持つ「ライフサイクル」の認識のズレにありました。

SWRがUX向上のために高速で返した「古いキャッシュ」を、RHFの defaultValues が「最新の初期値」として一度きりの評価で確定させてしまう。この両者の仕様同士の衝突をどう読み解き、どう解決したか。

本LTでは、単なるバグ修正に留まらず、ライブラリのライフサイクルをエンジニアがいかに設計すべきかという視点でお話しします。「ライブラリがよしなにやってくれる」という安心感の一歩先へ、実務での失敗から学んだ、状態管理における「意思表示」の大切さを共有します。

バックエン・インフラが主のエンジニアが初めてReactアプリを構築した実践記。Protocol BuffersからTS/Go双方の型を生成し、Repositoryパターンでコマンド一発でgRPC/Mock実装を切り替えるDI基盤を整備し、shadcn/ui+Tailwindの「way」に乗る
① Contract-First: .proto→TS+Goの型自動生成
② Repository DI: Mock/gRPC切替と並行開発
③ AI駆動UI: 型安全な境界がFigma MCP×Claude Codeを機能させた話
④ 「way」戦略: DI基盤上でshadcn/ui+Tailwindに委ねる割り切り

Mock実装はTypeScriptだけで完結していて、バックエンドの知識不要で書ける
フロント専門でなくても型で境界を定義すれば人間もAIもパラレルに動ける、という学びを共有します

フロントエンドでは、ディレクトリ構成がコンポーネント設計の品質に直結することが少なくありません。
言い換えれば、ディレクトリ構成こそがコンポーネント設計のスケーラビリティを左右する鍵なのです。
こうした背景から、近年ではFSDやBulletproof Reactといったパターンが注目を集めています。

BCD Designは、スケーラビリティに優れたコンポーネント分類手法です。
導入することで、コンポーネントの命名やパス、粒度の決定に迷う必要がなくなります。
ただし、BCD Designを理解するには、その根底にある「明名」という概念を押さえておくことが欠かせません。

本セッションでは、BCD Designをトップダウンで紐解きながら明名の考え方を学んでいきます。
また、応用的なディレクトリ構成についても紹介します。
ディレクトリ構成にこだわりのある方には、きっと響く内容になるはずです。

デザインシステムのコンポーネント配布はnpmパッケージが主流ですが、バージョン運用やブラックボックス化が課題になりがちです。
本セッションではshadcn/ui Registryを題材に、コンポーネントを「パッケージ」ではなく「コード」として配布する新しいアプローチを解説します。
CLIによって必要な実装がプロジェクトに展開される仕組みや、依存関係の解決方法を紹介し、従来方式との違いを整理します。
また、実装が手元に存在することでAIが内部コードを参照しやすくなり、修正提案や差分生成が行いやすい点にも触れます。

・ Registryの仕組みと導入の流れ
・ npm配布との比較と適用領域
・ AI代におけるコード配布の価値

2026年、デザインシステムの運用は「人間が手作業で支える」時代から「AIが自律的に同期する」時代へと変わりました。
本セッションでは、Figmaのデザイン変更からコード生成、さらには形骸化しがちなドキュメント更新までをシームレスに自動化する技術スタックとその実践方法を解説します。

特に「ドキュメントの自動生成」は、開発者の負担を劇的に減らします。
生成AIにコードの変更を連携し、使用例や注意点を最新の状態で維持し続ける仕組みを紹介します。

しかし、すべてを自動化すれば良いわけではありません。
成功の鍵は、生成AIに任せる「作業」と、人間にしかできない「設計（意思決定）」の境界線をどこに引くか。
自動化の仕組みを構築した上で、エンジニアが本来向き合うべき「プロダクトの体験設計」や「コンポーネントの柔軟性」に注力するための、2026年版・標準ワークフローを共有します。

生成AIの普及により、誰もが瞬時にUIを生成できる時代になりました。
しかし、「AIに指示を出しても、なんとなく微妙な画面しか出てこない」「何度もやり直しが発生して、結局自分で書いたほうが早い」と感じたことはありませんか？
生成AIから最適なUIを引き出し実用的なアウトプットを得るために必要なのは、UIデザインのスキルではなく、その前段階にある「情報設計（IA）」の力なのです。

本セッションでは、情報設計がいかに生成AIとの協働で必要不可欠なのかを説明し、ユーザーが触れる情報の優先順位や、データの親子関係を整理するプロセスなど具体的な手法についても解説します。
情報設計を学び、自分が意図した通りのUIを最短距離で作るための「地図」を手に入れましょう！

多言語対応では、翻訳キーや文言を人が手動で管理する設計が長く前提とされてきました。
近年は開発体験や自動化への関心の高まりを背景に、こうした「人がすべてを管理する前提」そのものを見直す動きも出てきています。

本LTでは、私自身が実務で利用している Next.js + next-intl を例に、翻訳キーの自動抽出を行う Experimental 機能 useExtracted を取り上げます。
この機能自体は AI を用いたものではありませんが、翻訳キーを人が増やして管理する前提を崩す設計になっています。

未来予測やAI活用の紹介ではなく、現場の実装から見えてきた「多言語対応の前提が変わり始めている兆し」を共有します。
多言語対応を設計・運用している方が、これからの構成を考えるきっかけになれば幸いです。

あなたはautofocusの正しい用法を知っていますか？
私はまず存在を知りませんでした。

ESLintのjsx-a11yルールをプロジェクトでリポジトリに導入したとき、no-autofocusルールに違反するエラーが発生しました。
そこで初めてautofocusという属性の存在を知り、プロダクトで使われていることに気づきました。
ESLintのエラーなので単純にautofocusを消すこともできましたが、知らなかった属性だったのでMDNやW3Cのドキュメントを読みました。
その結果、アクセシビリティに配慮したautofocusの正しい用法を理解できました。
本LTでは、実務での経験をもとに以下を紹介します。

• autofocusとは何か
• なぜLinterが警告するのか
• autofocusの正しい用法
  聞き終わる頃には、autofocusを自信を持って使えるようになります。

TanStack Start はルーティング・データ取得・型安全性を一体として扱える強力なフレームワークですが、自由度が高い分一人や少人数で開発する際には設計判断に迷いやすい側面もあります。
本セッションではTanStack Start を使って「破綻しない構成」をどう実装してきたかを紹介します。

具体的には、以下のようなトピックを扱います。
一人開発で起きがちな課題と TanStack Start を選んだ理由
Routes / Loader / Action をどう分けて考えると迷いにくいか
フォルダ構成や責務分離をどこまで厳密にするかの判断基準
型安全性が設計と実装の負担をどう減らしてくれるか

TanStack Start をこれから使ってみたい方や個人・少人数でフロントエンド開発を進めている方が自分のプロジェクトに持ち帰って活かせる考え方を得られる内容を目指します。

Chrome 144にて<geolocation>要素という新しいHTML要素が利用できるようになりました。
この新機能は今まで命令的なAPIでしか取得ができず、制約の多かったWebにおけるパーミッションのあり方を大きく変える可能性があります。

この発表ではいままでのWebにおけるパーミッションモデルの限界や、<geolocation>要素など権限を扱うことのできるHTML要素が解決する課題などを、この機能の前段となったPEPC（Page Embedded Permission Control）の提案段階から総括して発表させていただきます。

大手金融機関やメーカーの構築現場には、個人の制作では想像もつかない「徹底した品質管理」が存在します。
100項目超のチェックリストにはアクセシビリティや内部SEOも厳格に含まれ、altの一文字のミスすら「公開事故」として扱われます。一つのミスがブランド価値を損なうことに直結するからです。
本セッションでは、そんな環境で培った「徹底した品質管理」の実態と、スピードが重視される現場でこそ陥りやすい「品質の形骸化」をどう防ぐかをお話しします。
セマンティックなマークアップが単なる「コードの綺麗さ」ではなく、アクセシビリティや信頼を守るための防波堤であることを再定義します。

https://www.instagram.com/front_engineer_ykn