プロポーザル

引数をメソッドに渡すか、 __construct に渡すか......
どちらも機能しますが、本当に “どちらでも良い” のでしょうか？
動くのは間違いないですが、より「使いやすく」「保守しやすい」コードを目指すなら、最適な注入方法を選ぶ必要があります。
そこで、わたしの考える判断基準を具体例のコードに落としつつ紹介していきます。

• クラス設計・依存関係の整理
• テストの書きやすさ
• コードの可読性

また、このような話で一緒に出てくるのが依存性注入（DI）です。
具体例とともにあることでふんわり理解からじっくり理解にもっていきましょう。

このトークでは、実際のコード例を交えつつ、コンストラクタ注入とメソッド注入それぞれの判断基準を明確にしながら、DIの仕組みも合わせて紹介していきます！

PHPUnit、毎日（？）使っていますよね。
直接コマンドを叩いたり、便利なツールを介して使っていたりするかもしれませんが、
その中身に目を向けたことはありますか？

まずは、PHPUnitを「ちいさく作ってみる」ことで、その仕組みをひも解きます。
最低限必要な機能は何か？「最小限のPHPUnit」を作って 実際に動かしながら デモを行います。

その後、実際のPHPUnitと見比べ、どこに拡張の余地があるのか、また拡張の余地をどのように設計しているのかという部分を整理していきます。
これらは、自分たちの作るシステムにおいても「拡張の余地」の嗅覚に役立てられるはずです。

「ちいさく作る」そして「じっくり理解する」ことで中身を想像する足掛かりにしていただければ嬉しいです。
テストフレームワークの奥深さを一緒に覗いてみましょう！

みなさんはPHPでWebSocketサーバーを実装する際にどんな方法で実装しますか？
PHPでWebSocketサーバー実装する場合、いろいろなライブラリやミドルウェアがあります。
このセッションでは次のWebSocketサーバーの実装を紹介します。

• Ratchet
• amphp
• workerman
• Roadrunner
• swoole

PHPでは本来不得意な非同期処理を用いるWebSocketを実現できる方法は様々あり、PHPの面白さを共有できればと思います。

皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか！？

チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。

その原因、実は「コンウェイの法則」にあったんです！

このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。

私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです！

みなさんはFour Keysでどのクラスタに属していますか？

Four KeysはDORA（DevOps Research and Assessment）が提唱している開発チームのパフォーマンス指標です。Four Keysではパフォーマンスに応じて、Elite・High・Medium・Lowの4つのクラスタのいずれかに分類されます。

サービス開発においてEliteクラスタに属していないと、ビジネス競争力が低下するリスクがあります。近年ではEliteクラスタに属した上で競争力を高めるためにさらなる取り組みをしていくのは一般的です。

私が所属する合同会社DMM.com 二次元コンテンツ事業が開発に携わっている二次元コンテンツ事業のPHP製ECサービスは現在「High」クラスタに位置しており、Eliteクラスタを目指してさまざまな取り組みを積極的に進めています。

本セッションでは、まだEliteクラスタに属していないチームが具体的にどのようなアプローチを取ればよいのか、実際の取り組み事例を交えてご紹介します。

アジェンダ（予定）：

• Four Keysとは
• なぜFour Keysを使うのか
• スループットと品質の相関
• ECサービスの現状と課題点
• Eliteクラスタへ移行するための取り組み
  • スループット改善への取り組み
  • 品質改善への取り組み
    • リファクタリングに向けた準備
      • FakerとTestcontainersを用いたモデルベーステスト
      • Qodanaを用いたPHPアプリケーションの静的解析

対象者：

• Four KeysのEliteクラスタ入りを目指す開発チームのリーダーやメンバー
• 開発チームのパフォーマンスを具体的に改善したい方

2025年はPHPが公開されてから30周年のようです。おめでたい年ですね。
私は15年以上Webアプリケーションエンジニアとして働いてきたのですが、
これまでPHPでコードを書く機会は経験はありませんでした。
そんな私ですが、PHPが30周年を迎えた今年、転職を機にPHPを使うことになりました。

私はマジメな性格なので、PHPを使うからには、しっかりと基礎を学びたいと思っていました。
そこで、まずはPHPの思想や基礎を学ぶために、PHP1.0から履修することにしました。

PHP1.0の環境を作るのはそれなりに大変でしたが、なんとか環境を用意し、公開当時のPHPをブラウザで表示することができました。
これにより、当時のPHPで実現されていたことや、思想、そして少しのC言語(？)を学ぶことができました。
このような充実感はありつつも、最近のPHPにつながる実務的な知識は身につかなかったので、まだまだ精進が必要です。
ただ、PHP1.0を動かすこと自体は面白い経験だったので、このカンファレンスを良い機会に、この経験をみなさんに共有したいと思いました。

