あなたの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

PHP 8.5で導入されたパイプ演算子（|>）、もう使っているでしょうか？

パイプ演算子を使うと、
strtoupper('hello')
と
'hello' |> strtoupper(...)
が同じ意味になります。

実は、例にあげた2つの式は、opcodeとしても同一です。

このトークでは、php-srcのソースコードを読み解きながら、パイプ演算子がどのように実装されているかを見ていきます。

具体的には以下の内容を扱います

• vldでのopcodeの比較
• opcodeのコンパイルに使われるzend_astとznode
• パイプ演算子を処理するzend_compile_pipe

PHPの新機能を通じてphp-srcに入門してみましょう

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コードやアーキテクチャ図とともにお話しします。

OSS活動していますか？

多くの人は色々と理由があって活動されていないんじゃないかと考えられます。

• 使ったことあるけど、不便だと思ったことがない
• OSS、どうやって参加すればいいのかわからない
• OSS活動ってめっちゃ出来る人がやっているイメージがあって自分がやっていいとは思えない……

当然、これらの意見はとても共感し、尊重されることでしょう。
これまでの世界であれば……。

AI時代に突入した昨今から、実はOSS活動の参入障壁は最も低くなったのではないかと考えています。
そこで、みなさまにＯＳＳ活動に気軽に参加するためのAI活用方法をお話していきます。

アジェンダ

• OSS活動をするにあたって
• OSS活動その1 - ソースコードを洗い出す
• OSS活動その2 - 過去のプルリクを追ってみる
• OSS活動その3 - 直せそう or 追加したい処理を作ってみよう
• OSS活動その4 - ディスカッションしてみよう（チャンス待ち）
• 実際にやってみた（実例）

このセッションで伝えていきたいこと

OSSは怖くないし、もっと気軽にコントリビューターになれますよ！
「実務以外での経験を積みたいなら」の一つの事例として知ってもらえればと思います

普段使用している 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の裏側に興味を持っていただくきっかけになれば嬉しいです。

本トークはPHPカンファレンス名古屋2025で発表した「PHPのバージョンアップ時にも役立ったAST」の最新版です。

関心を持ち続けながら勉強会に参加していると、ふとしたことがきっかけでさまざまな情報がつながり、点から線そして面に変わり、勉強会で学んだ情報が業務に役立つことがあります。

勉強会でプログラムの構造をツリー状に表現したAST（抽象構文木）のハッシュ値が同じであればプログラムの変更前と変更後の間に差分がないと判断できるという発表を聞いたことがきっかけで、実際のプロダクト開発においてPHP 8.1からPHP 8.2にバージョンアップする作業の一部をスムーズに進められることに気づき、結果として大幅にテスト工数を削減できました。

このトークでは、ASTを取得およびそのハッシュ値を比較する方法やハッシュ値の確認時に留意する点を解説しつつ、ソースコードの解析や変換に活用できるASTがPHPのバージョンアップ時にも役立った事例を紹介します。さらに、業務で活用できるASTを使った影響範囲調査の応用例や、PHP 8.4からPHP 8.5にバージョンアップする際にASTが変わらないケースも今回新たに紹介します。

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

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

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

想定聴講者

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

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

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

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

仕事において「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を“そもそも生まない”ための開発プロセス・レビュー

近年、量子コンピュータの実用化に向けた開発が急速に進展しています。
その一方で、量子コンピュータの進化はRSAや楕円曲線暗号といった公開鍵暗号技術の危殆化を意味します。

これに対抗する技術が「耐量子計算機暗号（Post-Quantum Cryptography: PQC）」です。

2024年8月、NIST（米国国立標準技術研究所）は長年の選定プロジェクトを経て、PQCの最初の標準規格（FIPS 203, 204, 205）を正式に発表しました。日本国内でも政府機関が2035年への移行目標を掲げるなど、PQCは実装・運用のフェーズへと大きくシフトしています。

本セッションでは、PQCの基礎知識から、その中心技術である「格子暗号」の仕組みや特徴にフォーカスして解説します。 さらに、AWS、Google Cloud、Azureといった主要クラウドベンダーの対応状況や、PHPエコシステムにおけるPQCの対応状況についても取り上げます。

今すぐにコードを書き換える必要はないですが、PQCは近い将来には当たり前となる技術です。このトークをきっかけに興味を持ってもらえれば幸いです。

【トークのアジェンダ】
・PQCの現状
　　・量子コンピュータの脅威（ショアのアルゴリズム）とHNDL攻撃（Harvest Now, Decrypt Later）のリスク
　　・NIST標準化（FIPS 203, 204, 205）について
・PQC（とくに格子暗号）の特徴について
　　・主要なPQCの紹介（格子暗号、同種写像暗号、符号ベース暗号、多変数多項式暗号、暗号学的ハッシュ関数）
　　・格子暗号の簡単な仕組みや特徴
・各クラウドベンダーやPHPでの対応状況
　　・AWS、Microsoft Azure、Google Cloud の状況
　　・PHP での検討状況