ウェブアプリケーションの品質担保は重要課題です。しかし、2001年にローンチされた弊社のメール共有サービス「メールディーラー」のようなレガシープロダクトはより深刻です。

フレームワークを持たず、DBアクセスとHTML生成が単一プログラム内で混在する「スパゲッティコード」が構造を陳腐化させました。
このためコード全体の把握が困難になり、修正前の十分な影響調査ができない状態を生み出しました 。

実際、新機能リリース直後に改修していないはずの機能で「画面が表示できなくなる」という致命的な障害が発生。
この「意図せぬ機能破壊」に対し、理想は大規模リファクタリングでしたが、現実的なコストと期間ではありませんでした。

そこで私たちは、リスクを抑えつつ最低限の品質を担保する戦略的な選択として、E2Eテストの導入を決断しました。

本トークでは、私がテクニカルリーダーとして主導した、限られたリソース（3ヶ月）でのE2Eテスト導入戦略を公開します。

・複雑な内部構造を持つレガシーシステムに対し、テスト対象のスコープを切り出し、導入の投資対効果を最大化した手法。
・テストコード実装とテストケース作成において、スパゲッティコード特有の難しさをどのように克服し、273画面のカバー率を達成したか。
・導入後に「致命的な不具合の発生ゼロ」という具体的な成果をどのように勝ち取ったか。

本セッションは、レガシーシステムの品質改善に取り組むエンジニアに向けた、実践的な E2E テスト導入事例の共有です。
困難な環境下でのテスト戦略策定方法と、既存プロダクトへの段階的な導入テクニックと、
開発チーム全体に客観的な安心感をもたらすための確かな知見を持ち帰ってください。

PHP 8.5にて、配列の先頭・末尾の値を取得する array_first / array_last が導入されました。内部ポインタを操作せず、直感的に値をシュッと取得できる便利関数です。

実はPHP7.3にも、似た機能を持つ array_value_first / array_value_last というRFCが存在し、否決されていた事実をご存知でしょうか。
当時は配列の先頭・末尾のキーを取得する array_key_first / array_key_last のみが採用され、 array_value_first / array_value_last は見送られました。

PHP7.3だった時代に比べ、現代は readonly プロパティの普及により内部ポインタ操作の副作用ができなくなったことや、冗長な記述の蔓延など、array_first / array_last を必要とする理由があります。

本LTでは、array_first / array_lastの紹介に留まらず、array_value_first / array_value_lastのRFCが否決された背景や理由と、今回array_first / array_lastのRFCが可決された背景や理由を比較・解説します。
新機能だけでなく、歴史的経緯についても学べる5分間をお届けします。

PHPStanは簡単に使いはじめることができるツールですが、「きちんと」型をつけるのは案外簡単ではありません。
今回の記事では、これまで紹介してきたPHPStanの基礎知識を前提として、より具体的なプラクティスを紹介します。

PHPStanクイックガイド https://zenn.dev/pixiv/articles/7467448592862e
キミにも作れるPHPStan拡張 https://zenn.dev/pixiv/articles/1e6cade978808a
PHPStan 型付けマニュアル https://zenn.dev/pixiv/articles/09ae64aad4a2f6

ProgateでPHPを学び、2ヶ月でCRUD処理ができる掲示板を作れるようになりました。しかし機能を追加するたびにコードは複雑化し、どこに何を書けばいいか分からなくなり、収集がつかなくなっては最初からやり直す日々。
この地獄を抜け出すために「フレームワーク」を調べ始めましたが、LaravelやSymfonyの説明を読んでもありがたみが分からないし、漠然と機能を覚えていく学習に面白さを感じませんでした。ならば自分で作ってみよう。
MVC、ルーティングのディスパッチャー、コンストラクタインジェクション、バリデーター、CSRF対策、自動XSSエスケープ、Laravel風のヘルパー関数—これらをゼロから実装する中で、特に「依存性注入のメリット」と「設定より規約」の考え方が腹落ちしました。
本トークでは、フレームワーク自作を通じてこれらを理解していった過程を共有します。

