プロポーザル

普段Jest/Vitestでテストを書いているフロントエンドエンジニアが、PHPUnitを触ったとき、クラスベースの構文やアサーションの書き方などで不慣さや冗長さを感じることがあります。言語によるテストの書き方の違いは、生成AIによりコードを読む機会が増えた昨今において、認知負荷としてボディーブローのように効いてくるはずです。

Pestは、RSpecやJestからインスピレーションをうけている、PHPUnitをラップした軽量なテストフレームワークです。
describe/it/expectといったJest/Vitest風の構文で書け、PHPUnitの資産もそのまま活かせるのが特徴となっています。

本セッションでは、Jest/Vitestユーザーの視点から、Pestの書き味の良さ、それによって得られるメリットを紹介します。

話すこと：

• Pestの特徴と採用メリット
• Vitest/Pest/PHPUnitで同じテストを比較
• PHPUnitとの共存について

話さないこと:

• PHPUnitやPest以外のテストツールについて
• フロントエンドのテスト技法について

Laravelで開発しているWeb APIのテストでデータベースやRedisを使いたいとき、どうしていますか？
SQLiteで代用する、Docker Composeで事前に立ち上げておくなどのアプローチがありますが、どれも一長一短があります。
Testcontainersは、テストコードから直接コンテナを起動・破棄できるライブラリです。
MySQL/PostgreSQLでテストでき、テストごとにクリーンな環境が手に入り、CI設定もシンプルになります。

本セッションでは、LaravelプロジェクトにTestcontainersを導入し、APIテストを書く方法を紹介します。

話すこと：

• APIテストにおける課題
• Testcontainersの仕組みと利用するメリット
• LaravelのHTTP TestsやDBのマイグレーションと組み合わせた利用例
• GitHub ActionsなどCIでの動かし方
• テスト速度とのトレードオフ

状態をなんとなくbooleanやnullableで表していませんか？
そうすると「あり得ない組み合わせ」がコード上では許されて、仕様追加のたびに分岐漏れが増えがちです。
そこで、取り得るケースを列挙して閉じ、変更時の漏れが型エラーとして出るようにする、という代数的データ型の考え方を紹介します。

代数的データ型は、「かつ（AND）」と「または（OR）」という2種類の型の組み合わせで表現できます。
これにより矛盾した状態を作りにくくなり、分岐漏れも型検査で見つけやすくなります。

本セッションでは、代数的データ型を難しい理論としてではなく、変更に強い設計のための道具として扱います。
フロントエンドではTypeScriptの型検査、PHPではPHPStanの静的解析を活かし、言語やツールで担保できる範囲は素直に任せつつ、担保しきれない分岐や失敗だけを「閉じた形」として扱う落とし所を整理します。ケース追加時に「直すべき場所」が自然に見える形に寄せます。

型のテクニック集ではなく、レビューやAIコーディングでもブレにくい設計の基準を持ち帰ってもらうのがゴールです。

多くの人はWebアプリケーション開発の技術選定をする際に、

・フロントエンドとバックエンドを統一した言語やフレームワークを採用して開発する。
・フロントエンドとバックエンドそれぞれ適材適所の言語やフレームワークを採用して開発する。

かと思います。
それは開発効率やエコシステムの恩恵を最大限に受けられることや、各言語やフレームワークの持つ強みを活かせるからです、

ではバックエンドにTypeScriptを採用しつつ、フロントエンドにあえてPHPを採用して開発してみるとどうなるのでしょうか？

様々なライブラリやフレームワークが充実した現代では、このような構成でも開発できることは想像できますが、実際に試した方は少ないのではないでしょうか。
開発者体験や実装はどうなるのか？ライブラリやエコシステムの充実度は？パフォーマンスへの影響は？

本トークでは、この構成で実際に開発した経験を通じて、普段意識せずに享受している技術選定、言語やフレームワークの強みを再発見するきっかけなどをお伝えできたらと思います。

対話型AIのUIは即時応答を前提とした設計が主流でしたが、近年はウェブ検索や外部ツール操作、成果物の検証・修正を自律的に行うマルチエージェントAIの登場により、数分以上にわたる処理体験が一般化しつつあります。このような非即時性を伴うタスクにおいて、実行プロセスをどのように可視化するかは、ユーザーの作業効率を大きく左右します。

登壇者のチームでは、コーディングエージェントや近年のAIプロダクトを参考にしながら、マルチエージェントの実行プロセス表現を設計パターンとして整理・検証してきました。その結果、長時間処理であってもユースケースによって適切な表現手法は大きく異なることが明らかになりました。

