トーク

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

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

https://www.instagram.com/front_engineer_ykn

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

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

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

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

複数のバリデーションが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について、できるまでのところをすこしお話しできたらいいなと思っています。

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

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

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

SPAが主流となった現在、フロントエンドは複雑化しがちですが、「HTML-over-the-wire」という別の選択肢があります。
本セッションでは、サーバからHTMLを送信し、最小限のJavaScriptでUXを構築するこのアプローチと、その代表例であるHotwireの思想を紹介します。
HotwireはRails専用の技術と思われがちですが、本質はフレームワーク非依存の設計にあります。
デモではRailsを使用せず、Express.js上でTurboを動作させ、Turbo Drive / Frames / Streamsの仕組みを解説します。
また、SPAとは異なるアーキテクチャであるため、状態管理やCSRF、XSSなどセキュリティにおいて考慮すべき観点も異なる点について触れます。
SPAと比較しながら、HTML-over-the-wireが有効な場面と設計上の判断軸を整理します。

CSSは長らく「見た目を整えるための言語」とされてきました。しかし近年、：has（）、
Container Queries, Popover API, Custom Properties などの登場により、CSSはUIの状態や振る舞いを表現できる言語へと進化しています。
本セッションでは「モダン CSS はJavaScript を置き換えるのか？」という問いを起点に、CSSが実際に置き換え始めている領域と、依然としてJavaScriptが担うべき責務を整理します。
単なる機能紹介にとどまらず、「どこまでをCSSで書き、どこからをJavaScriptに任せるべきか」という設計上の判断基準を、実例を交えて紹介します。

Canvas APIはGoogle SheetsやFigmaなどリッチなWebアプリを支える技術ですが、Reactなどの宣言的UIフレームワークとは設計思想が異なり、組み合わせに悩むポイントが多くあります。
本トークでは、実務でCanvas APIを用いたテーブルUIの開発経験をもとに、以下の内容をお話しします。
・ReactのライフサイクルとCanvas描画の責務分離
・useRefやカスタムフックを活用した設計パターン
・Branded Typeによる座標・サイズの型安全な扱い方

「Reactと組み合わせると設計に迷う」という方に、明日から使える設計指針を持ち帰っていただけるトークを目指します。
https://diggle.engineer/entry/canvas-table
https://diggle.engineer/entry/branded-type