トークの内容：

• スパゲティコード地獄から、フレームワーク自作に至るまで
• 実装した機能の紹介
• 「設定より規約」： ディレクトリに置くだけで動く、コンストラクタに書くだけで再帰的インスタンス化
• 「依存性注入」： サービスプロバイダで実装の差し替え、テストの容易さ
• まとめ： 作ることで「なぜ必要か」が腹落ちした

DIコンテナは、Dependency Injection（依存の注入）を利用してクラス間の依存関係の解決を行ってくれます。
具体的には、オブジェクト生成時やメソッド呼び出し時に渡す引数を自動的に生成してくれるなどの機能を有します。
LaravelやSymfonyなど、最近のWebアプリケーションフレームワークの多くにもこの機能が組み込まれているので、普段使っているという人も多いのではないでしょうか。

Autowire機能を持つDIコンテナの場合、コンストラクタやメソッドに型宣言を書いてさえおけば、引数を増やしたり入れ替えたりしても柔軟に動作してくれます。
『これはまるで「魔法」だ』とDIコンテナを知った当時に感じたのを覚えています。

とはいえ、DIコンテナもただのプログラムです。実際には魔法などではなく、PHPのコードとして実装されているのです。

このセッションでは、Autowire機能がどのように実装されているのかを紐解きます。その上で、Autowireによるコンストラクタインジェクション機能を持つDIコンテナを実装してみます。
DIコンテナの裏側を理解し、普段ブラックボックスになっているフレームワークの動作の一端を覗いてみましょう。

話すこと

• DIコンテナのAutowire機能の実装に必要な技術
• Autowire機能を持つシンプルなDIコンテナの実装方法

話さないこと

• DIを用いたソフトウェア設計について（依存関係逆転の原則など）
• 特定のDIコンテナライブラリの詳細な使い方

PHPUnitは毎年新しいメジャーバージョンがリリースされ、どんどんと変化を遂げています。
新機能や改善が取り入れられるスピードが速い一方、古いメソッドや機能の非推奨化・削除もどんどん行われます。
実際にPHPUnit 11のChangeLogを見てみると、Deprecatedが19件、Removedが25件もあります。

私たちのチームではPHPUnit 9を使っていたのですが、9から11へのバージョンアップには広範囲の修正が必要になる変更もあり、なかなか実行に踏み切れませんでした。
そこで、コードの変更を自動で行ってくれるツール "Rector" を採用し、手動での変更を極力減らしてPHPUnitのバージョンアップを行いました。

このトークでは、Rectorを用いたPHPUnitバージョンアップの実体験に基づき、以下のことをお話しします。

• Rectorを使ったPHPUnit9→11へのバージョンアップ手順
• 自動では対応しきれず、手動対応が必要だった事例

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

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

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

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

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

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

このトークの対象者

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

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

• Symfonyの基本的な使い方

「間違いたくない」「正解を出したい」
かつての私は、はじめから完璧を目指しすぎて、かえって大きな手戻りを生んでしまっていました。

どうすれば、手戻りを減らせるだろうか？
試行錯誤の末に見えてきたのは、「はやく失敗する」ことの重要性でした。

このLTでは、手戻りの多さに悩んでいた新卒1年目の自分に伝えたい、はやく失敗するメリットと、その実現のために日々の開発で実践していることについてお話しします。
似た悩みを持つ方にとって私の経験が参考になれば嬉しいです！

弊社の主要な検索機能では、Laravel Eloquentを用いたRDS上の検索クエリにおいて、複数テーブルのJOINや複雑なクエリ構造が検索パフォーマンスに影響を及ぼしていました。特に、利用頻度の高いクエリがレイテンシー増加の主因となっていたため、その改善策としてOpenSearchを導入しました。

導入後、検索速度が飛躍的に向上し、レイテンシーも大幅に改善されました。
また、OpenSearchのPHP DSLライブラリを導入することで、クエリの構築をシンプルにし、保守性を高める工夫も行いました。

