はじめに

昨年、私はPHPerKaigi 2025のコードゴルフ企画に初参加し、決勝後の“非公式コードゴルフ”で決勝問題に挑んでランキング入りするほど熱中しました。この原体験から「この熱量は社内でも再現できる」と考え、社内向けCodeGolfの内製と運営を開始しました。半年以上の継続運営で見えてきたのは、PHPコードを安全に評価する難しさや、継続参加を生む問題設計といった、本質的ながら意外に複雑な論点でした。
本セッションではどのように社内コードゴルフサービスを構築したか、半年間で実際に出した問題も全部例示しつつ、どう運営をしてどんな反応を得られたかについて話します。

PHP採点基盤で直面した課題

提出コードを隔離実行しつつ無限ループや負荷暴走を防ぎ、公平性を保つ必要がありますが、実際には、「どこまで自由に動かせるべきか」や「安全性をどう確保するか」といった複数の論点が絡み合いました。本セッションではこうした“考えるべきポイント”を整理して紹介します。

問題設計とAI活用で見えたこと

継続参加の鍵は「短く書ける余地」「適度な難易度」「5〜10分で試せる小粒さ」の両立でした。AIに大量生成させることで良い題材の基準が明確になり、PHPの仕様がゴルフ的おもしろさにどう寄与するかも見えてきました。これらを踏まえ、問題設計の観点を紹介します。

運営から得た学び

ランク制によるレベル差吸収、忙しい時期でも取り組める構成、技術的対話が自然に生まれる環境づくりなど、CodeGolfは遊びを超え、組織の技術文化を育てる取り組みになり得ると分かりました。

想定聴講者

• コード実行基盤・サンドボックス設計に関心のある方
• 技術企画や勉強会を推進するエンジニアの方
• AIを教材作成に活用したい方
• CodeGolfを学習文化として活用したい方

Symfonyは“フレームワークを作るためのフレームワーク”と呼ばれ、Laravelのコアにも採用されています。
そのため、初心者向けの導入説明や上級者向けの抽象概念を獲得するための解説などの知見を聞く機会が多くあります。

また、PHP 5.4で導入されたtrait(特性)も便利な仕組みである一方で、「知ってはいるが、どう活用していいか分からない」という人が多いのではないでしょうか。

本トークでは、Symfonyの拡張しやすい仕組みとtraitの相性に注目し、ストレージアクセスモデル、フォームバリデーション、ページ描画といった領域で、少ないコードで手軽に拡張・調整する実践例を紹介します。
また、trait導入によるインターフェース統一による不具合防止、Doctrineエンティティ、フォームバリデーションや描画の定義の一貫性や安全かつ手軽な変更を実現する方法についても解説します。
そして、これらの事例を足がかりに、traitパターンをアプリ全体に横展開することでチーム開発における安心感と長期運用に耐える拡張性を手軽に実現できることをお伝えします。

このトークで得られる知見

• Symfonyの設計思想に沿ったtraitの活用パターン
• モデルやフォームを少ないコードで手軽かつ安全に変化させる技法
• traitを「どんな場面で選ぶべきか」という実務的な判断基準

このトークの対象者

• Symfonyを日常的に利用している方、または興味を持っている方
• PHPでtraitを知ってはいるが、実務でどう活用すればよいか悩んでいる方
• Symfonyやtraitの活用を通じて、アプリケーション開発を効率化したい方

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

• Symfonyの基本的な使い方

OpenTelemetryプロジェクトはPHP向けにもゼロコード計装を提供しており、アプリケーションのコードを変更せずにトレースなどのシグナルを生成することができます。これにより、手軽にオブザーバビリティを導入することが可能です。しかし、これはPHP8.0以降でなければ動きません。

前半では、OpenTelemetryのゼロコード計装の仕組みを紹介し、なぜこれがPHP8.0以降でなければ動かないのかを明らかにします。具体的には、Zend Engineに新しく追加されたObserver APIの話をします。

後半では、それでもPHP7.4でもトレースを労力少なくOpenTelemetryで計装したい！というニーズにお応えして2つの手法を提案し比較します。すでに公開されているOpenTelemetry eBPF Instrumentationを使った手法と、PHP8向けのOpenTelemetryゼロコード計装のインタフェースに倣って私が自作したextensionを用いる手法です。後者についてはその実現方法や、生成AIを活用したextension実装の進め方についても紹介します。

本セッションを聞くことで、アプリケーションの内部状態を観測可能にするオブザーバビリティを実現する裏側の仕組みを知ることができます。また、すでにサポートが切れているPHP7系から8系にアップグレードしたい開発者が、アップグレードによって影響があるかどうかを知るために7系のうちから必要なオブザーバビリティを担保するための手法について知ることができます。

パフォーマンスチューニングはあらゆるWebアプリにおける重要な関心事です。クエリ最適化、計算量削減、キャッシュ活用など、その手法は多岐に渡ります。しかし、それらの多くは「特定の箇所」を速くするアプローチに留まります。

一方、Webアプリケーションには例外なく、すべてのリクエストに必ず登場する要素があります。—「接続」 です。

• ブラウザ → CDN
• CDN → ロードバランサ
• ロードバランサ → Webサーバ
• Webサーバ → アプリケーションプロキシ
• アプリケーション → データベース / キャッシュ / ストレージ / 外部API

HTTP、TCP、Unixソケット、DB、キャッシュ… 技術は異なっても、接続は必ず発生します。接続の最適化は、特定部位ではなく「全体」を速くする改善点 となり得ます。

本トークでは、

