トーク

PHPのsocket拡張を利用するとsocketプログラミングができ、通信プロトコルもPHPで実装できます。
さらに、RAW socketという機能を使うとTCP/IPプロトコルもPHPで実装可能です。

今回のセッションでは、

• PHPのsocketプログラミングの基本
• TCPプロトコルの実装
• IPプロトコルの実装
• tcpdump, netstatによるデバッグ
  の話を通して、はまりポイントやプロトコル実装の楽しさを共有したいと思います。

プロトコルは仕様が決まっていて、その仕様を見てひたすら実装し、最終的にはサーバやクライアントと通信できるようになります。この通信できた時の喜びは非常に大きく、かつ大変勉強になります。通信できるまでの過程も含めて楽しさが伝えられたらと思います。

概要

Laravel開発でおなじみのコレクション操作、その裏側に潜む「yield」の力を最大限に引き出すのがLazyCollectionです。

本トークでは、PHPのyield構文の動作原理を紐解きつつ、なぜLazyCollectionが高速でメモリ効率が良いのか、Collectionとの違いについて内部の仕組みを追いながら丁寧に解説します。
また、実際に現場で使われているユースケースやテクニックについても紹介します。

ターゲット

• 大規模なデータを扱っている人
• ライブラリや処理系の実装から理解をしたい人

私のマネジメントする開発チームでは、GitHub Agentを活用した開発フローを取り入れており、今では「なくてはならない戦力」として定着しています。

とはいえ、導入当初からうまく活用できていたわけではありません。
「AIに任せたが期待通りのアウトプットは出なかった」などを中心に、いくつか悩みもありました。

本トークでは、実際の現場で行ってきた試行錯誤のプロセスをもとに、エージェントAIとの「共進化」の過程を振り返ります。
再現性のあるTipsを重視しつつ、以下のような観点から、「開発にAIを溶け込ませるために必要な視点」について掘り下げていきます。
・エージェントAIを活用する際の基本的な姿勢
・導入初期にまず取り組むべきこと
・開発業務で効果的に使うための準備と工夫
・開発以外の周辺業務での活用事例（例：PRレビュー補助、ドキュメントやSQL作成）

「とりあえず使ってみた」から一歩進み、エージェントAIをツールとして活用するには何が必要か？
そのリアルな知見と、成功も失敗も含めた経験談をお届けします。

純粋関数(pure function)という言葉を聞いたことはありますか？ 簡単にいうと、同じ引数を渡せば必ず同じ結果を返す関数のことで、「数学的な関数」と説明されることもあります。

同じ引数で同じ結果ということは『確実な再現性がある』ということで、「純粋」の概念を知って純粋と不純な処理を切り分けられれば、コードを見通しよく、テストしやすいコードにすることもできます。

いくつかの静的解析ツールとIDEは純粋性について分析を提供しており、意味のない純粋関数の呼び出しについて警告を与えてくれます。
これと関連して、PHP 8.5向けには #[NoDiscard] というattributeも追加され、戻り値を処理する必要がある実装をマークすることもできます。

では、既存実装をPureあるいはNoDiscardに明解に分類できるかというと… 現実には一筋縄にはいかない、さまざまな考慮事項があります。

本トークでは「純粋」および「副作用」という概念、そしてそれらをとりまく周辺事情についてお話しします。

PHPではtry-catchによる例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか？
過剰なエラーハンドリングや、catchしたけれど何もしていない“握りつぶし”が積み重なると、責任の所在が曖昧になり、コードの見通しや保守性にも悪影響を及ぼします。

こうした課題へのヒントとして、Rustなどの言語で採用されているResult型の考え方を、PHPに応用するアプローチがあります。
Result型は、失敗を型として明示的に扱い、成功も失敗も返り値で表現する設計手法です。
これにより、「どこで何が失敗しうるか」「どこまでが関数の責務か」がコードから読み取れるようになり、処理の流れや責任が明快になります。

本トークでは、Result型によるエラーの設計方法や、例外との使い分けについて、以下の観点から実装例を交えて解説します：

• エラーの分類と責務の整理
• 例外との使い分け
• PHPでResult型を実装する方法

Result型を導入するかどうかに関わらず、エラーをどう設計するかを見直すヒントとして、この考え方を持ち帰っていただけると嬉しいです！

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

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

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

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

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

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

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

あと1年でデータ件数10億件間近…そうなればテーブル変更したくても怖くて触れない…！

そんな状況から始まった打刻テーブル移行の軌跡を語ります。（DBはMySQLです）
・ パーティションテーブル移行と影響調査
・ 更新・参照効率に合わせたテーブル分割
・ 更新パラメータ追加に伴うログ検証
・ 参照切り替えのシャドーテスト的アプローチ
・ 重複データとの戦い、そしてユニークキーの採用
・ βリリースを活用した影響調査

