PHP 8.6 の最新動向、サプライチェーン攻撃への備え、30 年動き続けるレガシーコードとの向き合い方・・・・
国内最大級の PHP イベント「PHP Conference Japan 2026」に参加してきました。
それでは、セッションごとに振り返っていきます。
イベント情報
項目 | 内容 |
|---|---|
イベント名 | PHP Conference Japan 2026 |
開催日 | 2026 年 7 月 20 日 |
会場 | 大田区産業プラザ PiO |
公式サイト |
PHP の今とこれから 2026 - PHP 8.6 における新機能と未来への進化 -（廣川 類 氏）
PHP の「今」を総まくりするキーノートです。
PHP 8 系の最終版になると見られる PHP 8.6 の新機能を紹介いただきました。
個人的に注目したポイントはこのあたりです。
- 部分適用（Partial Function Application） :
$add = add(10, ?);のように、アロー関数でラップせずにコールバックを直感的に生成できる新構文 - ネイティブ非同期（Polling API） : 外部モジュール頼みだったイベント駆動処理が、ついに PHP コアに組み込まれる
- clamp() 関数 :
min(max($value, $min), $max)と書いていた冗長な範囲制御がclamp($value, $min, $max)の一発に - SortDirection Enum :
'ASC'/'DESC'の文字列指定を言語仕様として型安全に扱えるように - セッションのデフォルトセキュリティ強化 :
session.cookie_secure = Onをはじめ、標準設定のまま堅牢に - mbregex の非推奨化 :
mb_ereg系は 8.6 で非推奨、9.0 で廃止予定。`preg_match` +u修飾子への移行が必要です
一方で、こうした進化を安心して享受し続けるための前提として語られたのが、PHP のライフサイクルの話です。
PHP は毎年マイナーバージョンがリリースされ、サポート期間はアクティブサポート 1 年 + セキュリティ修正 3 年です。
EOL を過ぎたバージョンにはセキュリティ修正が提供されないため、アップデート周期を前提にしたバージョンアップ計画が不可欠だと再認識しました。
また、PHP 財団の専属デベロッパー 12 名による開発体制や、日本 PHP ユーザ会・地方勉強会などコミュニティの広がりにも触れられました。
そして講演の締めくくりは、PHP と AI の協業についてでした。
2025 年を境にプロダクションコードを AI に任せられるようになってきた今、PHP を書く私たちに求められるのは「変化を楽しむこと」、という言葉が印象に残りました。
Laravel で学ぶ Web アプリケーションチューニング入門（富所 亮 氏）
「最近なんだか遅い」「アクセスが増えると急に重くなる」。
Web アプリ開発で避けて通れないパフォーマンスの悩みに対して「何を計測し」「どこを疑い」「どう改善するのか」を体系的に教えてくれる入門セッションでした。
出発点として語られたのは、「遅い」という言葉の曖昧さです。
「遅い」は主観的で個人差のある表現だからこそ、「該当時間帯は通常より 500ms レスポンスが遅かった」のように、定性的な表現を定量的な表現に変えることがすべての始まりになります。
そのうえで、原因を切り分けて改善につなげる流れが示されました。
- ネットワーク全体から俯瞰すると Web アプリの世界は案外小さい。大陸間通信や速度制限のかかった格安 SIM など、コントロールできない領域が「遅い」の原因になっていることもある
- だからこそレイテンシーを分解して、時間を費やしているのが本当に Web アプリなのかを確かめる。第一歩は Web サーバのログにレスポンスタイムを出力すること。とにかく「出して見れるようにする」
- CloudWatch、Mackerel、Datadog、Laravel Cloud / Nightwatch など頼れるツールを活用して、メトリクスを定期的に眺める習慣をつけると変化に気づけるようになる
- ボトルネックを見つけたら、「特定 → 改善 → 特定」の改善ループを回し続ける
そして何度も繰り返されたのが、このメッセージです。
ボトルネックから目を逸らすな！
「ボトルネックはボトルネックだからボトルネック」という言葉も印象的でした。
ボトルネック以外の「簡単そうなところ」や「できそうなところ」をどれだけ改善しても、全体は速くなりません。
臭いものに蓋をするのではなく、臭いものを取り除く。
漫画「スラムダンク」で登場した有名な台詞「断固たる決意」を持って向き合わねばと感じました。
印象的だったのは、この話が AI の使い方にもつながっていたことです。
「何をどうして良いかわからない」ままの丸投げではなく、解決の解像度を上げてから具体的な指示を出すことが重要になります。
「推測するな、計測せよ」という原則は AI 時代にこそ効いてくるのだと感じました。
セッションの中では、目を逸らさないための基礎知識を固める書籍も紹介されました。
自分も武器を増やす & 理解を深めるために、この機会に再読します。
AI コード生成 × サプライチェーン攻撃 — PHP が直面する"二重の信頼問題"（斉田 真也 氏）
「composer require ... を AI が提案してきた。そのパッケージ、本当に安全ですか？」という問いかけから始まる、セキュリティのセッションです。
サプライチェーン攻撃は「信頼している対象を経由して行われる攻撃」であり、自分のコードをいくらレビューしても気付けないのが怖いところです。
さらに AI コード生成の普及で、AI が存在しないパッケージ名を提案し、攻撃者がその名前を先回りして登録しておく「SlopSquatting」という新しい攻撃まで登場しています。
現実的な防御策として紹介いただいたのは、次のような多層セキュリティゲートでした。
- まずは
composer self-update。Composer 2.9 で既知の脆弱版のブロック、2.10 で既知マルウェアの自動ブロックが搭載済み roave/security-advisoriesの導入で、既知のセキュリティ問題があるパッケージのインストールを防ぐcomposer audit --lockedを CI に組み込み、既知 CVE を検出したら PR を fail させる- Dependabot / Renovate で更新を統制し、minimumReleaseAge（Cooldown）を 3〜7 日に設定して公開直後の毒入り版を踏まない
さらに、SlopSquatting のような AI のハルシネーションに対しては、AI との付き合い方そのものを見直す対策が紹介されました。
- AI の記憶に任せてバージョンを指定させるのではなく、プロンプトに現行の正確なバージョンを明示（PIN）する
- AI に「fetch の前に search を実行する」ように指示して、パッケージがレジストリに実在することを確認させる
- エージェントによる auto-run（自動 install）を禁止する
- AI による提案は、必ず audit / roave / CI による検査を通す
疑って、確かめてから require。
あらためて「論より証拠」ということで実際に AI が提案する内容を疑い、事実確認をすることが大切だという学びになりました。
AI 時代の PHPer 生存戦略 〜「言語、もうなんでもよくない？」に本気で向き合う 〜（Hayashi Sugiki 氏）
「AI があれば言語なんてなんでもいい」— 半分冗談、半分本気のこのフレーズに正面から向き合うセッション。
登壇者の答えは「半分正解」でした。
どの言語も AI で"それっぽく"書ける時代になり、人間が実装すること自体はほぼなくなると予測しつつも、「枯れている」と言われる PHP はサーバサイド言語シェアで今も 1 位であり、学習データが豊富なぶん AI が間違えにくい言語かもしれない、という再評価が印象的でした。
一方で、書く速さと量で AI に勝つことはできません。
それでも「検証」は楽になっておらず、要件の品質やレビューで人間がボトルネックになるケースが増えています。
そのうえで語られたのが、この言葉でした。
消えるのは「コードを打つだけの職」であって「開発者」ではない。
人間に残る価値は、ユーザやサービスへの理解、PHP の知見、AI コードを見定める審美眼といった 付加価値の積み上げであり、感動は「機能の足し算」ではなく「人間の判断」から生まれる、というのが登壇者の答えでした。
あわせて、自分の感動体験を分解して言語化し、「感動する観点」を集めるという実践方法も紹介されました。
エンドユーザの存在を意識して開発する、という当たり前を改めて胸に刻んだセッションでした。
Laravel Boost に学ぶ、AI に PHP を書かせる技術 〜 OSS の実装から蒸留するエージェント制御の王道 〜（武田 憲太郎 氏）
AI 制御を「公式の関心事」として設計した数少ない PHP パッケージ、Laravel Boost の内部実装から普遍的な設計原則を抽出するセッションです。
核となるのは「情報の段層」という考え方です。
- 段（いつ渡すか） : 常時ロード（AGENTS.md）→ 段階的開示（SKILL.md）→ 実行時取得（MCP サーバ）の 3 段階で、コンテキストの肥大化を防ぐ
- 層（どう縛るか） : Lint やフォーマッタで「狭く即時」に、静的解析やテストで「広く機械的」に、レビュープロンプトで「大きく判断」する。安く確実な制御に多くを頼るのはテストピラミッドと同じ発想
- Laravel Boost はこの段層を、AI Guidelines（常時ロード）・Agent Skills（段階的開示）・MCP サーバ（実行時取得）として実装している
- MCP 経由でインストール済みパッケージの実バージョンや直近のエラーログを返すことで、AI が学習データではなく実環境を根拠にコードを書けるようになる
良い設計は、読み手が人間でも AI でも等しく効く。
フレームワークの規約は公式が配布してくれますが、ドメインの規約を定義するのは我々プログラマの仕事です。
「AI にどんな設計を渡すか」で成功と失敗の差が出るという言葉は、日々 AI と協業する身として重く受け止めました。
"今のまま" PHP サーバーを高速化する、PHP 8.6 に向けた "OPcache Static Cache" RFC について（Go Kudo 氏）
PHP のシェアードナッシング型アーキテクチャ（リクエストごとにすべて初期化される仕組み）は、メモリ管理を意識しなくてよい反面、データがリクエスト境界をまたげず、キャッシュ面で圧倒的に不利という弱点があります。
FrankenPHP や Swoole といった常時実行型ランタイムはこの弱点を解消できますが、既存コードベースの移行は相当な困難を伴います。
そこで「従来型の PHP のまま、オプトイン形式でリクエスト間を持ち越せる値を使えるようにしよう」というのが、登壇者自身が提出した RFC のお話です。
興味深かったのは、その顛末も含めて率直に語られたことです。
最初の OPcache Static Cache 案は変更規模が拡大してレビューコストが高くつき、それを踏まえて user_cache としてフルスクラッチで作り直して再提出したそうです。
できるからといって Feature creep になるのは良くない。
現実のワークロードを考えよう。
レビューする側の気持ちになってみよう。
この教訓は普段のプロダクト開発にもそのまま持ち帰れる話でした。
また、今回のセッションを通じて PHP の RFC を眺めてみようと思うきっかけになりました。
30 年価値を出し続けている PHP プロダクト ─ レガシーコードと向き合う（藤田 泰三 氏）
DLsite は、30 年間止まらずに価値を届け続けてきたサービスです。
その裏側には、Mojavi + Smarty の独自構成、約 1.2 万ファイル / 1,500 本規模のルートという巨大なコードベースがあります。
このセッションで最初に提示された視点が、すべてを物語っていました。
レガシーは「負債と資産が同居する状態」。「消せない」ではなく「消さない」。
負債と呼ばれがちなコードベースを「30 年分の価値を生み出し続けてきた証」とまず認めたうえで、価値を生かしたまま変え続けるための具体策が共有されました。
- 判断基準は常に事業影響という物差し。PHP 本体は追従必須、フレームワークは自動保守で対応
@deprecatedによる段階的廃止と提供終了機能の削除で、コードベースをコンパクトに保つstrict_typesで境界線を引きながら、モダンアーキテクチャへ段階的に乗せ替える- フレームワークを乗り換えるのではなく、足りないものを補っていく
- AI 駆動開発がレガシー借金の"徳政令"になり得る
「価値あるシステムとは、古くてもユーザに愛され続けるシステム」であり、それを支えるのは技術力と組織力です。
レガシーコードに悩むすべてのチームに届いてほしいセッションでした。
まとめ
一日を振り返って、自分なりに行き着いた答えが以下になります。
計測し、疑い、設計を渡す。
AI 時代の PHPer の武器は「判断の質」である。
AI がコードを書いてくれる時代だからこそ、ボトルネックを定量的に特定する力、AI の提案を疑って確かめる力、そして AI に渡す設計を組み立てる力が問われると感じました。
そして、PHP 財団と国内コミュニティが四半世紀にわたってこの土壌を耕し続けてくれていることに、改めて感謝の想いでいっぱいになりました。
まずは CI へのセキュリティゲート組み込みから始めたり、ローカルの PHP 勉強会にも出席したいと思います。
最後になりましたが、素晴らしい場を作ってくださった運営スタッフの皆さま、そして貴重な知見を惜しみなく共有してくださった登壇者の皆さまに、心からの感謝を。
Share ：
