PHP コードの正当性は、テストや静的解析によって保証するのが一般的です。

しかし実際には「このメソッド呼び出しが正しいことは、どのテストで保証されていたっけ？」と確認を要する場面や、静的解析ではカバーしきれないコード構造も現実には多く、必ずしも安心とは限りません。

このセッションでは、コード自身が自分のやろうとしていることの正当性をその場で保証する "Self-Validating Code" というアプローチを紹介します。

テストや静的解析を補完し「この処理は確かに正しい」とコードの内側で完結して確認できる仕組みが、開発体験をどう変えるかに注目してみましょう。

Laravel アプリケーションに導入した具体例をもとに「正当性の保証がコードの外部に散らばっている」煩雑さをどう減らせるか、それが Fail Fast や防御的プログラミングとどう違うのかも整理してお話しします。

書いたその場で、正しさを信じられる。そんなコードを書くためのヒントをお届けするセッションです。

スナップショットテストは、複雑な出力の変化を検知するための便利な手法で、主にフロントエンド領域で発展してきました。近年では PHP においても導入されるケースが増えてきました。

しかし、テストの削除やリネーム、アサーションの回数の変化などにより、使われなくなったスナップショットファイルがリポジトリに残り続けてしまうという問題があります。これらの不要ファイルは徐々に蓄積し、リポジトリを散らかすだけでなく、レビュー時の混乱や誤認、さらには技術的負債や開発者のミスの温床となる可能性もあります。

この問題は長年にわたり認識されているにも関わらず、未だ決定的な解決策が存在しません。大規模なモノレポ環境で複数言語や複数スナップショットライブラリが併存し、独自のカスタマイズも加わっている状況では、汎用的な解法を構築するのは特に困難です。

この LT では、そうした課題に対し、使われなかったスナップショットを自動的に検出し、現実的でシンプルな解決策を提案します。

MCP（Model Context Protocol）の仕様が 2025/03/26 に更新され、MCP サーバをステートレスな HTTP サーバとして実装可能になりました。

そうなったら我々 PHPer のフィールドですね？

本トークでは MCP サーバの仕様を説明しながら、フレームワークも Composer さえも使わない、非常に小さな PHP 実装例を紹介します。

このトークで扱う内容

• MCP とは何か？
• MCP サーバの仕様
• Streamable HTTP Transport による MCP サーバの実装例

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

LLM、生成 AI、 MCP といったものに関する

• 具体的な活用事例
• すぐに役に立つ知識

「パフォーマンス調査をしたら凄まじい数のクエリが発行されていた」という経験、ありませんか？
私自身、重いバッチの調査でRDSのPerformance Insightsを見てひっくり返ったことがあります。

これが有名な「N+1問題」ですが、バッチやCSV出力といった大きめのデータ処理で陥りやすい問題の代表例かと思います。
その一因として、Laravel標準のORMであるEloquentでは、リレーション取得をループすることで意図せず大量のクエリが発行されてしまうことが挙げられます。

一方で対策は比較的簡単で、withメソッドを使用してEagerロードさせることで、リレーションデータも1回のクエリで取得することができます。
しかし、安易に「親データの取得時にwithメソッドを呼び出せば解決」と考えていると、思わぬ罠に嵌まる可能性があります。

本LTでは私の失敗を出発点として、Eagerロードさせる上での注意点からEloquentのリレーションの仕組みまでお話しします。

トピック

• N+1問題とEagerロード
• 動的プロパティ（$user->posts）とリレーションメソッド（$user->posts()）

配属されたPHPプロダクトは、次につくる機能が決まっていませんでした。

私が担当することになったプロダクトは、立ち上げ時に想定していた機能をつくりきった状態でした。
しかし、ビジネスチームのメンバは他のタスクに追われ、次の開発方向性をなかなか決められず、小さなバグ修正や軽微改善のタスクばかりが提案される危険がありました。
そのため、次の一手をビジネスチームと一緒に考えることになりました。しかし、今までの開発チームはビジネスサイドからの要求を実装することがメインの仕事であり、主体的に開発の方向性を考えられるようになるためには、開発フローやいくつか"仕掛け"が必要でした。