本セッションでは、ストリーミング表示、中間成果物の即時確認、バックグラウンド実行と通知、エージェント単位の進行状況可視化といったパターンを紹介するとともに、それらの中からどの手法をどのような判断軸で選択し、実際のプロダクトへ適用してきたのかを解説します。パターンを銀の弾丸とせず、実装と検証を通じて設計判断を積み重ねてきた実践知を共有します。

私は今、とても悩んでいます。
チームメンバーの育成に、とても悩んでいます。

この一年で劇的に変化し、進化してきた生成AIによるコーディング支援技術はエンジニア個人の能力を拡張すると同時に、個人間の能力差というものも絶望的に広げていってしまいました。
すでに一線で活躍している人や、手を動かす以外の仕事に忙殺されるようになってしまった人にとって、これはとても喜ばしいことです。

しかし、チームで開発を続けていく以上、若手たちの育成もしていかなければならない。
私が十数年かけて培ってきたフロントエンドエンジニアとしての知識、経験。それらからくる勘所のようなもの。
こういったあれそれを、後輩たちに伝えていかなければならない。

アーキテクチャを教えればいいのかな？　
テクニックを教えればいいのかな？
心構えの話でもすればいいのかな？

・・・・・・一体どうすればいいんだーーーっ！！！

という具合に、この一年間、私が任されたフロントエンドチームメンバーの育成について、悩んだり実践したりしてきたあれこれを、お話しようと思います。

私はこれまで、大規模かつレガシーなMPAサイトの保守・運用に携わっていました。現場では「SPAいいな」と憧れつつも、大掛かりなリプレイスは現実的ではなく、モダンな画面遷移の提案を諦めていました。本セッションで紹介する「View Transition API」は、そんなかつての私と同じような制約下にあるエンジニアへの一つの回答となる標準技術です。

この技術の最大の特徴は、既存のHTML構造を維持したままCSS数行から導入でき、未対応ブラウザでもサイトが壊れない「プログレッシブ・エンハンスメント」の考え方にあります。リスクを最小限に抑え、ブラウザの標準機能だけで心地よい体験を後付けできるため、実務において非常に現実的な選択肢となります。

本セッションでは、MPAでの基本的な実装方法や、擬似要素によるスナップショットの仕組み、そしてDOMをクリーンに保つことによるアクセシビリティ上のメリットまでデモを交えて解説します。大規模サイトを保守している方はもちろん、クライアントへ低コストかつ効果的な改善提案をしたいエンジニアやディレクターの方に向け、フレームワークに頼らず「もっと良い体験」を届ける第一歩をお伝えします。

JavaScriptでリストをソートする際、多くの開発者は sort() 関数を何気なく使っているのではないでしょうか？

しかし、「ソート」と一言で言っても、複数のアルゴリズムが存在しており、それぞれ特徴や性能が異なります。
また、JavaScriptの内部実装は、使っている実行環境（エンジン）によって異なり、sort()関数もその例外ではなく内部で使用されているソートアルゴリズムが異なるのです。
つまり、同じコードでも、実行環境（エンジン）によって処理速度に微妙な差が生じる可能性があるということになります。

本トークでは、普段何気なく使用しているsort() 関数の裏側に焦点を当てて、実行環境（エンジン）ごとのソートアルゴリズムの違いや処理速度の微妙な違いなどをお伝えできたらと思います。

社内プロダクトのLaravelアプリ開発にアサインされ、リポジトリを覗くと、PHPでE2Eテストを書くDuskが導入されていました。E2EテストといえばPlaywrightやCypressなどJSで書くフレームワークの印象が強く、「なぜPHPでE2Eを書くのか？」と疑問を抱いていました。
しかし実際にDuskを使う中で、その選択には明確な理由があることに気づきました。

Laravelアプリにおいては、
・ユーザーや関連データをFactoryで生成し、画面表示に必要なDB状態をテスト内で明示できる
・権限の異なるユーザーを作成し、loginAs を使ってログイン済み状態を即座に再現できる
・テストに必要なデータ準備とログイン状態を、別ファイルに分けることなく同じテストコード内で定義できる
といった点で、JS製E2Eツールより相性が良いケースがあります。

本トークでは、JS製テストフレームワークと比較しながら、どのような条件でDuskが有効な選択肢となるのかを具体例とともに紹介します。LaravelアプリにおけるE2Eテスト導入時の技術選定の軸を持ち帰ってもらうことを目的としたセッションです。

