PHP を使った Web アプリケーション開発において、多くの場合はサーバーサイドとクライアントサイドで実装が分離されるでしょう。

それらの結節点として、API 仕様を拠り所とするスキーマ駆動開発は

• サーバーサイドとクライアントサイドで独立して開発できる
• 仕様の認識齟齬を防げる
• 型安全に開発できる

といった観点から強力な手法となり得ます。

一方で仕組みを十分に整えないとその恩恵に与れないまま、煩雑さだけを導入してしまうことにもなりかねません。

このトークではスキーマ駆動開発の実践例のひとつとして Symfony と NelmioApiDocBundle の組み合わせを取り上げて

• NelmioApiDocBundle でできること
• 使う上での設定や周辺の設計
• 具体的な API の実装
• NelmioApiDocBundle でできないこと、他の選択肢と比較しての弱み

を解説します。

弊社の主要な検索機能では、Laravel Eloquentを用いたRDS上の検索クエリにおいて、複数テーブルのJOINや複雑なクエリ構造が検索パフォーマンスに影響を及ぼしていました。特に、利用頻度の高いクエリがレイテンシー増加の主因となっていたため、その改善策としてOpenSearchを導入しました。

導入後、検索速度が飛躍的に向上し、レイテンシーも大幅に改善されました。
また、OpenSearchのPHP DSLライブラリを導入することで、クエリの構築をシンプルにし、保守性を高める工夫も行いました。

Laravel eloquentとの共存を図りながら、検索機能のパフォーマンス最適化を実現しました。
これらの経験を基に、検索機能改善の実例を紹介します。

このトークは、パフォーマンスに課題を抱える開発者や、検索機能の改善に興味のある方に向けた内容です。

MVC フレームワークが普及してから約20年。Web アプリケーション開発において「層」を分けることは当たり前の「お作法」になりました。

その効果は「関心の分離」というキーワードでよく語られます。しかし、あなたの現場ではその言葉の意味が正しく理解されているでしょうか。そこで分離したい「関心」とは一体なんなのでしょうか。

意味を理解しないまま、フレームワークや流行のアーキテクチャの表層だけをなぞり、雰囲気で「層」を分けていると、次のような事態に陥ります。

• Controller から Repository へデータを右から左へ流すだけの「土管」Service
• DB のスキーマ変更が、なぜかフロントエンドの修正にまで波及してしまう
• ビジネスロジックがあちこちに分散し、調査に時間がかかる

これでは「層」を分ける恩恵を受けられないどころか、コードを複雑化させ、開発速度を落とす無駄なコストが増えるだけです。「層」の分割は、その意図を正しく理解し、適切な「抽象化」によって本当の「関心の分離」を実現することで、初めてその効果を発揮します。

本セッションでは、形骸化しがちなレイヤー設計に意味を取り戻すための考え方を解説します。

こんな人に向けて話します

• なんとなくルールに従って層を分けているけど、面倒なだけに感じている
• 層を分ける理由をきちんと言語化し、後輩にもっと丁寧に説明したい

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

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

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

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

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

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

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

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

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

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

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

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

話すこと

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

あなたのPHPコードはif文の中にたくさんの条件を連ねて条件分岐していませんか？コメントを書いておかないと何の条件分岐かわからなくなっていませんか？
可読性の下がりがちな条件分岐、実はもっと読みやすく・テストしやすくすることができるんです！
Specificationパターンを使うことで、条件分岐に人間可読な名前をつけることができます。名前をつけるだけで、人間は物事を認識しやすくなりますし、覚えやすくなります。
まず名付けの大切さを日常生活や簡単なPHPコードの事例から解説し、その後にSpecificationパターンを使った実装・リファクタの実例をサンプルコードを共有しながら紹介します。

