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

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

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

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

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

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

話す予定

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

想定読者

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

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

ChatGPTが登場して約3年。設計ドキュメントやコードの書き方、デバッグの仕方まで、仕事の進め方が大きく変わった方も多いのではないでしょうか。

私たちホライズンテクノロジーは、エンジニアが8割を占める会社です。新規事業の立ち上げから開発・運用まで、エンジニアリングを軸に多くのクライアントを支援しています。
特にこの１年間、事業企画・サービス開発・QA・運用といったあらゆる業務にAIが取り入れられ、従来の役割やプロセスは大きく変わりました。
私たちはその変化を踏まえ、エンジニアが楽しみながらチャレンジを通じて成長できる組織をどう設計するかを考え直しました。

本セッションでは、これまでの実践や経験を踏まえ、

• AIがエンジニア組織に与えた具体的な影響
• 組織設計や人材育成で実践している工夫
• これからのエンジニアに求められる姿勢
  などを共有します。

新卒で入社した私が初めて足を踏み入れたコミュニティが、PHPカンファレンス福岡2017でした。
壇上で語られる技術への情熱、会場を包む一体感。
「自分もこの熱量の中に飛び込みたい」その衝動のまま、気づけば3度LT登壇していました。
このカンファレンスが、私のエンジニア人生を形作る場所になりました。

数年後、部門長として予算を預かる立場になり、スポンサー費用の判断を求められた時、迷いはありませんでした。
あの日背中を押してくれたこの場所が、今度は後輩たちの背中を押す場所になっていたからです。

立場が変わるたびに見える景色が変わりました。
参加者として興奮し、登壇者として挑戦し、スポンサーとして支える。
それでも変わらないものは、人が出会い、刺激し合い、共に成長していくこの場所の価値です。

新卒から部門長への8年間。PHPカンファレンス福岡と共に歩んだ私とFusicの物語をお届けします。

本講演は2016年から続けている「PHPで堅牢なコードを書く」シリーズの最新版です。

PHPはバージョンを追う毎に機能が強化され、堅牢なコードを書くための機能が充実してきました。本講演ではPHP 8.4（および 8.5）をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。

参考:
PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計
https://speakerdeck.com/twada/php-conference-2016

予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント
https://speakerdeck.com/twada/growing-reliable-code-phperkaigi-2022

PHPが登場して30年、さまざまな言語が現れてはWeb開発に新たな可能性が開かれてきました。
新しい言語やフレームワークにはPHPが実現したものを取り込んだもの、野心的なパラダイムを打ち出したものも多くありますが、しぶとくもPHPを完全に置き換えるには至っていません。

本トークでは歴史と多言語での実装事例を踏まえてPHPとWebの過去と現在の立ち位置を再確認して、未来の姿を占います。

• 前PHP時代 〜 Rasmusは何を革命したのか
• Webフレームワークの中世期断絶
• PHPが往かなかったWebフレームワークの世界線 〜 普通の奴らの上を行け
• 非同期I/OとWeb 〜 PHP最大の弱点と次世代への夢

概要

従来のPHP環境でリアルタイム通知を実装する場合、Node.js等を組み合わせた複雑なインフラ構成は悩みの種でした。
FrankenPHPではこの課題を解決するためにMercureが内蔵されており、PHPスタック内でシンプルかつ高速なリアルタイム通信を実現しています。
本セッションでは、実際に動作するアプリケーションの動作デモを交えながら、以下の技術的なポイントを紹介します。

話すこと

• 従来構成での実現の難しさを再確認する
• FrankenPHPがリアルタイム通信を実現する流れの紹介
• WebSocketとServer-Sent Events(SSE) の技術概要と差異
• FrankenPHPを使ったリアルタイムWebアプリケーションの具体的な実装方法と実演

話さないこと

• Mercureの技術詳細

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

外部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）を作り、動かしてみる…その無謀な挑戦の記録です。

今や AI 全盛の時代。コーディングの多くを Coding Agent に任せることが一般的になってきました。私自身も、簡単なタスクであれば積極的に AI に頼っています。

しかし、AI も万能ではありません。指示が曖昧であれば、同じファイルに処理を詰め込みすぎてしまったり、結果としてコードの可読性やアプリケーションのパフォーマンスに悪影響を及ぼすこともあります。そのまま開発を進めてしまえば、後からの保守や拡張も難しくなってしまうことでしょう。

