本講演は2016年から続けている「PHPで堅牢なコードを書く」シリーズの最新版です。

PHPはバージョンを追う毎に機能が強化され、堅牢なコードを書くための機能が充実してきました。本講演ではPHP 8.4（および 8.5）をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。

参考:
PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計
https://speakerdeck.com/twada/php-conference-2016

予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント
https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022

PHPが登場して30年、さまざまな言語が現れてはWeb開発に新たな可能性が開かれてきました。
新しい言語やフレームワークにはPHPが実現したものを取り込んだもの、野心的なパラダイムを打ち出したものも多くありますが、しぶとくもPHPを完全に置き換えるには至っていません。

本トークでは歴史と多言語での実装事例を踏まえてPHPとWebの過去と現在の立ち位置を再確認して、未来の姿を占います。

• 前PHP時代 〜 Rasmusは何を革命したのか
• Webフレームワークの中世期断絶
• PHPが往かなかったWebフレームワークの世界線 〜 普通の奴らの上を行け
• 非同期I/OとWeb 〜 PHP最大の弱点と次世代への夢

概要

従来のPHP環境でリアルタイム通知を実装する場合、Node.js等を組み合わせた複雑なインフラ構成は悩みの種でした。
FrankenPHPではこの課題を解決するためにMercureが内蔵されており、PHPスタック内でシンプルかつ高速なリアルタイム通信を実現しています。
本セッションでは、実際に動作するアプリケーションの動作デモを交えながら、以下の技術的なポイントを紹介します。

話すこと

• 従来構成での実現の難しさを再確認する
• FrankenPHPがリアルタイム通信を実現する流れの紹介
• WebSocketとServer-Sent Events(SSE) の技術概要と差異
• FrankenPHPを使ったリアルタイムWebアプリケーションの具体的な実装方法と実演

話さないこと

• Mercureの技術詳細

今や AI 全盛の時代。コーディングの多くを Coding Agent に任せることが一般的になってきました。私自身も、簡単なタスクであれば積極的に AI に頼っています。

しかし、AI も万能ではありません。指示が曖昧であれば、同じファイルに処理を詰め込みすぎてしまったり、結果としてコードの可読性やアプリケーションのパフォーマンスに悪影響を及ぼすこともあります。そのまま開発を進めてしまえば、後からの保守や拡張も難しくなってしまうことでしょう。

AI 時代の今こそ改めて「プログラミングの基礎」や「PHP の基礎」を理解することが重要です。本セッションでは、その土台となる知識を整理し、AI と協調して開発するための実践的な視点をお伝えします。

PHPの次期メジャーバージョンであるPHP 9.0に向けて、ライセンス変更の議論が進んでいることをご存知でしょうか？現在のPHP Licenseは、GNU General Public License（GPL）と互換性がなく、ソフトウェアの再配布時に制約が生じる状況になっています。将来、現在の独自ライセンスから、三条項BSDライセンスに移行されるかもしれません。

本トークは、OSSに関心のあるPHP開発者や、ライブラリ公開を検討しているエンジニアを主な対象としています。PHP Licenseの歴史や現在進行中の議論を紹介するとともに、OSSライセンスの基礎を初心者にも分かりやすく解説します。OSSライセンスの互換性にも触れながら、OSSにコントリビュートする場合や、自作ライブラリを公開する際に役立つ実践的な知識を紹介します。

私はdeckというMarkdownファイルからGoogle Slidesのプレゼンテーションを生成するツールを開発しています。
https://github.com/k1LoW/deck

Markdownからプレゼンテーションを生成もしくは実施するツールは既に数多くあります。
一見単純な機能ですが、後発のdeckは明確なコンセプトを持って開発をしています。

• 継続的なプレゼンテーション作成
• コンテンツとデザインの分離

なぜこのコンセプトに至ったのか、そしてそれをどのように設計・実装したのか。
本セッションでは、ゼロからv1リリースまでのdeckの設計と実装の変遷を追体験できるように構成します。
単なる一つのOSSの例ですが、小さなプロダクトが多くの人に受け入れられるようになるまでの設計と実装のログです。
皆さんが自身のプロダクト開発に役立つ気づきを得るきっかけになれば幸いです。

決済システムを長年運用してきた経験から得たTipsを語ります。
最大で1日約300億円の決済があるシステムを運用していました。
その決済負荷に対してどのような対応をしてきたかをお話しします。