• エッジ最適化（CDN / Keep-Alive / 圧縮 / TLSハンドシェイク）
• Webサーバチューニング（コネクション管理、ソケット、プロセス管理）
• DB接続の最適化（持続接続、接続プール、TLS、パラメータ）

これら、全く別の話題に見える領域を横断し、そこに共通する 接続の基本原理 を解説します。設定例と計測手法を交えながら、点と点を結ぶ「その一瞬」を制する考え方を提示します。

局所最適化を超え、サービス全体のパフォーマンスを左右する「最後の一手」をその手中に。

想定対象者:

• Webアプリの性能をもう一段階引き上げたい、アプリケーションエンジニア
• アプリケーションの性能改善に取り組む、インフラエンジニア
• 「接続」という低レイヤに入門したい、あらゆるエンジニア

サイボウズの Garoon は PHP と MySQL を利用した大規模グループウェアです。
2002 年にパッケージ版の提供を開始し、2011 年からはクラウド版もリリース。
今ではパッケージ版とクラウド版を合わせて 300 万以上のユーザーが利用しています。
しかし、長年支えてきたクラウドの VM ベースの基盤は、運用やスケールの面で限界が見え始めていました。

Garoon チームは、2022 年に Kubernetes（k8s）を軸とした新しいクラウド基盤への移行プロジェクトをスタート。
足掛け4年、2025 年についに全面移行を実現しました。
本セッションでは、Garoon という“巨大に動き続けるレガシー”を、どうやってコンテナ基盤へ移行したのかをドキュメンタリー形式でお話しします。

• なぜ k8s への移行が必要だったのか（VM 運用の限界）
• PHP + Nginx アプリをコンテナ化するための設計判断
• 非同期ジョブシステムを安全に k8s へ移行するための工夫
• “基本は止まらない k8s” で、あえて停止メンテナンスを可能にした技術的アプローチ
• カナリアリリースによる安全でユーザーに気付かれない移行戦略
• 4 年にわたる長期プロジェクトを率いるためのマネジメントとチームづくり
• 移行直前の育休と、チームメンバーに支えられたプロジェクト運営

技術的にも、プロジェクト運営的にも、みなさまに少しでも参考になればと思います。

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

本トークは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年越しの答え合わせ」を試みます。

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

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

想定聴講者

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

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

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

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

ソフトウェア工学70年の歴史で、我々は三つの主要パラダイムを経験しました。命令型（How）は手順を、オブジェクト指向（Who）は主体を、関数型（What）は計算内容を問いました。本講演では第四のパラダイム「存在論的プログラミング（Whether）」を提唱します。

従来のプログラミングはDOING（何をするか）に着目します：

$user->validate();
$user->save();
$user->notify();

対して本手法はBEING（何であるか）に着目します：

$rawData = new UserInput($_POST);
$validatedUser = new ValidatedUser($rawData);
$savedUser = new SavedUser($validatedUser);

動作を指示するのではなく、オブジェクトが「どう変容するか」を表現するのです。

『時間と存在は分割できない』——アインシュタインが時空の不可分性を説いたように、我々は「時間とドメインの不可分性」を基礎とします。メソッドを持たず、コンストラクタのみを持つそのオブジェクトは、内在（イマナンス）と超越（トランセンデンス）の出会いにより、時間の中で変態（メタモルフォーシス）し、時間的存在として自立します。

「さっぱり、何のことか分からない」と感じましたか？ しかし、その違和感はかつて60年代のアセンブラ利用者が初めてOOPに触れた時の衝撃と同じで、これが単なる方法論ではなくパラダイムシフトである証拠かもしれません。

70年間、我々は「より良い命令」を追求してきました。しかしAIが「命令（How）」を無限生成する今、人間が書くべきものは手順書ではなく「存在（BEING）の定義」です。

世の中にはさまざまなプログラミング言語があり、それぞれさまざまな分類方法があります。

オブジェクト指向プログラミング、関数型プログラミングのようなプログラミングのスタイルは「パラダイム」と呼ばれ、言語ごとのプログラムの世界観となるものです。これらの言語やパラダイムは独自に発展するだけではなく、互いに影響を与え合いながら発展を続けてきました。PHPも例外ではなく、30年前の誕生時から同じ「PHP」と呼ばれていても、そのソースコードは似ても似つかないものに変化しています。

特に2000年代以降は「関数型」と呼ばれる概念がPHPをはじめ、さまざまな言語に浸透してきましたが、その概念を育んできた関数プログラミング言語と、PHPで実現できる関数型プログラミングは同等のものなのでしょうか。

本トークではプログラミング言語にまつわるさまざまなトピックを紹介し、PHPの作者はそこまで考えていなかったであろうPHPの正体を丸裸にしていきます。

• PHPの構文の基礎
• プログラミング意味論について
• 型システムについて

PHP を Web アプリケーションを作るための言語の一つだと思っていませんか。
実はそれ Web アプリケーション以外の用途にも PHP を用いることができるのはご存知でしょうか。

実例として PHP で Java VM (JVM) を実装したり、RubyVM を実装したり，OS などが実装されています。

もちろん，PHP を使って "OS を動かす" エミュレータを実装することもできます。
エミュレータという言葉にピンとこない人もいるかもしれません。皆さんも一度は使ったことあるであろう QEMU や、 VirtualBox のような仕組みを PHP で実装する、というイメージを持ってもらうとわかりやすいのではないかと思います。

本セッションでは，OS の代表格の一つである Ubuntu の起動までをマイルストーンとし， PHP を用いたエミュレータの実装方法から OS を動かすのに必要な知識を解説します。