本トークの内容や対象者については、以下のように考えています。

内容

• PHP1.0を実行する環境の作り方
• PHP1.0でのWebページを作り方
• Webページの表示イメージ

対象者

• PHP経験者(初級者〜上級者、レベルを問わないかと思います)
• PHP1.0を知らない方はどなたでも
• C言語の経験者(？？？)

深い話に踏み込むつもりは無く、気軽にどなたでもお聞きいただける内容にしたいと思っています。

PHP で今一番勢いのある Web アプリケーションフレームワークであるところの Laravel 、最近もマネージドサービスのローンチ、純正エディタ拡張機能の提供、静的解析への対応を進めるなど、様々な改善が進んでいます。

一方で思いがけないタイミングで互換性を損なう変更が入ることもあり、既存アプリケーションのアップグレード作業においては稀に罠を踏んでしまうことも...

今回は筆者が PHP にコントリビュートした領域である乱数 (ランダム) 周りにおいて、 Laravel 11 での "サイレント" な変更により、自ら罠にハマってしまった話と共に、プログラミングにおける "乱数" との付き合い方を今一度考えてみたいと思います。

「設計ドキュメントは必要か？」
開発現場でたびたび持ち上がるこの議論に、正解はあるのでしょうか。

ドキュメントが少ないことでスピードが出るチームもあれば、丁寧な設計が結果的に開発効率を高めるチームもあります。

複数の開発チームを経験する中、チームトポロジーを読んで「ドキュメントの最適なあり方は、チームの特性に依存する」という気づきを得ました。

本トークでは、以下の観点から「チームごとに適したドキュメント管理の考え方」について具体的にお話しします。

• ドキュメントの必要性に関するよくある議論
• チームが扱うドメインの種類
• チームタイプによるアプローチの違い
• 実際のチームで実践しているドキュメント管理方法

設計やチーム運営に関わるエンジニアにとって、明日からの開発をより良くするヒントを持ち帰っていただける内容を目指します。

「ちょっとWAFのブロックを追加したい」「S3のバケットを作りたい」──そんなとき、SREにチケットを出して数日待ち、という体験をしたことはありませんか？私たちの現場でも、PHPアプリエンジニアがインフラに手を出しづらく、SREに依頼が集中していました。その結果、SREは日々の対応に追われ、改善や新しい挑戦に手を出す余裕がなくなっていきました。

このセッションでは、私たちアプリケーションエンジニアがインフラ構築の裁量を広げることでどう現場を変えたかを紹介します。Terraformを使ったIaCのテンプレート化、GitHub Actionsを活用した安全なCI/CDパイプラインの構築、パススルーやWAF設定といったよくある変更の“自分でできる化”など、PHPエンジニアが安心してインフラに関われるようにした具体的な工夫をお話しします。

もともと私自身がPHPerからSREに仕事を広げたことから何に困り、どう整えてきたか。開発体験を良くするためにSREとアプリケーションエンジニアが整えるべき“やってよい設計”のヒントを、実際の試行錯誤や失敗談も交えてお届けします。

PHPの標準関数やクラスで絶対日時を扱う時に利用するのが、strtotime や DateTime(Immutable)です。
引数には、どんな値が使えましたっけ？

どうしても『おしゃれ』に書きたい！そんな時には、色々な指定方法を知っておくと有利です。
どうやって知ればいいでしょう？PHPのことはPHPに聞くのが1番簡単そうですよね。

PHPについての信頼できるソースとして、php-srcを訪ねてみましょう。
構文解析の定義ファイルを読むことで、利用可能な形式を把握できます。

どこにあるファイルを、どのように読むべきかを知り、実際に使える値(とその調べ方)を知るLTです。

PHPで利用できる例

※ 2025年5月3日に実行すると、全て同じ値になります

<?php
strtotime('today');
strtotime('midnight');
strtotime('noon - 12 hours');
strtotime('3 days ago 00:00:00 + 72 hour');
strtotime('Sat.');
strtotime('00:00:00');
strtotime('00:00');
strtotime('2025-05-03');
strtotime('05/03/25');
strtotime('2025-W18-6');
strtotime('2025.123');

部署20 × ロール4 × 「自分のデータだけ見せたい」。社内システムの厄介なアクセス要件に、Laravel アプリへ Casbin を組み込みながら挑んだ設計奮闘記です。ロール制御（RBAC）だけでは表現し切れない “所有者判定” を ABAC 的に補強しつつ、ポリシーマトリクス爆発を抑え、UI 工数を削減して MVP を最速リリースしたハイブリッド構成と実装ハックを 25 分で共有します。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Laravel の Gate／Policy では追いつかない複雑な権限制御に対し、オープンソースの Casbin を導入。しかしすぐに「ポリシー膨張」「継承の採用判断」「Eloquent 直渡しによる性能不確実性」という 3 つの壁にぶつかりました。試行錯誤の末にたどり着いたのが、RBAC ベースに ABAC 的“所有者判定”をアプリ層で補完するハイブリッド構成です。

