Laravel×Inertia.js構成のSPAで、CSVから5,000件のデータを取得し複数テーブルを参照して表示する処理を実装した結果、ユーザーは真っ白な画面を十数分待つことになってしまいました。

まずEloquentのlazyById()で1,000件ずつ分割処理を試みましたが、すべての処理完了まで画面表示できず、5分待たされます。次にInertia.jsのlazyプロパティを導入したところ、初回表示が短縮され、重い処理は後から非同期で読み込まれるようになり、ユーザー体験は大きく改善しました。

さらにlazyに関して調査を進めると、Inertia.js v2.0で追加された「Deferred Props」という機能に出会いました。実際に導入してみると、lazyよりもパフォーマンスが向上し、コードもシンプルになりました。しかし、なぜDeferredの方が優れているのでしょうか。

本セッションでは、lazy propsとDeferred Propsの違いを内部実装から読み解きます。具体的には、HTTPリクエストの発生タイミング、サーバーサイドでのデータ解決の仕組み、なぜDeferredの方がパフォーマンスが良いのかを、LaravelとInertia.jsのコードベースを追いながら解説します。そして最後に、実践的な使い分けパターンをお伝えします。

このトークは、Inertia.jsを使っているけど遅延読み込み機能を使ったことがない方、v2.0の新機能が気になる方、大量データ表示で困っている方、「なぜ速くなるのか」を理解したい方に是非聞いていただきたいセッションです。

フレームワーク同士の噛み合わせによって、カスタムしたい箇所がうまくカスタムできずモヤモヤしたことはありますでしょうか？

私は「例外時のAPI Platformからのレスポンスをカスタムしたいのに、Laravelの標準エラーハンドラに書いても効かない〜〜〜！」とAPI Platform for Laravelの例外処理に悩まされました。
これは、API Platformが内部で利用するSymfonyのコンポーネントが、Laravelの例外処理よりも手前でレスポンスを生成し、意図的に上書きしているためです。

そこでフレームワークのソースコードを確認して勝ち取った解決策を共有します。それは、複雑な設定変更ではなく、たった一つのサービスプロバイダへの追記によるものです。
ポイントはフレームワークのErrorHandlerクラスをカスタムクラスで上書きすることでした。

このLTでは、フレームワークの制御の意図的な優先問題を解決する実例とDI（依存性注入）がいかにフレームワークを裏側から制御する武器になるかをお話しします！

20000以上のテストケース数を誇るWebアプリについて、2025年5月時点で9並列で約11分かかっていたCIを最終的には5分で終わるように改善しました。また、高速化を終えた後、コスト最適化という面での改善も実施しました。その過程で苦労したことや乗り越えたことなどを事細かに紹介します。

アピールポイント

• CI高速化において、ただお金で殴れば早くなる (例えば並列数を増やすなど) ではなく、コスト最適化も両立させることができたという話をします。

話す予定のトピック

• テスト高速化で実施したこと
  • ボトルネックの計測 (Workflowの時間を計測、プロファイラを利用した分析)
  • 並列実行の最適化 (ジョブ・プロセス毎のテスト時間均一化含む)
  • テストデータの改善 (Factoryの見直しや不要なデータ作成の削減)
  • MySQLの最適化 (tmpfs、my.cnf最適化、ダンプのキャッシュ)
  • Flakyテストへの愚直な対応
• コスト削減に向けて実施したこと
  • サードパーティマネージドランナーの調査
  • 物理マシンを購入し、セルフホステッドランナーとして活用
  • セルフホステッドランナーが落ちた際のフォールバック方法の検討
  • ubuntu-latestをubuntu-slimやself-hostedに置き換え
  • GitHub Actionsの課金体系を理解し、1秒で終わるジョブも1分として切り上げられるため、Jobの見直し
• 「委員会」を通じた改善
  • 私個人の力で全てを実施したのではなく、「委員会」という会社の取り組みの一環として実施
  • https://blog.smartbank.co.jp/entry/2025/07/02/committee-system-introduction

Feature Toggle を使って開発していますか？
Feature Toggle を使って開発をした後使わなくなったトグルを削除していますか？

このトークでは Feature Toggle を導入してから削除するまでどのように運用するといいか話します。

Feature Toggle は開発終わったら削除しようね！