PHPのsocket機能を利用すると手軽にネットワークプログラミングができます。
私は今までにPHPでHTTPS(TLS)プロトコル、TCP/IPプロトコルを実装してきました。
PHPでTCP/IPを実装？と思うかもしれませんが、意外とPHPでも下の層のプロトコルが自作できます。
PHP8.5からはその下の層のイーサネットプロトコルも扱えるようになり、ついにPHPで物理層以外のプロトコルが実装できるようになったのです！

今回はその機能を使って簡単なIPルーターを自作する方法を解説します。
異なるネットワークのホスト同士がどのように通信するのか、それをルーターとしてどう処理するのか。
PHPを使うことでこの処理の理解がしやすく、C言語よりは手軽に自作ルーターが体験できます。

このセッションを通して次のことが学べます

• IPアドレスとイーサネットとの関係
• MACアドレスの役割
• パケットを転送する仕組み
• PHPのネットワークプログラミング
• LinuxなどOSが提供するsocket機能の役割

アジェンダ（予定）

• PHPのsocket機能
• ルーターの仕組み
  • ARP
  • MACアドレス書き換え
  • パケット転送
• PHPでルーターを作る場合の注意点
• PHPを使ったネットワークプログラミングの面白話

PHP アプリケーション開発において、Xdebug + IDE によるデバッグ実行を利用している方も多いでしょう。

ブレイクポイントを設定して、そこでアプリケーション実行を停止し、変数の内容を見ながらステップ実行で処理を追いかけていく作業はアプリケーションを理解する上で大いに役立つものです。

一方、便利そうな機能だと認識していても設定につまづいて敬遠している方もいるかもしれません。
デバッグ設定では、PHP(Xdebug) と IDE 双方の設定が必要であり、さらに昨今では PHP(Xdebug) は Docker コンテナで実行しているケースも多いので設定に難しさを感じる場面もあるかもしれません。

デバッグ実行は、Xdebug と IDE の間で行われる通信によって成り立っています。
この通信がどのように行われているか、またそれぞれの役割を知ることで設定のどこでつまづいているかを理解しやすくなります。

なにより、日頃便利に使っている機能がどのような仕組みで実現されているかを知ることは楽しいものです！

本セッションでは、Xdebug の内部動作や IDE との通信に焦点を当てて、どのような仕組みでデバッグ実行が実現しているかを見てみましょう。

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

普段使用している Nginx や Apache の仕組みを知っていますか？
Webサーバーは、ブラウザからリクエストを受け取り、PHPに処理を渡し、レスポンスを返すという当たり前の仕事をしていますが、その内側で具体的にどんな会話が交わされているのか、コードレベルで説明できる人は意外と少ないかもしれません。

・TCPソケットの確立
・生のHTTPリクエスト文字列のパース
・RFCに則った正しいHTTPレスポンスの生成
これらをPHPという「アプリケーション側の言語」で書き下すことで、HTTP通信のライフサイクルを完全に理解することを目指します。

Prettier Code Formatterは、外部のParser利用や独自の変換機構によって、複数言語に対応しています。
PHPもその対応言語の一つであり、prettier/plugin-phpとしてnpm経由で利用可能です。

本セッションでは、Prettierのcode formatにおける段階的なデータ変換の仕組みや（Source Code → Parser → AST → Printer (Doc IR) → Formatted Output）、
plugin systemとしてPHPに同じ機構を提供するためのインターフェースなどについての内容を想定しています。

また、PHPには「PSR / PER」というcoding style guideが文書化されていますが、prettier/plugin-phpはこれに完全に準拠するものではないというスタンスが明記されています。
このようなopinionatedな実装などについてもまとめられれば良いと考えています。
https://github.com/prettier/plugin-php/blob/0c883a49850281077218007322f6149f853b2015/README.md?L39

普段は意識しないであろうCode Formatの裏側に興味を持っていただくきっかけになれば嬉しいです。

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

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

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

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

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

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

本トークでは、経営学のノウハウをいくつか取り上げ、エンジニアの実務でどう活かせるか、具体的なシーンとともに紹介します。

