PHPerKaigi 2026 感想

PHPerKaigi 2026 に参加した。各トークセッションへの感想を記す。順序はタイムテーブル順。

今後アーカイブで観た分は追記するかもしれない。おすすめがあれば是非教えて欲しい。

PHPでTLSのプロトコルを実装してみる (資料) by ひがき

このすぐあとの「IPルータ」も含め、タイムテーブルが発表されて肩の荷が下りたセッション。私は別枠で「接続」をテーマに登壇したが、TLSやTCPまでは時間的に踏み込めないと感じていた。直後にこのトークが配置されたことで補完しあえる流れになった。主催者の采配だろうか。感謝。

MAC とハッシュの違い

ここが役に立った。レガシープロダクトの刷新案件で、危なっかしいパスワード検証アルゴリズムの解析や、より安全な方式への移行提案を行うことがある。暗号は専門外のため不安を感じながら手探りでやっていたが、自分が採った手法に問題なかったことをこのトークの説明で確認できた。「やってみた」の知見がひょんなところで実務に活かされるパターン。カンファレンスの醍醐味。

質問コーナーでは、聴衆席にいた次の登壇者の市川さんが口を開いた。

市川: 私の場合最後の暗号化でドはまりしました
ひがき: 同じく暗号化ではまりました
市川: わかります、どこでミスしてるのか一切わからないんですよね

別の質問者からも質問が飛んだ。

質問者: エンディアンを考慮しますか？
ひがき: すぐには解らないので後日DMなどで回答します
市川: プロトコルはビッグエンディアンだがPHPはリトルエンディアンで動くのでそれを変換することになるはずです

登壇者への質問に聴衆席から市川さんが答える。突然IRTが始まったように感じ笑みがこぼれた。やはり交流がカンファレンスの醍醐味だ。この場の交流が他の聴衆の学びにもなっている。最高の瞬間。

PHPでできる！自作IPルーター (資料) by 市川@cakephper

市川さんはTCP/IP、TLS、ソケットプログラミングと、プロトコルの各レイヤーをPHPで実装する登壇を重ねている。本来はCの領域に近い。今回はIPルーター。

簡易HTTPクライアント

趣味の実験と捉えられがちだが、実務経験のあるエンジニアなら価値が解るはず。構築したサーバが上手く動かない時はtelnetやnetcat越しにHTTP, SMTP, FTPを手打ちしてトラブルシュートするのが一番手っ取り早い。なので、

仕事に役立つ（可能性）

資料では「可能性」と注記されているが、そんなことはないと思う。知識として持っておけば、意外と様々な時に調査やトラブルシュートの引き出しになる。私のセッションでKeepAliveや接続プーリングについて話したわけだが、プロトコルをこの深さで理解していれば自ずと見えてくる世界だと思う。

プロトコルは仕様が決まっている
→ ゴールが明確で取り組みやすい

私は業務と技術を切り離して学ぶことの重要性を説いている。双方の難しさに同時に圧倒されている人には「技術」を先に学ぶことを推奨している。業務と違って答えが明確だから。その意味でとてもいい題材。

ARP (Address Resolution Protocol)
ARPキャッシュ

昔の記憶が蘇った。初めてデータセンターと契約し、ネットワークの物理設計やルータの設定を自前でやった時のことだ。ARPプロトコルやARPキャッシュの存在すら知らない、ほぼ知識ゼロの状態で同僚とデータセンターへ赴き、ルータのマニュアルやその場のGoogle検索を頼りに設定作業をしていた時に最初にハマったのがARPキャッシュ。

ルータとの結線やサーバのIPアドレスを変更したら clear arp という「呪文」が必要なことを知るにも、現地で時間を要した。後日それがキャッシュに関するものだと知ったが、それがどの程度の効果があるのかは解らないまま10年以上が過ぎた。

そんな出来事はすっかり忘れていたが、今回のトークでその効果を突然知った。当時の拙さを思い出しつつ、感慨深い。

