トーク

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

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

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

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

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

みなさんPHPStanを使っていますか？ PHPStanはオープンソースで開発されているので誰でもソースコードを読んで仕組みを学ぶことができ、理に適った提案であれば取り入れてもらうこともできます。

ところが静的解析ツールはPHPや標準関数の仕様通りに実装すれば完成すればるというわけでなく、さまざまな考慮事項や現実との折り合い付けかたなどがあります。

本トークでは私がこれまでPHPStanに送信したPull Request(※トークプロポーザル時点で未マージ含め49件)について分類して紹介します。

• 取り入れられた提案
• マージされたPR
• マージされなかった
• マージされたが後にrevertされた提案
• 投げ出してしまって完成していないPR

想定聴講者

• 会計システムや EC サイトなどでお金を扱う開発をしている人
• PHPのstring, float, intがどのように相互変換されるのか挙動に興味がある人
• 設計に興味がある人

話すこと

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

話さないこと

• 既存の技術選定について
• 既存システムの苦悩と戦いについて

普段開発している時はあまり意識せずに数値を型変換することがあると思いますが、そこには思いもよらぬ潜在的なバグに繋がる挙動が潜んでいます。

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

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

2年前、私は「Laravelへの異常な愛情」と題し、Laravelの基礎的な考え方と、そのレールがもたらす開発上の効果を紹介しました。Laravelをモデルに対するCRUDに特化したリソース志向フレームワークと捉え、コード量を削減しスタイルを統一する、これがLaravel Wayです。

しかし、現実のアプリケーションが、この枠組みの範囲に収まることはありません。

枠組みを超えた要件はプロジェクト固有の設計やルールで解決する必要があります。この試みは、成功することもありますが、それが「ほころび」となりコードベース全体の保守性を脅かすこともあります。これもまた、Laravelというフレームワークの特徴です。

逆に考えましょう。枠組みの外に出るのではなく、枠組み自体を拡張すれば良いのです。その手法を紹介します。

個別のテクニック

• 認証の拡張
  認証プロバイダを理解し、Eloquentに依存しない認証や外部の認証基盤との連携を実現する
• リクエスト処理の拡張
  Laravelの処理ライフサイクルを理解し、変則的な要件に対応する
• Eloquentの拡張
  データベースドライバを理解し、データベース固有機能を自在に利用する
• レスポンス処理の拡張
  Responsableを理解し、モダンフロントエンドへ対応する

拡張の考え方

• あらゆるものを拡張
  Laravelの内部設計を知り、拡張の考え方を理解する
• 再利用性と安定性
  パッケージ化による責務分離と、バージョンアップへの備え

題材として扱うOSS

• Laravel Doctrine ORM
• Laravel PostgreSQL Enhanced
• Laravel Debugbar
• Inertia.js
• Testbench

Web アプリケーションのセキュリティ設計において、特定のユーザーに対してどの操作を許可するかという認可の設計は欠かせない要素です。近年では、マイクロサービスやゼロトラストの考え方が普及し、サーバー間の認可を含むより複雑な機能が求められています。

このような複雑な認可を効果的に管理する方法の一つとして、認可ロジックをアプリケーションから分離し、外部化して再利用可能なポリシー言語で定義する手法があります。AWS IAM はこのようなポリシー言語の一例ですが、AWS に限定されない一般用途にも Open Policy Agent (OPA) が広く知られています。

本セッションでは、認可の課題に対する新たなキラーソリューションとして、Cedar を紹介します。Cedar は AWS によって開発されたポリシー言語で、Amazon Verified Permissions としてマネージドサービスが提供されているほか、AWS 以外の環境でも使用可能な OSS としても公開されています。

OPA と比較した Cedar の顕著な特徴は、大量のルールを定義した場合のパフォーマンスにあります。このパフォーマンスは、一度評価された条件を部分的にキャッシュし再利用する仕組みにより実現されており、そのキャッシュ戦略の正当性は数学的に厳密に証明されています。このように、Cedarは高度な理論が実際のプロダクトに価値を提供する興味深い事例といえるでしょう。

Cedar は 2024 年に論文が発表されたばかりであり、理論的な詳細に関する日本語情報はほとんど存在しません。そのため、本セッションでは参加者が認可エンジンの内部機構と特性を深く理解し、実際のアプリケーションのセキュリティ設計に役立てられることを目指して、Cedar に対して応用と理論の両面から Deep Dive します。

このセッションではPHPのマイクロサービスアーキテクチャにおける分散トランザクション管理の新たな方法として、
アクターモデルとPhluxorを使ったSagaパターンの実装を紹介します。