私はCTOになったことをきっかけに、約1年前からMBA（経営学修士）プログラムで学んでいます。
現在はCTOを退任しましたが、今も続けています。
単純に「便利だ」と実感しているからです。

学んでみて気づいたのは、エンジニアリングと経営学のアプローチが似ているということでした。
問題を構造化し、制約の中で最適解を探し、仮説を立てて検証する。
フレームワークで思考を整理し、他者と共有可能にする。
違いは明確な答えがあるかないかです。
エンジニアにとって経営学は馴染みやすく、実務へ接続も難しくありません。

具体的な効果を挙げると、たとえば経営会議では、なぜ経営陣がそのような判断をするのか、その思考プロセスを理解できるようになりました。
また、メンバーとの1on1やメンバーが上程する際のフォローも理論を背景にして行えます。
よりエンジニアリングの文脈であれば、ドメイン駆動設計のサブドメイン等に対する解像度、技術的負債の返済優先度、イノベーションの進め方などのエンジニアリングの判断にもビジネス視点が自然と入るようになりました。
私個人の話でいえば、クリティカルシンキングやファシリテーション、ネゴシエーション等の知識は、レビュー、設計議論、ステークホルダーとの調整等、さまざまな場面に直結するスキルで、もっと早く知りたかったと感じています。

トークの中で紹介するノウハウは、MBAプログラムに通わずとも関連書物を紐解けば習得・活用できるものです。
エンジニアと経営学、その共通点から学びやすさを、そして活用法から相性のよさを感じていただき、皆様のキャリアを広げる新たな要素にしていただけることを目指します。

OAuthやOpenID Connectは、現代のWebアプリケーションで重要な役割を果たしていますが、これらの概念はしばしば誤解されがちです。
本セッションでは、これらの技術の基礎をしっかりと理解し、Laravelでの実装を通じて実践的な知識を得ることを目指します。
・OAuthとは
・OpenID Connectとは
・Laravelでの実装例

「これ以上触らない」ことが決まっているレガシーシステムを、どう安全に未来につなげますか？

PHP5.6で動くレガシーシステム。詳しい人はもういない。新規開発の停止が決定してから3年が経過しているが、毎月しっかりと売上を生んでいる。そんなシステムのPHP8.3へのジャンプアップを、最小限の工数で安全に実現した戦略の解説です。

新規開発を停止している以上、「リファクタリングしてから」「テストを書いてから」と時間をかけることはできません。システムの詳細を理解している人がいない以上、少しでもリスクのある修正は取り入れられません。このような強い制約の下での現実的バージョンアップ戦略を共有します。理解度の低いシステムに対するPHPバージョンアップへの不安を解消し、具体的な対策を持ち帰っていただける内容です。

対象

• なかなか手をつけられないレガシーなプロダクトを抱えている方
• アプリケーションのPHPバージョンアップで苦戦している方
• auroloadなど「PHPの仕組みの部分」を実践的に活用したい方

話すこと

新規開発はしない、現状維持できれば問題ないお金を稼いでる以上、いつまで使われ続けるかわからない
こう言った状況で力を入れすぎず、楽かつ安全にバージョンを上げる実践例を紹介します。

学べること

• AIのバージョンアップ作業での活用
• ワンコードでバージョンアップする戦略
• テストを書かずに安全を確保する戦略
• 段階的移行でリスクを最小化する戦略

内容

• AIでバージョンアップの影響を調査させる工夫
• 同じコードでPHP5.6と8.3の両方を動かす方法
• ミラーリングサーバーとアクセスログリプレイで実トラフィック検証
• エンドポイント単位の段階的移行(path-based routing)

Observabilityにおけるアプリケーションのパフォーマンス監視において、APM（Application Performance Monitoring）は不可欠な存在です。
しかし、これらのツールが「内部でどのように動作しているか?」を理解している開発者は多くありません。