想定外の事象に遭遇すると超楽しい

「業務」でこれを感じられる人はあまり多くないと思うが、業務から切り離された純粋な「技術」の学びでなら意外と感じられる。市川さんの場合は「プロトコル」がそれに当たる。こういう領域を持っている人は研鑽が苦にならない。結果として強くなる。

Laravel Nightwatchの裏側 ― Laravel公式Observabilityツールを支える設計と実装 (資料) by 濱崎竜太

NightwatchはLaravel開発元によるファーストパーティーのo11yプロダクトだ。登壇者はその開発チームのメンバー。かねてから私は「Laravelに対して変な改造を加えたりせず、提供された機能を素直に使うこと」の重要性を説いている。まさにそれを体現するセッションだった。

登壇の数日前に「公開されたコードはいくらでも読めるので裏側の話を」と個人的な希望を伝えていたが、パッケージの説明を厚めにしてくれていた。これが結果的に良かった。導入と起動がそれぞれ1コマンド、計2コマンドという簡潔さ。処理のライフサイクルや詳細なドリルダウンを含む情報満載のダッシュボード。これだけの機能を備えていながら、少なくともエージェント部分は「通常のLaravelパッケージ」の範囲内の技術で実装されている。開発元がこの設計思想をPHPerKaigiの場で示してくれたことが有り難い。

laravel/nightwatch のコードは一通り読んでいたつもりだったが、ReactPHPが採用されていることには気づいていなかった。注目していた製品の実運用でEvent-driven PHPが使われていると知り、一気に興味が湧いた。選定の理由も印象的で、RustやGoが一般的な選択肢である中「自分達はPHPのエンジニアなのでPHPで書きたい」という動機から候補とし、パフォーマンス検証を経て採用したそうだ。トレンドは追うが最終的には自分達の意志と実利で選ぶ。非常にLaravelらしくて好きだ。

車輪の再発明をしよう！PHPで実装して学ぶ、Webサーバーの仕組みとHTTPの正体 (資料) by H1R0

PHPでWebサーバーをフルスクラッチで実装する試み。出来ていない箇所を明確に認識していたのが良かった。単に「AIに作らせておしまい」としていない。「理解するまでにかかった時間は1週間程度」と、きちんと時間をかけている。

「習作なので不完全な箇所が残るのは当然として、その中でも『作ってみたかったが時間や技術で』箇所は？」と質問してみた。KeepAliveや並列処理などをやってみたかったとのこと。即答で回答された点に非常に好感を持った。決して試すような質問をしたわけではないが、「AIに作らせた、動いた、以上」だったとしたらこの質問には明確な答えを持っていないはずだ。資料冒頭「本発表のゴール」に「基本的な仕組みが理解できる」とあった。登壇者自身がそれを体現していたと思う。

終盤のスライドにて「他にも色々作ってみたくなった」としてDBサーバの作成予定が挙げられていた。自分はそれができない。HTTPで「作りきれなかった箇所」を納得いくまでやってしまう性格。「迂闊に作る」「やってみた」にも様々な形があるのだなあ、と新鮮だった。

モジュラモノリス導入から4年間の総括：アーキテクチャと組織の相互作用について (資料) by 川島慧

エンジニア約100名の組織における「モジュラモノリス導入」4年間の振り返りセッション。結論を先に書くと、モジュラモノリス自体は成功した。ただし試み全体は失敗。せっかくの「成功」は最後に余談としてのみ語られ、登壇の大半は「失敗」の分析に費やされ続けた。

リアーキテクチャの苦労やモジュラモノリスの導入ノウハウの話を期待して聞き始めたが、前半で「組織構造とアーキテクチャを一致させる」というスライドが登場した辺りで引っかかった。ビジネスも組織構造も常に変化し続ける中で、それらよりも変更容易性の低い「アーキテクチャ」を一致させる。結論を知った上で振り返ると、ここが起点だったのだと思う。