Smarty などのテンプレートエンジンで構築された既存ページに React を導入したい場面、ありますよね？

中には「ページまるごとリプレイス」ではなく「ページの中で部分的に React 導入」を選ぶべき場面も多いはずです。

このトークでは、Astro で知られる "Islands Architecture" の概念を、
フレームワークに頼らず既存のシステム上で再現・実践するためのアプローチを整理します。

概念自体は React の大前提とも言えるユースケースであり、一見シンプルに見えます。
理論上は、script タグで React をロードして、createElement することもできます。

しかし、JSX はほしいですし、TypeScript 対応や npm ライブラリの利用にはビルドが必要となり、
アーキテクチャやデプロイフローが一気に複雑化してしまいます。

このような悩みに対して、理想論ではない「現実的で実践的な付き合い方」をお話します。

AIエージェントで開発する際、生成コードの品質を担保しつつ、AIにコードを壊させず・迷わせないためには「ガードレール設計」が重要です。
本トークでは、その中核となるフロントエンドのディレクトリ設計手法 Feature-Sliced Design（FSD）に焦点を当て、レイヤー構造とインポート制約、ライブラリ生成物の隔離、entities層を腐敗防止層として機能させる考え方を紹介します。
AIが触ってよい範囲／触るべきでない範囲を構造で表現することで、変更影響を局所化し、レビューや運用を安定させる実践的なパターンを持ち帰っていただきます。

三大クラウドではAIエージェントをAPIとして切り出す方式が公式に用意されています。しかし別途デプロイするとリソース費用の増加などの課題があります。一方で、AIエージェント開発用のSDKやFWが台頭し、実際に構築してみると「Webアプリ内でAIエージェントを構築する」選択肢も現実的だと感じます。

LaravelにおいてもOSSのエージェント開発FW"LarAgent"を使ってLaravelアプリ内にAIエージェントを組み込めました。また、公式が"Laravel AI SDK"を発表したことも相まって「Laravel内でAIエージェントを構築する」流れは強まっていくと感じています。

外部API化は運用の独立性が高い一方、Laravel内実装は既存基盤に乗るのが強みです。ミドルウェアや例外ハンドラ等に統合でき、運用と権限設計の一貫性が生まれます。また、Python中心だったAIエージェント開発にPHPerが参入しやすくなる点もメリットです。

本セッションでは「使い方」ではなく「作り方」に焦点を当て、LaravelでAIエージェントを構築する意味を整理し、実際に構築して見えた課題と可能性を共有します。

PHPのtraitは忌避されがちな機能ではないでしょうか？
私自身、数年間PHPを使ってきて「traitはあまり使わない方が良い」という感覚を持っていました。

一方、私は最近Rubyを書く機会が増えているのですが、RubyのMix-inはtraitよりかは使われる機会が多い印象を受けています。

PHPのtraitとRubyのMix-inはいずれも単一継承言語でコードを再利用する仕組みですが、どこに違いがあるのでしょうか。
PHPのtrait は本当に「悪者」なのでしょうか？

本セッションでは、PHPのtraitとRubyなど他言語を比較しつつ、traitの位置づけや適切な使いどころを整理します。

セッション内容

1. traitの基本と目的
2. 他言語の類似機能との比較
3. trait の評価と使い方・設計判断の考え方

このセッションの価値

• traitの使いどころ・避けどころについて整理できる
• 他言語の類似機能について知れる
• コード再利用の考え方を見直すきっかけになる

想定する聴講者

• 初〜中級者のPHPer、または他言語を利用するエンジニア

概算見積もりのフェーズでは、APIとアプリを同時に開発する前提であっても、設計や見積もりの前提が揃わないまま話が進み、各工程で確認や調整が増えてしまうことがあります。
特に、画面設計や仕様がまだ固まっていない段階では、何を前提として見積もるのかが曖昧になりやすいと感じていました。

そこで、概算フェーズをアプリ主導で進めることが有効なのではないかと考えるようになりました。
アプリ側で画面やユーザー操作、必要なデータの流れを整理し、箇条書きや図などを使って前提を可視化・構造化できれば、APIを設計・実装する人やPMを含む他のメンバーも判断しやすくなるのではないか、という仮説です。

スモールな単位で試す中で、前提が揃っている状態では各メンバーが自分の役割に集中しやすくなる手応えを感じました。
一方で、外部連携や専門性の高い処理が中心となる機能では、バックエンドや知識を持つメンバーが主導した方が自然なケースがあることも認識しています。

