プロポーザル

任意の時点の PHP プロセスのメモリ状態のスナップショットをとり、SQL で「一番大きな文字列」「あるクラスの全インスタンスにおける特定プロパティに格納された配列の平均サイズ」「前回取得時のスナップショットから生き残り続けているオブジェクト」といった情報を自由に取り出せるとしたら、とてもおもしろいと思いませんか？

え、何の役に立つのかって？そりゃ何かの役には立つでしょう。何かの役に立つという確信はありますが、しかしそのような実用一辺倒の観点でものごとの価値を決めつけていくのは、あまり豊かな生き方とは言えません。役に立とうが立つまいが、とにかくスクリプトの状態を SQL でクエリするのです。

このトークは自作のメモリプロファイラ Reli に、登壇駆動開発で機能追加をするための枠です。採択されトークが行われることで、世界中の PHPer がメモリリークの心配なく long running な PHP スクリプトを安心して作ったり動かしたりできる、そんな夢のある世の中へ一歩近づくこともできます。
トーク内容そのものは PHP 処理系の内部状態をどう RDB のテーブル構造で表すかというマニアックな話が延々続くこととなります。
PHP スクリプトによる大道芸に興味のある方には、大道芸として面白く聞こえるかもしれません。
聞く人がほぼ全員置いてけぼりになるけれど喋ってる本人は妙に熱量が高いという、その温度差を眺めて苦笑いしたり、運が良ければ「こんな変なことやっていいなら俺も/私も変なことをやるぞ」と妙な熱量が伝染したような気持ちになることもできるかもしれません。

今すぐ社内用のWebツールを作らなくてはいけなくなったので、いまからこの部屋で、20分だけ仕事をさせてください!

2025年現在、OpenID Connectが多くのIDプロバイダーに実装され、とても良い時代になりました。
PHPでのライブラリも多くあり、OktaやOneLoginなどを社内で使っている方なら、すぐに社員にアクセスを限定した簡単なWebサービスを作成可能です。

今回は、OpenID Connectで社員情報を認証、認可するところまでをBref(serverless on AWS Lambda)でライブコーディングし、
20分で社内Webツールが初心者でも簡単に作れるところまでを実践します。

みなさん、もっと気軽に会社のアカウントで認証認可、やっちゃいましょう!

CTOとして内製開発チームをゼロから立ち上げ、現在では社員・業務委託を含め約20名の規模にまで成長させてきました。このチーム拡大の過程では、採用難が叫ばれる時代の中、スキルやマインドを見極め、自社にフィットする人材を見つけることに真剣に向き合ってきました。
その一方で、採用活動ではさまざまな課題にも直面しました。理想の人材と巡り合えないことや、採用後に感じるミスマッチなどの試行錯誤を繰り返してきた中で、一つの有効な手法としてコーディング試験を導入しました。この取り組みによって、候補者の技術力や考え方をより深く理解し、チームに適した人材と出会う手ごたえを得ることができました。
本セッションでは、コーディング試験導入の背景や実際の運用方法、そこで得られた成果や課題、そしてそれを通じて得た学びを共有します。同じように採用の課題に直面している方々にとって、実践的なヒントとなれば幸いです。

◆対象者
・エンジニアの採用に関わるエンジニア
・新規の開発チーム立ち上げをしている人

◆話すこと
・なぜ採用プロセスを改善しようと思ったのか？
・PHPer採用の課題感
・技術力を客観的に評価する必要性
・テスト内容の作成
・実施してみた結果
・候補者の反応やフィードバック
・実施したうえでの改善
・どのようなポイントを評価したか
・採用プロセスにおける成果
・コーディングテストの有効性

昨今、開発の中にコードレビューのフローが存在するチームは多いのではないでしょうか。
そして、そういったチームへのジョインや会社への入社したエンジニアは、いつかコードレビュー1日目を迎えることでしょう。

特に、自分自身のスキルに自信がない方は、
・ 他の先輩方のコードレビューをするのは気が引けるな・・・
・ 自分はスキル的にまだまだだから、コードレビューなんてまだできないよ・・・
・ いざレビューしてみてるものの、なんてコメントしたらいいかわからないな。。
・ 自分はLGTM( = Look Good To Meの略。自分的にはOKという意) と思ってLGTMにしたけど、他の人がめっちゃコメントしてる・・・

のようなネガティブな考えに囚われてしまい、気付けばLGTMしかコメントしなくなっていたり、誰かがLGTMとコメントした後に自分もコメント残しておこうみたいなマインドにもなってしまいます。（新卒時代の僕がまさにその状況でした。）

本セッションでは、自分自身が思考錯誤して見つけた「自信を持って最初の1歩を踏み出す方法」を紹介します。

・ これならできそう
・ そんなに難しく考えなくていいんだ
と思っていただけると嬉しいです。

新たにチームにジョインする方が新しい環境にも臆さずコードレビューできるようになったり、
チームに招き入れる側の方が、新人に対して安心させてあげられる状況作りの1つになると幸いです。
新卒1年目の僕のような状況に陥ってしまう方が1人でも少なくなりますように。

対象者：コードレビューの体制のあるチームの全エンジニア（役職問わず）、これから新卒として入社を控えるエンジニア志望の学生の皆様

昨年のカンファレンスで「CodeReviewerが求められること」について発表させていただきました。
その中で、Revieweeが
・気づきや学びが欲しい
・自信を持ちたい
と感じていることが明らかになりました。
またその時の発表では触れませんでしたが、Revieweeは「楽しく働きたい」とも考えていることがわかりました。