本セッションでは、OpenTelemetry PHP SDKを使用して、シンプルなAPMツールをゼロから自作します。
トレース、メトリクス、ログの3つのシグナルを収集・可視化する過程を通じて、APMの仕組みとOpenTelemetryの設計思想を深く理解することを目指します。商用のAPMツールを「なんとなく使っている」状態から、「仕組みを理解して使いこなす」状態へステップアップしていきましょう!

【セッションの対象者】
・APMを使っているが仕組みを理解したいエンジニア
・Observabilityに興味があるエンジニア

【このセッションで得られること】
APMが内部で何をしているか?の理解
OpenTelemetry SDKの活用方法について

Laravelアプリケーションの運用において、エラー調査にどれくらいの時間を費やしていますか？ 「ログ検索（Kibana等）をしているが、POSTパラメータが欠落していて再現できない」「スタックトレースだけでは原因が特定できない」——かつての弊社もこのような課題を抱え、調査に数時間を費やすことも珍しくありませんでした。

本トークでは、Sentryを導入していない、あるいは基本機能のみ利用している方に向けて、エラー対応の効率化からパフォーマンス改善までの一連の流れをお話しします。

前半では、Sentry導入による劇的な開発体験の変化を紹介します。 リクエスト時のパラメータや実行環境などの豊富なコンテキスト情報の記録、そして類似のエラーを自動でまとめる「インテリジェントなグルーピング」機能により、Slack通知のノイズを大幅に削減。以前は困難だったエラー原因の特定が数分で完了するようになった経緯と実績をお伝えします。

この「守りの効率化」を踏まえた上で、後半は「Laravel Insights」を活用した「攻めのアプリ解析」について詳しく見ていきます。 ここでは、ループ内で過剰にDBクエリを発行してしまう「N+1問題」の検知や、遅延しているHTTPリクエストの特定など、パフォーマンス低下の要因（ボトルネック）を可視化する方法を解説します。さらに、AIエージェントによる根本原因の推論機能を用いたデバッグフローも紹介します。

Sentryを導入し、「ログを探す時間」を「コードを直す時間」に変えましょう。チームの開発生産性を高めるための具体的な実践手法を持ち帰っていただければ幸いです。

プログラミング言語の処理系は複雑な処理を行っているように見えますが、個別に分解してみれば一つ一つの処理はそれほど難しくありません。
しかしながら、PHP 処理系のような実用的な言語の処理系は大規模かつ複雑であり、全体の構造を把握したり、どこから読んでいけばよいのか見定めたりするのには一定の事前知識が必要です。

ここでは、PHP 処理系のソースコードを魔改造して PHP 言語に独自の拡張を施すことで、日ごろ使っている PHP の処理系が内部的にどのような処理を行っているのかを追いかけてみましょう。

話すこと

• PHP のソースコードを改造し、関数の合成を行う独自の演算子を追加する
• 言語処理系がどのような処理を行っているのか、はじめからおわりまで一通りさらう
  • 字句解析
  • 構文解析
  • コンパイル
  • 実行

目的としないこと

• PHP に実用的な拡張をおこなうこと

「やべっ！テスト落ちた！！一旦Rerun！！！」
──みなさん、これ、やっていませんか？（特大ブーメラン）

通ればラッキー、通らなければ…まああとで考えるか、というアクションに陥りがちです。
このような"たまに落ちる"Flaky Testを放っておくと、じわじわとテスト全体の信頼性を失っていきます。

私自身、何度も同じ轍を踏んできましたが「そもそもそのようなテストを書かないようにする」勘所を掴んできました。
このトークでは、Flaky testになりそうな臭いのするテストの勘所、そして、そもそも生まないためのテストの書き方について話します。

話すこと

• PHPで遭遇しがちな Flaky Test の具体例と原因パターン
  • 不定順・日付またぎ・fakerの揺れ・CIとローカルの差異 など
• Flakyにならないテスト設計の指針
• Flaky Testを“そもそも生まない”ための開発プロセス・レビュー