大規模リリースを避け、スモールステップで内側のテーブルをすげ替える試みの具体的な方法についてお話しします。
本セッションがみなさまのシステム改善やレガシーシステムの移行の一助になれば幸いです。

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

本セッションでは、PHPでBDDを始めるための基本的な考え方と実践方法を紹介します。Behatなどのツールを用いることで、自然言語に近い形式で振る舞いを定義し、テストの読みやすさや保守性を高めることが可能です。また、BDDを導入することで、開発者とQAのあいだで仕様の意図や期待される挙動を共有しやすくなるといったメリットにも触れます。

PHPでテストを書いて、プロジェクトに無理なく導入できるBDDの第一歩を、これから始めたい方に向けてわかりやすく解説します。

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

• Ratchet
• amphp
• workerman
• Roadrunner
• swoole

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

私は主にPHPを書いてきたエンジニアですが、業務でGoを触る機会が増えています。
その中で、最も大きな衝撃を受け、書く上で一番苦労したのが「インターフェイス」の実装方法と思想の違いでした。
（PHPでimplementsに慣れた私にとって、Goの暗黙的に満たすインターフェイスは衝撃的でした）

このセッションでは、私なりの理解を基に、PHPとGoのインターフェイスの仕組みを比較しながら、それぞれの思想、メリット・デメリットをサンプルコードを交えて解説します。
PHPエンジニアがGoを書く上で躓くであろう最初のハードルを乗り越えるきっかけをお届けします。

PHPエンジニアでGoも書いてみたいなと思っている方、PHPとGoのインターフェイスの違いに興味がある方におすすめです!

話すこと

• 明示的な実装（PHP）と暗黙的な実装（Go）の違い
• PHPとGoそれぞれのコード例を交えた実装方法の解説
• PHPとGoのインターフェイスの置き場所の違い
  • 例）RepositoryのインターフェイスはPHPではDomain層、Goでは実装近くに置きがちなのはなぜか、など

話さないこと

• PHPとGoの基本的な文法
• PHPとGoの深い設計思想

部署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プロジェクトで、知らず知らずのうちに技術的負債が溜まっていませんか？機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、オブジェクト指向設計の基礎である SOLID 原則への理解不足や誤解にあるかもしれません。

SOLID 原則はソフトウェア開発において高品質で保守性の高いコードを書くための重要なガイドラインですが、やたら難しい言葉が並んでいるせいで理解が難しかったり、誤解が広まってしまっている面があります。

本トークでは、SOLID 原則に含まれる5つの原則について、アンチパターンやPHP での実践的な例を交えながら解説し、その活用方法や得られるメリットについてお話しします。このトークを聞けば、あなたはSOLID原則を「開発を楽にする武器」として捉えられるようになり、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

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

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則、聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていない人
• SOLID 原則、理解しているけどどこまでやればいいのか悩んでいる人

「PHPってWebサーバー上で動くもの」——そんな常識をNativePHPは打ち破ります。
2025 年 4 月に正式リリースされた NativePHP for desktop について解説していきます。

Electron やTauri のようなクロスプラットフォームなデスクトップアプリが主流になる中、
私たちが普段使っている PHP でも実現できる時代が来ました。

NativePHP を使えば、PHP でデスクトップアプリが作れちゃうらしい！
そんな知らせを聞いて、手を動かさない PHPer はいない！
実際にデスクトップアプリを作成して、見えてきた魅力や気づき、課題について率直にお話しします。

Web の外へと飛び出した PHP の勇姿を、ぜひ見届けてください。
「PHP もまだまだやれる！」

CakePHPとGoで構築された社内ユーザー向けシステムのデータベースをMySQL5.6から8.4へアップグレードしました。
その旅路は非常に困難で苦難の連続でした。

このトークではMySQLのバージョンによる仕様的な話は多くは語りません。
代わりに、下記の点をお話します。
・なぜMySQL5.6から8.4へアップグレードしたのか
・リスク最小化のための方針
・対応した内容
・アップグレード当日の対応手順と失敗時の手順

社内向けとはいえ、基本的にはデータベースを止めることができない中でどう検証し、何が大変だったかをご紹介します。

「なぜこの設計になったのか？」「複雑な判断の根拠を説明できない...」「チームの知恵が個人に閉じ込められている...」
チームでこんな課題を感じていませんか？複雑化するシステム開発において、特定の個人に依存した知識管理ではなく、チーム全体の「知」を育み、新たな知識を創造することが成功の鍵です。