このトークでは、ビジネスチームに頼っていた開発チームを、主体的に動けるチームに変えるために行ったことについてお話しします。

「PHPってWebサーバー上で動くもの」——そんな常識をNativePHPは打ち破ります。
2025 年 4 月に正式リリースされた NativePHP for desktop について解説していきます。

Electron やTauri のようなクロスプラットフォームなデスクトップアプリが主流になる中、
私たちが普段使っている PHP でも実現できる時代が来ました。

NativePHP を使えば、PHP でデスクトップアプリが作れちゃうらしい！
そんな知らせを聞いて、手を動かさない PHPer はいない！
実際にデスクトップアプリを作成して、見えてきた魅力や気づき、課題について率直にお話しします。

Web の外へと飛び出した PHP の勇姿を、ぜひ見届けてください。
「PHP もまだまだやれる！」

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

この発表では、オニオンアーキテクチャによって仕様追加による改修が最小限に抑えられた事例について解説します。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

PHPに出会ってまもなく遭遇した奇妙なコード「$$」
まるで変数名が意思を持ち、少し不思議な動きを見せるその子は可変変数と呼ばれます。
本LTでは、可変変数について「変数名が踊り出す」とは一体どういうことなのか、PHP初心者の目線で簡単な例を通して、その基本的な仕組みを紐解きます。
便利な機能にも落とし穴はつきものです。可変変数を使うと、なぜコードが分かりにくくなってしまうのか、本当に使い所はないのか？について発表します！

対象者
・PHP初心者
・変数という概念は理解しているが、可変変数についてはまだ知らない方
・可変変数の使い所がわからない方

はじめに

PHPの最新版は8.4になり、かなり進化しました。7.0が出たのはすでに10年前。
巷ではモダンなフロントエンド技術が流行っており、PHPerは圧倒的な高齢化の一途を辿っています。
「うちの会社は割と若い人もいるよ！」と思ったそこのあなた。では一番コード書ける人、一番技術力ある人も同じく若い人たちですか？

10年前、第一線で活躍してた人が今もポジション変わらずの状態であればイエローサインです。
PHP界の高齢化を防ぎ、若手が育ちやすい“新陳代謝のある”文化をつくっていきましょう。

ちなみに私は過去COBOLのプログラマーを「おじいちゃんばっかりじゃん」と思っていた時期がありますがそんな自分を殴りたい。

話す内容

• PHPは素敵な言語
• 勉強会による間口を広げるご提案
  • 老害化の注意点
• 他言語とのコラボを狙う
  • 例えばSPAのフロントはJS、API側PHP、というご提案
• PHPの普及ではなくPHPで作られたものの普及を考えてみる
  • 言語の良さを説いても限界がある
  • 魅力的なPHP製品の良さを伝えて、メンテをする楽しさを伝えてみる。WordPressとかEC-CUBEとか

技術の話よりかはPHPerのコミュニケーションの話です。
意見も聞きたいので、みなさんにも意見を聞きながらセッションを進めて行きたいと思っています。
一緒に高齢化阻止の方法を考えましょう

こんな人は聞いてほしい

• PHPの良さを改めて知りたい人
• PHPの良さって何なんですか？と言われてアピりたいけど答えに詰まってしまう人
• 最近若い人減って来たなぁと嘆いてる人
• もっとPHPerを増やしたい人
• ↑のように思ってるのに若者にマウントを取ってしまう人

概要

時は2025年、AIエージェント元年と言われるこの世の中では「人よりもAIが仕事ができる」という噂が囁かれる事態となりました。
ですが、果たして本当にそうなのか。AIは人並みに仕事してくれるのか？我々のような老練のPHPerが立場を危うくするほど驚異的なものなのか？

本セッションでは、自律型AIエージェントプログラマー「Devin」について実際に使ってみた感触と、PJメンバーとしての有用性についてお話します。
今みなさんが気になってるホットなAIエージェントの話題をPHPer的な視点から掘り下げます。

トピックとしては以下です

