プロポーザル

PHPUnitにおける「データプロバイダー」とは、1つのテストメソッドを引数を変えて実行する「パラメタライズドテスト」を実現する仕組みです。
#[DataProvider]アトリビュートを使うと実現できるのですが、類似のアトリビュートに#[TestWith]があるのはご存知ですか？

以前はちょっと使いにくかったのですが、最近では#[TestWith]もとても便利になってきていて、私自身#[DataProvider]よりも#[TestWith]を使う機会が増えてきています。

このLTでは、パラメタライズドテストを実現するアトリビュートの種類と、私なりの使い分け方をお話しします。

想定する観客

• PHPUnitを使っているがデータプロバイダーを知らない人
• #[DataProvider]は使ったことがあるが#[TestWith]は知らない人

考えるより感じろ！

「今やってるこれ、何度もやってるな…これ、便利ツールにしたら二度と書かなくて済むのでは？」って思う瞬間、ありませんか？

そんなときにバイブスあるコーディングです！！！

このLTでは、そうした“ノリ”で作る小さなPHPツールの実装Tips、サクッと役立つテクなどを紹介します。
難しい理論や設計の話はナシ！Vibeのままコードを書いて、便利にして、また次のコードへ。

今日のバイブスが明日の時短になるかも。

過去のカンファレンスでOSI参照モデルのプロトコル実装に関する発表を聞いたとき、「自分でも実装してみたい」と思うと同時に、このような“階層による責任の分離”は、コード設計や組織構造にも通じるのでは？と感じました。
OSIが解決している課題や、層が混ざったときに起こる問題を紐解くことで、私たちの設計やチーム運営にも活かせる視点が見えてきます。
本LTでは、異分野から学んだ“構造を守る”ための考え方とその応用についてお話しします。

PHPカンファレンス関西2025ではカンファレンスに初めて来るという方も多くいることと思います。

私が、カンファレンスに参加したときは知らない世界をたくさん見ることができ、大いに刺激を受けた一方で、レッドピルを飲んで真実を知ってしまったような感覚も味わいました。

業務で扱うコードは制約もあり、せっかくカンファレンスで学んだことを活かせないことも少なくありません。

そんな中でも、今日カンファレンスに参加したあなただからこそできることがあります。

このトークでは、カンファレンスに参加したあなたが明日から、自分の周りから少しずつ、改善を始める方法をお話しします。

歴史的にコーディングツールは、高機能なIDE(統合開発環境)とシンプルなテキストエディタに大別されます。
コンパイルが必要な複雑な言語と対比して、PHPのようなスクリプト言語はシンプルなテキストエディタでも開発できる単純な言語と考えられていましたが、昨今ではPhpStormのような複雑なIDEの機能も求められています。

本トークではPhpStormなどがどのような機能を備えているか、EmacsやVS Codeといったツールでどこまで肉薄できるかを追求します。

Gitの仕組みについて解説しつつ、git addとgit commitするまでをPHPのコードでどう実現するかを話します。

話す予定
・Gitでファイルを保持する仕組み（Blobオブジェクト・Treeオブジェクト・Commitオブジェクト）
・git addをPHPで実現するには
・git commitをPHPで実現するには

本セッションではMatthias Noback 氏が著者の「オブジェクト設計スタイルガイド」を通じて、ドメイン駆動設計での手法について入門する発表になります。
まずは、「オブジェクト設計スタイルガイド」を通して学べる「意味あるオブジェクトの作り方」や「ふるまいを持つクラス設計」の考え方を振り返り、そこからドメイン駆動設計で登場するエンティティや値オブジェクト、ユビキタス言語といった基本概念とのつながりを解説していきます。
具体的には以下の内容を通じて、現場での活用方法について紹介します。

• 小さな設計改善が、どうやってドメインモデリングにつながるのか
• PHPでの具体的なコード例（ValueObject、Entityなど）
• 「まずどこから始めればいいの？」という現場向けアドバイス