Laravel eloquentとの共存を図りながら、検索機能のパフォーマンス最適化を実現しました。
これらの経験を基に、検索機能改善の実例を紹介します。

このトークは、パフォーマンスに課題を抱える開発者や、検索機能の改善に興味のある方に向けた内容です。

我々ソフトウェア開発者の日々の業務は、常に不確実性との戦いです。
新しくチームに加入したメンバーが「今までの現場で一番チームとしての一体感がある」と評してくれた我々のチームも、最初から全てが順風満帆だったわけではありません。

立ち上げ当初は、楽観的すぎる見積もり、沈黙が支配するお通夜ミーティング、そして正常系すら動かない壊れたプロダクトコードなど...
プロセスもチームも、まさにバグだらけで崩壊寸前でした。

このセッションでは、立ち上げから半年以上、数々のトラブルや不確実性と向き合う中で私たちが実践してきた、タスクの「解像度」を上げる工夫や対話の文化作りなど、チームを立て直すための具体的なテクニックについてN=1の事例として赤裸々にお話しします。

■ アジェンダ
前途多難なチームの「バグ」と向き合う

• 「根拠なき楽観見積もり」の罠
• 「お通夜ミーティング」はどうして生まれたのか？
• 「壊れたプロダクト」を前に我々はどうしたのか？

立ち上げを乗り越え、チームがぶつかった「3つの壁」と修正パッチ

• 「山頂の見えない台地」とモチベーションを再燃させた問い
• 「俺がn人分になる！」という属人化との決別
• 「次にやることが分からない...」というチームの向きを揃えた羅針盤

そして、その先へ

• チームの現在地と、新たに見えてきたプロダクトマネジメントという課題

■ このトークで持ち帰れること

• 不穏なチームの雰囲気を変えた具体的なアクション例
• 不確実性が高い状況下でのタスク管理・メンタル管理のヒント
• 「N=1」の事例から学ぶ、明日から使えるチームビルディングの知見

昔は3つくらいのGitクライアントを併用していた私も、今ではほとんどの操作をPhpStorm上で完結するようになりました！

• logを見る
• 編集してるコードから、ピンポイントにファイルや行の歴史を辿る
• グラフィカルな操作でrebaseやmergeも自由自在
• todo管理やstashも気軽にok
• 内部的に何をしてるんだ??という時も、簡単に確認できる

などなど、便利なポイントを思い出そうとすると、枚挙に暇がありません！

普段の作業の効率を高める、PhpStormを使ったGit操作の便利な活用術を紹介します。

「Circuit Breaker」
「BFF」
「Active Record」……
エンジニア界隈に飛び交う横文字や「〇〇パターン」という言葉に、苦手意識を持っていませんか？
「言葉を知らなくてもコードは書ける」「難しい言葉を使うとマウントだと思われる」と、あえて用語を避けてきた方も多いかもしれません 。
しかし、AIによるコーディング支援が当たり前になった今、これらの「技術用語」は、AIに対する「高圧縮で高精度なプロンプト」として極めて重要な役割を果たします。

本LTでは、教科書から入る退屈な学習法ではなく、AIを使って「今書いている自分のコード」から技術用語を学ぶ、実践的なアプローチを紹介します。
開発をもっと楽しく、創造的にするための新しい学習スタイルを提案します 。

PHP を使った Web アプリケーション開発において、多くの場合はサーバーサイドとクライアントサイドで実装が分離されるでしょう。

それらの結節点として、API 仕様を拠り所とするスキーマ駆動開発は

• サーバーサイドとクライアントサイドで独立して開発できる
• 仕様の認識齟齬を防げる
• 型安全に開発できる

といった観点から強力な手法となり得ます。

一方で仕組みを十分に整えないとその恩恵に与れないまま、煩雑さだけを導入してしまうことにもなりかねません。

このトークではスキーマ駆動開発の実践例のひとつとして Symfony と NelmioApiDocBundle の組み合わせを取り上げて

• NelmioApiDocBundle でできること
• 使う上での設定や周辺の設計
• 具体的な API の実装
• NelmioApiDocBundle でできないこと、他の選択肢と比較しての弱み

