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

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

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

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

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

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

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

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

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

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

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

話すこと

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

話さないこと

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

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

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

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

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

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

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

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

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

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

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

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

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

そして、その先へ

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

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

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

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活用の勘所をお話しします。

プログラミング言語の処理系は複雑な処理を行っているように見えますが、個別に分解してみれば一つ一つの処理はそれほど難しくありません。
しかしながら、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の基本的な使い方を説明しつつ、どんなところが便利なのか
どういうふうに使うとより便利なのかについて、紹介していきます。

概要

TiDB は「NewSQL」と呼ばれる分散データベースで、
MySQL 互換のプロトコルを持ちながら水平スケールできるなんだかすごいやつです。

さてMySQL互換というからには、さぞ移行もしやすいことでしょう！
MySQLを利用している既存のLaravelのアプリケーションをローカル環境でTiDBに切り替えてみて、果たしてどこまで動くのか？
実際に切り替えてみてからの躓きからTiDBとMySQLの違いを掘り下げ、完全に理解していきましょう！

ターゲット

• TiDB に興味はあるけど触ったことがない方
• RDBMS以外のDBも学んでみたい方
• DBが好きな方

お話すること

• TiDBの簡単な概要、特徴
• TiDBのローカル環境の構築方法
• Laravel アプリケーションを接続してみて実際に詰まったポイント
• MySQLとの挙動の違いとその理由

サービスに途中から参加すると、最初の頃はコードとドメインがどのように積み上がってきたのかを追いかけるところから始まります。私が担当しているユーザー領域も、サービスの成長に合わせて機能が増え、その結果としてバリデーションや判定処理がいくつかの層に分散していました。本セッションでは、これらを読み解きながら整理していったプロセスを紹介します。

まず、散在していたユーザーまわりのバリデーションをドメインサービスに集約し、どのような処理をドメイン側で扱うべきかをチームで合意できるよう、簡単なマニフェストを用意しました。また、利用者ごとのケーパビリティを導入し、エンドポイント単位でアクセス制御を行うことで、コントローラへの細かな分岐を避けられるようにしました。

さらに、DB のインデックス追加を安全に進めるために、GitHub Actions から実行できる “alterguard” を開発し、作業手順を極力シンプルにしながら pt-osc を併用できる環境を整えました。これにより、ユーザー領域以外の改善も継続的に進められるようになりました。

成長中のプロダクトに後から加わった立場として、どのようにドメインを理解し、どこから整えていったのか。その具体的な進め方をお話しします。

「テスト」という言葉は、文脈によって全く異なる意味を持ちます。
例えば、プログラマーとQAが「テスト」について話すとき、よく認識のズレを感じることがあります。
不思議ですよね。

それは、テストには「開発手法（設計）」としての側面と、「品質保証」としての側面の二面性があるからです。
この違いを理解せず、開発手法としてのテスト（TDDなど）だけで「品質は保証された」と判断してしまうことは危険です。
それと同時に、品質保証の側面だけから開発手法としてのテストを語ることも、また危険です。

本セッションでは、テストを「事実から学習し、意思決定するためのフィードバックループ」と捉えます。
そして、アジャイルテストの4象限を用いて、その役割の多様性を整理します

チームを支援するテスト

テストから得られた情報によって、チームを導き、支援するような役割を表すのがこの側面です。

製品を批評するテスト

一方で、作り手が考える「あるべき姿」とはまた違った視点から、批判的に評価し、チームの自信とステークホルダーへの説明責任を果たす役割を持つのがこの側面です。

ビジネス面と技術面

上記の左右の軸に加え、それが「ビジネス（ユーザー）視点」なのか「技術（内部品質）視点」なのかでマッピングすることで、テストの目的はより鮮明になります。

テストの二面性を知り、アジャイルテストの4象限を使うことで、漫然とテストをしていたことに気づくかもしれません。
これらは「誰のために、どんなことをするのか」に気づくことができる強力なツールです。

テストの二面性と4象限へのマッピングを使って、チームで納得のいくコミュニケーションを行うためのヒントをお話しします。

「バグ」という言葉を聞くと、ネガティブな気持ちになるプログラマーは少なくありません。
多くの人にとって、バグ報告は「自分のミスへの指摘」のように感じられ、決して気持ちの良いものではないでしょう。
その結果、バグ報告を躊躇したり、見なかったことにしてしまう心理が働くことも理解できます。

しかし、1人のテストエンジニアとして一貫して思うのは、バグは誰かの「罪」ではなく、単なる「事実（期待結果との差異）」です。
この事実と正しく向き合うための技術こそが「バグ管理」だと考えています。
そして、それを運用するのは感情を持った人間です。