ECのトレンドとして、以前はアリババのように1日単位でGMVを最大化していましたが、最近はユーザーの購買行動を分散させるために数日続けるキャンペーンが増えてきています。
システムを安定化させるためにはこのようにビジネス側の設計も必要になると思います。

現場で実際に効果があった施策を中心に以下についてお伝えします。
・データベース設計
・負荷テスト
・バッチ設計

教科書では学べない現場のTipsを決済・金融系のエンジニア向けにお届けします。

エラーが発生したとき、ログを追ったりデバッグを繰り返したりするのは大切な作業ですよね。でも、それだけだと「エラーが起きた後の対処」に留まってしまいます。もっと良い方法があるとしたら？

設計の段階から、エラーが「見つけやすい」仕組みや「そもそも起きにくい」コードの書き方を取り入れることで、システムの信頼性がグッと上がり、あとから困ることも減ります。

このセッションでは、例外の基本的な役割や考え方から始めて、PHPやJavaのように例外を持つ言語と、RustやGoのように例外を使わない言語のエラーハンドリングを比較。それぞれの特徴を活かした設計方法をお話します。難しい話だけでなく、「こうすれば実務で役立つ！」という具体例も紹介しますので、チームのディスカッションにもぜひ活用してください！

「DDDは難しい」と思っていませんか？実はコア業務の定義と依存関係の整理こそが成功の鍵です。

レセプト業務という複雑ドメインで法改正に挑んだ実体験から、「何をコア業務とするか」「何に依存させて何に依存させないか」という依存関係の設計がシステム全体の安定性をどう変えるかをお話しします。

コア業務を安定させた結果、以下の効果がありました。

• 開発プロセス全体が改善
• スキーマ駆動開発が自然に導入できる
• チーム間の調整コストが激減

依存関係の逆転によってスキーマ自体も安定化。その安定度を高める具体的施策も含めて、理論より実践重視で解説します。
3年に一度の大規模法改正に立ち向かった実話の例とともに、段階的にアーキテクチャを進化させていくための、現実的な道筋をお伝えします。

設計について話をすると、実に多くの「◯◯概念」「◯◯原則」が付いて回ります
あるいは、「良い設計を考えよう」とか「設計を学ぼう」とかして、多様な知識が必要で大変だ！と感じた事はありませんか？

全く逆のアプローチで
「たった1つの軸を決め、多くのことを説明できないか」と考えてみましょう
その拘りは、あなたの設計の地力の向上に繋がるはずです

今回は、その回答に 「フィードバック」に注目する という提案をします

フィードバックとは、何かを伝え、その反応を受信することであり、
関係性に意味をもたらすものとも言えます

この「フィードバック」という眼鏡を通じ、システムを覗き込むと？
──設計について多くを語る武器になり得ます
ソフトウェアにとどまらない、組織についても使える武器です
分割、配置、バランス、そこから生まれる相互影響について、
よりシンプルに思考し尽くせるようになるでしょう

AIエージェントがコードを生成する時代、エンジニアに求められるスキルは根本から変わりつつあります。
単なるコーディング速度ではAIに太刀打ちできない今、必要なのは「AIに正確で効果的な指示を出す力」。そしてその力の本質は、設計論という“共通言語”にあります。SOLID原則、デザインパターン、クリーンアーキテクチャなどの知識は、AI時代における最強の武器となるでしょう。
本セッションでは注目の「スペック駆動開発」にも触れながら、設計力がどのようにAI協働を支えるのか、実例を交えて掘り下げます。
今こそ、設計を学びなおす絶好のタイミングです！

現代のPHPフレームワークでは、Dependency Injection(DI)が標準機能として組み込まれ、その有用性は広く認知されています。
しかし、既存の動いているアプリケーションへ適用するにはどうすれば良いでしょうか？

本トークでは、実運用されているレガシーアプリケーションや、Ray Di for Laravel など、複数のDI適用事例を基に、実践的な戦略を共有します。
フレームワークとユーザーコードの境界線、既存のライフサイクルに配慮した依存性注入の活用、マーカーパターンによるルートオブジェクトの識別など、既存アプリケーション特有の課題と、その解決策を具体的なコード例と共に紹介します。

本トークを通じて、既存アプリケーションにDIを導入する際に考慮すべきポイントを持ち帰っていただき、明日から実践できる知見を提供します。