しかし、コードレビューにおいて、Reviewerが気づきや学びにつながるようなコメントをしたとしても、伝え方次第でRevieweeから楽しさや自信を奪うことがあります。
逆に言えば、伝え方次第ではRevieweeが自信を持たせたりコードレビュー依頼を活性化させることもできるようになります。
本セッションでは、Revieweeのやる気を促進させつつ、レビューも行っていく方法を紹介し、PHPerエンジニアへのヒアリングも交えながら、心地よいコメントの条件を考察します。
コードレビューの場が楽しくなり、組織が活発になる一助となれば幸いです。

対象者：コードレビューを行う全エンジニア（役職問わず）

設計に詳しくなりたいし、設計力が欲しいし、色々な場面で良い感じな設計を描けるようになりたいですよね。
ソフトウェアづくりに設計は必要です。
何をもって「良い設計ができた」と言いますか？何を目指していますか？
本トークは、その自信と根拠を持つための、「なぜ設計を行うのだっけ」を考えるきっかけとなることを目指します。

考えるべきこと

このトークにおける「設計」に対する態度

• 設計は、何かしらの品質を支えるためにある。その意思決定が具体化されたものと捉える
• 品質には「いま必要なものを、必要なレベルで実現できている」「必要な期間中、継続的に、要求に応え続けられている」の両軸が必要
  • 「将来的にも拡張・変更しやすい」だけでは満足されず、「今の環境や要員でついて行ける」ことも重要
• 自信が持てるような設計にするには、「身の丈にあう」のガイドラインとしての機能を果たす必要がある
  • 「ぼくのかんがえたさいきょうのデザイン」にしない

「良い設計」のために必要なこと

• 設計の「ねらい」をトレードオフとして表現して伝える
  • カーゴカルトよりテイラーメイドを重んじる
  • 何が本質かは自ら選び取り、思考をdumpする
• その設計を「支える」のはメンバーたち
  • 本来のねらいが、実現され続けてこそ意味がある
  • 技量面への教育やツールによる支援が必要

このトークで得られるもの

• ねらい: 「良い設計」を議論するための観点を提供する
• 得られるもの: チームで「自分たちに必要な設計」を見つめ直すきっかけ

話さないこと

• 具体的な設計技法やパターン
• 各論的な品質特性やその計測方法

想定オーディエンス

• 「設計ってなんだろう？」に興味を持ち始めたジュニア
• 駆け出しテックリード

https://fortee.jp/phperkaigi-2025/proposal/8e379e7d-9910-4b9e-adf8-3ea606b7153a

PHPではtry-catchを使った例外処理が一般的ですが、「この例外はどのレイヤーで処理すればいいのか？」や「どの場面で例外を使うべきなのかが曖昧だ…」と感じたことはありませんか？例外の種類や扱い方が曖昧だと、設計の混乱やコードの保守性低下を招きます。この課題に対するヒントとして、Rustなどの言語で採用されているResult型の考え方があります。

Result型は、成功と失敗を型として扱い、例外に頼らずエラーを管理する手法です。これにより、エラーの種類や処理責任が明確になり、設計の一貫性を保ちながら保守性を高めることができます。このセッションでは、Result型をPHPに応用する方法を具体例を交えて解説します。

取り上げる内容：

• 例外の種類や扱い方が曖昧になる原因とその解消方法
• Result型の基本的な考え方とPHPでの実装方法
• try-catch採用プロジェクトでも活かせる学び

例外の扱いをもっと明確にし、エラー処理を改善するヒントをお持ち帰りください！

皆さん、ちょっとしたコードの動作確認をしたい・サクッとRDBを参照/書込する作業をしたい、等の場合に何を使っていますか？

コードを対話式で実行できるREPL(Read Eval Print Loop)は書き捨てのスクリプトを作ったりせずにコードを実行でき、開発を大いに助けてくれます。

PHPではphp -aコマンドで起動されるランタイム同梱のインタラクティブシェルや、より高機能で補完機能やコード実行結果の自動出力機能などを備えたPsySH (bobthecow/psysh)などがあります。

また、laravel/tinkerやcakephp/replなど特定の用途向けに作成されたREPLも存在し、筆者は簡単なRDBの読み書きであればREPLから行うこともあります。
実はそれらのREPLはPsySHをベースとして開発されています。

そんな便利、かつ他のツールの基盤となっているPsySHはPHP製のOSSです。
そう、PHPerが普段使い慣れた言語で作られているのでコードを読めば仕組みがわかります。

この発表では、REPLの基本である「入力の読み取り (Read)」「評価 (Eval)」「出力 (Print)」を軸に、PsySHがどのように実装されているのか・laravel/tinkerなどがどのようにPsySHを拡張しているのかを深掘ります。

• 発表の対象
  • PsySH（やそれを拡張したツール）のREPLとしての機能
• 話さないこと
  • REPL以外の機能 (デバッガ、コマンドライン引数で受け取ったコードの実行など)
• 対象聴衆
  • 普段REPLを使っている人
  • (普段REPLを使っているかどうかは関係なく) REPLの仕組みに興味がある人

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

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

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

話すこと

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

運用中の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が跳ね上がるのってなぜ？
• ログとメトリクスからユーザー特性を推論する、問題発生箇所のコードを探す技術

本セッションでは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 などについての細かいお話はしません。

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

背景

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

本トークで話すこと

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

発表者について

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

対象者

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