本セッションでは、バグ管理を「(意図的でないにせよ)開発者を責める場」から「チームが前進する場」へと変革した実践事例をお話しします。

バグ管理の本質は「事実」の管理

バグとは「現実で起こっている問題」であり、リスク管理の対象として適切に管理すべき対象です。
バグを全て修正するのではなく、限られたリソースの中で建設的に対処することが必要です。

「バグ」ではなく「チャンス」と呼ぶ

「期待と違う挙動」は、実はプロダクトを良くする機会であることに気づきました。
呼び方を変えるだけで、バグ起票や対処のハードルが下がった事例を紹介します。

重大度を「妖怪」で定義する

重大度という、そのバグが持つ悪い結果を予知するステータスがあります。
これは一般的に「Critical/Major」などの言葉がありますが、私がいたチームでは「座敷童（軽微）」「鬼（重大）」「八岐大蛇（致命的）」と定義しました。
これにより「今週は鬼を退治しよう！」とチームの会話がポジティブに変わりました。

バグ管理は重要です。一方で、嫌な気持ちを放置するのも違います。
バグ管理をハックして、毎日の開発を楽しくしませんか？

「全数テストは不可能」というソフトウェアテストの原則があります。
ごく単純なソフトウェアを除けば、すべてのバグを見つけることは不可能です。
では、私たちは不完全さを理由に、テストという活動やその責務を放棄してよいのでしょうか？

私はそうではないと考えます。
無限のテストに立ち向かうためには、「どこまでやれば我々の責務を果たしたと言えるか」を定義し、チームで納得する必要があります。
私はそれを「テスト計画」によって示せると考えています。

多くの現場において、テスト計画は「スケジュール調整」「テンプレートを埋める作業」と誤解されていますが、それは本質ではありません。
本来のテスト計画とは、ソフトウェア開発におけるコンテキストを深く理解し、「テストすべきもの」と同時に「テストしないもの」を定義します。
そして、「我々はこれでリリースできる」と納得することです。

本セッションでは、QAエンジニアである私の視点から、テンプレ埋め作業ではない、「テスト計画」という活動を構成するプラクティスを一部紹介します。

「コンテキスト」を集める

「テストはコンテキスト次第」という原則があります。
「なぜ作るのか」「誰が使うのか」、そして「制約」そういった情報を集め、整理することがテスト計画の第一歩となります。

「作ってはいけないもの」を見つける

我々は「作るべきもの」に集中することが多いです。
一方テストでは、「作ってはいけないもの」ということも考える必要があります。
プロダクトリスクと言いますが、これを批判的な問いによって見つけていきます。

完璧なソフトウェアが存在しないように、完璧なテストも存在しません。
しかし、我々はプロとして、「これなら大丈夫」と胸を張って顧客に届ける必要があります。

その方法のひとつとしての「テスト計画」について語りたいと思います。

"Official PHP SDK for MCP"、mcp/sdkというライブラリがあります。
これを使うと、簡単にPHPアプリケーションを「MCPサーバー」化できます。

例えばToolsを提供するなら、「jsonを返すPHPのメソッドに、「Tools」用のattributeを付けて、 Mcp\Server クラスを run() する」で、もうAIエージェントから使えます！
あまりに簡単。魔法のようですよね。

これは、一種のフレームワーク(FW)としての開発体験を提供していると言えます。
すなわち、

• 開発者は、自分の必要なロジック(アプリケーション機能)にだけに関心を払えば良い
  • それより下の、「クライアントとのやり取り作法」については、全てカプセル化
• 「実装した機能」の検出と呼び出し = ルーティングを一式備えて、正式で唯一のエントリーポイントを提供する
• この2点により、「制御の逆転」を実現する

というものです。
──さて、phper的には「どうやって、”足場”と”アプリケーション機能"の分離を行っているのか」「MCPならではの特殊な事情を繋ぎ込んでいるのか」が気になりませんか？
なぜ、こんな少ない労力で「すぐ動く」のでしょうか。

そんな訳で、「MCPそのもの・便利な使い方」はさておき、「FWとしてのmcp/sdkはどう設計され、機能を実現しているのか？」を読み解こう！というトークです。

このトークでは、次のような知識と知恵を提供します。

• 「FW」とは何を指しているのか、目的と要件
• mcp/sdkの「制御の逆転」と手続きの隠蔽、MCP的な事情をクリアするための実装
• 現代PHPのエコシステムに則った拡張性の実現(PSR関連)

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を使ったネットワークプログラミングの面白話