予感の通り、いやそれ以上に、身も蓋もない話が展開され続けた。

「組織図は高頻度に更新され続けた」「ほぼすべての開発PJが（せっかくモジュラモノリスを導入したのに）複数モジュールを跨いでいた」など、最初の前提が覆され続ける。これ自体は、悪いことではない。開発上の制約に縛られず組織やビジネスが新陳代謝よく変化し続けていることの証左だからだ。だが、試みの振り返りとしてどう着地するのかと思っていたら、登壇者自身の口から「命題自体が構造的に破綻している」と出てきて仰天した。いい意味で他人事のように、冷静に言語化している。

一方で、組織論を切り離した上でのモジュラモノリス導入の評価が対照的だったのも面白い。試み自体は破綻していたがアーキテクチャは組織の変化にもビジネスの変化にも耐えたという点が興味深かった。組織的な判断と技術的な判断とを切り離して単体で評価している。

モジュラモノリスを導入したと言いつつ、リファクタリングに伴い機能をモジュール間で移動する判断も比較的頻繁に行っていた、この機動力の高さも印象的。破綻の話であると同時に、それをリカバリするのは意外と容易という話でもある。

実のところ、何れの話も「それはそうだろう」「そんなことは経験的に知っている」という内容だった。だが、聞いている分にはそうだったとしても、自分にはこの精緻な言語化はできない。この言語化は、4年間、勉学に励み課題に真摯に向き合い続けた結果のはず。称賛。

ビジネスがわかるエンジニアになろう：経営学とエンジニアリング、その共通点と活用法 (資料) by nrs / 成瀬允宣

経営学のフレームワークとエンジニアリングの共通点を探る内容だが、プレゼンがとにかく上手い。特に印象的だったのは、問いかけの時と説明の時の口調や間の使い分け、表情、視線。羨ましい。エンジニアにとって馴染みの深い分野を最後に持ってきたのも上手い。

惜しいと感じた点がひとつ。この場で「フレームワーク」と言えば、実装を伴うWebアプリケーションの基盤を想像する聴衆が多いはずだ。経営学のそれは思考の枠組みであり、意味が異なる。この橋渡しがあるとなお良かったかもしれない。それを差し引いても、刺さるスライドは多かった。

開発者と相性がいいのでは？

AIが「開発者 ≠ プログラマー」という事実を突きつけた昨今、この相性は他人事ではない。

最初のケーススタディからヒントを得た。現場でよく聞く「上から決定が落とされる」「上は抽象的なことばかり言っていて」等の不満。これを変革の失敗と捉えることもできるが、「落とされた」決定を経営学のフレームワークに当てはめ、その意図を逆算する。こんな使い方もできそうだ。

後続のケーススタディはより具体的な例だったが、聞いていて、書籍「いかにして問題をとくか」を思い出した。過去に記事を書いたこともある。問題の変形や評価すべき変数の過不足の確認。「◯◯学である以上、構造は同じ」という説明が前半にあったが、まさにその通り。経営学には明るくないが、説明された内容は何れも自分にとって馴染み深い考え方ばかりだった。それを確認できたことが大きな収穫。

キーワードは「延命」 ― リプレイス困難システムの現実的バージョンアップ戦略 (資料) by 李丞浩

PHP 5.6。24時間無停止。金銭計算に直結。テストカバレッジは20%以下。このシステムをリプレイスではなく「延命」する。

翻って自分のこれまでの経験では「延命」どころか「塩漬け」にしてしまうか、常に最新を追従し続けるか、両極端の対応しかしてこなかった。対応困難な非互換とそれを修正しテストするコストに絶望し追従を辞めた瞬間が「塩漬け」。ここに至らない限りは最新しか使わない。レガシープロダクトの扱いには一家言あったつもりだが、要は「上手いやり方」を知らなかったのだと思う。最新化と塩漬けの間を取った今回の方法に目から鱗が落ちた。