を解説します。

「顧客の業務フローをヒアリングし、その業務に必要なデータベース構築を自動化する」

夢のようなLLMアプリケーション開発に挑んだ私たちが直面したのは、「LLMは所詮トランスフォーマーであり、論理計算機ではない」という現実でした。
本トークでは、その限界を踏まえたうえで実用的にLLMを使いこなすための設計戦略についてお話します。

私が開発に関わる製品は、ユーザーがDBにテーブルやフィールドを自由に作成できる特殊なPHP製の大規模SaaSであり、構築される定義には厳密な整合性が求められます。
顧客へのヒアリング（自然言語・曖昧）から、この柔軟かつ厳密なDB構成（構造化データ）を導き出すため、私たちは「プロンプト一発ドカン！」で解決することを諦めました。

本トークでは、PHP製SaaSにPython製のLLM機能を統合したアーキテクチャの全貌と、実用レベルの精度を出すために繰り返した「泥臭い試行錯誤」を共有します。

• PHP × Python連携：OpenAIライブラリのないPHP環境から、Python側で構造化出力（Structured Output）させ、PHPでDB構築するための入力データを生成する構成
• 「感覚」で修正しない：プロンプトのTry&Errorを高速化し、デグレを確実に検知するために自作した「評価ツール」の重要性
• LLMに任せない勇気：「形式的な処理」は徹底してロジックに戻し、LLMには得意なことだけをさせる責務の分離

「チャットボットを作ってみた」の先にある、複雑な要件を伴うシステム開発におけるLLM活用の勘所をお話しします。

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

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

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

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

プログラミング言語の処理系は複雑な処理を行っているように見えますが、個別に分解してみれば一つ一つの処理はそれほど難しくありません。
しかしながら、PHP 処理系のような実用的な言語の処理系は大規模かつ複雑であり、全体の構造を把握したり、どこから読んでいけばよいのか見定めたりするのには一定の事前知識が必要です。

ここでは、PHP 処理系のソースコードを魔改造して PHP 言語に独自の拡張を施すことで、日ごろ使っている PHP の処理系が内部的にどのような処理を行っているのかを追いかけてみましょう。

話すこと

• PHP のソースコードを改造し、関数の合成を行う独自の演算子を追加する
• 言語処理系がどのような処理を行っているのか、はじめからおわりまで一通りさらう
  • 字句解析
  • 構文解析
  • コンパイル
  • 実行

目的としないこと

• PHP に実用的な拡張をおこなうこと

コードゴルフというコーディング競技があります。
コードゴルフとは、問題に対してコードを提出し、テストが通ったコードのうち最も短いコードを書いた人が勝利するというものです。

PHPerKaigi 2024 ではコードゴルフコンテストを、PHPerKaigi 2025、2026 では、コードゴルフを元にしたコードバトルという企画を実施しました。

こういったシステムを安易に実装すると、サーバ上で任意のコードを実行することになり、深刻な脆弱性を作り込んでしまいます。

このセッションでは、これらの企画の技術面・運営面での裏側を話します。

話すこと

• コードゴルフ・コードバトルとは
• 投稿されたコードを安全に動かすために
  • Docker による隔離
  • WebAssembly による隔離
• ルールとその変遷
• 問題の難易度調整
• 今年または去年の問題と解答の紹介
  • コードゴルフのテクニック紹介が趣旨ではないため、それぞれの問題に対する詳細な解説はおこないません。

Inertia.jsはLaravelとモダンフロントエンド（React, Vue.js）をシームレスに繋ぐアダプターです。
Laravelから見るとbladeテンプレートを利用するのとほとんど同じ書きっぷりでReactと連携することができます。
バージョンが2.0に上がってからはprefetchや無限スクロール、遅延ロードなどもサポートされ、より利便性が向上してきています。
この登壇ではInertia.jsの基本的な使い方を説明しつつ、どんなところが便利なのか
どういうふうに使うとより便利なのかについて、紹介していきます。

OSS活動していますか？

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

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

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

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

アジェンダ

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

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

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