本セッションでは、以下を具体コード付きで解説します。

・ 要件整理とモデル選定プロセス——ロールだけを捨てた決断
・ 落とし穴 Top3 と対処法
　・ ポリシー爆発：ドメイン分割＋ワイルドカードでポリシー圧縮、CSV→PHPUnit 自動生成テストも紹介
　・ 継承 (g) の採用判断：メリット・デメリットと PJ が不採用にした理由
　・ Eloquent 直渡し問題：N+1 回避のアプリ層 if 判定
・ ベンチ設計：middleware vs model‑level、QPS 実測のコツ
・ UI 後回しで MVP 切り出し——工数を半減させる分割術

権限管理に頭を悩ませている方、これから設計を任される方へ、実戦で使える指針と突破口をお届けします。

型定義が不完全、変更の副作用も予想しきれない、リファクタしたいけどリスクが読めない――そんなレガシーなPHPモノリスと日々向き合う中で、私たちのチームでは本番環境でユーザーに影響なく検証ができる「シャドーテスト」というお作法を実践しています。

このLTでは、

本番と同じリクエスト・入力を使って新旧ロジックを同時に実行し、
結果の差分を検証する
というアプローチを紹介します。

「テストコードは書きづらい」「型がないから静的検証も弱い」そんな環境でも、実行して確かめることで安全にリファクタや置き換えが進められます。実際にどのように組み込んでいるか、実施してどういうところが良かったか、5分でさくっと共有します。

レガシーPHPと戦う皆さんの一助になれば幸いです！

私が担当しているメール共有サービスのメールディーラーではE2Eテストを導入することで、一定以上の品質を担保することに成功しました。

E2Eテストを導入したことの効果やテストコードの実装やテストケースの作成で工夫しているポイントなど、
メールディーラーのテクニカルリーダである私が可能な限り具体的に事例をもって説明いたします。

メールディーラーは2001年にローンチしましたが、フレームワークを導入しておらず、
DBアクセスとHTMLの生成をひとつのプログラムで行っています。

内部構造のアーキテクチャもさることながら、プログラム構造の陳腐化がリリースを行うごとに進みました。
いわゆる「スパゲッティコード」が散在し、それらがサービスの品質にまで影響するようになりました。

具体的には、ある共通関数が別の共通関数を呼び出し、
それが繰り返されることでプログラムが複雑にネスト化しています。

その結果、コード全体の把握が難しくなり、修正前に十分な影響調査ができない状況が生まれました。
このような状況下で、思ってもみない機能に不具合が混入し、
新機能のリリース直後に改修していないはずの機能で「画面が表示できなくなる」といった致命的な障害が発生しました。

そこで対策としてE2Eテストの導入と自動化を行いました。

通常の開発と並行して約3ヶ月という期間で273画面に対してテストコードを実装し、
導入後は「画面が表示できなくなる」といった致命的な不具合の発生を防止することができました。

限られた期間とリソースでどのようにして、当初の目標通りの成果を出すことができたか？をご説明いたします。
本セッションを通じてE2Eテストの導入や品質担保の参考になれば幸いです。

私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。

「AIクレーム検知オプション」の開発に当たり、メールディーラーの史上初となるβ版をコンテナで構築して、
お客様に実証実験ご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減やパフォーマンスの分散化を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
将来的なアーキテクチャの構想も含めて、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例を交えて説明いたします。

AWSやコンテナは新しい技術ではありませんが、2001年にローンチしたメールディーラーにとっては違います。
メールディーラーは全機能がひとつのサーバに実装されており、WebサーバとDBですらひとつのサーバに集約されています。
また、フレームワークを導入しておらず、DBアクセスからprint文によるHTML出力が、1つのPHPファイルに実装され、
プログラムの陳腐化が急速に進んでいます。

その一方で市場開拓の必要性から新機能を定期的にリリースすることが求められています。
さらにLLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、
LLMを「導入していることがメリット」だったのが「導入していないことがデメリット」に変わりつつあります。

AIブームを背景に、ChatGPTを活用したクレーム検知機能をAWS上で構築し、無事リリースに至りました。
本セッションを通じて、新しい試みを試す参考になれば幸いです。

