トーク

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）を取り入れることによって解決できた事柄について紹介します。

2025年現在、Viteはフロントエンド開発の至るところで見られるようになりました。
Next.jsを除く、ほとんどの主流なフロントエンドフレームワークで採用され、Webアプリだけではなく、ライブラリ開発やテストなどにも利用されています。

なぜ、これほどまでに普及したのでしょうか。
１つはスピードでしょう。ESModulesを基本とした設計により圧倒的な開発スピードをもたらします。
それだけではなく、もう１つはプラグイン開発のしやすさだと私は考えています。
Rollupをベースにしたプラグインインターフェースはプラグイン開発者の体験をワンランク上へと引き連れました。

本トークでは、簡単なプラグインの作成ハンズオンをしながら、プラグイン作成の容易さを確認し、Viteの内部的な動きをイメージできるようにします。

本発表ではドキュメント駆動な開発によって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 を例に取り上げます。
また、実際に、ディレクトリ用リンタの活用事例などを踏まえた運用手法を含め、今すぐ開発に取り入れられる、ディレクトリ戦略としてお伝えできれば幸いです。

「CSSって地味？古い技術？」そのイメージ、もう過去のものです！
実はCSSはここ数年で驚異的な進化を遂げ、かつてないほど便利で強力なツールになっています！
これまでJavaScriptやSassの助けが必要だった複雑なレスポンシブレイアウト、ユーザーの動きに合わせた動的なスタイル変化、そして目を引くリッチなアニメーションなど、多くのことがCSSだけで、直感的かつシンプルに実現できるようになりました。
本トークでは、そんなモダンCSSの持つ真の力を凝縮してお届けします。

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

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

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

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

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

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

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

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

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

魔法のようなAIコードエディタ（Cursor、GitHub Copilot、Cline）は、一見すると謎めいたツールですが、その正体はElectronを基盤に、TypeScriptとReactを用いて構築されたWebフロントエンドです。

本セッションでは、AIコードエディタの内部動作を技術的に詳しく解説します。ユーザーが入力したプロンプトがどのようにLLMのAPIに送信されるのか、その際に必要な文脈や情報がどのように収集されるのか、レスポンスをどのように解析してUIに反映するのかを順序立てて説明します。

また、LLMからのツールコール（edit_file）を解析し、具体的なコード差分をVS Code APIを介してどのようにファイルへ反映するかについても触れます。実際のソースコードや具体的な動作フローの図解を交えて、「魔法」の中身を分解・理解できるようになることを目指します。

激動の2025年、クラウドで簡単に高性能なAIを呼び出せる時代となりました。
しかし、クラウドAIには以下の注意点があります。

・通信の遅延や切断
・プライバシーに関する懸念
・継続的な金銭コスト

LLMをクラウド経由ではなくローカルPC内で動作させることで、これらのリスクを回避できます。

2024年11月、Chromeブラウザ内部にGemini Nanoをダウンロードして利用できるBuilt-in AI APIのOrigin Trialがスタートしました。
本セッションでは、これらのAPIの概要から活用例までを、実際にAPIを利用して開発したChrome拡張機能のデモを交えて解説します。

※ AIのモデルとエコシステムの発展速度が非常に早いため、発表時（9月）の状況に応じて内容を調整する可能性があります。

フロントエンド開発で「なんでこの型設計がこんなに難しくなるんだろう？」と感じたことはありませんか？実は私も同じ悩みを抱えていました。
開発を進める中で気づいたのは、TypeScriptの型には「ユーザー視点の型」と「システム視点の型」という2つの異なる性質があるということ。

ユーザー視点の型は「検索フォームの状態」や「ページ遷移履歴」のようなUIと直結し、頻繁に更新される情報です。
一方、システム視点の型は「ユーザー情報」や「注文データ」のようなビジネスロジックやAPIに関わる構造で、整合性が重視されます。

この2つを混ぜると、UI変更がバックエンドまで影響することも。実プロジェクトから学んだ「型の境界線」の見つけ方を具体例とともにお話しします。