「楽したい」が動機になっているのが良い。プログラマーの三大美徳「怠惰」は言うまでもないが、別システムのリプレイスが決定している点からも、必須でない作業はやらずに済ませる判断は妥当だ。人に言われるがままに仕事をしている人は、この合理的判断が逆にできない。autoloaderのカスタマイズ、ログのリプレイ、段階的リリース、テクニックとしてはどれも難しくない。「組み合わせ」が効いている。技術力の勝利であると同時に、発想と組み合わせの勝利でもある。

さらば、不毛なログ調査。SentryとLaravel Insightsでボトルネックを完全可視化 by 三上崇

このトークを聴いて、o11yツールの使い所がようやく腑に落ちた。

新規プロダクトの場合、ログレベルの定義を早々に明確化し、レベルに応じたo11yやアラートを設定し、Slackチャンネルの通知設定や購読対象者を慎重に決定し、私の場合ここで終わりにしてしまう。なのでSentryのような外部のo11yサービスを自分の意志で導入したことが一度もない。

対して、冒頭「弊社の現実」では、それだけでは監視が困難なほどの状態になっていた。自分はこの状況に弱い。既知のアラートを片っ端から根治しようとして挫折、ログレベルとログ内容を整理しようとして挫折、という経験が何度かある。今まで対処の仕方がわからなかった。

ところが、パッケージの導入とアプリケーションの数行のコード変更だけで様々な問題を抜本解決できるようなダッシュボードが提供され、当然だがアラート閾値や条件の調整も、かなり高度な範囲を含めコード変更を伴わず可能。監視の構築を自前で「出来てしまう」ために、世のツールの便利さを今まで知る機会が無かったジレンマ。私はよくこの失敗に出くわすが、o11y分野でも同じ失敗をしていた。

ここまでの話は「ツールを便利に導入した話」だと思うが、運用の知見も見事だと思った。平均値と95pctの乖離を見ただけで「裏で何が起きているか」を推測してしまう観点、トークの最後には監視自体のチューニングの重要性も説明されていた。実のところ、o11yツールを導入してはみたが上手く使いこなせていない、というプロジェクトも幾つか見てきた。このトークで話されていた内容を実践すればそうはならないはずだ。良い知見が得られた。

「通るまでRe-run」から卒業！落ちないテストを書く勘所 (資料) by asumikam

トークの冒頭でフレイキーテストの前提が整理されていた。

「なぜFlaky Testを避けるのか」「落ちなくて嬉しい or 落ちて嬉しい」「落ちて嬉しくない」

この説明を試みる姿勢が良い。かなり昔の話だが「テストを『書かされている』雰囲気のプロジェクト」で、前提の説明なく「フレイキー（かもしれない）テスト実装」に対してChange Requestを提出し訝しい顔をされた経験などがある。それはそれでどうかと思うが、テストを嫌々「書かされている」ような現場では、Approveのハードルを（一見して）無意味に上げるようなコメントが歓迎されないのは当たり前だ。前提の説明は大切なのだ。

実装側でorder byが欠落していたためフレイキーになっていた例。プロダクトコードでの順番固定は「対処法」として紹介されていたが、これは「フレイキーテストへの対処」ではなく「実装側の隠れたバグ」だと思う。登壇テーマとして「対処法」という表現になるのは解るが、この点を明確に区別して紹介すると良かったかもしれない。もっとも、フレイキーテストが実装側の問題かテスト側の問題か、きれいに線引きできないことは多い。この例は確率で実装のバグを洗い出してくれたケースでもある。

テストの品質をチームや仕組みとしてどう上げていくか？という趣旨の質問をした。「みんながやらないなら、私がやる」でやってきてしまったのが実情、と率直に回答されていたのが好印象だった。その活動を通じてテストの良さをチームに広められればそれが一番良い、と。背中を見せチームを牽引する姿が素敵だ。

成長期における、ユーザー領域の複雑さと整備の進め方 (資料) by P山