Laravelアプリケーションの運用において、エラー調査にどれくらいの時間を費やしていますか？ 「ログ検索（Kibana等）をしているが、POSTパラメータが欠落していて再現できない」「スタックトレースだけでは原因が特定できない」——かつての弊社もこのような課題を抱え、調査に数時間を費やすことも珍しくありませんでした。

本トークでは、Sentryを導入していない、あるいは基本機能のみ利用している方に向けて、エラー対応の効率化からパフォーマンス改善までの一連の流れをお話しします。

前半では、Sentry導入による劇的な開発体験の変化を紹介します。 リクエスト時のパラメータや実行環境などの豊富なコンテキスト情報の記録、そして類似のエラーを自動でまとめる「インテリジェントなグルーピング」機能により、Slack通知のノイズを大幅に削減。以前は困難だったエラー原因の特定が数分で完了するようになった経緯と実績をお伝えします。

この「守りの効率化」を踏まえた上で、後半は「Laravel Insights」を活用した「攻めのアプリ解析」について詳しく見ていきます。 ここでは、ループ内で過剰にDBクエリを発行してしまう「N+1問題」の検知や、遅延しているHTTPリクエストの特定など、パフォーマンス低下の要因（ボトルネック）を可視化する方法を解説します。さらに、AIエージェントによる根本原因の推論機能を用いたデバッグフローも紹介します。

Sentryを導入し、「ログを探す時間」を「コードを直す時間」に変えましょう。チームの開発生産性を高めるための具体的な実践手法を持ち帰っていただければ幸いです。

MVC フレームワークが普及してから約20年。Web アプリケーション開発において「層」を分けることは当たり前の「お作法」になりました。

その効果は「関心の分離」というキーワードでよく語られます。しかし、あなたの現場ではその言葉の意味が正しく理解されているでしょうか。そこで分離したい「関心」とは一体なんなのでしょうか。

意味を理解しないまま、フレームワークや流行のアーキテクチャの表層だけをなぞり、雰囲気で「層」を分けていると、次のような事態に陥ります。

• Controller から Repository へデータを右から左へ流すだけの「土管」Service
• DB のスキーマ変更が、なぜかフロントエンドの修正にまで波及してしまう
• ビジネスロジックがあちこちに分散し、調査に時間がかかる

これでは「層」を分ける恩恵を受けられないどころか、コードを複雑化させ、開発速度を落とす無駄なコストが増えるだけです。「層」の分割は、その意図を正しく理解し、適切な「抽象化」によって本当の「関心の分離」を実現することで、初めてその効果を発揮します。

本セッションでは、形骸化しがちなレイヤー設計に意味を取り戻すための考え方を解説します。

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

• なんとなくルールに従って層を分けているけど、面倒なだけに感じている
• 層を分ける理由をきちんと言語化し、後輩にもっと丁寧に説明したい

概要

GitHub Copilot は優秀な相棒ですが、あなたのプロジェクトの「空気」まで読んでくれていますか？
特に長く運用されているレガシーコードや、独自のフレームワークを採用している現場では、AIが良かれと思って提案する「モダンで洗練されたコード」が、逆に修正の手間を生むノイズになることがあります。
「そこは namespace ではなく、アンダースコア区切りで……」と、AIの提案を人間が修正する作業に疲弊していないでしょうか。

本セッションのテーマは、Copilot への「教育」です。
単なるコード生成ツールとしてではなく、プロジェクトの文脈を理解した「専属の一流エンジニア」として育てるための、 Custom Instructions の活用と実践術を深掘りします。

話すこと

• Custom Instructions について: 設定ファイルの仕様と、AIに「空気を読ませる」ための基本的な記述ルールについて解説します。
• 独自ルールの徹底: モダンな学習データには少ないルールをどう言語化すればAIに伝わるか解説します。
• Before/After: 同じプロンプトでもインストラクションの有無で、AIの提案コードがどう変化するのか見てみます。

ターゲット

• AI の出力修正に時間を取られているエンジニア
• 長期運用中のレガシーシステムや、厳格な独自規約を持つプロジェクトに携わっている方
• チーム全体のコード品質均一化を目指す、2〜5 年目のリーダー層

曖昧な指示を排除し、意図通りに動かすプロンプトエンジニアリングの基礎から、標準規約とレガシー規約の共存テクニックまで。
明日からチームの Copilot が「新人」から「熟練の古参メンバー」へと変わる、実践的な育成技術をお持ち帰りください。