• コードのクオリティーについて
• 仕様をどこまで理解してくれるのか
• Unit Testとかも書いてくれるの？
• リーダブルコードを考慮して書いてくれるのか
• PHPのVersionは考慮してくれるのか
• 結論、有用なのか否か

対象者

• PHPer
• AIに興味がある人
• AIに焦燥感を抱いてる人、大丈夫でしょうと高をくくってる人
• Devinについて情報収集してる人

得られるもの

• AIエージェントはどんな仕事をしてくれるのか
• AIエージェントへの指示（プロンプト）の効果的な与え方はどうすれば良いのか
• 自社で導入する時に評価できる・できないポイントがどこにあるか

私は今、受託開発の会社に勤めていますが、受託開発だと複数案件に関わることはあるあるだと思います。
ただ、参画したタイミングや状況により様々なポジションや開発言語で案件をかけもつことがあります。
時にはマネージャーとして管理を行い、時にはメンバーとして開発を行う。イレギュラーな事態は毎日発生し、考えていた進捗まで中々届かない。。
このLTはそんな中で自身を管理しつつ各案件をなるべく燃やさずに進めている方法をお話します。

対象者

• Laravelを使用している開発者（初級〜中級）
• コード品質向上に関心のあるPHPエンジニア
• 静的解析をこれから導入したいと考えているチーム

セッション概要

型エラーや未定義変数のアクセスなど、実行前にコードの問題を発見できる静的解析ツールは、モダンPHP開発の必須ツールとなっています。本LTでは、Laravel向け静的解析ツール「Larastan」の導入から実践的な活用方法までを5分間で簡潔に解説します。Eloquentモデルやファサードなど、Laravel特有の型安全性課題に対する解決策を中心に、明日から使える実践的なテクニックをお伝えします。

名前の似た機能の実装を集約して、複数のドメインと機能でテーブルとAPIを共有する。

この設計アイディアによって、弊社機能の立ち上げは部分的には加速しましたが、サービスの成長に伴い高いコストをもたらしました。
この設計アイディアを社内では「汎用テーブル・API」と呼んでいます。

本トークでは、「汎用テーブル・API」がどのようなコストをもたらしたか、ドメインと機能の境界に沿ってテーブルとAPIを分割するまでの道のりを具体例を交えてお話しします。

以下の内容をお話しします。

• 「汎用テーブル・API」とは何か、どのようなコストを発生させているか
• ドメインと機能の境界に沿って分割するまでの具体的な手順

対象者:

• バックエンドの技術負債に向き合っている方
• DBテーブルのデータ移行に興味のある方

DB負荷問題に直面した時、インデックス、クエリチューニング、キャッシュ… 私たちは反射的に技術的な解決策を探しがちです。
しかし、本LTでは「ちょっと待ってください！その負荷、本当に技術だけで解決すべき問題ですか？」と問いかけます。
私たちがアプリのタイムライン機能で経験した、深刻なDB負荷との戦い。
そこで見出したのは、技術的な複雑化に頼るのではなく、「仕様そのものを見直す」という、シンプルかつ強力な解決策でした。

本トークでは以下の内容をお話します

• なぜ私たちが技術的対策の前に「仕様変更」に踏み切ったのか
• その結果、いかにDB負荷を劇的に削減できたのか（嬉しいことにUXも向上しました！）
• 仕様変更という負荷対策のアプローチについて

対象者:

• DB負荷をはじめとするパフォーマンス問題に悩むWebアプリケーションエンジニア
• 要件定義や仕様策定の段階からパフォーマンスを意識したい方
• プロダクトの持続可能性とユーザー体験の両立を目指すプロダクトマネージャー

DB負荷対策の引き出しに、技術的アプローチと並ぶ選択肢として「仕様変更」を加えることの有効性を、具体的な事例と共にご紹介します。

いまやPHPの根幹を成すComposer

意外と「なんとなく」使ってる方もいらっしゃるのではないでしょうか？
そんな方々に、「Composerの仕組みもバッチリ知ってるよ！」となって帰って頂ける内容をお話します。

1. なぜComposerを使うのか？
   ・「車輪の再発明」は絶対やめよう
   ・ 成熟したPHPコミュニティ、あなたが作ろうとしている機能、大体あるんです
   ・ 複雑な依存関係を理解しよう

