トーク

長期的な保守性や再利用性を考慮して、Reactに依存しないライブラリを選ぶことがあります。
このLTでは、TanStack Query風のライブラリを簡易的に自作しながら、「Reactに依存しないライブラリ設計」とは何か、コードベースからイメージを掴みます。

• useSyncExternalStore と Pub/Subパターンを使った React と VanillaJS の連携
• Reactから他UIライブラリへの対応

について話します。

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

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

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

歴史あるフロントエンドコード内部は型のないJavaScriptで溢れかえっていませんか？ 私たちのチームも同じ問題に直面していました。
チームではフロントエンド担当1名を含むエンジニア5名でNuxt3アプリケーションを扱っています。そのうち8割はJavaScriptです。
この状況で、すべてのコードにTypeScriptを厳密に導入するのは、影響範囲・工数観点でも現実的ではありません。
本発表では、私たちが実践している段階的なTypeScript導入のアプローチを共有します。
特に「コンポーネント改修の優先順位付け」「現実的な型定義の落としどころ」、そして「妥協しなかったAPIスキーマの型定義」について具体的な事例を交えて解説します。
完璧な型システムを目指すわけではありません。重要な箇所に型を適用し、エンジニアが快適に開発できる環境を構築する実践的な知識をお伝えします。

Rust 製 NES エミュレータを 1 コードベースのまま

• wasm（ブラウザ）
• SDL2（デスクトップ）
• CLI（ターミナル）
  の 3 環境で動作させる設計方針を 5 分で紹介します。

今回の発表では主に以下の内容を詳しく話します。

• 純 Rust コアと UI 境界を trait で分離するアーキテクチャ
• ブラウザ向けに wasm-bindgen でバインディングを生成する手順
• Canvas＋WebAudio を用いたフレーム／音声レンダリング
• ts-bindgen 等を使った Rust 型 → TypeScript 型自動生成ワークフロー

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

とあるプロジェクトにアサインされたときのこと。

巨大なAPIをフロントエンドで受け取り、フロントエンドでいい感じに描画するため、APIのデータを整形する様々な整形処理がされていました。
APIにはクエリパラメータもない。APIを改修するのは、諸般の事情で何故かできない...

同じような処理が様々なファイルに記述され、複雑に絡まったコードベースたち...　（これはメンテナンスができない！）
そんな複雑に絡み合った状況に、少しでも見通しを良くするためモデル層を設けて、データフローを一方通行にしてリファクタリングしました。
データフローを、一方通行にするために助けてくれたのが、Remedaのpipeというメソッドの力でした。

本セッションでは、Remedaのpipeを使ってリファクタリングを行った仮定を追いながらpipeの威力をご紹介します。

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

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

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

魔法のような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変更がバックエンドまで影響することも。実プロジェクトから学んだ「型の境界線」の見つけ方を具体例とともにお話しします。