プロポーザル

みなさん、ドメインイベントって使っていますか？

このトークでは、ドメインイベントを使ってPHPコードをリファクタリングする方法についてお話しします。
ドメインイベントは、ビジネスドメインで発生する「出来事」を表現するモデルです。注文の完了やユーザー登録のようなビジネスプロセスの特定の状態変化を表現できます。
これをうまく使うことで、副作用をわかりやすく整理し、システムをシンプルにできます。

ドメインイベントを導入してみると、「あ、こんな風に設計すれば良いんだ！」と新しい発見があるはずです。リファクタリングを通じて、どうやってドメインイベントを設計し、活用するのか、その具体的な手法をお伝えします！

話すこと

• ドメインイベントって何？
• リファクタリングでドメインイベントをどう導入するか
• システム間の連携を簡単にするイベントの使い方

API Platformという、APIを作るためのフレームワークがあります。

便利なフレームワークである反面、引き換えに犠牲を伴うことが多くありますが、
その話題がのぼるほど利用者がいないのではないか…と思っています。
なので、API Platformを広めるために便利機能を見開きでわかりやすく！お伝えします。

本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、その仕様を様相論理の一種である時相論理を用いて厳密に記述し解析する技術について解説します。

みなさんは「ボタンをクリックすると機能 X が正しく動く」といったテストケースを目にしたことはありませんか？ お気づきの通り、このテストケースはあまり良くない例です。では、何が良くないのでしょう？ 一番の問題は、ここで言う「正しく」がどのような状態を指すのか、言い換えればこのテストケースが何を保証しているのか、が全く具体的ではない点です。

我々が何らかの方法でシステムの仕様を保証しようと考えた場合、テスト設計であるとか、あるいは自動化ツールのような、仕様を「テストする」ための方法論に目が行きがちです。しかしその前段階として、仕様を「記述する」というステップがあることは忘れてはいけません。入力に対して出力がある、いわゆる単体テストであればそれほど困らないかもしれません。しかし、例えば複数のサーバが協調して動く「分散システムの正しさ」だったら？ さらに、複数のサーバのうち一部が高負荷となってレスポンスを返したり返さなかったりする状況だったとしたら、全体の動作の「正しさ」にはどのような影響があるでしょうか？

自然言語による仕様の表現は、我々が普段なんとなくイメージしている以上の曖昧性を含みます。そしてその曖昧性を排してシステムに対するより良い理解と洞察を得るために、厳密な「共通言語」を定義したいという動機は、かなり旧い時代から現在に至るまで、一貫して計算機科学の興味の対象であり続けています。

本セッションでは、このような動機に応える様相論理とモデル検査について、可能な限り誤魔化さずに解説したいと思います。普段、分散システムを触っていて、何となく計算機科学の基礎が気になってきたぐらいの方にお薦めです。

私たちのチームはPHPとRDBMSを用いた受託開発を中心に開発をしてきました
チーム文化として、クライアントニーズに迅速に応えながら、時代の変化への柔軟性を持って開発を進めることを大切にし、
常に新しい技術や手法を積極的に受け入れることを得意としていました

そんな中、話者である私自身は「サーバーレス」を得意としていましたが、そのスキルを自分ひとりの武器として振るうのではなく、
チーム全体の文化や価値観に溶け込ませ、組織的な生産性・開発価値の向上につなげるにはどうすればよいのか、日々考え続けてきました

そこで目を向けたのが「Platform Engineering」の考え方です
Platform Engineeringは、開発者がインフラやツール選定に悩まず、本質的なビジネスロジックの創造に集中できるようなプラットフォームやサービスを用意し、組織内のエンジニアリングプロセスを最適化するアプローチです
サーバーレスが得意な「私自身」から離れ、あくまで「チームとしての開発価値向上」をゴールに据え、共通のプラットフォーム基盤としてサーバーレス技術を位置づけることで、メンバー全体がその恩恵を享受できる形が見え始めました

本セッションでは、従来のLAMP系スタックを踏襲しながらもサーバーレス環境をチームにシームレスに組み込み、Platform Engineeringという視点で共通基盤として活用し続ける工夫についてご紹介します
個々人がスキルやツールに依存するのではなく、チームとして得られる付加価値、そして最終的に生まれるエンジニアリング体験の向上への挑戦についてお話できれば幸いです

