プロポーザル

読みやすいコード、分かりやすいコード、とっても良いですよね！
そのためには「しっかり読まなくても良い部分」が大事です

実際の所、プログラミングは「いかにして”端折るか”」の勝負でもあります
低レイヤーはよく枯れた実装に、頻出する処理はフレームワークやライブラリに任せる
そうした汎用的なサポートがあってこそ、「ビジネス固有の処理の実現への注力」が実現します

半世紀以上も前に提唱された「構造化プログラミング」がもたらすのは、正にそんな力です
「順接、分岐、反復の制御構造を用いる手法」と説明されても、今や当たり前すぎてよく分からないかも知れません
その反面、構造化こそが、「抽象概念と詳細な実装の分離」「段階的な詳細化」をもたらす武器となるのです

Agentic Codingの普及で「人間の役割」が変わりつつある今日、
いま一度「構造化プログラミングとは何だったのか」に立ち返って考えてみませんか？

このトークでは

• 構造化プログラミングと、それが無い世界
• 具体の方法論を超え、その背景にあった「良いプログラミング」への視点
• ”今風”な設計手法やアーキテクティングと「構造化」の関係

について展開します

静的解析は単なる「コードの粗探し」ではありません。

例えば React Compiler はコードを静的に解析することで、 React が前提としているメンタルモデルを私たちに提示します。
また、プロジェクト固有のカスタムルールは、暗黙のコード規約を明文化し、人が書いても、 AI が生成しても同じ品質を担保するための基盤になります。

本セッションでは、静的解析が私たちに「どんな世界を見せてくれるのか」を掘り下げた上で、 ESLint・Biome・oxlint といった主要ツールの現在地を整理します。
その上で、プロジェクト規模やフェーズに応じた、静的解析との現実的な向き合い方を提案します。

Next.js 16 から従来のPPAを置き換える形でCache Components機能が登場しました。

Next.js Conf 2025 の目玉でもあったこの機能を実際に皆さんの目の前で使いながら解説していきます。

謎解きアドベンチャーゲーム「カミとミコ」開発の裏側を紹介します。
https://realdgame.jp/s/kamitomiko/

ReactのSPA構成で実装したブラウザゲームです。
サーバーサイド無しのため、画面遷移や進行状態の設計で苦労しました。

ゲーム開発ではキャラクターやフラグなど扱う情報が多く、開発が進むほどデータと状態の関係性も複雑になります。
シナリオ・会話・キャラクター情報・謎の答え・フラグなどの情報はmicroCMSで管理しており、「なぜブラウザゲームにCMSを使うのか」という背景から、スキーマ設計や開発・運用のコツまで説明します。
また、「Figmaを管理画面」としてキャラクターの配置や移動ルートを設定する手法を取り入れたので、その連携方法にも触れます。

本セッションでは、JavaScriptでゲームを作ってみたい人や、状態管理・データ設計で悩んでいるエンジニアに向けて、実装の工夫や苦労した点を紹介します。
・進行フラグや状態管理の設計
・CMSやFigmaによるコンテンツ管理
・LocalStorageでのオートセーブ
・開発中にデバッグしやすくする工夫

マネージャーに対して「開発状況をわかっていない」「どう関わるべきか迷う」と感じたことはあるだろうか？

開発プロジェクトのマネジメントを生業としている私から、
「何を考えて、この発言をしたのか」 「どんな回答を期待しているのか」といったコミュニケーションの裏側を伝えたい。

このセッションで目指すのは、私見ではあるが「マネージャーが何を考えていて、開発者とどんなコミュニケーションを取りたいのかを伝えること」である。

以下のアウトラインでお届けする

• 見積りについて
  見積りに正確さは求めていない。既知と未知の線引きを一緒に行いたい
  精緻な見積りなど不可能である前提に基づいて会話していることを知ってほしい

• 日々の対話について
  世間一般でのコミュ力はいらない。笑いも盛り上がりもいらない。ただ情報と感情について知りたい

• 責任範囲と自由について
  指定していない限りはとにかく自由に開発してほしいと願っている
  そして開発者からのプロフェッショナルとしての責任（提言や批判）を期待している

マネージャーを正しく利用し、もっと自由に楽しく開発できるチームをどう作るか。そのためのヒントを持ち帰ってほしい。

「プログラマが知るべき97のこと」に、未来へのメッセージというエッセイがあります
「いま動く」だけでなく「未来の世界で、それを読む人のため」にコードを、と説くものです

それは、ただ単に「読んで理解しやすいコードを書こう」という話に留まらないと理解できます
レイヤーの設計に、クラスや変数の命名1つとっても、「何をして欲しいか・何を望んでいないか」を伝えていくものになります

1度書かれてpushされたら、「他の誰かのもの」です
そのコードには"signifier"が宿り、それを受け取った人の次なる判断を進ませます
そして、その人の隣に「今それを書いた貴方自身」はいないのです

例えば「◯◯Manager」と「◯◯TableAccess」で、それぞれどんなメソッドが追加されそうでしょうか？
あなたの思った未来に近いのは、どちらでしょう

このトークでは、個人的に考える「設計行為に重要な2つの観点」を共有します

1. 全てのコードは「あなたのいない世界」で勝手に育つ
2. あらゆる形象は、受け手にとっての「示唆」を持つ

皆さんは、AIを日々活用しながら、フレームワークの基礎をどれくらい意識的に学んでいますか？

生成AIの登場により、コーディングは劇的に効率化されました。しかし、私が危惧しているのは、AIが出力したコードを深く理解せずに「そのまま使う」エンジニアが増えていることです。
その結果、一見動くけれどバグやパフォーマンス問題を抱えたコードが生まれています。さらに深刻なのは、タスクが終わっても何も学んでいない——「AIに任せた」で終わってしまうケースです。
私自身、React公式ドキュメント（https://react.dev/learn）を最初から最後まで通読したことで、全体像が見えるようになりました。