このトークに技術の話はほとんど出てきません。ハウツーでもありません。
プログラミングと出会って25年、ようやくたどり着いた気づきを共有したいです。

技術が好きですか？
もうイヤになりそうなこと、ありませんか？

ぼくはずっと、ある選択をし続けてきました。意識してやっていたわけじゃない。
振り返ってみたら、そうなっていた。
それに気づいたときふと、改めてPHPの生みの親、Rasmus Lerdorfの言葉を読み直し…この気づきは間違いじゃなかったと思えました。

こんな人に聞いてほしいです。

• 新しい技術を追わなきゃと焦っている
• 周りについていくのがやっとで自信がない
• キラキラしたエンジニアにはなれないと思っている

すぐに何かを解決するものではありません。それでも「自分だけじゃない」と少しでも安心してもらえたら。

もしかしたら、ぼくが、ぼくたちがRasmusだ。

オンプレミスの本番環境の構築を行う際にも、やはり開発/テスト環境が欲しくなります。

Dockerを日常的に使用するエンジニアが多いですが、Hyper-Vを利用すると実機の環境をより正確に再現できます。
特にHyper-VはWindows Pro / Enterpriseの環境であれば、機能を有効化することで簡単に導入できるのでとても便利です。

Hyper-Vの機能を有効化すると「Hyper-Vマネージャー」というGUIツールで管理できるようになりますが、設定項目が多いのでチームで共有するためにPowerShellスクリプト（ps1ファイル）で記述してコードで管理できるのが望ましいです。

本LTでは、Hyper-Vの各コマンドを詳しく説明するのではなく、実際にps1ファイルで環境構築を自動化しようとしたときにハマったポイントと回避策を紹介します。

今回はこの2点に絞って話します。

・ps1ファイルをそのまま実行できない環境で、WSL2からPowerShellを呼び出してHyper-Vを操作した方法
・仮想スイッチ作成やVM作成など、管理者権限が必要な作業をPowerShellで記述するための工夫

これからHyper-V環境をコードで管理したい方が、同じ落とし穴にはまらないための知見を共有できればと思います。

近年、PHPには多くの意欲的な言語機能が追加され、ますますコーディングしやすくなっています。
筆者はLispをはじめ、「関数型」と分類されるプログラミング言語について関心を持って取り組んでいますが、それでもPHPと関数型言語には大きな隔たりがあります。

このトークでは、関数型的な観点からの近年のPHPの構文の変化と、それでも関数型言語と見なすには何が足りないのかについて騙ります。

合わせて読みたい： (読まなくていい)

• Lispは関数型言語(ではない) by うさみけんた | トーク | 関数型まつり2025 #fp_matsuri - fortee.jp

4年前、BASEはモジュラモノリスという選択をしました。今では開発のほとんどが新アーキテクチャ上で行われ、リアーキテクチャの大枠はある程度達成されました。本セッションでは、その当時の意思決定に対する「4年越しの答え合わせ」を試みます。

アーキテクチャの成否を数値的に評価することは難しく、また立場上、生々しい事例の全てを詳細に語ることはできません。しかし、アーキテクチャ上にモジュールという「自治のための箱庭」を用意し、そこをメンテナンスする専任チームを組織図上に配置し、４年間運用してみた先にある現実のなかで「アーキテクチャとそれが組織に与える影響」については、多くの知見が得られました。

これらを振り返り、最終的に「モジュラモノリスアーキテクチャは技術だけでは駆動しない」などいくつかの私見に至ったため、それらを述べたいと考えています。疎結合なシステムや、コードの凝集度などの技術的指標だけでなく、組織の力学や人と人との関わりが、いかにシステムに反映されるかをお話ししようと思います。

想定聴講者

• エンジニアリングマネージャー、テックリードなど、エンジニア組織に影響力を持つ方

想定外の聴講者（または留意点）

• モジュラモノリスの実装パターンや技術的詳細に関心のある方
  • 今回は「実装」の話は薄くなりますが、私自身は無限に話せますので、ぜひセッション外で捕まえて無限に聞いてください
• 移行過渡期や具体的な移行方法など、リアーキテクチャの手順に関心のある方
  • ただしセッション外では無限に話せます

※なお、発表内容は社内レビューの結果により一部調整または除外される可能性があります。あらかじめご了承ください。