• 想定聴講者
  • サーバーレスをチームに浸透させたい人
  • Platform Engineeringが何か知りたい人

運用中のPHPアプリケーションに後からCDNを導入する際、特に歴史的な経緯により、複数のカスタムドメインを使用している場合、移行作業には慎重な計画が必要です。このセッションでは、AWSのCloudFrontを例に、複数ドメインを持つ既存アプリケーションにCDNを導入する際のベストプラクティスを解説します。

まず、複数ドメインで運用している環境で効果的なCDN導入が難しい理由を整理します。たとえば、静的リソースのURLがハードコーディングされている場合や、既存のキャッシュ制御ヘッダーが正しく設定されていない場合、移行中にアクセス障害やパフォーマンス劣化を引き起こすリスクがあります。これらの課題を特定し、解決するための準備ステップを紹介します。

次に、CloudFrontを活用して既存のアプリケーションにCDNを導入するプロセスを具体的に解説します。CloudFrontのディストリビューション作成方法、複数ドメインを扱うためのカスタムオリジン設定、HTTPS対応のためのACM（AWS Certificate Manager）の証明書設定について実例を交えて説明します

さらに、移行中の段階的なテスト方法についても触れます。たとえば、特定のリクエストのみCloudFrontを経由させる設定や、デバッグ用にキャッシュを一時的に無効化する方法など、移行時に安全性を確保するためのテクニックを共有します。

このセッションは、複数ドメインで運用中のPHPアプリケーションを対象に、後からCDNを導入する際の手順と注意点をわかりやすく解説します。AWSを活用した実践的なアプローチに興味があるエンジニアの方に、移行作業をスムーズに進めるための知識を提供します。

話者は普段PHPをBrefというOSSを利用してAWSにデプロイしています
この方法は非常に有用で、サーバーレス環境にPHPアプリケーションを載せるための標準手法として紹介してきましたが
一方で第三者が構築しているOSSに対する不安を感じる方もいるはずです

既存コードをどのようにサーバーレス化すれば良いのか、またカスタムな環境構築がどこまで信頼できるのかといった懸念があるかもしれません
特に既にLaravelやSymphonyなどのフレームワークを用いて開発されたアプリケーションを、
既存のワークフローを大きく変えずにクラウドネイティブな環境へと移行したい場合、そうした課題はより顕在化します

そこで今回はAWSが構築を行っているAWS Lambda Web Adapterを利用します
PHPerはサーバーレスの利点を享受しつつ、従来のWebアプリケーションをシームレスに移行する手法を身につける事が出来ます
さらにLaravelに適用する際には、既存のルーティングやミドルウェア、コントローラ群をそのまま活用し、AWS Lambda上でリクエスト-レスポンスサイクルを再現することが可能です

AWS Lambdaの可能性を広げるWeb Adapterを利用したサーバーレスPHPの普及に助力出来れば幸いです。

• お話すること

  • AWS Lambda Web Adapterについて
  • Laravelのデプロイ手順

• 想定聴講者

  • サーバーレスPHPに興味がある方
  • AWSを利用してPHPを利用している方

クラウドネイティブやマイクロサービスアーキテクチャの普及に伴い、アプリケーションは複雑化し、
従来のモニタリング手法では原因特定が困難な障害やパフォーマンス劣化が増えています

こうした状況下で注目されるのがObservability（可観測性）です
Observabilityは、システム内部の状態や相互作用を可視化し、迅速な問題解決や改善策の立案を可能にします

本セッションでは、業界標準化が進むオープンソースプロジェクト「OpenTelemetry」を活用し、
PHPアプリケーションにObservabilityを導入する手順を段階的に解説します
Observabilityの基本概念をMonitoringとの違いを交えつつ明確化し、実際のトラブルシューティングシナリオを示します
これにより「なぜObservabilityが今必要なのか」を理解します
さらに、OpenTelemetry自体が何なのか、その本質と狙いをOpenTelemetryの特徴やコンポーネントをわかりやすく整理します
公式SDKのセットアップ、計測ポイントの挿入、外部サービスとの接続方法をサンプルコードを交えながら示し、PHPアプリへの適用ステップを紹介します

このセッションで参加者が次の開発・運用プロセスでOpenTelemetryを用いてObservabilityを導入できる一歩目を提供します

• 想定する聴講者
  • OpenTelemetryを知らない方
  • OpenTelemetryが何故必要とされているか知らない方
  • OpenTelemetryを利用してみたい方