本セッションでは、概算フェーズをアプリ主導で進めるために、どのような前提を整理し、どのように可視化・構造化しようとしているのか、現在模索している取り組みと気づきを共有します。

WebSocketやSSEはステートフルな接続です。一度確立するとサーバー側に状態が残り続けるため、切断や再接続の制御が難しくなります。
本セッションでは、配信画面デザインツールにおけるストリーミングコメントのリアルタイム表示機能を題材に、SSEとWebSocketをイベント駆動で管理する設計を紹介します。
SSE接続の有無を起点にWebSocketを制御し、再接続の判断はクライアントに委ねる。このシンプルなルールで、実際の利用状況と整合した接続管理を実現する方法をお話しします。

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

Signalsが提案するリアクティブモデルは、状態の変更を効率よく扱うアプローチとしてフロントエンド開発で重要な設計パターンであり、Angular、Vue、Solid、Svelte、Preact、Qwikなどの主要フレームワーク／ライブラリでも採用されています。

状態管理はフロントエンド開発で避けて通れない課題ですが、Signalsを理解することで、不要な再描画を減らしパフォーマンスを高める設計判断や、リアクティブモデルの本質的な振る舞いを理解できます。

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

Signalsの内部メカニズムを通じて、現代的なリアクティブ設計の理解を深めます。

普段の開発で、「このUIってどのコンポーネントで定義されているんだっけ？」と思ったことはありませんか？

フロントエンドではビルドやminifyによってコードが大きく変換されるため、ブラウザ上に表示されている要素が、どのファイルのどのコンポーネントに由来するものかを知ることは簡単ではありません。
このセッションでは、これを解決する2つの方法をピックアップし、その仕組みについて解説します。

1つはreact-grab等で利用されている、React FiberにアクセスしてFiber Nodeを特定する方法です。ReactのFiberTreeは通常は公開されていないのですが、Developer Tools向けのAPIをフックして実装されています。

もう1つは、Tanstack Devtools等で利用されている、ビルド時にデバッグ情報をJSX Propsに埋め込む方法です。Vite pluginの形式で配布されており、JSXを変換しデバッグ情報を埋め込みます。こちらはフレームワークに依存しないアプローチです。

どちらも最近話題になったライブラリですが、その内部実装について取り扱います。

振る舞い駆動開発（BDD）は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も担うため、開発者とQAのあいだだけでなく、フロントエンドとバックエンドのあいだでも認識のズレを防ぎやすくなります。

本セッションでは、バックエンド・フロントエンドの双方に活かせるBDDの始め方を紹介します。フィーチャーファイルを中心としたBDDの基本的な進め方を軸に、実装レイヤーが異なっても共通して使える考え方を解説します。

PHPとTypeScriptでの実装例を取り上げ、言語や担当領域を越えて共有できるBDDの実践方法を紹介します。

BDDの考え方から実装までを一通り体験できる内容に絞り、職種を問わずチーム全体で活用できるテストの書き方の第一歩を持ち帰ってもらうセッションです。

昨年12月、React2Shell の脆弱性は、フロントエンド業界に大きな衝撃を与えました。しかし、Astroはその設計思想からこの問題を回避していました。また、今年1月にはCloudflareによる買収が発表されるなど、今まさに大きな注目を集めています。

一方で
「Astroって静的サイト向けのフレームワークだよね？」という認識をされている方が多いかと思います。

実は、2024年3月にAstro DB がリリースされ、その後、v4.15でAstro Actionがリリースされたことにより、Astroをフルスタックに使うことができるようになりました。

本セッションでは、このフルスタックの処理がいかにしてアイランドアーキテクチャとZero-JSというAstroの特徴を維持しながら作られているのか、また、フルスタックツールとしてどこまでの機能を実現できるのかに関して言及したいと思います。

AI駆動開発が注目を集めていますが、実際にどのように導入・運用されているか気になりませんか？

本セッションでは、600万ダウンロードを突破したtoCプロダクトの開発現場で実際に実践しているAI駆動開発のリアルな姿をお見せします。AIを活用した開発には、環境づくりが重要です、詳細はこちらの記事：https://zenn.dev/canary_techblog/articles/2358dd21cee434。

具体的には、やりたい施策の立案から、調査、実装、タスク管理、そしてスプリントのプラニングまで、一連の開発フローをAIとどう連携させているかを紹介します。「AIを導入したいけど、どこから始めればいいかわからない」という方に、実践的なヒントをお届けします。