GNU socialという2008年に生まれたPHP製のX/Twitter系のマイクロブログ型の分散SNSのフリーソフトがある。いろんな歴史的経緯があって、元の著者の手を離れ、複数のメンテナーを転々として、最終的に見捨てられたプロジェクト。
誰にも相手にされず、PHP経験ゼロ、Webアプリ開発経験ゼロ、人なし、金なし、コネなし、スキルなし。ないないづくしで、あるのはハンデだけの絶望的状態。ただの1ユーザーだった私が、この状態から、ここ何年かかけて、最終的にプータロー (無職) になって、この子の自称責任者になった。
ここまでのGNU socialで世界を変える物語の一番重要な始まりの序章を話す。

テクニカルな話は一切ない。あるのは泥臭い話だけ。というか、小手先の技術はネットや対話AIにきいたほうが人より詳しくて正確なことが大半。そんなことよりもっとクリティカルで重要なことがある。何をするか？方向と戦略が全て。

掃いて捨てるほどいるPHP技術者、IT技術者、人間の一人として、自分が世界でやりたいこと、すべきことって何？世界で自分しか理解できていない状態で、サラリーマンとして、組織に所属していて、しがらみ、忖度、組織の論理にまみれた中で、責任取れない立場で、組織のいいなり状態で、本当にやりたいこと・すべきことを邪魔されずにできるのか？
華やかな世界、規範、キャリア、組織・業界・コミュニティー・仲間からの評価・共感。所詮他人が勝手に作った基準。寄付、スポンサー、支援。基準や周囲の共感、理解、土台前提。恵まれた「普通」だからできる。他人・環境依存で弱すぎる。自分しか理解できないのだからどうでもいい話。

誰の力も借りず一人で自立。何のしがらみもなく、誰にも邪魔・指図を受けない「無敵の人」。それがプータロー。
言うのは簡単だがはたしてどうやる？気になったあなたを会場で待ってる。

チームに途中参加し、初見のアプリケーションを前にして「これ、どこから読めばいいんだろう」と立ち止まった経験はありませんか？

私は、技術サポートという仕事柄、すでに稼働している PHP アプリケーションに関わる機会があります。
中には長い歴史を持ち、コード量も多く、当時の設計意図がドキュメントとして残されていないケースもあります。

現場に入ると、こうしたアプリケーションをキャッチアップしていくのですが、
その様子を見ているメンバーの方から「どのようにキャッチアップすれば良いですか？」という質問を受けることがしばしばあります。

重要なポイントを一つ挙げるなら、すべてを理解するのではなく、必要となる箇所を効率よく把握することです。

本セッションでは、特に日々既存のアプリケーションのキャッチアップに課題を感じている若手の方に向けて、
私自身が実際に意識している考え方や、見るポイント、活用している手段などを具体的にご紹介します。

チームで既存アプリケーションの知識をシェアする方法を模索されている方にも言語化のヒントとして持ち帰っていただけると嬉しいです。

あなたの担当するプロジェクト、変更が難しい「モンスター」になっていませんか？

機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、オブジェクト指向設計の基礎であるSOLID原則への理解不足や誤解にあるかもしれません。

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

本トークでは、SOLID 原則に含まれる下記の5つの原則について、アンチパターンやPHP での実践的な例を交えながら解説し、その活用方法や得られるメリットについてお話しします。

• 単一責任の原則
• 開放閉鎖の原則
• リスコフの置換原則
• インターフェース分離の原則
• 依存性逆転の原則

このトークを聞けば、難しかったSOLID原則が「いつでも使える便利な武器」へと変わり、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

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

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

deptrac、便利ですよね。
設定ファイルを書いて実行するだけで、アーキテクチャのルール違反を検出してくれる。神ツール。

内部では、一体どんなことが起きているのでしょうか？
考えてみると、私はdeptracのことを何も分かっていなかった──
依存関係をどう収集しているのか。グラフとしてどう表現しているのか。ルールチェックはどうやって…？
「こういう情報を集めて、上手く使っているんだろうな」と想像してみても、実装方法まではピンと来ません。

そして思ったのです。
自分で読んで作って、動かしてみよう！
そうすれば納得感が増すに違いありません。

今の時代、知らないコードを読むのにAIの力を借りないなんて、 嘘 ですよね！
少し前なら「読み解くハードルが高いぞ…」と感じていたものも、挑戦しやすくなりました。
今回は、その力を存分に借りながら、
「どういう技術要素が詰まっているのか」「どういう流れで処理していくのか」をひも解いて、
「deptracもどき」を動かすところまで進めます。

やること

• ステップバイステップで「コードリーディングと小さなコードの実装」を進める
  • 「中身を読む〜動かしてみる」までを、40分で追体験できるように
• deptracの基本的な機能（＝「依存先の解決」と「ルールチェック」）の実装

