プロポーザル

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

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

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

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

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を機能させた話
④ 「ウェイ」戦略: DI基盤上でshadcn/ui+Tailwindに委ねる割り切り

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

フロントエンドでは、ディレクトリ構成がそのまま設計の品質に直結することが多々あります。
それに伴い、最近ではFeature-Sliced DesignやBulletproof Reactといったディレクトリ構成のパターンが話題に上がりやすくなりました。

BCD Designは、その中でもコンポーネントの分類に特化した手法です。
BCD Designでは、コンポーネントを関心・状況・基礎の3つの軸で分類します。
しかし、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）の提案段階から総括して発表させていただきます。

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のレイアウトは、プロパティ単体ではなく「コンテキスト」によって決まります。

本セッションでは基礎となるボックスモデルから触れ、主要なレイアウト手法である通常フロー, Flexbox, Grid Layout, position, float, マルチカラムレイアウトと新しいレイアウト手法「Grid Lanes」を取り上げ、それぞれの特徴と得意なユースケースを具体例で整理します。

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

私が普段どのようにレイアウト手法を選定しているか、その判断プロセスを30分で共有します。

「CSSが思った通りに動かない」 「とりあえずコピペして、値をいじって直す」
そんな「雰囲気実装」から卒業しませんか？ CSSの挙動はプロパティに使われている英単語の「原義（本来の意味）」を知ることで格段に理解しやすくなります。

例えば、flex-shrinkは「flex（柔軟に）」「Shrink（縮む）」という言葉の意味を知っていれば、「親要素が狭くなった場合はコンテンツを柔軟に縮める設定」だと直感的に理解できます。

本LTでは、CSSの挙動を支配する「10の英単語」を厳選して紹介します。
align, justify, inheritなど英語としてあまり聞きなじみはないのに、ＣＳＳでよく見る英単語の原義をＣＳＳプロパティを踏まえて説明します。
初学者の方にはＣＳＳを理解するきっかけを提供し、ベテランの方にはＣＳＳプロパティを原義から振り返ることができる発表にします。

複数のバリデーションが1つの巨大な関数に詰め込まれ、フラグで状態管理し、UIへの反映と判定ロジックが混在している
そんなコードに出会ったことはありませんか？
この問題を解決するのが「Railway Oriented Programming（ROP）」と「Result型」です。
ROPはエラーをthrowせず「値」として返すことで、副作用のない純粋関数としてバリデーションを記述できます。
fp-tsやneverthrowもありますが、限られたスコープではシンプルな自前実装が「ちょうどいい」選択になることも多いです。
本セッションでは、以下のブログをベースに、ROPの概念と自前実装の設計判断を加えてお話しします。
https://kaminashi-developer.hatenablog.jp/entry/typescript-rop-result-validation-design

ActivityPubの勉強と新しい技術に触れるべく、AIと共に開発をしてみたら、意外と1人OSSを生み出せるという気持ちになりました。
そして生まれたRoxについて、できるまでのところをすこしお話しできたらいいなと思っています。

長期間運用されるプロダクトにおいて、「良かれと思って行った部分的な改善」が、逆にプロジェクトの寿命を縮めることがあります。
本セッションでは、失敗談をベースに、「開発のリズム」を戦略的に維持するための具体的なアプローチを提案します。

過去、レガシーなコードに対し中途半端にモダンな設計を持ち込んだ結果、全体の一貫性が崩壊し、後の全横断的な機能追加を阻害する事態を招きました。
この経験から、リソースが限られた状況下では、「あえてレガシーなリズムに合わせる」ことこそが、全体最適解になり得ると学びました。

局所的な「正しさ」よりも、プロジェクト全体の「ノリ」や「一貫性」を最優先する。そのためにコピペすらも戦略として使いこなす。
「綺麗なコード」ではなく「次に触る人が迷わないコード」を残すために、エンジニアが持つべき「全体調和のための技術的妥協」という選択肢を提示します。