トーク

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のテスト実行時間を大幅に短縮するための実践的なテクニックをご紹介します。

設計について話をすると、実に多くの「◯◯概念」「◯◯原則」が付いて回ります
あるいは、「良い設計を考えよう」とか「設計を学ぼう」とかして、多様な知識が必要で大変だ！と感じた事はありませんか？

全く逆のアプローチで
「たった1つの軸を決め、多くのことを説明できないか」と考えてみましょう
その拘りは、あなたの設計の地力の向上に繋がるはずです

今回は、その回答に 「フィードバック」に注目する という提案をします

フィードバックとは、何かを伝え、その反応を受信することであり、
関係性に意味をもたらすものとも言えます

この「フィードバック」という眼鏡を通じ、システムを覗き込むと？
──設計について多くを語る武器になり得ます
ソフトウェアにとどまらない、組織についても使える武器です
分割、配置、バランス、そこから生まれる相互影響について、
よりシンプルに思考し尽くせるようになるでしょう

AIエージェントがコードを生成する時代、エンジニアに求められるスキルは根本から変わりつつあります。
単なるコーディング速度ではAIに太刀打ちできない今、必要なのは「AIに正確で効果的な指示を出す力」。そしてその力の本質は、設計論という“共通言語”にあります。SOLID原則、デザインパターン、クリーンアーキテクチャなどの知識は、AI時代における最強の武器となるでしょう。
本セッションでは注目の「スペック駆動開発」にも触れながら、設計力がどのようにAI協働を支えるのか、実例を交えて掘り下げます。
今こそ、設計を学びなおす絶好のタイミングです！

現代のPHPフレームワークでは、Dependency Injection(DI)が標準機能として組み込まれ、その有用性は広く認知されています。
しかし、既存の動いているアプリケーションへ適用するにはどうすれば良いでしょうか？

本トークでは、実運用されているレガシーアプリケーションや、Ray Di for Laravel など、複数のDI適用事例を基に、実践的な戦略を共有します。
フレームワークとユーザーコードの境界線、既存のライフサイクルに配慮した依存性注入の活用、マーカーパターンによるルートオブジェクトの識別など、既存アプリケーション特有の課題と、その解決策を具体的なコード例と共に紹介します。

本トークを通じて、既存アプリケーションにDIを導入する際に考慮すべきポイントを持ち帰っていただき、明日から実践できる知見を提供します。

VAddyでは、Webの脆弱性診断ツールをSaaSで提供しています。
2015年から10年ほど運営しており、現在までに60万件以上の診断を実施してきました。
誰でも手軽に使えるセキュリティツールを目指すVAddyの話をする予定ですが、趣味でやっているPHPのネットワークプログラミングについて話す可能性もあります。

多数の副業エンジニアが活躍する株式会社coco。私たちは、全国の「お店」で使われる現場接客DXサービスを開発・提供しています。
副業エンジニアの活躍の秘密は、完全リモートワーク（社員も全員！）、柔軟な働き方、ドキュメント整備や非同期化ワークフローの徹底などにあります。
cocoでは副業、社員ともにエンジニアを積極募集中です。福岡にいながら東京のスタートアップ企業で働ける。そんなcocoについてお話しします。

OJTプロジェクトでOpenAI APIをcurlで呼び出していたのですが、プロンプトやAPIクライアントの管理が煩雑になりました。

そんな時社内にてAWS Strands Agentsの話を聞き、LaravelにもAIを効率的に実装する方法があるはずだと調査したところ、LarAgentというフレームワークを見つけました。

LarAgentを使うことで、AIエージェントの定義と呼び出し部分を簡単に分離でき、実装ロジックが単純になりました。
また、artisanコマンドでエージェント生成ができ、#[Tool]属性を活用することで、エージェントのFunction Tools定義が簡単になり、従来のJSONによるAPI呼び出しから解放され、認知負荷を大幅削減できました。

LarAgentを使うことで、新卒の私でも簡単にAIエージェントをつくことができました！その体験を皆さんに共有します！

Eloquent ORMはLaravelのコアを成す機能といっても過言ではありません。
しかし、少ない記述量で多くの処理を書くことができる一方で
モデルにいろんな知識が集約されていくとすぐにFat Model化してしまいます。
ではEloquentを諦めてRepositoryを導入するのか？

いやいや
せっかくLaravelを使うならEloquentでもう少し頑張りたい！

そのためにどんなことができるのか、Laravel歴1年ちょっとの新人が考えてみました。

弊社で運用しているサービスの一機能である検索機能は、数百万件以上のデータを対象に、ユーザから毎分3,000件以上もの検索リクエストが送られています。
検索機能のミドルウェアにはAWS OpenSearch Serviceを利用していますが、現行バージョンがEOLになる見込みがあり移行が避けられない状況でした。
移行にはアプリケーション側の修正も必要で、移行中にダウンタイムが発生するとサービス提供に影響が生じ、インシデントに繋がる可能性もあります。

本発表では、運用中のサービスを止めず・壊さず、段階的リリースやコードの移植を通じて実現したゼロダウンタイム移行の手法、移行を通じて浮上した移行しにくい設計、今後の設計改善についてお話します。

ターゲット

ミドルウェアのバージョンアップを実施・検討している方
ゼロダウンタイムでのリリース手法に興味がある方
既存設計の改善に興味がある方

サービスAとサービスBがつながればいいのに…！
そんなもどかしさを感じたことはありませんか？今の時代、自分で簡単に作れます！

この発表では、私のいくつかの隙間ツールの開発の経験から得た知見や恩恵と、昨今のAIによるコーディングを活用すると如何に簡単に隙間ツールが開発できるかについて発表します。

隙間ツールとは隙間家具と比べて個別の事象に対して書かれたコード（ツール）のことを示しております。
隙間家具OSSとは: https://speakerdeck.com/fujiwara3/ecspresso-meetup

私が開発した隙間ツールの例

• PHPの公式ドキュメントのサンプルコードをPHP Playgroundで実行できるChrome拡張
• 某サービスのリリースノートをGitHub PagesでRSS化するツール（PHP製）

標準で備わっている多種多様な関数たちはPHPの大きな魅力です。

array_merge() や implode() のような定番の関数がある一方で、
「えっ、こんな関数あるのぅ〜〜〜ぅん！？」と思ってしまうような、
ちょっとニッチで味濃いめな関数も存在します。

今回はそんな"気になる関数"を取り上げて、
背景から意外な使い方までざっくばらんに紹介していきたいと思います。

まだ内容は調整中ですが、5分で「へぇ〜」がひとつ増える
そんなトークを楽しくライトにお届けする予定です！

PHPのロゴがどんなデザインか、皆さんは即座に思い浮かべられますか？
「たしか楕円…」「青と紫の中間色？」「このロゴって何代目？」「っていうか背景色あったっけ？」など、さまざまな思いが頭をよぎるかもしれません。

「知ってるつもり」だったPHPロゴについて、公式ドキュメントをベースに正しい仕様を紐解いていきたいと思います。
スライド作成中に「あれ、どのロゴが正しいんだっけ」と迷った経験のある方、一緒に答え合わせをしてみませんか？

対象者

• 資料作成などでPHPロゴを使ったことがある方
• PHPロゴの正しいデザインを覚えて帰りたい方

話すこと

• PHPロゴクイズ
• 正しいロゴの仕様確認
• 入手方法と使用ルール