PHPによる分散処理を諦めた方は多いのではないでしょうか？
並行処理の理解やサーバについての知識、結果整合への理解や、
障害対応方法や復旧方法など分散システムになればなるほど難しくなり、PHP以外の知識が要求されます。
アクターモデルはそれらを強力にサポートしてくれる仕組みがたくさんあります。
そんな仕組みを活用したデータ整合性の維持やレジリエンス向上に役立つ例として、
在庫管理やショッピングカートなどをテーマに実践的なアプローチを実装コードを交えて解説します。
アクターモデルによるメッセージングや、アクターによる振る舞いの変更、
state管理やSupervisionの活用、アクターの永続化などを用いて詳しく解説します。
複雑なワークフローをシンプルにし、スケーラビリティとフォールトトレランスを向上させる具体的な手法を習得しましょう！

クイックには15年以上にわたり、社内の売り上げを支え続けてきた基盤システムが存在しました。
このシステムは、事業ドメインの変遷に合わせて不断に拡張され、事業の成長を支えてきました。
しかし、その結果として、巨大なモノリシックレポジトリ、仕様書の欠如、1ファイルに集約されたJavaScript、そして無数のマジックナンバーという問題があり
不具合の発生頻度増加、開発生産性の低下、追加開発の難易度上昇といった「技術的負債」が無視できない状況になっていました。

本トークでは、問題を安全に解決するための戦略と、fuelPHP（PHP version 7.3）からLaravel（PHP version 8.2）へのリプレイスを行いつつ
フロントはJavaScriptからReact/TypeScriptへ移行した事例についてお話します。

具体的には以下のトピックについてお話させて頂きます。

• 実現可能性を高めるスケジューリングと決め事
• 開発環境の技術選定とその選定理由
• Inertia.jsによるLaravelとReactの親和性向上
• 基本的なアーキテクチャ設計のアプローチ
• 安全なリプレイスのために行った対応策
• リプレイスの具体的な成果

技術的負債を抱える皆様にとって役立つ情報を提供できれば幸いです。
ぜひ、このセッションを通じて、皆様のプロジェクトの成功につながるヒントを得ていただければと思います。

「Chatwork」はサービスが誕生してから今まで主要なところで PHP を利用し続けており、誕生してまもなくに書かれたコードも未だにメンテナンスし続けています。

私が所属しているチームは、そのメンテナンスに加えてEOL 対応やミドルウェアのアップデートなどを担当することが多く、長らくそれらをメインの業務としてきました。
また、その業務に加えてアラート対応やトラブル対応等のイレギュラータスクを多数対応する必要もありました。
チーム内では仕組み化や対応手法の標準化など、イレギュラータスクとうまく付き合いたい思いはあり様々な検討を行いましたが、今まではなかなか良い結果に繋がりませんでした。

このセッションでは上記のチームにおいて、自ら問題を認知して改善サイクルを回すことができるようになったプロセスやアクション、チームビルディングについてお話します。

2012年に日本初のふるさと納税ポータルサイトとして立ち上がった「ふるさとチョイス」は、最後のリニューアルを2018年3月に行い、そこから開発・運用を続けてきました。

リニューアル当時はPHP7.4 + FuelPHP1.8.2で構築されていましたが、言語のEOLに伴ってこの度PHP8.3 ＋ FuelPHP1.9-Dev へアップデートしましたため、
その時のつまづきポイントや苦労したところなどをお話させていただこうと思います。

PHPのバージョンアップはここ数年で実施している所も多く、目新しい構成や情報はそれほど多くないかもしれませんが、今後もアップデートを実施してく方の参考・助けになれば幸いです。

お持ち帰りポイント
・既存のリリースを止めずにバージョンアップを完遂させた方法と、想定通りに行かなかったポイント
・トラフィックの切り替え方法とその際の失敗パターン
・移行に伴って苦労したのはテンプレートエンジンでした（弊社はPHPTALを使用）

ふるさとチョイスの数字的特徴（2024年10月時点）
・PV：2億 / 月
・品の数：76万超
・利用自治体数：1700超
・決済種別：14種類

技術スタック
・PHP7.4
・FuelPHP1.8.2
・PHPTAL1.2.2
・MySQL5.6

ふるさとチョイス開発組織の特徴
・開発部門の人数： 80人
・リリースチケット件数：約25件/週

【会社紹介】
トラストバンクは、2012年に設立。第2創業期のITベンチャー企業です。
「ヒト」「モノ」「おカネ」「情報」を日本中に循環させ、地域の経済循環を生み出すことがビジョン「自立した持続可能な地域をつくる」の実現に繋がると考え、
ふるさと納税事業・パブリテック事業（自治体業務の生産性向上を促進）・地域通貨事業など、様々な事業を展開しています。

