プロポーザル

LLM にフロントエンドのコードを書かせたときにこんな問題に直面していませんか？

・同じようなコードが繰り返されている
・コンポーネントの責務が曖昧
・使われていないコンポーネントがある

これらのコード品質の問題は開発前の設計で防ぐことができます。

Vue コンポーネント開発において、props とコンポーネントの依存関係を事前に設計することで、LLM が生成するコードの品質を安定させることができます。

本 LT では、業務で試して分かった品質を担保するための設計プラクティスをお話しします:

・LLM に渡すべき設計情報
・品質ブレを防ぐ設計フォーマット
・実務で得られた効果と課題

LLM でも長期的に保守できるコードを書けるように設計を工夫していきましょう！

皆さん、「Laravelインターフェースの恩恵」を受けた！と感じた経験はありますでしょうか？
自分は入社当初から先輩エンジニアに「インターフェースありがたみ、3年後かな〜5年後かな〜、いつかわかる日が来るよ」と教育され、開発を続けてきました。

コードを書く中で何度も触れる一方で「定義はしてるけど…これ本当に必要？」という疑問もずっとありました。
今回のセッションでは、エンジニア5年目、今の自分が感じる「インターフェースの恩恵」について語っていきたいと思います！

要点
①「いつかわかる」の正体（FW理解×プロジェクト成長）
②実例：同じ機能でも中身が違う（同じ受け口で扱い、条件分岐の散在を防ぐ）
③DI/Facade/モデル/ポリシーで効く場面
④テスト容易性と重要性
⑤使う/使わない判断軸

インターフェースは魔法の解決策ではありません。
しかし 「同じ機能でも中身が違う」時、コードの重複を避けつつ「渡せる対象」と「呼べる操作」を固定できます。
運用で発生するであろう追加要件にも耐えやすい設計になります。

運用とテストを考えたシステム設計開発を！
皆さんも、インターフェースのありがたみ感じてみませんか？

ユーザーが試行錯誤しながら状態を行き来する探索的UIでは、CRUDアプリケーションなどとはまた異なる前提・アプローチが必要になると考えます。

本セッションでは、サーバーをほぼ持たないクライアント完結型のツール開発を通して得た経験をもとに、
「画面の状態」と「アプリケーションとして守るべき論理状態」を分離することの重要性を整理します。

入力・状態の正解が存在しないUIにおいて、どの状態をUIに委ね、どの状態を設計として固定すべきか。
UIから分離した設計を固定するために、どのような構成・配置にするのか。

その考え方を、特定のフレームワークやドメイン知識に依らず、一般化して共有します。

みなさんは「この会社、エンジニア強そうだな」と感じたことはないでしょうか。
実は、エンジニア組織の強さは外からでも意外と見えます。

26卒の就活生として、学生の立場で多くの企業を見てきた中で感じたのは、プロダクト思考やビジネス視点があることはもちろん大切ですが、
それだけでは「エンジニアとして強い組織」には見えないということでした。
一方で、設計の話をしている、技術選定の理由を語れる、失敗を技術として言語化している。
そうしたエンジニアがいる会社は、学生から見ても自然と「ここは強い」と伝わってきます。

本LTでは、学生目線で企業のエンジニアを観察してきた経験をもとに、プロダクト思考と技術思考の違いに触れつつ、外から見える“エンジニアとしての強さ”の正体を整理します。

みなさんは、「このUI、わかりにくいな」と思った瞬間にアプリを閉じたことはないでしょうか？

ユーザーは迷った瞬間に離脱します。説明が必要なUIは、その時点で選ばれません。

私はスポーツ指導者や高齢者支援、地域サービスといった現場にITを持ち込み、実際にユーザーに使ってもらうプロダクト開発に取り組んできました。しかし、そこで何度も目にしたのは「正しく作ったはずのUIが、誰にも使われない」という現実でした。

本セッションでは、現場で実際に起きた「想定外の使われ方」「そもそも使われなかったUI」の失敗事例をもとに、ユーザーを迷わせないUIとは何かをフロントエンドの視点で整理します。

フレームワークやコンポーネントの前に考えるべき、ユーザー行動から逆算したUI設計の原則を持ち帰っていただければ幸いです。

条件を少しずつ変えながら結果を比較し、試行錯誤そのものを行うUIは、
入力→保存を前提としたCRUD型の設計とは性質が大きく異なります。

これといった正解が存在せず、状態が頻繁に変化し、保存は後段かつ必須ではない。
このような「探索的UI」では、画面とアプリケーションの論理状態を疎結合とすることによって、
より柔軟で堅牢なフロントエンド設計がもたらされると考えます。