成長を続けるタクシーアプリ『GO』のバックエンド。入社直後の登壇者がユーザー領域の複雑さに向き合った話だ。

「入社直後が課題に一番気付ける」「同質化する前に直すのが大事」という姿勢に感銘を受けた。同じ考えなので、それを踏まえた質問をぶつけた。入った直後はバリューを出さなければならない、しかし過去の経緯を知らないから判断を誤るかもしれない、だがそれが払拭される頃には「同質化」してしまっている。このジレンマをどう解決するか。答えは「そこにIssueがあるか？あるとしたらその大きさ」を基準にしているとのこと。単にエンジニア的な観点に偏るのではなく、きちんとユーザーを見ている。

続く質問「度胸がいるのではないか？」に対して「九州男児なので…」という回答には会場から笑いが起こった。共感を感じ、思わずXにポストした。

「リリース優先」は一生そうなので真に受けずいつでもリファクタすべき、とのこと。ここでも歴戦の猛者という印象を受けた。認証認可のリファクタでは、ユーザー種別と機能の利用有無を独立管理しManyToManyで結ぶ設計を後付けで導入。今どきのフレームワークであれば標準機能に近い形として備わっている「王道」の設計だが、リファクタリングとしてこれを実現するには設計知識と技術的腕力の両方が必要だ。設計時に機能のグルーピングをAIに任せたというのも目の付け所が鋭い。

夢の無限スパゲッティ製造機 (資料) by きんじょうひでき

昨年の「非構造化プログラミング入門」の続編にあたるセッション。昨年は質問コーナーで少し意地悪な質問を投げたところ、懇親会で「この手の質問をすることはある程度予測していた」と言われた。阿吽の呼吸のようなやりとりだった。今年のトークはgotoの更に先、「なぜスパゲッティが生まれるのか」という構造的な問いに踏み込んでいる。

CPUレベルではコールスタックの管理はハードウェアが自然に処理する。CALL命令で戻り先をスタックに積み、RET命令で戻る。動的なジャンプも可能だ。一方、PHPのgotoは静的なラベルへのジャンプしかサポートしていない。今回の製造機は、この制約の中でコールスタックを配列と変数で手動再実装するという力技で動作を実現した。不可能ではない。製造機がそれを証明した。だが膨大な力技を要した。

この力技が必要だった理由を考えると、言語設計の本質に行き当たる。言語設計とは「何を自然にするか」の方向を選ぶことだ。そしてその選択は、同時に「何を困難にするか」を決める。PHPはgotoを制約し構造化プログラミングを自然にする方向を選んだ。その裏側として、製造機のような非構造的な実装のコストが爆発する。これは欠陥ではない。スパゲッティを防ぐという設計意図が正しく機能している証拠だ。制約とは設計意図の可視化に他ならない。

歴史を振り返ると同じ構造が見える。N88-BASICはGOSUB/RETURNを持っていたが、ローカルスコープも戻り値もなかった。当時のi286 CPUはCALL/RET、レジスタ渡し、スコープを完全にサポートしていたにもかかわらず、だ。N88-BASICは「簡単なプログラムが自然に書ける」方向を選んだ。実際にeasyだった。だがその裏側として、プログラムの規模的成長のコストが爆発し、言語そのものが「レガシー」に固定された。方向の選択が長期的な帰結を決定づける。PHPのgoto制約と同じ構造がここにもある。

自然言語の世界には言語的相対論という概念がある。言語が思考を「決定」するのではなく「選択を偏らせる」とされる考え方だ。今回のトークが示したのは、まさにプログラミング言語における同じ現象ではないかと思う。

今年も質問に手を上げた。「武田さんが来ると思ったんですよ」。そろそろプレッシャーを感じ始めてきた。さて、来年は何を質問しよう。

存在論的プログラミング：時間と存在を記述する (資料) by koriym