プログラミングはテキストの海。書けても読めない単語は意外と多く、チーム内でも呼び方がまちまち──そんなモヤモヤはありませんか？
もうこの場で決めてしまいましょう。明日からは自信を持って口に出せますよ。

対象者
PHP に限らず、コードの読み上げや口頭レビューで「あれ、どう読むんだっけ？」と一度でも戸惑ったことのある開発者すべて。

「クリーンアーキテクチャ」というものがやりたいのではない。クリーンなアーキテクチャをつくりたいのだ。
そんな思いから、このセッションは始まります。

丁寧につくりあげた設計の理念が、納期・チーム事情・歴史的経緯を前にして思いどおりに適用できないことは珍しくありません。

本セッションでは、特定の設計流派にとらわれることなく、万能レイヤー構成を追い求めるのでもなく「現場で選び取るための判断軸」にフォーカスします。

• どこまで追い求め、どこで割り切るかの基準
• チーム負荷を増やさずに設計方針を整理する考え方
• 現場の文化を壊すことなく改善を提案し、合意を得るための工夫

完成形の図面ではなく、変化し続けるプロダクトと向き合うための「ゆるい設計術」を提案します。

想定対象者: 中規模 PHP プロダクトで設計・リファクタリングに関わるエンジニア

PHP コードの正当性は、テストや静的解析によって保証するのが一般的です。

しかし実際には「このメソッド呼び出しが正しいことは、どのテストで保証されていたっけ？」と確認を要する場面や、静的解析ではカバーしきれないコード構造も現実には多く、必ずしも安心とは限りません。

このセッションでは、コード自身が自分のやろうとしていることの正当性をその場で保証する "Self-Validating Code" というアプローチを紹介します。

テストや静的解析を補完し「この処理は確かに正しい」とコードの内側で完結して確認できる仕組みが、開発体験をどう変えるかに注目してみましょう。

Laravel アプリケーションに導入した具体例をもとに「正当性の保証がコードの外部に散らばっている」煩雑さをどう減らせるか、それが Fail Fast や防御的プログラミングとどう違うのかも整理してお話しします。

書いたその場で、正しさを信じられる。そんなコードを書くためのヒントをお届けするセッションです。

スナップショットテストは、複雑な出力の変化を検知するための便利な手法で、主にフロントエンド領域で発展してきました。近年では PHP においても導入されるケースが増えてきました。

しかし、テストの削除やリネーム、アサーションの回数の変化などにより、使われなくなったスナップショットファイルがリポジトリに残り続けてしまうという問題があります。これらの不要ファイルは徐々に蓄積し、リポジトリを散らかすだけでなく、レビュー時の混乱や誤認、さらには技術的負債や開発者のミスの温床となる可能性もあります。

この問題は長年にわたり認識されているにも関わらず、未だ決定的な解決策が存在しません。大規模なモノレポ環境で複数言語や複数スナップショットライブラリが併存し、独自のカスタマイズも加わっている状況では、汎用的な解法を構築するのは特に困難です。

この LT では、そうした課題に対し、使われなかったスナップショットを自動的に検出し、現実的でシンプルな解決策を提案します。

MCP（Model Context Protocol）の仕様が 2025/03/26 に更新され、MCP サーバをステートレスな HTTP サーバとして実装可能になりました。

そうなったら我々 PHPer のフィールドですね？

本トークでは MCP サーバの仕様を説明しながら、フレームワークも Composer さえも使わない、非常に小さな PHP 実装例を紹介します。

このトークで扱う内容

• MCP とは何か？
• MCP サーバの仕様
• Streamable HTTP Transport による MCP サーバの実装例

このトークで扱わない内容

LLM、生成 AI、 MCP といったものに関する

• 具体的な活用事例
• すぐに役に立つ知識

「パフォーマンス調査をしたら凄まじい数のクエリが発行されていた」という経験、ありませんか？
私自身、重いバッチの調査でRDSのPerformance Insightsを見てひっくり返ったことがあります。

これが有名な「N+1問題」ですが、バッチやCSV出力といった大きめのデータ処理で陥りやすい問題の代表例かと思います。
その一因として、Laravel標準のORMであるEloquentでは、リレーション取得をループすることで意図せず大量のクエリが発行されてしまうことが挙げられます。

一方で対策は比較的簡単で、withメソッドを使用してEagerロードさせることで、リレーションデータも1回のクエリで取得することができます。
しかし、安易に「親データの取得時にwithメソッドを呼び出せば解決」と考えていると、思わぬ罠に嵌まる可能性があります。

本LTでは私の失敗を出発点として、Eagerロードさせる上での注意点からEloquentのリレーションの仕組みまでお話しします。

トピック

• N+1問題とEagerロード
• 動的プロパティ（$user->posts）とリレーションメソッド（$user->posts()）