本セッションでは、ほぼ完全にクライアントサイドで完結する構成検討ツールの開発を題材に、
制約ルールや計算結果といった「守るべき論理状態」をUIから切り離し、
URLを巻き戻し可能な状態スナップショットとして扱った設計判断を紹介します。

重要なのは、「その状態は画面の都合か、アプリケーションとして守るべき論理か」という線引きです。

探索的UIを扱う際の、一般化可能なフロントエンド設計の考え方と判断基準を共有します。

エンジニアとして成長したい！でもなぜか成長が頭打ち…そんな焦り、ありませんか？
僕も未経験〜５年目の今まで、成長したい一心で “正しそうに見える地雷” を踏み続けてきました。
今回はそんな僕がやって来た「働き方アンチパターン」をご紹介します

アンチパターン５選+α
・「設計後回しで突っ込む」病
・エラー/Warning無視」病（敵を味方にしない…）
・「思い込みで進める」病（きっと〇〇のはず！）
・「迷走して自分でも説明できない」病（木を見て森を見ず！）
・「無茶して英雄になりたい」病（持続不能、SDGSな働き方大事！）
＋
「努力の空回り」病（やるべきことをやらず、やらなくていいことをやる）
などなど…

これらは若手のあるあるかと思います
頑張っている”のに、実は遠回りになる典型的なアンチパターンです。

本トークでは、なぜそれが起きるのかと、明日から置き換えられる具体アクションを、実体験、先輩からの助言を踏まえ、現場あるあるで共有します。

成長は“努力量”より“努力の設計”で決まる。
皆さんも明日から、まずは「努力の設計」始めてみませんか？

楽観的UIは現在多くのアプリケーションで使われており, なおかつReact 19でuseOptimisticが導入されたことでフロントエンドエンジニアにとっても身近な存在となりました. ユーザーを待たせないUIはプロダクトにとって重要なUX上の利点となりえます. しかしそんな楽観的UIも使い方を間違えばフロントエンドとバックエンドの整合性に混乱を引き起こします. この発表では楽観的UIをきっかけにシステム全体のモデル設計について考えます.

この発表ではまず楽観的UIについて整理し, ユーザーを待たせないUIがもたらす利点や使ってはいけないポイントについて触れます. またReact 19で導入されたuseOptimisticを例に具体的な楽観的UIの導入方法についても紹介します.

実装を通じて楽観的UIはUI単体のテクニックではなくシステム全体のモデル設計にかかわることが見えてきます. このような楽観的UIがもたらすメンタルモデル: 投機的・冪等性・イベントに目を向けてフロントエンドからバックエンドまで一貫したモデリングを考えるためのきっかけを提供します.

「ゴール設定は大事」と分かっていても、実際の現場ではやっている割に効果を感じない、
結局タスク消化に戻ってしまう、そんなモヤモヤを抱えていないでしょうか。

本セッションは、ゴール設定にはスキルが必要であり、チームとして練度を上げていくことが重要だという前提に立ち、チーム全員が集中できるゴールを作るための考え方とコツを紹介します。

良いゴールが設定できるようになると、日々の会話が変わります。タスクを終わらせるかではなく、「ゴールに対して今どんな状態か」「次に何を打つべきか」という対話が中心になります。
その結果、

集中度が上がり、優先度の入れ替えや中止を冷静に判断できる
エンジニア自身が次の一手を提案しやすくなる

といった変化が生まれます。セッションでは、以下のポイントを実践的に扱います。

・チーム全員でゴールを作る理由
・自分たちも含めたステークホルダーのゴールを毎回イメージ
・SMART・ALIVE・FOCUSを使ったゴール設定の視点
・完璧なゴール（青い鳥）を追わず、手元から始める考え方

ゴール設定を「イベント」ではなく、チームで磨き続けるスキルとして捉え直したい方に向けたセッションです。

概要

TiDB は「NewSQL」と呼ばれる分散データベースで、
MySQL 互換のプロトコルを持ちながら水平スケールできるなんだかすごいやつです。

さてMySQL互換というからには、さぞ移行もしやすいことでしょう！
MySQLを利用している既存のLaravelのアプリケーションをローカル環境でTiDBに切り替えてみて、果たしてどこまで動くのか？
実際に切り替えてみてからの躓きからTiDBとMySQLの違いを掘り下げ、TiDB導入を検討する際の判断材料を持ち帰ってください！

ターゲット

• TiDB に興味はあるけど触ったことがない方
• RDBMS以外のDBも学んでみたい方
• MySQLの内部挙動に興味がある方
• DBが好きな方

お話すること

• TiDBの簡単な概要、特徴
• TiDBのローカル環境の構築方法
• Laravel アプリケーションを接続してみて実際に詰まったポイント
• MySQLとの挙動の違いとその理由