PHPユーザーであれば、日々APIのパフォーマンスと向き合うことがあるかと思います。
中でもGolden Signalと呼ばれる4つの指標（レイテンシー、トラフィック、エラー、サチュレーション）は、システムが「健全」であると判断する基準となるものです。
本セッションではGolden Signalを中心に、Performance Insightや周辺のメトリクス、モニタリングツールの操作、問題の特定や推論を可能にする為のTipsについて話します。

• Golden Signalについて
• 価値のあるログとは何か、どこにあるのか
• Performance Issueをどう特定するか
• ケーススタディ、 ex: このアプリケーションは20時台にCPU Usageが跳ね上がるのってなぜ？
• ログとメトリクスからユーザー特性を推論する、問題発生箇所のコードを探す技術

EC2のセキュリティがガバガバに穴が空いている状態の皆さん息してますかー？
すみません。いきなり煽りから入ってしまいました。
最近、サーバー構築作業をしている中でセキュリティ担保の方法を学ぶことがあったので、この場を借りて皆さんに共有させて頂ければ幸いです。
EC2へSSH接続を行い、サーバーでの作業を行っているバックエンド側の人の幸せにつながってくれたら嬉しいです〜
EC2のSSH鍵の扱いどうしていますか？
複数人でプロジェクトを組んでいる場合、サーバーで作業をする人が複数出てくると思います。
そうなってくると以下の作業を 作業者の人数分 × サーバーの台数分 実施しなければいけなくなります。
この時点で億劫ですね。
また、上記の作業に加えて 鍵の定期的なローテーション、チームの入退場が発生した時のユーザー管理が発生してしまいます。
死ぬほど面倒くさい！
更にセキュリティに興味が無いメンバーが存在すると、鍵のローテーションはやらなくていいじゃんとか抜かすんですよ。。あー、面倒くさい。
その問題、ECS Instance Connect で解決しましょう
EC2 Insatnce Conncetを使うと僕達ユーザーが鍵の管理をする必要がなくなるので、運用の手間をかなり減らすことができます。
（サーバー運用やったことにしか伝わらないと思いますが、管理するものを減らすという事は運用において絶大に効果があるのです！！
EC2 Instance Connect を使う際には、セキュリティグループで SSHのポート 22 を開放して置く必要があります。
22番ポートを開けるのは多少なりとも気が引けますよね〜
最低限のセキュリティ担保として、 EC2 が所属する Region のみからアクセスできるようにIP指定をすることができます。
運用負荷が下がると幸せになれます。
幸せになろう。

近年、大規模言語モデル（LLM）が急速に進化し、ナレッジグラフとの連携が重要性を増しています。LLMは膨大なデータを処理しながらも、特定分野の知識を正確かつ構造化して扱うには限界があります。ここで注目されるのがナレッジグラフ。データを構造化し、関連性を明確にすることで、LLMと補完し合いながら、より高度なアプリケーションが実現可能になります。では、PHPでナレッジグラフを扱うにはどうすれば良いのでしょうか？

本セッションでは、PHPを使ってナレッジグラフを活用する方法を解説します。ナレッジグラフとは何か、その基礎概念から始め、具体的にPHPでどのように操作・活用するかを探ります。まず、ナレッジグラフに関連するRDF、OWL、SPARQLなどを簡単に説明し、PHPでそれらを扱うためのライブラリ（例: EasyRdfやRdfPhp) を紹介します。その後、SPARQLクエリを用いてナレッジグラフからデータを取得・操作する方法を具体例とともに解説します。

さらに、PHPで構築した既存のWebアプリケーションにナレッジグラフを組み込むためのアーキテクチャ設計や、LLMとの統合方法についても議論します。たとえば、LaravelやSymfonyのようなフレームワークを利用して、ナレッジグラフを効率的にクエリ・操作し、APIを通じて他のシステムやLLMと連携するパターンを具体例で説明します。

最後に、ナレッジグラフとLLMの組み合わせによる具体的なユースケース（FAQシステムやレコメンデーションエンジンなど）を示し、ナレッジグラフの可能性を最大限に活用するための道筋を提案します。このセッションは、ナレッジグラフという新たな分野に挑戦するための第一歩となる内容です。LLM時代の今だからこそ必要とされる技術に触れ、一緒に未来のWebアプリケーションの可能性を広げてみませんか？