個人に知識が集中すると、その人の離職で暗黙知が失われ、プロジェクトが停滞するリスクがあります。また、複雑で不確実性の高い開発では、個人判断では視野が限られ、想定外の事態へのリカバリーも困難です。個人の暗黙知をチーム全体の知恵に昇華させる仕組みが求められています。

本セッションでは以下をお伝えします：

1. SECIモデルとは？知識創造の4つのプロセス
2. モブワークがSECIモデルを加速させる仕組み
3. 各プロセスを促進するモブワークプラクティス
4. 知識創造するチームへの変革事例

SECIモデルの「共同化」「表出化」「連結化」「内面化」という知識創造の4プロセスを、モブワークは自然な形で促進します。暗黙知の共有から始まるこのサイクルは、モブワークで驚くほど加速します。

これにより「部族記憶」や共通文脈が生まれ、背景情報の共有だけでなく、チームの知的相互作用から新しいアイデアや知見が生まれる土壌が形成されます。個人では到達できない創造的飛躍が、多様な視点の交わりから実現できると登壇者は考えています。

PHP 8.4「プロパティフック」からオブジェクト指向設計を紐解きます。

プロパティフックとは、プロパティの読み書きに任意の処理を挟み込む機能です。従来の退屈なgetter/setterメソッドを使うことなく、より自然かつ柔軟な記述でプロパティの読み書きを実装できます。初めて使う際の学習コストも低く、手軽に導入できる点も魅力です。

一方、少し複雑な使い方や他の機能と組み合わせた使い方をしようとすると、型に関する制限や思わぬ仕様の違いに戸惑うことがあります。コンストラクタプロモーションとsetフックでの型の違い、readonlyとの併用不可、継承時の制限、これらは経験者でも混乱を招きがちです。

こうした仕様の背後には、オブジェクト指向設計の基本原則のひとつである「リスコフの置換原則（LSP）」が存在します。LSPは一見すると開発を窮屈にする制約のように感じるかもしれません。しかし、実はその制約が、アプリケーションの一貫性や信頼性を守るための重要な役割を果たしています。

本トークでは、プロパティフックの構文と振る舞いを整理しながら、なぜそのような制約が必要なのかを丁寧に紐解いていきます。また、LSPの考え方はオブジェクト指向の設計にとどまらず、より広い領域でも応用可能な「設計上のものの見方」であることにも触れていきます。

PHPの最新機能をきっかけに、日々の開発でも見落とされがちな設計原則の価値を改めて見直しましょう。

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

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

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

プログラミング技術はこの長い歴史の中、Webではいろんな業種のナレッジが共有をされてきました。その中の一つに「共通化」を行い、「車輪の再開発をやめる」や「認知負荷を下げる」といったこと目的で取り組みするのをいたるところで聞きます。

ただし、「共通化」をすることで数年後に見るも無残な姿となり、逆にプロダクトの成長を抑制してしまったり、認知負荷を上げてしまうことがよくあります。

今回筆者が考える、プログラミングで考えるべき「共通化」の考えを中心に、過去経験したアンチパターンを元に話ができればと思います。

対象の聴講者は下記となります。

・プログラミング初心者
・悪い「共通化」がいたるところで見えるけど、どう伝えようか悩んでいる人
・失敗談を聞きたい人

本トークでは、チームの協働によって生み出されたイベントストーミング図を実際の動作するコードへと変換する手法を紹介します。

イベントストーミングとは、ドメインイベントを中心に据えたワークショップ形式のモデリング手法で、付箋やポストイットを使って、ビジネスプロセスの流れを視覚的に表現していくものです。
ドメイン駆動設計の原則に基づいたシステム開発を実現する上で、開発者とドメインエキスパートの協働を支える効果的な手法として注目されています。

これまで、イベントストーミングのワークショップを行うことで、ビジネスプロセスの理解を深め、チーム間の認識を統一するといったことは成功させてきました。
しかしながら、その成果物を具体的なソフトウェア実装へ昇華させる段階でつまづくことがあります。

そこで、このトークではイベントストーミングで可視化された知識の宝庫を、どのように実装へ導くのかということをテーマに、具体的なアプローチを解説します。
ビジネスドメインの本質を損なうことなく、いかにモデルをコードに落とし込むか、そのプロセスと実践的なテクニックを共有していきます。
また想定コードは先進的なアーキテクチャでなく、一般的な Web サービスを想定としたコードとします。

理論と実装の間に存在するギャップを埋め、モデル図をコードへ落とし込む方法論を学びたい開発者、設計者、プロジェクトリーダーにとって価値ある内容となっています。

◆お話しすること
・イベントストーミング図からPHPコードへの変換手法
・イベントストーミング図を構成する要素の簡単な説明
・ドメインモデルのコード表現
◆話さないこと
・イベントストーミングワークショップの具体的な進め方
・ファシリテーション手法