リアルタイム通信といえばWebSocketが採用されることが多いです。しかし反面、運用の複雑さや、HTTP/2環境では扱いが単純でない点など、実運用では多くの考慮事項が伴います。
対して一方、Server-Sent Events（SSE）という仕組みも存在します。SSEは仕組みがシンプルで、通知系などのユースケースでは有力な選択肢になります。
本セッションでは、SSEとWebSocketを、プロトコルの挙動・インフラ構成・バックエンド／フロントエンドの実装・運用負荷といった観点で比較・検証します。
どちらが優れているかではなく、バックエンドとフロントエンドの連携を軸に、要件から逆算して、より最適な技術を選ぶための判断基準を紹介します。

各技術のトレードオフを整理し、単なる実装に留まらない、現場で役立つアーキテクチャ設計の指針を提示できれば幸いです。

ユーザー体験を向上させるうえで、Webサイトの表示速度改善は重要です。そのためには、バックエンド・フロントエンド双方での最適化が不可欠です。
ただし、処理を改善してもネットワークやサーバー応答待ちがボトルネックになることがあり、とくにサーバーがHTMLを生成している間は、ブラウザ側で描画や重要リソースの取得が進みにくい「待ち時間」が発生しがちです。
こうした待ち時間を活用して重要リソースの取得を前倒しする仕組みが、HTTPステータスコード「103 Early Hints」です。

本セッションでは、サーバーがHTMLを生成している間にCSSやJavaScriptなどの重要リソースを先行してブラウザに通知する「103 Early Hints」の仕組みを解説します。
PHPでのヘッダー送信から、受け取ったブラウザがそれをどのように扱うのかまで技術的に深掘りします。
さらに、実プロジェクトにおけるLCP（Largest Contentful Paint）の変化など、実測データに基づく検証結果も共有します。
サーバーサイドとフロントエンドが連携して実現する、一歩進んだ高速化手法を共に考えましょう。

「技術はあくまで手段であり、目的ではない」本当にそうでしょうか？

振り返れば、通信速度の飛躍が人々のコミュニケーションの形を変え、AIという技術の登場が人間の思考のプロセスそのものを塗り替えています。これらは「手段」が「目的」を追い越したのではなく、「新たな技術の出現が、世界の前提を書き換えた」のです。

技術のポテンシャルを誰より、深く理解しているのは私たちエンジニアです。 ならば、「ビジネスの課題を解決するために技術を選ぶ」という受動的な姿勢はもう捨て、能動的なビジョンを提示し、責任を持ってそれを具現化していくべきです。

本セッションでは、フロントエンドやPHPというWebの最前線に立つ私たちが、技術的確信から逆算して「新しい当たり前」を創り出すために
・　 「技術が世界を定義する」というパラダイムシフト： 技術を手段に留めず、世界のあり方を規定する「前提条件」として捉え直す。
・　「見えている者」の責任： 技術の進歩がもたらす未来を予見し、それを事業やプロダクトにねじ込んでいくための覚悟。
・　技術の進化： 変化の渦中で「好きな技術」を使い続けることは、エゴではなく、未来を証明するための闘いである。

SPA フレームワークのひとつ、Blazor WebAssembly は、React、Angular、Vue、Svelte 等と同類の「コンポーネント指向」フレームワークです。その最大の特徴は「C# で実装する」という点です。これは C# を JavaScript にトランスパイルするのではなく、ビルドして生成された .NET のアセンブリ (.dll) を WebAssembly によるインタープリタで実行するという大胆な仕組みで実現されています。Blazor は認知度こそ低いですが、WebAssembly を利用して JavaScript 以外の言語で SPA 開発を行う成功例のひとつと言えます。このトークを通じて JavaScript 一辺倒の SPA 開発に一石を投じ、様々な言語の開発者の声を拾うきっかけになればと思います。
また、「ブラウザで C#/.NET が動く」という点だけでなく、SPA フレームワークとしての Blazor の特徴や設計思想についても、他ライブラリと比較しながら取り上げていきます。
普段とは異なる技術スタックに触れることで、技術者としての視野を広げる機会になれば幸いです。

SPA フレームワークのひとつ、Blazor WebAssembly は、React や Angular、Vue、Svelte などといったライブラリ/フレームワークと同じく、UI コンポーネントを組み上げてクライアント Web アプリケーションを構築する「コンポーネント指向」のフレームワークです。しかし最大の違いは「C# で実装する」という点です。しかも C# のソースを JavaScript にトランスパイルするのではなく、C#/.NET のアセンブリバイナリをそのまま WebAssembly によるインタープリタで実行してしまうという大胆なアーキテクチャです。さらに加えて、ただ実行できるだけでなく、ブラウザの開発者ツールウィンドウでのデバッグが可能です。つまり、開発者ツールでのブレークポイントの設定とステップ実行、変数ウォッチなどが C# ソースを対象に行えるのです。