私はアドテクノロジーを扱う会社で、広告配信の制御や入稿を行うための管理システムの開発を行っています。そのシステムでは社内用の広告配信設定の管理、メディア用レポート閲覧、広告配信設定機能が行えます。

歴史的経緯から3つの管理システムが存在してます。

• 10年以上の歴史を持つ古い社内・社外向け管理システム(PHP + CodeIgniter)
• 社内向け新管理システム(PHP + Slim)
• 社外向け新管理システム（Go）

1番のシステムは10年以上保守運用されており、システムも運用も把握しきれない部分が多く、フレームワークの保守も厳しくなってきました。過去に何度も古い管理システムを葬ろうと挑んでは、志半ばで取り組みが終わることを繰り返してきていました。今回、古い管理システム の葬りが完了する目処が立ちました。

今回の発表では、 「過去、なぜ、移行しきれなかったのか」、「今回、なぜ、移行の目処が建てられたのか」、「今回の移行戦略」 をお話します。

具体的には以下の戦略を取りました。

• ロードマップを作成
• ステークホルダーに宣言
• 移行をやり切るためのサポート（ヒアリング、移行アナウンスや進捗の分かるシートへのリンクを表示）
• 旧管理画面の解像度を上げる工夫（Xdebug によるデバッガ、OpenTelemetry + Jaeger による SQL ログなど）
• 自動テストの拡充

聞いてほしい人

• 長年改修されてきたシステムのリプレイスや移行を考えている人
• 移行タスクが志半ばで終わった経験がある人
• フルサイクル開発の仕事の進め方に興味がある人

皆さんOpenSearchを活用してますか。

自社プロダクトのパフォーマンスを上げるためにAmazon OpenSearch Serviceを採用してます。
今まで事業部の人が事業運営する上で欲しいデータをエンジニアが直接DBから抽出して、都度共有していました。
OpenSearchからじゃないと取得しづらいデータがあり、そのデータが必要になるたびにエンジニアが稼働していました。
そこでエンジニアの負担を減らすために誰でもGrafanaからデータを見れるようにしました。

実際に可視化する上でつまづいた点を実践的なステップで紹介します。

本LTが参考になる人
・可視化する上で選択肢として何があるのか分からない
・どういう観点でデータを可視化すべきか分からない
・AWSアカウントを跨いでデータを可視化したい
・データを可視化するためだけでOpenSearchを外部公開したくはない

本LTを通じて、皆さんもOpenSearchとGrafanaの翼を授かって、新しい世界に羽ばたきませんか？

「テストがないコードはレガシーコードだ！」
Webアプリケーション開発においてテストコードが書かれることは一般的になってきました。

ですが、テストにかかる時間は適切でしょうか？ テストにかかる時間は開発スピードに大きな影響を及ぼします。
本トークでは自動テストを高速化するための考え方やテクニックについてお話します。

想定観客

• テストにかかる時間を短縮したい方

お話しすること

• Google提唱の「Test Sizes」を取り入れて、テスト対象をCIとローカルで変えるテスト戦略
• テスト実行の並列化 (Makefile, xargs, paratest)
• CIをジョブ分割して体感速度を上げる
• OPcache有効化とXDebug無効化による高速化

私たちは、プロダクトコードの中でさまざまなコードをtry-catchで囲み、ばしばしエラーを処理しています。
そしてエラー処理にはさまざまな選択肢があることを知ります。
例外を投げっぱなしにする（そもそもキャッチしない）、例外をキャッチして処理する、あるいは例外をキャッチしてうまく戻り値を定義する、など...です。

これまでプロダクトコードのみでの経験だった私は、OSSのコードを見て、「こんなアプローチもあるんだ」と新たな視点を得ることが多くありました。
特に例外処理に関しては、さまざまな場面での使い方や選択肢を知り、自分の考え方が広がりました。
このトークでは、プロダクトコードを書いていく中で実践的に得た知見と、OSSを通じて新たに学んだ例外処理の手法や考え方を深掘りします。

話すこと

• プロダクトコードにみる"例外処理"の扱い方
• OSSにみる"例外処理"の扱い方
• キャッチしたい場面・したくない場面
• 投げっぱなしにしたい場面・したくない場面
• 最適な選択肢をどう選ぶか

本番環境のプロファイルを継続的に取得する継続的プロファイリングは、ログ・メトリクス・トレースに続く可観測性ツールにおける4つめの柱として近年注目を集めています。
Datadog や Blackfire などの商用サービスもPHP向けの継続的プロファイラをリリースしており、PHPアプリケーションのモニタリングでも今後さらに注目されていくことでしょう。