「AIコーディングエージェントを導入すれば開発が加速する」

そう期待して導入したものの、現実は違いました
人によって生成されるコードの品質がバラバラ、アーキテクチャの一貫性が保てない、レビューコストは減るどころか増える一方、これがチーム開発の現実でした

「なんかいい感じにして」で動くのがVibe Codingです。楽しいし確かに動くコードは出てきます。しかし毎日AIガチャを引き続ける日々となり、チーム開発で再現性が出ません
必要なのは【理論】でした

そこでAWSが提唱するAI-DLC（AI-Driven Development Life Cycle）を導入しました
「AIが実行し、人間が監視する」という原則のもと、AIが参照・模倣できる設計資産を整備することで、ドキュメントを「人間が読むもの」から「AIが従うもの」へと再定義します。
Vibeに頼らない、感覚に逃げない、理論で設計し、理論でAIを導く
これらの対策により、誰が使っても一貫したコードが生まれる仕組みを構築し、レビュー指摘の大幅な削減とオンボーディング期間の短縮を実現しました

本セッションでは、AI-DLCを現場で実践するための具体的な手法をお伝えします。
AIコーディングはやればやるほど奥深く興味深いものになります。
ぜひこの機会に理論を軸にしたAIコーディングを実践して、本当に解決したい課題に集中しましょう！

• 想定する聴講者
  • AIコーディングエージェントを導入したが成果が安定しない方
  • AI-DLCを知らない方、導入してみたい方
  • Vibe Codingに限界を感じている方

「CQRSは大規模で複雑なシステム向けのパターンである」

これが一般的な認識です
AWS公式ドキュメントでも「シンプルなCRUDアプリケーションには推奨しない」と明記されています
ではシンプルなシステムにCQRSを選ぶ理由はあるのか、答えはサーバーレスアーキテクチャにありました

Lambda、DynamoDB、DynamoDB Streamsを組み合わせることで、CQRSの複雑さを吸収しながらメリットだけを享受できます
pay-per-useの課金モデルにより、小規模でもコスト負担なく読み書き分離の恩恵を受けられる
将来のスケーラビリティを考慮しつつ、現在は低コストで開始できる設計を実現します
これがシンプルなシステムにCQRSを選ぶ理由です

本セッションではDynamoDBをイベントストアとして活用した実装、Streamsによるリアルタイム同期、冪等性の担保、最終整合性との向き合い方、SQSとDead Letter Queueを用いたエラーハンドリングまで、実際の実装方法について解説します。

シンプルだからCQRSは不要、ではない
シンプルだからこそ、サーバーレスでCQRSを低コストに始められる
その選択肢を持ち帰ってください

• 想定する聴講者
  • CQRSに興味がある人
  • サーバーレスアーキテクチャの導入を検討している方
  • 小規模システムでコスト効率と将来の拡張性を両立したい方

「このエンドポイント、なんか遅いんだよね」

勘と経験でコードを眺め、怪しそうな箇所を修正する
本番にデプロイして「速くなった気がする」で終わる
あの言葉がよぎります。「推測するな、計測せよ」

Traces・Metrics・Logsの3つのシグナルを収集することで、パフォーマンス改善の景色が一変しました
Tracesでリクエストの流れを可視化し、どのスパンで時間がかかっているか特定する
Metricsでp95/p99レイテンシ、スループット、エラーレートを継続的に監視する
Logsでトレースと紐づけた詳細なコンテキストを取得する
3つのシグナルを相関させることで、ボトルネックの特定から改善効果の検証まで、データに基づいた意思決定ができるようになりました

本セッションでは、PHPアプリケーションに対してテレメトリーシグナルを活用したパフォーマンス改善の具体的な手法をお伝えします
サンプリング戦略、属性設計、Collector構成など、本番運用で直面する課題と解決策も紹介します

勘と経験に頼らず、シグナルが導く改善を始めましょう

• 想定する聴講者
  • パフォーマンス改善を勘と経験で行っている方
  • Observabilityに興味があるがどこから始めればいいかわからない方

世は大酸化時代！
昨今、さまざまな言語のためのツールチェーンをRustで書き直すムーブメントがあります。