ということでこの LT では、開発者ツールに JavaScript 以外の言語が表示される、そんな不思議な光景をライブデモでお見せします。

1ページ構成のWebサイトにおいて、タイポグラフィの質とパフォーマンスを両立させるための取り組みをご紹介します。

• フォントの選択
  • システムフォントでは代替できないNoto Sans JP Weight 100のデザイン性を重視
• パフォーマンスの制約
  • 日本語WebフォントのサイズによるLighthouseスコアの低下を回避したい
• 既存ツールの限界
  • 一般的なサブセット化ではカーニング情報が消失し、品質が維持できない

これらの課題を解決するため、ビルドプロセスを組み込みました。

• 静的解析
  • Astroのビルド済みHTMLをパースし、Weightごとに使用文字を1文字単位で抽出
• クエリ最適化
  • 抽出結果から、必要な文字のみを配信するためのクエリを自動生成
• 自動化パイプライン
  • Cloudflare Pagesを活用し、デプロイのみで最適化まで完結する全自動フローを構築

妥協のないタイポグラフィを、静的解析による抽出からCloudflare Pagesでの自動化へと繋げ、いかに全自動で最適化しきるか。そのアーキテクチャの全容をお話しします。

その角丸、本当に納得していますか？
Apple製品のアイコンやハードウェアの曲線がどこか「気持ちよく」感じる理由。それは単純な円弧（border-radius）ではなく、直線から曲線へと曲率が滑らかに変化する形状が使われているからです。こうした形状は一般にSquircleなどと呼ばれ視覚的な自然さを生み出しています

これまでWebでこのような角丸を再現するには、SVGマスクやclip-pathなどを用いた実装が必要でメンテナンス性に課題がありました
しかし現在CSS Backgrounds and Borders Module Level 4において、corner-shapeプロパティが提案されておりCSSネイティブで表現できる未来が見え始めています。

本LTでは以下の内容についてお話しします。

• なぜ border-radius の角丸は硬く見え、Squircleは「気持ちよく」感じられるのか
• 提案されているCSS仕様corner-shapについて

たかが角丸、されど角丸。
フロントエンドエンジニアのこだわりを、CSS がどこまで表現できるようになるのか。その一端を一緒に覗いてみませんか？

TypeScriptのファーストのスキーマ検証ライブラリであるZod。
「TypeScript バリデーション」で検索すると必ずと言っていいほど候補に上がってくるライブラリであることから、
入力フォームのライブラリで採用している方も多いかと思います。

それに加え、入力フォームの検証以外にもJSON.parseしたオブジェクトなどに利用することも有効です。
ですがTypeScriptのJSON.parseはある問題を抱えています。

本セッションははその問題を起点に複雑なネストを抱えたオブジェクトに対して、
どういうアプローチで型安全な実装をしていくかをお話していければと思います。

目次

1. Zodについて
2. JSON.parseの問題点
3. 複雑なネストを抱えたオブジェクトに対して、ユーザー定義の型や型ガードで対応するのじゃだめなの？
4. Zodの使用例

Obsidianとは、マークダウン形式のテキストデータをローカルで管理できるノートアプリケーションです。
デフォルトの設定で使っても十分に便利ですが、各種プラグインを導入して色々とカスタマイズすることも可能です。

そして実はなんと、Obsidianのプラグインは、フロントエンドの技術（TypeScriptなど）だけで簡単に開発できるようになっています。素晴らしいですね！

本セッションでは、Obsidianのプラグイン開発の基礎と、作成したプラグインの公開方法についてお話します。
また、サンプルとして私が丹精込めて作った謎プラグインをお出しします。

こんな人におすすめ

• Obsidianが好き
• Obsidianのプラグインを作ってみたい
• 謎機能が追加されてしまったObsidianを見たい

「クラスは一つの責務だけを持つべき」

SRPはこの一言で語られがちですが、この単純化された表現だけで理解しようとした場合、多くのケースでは原典の定義・観点とずれていきます。
「責務」とは何か？一つだけの「責務」を持つとは、どのような状態を指すのか？
その意味は、しばしば原典の定義や観点を省略して、日常語の範疇で理解されてしまい、結果として混乱を生み出していることがあります。

しかもSRPは、提唱者Robert C. Martin自身が2003年→2014年→2017年にかけて焦点を動かしています。
そのため、一通りの定義だけを知っていても、議論が噛み合わない危険があります。

本セッションでは、SRPの定義が「変更の理由」から「人々」、さらに「アクター」へ移る過程を原典（書籍・著者ブログ）から辿り、
なぜ日本語圏で「責任」が日常語化して混乱が起きるのかを解体します。

最後に、技術的関心と組織的関心を見分け、どの観点で分離を判断すべきかを実務の判断基準として提示します。