さて、OSS の可観測性ツールとしてとても人気がある Grafana を開発する Grafana Labs は 2023 年、Pyroscope という継続的プロファイリングツールを買収しました。
私も Grafana を使っているので、Grafana で PHP アプリケーションのプロファイルも監視できるようになるのでは？と思ったら、なんと Pyroscope は現在 PHP に対応していません😭

「Grafana で PHP アプリケーションのプロファイルが見たい！ Grafana にメトリクスやトレースと一緒にプロファイルが並ぶかっこいい画面が PHP でも見たい！」
この夢を叶えるために、PHP プロファイラである xhprof のプロファイル結果を Pyroscope で受け取れる形式に変換するライブラリを自作しました。

本トークでは、

• PHP プロファイラ（ xhprof, phpspy など）の仕組み
• xhprof のプロファイル結果を Pyroscope に送る方法
• 継続的プロファイリングによる PHP アプリケーションのパフォーマンス改善
  についてお話しします。

本トークを通じて、

• 継続的プロファイリングを使ったパフォーマンス改善の明日役に立つ実践的な知識
• PHP プロファイラの2種類の仕組みや pprof フォーマットについての明日役に立たない豆知識
  をお届けできれば幸いです。

ECサイトでのオンライン決済は当たり前の時代となっています。
オンライン決済の中でもクレジットカードでの決済を利用した方はかなり多いのではないでしょうか。
しかし今、クレジットカードの不正利用が問題となっており、経済産業省は2025年3月31日までに3Dセキュア2.0の導入を義務化しています。
3Dセキュア2.0とは何なのか、何を考慮すればよいのかをLaravelとStripeをサラッと使いながら軽く説明します。

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

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

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

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

WindowsでPHPをビルドする場合、PHP 8.0からPHP 8.3まではVisual Studio 2019を使ってビルドしていましたが、PHP 8.4ではVisual Studio 2022の使用が推奨されるようになっています。このトークでは、Windows環境におけるPHPのビルド手順や最新情報に興味がある方を対象に、ビルドに必要な準備や実際の手順についてデモを交えて解説します。Windows版のPHPをビルドするにあたって知っておきたい情報やPHP 8.4における変更点もあわせて紹介する予定です。

インターフェイスという言葉は、さまざまな文脈で使用されます。具体的には以下のようなものがあります。

• プログラミング言語に備わっているInterface（オブジェクトインターフェイス）
• interface型
• Web API（のI）
• ユーザーインターフェイス（UI）
• コマンドラインインターフェイス（CLI）
• etc.

本セッションのスコープとなるインターフェイスは「その全て」です。

本セッションではソフトウェア開発において意識せざるを得ないインターフェイスというものについて考えてみます。
前述したようにひとことでインターフェイスといってもさまざまな種類があります。
それぞれのインターフェイスの特性を明らかにし、それらに共通する要素を探ります。この共通点を本セッションでは「インターフェイスという考え方」と呼ぶことにします。

本セッションではソフトウェア開発において強力な武器となるインターフェイスという考え方について、私なりに言語化して共有します。

例えばテストも、名前重要も、スキーマ駆動開発も、モジュラモノリスも、CQRSも、全てインターフェイスが意識されています。
インターフェイスという考え方は、空気のように当たり前に自然と活用されている一方、意識するだけで開発に新たな視点を得られるものだと感じています。

本セッションを通じて、参加者の皆さんがインターフェイスという考え方に改めて気づき、インターフェイスを意識することで、参加者が自身の開発プロセスに新たな視点を得ることができるようになることを目指します。

皆さん、ちょっとしたコードの動作確認をしたい・サクッと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の仕組みに興味がある人

DKIM、DMARC、SPF
これらを説明できるでしょうか？

これらの技術はメール認証技術であり、フィッシングやスパムから守るために重要な役割を果たします。
2024年4月から本格的に始まったGmailのガイドラインに基づくメールの受信拒否設定によって、メールセキュリティの考慮は他人事ではなくなりました。
これは、非エンジニアにとっても同じです。
場合によっては、サービスの利用者にGmailガイドラインに対応するよう依頼する必要があるからです。

しかしながら、これらの知識はどうしても専門的な技術知識なしでは説明しづらく、非エンジニアにとってはなおさら理解しづらい分野です。
難しい専門用語を使わないよう注意しながら、非エンジニアの方に理解してもらおうと頑張って資料を用意して説明した方も多いのではと思います。

この発表では、非エンジニアの人にも伝わるよう、今押さえておくべきメールセキュリティについて解説します。