トーク

AIの進化によりコーディングエージェントの利用が一般的になってきました。
様々なツールを使い分けて利用している方も多いのではないでしょうか。

ところがいざ使ってみると

• 開発効率の向上
• 出力されるコードの品質
• そもそもの導入目的の達成可否
  といったことが十分でないと感じるタイミングがあるかもしれません。

本セッションではLaravelプロダクト開発におけるこれらの課題を解決するため
AIの活用で高めるべき事柄に焦点を当てます。
効率と品質を両立させ、高いアウトカムを実現するための具体的な整備・実践・意識すべき点を
プロダクト開発チームの実例とLaravel特有の取り組みを交えながら解説します。

複雑さという概念をご存知でしょうか？プログラムは放置しておくと、際限なく複雑になっていきます。この複雑さは、プログラムそのものから発生するものはもちろん、インフラやミドルウェアなどのアーキテクチャー設計、さらにはチーム体制や組織設計から発生するものまで、多種多様な発生源から現れます。本トークでは、プログラムにどのようにして複雑さが入り込むのかをマクロな視点、ミクロな視点の両方から解説します。複雑さが入り込む要因について、解像度を上げることで、今後の開発において複雑さの混入を防ぐ予防的な措置が取れるようになりましょう。

PHPでRustリスペクトのResult型をなるべく使いやすい形で実装するならこうなりそうを話すセッションです。
PHPで制御が複雑になりがちなtry-catchのエラーハンドリングを解消したい人に向けて、Result型を使ったエラーハンドリングを話します。

話す予定

• Result型の説明
• （PHPStanを前提に実装するので）PHPStanの簡単な説明
• PHPで実装したコードの説明
• Aの実装だと使いずらいのでBの実装に変更変えると良さそう
  • @templateを使ったジェネリクスだと複数のエラーを返せない
  • 型のnarrowing
  • 関数を補完してくれないパターン（IDEでの関数補完を効かせる工夫）

想定読者

• Result型を使ったことがない人

※ Rustの知識が必要ないセッションにします

「詳細の決定を遅らせつつ実装を早くする」一見矛盾しているように思えます。

外部APIの選定で悩んで手が止まる、DB設計が決まらず実装が進まない。こんな経験はありませんか？
APIやDBなどは「詳細」と呼ばれるものです。詳細の決定は大事ですが、まずは動くものを作ることが重要です。
動くものを作りフィードバックを得ることで、詳細の決定をより良いものにすることができます。

当セッションでは、「詳細」の決定を待たずに、PHPの柔軟性を活かして実装を進める手法を考えます。
インターフェースで境界を作り、ダミー実装から始めて、詳細を決定していきます。

詳細の決定を後回しにすることは、とりあえず動くものは作ったものの手戻りがある、まるで三歩進んで二歩下がる感覚を持つかもしれませんが、実際には一歩ずつ前進しているのです。
完璧主義から脱却し、仕様未確定でも手を動かせる実装パターンを身につけましょう。

テストコード、書いていますか？

今日において、自動ユニットテストを整備することが開発生産性の向上に寄与することはもはや疑う余地がありません。また AI の活用により、テストコードを書くコストは従来に比べて大幅に減っています。

しかし「テストコードの書き方や導入方法がわからない」「テストコードがあるだけで満足してしまい十分にその効果を発揮されていない」「テストコードが負債化し開発の足枷になっている」などの課題に直面している方も多いのではないでしょうか。

AI がコードを書く時代になっても……いや、むしろ AI がコードを書く時代だからこそ「価値のある」ユニットテストについて一緒に考えてみませんか？

お話しすること

• AI 時代における自動ユニットテストの価値とは
• 価値のあるテストコードを書くための基本的な考え方
• よくあるアンチパターンと処方箋・テクニック

WebAssembly（Wasm）はブラウザ上で動かすだけでなく、複数の言語環境で動くユニバーサルバイナリとしても流行しつつあります。
もちろんPHPの中でもWasmを動かしたいところですが、PHPでWasmを動かすことはまだ敷居が高いようです。Wasmを動かす場合、基本的にはC製のWasmランタイムをPHP拡張としてネイティブコンパイルする必要があり、動かそうとして失敗した報告も多いです。
果たして、一体どうすればもっと簡単にPHPでWasmを動かせるのか…。
今回、筆者は考えました。自分にはWasmのVM自作経験がある。では、PHPでWasmのVMを自作し、その上で動かしてみるのはどうか？そうすれば、C言語不要でWasmの力を享受できるはず！
ということでこの発表は、PHPでWasmのVM（のPoC）を作り、動かしてみる…その無謀な挑戦の記録です。

