レガシープロダクト開発の目線から見るこれからの PHP との付き合い方
486 Views
October 10, 25
スライド概要
PHP developer
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.1M
各ページのテキスト
レガシープロダクト開発の目線から見る これからの PHP との付き合い方 2025.10.11 PHP Conference Hiroshima 2025 荒瀬 泰輔 #phpcon_hiroshima
荒瀬 泰輔 @at_taisuke PHPer歴6年くらい 徳島出身 サイボウズかき氷部の部長 広島のかき氷やスイーツのお店知っ てたら 𝕏 #phpcon_hiroshima で教え てください！ 2
Agenda 1. レガシープロダクトで PHP をアップデートする理由 2. セキュリティ期限が過ぎた PHP で起きてるヤバ脆弱性 3. レガシーだからこそ、PHP の最新情報をキャッチアップしてお こう 4. 技術的負債は少しずつ解消しておこう 5. PHP 以外の OSS ライブラリの動向にも注意 3
サイボウズの Garoon について 4
サイボウズの Garoon について サイボウズの Garoon について 中規模〜大規模な組織向けのグループウェア スケジュール・メール・メッセージなどのアプリを内蔵 cybozu.com が提供するクラウド版とオンプレミス版がある 2002年から展開、2011年からクラウドサービス提供開始 5
サイボウズの Garoon について サイボウズの Garoon について PHP 4 の時代から20年続く伝統のソースコード require_once 、 == 演算子を多用 1ファイル1万行以上の可読性の低い古いコードが多数 超巨大なコードベース（PHP だけで約120万行） 単体テストのカバレッジは約20% 保守だけでも大変！！！ 6
レガシープロダクトで PHP を アップデートする理由 7
レガシープロダクトで PHP をアップデートする理由 なぜアップデートが必要なのか？ PHP のアップデートは多大なコストがかかる （レガシープロダクトの場合は特に） 互換性のない変更に対応しなきゃいけない コードが複雑、テストコードがない お客さまが得られる恩恵が説明しずらい（予算が取れない） 8
レガシープロダクトで PHP をアップデートする理由 Garoon でも PHP 7.4 から PHP 8.0 へは一年かけてアップデート 詳しくは PHP Conference Japan 2022 での弊社赤間の発表をご覧 ください https://fortee.jp/phpcon-2022/proposal/8f29f20e-1275-49eb-89c0-fe684e28d110 より 9
レガシープロダクトで PHP をアップデートする理由 1番の理由は脆弱性に対応するため 脆弱性の被害にあった際の損失がデカすぎる どのプロダクトがいつ狙われてもおかしくない 世間のセキュリティ意識も高まっている レガシープロダクトであっても求められるセキュリティレベルは一緒 10
セキュリティサポート期限が過ぎた PHPで起きてるヤバ脆弱性 11
セキュリティサポート期限が過ぎたPHPで起きてるヤバ脆弱性 PHP 5.5.x系 CGI等を利用するWebサーバの脆弱性(CVE-2016-5385) HTTP_PROXY を悪用した脆弱性 CVSS v3 による深刻度は 8.1 (最大が10) サイボウズでも過去にこの脆弱性についてのお知らせを出したようで す https://cs.cybozu.co.jp/2016/006215.html 12
セキュリティサポート期限が過ぎたPHPで起きてるヤバ脆弱性 PHP 7.3.x 系 PHP-CGI 引数インジェクションの再来(CVE-2024-4577) windows のみで発生 CVSS v3 による深刻度は 9.8 徳丸先生曰く、最も悪用されたPHPの脆弱性(CVE-2012-1823)の残 党 外部からリモートスクリプトの実行が可能となる恐ろしい脆弱性 https://www.youtube.com/watch?v=XiIPXQX8RRU 13
セキュリティサポート期限が過ぎたPHPで起きてるヤバ脆弱性 これ以外にも大小さまざまな脆弱性が日々修正されている セキュリティサポート期間中の PHP を使用し、アップデートしてい くことで、セキュリティリスクを抑えることができる 14
レガシーだからこそ PHP の最新情報を キャッチアップしておこう 15
レガシーだからこそ PHP の最新情報をキャッチアップしておこう 脆弱性の情報 脆弱性は日々現れていて、影響度はプロダクトによって異なる すぐにアップデートで対応できればいいけど、テストが必要だったり アップデートの影響を調べたりと時間がかかることも多い 脆弱性の情報を早めに手に入れることで、対応の優先度をつけやすく なる 弊社では PSIRT（セキュリティつよつよチーム）が脆弱性情報をお知 らせしてくれたり、yamory というサービスで脆弱性を検知している 16
レガシーだからこそ PHP の最新情報をキャッチアップしておこう 将来使えなくなる PHP の機能への対応 PHP 9 では多くの機能がエラーになることが予告されている 未定義のプロパティの呼び出し、書き込み 未定義の変数の利用 ビルトイン関数の nullable でない引数に null を渡すと TypeError false からの配列の自動生成 $row = false; $row[] = 1; // PHP 8.1 : Deprecated: Automatic conversion of false to array is deprecated // PHP 9.0 : Fatal Error 17
レガシーだからこそ PHP の最新情報をキャッチアップしておこう 将来使えなくなる PHP の機能への対応 これらの情報を知ってないと、いざ PHP アップデートしたい！とい うときにボトルネックになってしまうかも… 弊社ではなりかけましたので、次からは弊社の Garoon での事例を紹 介 18
レガシーだからこそ PHP の最新情報をキャッチアップしておこう 動的プロパティへの対応 -2024年1月編PHP 8.2 アップデート時に対応しようとしたが、以下の理由で動的プ ロパティ対応がボトルネックになりそうになった 1. Phan と PHPStan を使用した静的解析の結果、動的プロパティ の利用が500件ほどあり、対応には3ヶ月ほどかかりそう 2. 一括でプロパティを宣言した場合、影響範囲が大きくQAによる テストが困難（ユニットテストがない箇所も多い） 3. リリース計画上、PHP 8.2 のリリースは遅らせたくない 19
レガシーだからこそ PHP の最新情報をキャッチアップしておこう
動的プロパティへの対応 -2024年1月編なので、一旦対応を先送りにした
Garoon ではエラーハンドラーで特定の Deprecated や Warning を
キャッチし、ログに残した上で本番環境では無視するようにできる
if (str_contains($errMsg, 'Creation of dynamic property')) {
(new LoggerFactory())->make('php_suppressed', 'garoon.log')->info(...);
return; // 例外は投げずに返す
}
20
21
レガシーだからこそ PHP の最新情報をキャッチアップしておこう https://fortee.jp/phpconkagawa-2024/proposal/039ebb21-d104-4df2-86bb-be2680979b7b 22
レガシーだからこそ PHP の最新情報をキャッチアップしておこう 23
レガシーだからこそ PHP の最新情報をキャッチアップしておこう 反省点 もっと早く動的プロパティに対応できていれば、一時的とはいえ技術 的負債にせずに済んだ そのときは最善だったけど、結果的に対応コストが高くなってしまっ た 24
レガシーだからこそ PHP の最新情報をキャッチアップしておこう PHP を計画的にアップデートするためにも、技術的負 債にしないためにも 普段から PHP の最新情報をキャッチアップし、デカい変更が入るこ とがわかったら事前に対応を計画しておこう！ 25
技術的負債は少しずつ解消しておこう 26
技術的負債は少しずつ解消しておこう 動的プロパティへの対応 -2025年7月〜9月編エラーログで動的プロパティのエラーは 33万件/週 くらい出ていた ここから地道にエラーログや静的解析の結果から修正箇所を特定し、 修正方針とテスト方針を練っていった 最終的にはバックログは30件ほどで、3ヶ月で修正でき動的プロパテ ィのエラーログは0件になった 最終目標のエラーハンドラーでのキャッチを外すのはログの様子を見 てこれから対応予定 27
技術的負債は少しずつ解消しておこう ビルトイン関数の nullable でない引数に null を渡す と TypeError 現在対応中、なんだけど… 対象の関数が多すぎ 変更箇所のテストも膨大に ?? 演算子を入れたりラッパー関数つくるのも数が多すぎる PHP Doc に嘘が書かれすぎ（ null が入るのに書いてない） 静的解析がロクに機能しない いい対応方法をご存知の方、ぜひ教えてください 28
技術的負債は少しずつ解消しておこう 技術的負債によるボトルネックは他にも CI/CD で動かしている静的解析ツールを Phan から PHPStan にしよ うとしたけど、古すぎる OSS （SmartyValidate）が原因で PHPStan がうまく動作しなかった SmartyValidate やめる計画をまず立てないといけない… → メンテされていない OSS を使い続けることはセキュリティリスク以 外にも開発を妨げる原因にもなりうる 29
PHP 以外の OSS ライブラリの動向にも 注意 30
PHP 以外の OSS ライブラリの動向にも注意 PHP 以外の OSS がボトルネックになることも Garoon では Smarty 4 を利用していたが、PHP 8.3 では Smarty 5 にしないと対応されない 早めに気付けたので、Smarty 5 へのアプデと PHP 8.3 のアプデの計 画を立てることができた → 自分たちが使っている OSS が最新の PHP に対応しているか確認 しておこう！ 対応が明記されていない OSS もあるので、開発環境で実際に PHP をアップデートして動かしてみてどんなエラーが出るかの観測も早め にやっておくと良い 31
PHP 以外の OSS ライブラリの動向にも注意 OSS が最新の PHP に対応してなかったら？ issue を見ても対応される気配がない！ 代わりの OSS を使おうにも簡単には移行できない！ 「お前もコントリビューターにならないか？」 32
PHP 以外の OSS ライブラリの動向にも注意 OSS にはコントリビュートできる 弊社のメンバーが実際に Phan や Smarty にコントリビュートして、 PHP 8.3 での不具合を直してくれました https://github.com/phan/phan/issues/4961 https://github.com/phan/phan/issues/4962 https://github.com/smarty-php/smarty/pull/1128 33
まとめ 34
まとめ レガシープロダクトとPHPの付き合い方 1. 脆弱性に対応できるよう、PHPは最新にしておこう アップデートには時間がかかることもあるので、計画を立ててお こう 2. 最新の PHP の情報をキャッチアップしておこう 脆弱性情報・非推奨になる機能の情報は定期的に仕入れよう 技術的負債はなるべく解消しておこう 35
まとめ レガシープロダクトとPHPの付き合い方 3. PHP 以外の OSS ライブラリの動向にも注意 PHP はアップデートできても使っていた OSS が対応していな い、新しい OSS にするにはコストがかかりすぎる場合も OSS にはコントリビュートできる、自分たちで OSS を対応させ ることも視野に入れよう 36
え？当たり前のことしか言ってないやん って？ 37
そのとおり 38
その当たり前をちゃんとこなすことが、 レガシープロダクトにとっては大事で、 難しいという話でした 39
ご清聴ありがとうございました！ 40