トーク

PHPを社会人になって初めて触りました。またLaravelというフレームワークを知りました。そして新卒だった自分はアプリの初期開発でフレームワークの自由さに魅了され、振り回され、恥の多いコードを書きました。その後、過去の自分が未来の自分を苦しめ、改善を決意し、小さく小さくコツコツと改善を進めました。

本セッションでは自分がどんな恥の多いコードを書いてきたのか、どうやってコード的な側面、非コード的な側面からシステムを改善していけるかを実体験をもとにご紹介していきます。
セッションを聞いた方が「自分と似た経験をしないための知識」、「しくじりを自分の成長に変えていける引き出し」を得られたら幸いです。

話すこと(変更の可能性あり)
・ 設計を知らないで実装をするとこんなことしちゃう
・ 自分が行った小さな改善作業(技術側面、非技術側面)

平均80点ぐらい取れるAWS構成とその使い所と細かいハマりポイントを紹介します

セキュリテイの巻

• rate limitのハマりポイント、WAFとLaravel
• .envに書く内容はパラメーターストアにいれておこう
• ECSはプライベートサブネット(イメージPullできない問題)

コストの巻

• 画像類はなるべくS3に置く(公開したくないやつをlaravelでどうやって表示する？)
• t4gインスタンスいいぞ！（昔はPHPとARMの相性悪かったらしいが）
• ほんとにNginxいる？(Franken PHPでコンテナ一個で運用するのはどうだろう、Nextjsと比較)

動作確認の巻

• ローカルスタックのS3は割と使い勝手が良い
• でも、メールはsmtpでmailtrapとか建てたほうが楽かも
• というかその辺Laravelで良い感じにできる

純粋関数(pure function)という言葉を聞いたことはありますか？ 簡単にいうと、同じ引数を渡せば必ず同じ結果を返す関数のことで、しばしば数学的な関数とも説明されます。

同じ引数で同じ結果ということは確実な再現性があるということで、「純粋」の概念を知って純粋と不純な処理を切り分けられれば、コードを見通しよく、テストしやすいコードにすることもできます。

言葉をトークでは「純粋」および「副作用」という概念について学び、コードを改善するための手掛かりを学びます。

開発が終わってしまったテストフレームワークをリプレイスした事例を元に、技術的負債にどうやって戦ったのかを紹介します。

トーク内容（予定）

• 具体的な課題
  • 開発終了したフレームワークがもたらしていた具体的な課題（メンテナンスコスト、実行速度、新機能への追従困難など）
• 立てた戦略
  • 段階的移行か一括移行か、手動か自動か
• リファクタリングツールの検討
  • rector の紹介
• 得られた成果

最近弊社ではmcpというワードをちらほら見かけます。
そうだ、phpでmcpを作ってみよう！
でも、phpにはmcpのsdkがありません！！😨

mcpとはなんぞや？から、どういうことをすればmcpができるのか？

※まだ何も着手していないので、どこまで紹介できるかわかりませんが
全力でphp&mcpについて紹介したいと思います！

本トークでは、障害対応が特定のメンバーに集中していた状態を見直し、チームで対応できる体制を構築するために取り組んだ内容を紹介します。

私たちは、レガシーな PHP アプリケーションを日々運用しています。
その中で、障害対応が属人化し、特定の人に負担が偏ることが課題となっていました。

この課題に対して以下のような取り組みを行いました。

• 障害対応の予行練習
• 障害振り返り会の実施
• PagerDuty を用いたローテーション制の導入

これらの取り組みにより、障害対応の対応手順やナレッジがチーム内に共有され、属人化から脱却しつつあります。
似たような課題を抱える方にとって、何かしらのヒントになれば嬉しく思います。

PHPのsocket拡張を利用するとsocketプログラミングができ、通信プロトコルもPHPで実装できます。
さらに、RAW socketという機能を使うとOSが管理しているTCP/IPプロトコルもPHPで実装可能です。

今回のセッションでは、

• PHPのsocketプログラミングの基本
• HTTPの実装
• TCP/IPの実装
  の話を通して、はまりポイントやプロトコル実装の楽しさを共有したいと思います。

プロトコルは仕様が決まっていて、その仕様を見てひたすら実装し、最終的にはサーバやクライアントと通信できるようになります。この通信できた時の喜びは非常に大きく、かつ大変勉強になります。通信できるまでの過程も含めて楽しさが伝えられたらと思います。

私のチームが運用するPHPサービスは、全てがEC2で動作し、オートスケーリングにも対応していないレガシーな構成です。
さらに、Laravel・Zend Framework・Yiiという3種類のフレームワークが共存し、構成は複雑を極めています。
TerraformによるIaC導入を進めた私は、社内勉強会中に操作を誤り、本番環境を壊してしまい、サービスが一時停止する事態に。
このトークでは、構成管理が属人化したPHP環境にIaCを導入する中での失敗と学び、環境差異や大量のバッチ処理など泥臭い現場で起きた苦労、そして再発防止に向けた取り組みを共有します。
理想と現実のギャップに悩むPHPerの、生々しい挑戦の記録です。

Laravel 11/12に移行して「Handlerクラスがなくなった！どう構成すべき？」と悩んだ方も多いはず。
例外処理の責任の境界が曖昧になっていませんか？
本セッションでは、例外設計・分類・キャッチの責任を明確にし、保守しやすく壊れにくいLaravelアプリケーションの作り方を紹介します。

扱う具体例:
例外をどこでthrowし、どこでキャッチするかを整理する方法
Laravel 11でExceptionHandler相当をサービスごとに定義し、モジュール単位で対応
例外が増えてきたときの管理方法
CIで異常系テストを実行し、例外が正しく処理されているかを確認する仕組み