本セッションではTerminal IDEを、VsCodeやJetBrains製品が提供する「統合開発環境」としての機能をVimとTUIを利用してTerminal内で表現する事であると定義します。
LSP、DAP、補完やGitにDocker操作等々のIDEとしての環境をVimで構築するまでのステップと、その効率性について解説する内容になります。
皆さんに「こんな選択肢があるのか」と自分の開発環境を見直す機会になることがGoalです。

話すこと

• なぜTerminalで完結させているのか
  -Terminal IDEとIDE製品のPros/Cons
• Lua言語について
• Terminal周りのOSS事情と、Rust製の勢い
• 自分が大規模コードをNeoVimのみで編集できるようになるまでの四苦八苦
• PHPでのライブコーディング

何かを作ることって楽しいですよね。プログラミングを始めたキッカケは、それぞれ違うでしょうけれど、「動くもの」ができたときに得る快感は、およそ共感できるでしょう。
ところで、日々のお仕事に忙殺されて、その得られる快感が薄くなっていませんか？業務ではさまざまな制約があることでしょう。

そんなあなたに、自由な開発をする後押しをしたい。そして自由を糧にしてあなたのWayを作って欲しいのです。

想定ターゲット

• お仕事でしか開発をしない人
• 日々のお仕事に忙殺されてる人
• 個人開発ってなんだろう、どうすればいいんだろう、という人

話さないこと

技術的な詳細には触れませんが、トーク後に質問をいただければ大歓迎です！嬉！

ISUCON は「いい感じにスピードアップコンテスト」の略で、ほぼ同様の処理をするよう作られた Web サービスの参考実装が複数の言語で用意され、参加者は競技中好きな言語を選んでその性能改善をしていきます。2024 年に実施された ISUCON14 でも PHP 用の参考実装が用意され、実際に PHP を使って参加し、良い成績をおさめたチームもありました。

このトークでは ISUCON14 の問題の PHP 参考実装を使い、時間制限を気にせず、参加者の感想ブログの取り組みを平然とパクりつつ、PHP で優勝チームに勝てるスコアを出せるか試した際の知見をお話します。

かつて PHPerKaigi 2023 で ISUCON12 本選問題を使って同様の試みを行った際は、

• 計測の重要性
• DB ネックの間は他言語と同じような改善が効く
• 処理系へボトルネックが移ると同じやり方は使えない
• AltFPM の有効性
• CPU をより多く割り当てる必要性
• 徹底的にやれば PHP でもスコアは出る

といった知見が得られました。
今回もそれらの知見にもとづき同様の改善の道筋をなぞりつつ、FrankenPHP や PHP 製アプリケーションサーバに PHP 8.4 など、前回は存在しなかった・試せなかった取り組みを上乗せで行っていきます。

みなさん、PHPのテストを書くときに「他のクラスや依存関係のせいでテストが難しいな…」と思ったことはありませんか？
そんなときに役立つのが、PHPのモックフレームワーク Mockery です！

Mockeryを使えば、依存するクラスやインターフェースの動作をモックして、テストをもっとシンプルに、効率的に進められます。このトークでは、Mockeryの基本的な使い方から実際の業務で役立つテストケースまで、具体例を交えて解説します。

取り上げる予定の内容はこちら！

• モックを使ったメソッド呼び出しの検証方法
• 高度な引数の比較を使った柔軟なテスト
• 実務でのテストケースの実例紹介

Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

「アジャイルなんてオシャレな自社開発企業だけの特権でしょ？」

そう思っていた時期が自分にもありました。

その後、自組織へのアジャイル導入を主導し、実践を重ねた今となっては、アジャイルはチーム単位や、ひとりからでも始められる！と確信しています。

このセッションでは、アジャイルの魅力、そして「はじめの一歩の踏み出し方」についてお話しします。

こんな人に聞いて欲しい

• アジャイルのことは知っているけど、まだ実践できていない人
• 受託開発だからアジャイルは無理、とあきらめてしまっている人

お話しないこと

スクラムや XP などについての細かいお話はしません。

「言語設定」という言葉は普段の開発でよく耳にするものの、これまで深く考えたことがありませんでした。日本語や英語などの言語設定がどのように決められ、どのように利用されているのかを理解することで、国際化対応やユーザー体験の向上にどのように活かせるのか。本セッションでは、自身が初めて真剣に言語設定の仕組みと設計に向き合った経験をもとに、言語設定の基本から設計に至るまでの学びを共有します。