phperの皆さんはサーバにsshで入って作業することはありますよね?
その際、shell scriptを流したり、vimで編集したり、色々な作業をすると思います。

本ワークショップでは安全に作業するTipsやVimの基本操作、VimでPHPを書く時の便利な方法などを一緒に学んでいきます。

PHP-Parserを利用すると、PHPのコードを抽象構文木 (AST) に変換したり、逆にASTをソースコードとして出力したりすることができます。

ASTの一部を書き換えることもでき、たとえばRectorはこれを利用してソースコードの書き換えを行います。

この技術を利用すると、PHPコードをminifyすることも可能です。
minifyはソースコードの空白の除去や変数名の短縮などにより、ソースコード全体のサイズを圧縮することです。JavaScriptやHTML、CSSでは、ブラウザ↔サーバー間の転送量削減のためによく行われます。

WASMを使いブラウザ上でPHPを動かす事例も増えている昨今、PHPコードをminifyしながらASTの力を感じてみませんか？

想定観客

• 抽象構文木を知らない人
• ASTが何の役に立つか分からない人
• PHPをブラウザで動かしている人

現代の多くのスクリプト言語は行末に ; を必要としないシンタックスを提供している一方、PHPは基本的に式文の終端に ; を要求しているため、他言語からPHPへの参入障壁となっています。このトークではPHPの言語機能を駆使して、コード上に ; を書かずに任意の処理を記述するテクニックを紹介します。

具体と抽象の関係は、プログラムだけでなく実際の仕事でも非常に重要な概念です。

しかしながら、具体と抽象の関係性は、知らなければなかなか気づくことができません。
いろいろなタスクに具体と抽象の関係性を見つけ出し、チームで布教活動を行っていたところ、チームメンバの発案で「具体と抽象 ―世界が変わって見える知性のしくみ」（細谷 功 著）の読書会を行いました。
すると、日々の会話やタスクの進め方にもみるみる変化が...
この発表では、「具体と抽象」に入門し、日常的に使うようになったチームの日常を紹介します。

共通クラスへの仕様追加、みなさんどうしてますか？
私は一度、抽象クラスに処理を書こうとして「これ全テスト壊れるやつだ」と震えました。
Factoryパターンを導入して処理を切り出したことで、影響範囲の限定、レビューの見通し改善、テストのしやすさまで一気に良くなりました。
このLTではその設計改善の実体験を共有します。

「このAPIエンドポイントは絶対に個人情報を返さない」…
そのはずが、ある日、意図せず個人情報を含むレスポンスを返してしまっていた。
考えただけでも恐ろしいこの事態は、残念ながら実際に起こりえます。
本セッションでは、私たちが経験した「個人情報を返してはいけないAPI」から、予期せずそれが返却されてしまったインシデントの事例を共有します。
気づくことができなければサービスが潰れかねませんでした。なぜそのような設計・実装上の欠陥が見過ごされたのか？ どのようにして問題を発見し、インシデントとして対応を行ったのか？
そして最も重要な、具体的な再発防止策として何を導入したのか（テスト戦略の見直し、静的解析、コードレビュープロセスの強化、監視アラート設定など）を、原因分析から得られた教訓と共にお話しします。
対岸の火事ではない情報漏洩リスクに対し、明日から実践できる防御策のヒントを提供します。

PHPのアップデートといえば、新しい文法や関数が使えるようになって開発者体験が向上した！みたいなどちらかというと攻めの意味合いに目が行きがちだと思います。
しかし実際に CVE 対応を検討する中で、OS のバージョンによりパッチの適用に課題が生じた経験から、“守り”の視点の重要性を実感しました。
このLTでは、アップデートにおける“語られない守り”に光を当て、今を守りながら未来を選び取るための向き合い方を共有します。

