プロポーザル

Reactを使いこなす鍵は、その「思想」の正しい理解にあります。
本セッションでは、Reactを単なるライブラリではなく一つの「思想体系」として捉え直し、全てのReact開発者が共通して持つべき基礎教養を提示します。

「f(state) = UI」という純粋関数性の重要性、状態をスナップショットとして扱うイミュータブルな設計、
そして副作用を「外部システムとの同期」として外部に逃がす設計など、React独自のメンタルモデルを深掘りします。
さらに、Fiberアーキテクチャや差分検知アルゴリズムといった内部実装のソースコード・データ構造にも踏み込み、
並行レンダリング等の最適化手法も踏まえつつ、その思想と実装の繋がりを紐解きます。

この一年、様々なところで「MCP」という単語を聞くようになりました。
なにやらAIチャットが外部と連携できるようになるようです。
ところでMCPサーバーとはどのような仕組みで動いているのでしょうか。

また、MCP Appsという仕様も2026年1月に安定化しました。
MCP Appsとは一体なんなのでしょうか。もしくは、どのように動いているのでしょうか。いわばサードパーティのアプリケーションをどのように隔離しているのでしょうか。

MCP Appsのためのフレームワークchapplinを開発している私が、MCPサーバーからMCP Appsまで技術的な面にスコープを当てて紹介します。

SignalsはTC39のStage1標準化プロポーザルとして進行中で、依存関係を追跡し必要な部分だけを効率的に更新する仕組みとして注目されています。

Signalsが提案するリアクティブモデルは、状態の変更を効率よく扱う設計アプローチとして現代のフロントエンド開発における重要な設計パターンのひとつです。

状態管理は避けて通れない課題ですが、Signalsを理解することで、不要な再描画を減らす設計やリアクティブシステムの振る舞いを構造的に捉える視点が得られます。

フレームワークに依存しない状態管理の共通原理を理解できる内容です。

本セッションでは、以下の視点でSignalsの仕組みを解説します。
・Signalsがどのように依存関係を追跡しているのか
・状態が変わったとき、必要な箇所だけ更新される仕組み
・signal-polyfillを用いた実装検証から得られた知見

ガワネイティブアプリとは、SwiftやKotlinで開発されたネイティブアプリの中でWebViewで機能を表現するアプリの形式です。
様々な都合で、ネイティブアプリ開発が行えない場合において、
Webフロントエンドエンジニアを中心に組成されたチームで、スマートフォンアプリを開発する際に選択される形式でもあります。

本セッションでは、ガワネイティブアプリにうっかり遭遇してしまったフロントエンドエンジニアの方に向け、WebViewの取り扱い方法や、注意点などをお話しします。
また、WebViewで作られた画面とネイティブコードの連携方法など高機能なアプリ開発のためのTipsもお伝えします。

トピック

• iOSで注意すべきCSS
• 検知できるイベント、できないイベント
• ページ遷移（画面遷移）の注意点

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 の役割の理解と実用方法の習得
  • サーバーコンポーネントとクライアントコンポーネント

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

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

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

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

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

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

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

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

React/Vue/Svelteは、同じセキュリティリスクに対して同じアプローチで対処しているのでしょうか？ この疑問から、3つのフレームワークのソースコードと公式ドキュメントを読み比べてみました。調査の結果、自動エスケープのように共通の実装がある一方、javascript: URL のブロックのように React19で導入された対策が Vue/Svelte にはないなど、明確な違いがあることがわかりました。その背景には、各フレームワークが持つ設計思想の違いがあります。本セッションでは、XSS対策を中心に、ソースコードの比較結果と設計思想の違いを、公式ドキュメント・GitHub PR・過去の CVE を根拠に共有します。
こちらの記事でまとめたような内容を発表する予定です！ https://zenn.dev/akito_tsukahara/articles/1d15cb875b0f82

業務中、クライアントから奇妙なバグ報告が届きました。「カタカナ入力で文字が二重になる」

調査すると、「ああ」→F8押下で「ああｱｱ」や「あｱ」になる現象が。F7/F9/F10は正常なのに、なぜF8だけ？原因を突き止めた後、「もしや他でも...？」とこのトークのプロポーザルフォームを試すと、案の定同じ問題が...。カンファレンスのフォームですら見落とされているこの問題は、多くのWebフォームで潜在しています。

本トークでは、F8が引き起こす日本語IME特有の挙動、compositionイベントの仕組み、ブラウザ・OS・IME実装による違い、そして堅牢なフォーム設計の実装方法を解説します。

あなたのプロジェクトのフォームは大丈夫ですか？

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

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

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

バックエン・インフラが主のエンジニアが初めて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をトップダウンで紐解きながら明名の考え方を学んでいきます。
また、応用的なディレクトリ構成についても紹介します。
ディレクトリ構成にこだわりのある方には、きっと響く内容になるはずです。

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

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

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

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

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

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

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

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

10年以上の運用で15,000行に膨れ上がった「CSS地獄」。
"!important" が飛び交うレガシー環境で、既存システムの開発を止めることなく「Vite + React + Tailwind」の開発体験を手に入れる
そのような都合の良い方法は存在するのでしょうか？

本セッションでは、フルリプレースや完全SPA化ではなく「画面のコンテンツ領域にReactを後付けする」という移行事例を紹介します。
最大の壁となるレガシーCSSの干渉を防ぐために、「iframe」ではなく「Shadow DOM」を採用しました。
Reactを「Shadow DOM」でラップする実装パターンを中心に、この手法に至った経緯や、実運用で遭遇した落とし穴とその対策についても共有します。

「レガシー環境を捨てられないが、開発体験は諦めたくない」 というエンジニアの方へ、新旧UI共存の現実解をお届けします。

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

https://www.instagram.com/front_engineer_ykn

私たちが毎日書くJavaScript
その動作が仕様通りかどうかを検証するテストスイートが存在することをご存知ですか？ ECMAScript公式テストスイート「Test262」は、V8、SpiderMonkey、JavaScriptCoreといった主要エンジンが参照する「共通の物差し」です。
この物差しがあるからこそ、「どのブラウザでも同じ結果になる」当たり前が実現されています。

本トークでは、Test262の役割と必要性をわかりやすく解説します。また、私がV8のコードリーディング中に偶然見つけた「FIXME」コメントが、実はTest262の仕様準拠に関わるものであり、長年放置されていた修正のきっかけとなったエピソードも紹介します。 普段意識することのないJavaScriptの「信頼性の源泉」を覗いてみませんか？

CSSレイアウトは、プロパティ単体ではなく「コンテキスト」によって決まります。

CSSレイアウトに苦手意識を持っている方が多いのは、構文の裏にある概念を知らない場合が多いためです。本セッションでは「すべてはボックス」という原則から始まり、ボックスモデル、通常フロー、Flexbox、Grid、position、float、マルチカラムレイアウトと新しいレイアウト手法「Grid Lanes」の概念を解説し、それぞれの特徴と得意なユースケースを具体例で整理します。

CSSレイアウトを「複数のプロパティが協調して動くアルゴリズムの集合体」として捉えることで、私たちが何気なく使用している width や margin の挙動が状況によって変わる理由もクリアになります。

CSSレイアウトの基礎を体系的に解説しつつ、私が普段どのようにレイアウト手法を選定しているか、その判断プロセスを共有します。