お届けすること

• 「実際にこんな感じでコードリーディングを進める」という雰囲気
• deptracの内部実装についての知識
• 自分にもできそうだな！という気配

対象者

• コーディング用AIを使いながら、複雑なコードを読むことにチャレンジしてみたい方
• 「雑に作って学ぶ」方式の勉強法が好き、または興味のある方

一般にフレームワークは「便利なツール」として捉えられますが、設計者の視点では、フレームワークの本質は「設計原則にしたがった制約（Constraint）」です。

本セッションでは、登壇者が設計・実装してきた複数のフレームワーク（AOP, DI, REST, 独自ドメイン基盤など）を題材に、これらを「アプリケーション制約」としてどのように機能するか、その効能を考察します。

具体的には以下の3つの視点から「制約」を紐解きます。

依存と関心の制約（DI/AOP）： コードの構造を縛ることで、変更耐性とテスト容易性をどう担保するか。

Web標準の制約（HTTP/REST）： アーキテクチャを標準に準拠させることで、キャッシュやスケーラビリティをどう「自動的」に獲得するか。

ドメインの制約（Temporal Model）： ドメインを静的なデータではなく「時間的変化」として制約することで、AI生成時代におけるモデルの整合性をどう保証するか。

特に、AIによるコード生成が当たり前になる時代において、「何（How）をAIに任せ、何（What）を人間が厳格に定義すべきか」の境界線は、この「制約の設計」にあります。

情報設計（ALPS）から実装へと段階的に制約を与えていく手法を例に、自律的なソフトウェアを構築するための指針を提示します。結論はシンプルです。

「どうでもいいことは流行に従い、重大なことは標準に従い、ドメインのことは自らドメインフレームワークを設計し実装する」

ソフトウェア工学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 8.5で導入されたパイプ演算子（|>）、もう使っているでしょうか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

想定聴講者

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

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

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

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

「AIコーディングエージェントを導入すれば開発が加速する」

そう期待して導入したものの、現実は違いました
人によって生成されるコードの品質がバラバラ、アーキテクチャの一貫性が保てない、レビューコストは減るどころか増える一方、これがチーム開発の現実でした

「なんかいい感じにして」で動くのがVibe Codingです。楽しいし確かに動くコードは出てきます。しかし毎日AIガチャを引き続ける日々となり、チーム開発で再現性が出ません
必要なのは【理論】でした

そこでAWSが提唱するAI-DLC（AI-Driven Development Life Cycle）を導入しました
「AIが実行し、人間が監視する」という原則のもと、AIが参照・模倣できる設計資産を整備することで、ドキュメントを「人間が読むもの」から「AIが従うもの」へと再定義します。
Vibeに頼らない、感覚に逃げない、理論で設計し、理論でAIを導く
これらの対策により、誰が使っても一貫したコードが生まれる仕組みを構築し、レビュー指摘の大幅な削減とオンボーディング期間の短縮を実現しました

本セッションでは、AI-DLCを現場で実践するための具体的な手法をお伝えします。
AIコーディングはやればやるほど奥深く興味深いものになります。
ぜひこの機会に理論を軸にしたAIコーディングを実践して、本当に解決したい課題に集中しましょう！

• 想定する聴講者
  • AIコーディングエージェントを導入したが成果が安定しない方
  • AI-DLCを知らない方、導入してみたい方
  • Vibe Codingに限界を感じている方

「CQRSは大規模で複雑なシステム向けのパターンである」

これが一般的な認識です
AWS公式ドキュメントでも「シンプルなCRUDアプリケーションには推奨しない」と明記されています
ではシンプルなシステムにCQRSを選ぶ理由はあるのか、答えはサーバーレスアーキテクチャにありました

Lambda、DynamoDB、DynamoDB Streamsを組み合わせることで、CQRSの複雑さを吸収しながらメリットだけを享受できます
pay-per-useの課金モデルにより、小規模でもコスト負担なく読み書き分離の恩恵を受けられる
将来のスケーラビリティを考慮しつつ、現在は低コストで開始できる設計を実現します
これがシンプルなシステムにCQRSを選ぶ理由です

本セッションではDynamoDBをイベントストアとして活用した実装、Streamsによるリアルタイム同期、冪等性の担保、最終整合性との向き合い方、SQSとDead Letter Queueを用いたエラーハンドリングまで、実際の実装方法について解説します。

シンプルだからCQRSは不要、ではない
シンプルだからこそ、サーバーレスでCQRSを低コストに始められる
その選択肢を持ち帰ってください

• 想定する聴講者
  • CQRSに興味がある人
  • サーバーレスアーキテクチャの導入を検討している方
  • 小規模システムでコスト効率と将来の拡張性を両立したい方

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

