トーク

ESLintは、JavaScriptやTypeScriptのコード品質を維持するための重要なツールです。
理想的には最初からESLintを導入して品質を保つことですが、現実には既存の大規模コードベースで数千、数万のESLintエラーが発生しているケースが多々あります。

私たちも同様の課題に直面し、効果的な段階的解消戦略を開発・実践しています。

改善はまだ道半ばですが、これまでの経験から得られた知見と戦略をお話しします。

以下のような課題をお持ちの方に特に参考になると思います：

• 「ESLintを導入したいが、既存コードのエラーが膨大で手がつけられない」
• 「ESLintエラーを解消したいが、効率的な進め方がわからない」

私たちと同じ悩みを抱える方々に向けて、段階的な解消戦略の具体例と実践方法を紹介します。

社内デザインシステムをMCPサーバー化し、AI エージェントに UI 実装を生成させる取り組みが話題になりました。指定のルールに従った精度の高いコードをAIに書かせられる一方、MCPサーバーの保守や提供情報の整備といった課題もあります。

そんな中、「Storybook に代表される UI コンポーネントカタログにMCPサーバー機能を搭載すれば、追加投資なしに AI 活用できるのでは？」と思いつきました。UI コンポーネントカタログは、コンポーネントの一覧、パラメータ、使用例、といった、AI が必要とする情報を既に持っているからです。

本トークでは、実際に自作のカタログアプリケーションにMCP機能を追加してみたので、その結果を共有させて頂きます。
これは .NET/C# による Web フロント開発の事例ですが、Storybook の利用者をはじめ、プラットフォームに依らず応用頂けます。

Viteを使用した開発では、ファイルを編集すると、アプリケーション全体のリビルドを伴わずに、変更がブラウザで動作しているアプリケーションに反映されます。
このような仕組みを Hot Module Replacement (HMR) といい、モダンなビルドツールが提供する開発体験の基本的かつ重要な要素のひとつとなっています。