AI 時代の今こそ改めて「プログラミングの基礎」や「PHP の基礎」を理解することが重要です。本セッションでは、その土台となる知識を整理し、AI と協調して開発するための実践的な視点をお伝えします。

PHPの次期メジャーバージョンであるPHP 9.0に向けて、ライセンス変更の議論が進んでいることをご存知でしょうか？現在のPHP Licenseは、GNU General Public License（GPL）と互換性がなく、ソフトウェアの再配布時に制約が生じる状況になっています。将来、現在の独自ライセンスから、三条項BSDライセンスに移行されるかもしれません。

本トークは、OSSに関心のあるPHP開発者や、ライブラリ公開を検討しているエンジニアを主な対象としています。PHP Licenseの歴史や現在進行中の議論を紹介するとともに、OSSライセンスの基礎を初心者にも分かりやすく解説します。OSSライセンスの互換性にも触れながら、OSSにコントリビュートする場合や、自作ライブラリを公開する際に役立つ実践的な知識を紹介します。

私はdeckというMarkdownファイルからGoogle Slidesのプレゼンテーションを生成するツールを開発しています。
https://github.com/k1LoW/deck

Markdownからプレゼンテーションを生成もしくは実施するツールは既に数多くあります。
一見単純な機能ですが、後発のdeckは明確なコンセプトを持って開発をしています。

• 継続的なプレゼンテーション作成
• コンテンツとデザインの分離

なぜこのコンセプトに至ったのか、そしてそれをどのように設計・実装したのか。
本セッションでは、ゼロからv1リリースまでのdeckの設計と実装の変遷を追体験できるように構成します。
単なる一つのOSSの例ですが、小さなプロダクトが多くの人に受け入れられるようになるまでの設計と実装のログです。
皆さんが自身のプロダクト開発に役立つ気づきを得るきっかけになれば幸いです。

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下げをするものではありません

決済システムを長年運用してきた経験から得たTipsを語ります。
最大で1日約300億円の決済があるシステムを運用していました。
その決済負荷に対してどのような対応をしてきたかをお話しします。

ECのトレンドとして、以前はアリババのように1日単位でGMVを最大化していましたが、最近はユーザーの購買行動を分散させるために数日続けるキャンペーンが増えてきています。
システムを安定化させるためにはこのようにビジネス側の設計も必要になると思います。

現場で実際に効果があった施策を中心に以下についてお伝えします。
・データベース設計
・負荷テスト
・バッチ設計

教科書では学べない現場のTipsを決済・金融系のエンジニア向けにお届けします。

エラーが発生したとき、ログを追ったりデバッグを繰り返したりするのは大切な作業ですよね。でも、それだけだと「エラーが起きた後の対処」に留まってしまいます。もっと良い方法があるとしたら？

設計の段階から、エラーが「見つけやすい」仕組みや「そもそも起きにくい」コードの書き方を取り入れることで、システムの信頼性がグッと上がり、あとから困ることも減ります。

このセッションでは、例外の基本的な役割や考え方から始めて、PHPやJavaのように例外を持つ言語と、RustやGoのように例外を使わない言語のエラーハンドリングを比較。それぞれの特徴を活かした設計方法をお話します。難しい話だけでなく、「こうすれば実務で役立つ！」という具体例も紹介しますので、チームのディスカッションにもぜひ活用してください！

「DDDは難しい」と思っていませんか？実はコア業務の定義と依存関係の整理こそが成功の鍵です。

レセプト業務という複雑ドメインで法改正に挑んだ実体験から、「何をコア業務とするか」「何に依存させて何に依存させないか」という依存関係の設計がシステム全体の安定性をどう変えるかをお話しします。

コア業務を安定させた結果、以下の効果がありました。

• 開発プロセス全体が改善
• スキーマ駆動開発が自然に導入できる
• チーム間の調整コストが激減

依存関係の逆転によってスキーマ自体も安定化。その安定度を高める具体的施策も含めて、理論より実践重視で解説します。
3年に一度の大規模法改正に立ち向かった実話の例とともに、段階的にアーキテクチャを進化させていくための、現実的な道筋をお伝えします。