国内のPHPコミュニティは、今も活発です。
しかし、10年以上PHPerとして現場を見てきた立場から申し上げると、参加者の年齢分布が静かに、確実に、変わりつつあるのを感じます。
若手の新規参入が減り、このまま放置すれば、PHPという文化そのものがゆるやかに縮んでいく未来を危惧しています（・・・言い過ぎ？）

本トークでは、コミュニティの高齢化が「気のせい」でなく構造的に起きている現象であることを、実例や現場感覚を交えて整理します。なぜ若手がPHPを選ばないのか。なぜ企業も新人をPHPで育てなくなってきたのか。技術面だけでなく、採用市場・教育環境・コミュニティ文化といった複数の視点から“本当の原因”を紐解きます。

その上で、みなさんが今日から現場で実行できる具体的なアクションを提示します。
「あとは現場の人が頑張りましょう」みたいな投げっぱなしの話ではなく、個人・企業・コミュニティのそれぞれができる実践できる施策を聞いて下さい。

話す内容

• 若手がPHPを避ける心理的・構造的ハードルの正体
• 「モダンPHP」を若者に届く形で伝え直す方法
• 初学者にPHPを選んでもらうための教育デザイン
• 企業が採用・研修でやめるべきこと、すぐ始められること
• コミュニティが若手を迎え入れるための環境づくり
• ベテランPHPerが持つ「邪悪な常識」の正体とアップデート手法

「高齢化しているらしいから危機感を持ちましょう」ではもうちょっと止められない状況にあります。
私のトークを聞き終わって、みなさんが会場を出たその瞬間から、何か行動を変えられるようにすることを目的にしています。

念の為にいうと、PHPの言語自体はさすがに廃れないと思っています。
ただし、何もしなければ静かに活気は失われていきます。
会場の皆さんと一緒に、PHPの未来を“作る側”へ回りましょう。

はじめに

昨年、私は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の基本的な使い方

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

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

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

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

OSS活動していますか？

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

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

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

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

アジェンダ

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

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

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

本トークはPHPカンファレンス福岡2025で発表した「Node.jsに頼らずにFrankenPHPでリアルタイムWeb通信を実現する
」（30分）をベースに、動作デモの充実させ、Socket通信やプロセス分離の説明を厚くアップデートしたものです。

概要

従来のPHP環境は1リクエスト1プロセスのモデルであり、長時間接続を維持するソケット通信とは相性が悪く、
リアルタイム通知を実装する場合、Node.js等を組み合わせた複雑なインフラ構成は悩みの種でした。
しかしFrankenPHPの登場で取れる選択肢が増えてきました。
この課題を解決するためにMercureが内蔵されており、PHPスタック内でシンプルかつ高速なリアルタイム通信を実現しています。
本セッションでは実際に動作するアプリケーションの動作デモを交えながら、Socket通信の様子やプロセス分離の様子を可視化し、解説します。

話すこと

• FrankenPHP (Mercure) を使った実装デモと、PHPスタックのみで完結するメリット
• PHPにおける常時接続の難しさと、ポーリング等の従来構成の限界
• Server-Sent Events(SSE) と WebSocketのソケット通信の基礎と違い
• 通信方向の違いによる技術選定のポイント
• PHPランタイムと通信プロセスのプロセス分離

話さないこと

• Mercure（Hub）の技術詳細
• スケーラビリティ、耐障害性等の非機能要件

概要

PHP8以降、match式の登場に代表される関数型言語の取り込みが進み、マルチパラダイムへと進化してきています。
さらにパイプ演算子の導入により、コーディング体験が大きく変わる局面に来ています。
一時変数の命名に掛かるコストや、多用による可読性の低下によるメンテナンス難易度の上昇、
array_mapに代表される配列操作の深いネストや、Collectionでの型情報がないメソッドチェーンに苦労された方も多いでしょう。
本セッションではパイプ演算子を中心にこのような問題を解決し、
より宣言的でわかりやすいコードを書くための手助けをしつつ、マルチパラダイムに向かうPHPについてお話しします。
オブジェクト指向設計に関数型言語の要素が加わることで、どのように設計の幅が広がり、どのようにコードが変化するのか。
そしてそれらにパイプ演算子がどう関わるのかを、具体的なコード例を交えて解説します。

話すこと

• パイプ演算子の基礎と仕様。従来の記述（ネスト・一時変数）との比較
• パイプ演算子がもたらす可読性と型安全性のメリット
• Enum・match式・パイプ演算子を組み合わせた宣言的なコードの実装例
• RFCも含めた、PHPのマルチパラダイムなコード設計

話さないこと

• パイプ演算子の内部実装
• 厳密な関数型プログラミング理論
• 他の言語との詳細な機能比較

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系のうちから必要なオブザーバビリティを担保するための手法について知ることができます。