本セッションでは：

• React公式ドキュメントを紹介
• 確固たる基礎を持つことで、AIの提案を瞬時に評価し、問題点を見抜けるようになることを示す
• 基礎があれば、AIをもっと効果的に使える。何より自分が書いたコードに責任を持てるようになる。この「オーナーシップ」こそ、信頼されるエンジニアの土台であり、開発をもっと面白くし、学び続ける情熱の源である
  一緒に基礎を見直しましょう。

「あとで読む」に保存した記事、本当に読んでいますか？

私は個人開発で記事キュレーションサービス「CuraQ」を開発し、3400人以上のユーザーに使っていただいています。
このサービスの根底にあるのは「知識は溜めるのではなく循環させるべき」という思想と、「AIは代行者ではなく触媒である」という設計哲学です。

本セッションでは、この思想がどのように技術選定とAI実装に反映されているかをお話しするとともに、「個人開発でもここまでできる」という実践例として、設計思想から具体的な実装まで一気通貫でお伝えします。

対象者

• AIを活用したプロダクトを作りたい方
• Next.js以外のフロントエンド技術（Hono）に興味がある方
• ベクトル検索・セマンティック検索の実装に興味がある方
• プロダクトの設計思想と技術選定の関係に興味がある方

PHPとフロントエンドと聞くと、個人的に思い浮かぶのが, Facebook社（現Meta社）でした.
なにしろFacebookやInstagramでPHPやJavaScriptがそれはもうふんだんに使われてるらしいですよね.
そこから生まれたHHVMやHack言語, ReactやFlow, 結果はどうあれそれらがもたらしてくれたもの.

PHPとフロントエンドとFacebookの話に想いを馳せる30分間ってどうでしょうかね.

皆さんはフロントエンドの監視を行えていますか？

サーバーやインフラの監視に比べ、フロントエンドのエラーは後回しにされがちで、そもそも監視していない、通知は鳴っているものの見られていない、行動につながらないといった状態に陥っているチームも多いのではないでしょうか。

私たちのプロダクトでも、エラーは収集していたものの、何を基準に対応すべきかが曖昧で、フロントエンド監視が形骸化していました。

本セッションでは、

• フロントエンドの監視とは何か、アラートは誰のためのものか
• AI を活用したアラート内容の要約、重要度判断、一次切り分けの仕組み
• チームで機能するフロントエンド監視体制を構築した実践例

これらを具体的な実例とともに紹介し、フロントエンドのアラート運用を形骸化させず、チームで継続的に実践していくための考え方と方法を共有します。

品質向上のためにE2Eテストを導入したものの、「実行時間が膨れ上がってきている」「たまに原因不明で落ちる」「メンテナンスが大変でもう動かしてない」という経験はありませんか？

E2Eテストはシステム全体を通した品質を担保できる一方、安定した運用が難しく形骸化しやすいという課題があります。

本セッションでは、私がPlaywrightを使ったE2Eテストを運用する中で、高速化・安定化させるために行った以下の取り組みを紹介します。

• テストアカウント分離によるテストの並列化
• project機能を使ったテスト分割
• テスト間のデータ受け渡しによる検証の安定化

発表では、申請・承認フローなどがあるBtoB向けのサンプルWebアプリケーションを用いて、実践的な形で改善していきます。
AIにより実装スピードが上がり続ける今だからこそ、高速で信頼性の高いE2Eテストを目指していきましょう！

Laravel上の巨大なjQueryレガシーコードに対し、顧客体験やURLを変更せず、安全かつ段階的にReactへ移行する具体的戦術を提案する。

移行の鍵は、新旧システムの「境界線」を明確にし、開発者が安心してコードを書ける「安全地帯」を作ることだ。技術的には以下の2点を組み合わせることで実現した。

Feature Flagによるバックエンド制御：
　リクエスト単位で「従来のjQuery Blade」と「React用Blade」を出し分ける。これにより未完成の機能を隠蔽し、本番環境でも安全に制御・リリースが可能になる。

戦略的な強制リロード：
　React Routerを導入しつつ、レガシー画面との境界ではあえて強制リロードを行う。SPA化に固執せず疎結合を保つことで、複雑さを排除し置換スピードを最大化する。

本手法の最大のメリットは、URL変更が不要なため顧客への通達コストがゼロである点だ。
「すべてを一度に救わない」「やらないことを決める」というマインドセットと共に、ビジネス価値を損なわず技術負債を返済する現実解を共有する。

皆さん、Laravelでインターフェースの「恩恵」を実感した瞬間はありますか？
僕は入社当初から先輩エンジニアに「ありがたみは3〜5年後に分かるよ」と言われ続け、コードに触れながらもずっと「定義してるけど…これ本当に必要？」とモヤモヤしていました。

そんな僕が腹落ちしたのは、実務で同じ目的なのに手段が増える変更が来た時。
例えば通知、最初はメールだけだったのに、途中からSlack、さらにLINE…と増えていく。
「送る」という目的は同じでも、実装はそれぞれ違う。ここで分岐や修正が増えていくと、変更漏れや把握コストが一気に上がります。

このセッションでは、通知のような身近な題材を使いながら、インターフェースが効く瞬間／効かない瞬間を整理し、迷った時の使いどころの判断軸を提示します。

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

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

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

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

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

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

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

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

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

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

概要

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）の変化など、実測データに基づく検証結果も共有します。
サーバーサイドとフロントエンドが連携して実現する、一歩進んだ高速化手法を共に考えましょう。

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

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

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

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

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

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

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

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

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

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