PHP 8.5バージョンアップをAST（抽象構文木）でテスト工数を削減する方法

記事のサマリー（TL;DR）

PHP 8.5では (integer) (boolean) 等の非正規キャスト表記とswitch文のcaseセミコロン記法が非推奨となり、修正対象が大量発生する
php-ast を使って変更前後のASTを比較すると、テキスト上に差分があっても構文構造が同一であることを機械的に確認できる
ASTに差分がない変更は「表記の正規化のみ」と判断でき、テスト範囲を必要以上に広げずに済む

PHP 8.5対応を進める開発チームが押さえておくべき工数削減のポイント

PHPのメジャーバージョンアップはアクティブサポート2年＋セキュリティサポート2年のサイクルで追い続ける必要があり、大規模なコードベースを持つ企業ほど対応コストが重くなります。サイボウズGaroonのようなエンタープライズ向けグループウェアでは、修正箇所の量そのものより「この変更は安全か」を判断するレビュー・テスト工数が課題です。

AST比較の手法は、kintoneやGaroonのようなPHPベースのSaaS製品だけでなく、EC-CUBEやfutureshopなど国内で広く使われるPHPカートのバージョンアップ作業にも同様に適用できます。変更を「構造が変わる変更（重点テスト必要）」と「表記のみの変更（AST差分なし＝軽量テストでよい）」に自動分類できれば、QAリソースを本当にリスクのある箇所に集中させることができます。

詳細

なぜPHPのバージョンアップが欠かせないのか

サイボウズGaroon開発チームのYukimiチームは「より安全なGaroonをユーザーへ届け続ける」ことを目標に据えており、PHPのバージョンアップはその中核的な作業のひとつです。

PHPのサポートモデルは次のとおりです。

アクティブサポート：リリースから2年間。不具合とセキュリティ問題の両方を修正
セキュリティサポート：その後2年間。重要なセキュリティ問題のみ修正
サポート終了後：脆弱性が発見されても修正されない

サポートが切れたバージョンを使い続けることは、既知の脆弱性を放置するリスクに直結します。PHPは毎年新バージョンをリリースするため、プロダクト側も定期的なアップデートが必須です。

一方で、バージョンアップは単純な作業ではありません。新バージョンには新機能だけでなく、後方互換性のない変更（BC Break） や 将来削除予定の非推奨機能 が含まれます。コードベースが大きいほど、調査・修正・テストの負担は増大します。

ASTとは何か

AST（Abstract Syntax Tree＝抽象構文木）は、ソースコードを構文として解析し、プログラムの構造を木構造で表現したものです。空白・改行・インデントなどの「見た目の違い」を無視し、PHPの構文としてどう解釈されるかだけを扱います。

今回のポイントは「ソースコードの表記は変わるが、ASTは変わらない」という変更パターンの識別です。

PHP 8.5で非推奨となる2つのパターン

1. 正規化されていない型名でのキャスト

PHP では現在、次のような非標準のキャスト表記が使えます。

$value = (integer) $input;   // → (int) に変更
$flag  = (boolean) $enabled; // → (bool) に変更
$rate  = (double) $number;   // → (float) に変更
$data  = (binary) $value;    // → (string) に変更

PHP 8.5 からはこれらが非推奨となり、正規化された表記への置き換えが必要です。テキスト差分ツールで見ると当然「変更あり」と表示されますが、PHPの構文として解釈した場合、(integer) も (int) も「整数へのキャスト」として同じASTノードになります。

実際に php-ast で確認したところ、変更前後のASTに差分は出ませんでした。これは「キャスト表記の正規化のみであり、式の構造自体は変わっていない」ことを機械的に証明できることを意味します。

2. switch文のcaseをセミコロンで終了させる書き方

PHPでは、次のようにcaseの後をセミコロンで終わらせる記法が文法上許容されていました。

switch ($type) {
    case 'admin';   // セミコロン（非推奨）
        return true;
    case 'user';    // セミコロン（非推奨）
        return false;
}

PHP 8.5 ではこの書き方が非推奨となり、一般的なコロン記法への統一が求められます。

switch ($type) {
    case 'admin':   // コロン（推奨）
        return true;
    case 'user':    // コロン（推奨）
        return false;
}

テキスト上は ; が : に変わるため差分が出ますが、PHP 8.4環境で php-ast を使って検証した結果、セミコロンをコロンに置き換えてもASTは完全に同一であることを確認しています。switch文の分岐構造そのものは何も変わりません。

ASTの比較をどう運用するか

ASTの比較手順は以下のとおりです。

変更前のコードを同一の php-ast パーサーで解析し、AST を取得
変更後のコードを同じパーサーで解析し、AST を取得
2つのASTを比較し、差分の有無を確認

php-ast の util.php を使うとASTの取得・比較を手軽に実施できます（詳細はPHPerKaigi 2026のセッション資料を参照）。

差分なし → 構文構造は同一 と機械的に判断でき、人間によるコードレビューやテスト範囲を絞る根拠になります。

ASTで判断できること・できないこと

ASTは万能ではありません。ASTが同一であっても、以下の観点では安全性を保証しません。

確認できる	確認できない
構文上の構造が同一であること	実行時の値の変化
PHPパーサーの解釈結果が同一であること	外部環境・設定の影響
表記の正規化に留まる変更であること	テストデータ依存の挙動

つまり、ASTで差分がない変更は「テスト範囲を絞る判断材料のひとつ」として使えますが、「あらゆる意味で安全」とは言えません。使い所を正しく理解することが重要です。

変更の優先度分類に活かす考え方

PHPのバージョンアップ対応では、修正対象が大量になりがちです。すべての変更を同じ重さで扱うと、確認作業のコストが爆発的に増えます。ASTを使うことで変更を次の2種類に分類できます。

ASTに差分なし：表記の正規化のみ。テスト範囲を最小化しやすい
ASTに差分あり：構造が変わっている。人間が重点的にレビュー・テストすべき

この分類を設けるだけで、QAリソースの配分が合理的になります。

まとめ

今回の記事でサイボウズGaroon開発チームが紹介した手法のポイントは以下のとおりです。

PHP 8.5移行で非推奨となる「非正規キャスト表記」と「caseセミコロン記法」は、テキスト上は変更に見えてもASTは変化しない
php-ast を使ったAST比較で「構造は変わっていない」ことを機械的に検証できる
変更を「構造変更」と「表記変更」に分類することで、テスト工数を合理的に削減できる

PHP 8.5への移行作業を控えているチームにとって、ASTを補助ツールとして活用する選択肢は有効です。PHPerKaigi 2026のセッション資料（SpeakerDeck公開）も、具体的な実装例とあわせて参照することを推奨します。