PHPにもMagoというプロジェクトがあり、非常に高品質かつ高機能な製品が既に実用レベルに達しています。
この記事ではMagoの機能について既存の各種フォーマッター・静的解析ツールとの違いを紹介します。

PHPerとして働いていると、普段の開発の中や役割が変わるタイミングなど、さまざまなシーンで「思うようにできていない」「期待に応えられていないのでは」と不安を抱く場面は少なくありません。
タスクの優先順位、仕様変更、レビュー文化、ステークホルダー調整など──“自分ではコントロールしきれないこと”は日常の中に多く存在します。

私自身、プログラマからマネージャーへと役割が変わる過程で、無力感や焦りに振り回される時期がありました。
そんな中で助けになったのが「コントロールの三分法」という考え方です。
物事を「コントロールできること」「影響を及ぼせること」「まったくできないこと」に分けて捉えることで、不安な状況でも少しずつ前に進めるようになった感覚があります。

このトークでは、不安や焦りを抱えたときにどのように自分と向き合い、考え方を整えていったのかを共有します。
キャリアステージや役職に関係なく、エンジニアは常に不確実性の中で仕事をしています。
このセッションが、どんな立場の方にとっても「今の状況をどう捉え、どこから前に進むか」を考えるきっかけになれば嬉しいです。

PHPerKaigi 2026 楽しかったですかーー！！！ ＼全員「はーーい！！」／

楽しかった思い出を残しつつ、学んだことを今後の成長に結びつけましょう！
このパンフレット記事では、PHPerKaigiを含むカンファレンスに参加したあとにすぐにでも行える、是非やって欲しい事を紹介します。

個人で

1. 発表を見返してみよう
2. ブログを書いてみよう

会社で

1. 同僚に発表をオススメしてみよう
2. 振り返り会をやってみよう

近年、AIを使ってテストを書くという流れが一般化しつつあり、私自身もAIにテストコードを補助的に生成させています。

しかし一方で、「AIにはあえて任せないテスト」が確実に存在します。
それは仕様そのものを表現するテストです。
AIは既存コードや表層の情報をもとにテストを書いてくれますが、「どうあるべきか」という意図やコンテキストの把握は人間がやる必要があり、仕様の補完や抜け漏れの指摘まで踏み込むことはできません。
TDDを行うときに「先にテストを書く」理由と同様に、最初に仕様を描く役割は人間側に残されていると感じています。

私はテストを「振る舞いの記述」であり、「仕様を共有するためのドキュメント」だと考えています。
したがって、他の開発者が見たときに、そのテストがどんな意図で書かれ、どのような状態を期待しているのかが読み取れる形を大切にしています。

このLTでは、AI時代における「AIに任せるテスト」と「手で書くべきテスト」の線引きを、実務の経験と失敗談を交えながら整理します。
AIに任せてショートカットした方が良い部分、一方で人が書くべき仕様の部分をPHPUnitを使った具体例とともに紹介します。

Feature Toggleは、ソフトウェア開発において特定の機能を有効または無効にできる手法です。

Feature Toggle はとても便利です。一部のユーザーだけに機能を公開したり、本番では機能を無効化しておくことでトランクベースの開発ができることによってコンフリクトを避けることができます。

一方で、Feature Toggle は便利ですが、if (FeatureToggle::enabled(...)) をあちこちに書き散らすと、後からトグルを消すのが辛くなりがちです。
「とりあえず if で分岐」から始めた結果、開発が終わった頃には自信を持って削除できない…という経験がある方も多いのではないでしょうか。

このトークでは、コードの可読性を保ちながら安全にトグルを削除するための設計方法を紹介します。

トーク概要（800文字以内・感謝ニュアンス版）

約3年ぶりにPHPへ「ただいま」しました。
復帰して最初に困ったのは文法ではなく、「今の現場の前提」が変わっていたことでした。
PHPのバージョン差に起因する互換性の勘どころ、フレームワークを選ぶときの判断軸、テストや静的解析をどこまで整備するのが標準なのか。
名前は聞いたことがあっても、根拠を持って決めるための材料が手元にない。ここが復帰直後のいちばん大きなギャップでした。