2. Composerはどのような仕組みで動いているのか？
   ・ packagistとComposerの関係について
   ・ composer.jsonとcomposer.lockの役割について
   ・ autoloadの仕組み、説明できますか？
   ・ ライブラリのバージョン、理解してますか？

3. Composerは遅いのか？
   ・ プロジェクトにおいて、Composerを使わず、手動requireした方が速いのか？否。
   ・ 大規模プロジェクトでのComposerの最適化テクニック

4. どんなプログラムをパッケージとして頒布するべきか？
   ・ もう、プロジェクト間のコピペはやめよう

ブラックボックス的な印象の強いComposer、これを機に、仲良しになりましょう！

Agenda

1. What is DDD x Clean Architecture?
2. What kind of systems is it suitable for?
3. How was the actual implementation in Laravel?
   • What steps were taken to introduce it?
   • What kind of structure was used for the implementation?
   • Good points and bad points

※この資料の内容で話します！日本語版に直すのも可能です。
https://speakerdeck.com/bumptakayuki/laravel-x-clean-architecture

あなたのPHPコードはif文の中にたくさんの条件を連ねて条件分岐していませんか？
可読性の下がりがちな条件分岐、実はもっと読みやすく・テストしやすくすることができるんです！
Specificationパターンを使ったリファクタの実例をライトニングに紹介します。

PHPに限らず、プログラムは繰り返しても劣化しない正確さと速さが持ち味です。人間は繰り返すと集中力が落ち、集中力が落ちると正確さと速さが劣化しがちですよね。
私は素早く開発することを突き詰めた結果、定型的なPHPコードは自分で書くよりPHPに書かせた方が早いと考えるに至り、さまざまなコード自動生成を日々試してきました。
2025年、AI時代に入って、世間のPHPerの皆さんもコード生成を始めていると思いますが、単に自然言語でプロンプトを投げては生成ガチャを引くだけになっていませんか？
私は、作業ログを読み込ませたりコンテクストの与え方を工夫するよりも、AIとPHPを組み合わせて利用することで「退屈な仕事」はPHPに任せてガチャの範囲を狭め、より効率的にコード生成を行えるのではないか、という仮説に基づいて実験をしています。その結果を報告します。

PostgreSQLにはRow Level Securityがありますが、PHPを使った開発プロジェクトではほぼ使われていないのではないでしょうか。
Row Level Securityを使ってLaravelでアプリケーションを開発するにあたって、私はEloquent ORMとDoctrine ORM両方でコードを書いてみて、開発者体験を比較検討してDoctrineを選択しました。どういう判断でDoctrineを選んだか、2年半に渡って実際に開発に使ってみてどうなったかを共有します。

• Row Level Securityとはどんなものか
• EloquentでRow Level Securityを扱う方法の解説
• DoctrineでRow Level Securityを扱う方法の解説
• Eloquent vs Doctrine そして結論

「HowじゃなくてWhyで考えよう！」なんてセリフを良く聞きますね。
その一方で、設計について聞くと「○○設計を踏まえていて〜」と返答をもらうことも、しばしば。

ローカル変数の命名1つをとっても、フレームワークやインフラストラクチャの選定にしたって、
一気通貫の「なぜ設計をするのか」「どんなものが必要なのか」の考え方があるはずです。

それが「トレードオフを見極め、織り込み、決定する」ことです。
これこそが「設計行為である」という立場からトークをします。

抽象的で、広いスコープに届くような話を、なるべく具体的で卑近な例を取り上げながら説明していきます。

話すこと

「Why」としての設計

• ソフトウェア開発の最終目的である「品質」 = ユーザーにとっての価値実現
• 求めるべき品質を可能な限り摩擦ゼロで実装する支えが「設計」

取り上げる話題の例

• 「テストしやすくする」時に、何を天秤にかけているのか
• 「YAGNIだ、だからやめよう」は何を捨てているのか・拾っているのか
• ベテランに聞いてみました！ "「設計的な判断をする」時に、何を考えていますか？"