PHPアプリケーション開発では主にPHPUnitを使い、ユニットテストを書いていると思います。
PHPUnitは個々のクラスやメソッドをテストするのが得意なツールですが、実際のユーザがブラウザを通して体験するJSやCSSまで含めたレンダリング結果や、複数のページ遷移を伴う複雑なフローへのテストは苦手です。
こんな時にPlaywrightを使うとフロントエンドのテストが効率的にできます。実際にブラウザを動かしてテストを行うツールであり、ユニットテストが苦手としている領域をカバーすることができます。
一方でPHPUnitと比べ実行速度は遅く、メンテナンスのコストも高くなる傾向があります。

本トークではPlaywrightでできることを紹介しつつ、PHPUnitとPlaywrightの特性に沿ってテストをかき分けることでテスト時間を短縮し、より安心してリリースできる環境作りを紹介します。

PHPStanは簡単に使い始められる便利なツールですが、レベルを上げようとするとPHPStanの型付けの特性について学ばなければ効果的に型をつけることはできません。本ワークショップではブラウザから動かせるPHPStan Playground上で問題を解くことでPHPStanの型についての理解を進めます。

このワークショップではブラウザ上で動作するPlaygroundとPHPが動作するローカルマシンのどちらでも取り組むことができます。
(ローカル環境でのPHP開発環境について本編時間内ではサポートできません)

PHPの文法について基本的に理解していると望ましいですが、可能な限りサポートします。

以前、別のカンファレンスで「var_dumpとvar_exportの理解から始めるPHPのソースコードリーディング」というタイトルで、
php-src の中身を読んで調べた内容を発表しました。
発表の準備として、改めてvar.cやzend系の関数を読み直す中で、不安だったところを丁寧に確認し、自分なりの理解を深めていきました。
その過程を経て、今ではphp-srcを読むことが自然な選択肢になり、調査や設計判断の場面でも「読んで確認する」ことが当たり前になったと感じています。
このLTでは、発表がきっかけで“読む”という技術の向き合い方が変わった、自分自身の小さな変化を共有します。

近年、LLMの進化に伴い、AIを用いたコーディングが現実のものとなってきました。
しかし、AI Codingには課題も多く、うまくAIが動いてくれない。思ったとおりにコーディングしてくれない。と、もやもやしている人も多いかと思います。
そんなときに役に立つのが呪術廻戦です。
呪術廻戦における呪術の理論体系を参考にAI Codingの課題と性能のトレードオフについて語ります。

MySQL9でのベクトルカラム/ベクトル検索サポートは、PHPアプリケーションにおけるAI活用や類似性検索を大きく変える可能性を秘めています。
プロポーザル提出時は、AWSのRDSで取り扱い可能なバージョンは、8系が最新ですが、特にAWS (RDS/Aurora) 環境での利用が現実味を帯びる中、そのインパクトは計り知れません。
本セッションは、ミドルレベルのPHPエンジニアを対象に、この「ベクトルカラム」導入に焦点を絞ります。ベクトルデータの基本的な概念から、MySQL9で予想されるベクトル型・専用インデックス・検索関数の概要、そしてPHPからこれらをどう扱うか、パフォーマンス考慮点、AWS環境特有の設定や制約についてを説明します。推薦システム、画像検索、セマンティック検索といった機能の実装がどう変化するのか？何を学び、どう備えるべきか？ 未来のキラー機能開発に向けた勘所をお伝えします。

Laravelでの検索実装、「全文検索」と「セマンティック検索」の選択に迷っていませんか？
それぞれに利点があり、プロジェクトの特性に合わせた最適な選択が求められます。

本セッションでは、Laravel Scoutによる使い慣れた全文検索と、Typesenseなどを用いた高精度なセマンティック検索と検索のテスト手法についてお伝えします。
具体的な実装パターン、気になるパフォーマンスの違い、導入から運用までのコスト感を、コード例を多めに交えながら比較検討します。
「結局、自分のプロジェクトにはどちらが合うのか？」その疑問に明確な答えを出す、実践的な選択ガイドラインとインデックス戦略や関連性チューニングといった、導入後の運用で直面しがちな課題と具体的な対策も共有します。