このトークは、Vue Fes Japan 2024で発表した「Demystifying Vite Internals」 (https://speakerdeck.com/nozomuikuta/demystifying-vite-internals) に関連して、
Viteの内部実装のうち、Hot Module Replacementに関わる部分を解説します。

202X、私はボタンコンポーネントのスタイルを調整していた。修正は軽微で開発も快調。
しかし動作検証をした時に悲劇は起こった。表示崩れしているのである。
ありえない、原因はコンポーネント外部から指定されているCSSだ。

狂った声を上げると同時に、「またか」と心の中で呟いていた。

素早く変更履歴をチェックすると、そのCSSを書いたのは私だ。
書き捨てCSSの、甘い誘惑に人は耐えらえない────。

様々な顔をみせる悲劇の分析、そして悲しみを繰り返さないためのプラクティスとは────。

デザインシステムは「らしさ」を再現するための仕組みだと定義すると、「らしさ」の部分を設計する行為がブランディングです。
この「らしさ」をきちんと設計することで他プロダクトと差別化でき、顧客のロイヤリティも向上させることができます。
しかしブランディングを担当する部署とプロダクトの開発をする部署は離れている場合が多く、その接続に課題がある組織も多いでしょう。
このトークではプロダクトブランディングからデザインシステム、フロントエンド開発を一気通貫で接続するための手法について、事例を交えながら解説します。
デザインシステムの技術だけでなく、組織やワークフローの設計、フロントエンド開発への適用についてもお話するつもりです。

Typescript の型って複雑だと思ったことありませんか？
でも型を値の集合だと考えると、実はそんな難しくありません。

本セッションでは集合の観点から Union (和集合)、 Intersection (共通部分)を解説します。
集合の観点だと never (空集合)や unknown (全体集合)、 any (世界観クラッシャー) も分かりやすくなります。

しかし、JavaScript の Structure Typing を理解していないと集合の観点だけでは理解し難いところもあります。
オブジェクト型の Intersection って共通部分なのに何でプロパティ増えるんだ！？
逆にオブジェクト型の Union だとプロパティ減ってるんだが！？
戸惑うかもしれません、でも大丈夫！その理由もはっきり解説します。

TypeScript 型への理解がもっと深まる機会を提供しま！

デザインシステムというと、UIの共通化やルールの整備を思い浮かべる方が多いかもしれません。
でも実際には、それを「どう運用していくか」「どうやってチームに根づかせるか」のほうが、ずっと悩ましかったりします。

このトークでは、デザインシステムを導入・運用してきた中で見えてきた

• 再利用と柔軟さのバランスを取るコンポーネント設計の考え方
• 一貫性を保ちつつ変更に強くするための構造づくり
• チーム内の共通理解を育てるレビューやドキュメントの工夫
• 属人化しないための設計

など、エンジニア視点での実践と気づきを紹介します。

「とりあえず作って終わり」じゃなくて、「ちゃんと使い続けられるデザインシステム」を目指す。
そのために実践してることを紹介します！

Reactのフレームワークといえば、Next.js？
いいえ、ReactベースのWebフレームワークはNext.jsだけじゃありません。
このトークではNext.js以外のフレームワークとして、 React Router（Remix）やWakuなどさまざまなReactベースのWebフロントエンドフレームワークに触れ、その結果と個人的な感想について話をします。

デプロイのしやすさ、フレームワークの機能、レンダリングの挙動 etc...できるかぎり多くの観点で比較に挑戦します。

※このプロポーザルは執筆（2025/5/27）時点の情報を多く含みます。当日トーク内容の詳細部分に変更が入る可能性があります。

Webフロントエンド開発において、グローバルでの状態管理は常について回ってきます。
特にクライアントサイドにおいては、バックエンドや外部のサービスから取得した状態をグローバルに持ち、バックエンドと同期を取りながら画面を更新していくことが前提となっています。
とはいえ、グローバルでの状態管理は開発が進むにつれて、認知負荷が高くなりやすかったり、全体像を把握しづらかったり、はたまたライブラリを扱うためのコードで見通しが悪くなったりするなど課題も多いのが現状です。

このトークでは、極力グローバルでの状態管理を避けていかに「取得⇨更新/同期⇨取得」のサイクルを実現するかについて紹介した後に実際の事例としてReact x useSWRでの実現例、CQRS的な実装（オレオレCQRS）を取り入れることによって解決できた事柄について紹介します。

本発表ではドキュメント駆動な開発によってCoding AgentやCode Generatorなどを積極的に活用していくための戦略や取り組みについてお伝えします。
私が所属する組織で取り組んでいる内容、私個人で試してみて良かったこと、これからやっていきたいと思っている内容なども含めてお話しします。

• 人とAIで作業の分担、Coding AgentとCode Generatorの棲み分け
• UIやロジック、テストを生成するためのドキュメンテーション
• OpenAPIを用いたAPI仕様の記述とコード自動生成によるポータビリティの向上
• コード品質を担保するためのLinterやテスト、コメントの記述
• 継続的に品質・スピードを上げ続けていくためのドキュメントのメンテナンス

当日は上記に関するデモなども交えながら実際にどのように開発しているのかをお見せする予定です。

Tauri は軽量でも「OS 依存 WebView」と「ビルド待ち」の二重コストが開発速度を阻害します。
Electron では Chromium が吸収していた OS 間の実装差異を自分たちで解決する必要があり、スクリーンキャプチャなどブラウザ未実装機能も Rust 側で補完しなければなりません。
さらに UI 修正の共有のために毎度フルビルド配布が必要で 15 分超の待機が発生します。
本発表では以下を紹介します。

• 音声API を Rust 側で抽象化し OS 環境に依存せず動作させる方法
• OS ごとに機能を分岐する方法
• Tauri API を Bridge パターンで抽象化し、ブラウザ／Tauri 環境をシームレスに切り替える手法
• plop によるボイラープレート自動生成で開発サイクルを高速化する仕組み

本セッションでは、Tauriフレームワークを通じたWebフロントエンド技術とRustを組み合わせたアプリケーションの開発事例を紹介します。

・ アプリケーションデモとアーキテクチャの紹介
・ Tauriの概要について
・ 他クロスプラットフォームフレームワークとの比較
・ Tauriを導入することで実際のプロジェクトで獲得した知見の共有
　- フロントエンド/Rust間の状態・疎通
　- 他デスクトップアプリケーションとの連携
　- フロントエンドエンジニアがRustを習得するために乗り越えるべき課題
・ macOSアプリケーションの頒布において直面した課題とその解決、OSSコミュニティへの貢献事例

2025年1月2日にRecoilがGitHub上でアーカイブされ、React 19で動作しないという問題を抱えたまま開発が完全にストップしました。

私の所属する会社ではRecoilを広く活用しており、データ取得からUI表示までを一貫してRecoilで構築していました。Recoilの代替としてjotaiなどのライブラリが挙げられますが、Recoilのデータフローが大きく複雑に絡み合っていたため、一括で移行することは困難でした。そのため、まずはデータフローの流れを可視化するツールを作成し、重要な点から剥がしていく方法を取りました。また、一定の基準を設けてRecoilをuseMemo、useContext, TanStack Query、jotaiに分割して移行しました。

本セッションではデータフローの可視化からRecoilを各ライブラリへ移行した方法について実例を交えてご紹介します。

アイディアと動作するプロトタイプの間には多くの地味な作業がある。技術選定から基礎設計、実装までやるべきことが多い。そこを生成 AI に任せて「動く仮説」を素早くつくり、ユーザーにあてていく開発スタイルを模索した。本トークでは、次の観点で実践内容を共有する。

• 生成 AI にざっくり作らせる
• 技術検証したい部分だけはしっかり作る
• 生成 AI が苦手なところとその対策

インタビューやフィードバックから動くものまでの距離が短ければ、学習も速く、深くなる。生成 AI を使うことで、人間はユーザーが触れるフロントエンドに注力しやすくなる。仮説検証サイクルがどう変わったかを実例ベースで紹介する。

教育向けプロダクトにおいて、教材を Markdown で構造化・管理している。その中で直面した課題は大きく次の 3 つだった。

1. 一般的な Markdown には存在しない構文の追加: ルビや画像サイズの指定など
2. Markdown 編集支援: textlint ルール作成
3. 効率的なレンダリング: SSR / CSR / Edge 使い分け

本トークでは、これらへの自分なりの解決を共有する。

Reactで宣言的に3Dシーンを構築し、React Hooksでインタラクションやアニメーションを制御する、具体的で「Reactらしい」実装方法をデモを交えてお届けしたいです。

Reactで開発していると、整ったUIだけでなく、ユーザーが思わず触ってしまうようなインタラクティブな表現を追求したくなります。しかし、そのためにWebGLを導入しようとすると、途端に「Reactらしくない」複雑な連携に悩まされる。私もそのギャップに苦しみました。
React Three Fiberは、そんな「Reactのままで、もっと面白いものを作りたい！」という純粋な思いを叶えてくれたツールです。このトークを通じて、WebGLが決して特別な技術ではなく、Reactスキルを拡張する楽しい武器になることを伝えたいです。複雑さから解放され、表現の喜びを皆さんと共有できれば最高です。

開発において「適切なコンポーネント設計」とは何でしょうか？

DRY原則に従って重複した実装を避けること？
単一責任の原則に基づいてコンポーネントを厳密に分離すること？
それともコロケーションに倣って関心毎に実装をまとめること？

どれも正しいようで必ずしも絶対的な正解とは言えません。

日々の開発の中で「銀の弾丸」は存在せず、適切な設計は決して簡単ではありません。
一般的に効果的とされる設計思想であっても、何かしらの「トレードオフ」が伴います。

だからこそ、チーム体制やプロダクトの要件、スケジュールなど、様々な要素を踏まえてプロジェクトに適した設計方針を模索する必要があります。

このプロポーザルでは私が直面した設計上の課題や葛藤にどのように向き合ってきたかをケース化し、Vue.jsの実装例とともにお話しします。

事例を通じて、コンポーネント設計に悩む皆さまのヒントになれば幸いです。

フロントエンド開発では、コンポーネント粒度や、ディレクトリ設計について必ず考慮する必要があります。しかしながら、 Vue.js や Nuxt に関連して言及される機会は少なく、困っている開発者の方も多いのではないでしょうか？
このセッションでは、コンポーネントの粒度からディレクトリ管理まで一貫したディレクトリ管理の手法を Nuxt を例に取り上げます。
また、実際に、ディレクトリ用リンタの活用事例などを踏まえた運用手法を含め、今すぐ開発に取り入れられる、ディレクトリ戦略としてお伝えできれば幸いです。

「リリックビデオ」とは楽曲をバックグラウンドミュージックとし、その歌詞やモーショングラフィックで視聴者に対し楽曲を訴求する映像メディアです。
一方で筆者は、インパクトを優先するあまり歌詞が過度に断片化され、過剰な背景処理が加えられた映像を見るにつけ

『私は何を見せられているんだ...。あなた達が想いを込めて書き上げた、その歌詞で勝負しろよ！』

という想いを抱かざるをえません。筆者はこれをリリックビデオにおける「リリック至上主義思想」と称します。

その思想のもと筆者は、楽曲と歌詞を同期再生するTauri製の楽曲再生アプリケーションを制作しました。
筆者の音楽とCSSへの愛によって実装されたフルスクラッチのCSS Animationによるリリックビデオとともに、ここに「リリック至上主義思想」を宣言します。

生成AIの台頭で、AI駆動開発によるアウトプットは飛躍的に増加しています。しかし、その裏側で品質への懸念が高まっているのではないでしょうか？

私たちのチームでも、同様にAIのアウトプットに対する品質の課題に直面しました。
特に、人命にも関わる可能性もある医療系業務サービスでは、品質の懸念は徹底的に排除しなければなりません。

本セッションでは、これらの課題を乗り越えるために私たちのチームが4月から実践している、「品質を担保しながらAIと共存し、確実なリリース・運用を実現する」具体的なプラクティスを共有します！

AIを用いたフロントエンド実装と仕様書の整合性チェック事例などを交え、AI時代の品質担保における次の一手を提示します！

参考: https://kakehashi-dev.hatenablog.com/entry/2025/05/09/104354