まず、OS（Linux、Windows、macOS）やブラウザがどのように言語設定を決定し、利用しているのかを解説します。その後、これらの情報がPHPアプリケーションに渡されたときにどのように利用されるのか解説します。

さらに、実際のアプリケーション設計において、どのように言語の対応を処理すべきかを検討します。具体的には、Accept-Languageヘッダーを基に動的に言語を切り替えるミドルウェアの設計や、クッキーやセッションを利用したユーザー固有の言語設定の永続化方法についても触れます。また、多言語対応におけるドメインの利用（例: example.jpとexample.com）やURLパス（例: /enや/ja）を使った切り替えの実装パターンについても議論します。

このセッションは、言語設定について初めて真剣に考えるエンジニアに向けた内容です。言語設定の仕組みを理解し、設計に落とし込むまでのプロセスを一緒に探ることで、これからの国際化対応に必要な知識と視点を得られるはずです。一緒に、言語の設計に一歩踏み込み、真剣に考えて見ませんか？

ISUCONにPHPで挑み続けて8回（ISUCON7〜ISUCON14）。
ふと、こんな疑問が頭をよぎることがあります。

「自分（私たち）は本当に成長しているのだろうか？」

8回も挑戦を重ねてなお、悔しさや「まだまだできないことが多いなぁ」という気持ちに直面します。
それでも、振り返ってみると、できることや考えられることが確実に増えていると実感しています。

「できない」と「できる」には壁があります。

しかし、その差は小さいことも多く、ふとしたきっかけで「できる」になるなと感じています。
この過程こそが成長であり、試行錯誤を通じて得られる価値ではないかなと思います。

ISUCONに挑む中で得た学びと、「続けることで見えてくる成長」について共有します。
技術的なノウハウだけでなく、挑戦することの意義や、それを続ける中で見つけたヒントをお伝えしたいと思います！

Svelteって名前、聞いたことありますか？
SvelteはReactやVue、Angularなどと同じ、リアクティビティをもったWebアプリケーションライブラリです。
Reactに対してNext.jsがあるように、SvelteにもフレームワークとしてSvelteKitがあります。

このLTではPHPerの皆さんにだからこそ伝えたい、
SvelteKitの魅力やおすすめポイントを5分でギュギュっとお伝えします！

このLTがおすすめの人

• SvelteやSvelteKitに興味がある人
• よりよいUIフレームワークを探し求めている人
• 状態管理でつらい思いをしたことがある人

このLTで得られること

• SvelteやSvelteKitの概要
• SvelteKitの基本
• 「早速触ってみたいぞ！」という気持ち

現在担当しているプロダクト（建設DX領域のバーティカルSaaS）で多言語対応プロジェクトに参画した際の学びを共有したいと思います。

背景

プロダクトは10年以上運用しているものでリポジトリのファイル数は3千を超えます。
図面を見たり写真を撮ったりという標準的な機能のほか、外部機器と連携して検査をするというオプショナルな機能をあわせると30以上機能があります。
標準的な機能は多言語対応が完了していましたが、オプショナルな機能をこれから多言語対応していくというタイミングでした。

本トークで話すこと

• サービスを多言語対応をするうえでそもそも起こりうる、日本語と英語で文字数や記号による違いなど、表現について。
• 長く運用しているプロダクトの複雑な仕様を理解しながら進める多言語対応。
• 考慮不足によって発生したバグからの学び。

発表者について

プログラミング歴約2年半で転職して入社した会社での話し。
入社から数カ月後に参画したプロジェクトが多言語対応でした。

対象者

これから多言語対応をする予定の方、今多言語対応している方。
多言語対応で起きる問題に興味がある方。

我々はメモリの確保・解放をほとんど気にすることなく、プログラムを書くことができます。
PHPを触れていると、このGarbage Collectionを意識することもないと思います。

Garbage Collectionは、プログラムがメモリを効率的に利用できるようにする重要な仕組みです。
本セッションでは、PHPにおけるGarbage Collectionの動作やgc_XXX関数について簡単に解説します。

皆さんと共に、Garbage Collectionの恩恵を再認識し、より効率的なプログラミングを目指す旅に出かけましょう。