そんなときキャッチアップの根源になったのが、PHPコミュニティが積み上げてきたブログ記事や登壇資料でした。公式ドキュメントへつなぐ導線になっていて、単なる機能紹介ではなく「なぜそうするのか」「どこでハマるのか」「どう進めると安全か」という実務の知恵が、短時間で手に入る。
結果として、復帰直後に必要だった互換性・FW・品質ツールの未知を、一気に理解できる形に変えてくれました。

このLTは、その感謝を伝えにきました。
PHPに戻ってきた人間が、どんな知らなさに直面し、コミュニティの知見にどう救われたのかを共有します。

Laravel Nightwatchは、Laravelアプリケーションに特化した公式のObservabilityツールです。
https://nightwatch.laravel.com

このセッションでは、その「裏側」で実際に動いている仕組みを、アーキテクチャからコードレベルまで紹介します。

Nightwatchは、ユーザーのLaravelアプリケーションにインストールするパッケージ、ローカルエージェント、クラウド上のデータパイプラインといった複数のコンポーネントの連携によって成り立っています。
OSSの laravel/nightwatch パッケージが各種イベントをフックしてメトリクスを収集し、レスポンス後にローカルエージェントへTCPで送信、エージェントから Ingest API → Kafka → ClickHouse とデータが流れ、最終的にダッシュボードで可視化されます。
リリース初日から世界中から大量のアプリケーションがメトリクスを送り続ける前提で、数十億レコード規模のデータを、マルチリージョン構成で、かつPHP中心のスタックで処理し続ける必要がありました。

このセッションでは、

• Laravel内部のライフサイクルをどうフックしてメトリクス情報を取得しているのか
• どうやってアプリ本体のパフォーマンスを落とさずにデータを収集しているのか
• ReactPHPを使ったイベントドリブンな常駐プロセス
• エージェント〜Ingest〜Kafka〜ClickHouseまでのデータフロー設計
• 大量データ・高トラフィックを前提にしたボトルネックとその対策

といったトピックを、実際のOSSコードやアーキテクチャ図とともにお話しします。

仕事において「Webフロントエンドでサービス開始されたが、あとからネイティブアプリも必要になった」という状況が起こり得ます。

そのときに起こりがちなのが、React Native製ネイティブアプリとReact Router v7以降（元Reimix）などのWebフロントエンドで、独自にAPIクライアントが生えてしまい、仕様変更のたびに2倍のコストで改修することになる問題です。
本セッションでは、このカオスを避けるために、API通信ラッパーをどこまで共通化するのかという現実的な戦略を共有します。

特に以下の3点を扱います。

• ネイティブとWebフロントエンドの違い（ネットワーク品質・バックグラウンド実行・ストレージ・オフライン対応・認証方式・エラー表現など）を踏まえた、バックエンドのAPI設計において配慮すべきポイントと具体例
• API通信ラッパー共通化のためのレイヤー構成（型付き共通クライアント層／トークン管理やナビゲーション連携などのプラットフォーム依存層）と、実行環境の差分を吸収する実装パターン
• Orvalを用いたOpenAPI＋型生成、HTTPクライアント、SWR系ライブラリを選定する際の判断基準と、「ネイティブだけ別実装にしてしまい後から辛くなった」「最初に共通ラッパーへ投資して変更が楽になった」といった実例

[持ち帰ってもらうこと]

• ネイティブアプリ追加時にも破綻しないAPI設計・レスポンス設計のチェックリストを自チームで作成できるようになる
• React Native／Webフロントエンドの両方から使い回せるAPIラッパー構造を、自プロダクト向けに設計し直す際のたたき台を持ち帰れる
• フロントエンド／ネイティブアプリ／バックエンド間で「どこまで共通化し、どこから分けるか」を合意形成するための議論のフレームワークを得られる

TLSは、HTTPSなどで普段使用する際に暗号化を担っている技術ですが、私自身、「HTTPSの裏側でいい感じに暗号化してくれるやつ！」くらいの漠然とした理解しか持っていませんでした。

そこで、TLSを理解するために、TLSプロトコルを実装することに挑戦しました。

このトークでは、TLSの基本的な仕組みについて説明し、どのようにTLSを実装したか、そのプロセスについてお話しします。
また、実装を通じて得られた学びや、ソケット通信に触れることの楽しさについても共有します。

話すこと

TLSの仕組み
PHPでどのように実装したか
得られた学び・ソケット通信に触れる楽しさ