登壇者は「聴衆のパラダイム転換を促すこと」を動機としている。それに対し私の感想は、おそらく既存のパラダイムの枠組みの中で登壇を理解しようとしてしまっている。その点で登壇者の望む感想ではないかもしれない。

実用的な観点で見ると、ここで提示された設計論は TypeScript 関数型スタイルでバックエンド開発のリアルを、関数型ではなくオブジェクト指向から追求したものと感じた。両者は「型で不正な状態を表現不可能にする」「イミュータブルな状態遷移を明示する」という核心で共鳴している。

しかしアプローチは対照的だ。@naoya氏が既存エコシステム内での実用主義的なFP採用であるのに対し、参考実装であるBe Frameworkは、処理フローを呼び出し側が組み立てるのではなく、オブジェクト自身が#[Be]アトリビュートで「次に何になるか」を宣言し自律的に変換を駆動する。シンタックスの違いはあれど同じ結論に行き着いているというのが私の見立てだ。

ただし背景となる哲学が本登壇はあまりにも深い。

この哲学的深度の高さは、AI時代にきわめて有効かもしれない。Claude CodeのSkill Creatorスキルには次のような表記がある。

Explain the why behind everything you’re asking the model to do. (…) reframe and explain the reasoning so that the model understands why the thing you’re asking for is important. That’s a more humane, powerful, and effective approach.

スキルを幾つも自作した自分にとっても、この表記は感覚的にしっくり来る。AIにWhyを伝える重要性。Be Frameworkは、フレームワーク自体の命名に始まり、ユーザーに提供するアトリビュートなどのインターフェース、結果として出来上がるコード、それらすべてが思想を体現するよう設計されている。

#[Be(ValidatedUser::class)]
final readonly class UserInput
{
    public function __construct(
        public string $name,
        public string $email
    ) {}
}

$userInput = new UserInput($name, $email);
$validatedUser = new ValidatedUser($userInput);

コードが様々な人やAIの手による修正を経た先にどのように堅牢または脆弱になるか、それは背景にある哲学がどれだけ強固なものなのかにかかっているのではないかと感じている。その意味で極めてAI時代的なプロダクトだ。

レガシーコードの呪縛を断つ！ 20年モノのスパゲッティシステムにE2Eテストを導入し、致命的なバグ混入をゼロにした3ヶ月間の戦略 by 藤掛治

ラクスの方による「メールディーラー」「レガシーコード」のトークは何度も聞いてきた。レガシー返済の知見は対象がレガシーであればあるほど深度が増す。サービスは25年が経過している。知見の宝庫だ。題材は、不適切な共通化が行われたネストの深すぎる共通関数が意図しない不具合を引き起こした事例。典型的な「レガシーコード」問題であると同時に、壊れるのが怖くてついコピペ対応をしてしまいがちという、多かれ少なかれ悩んでいないプロダクトを見たことが無いような問題だ。

これに対するアプローチが秀逸だった。スモークE2Eテストで273画面の品質を担保する。基準は「画面を表示できれば良い」という簡易なもの。リリースサイクルの3か月間で実装し、1日3画面と考えれば十分に余裕のあるスケジュールだ。この割り切りがコストパフォーマンスの最も高いラインを見極めている。

「今後」のセクションで「AIを使って自動化」について、AIがテストを実行するかAIにテストコードを書かせるかという選択が示された。個人的には「AIがテストを実行」が良いと思う。E2Eは一般的に壊れやすい。確定的なコードに落とし込むのではなく、AIの不確定性を逆に活かす。ある程度「よしなに」やってくれる点に頼るべきだ。

今回も登壇しました。それに関する記事は別途書く予定です。

この記事を振り返ると、感想の多くが質問コーナーや懇親会でのやりとりから生まれていました。セッションを聴いて考え、質問し、議論する。アーカイブでは得られない、この場にいるからこその体験です。スタッフの皆様、スポンサーの皆様、今年もこの場を作っていただきありがとうございました。