ChatGPTやClaude Codeなどの生成AIツールの登場によりコードの自動生成や設計補助を一瞬でこなせるようになり、開発のスピードはかつてないほど上がりました。
しかし、システムの価値を決める設計の心臓部である中核の業務領域のモデリングや設計判断は、いまだ人間の理解と経験が不可欠と考えています。
本セッションでは、『はじめてのドメイン駆動設計』で紹介されている「中核の業務領域」に焦点をあてドメインモデリングを行う方法、それ以外の領域で生成AIを活用する事例を発表します。

• 設計を取り組むべき「中核の業務領域」について
• ドメインモデリングを活かした具体的な実装例
• 「中核の業務領域以外」でAIツールを効果的に使うポイントについて

このセッションを通じて、AI時代でも揺るがない設計の軸と、生成AIを使った開発を上手く共存する方法を持ち帰っていただければ幸いです。

皆さんのコードは捨てやすい設計になっていますでしょうか？
現在私がリードを勤めているチームでは派生元となったチームの思想を引き継ぎ、「捨てやすい設計」を意識して開発を行なっています

でも捨てやすいって一体どういうことなんでしょうか？

このトークでは実際の開発現場で我々が日々取り組んでいることをお話しするとともに、
失敗したことによって再認識した「捨てやすさ」について実例やコード例を元に紹介します

このトークを聞いて「10分以内に機能を消せる状態」を一緒に目指していきましょう！

元々PHPerだった私は、2025/03に転職をし、Gopherとなりました。
まだまだGoの知見は少ないですが、そんな中で感じるPHPの良さについて話します。

当然ながらGoの良さはたくさんあり、パフォーマンス、静的型付け言語、シンプル、ゴルーチンによる並列処理 etc...
しかしながらPHPも進化を重ね、非常に優れた言語となっています。
高速かつ安定したPHPの実行を可能にするPHP-FPM、膨大なライブラリとコミュニティの知見、Laravelのような至れり尽くせりなフレームワーク etc..

Goと比較しつつ、PHPの良さを語ります。
※Go下げをするものではありません

PHPカンファレンス福岡は10周年、そのカンファレンスのコアになっているPHPが30年の歴史で世界の79.2%のWebサイトを支える理由はなんでしょうか？

歴史：1994年Rasmus Lerdorfの「Personal Home Page Tools」、Zendエンジン誕生まで歴史から設計思想を知り、
現在：PHP8のJITコンパイラ、Laravel・Symfonyエコシステムなど、2025年における実践的価値を理解し、
未来：なぜ650万人の開発者がPHPを選び続けるのか？「Why PHP？」の未来への展望を知る

歴史的必然性から現代の実用性、未来の可能性まで、PHPカンファレンス福岡10周年の今、PHPの真の価値を再評価しましょう

• 対象者:
  • PHP採用検討中の技術者・意思決定者
  • 他言語からの移行検討者
  • PHPの将来性に疑問を持つエンジニア

バグはゼロにできません。だからこそ、起こさないための仕組みと、起こったときの対応力の両方が重要です。
本セッションでは、QAがエンジニアと協働しながら、PR環境の自動生成やFeature Flagsによる安全な開発プロセスなど、予防的な仕組みにどう関与しているかを紹介します。
さらに、Slackでの即応体制やレトロスペクティブへの関与など、インシデント対応におけるQAの役割と、品質文化の育て方についても共有します。
「防ぐ」と「向き合う」両軸を支える仕組みと文化を、実践例を交えてお話しします。

E2Eテストの重要性は理解していても、実行時間の長さがボトルネックになっていませんか？

Playwrightはユーザー体験をテストするE2Eテストツールです。
PHPのテストでよく使われるバックエンド検証のユニットテストツールPHPUnitでは検証が困難な領域をカバーできます。

Playwrightは実際のブラウザを動かすため、ユーザーがWebサイトを操作するのと近い状況でテストを実行できます。
しかし、ユニットテストと比較すると実行時間が長くなる傾向があります。
テストケース数が増加すると、CI/CDのボトルネックとなり、開発者のテスト実行頻度低下の要因となります。

本セッションでは、Playwrightのテスト実行時間を大幅に短縮するための実践的なテクニックをご紹介します。