このセッションで得られること:
各層でのエラー処理の役割を整理し、例外を分類する方法
Laravel 11/12のエラーハンドリング設計のポイント
「例外が増えても怖くない」CI/CDとテストで品質を保つ方法

「例外＝\Exception、返すのはいつも500…」そんな状態に悩んだことはありませんか？
Laravel 11/12では、ExceptionServiceProviderによってエラーハンドリングの構成が見直され、独自例外による明確な設計がより重要になっています。
本セッションでは、独自例外をドメインルールを表す手段として活用し、保守性と読みやすさを高める設計のコツを紹介します。

扱う具体例
PermissionDeniedExceptionのようなドメインルールを表す例外の設計方法
Laravel 11以降のExceptionServiceProviderの活用法

セッションで得られること
業務ドメインを意識した例外設計による責務の明確化
「なんでも 500」から脱却し、想定外と想定内を分けた異常系設計
Laravel 11/12 での例外処理構成の考え方と実装の勘所

デシジョンテーブル（決定表）といえばテスト設計の手法として知られていますが、PHPでの実装パターンとしても非常に強力です！
複雑な条件分岐をif文の入れ子で書くと保守性が低下しますが、決定表を使えば条件と結果の組み合わせを表形式で美しく整理できます。

登壇者は実際の業務で、条件の組み合わせが数千パターンにも及ぶ大規模な決定表を実装してきました。
この経験から得たノウハウと実践的なテクニックをご紹介します。

• 複雑な条件をわかりやすく可読性を上げる
• 決定表の定義誤りを防ぐ
• 時系列で変化する決定表の表現方法
• 決定表の評価のバグを検知する
• 決定表をアプリケーションだけでなく、テストでも活用する

明日のプロジェクトですぐに活用できる実装パターンをお伝えします。
難解なビジネスロジックをクリアに表現できるPHPのデシジョンテーブル実装に、ぜひチャレンジしてみましょう！

もぅﾏﾁﾞ無理…PHP の array 関数、多すぎぃ〜😵‍💫
array_map とか array_filter とか、似た名前ばっかでﾏﾁﾞで呪文かと思ったし🌀
「どれ使えば正解なん？」「ﾃｶ違いなに？」「ぇ、もう全部 foreach でよくね？（白目）」ってなって、
ｶﾞﾁで心折れた🥀

でもね、業務でﾌﾞﾁ当たりすぎて、
泣きながら調べて、試して、失敗して、やっとちょっとずつわかってきたの🫶

このトークでわ、その時の「array 関数メンタル崩壊事件簿」をゆるっと共有しながら、
それぞれの関数の違いや、こう使えばよくね？って話をしてくよん🌈💡

array 関数で病みかけたギャル（ぅちらギャルだよね？）、全員集合〜💖💖

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

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

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

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

「とりあえず動くPHP」から一歩進みたい初学者へ向けて、PHP 8の文法と型の表現力を通じて、読みやすく・壊れにくいコードの設計を学ぶセッションです。

match 式や readonly プロパティ、union types、named arguments などの機能が、静的解析ツール（PHPStan, Psalm）と組み合わせてどのように活きるのかを具体的なコード例で解説します。

「型を書くだけで、こんなにミスに気づけるのか」「PHPでも設計って考えられるんだ」と実感できる内容を目指します。

文法の表面的な知識だけでなく、現場でコードを書く上で意識したい“意図を型で伝える”視点を手に入れましょう。

PHPを使用して「サーバーサイド・ブロックチェーン」という新たな概念にチャレンジします。

従来、ブロックチェーンはクライアントサイドで署名したデータを、スマートコントラクトがデプロイされたP2Pネットワークに通知する構成が主流であり、サーバーサイドでの活用事例は多くありませんでした。

この構成は、1対1の当事者間においては高いセキュリティを実現できる一方で、複数関係者の同時関与や段階的な意思決定が求められる実業務の場面においては、柔軟なワークフローの設計や、合意形成の自動化に課題が残っていました。

本トークではSymbolブロックチェーンを活用し、サーバーサイドに部分署名を組み込むことで、既存のWebシステム上に、安全かつ自然に統合する手法を紹介します。

これにより、業務システムに求められる実用性と、ブロックチェーンの信頼性を両立する、新たな実装モデルの可能性を提示します。

本トークはPHPのメタプログラミング技術を活用し、本来の言語設計が提供する制約を超えた操作がどのように可能となるか、またその結果生じるリスクと課題についてをお話します。

PHPにはリフレクションAPIを使用したアクセスやeval()による動的なコード実行など強力な機能が提供されています。
これらの技術はいわゆるメタプログラミング技術に内包されるもので、特定状況下では非常に有用ですが、同時に深刻なリスクが伴うものです。
ちょっとしたいたずら心がどのような災厄を招くのか。
本トークではメタプログラミングの威力をあらためて確認し、その適正な使用範囲とベストプラクティスについてお話いたします。

話すこと

• PHPでstring, float, intを相互変換するとどのような問題が起きるのか、どのように実行されているのか
• センシティブな数値を扱う時、どのように扱うべきなのか

説明

会計システムを作る時にPHPの数値仕様をしっかり理解した上で作らないと、後々大変なことになってしまう可能性があります。
小数点以下の誤差によって1円が消えたり増えたりしてしまうことがあり、1円の行方を巡って終わりのない、解決もしない調査の旅に身を投じることになるでしょう。
それが今なのか、いつなのかは分かりませんが、知っていれば防げる問題でもあります。

本セッションでは数値にはどんな問題があり、扱う時に何を気をつける必要があって、さらに扱いやすくするためにおすすめの方法をお話しします。

PHPカンファレンス関西2025のオープニングをします