PHP 8.0.30 から
8.4.27 / 8.5.12 へ

※2026年10月時点の公開情報に基づきます。項目数と内容は、この特集の変更カタログ（全 213 項目）と php.net の移行ガイドから作っています。

このページが当てはまるバージョン

PHP 8.0 系のすべて、8.0.0 から 8.0.30 までの 31 版が対象です。PHP はパッチ版（3 つ目の数字）の間では後方互換性を保つので、8.0.7 で動いているコードも 8.0.30 で動いているコードも、新しい版へ移すときに直す箇所は同じです。8.0 系のパッチ版の途中で入った変更のうち、コードの修正が要るものは、この特集の資料では把握していません。細かなセキュリティ修正は ChangeLog の各パッチの項で確かめてください。

8.0 系の最後のリリースは 8.0.30（2023-08-03）です。8.0.31 以降の番号は php.net から出ておらず、php-src のリポジトリにもタグがありません（2026-10-23 に確認）。どこかで 8.0.31 や 8.0.33 といった番号を見かけても、8.0 系であればこのページの内容がそのまま当てはまります。

移行先として扱うのは、2026-10-21 に公開されたセキュリティ修正版の 4 つです。起点と移行先の組み合わせごとの項目数は次のとおりです。8.0.0 → 8.4.27 も 8.0.15 → 8.4.27 も、一覧は 8.0.30 → 8.4.27 と同じです。

• PHP 8.0.30 → PHP 8.4.27：58 項目（削除 6・非推奨 24・挙動変更 28）
• PHP 8.0.30 → PHP 8.5.12：80 項目（削除 7・非推奨 36・挙動変更 37）
• PHP 8.0.30 → PHP 8.3.36：42 項目（削除 4・非推奨 17・挙動変更 21）
• PHP 8.0.30 → PHP 8.2.35：28 項目（削除 3・非推奨 13・挙動変更 12）

まず結論：どこへ移すか

8.0 起点なら、8.4.27 へ直行するのが第一候補です。8.1・8.2・8.3・8.4 の 4 版を経由しますが、7.x から 8.0 へ上げたときのように文法や比較の規則ごと変わる項目は入っていません。58 項目のうち 24 項目は非推奨で、Deprecated の通知がログに出るだけで処理は続きます。その一方で、8.1 の既定値の変更は 8.0 から上げる人だけが通る関門で、7.x 起点よりむしろこの起点で目立つ問題になります。

バックポートは応急処置。8.0 系に
正式な修正版は出ない

2026-10-21 の php.net の勧告は、「PHP 8.1 and older no longer receive updates from the PHP project」と書いたうえで、脆弱性の深刻さを理由に、PHP セキュリティチームが 7.4・8.0・8.1 向けの「minimal source-backports」を用意したと説明しています。対象として挙げているのは「people building from source or without access to an LTS vendor」、つまりソースから自分でビルドする人と、LTS ベンダーの延長サポートを使えない人です。

8.0 向けは php-src の PHP-8.0-CVE-2026-109618-109619 ブランチです。2026-10-23 に中身を見たところ、修正のコミットのメッセージは「Avoid state corruption via bailout / Minimal mitigation for EOL version.」で、main/php_version.h の版番号は 8.0.30 のままでした。8.0.31 というタグもリリースもありません。このブランチからビルドしても php -v は 8.0.30 と表示するので、修正を当てた PHP と当てていない PHP を版番号では見分けられない点にも注意が要ります。

このブランチは今回の 2 件の CVE（CVE-2026-109618 / CVE-2026-109619）を塞ぐための応急処置で、8.0 系の保守が再開したわけではありません。次に別の脆弱性が見つかったときに同じ手当てがあるとは、勧告のどこにも書かれていません。ディストリビューションのパッケージや LTS ベンダーの修正で今回をしのいだ場合も、そこで止めずに、サポートが続く 8.4 か 8.5 へコードを移す。このページはその前提で書いています。

この起点で特に危ない変更

8.0 起点で一番気をつけたいのは、8.1 で入った既定値と戻り値の型の変更です。8.1 は 8.0 から上げる人だけが通る版で、7.x 起点では 8.0 の大きな変更の陰に隠れがちな項目が、ここでは主役になります。以下は、エラーを出さずに結果が変わるものと、通知が大量に出て本当の問題をログに埋もれさせるものから選んだ 10 件です。

1. 8.1htmlspecialchars() がシングルクォートも変換する

   既定のフラグが ENT_COMPAT から ENT_QUOTES|ENT_SUBSTITUTE に変わりました。' が ' になり、不正なバイト列は空文字列ではなく U+FFFD に置き換わります。ブラウザの表示はほとんど変わらないので目では気づけず、出力 HTML を文字列で比べるテストや、エスケープ済みの値を保存して後で突き合わせる処理で差が出ます。

   → 一覧の該当項目へ

2. 8.1PDO が数値の列を
   int / float で返す

   PDO MySQL でエミュレートプリペアドを使っている場合と PDO SQLite で、整数の列が "1" ではなく 1 で返ります。$row['status'] === '1' は常に false になり、分岐が黙って反対側に倒れます。json_encode() の出力も変わるので、API の受け手が文字列を前提にしていれば、壊れるのは相手側です。

   → 一覧の該当項目へ

3. 8.1内部関数に null を渡すと
   Deprecated

   strlen(null)、trim(null)、htmlspecialchars(null) などが通知の対象です。DB の NULL 列や未設定の $_GET をそのまま文字列関数に渡しているコードでは、1 回の画面表示で何十件も出ることがあります。動作は続きますが PHP 9 で TypeError になる予定で、件数が多いぶん、他の重要な通知を埋もれさせます。

   → 一覧の該当項目へ

4. 8.1mysqli がエラーで
   例外を投げる

   既定のエラー報告モードが MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT になりました。mysqli_query(...) or die(...) や if (!$result) で書いたエラー処理には到達せず、mysqli_sql_exception が捕まえられないまま上がります。用意していたエラー画面ではなく、PHP の Fatal error の画面やログになります。

   → 一覧の該当項目へ

5. 8.1継承したメソッドの static 変数が
   親子で共有される

   メソッドの中の static $cache を、子クラスごとのキャッシュとして使っていたコードが対象です。8.1 からは親クラスと子クラスが同じ変数を見るので、別のクラス向けに計算した値が返ります。エラーも通知も出ません。

   → 一覧の該当項目へ

6. 8.2宣言していないプロパティへの
   代入が Deprecated

   8.0 時代に書いたモデルクラスや、配列の値をオブジェクトに詰め替えるヘルパーでよく出ます。プロパティの宣言を足すのが本来の直し方で、すぐには直せないクラスだけ #[\AllowDynamicProperties] を付けて先送りします。PHP 9 で Error になる予定です。

   → 一覧の該当項目へ

7. 8.2strtolower() が
   ロケールを見なくなる

   strtolower()・ucfirst()・stripos() などが ASCII の文字しか変換しなくなりました。setlocale() で Latin-1 などのロケールを設定し、アクセント付きの文字を変換していたコードでは、結果が黙って変わります。UTF-8 の日本語にはもともと効かない関数なので、影響を受けるのは主に多言語のサイトです。

   → 一覧の該当項目へ

8. 8.4round() の結果が
   境界値で変わる

   内部の事前丸めが無くなり、たとえば 0.49999999999999994 は 1 ではなく 0 に丸められるようになりました。ほとんどの値では結果は同じですが、金額や税額の端数処理に round() を使っているなら、境界の値で旧版と結果を比べてから切り替えてください。

   → 一覧の該当項目へ

9. 8.4IMAP・OCI8・PSpell が
   本体から消える

   メールの受信に imap_open() を使っている、Oracle に OCI8 でつないでいる、といったコードは 8.4 では関数自体が無くなり Fatal error になります。壊れ方は分かりやすいものの、PECL でのビルドや純 PHP のライブラリへの置き換えには時間がかかるので、移行の最初に有無を調べておきます。

   → 一覧の該当項目へ

10. 8.5PDO::FETCH_* の
    定数の値が変わる

    8.5.12 を選ぶ場合の項目です。PDO::FETCH_GROUP や PDO::FETCH_UNIQUE などの値が変わったため、定数名ではなく数値をそのまま書いているコードは、別の取得モードとして解釈されます。定数名で書いていれば影響はありません。

    → 一覧の該当項目へ

起点から移行先までに入った
変更の全一覧

8.0 系から 8.5 までに入った削除・非推奨・挙動変更を、入った版ごとに 5 つのブロック（[8.1]〜[8.5]）で並べています。一覧は累積で、たとえば 8.4.27 へ移すなら [8.1]〜[8.4] のブロックをすべて確認します。下の移行先を選ぶと、選んだ版より後のブロックは折りたたまれ、件数の合計も選んだ移行先に合わせて変わります。

区分の見方は次のとおりです。削除は Fatal error や Error 例外になるか、機能や拡張そのものが無くなるもの。非推奨は E_DEPRECATED の通知が出るが動くもの（将来の版で削除の予定）。挙動変更は、エラーを出さずに結果やエラーの種類が変わるもの。各項目の id（v81-03 など）は、エージェントへの指示や作業記録で項目を指すときに使えます。

※以下の一覧に載せたコード・コマンド・プロンプトはあくまで例です。最終確認は php.net の公式 ChangeLog・移行ガイドで行ってください。内容の利用により生じた損害について当方は責任を負いません（詳しくはページ末尾の免責事項）。

作業の進め方

8.0 起点の移行は、構文を書き直す作業より、通知と既定値の違いを一つずつ確かめる作業が大半を占めます。次の順で進めると、機械で拾えるものと人が判断するものを分けやすくなります。コマンドはリポジトリの直下で、Docker が使える端末から実行する前提です。

1. 消える拡張と既定値に頼る箇所を数える

最初に、8.4 で関数ごと無くなる拡張と、8.1 の既定値の変更に引っかかりそうな書き方を数えます。ここで件数をつかんでおくと、移行先を 8.4.27 にするか、いったん 8.3.36 で止めるかを早めに決められます。grep の結果は候補の一覧で、該当しないものも混じります。

# 8.4 で削除される拡張（IMAP / OCI8 / PDO_OCI / PSpell）
grep -rnE '\b(imap_|oci_|pspell_)[a-z_]+\(' --include='*.php' --exclude-dir=vendor . | wc -l

# 8.1 の既定値の変更：フラグを省略した htmlspecialchars() / htmlentities()
grep -rnE '\b(htmlspecialchars|htmlentities)\(\s*[^,()]+\)' --include='*.php' --exclude-dir=vendor .

# 8.1 の mysqli の例外化：or die / or exit で書いたエラー処理
grep -rnE 'mysqli_[a-z_]+\(.*\)\s+or\s+(die|exit)' --include='*.php' --exclude-dir=vendor .

# 8.1 の PDO のネイティブ型：文字列の数字と厳密比較している箇所
grep -rnE "===\s*'[0-9]+'|'[0-9]+'\s*===" --include='*.php' --exclude-dir=vendor .

2. 移行先の PHP をコンテナで用意する

Docker の公式イメージには、パッチ版まで固定したタグがあります。ホストの PHP は 8.0 のまま残し、解析とテストはコンテナの 8.4.27 で動かします。8.5.12 も候補に残すなら、同じ手順をタグだけ変えてもう一度実行します。

docker run --rm php:8.4.27-cli php -v
docker run --rm php:8.5.12-cli php -v

# 依存パッケージのうち、8.4.27 を拒んでいるものを一覧にする
docker run --rm -v "$PWD":/app -w /app composer:2 composer why-not php 8.4.27

composer why-not が何か返したら、そのパッケージの更新を先に済ませます。フレームワークの版を上げる必要があるなら、PHP の移行とは別の作業として切り出したほうが、問題が起きたときに原因を切り分けられます。

3. 静的解析で拾えるものを拾う

PHPCompatibility は、指定した範囲の PHP で使えない関数や構文を指摘します。8.0 起点では範囲を 8.0-8.4 にすると、8.0 でも 8.4 でも動く書き方になっているかを見られます。Rector は機械的に直せるものを書き換えますが、版ごとのセットには「新しい書き方への置き換え」も含まれ、差分が膨らみます。8.0 起点では、8.1 → 8.2 → 8.3 → 8.4 と 1 版ずつ上げてコミットを分けると、レビューで何が変わったかを追えます。withPhpSets() の名前付き引数は「その版までの規則をすべて」適用する指定で、1 つの設定ファイルで 1 回しか呼べません。

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/app'])
    // 1 回目は php81、コミットしたら php82、php83、php84 と上げていく
    ->withPhpSets(php81: true);

composer require --dev phpcompatibility/php-compatibility rector/rector phpstan/phpstan

# 8.0 でも 8.4 でも動く書き方かを調べる
vendor/bin/phpcs -ps . --standard=PHPCompatibility --runtime-set testVersion 8.0-8.4 --ignore=*/vendor/*

# 書き換えの差分だけを見る（まだファイルは変えない）
vendor/bin/rector process --dry-run

8.1 の「内部関数への null 渡し」には、Rector の NullToStrictStringFuncCallArgRector という個別の規則があり、引数を (string) でくるみます。ただしこれは PHP 8.1 のセットには入っていない任意の規則で、NULL と空文字列を区別していた処理まで一律に空文字列にしてしまいます。全体に当てるより、ログで件数の多い箇所を確かめてから、範囲を絞って使うほうが安全です。

4. Deprecated を全件ログに出して潰す

このページの項目の 4 割は非推奨なので、移行の進み具合は「E_DEPRECATED が何件残っているか」でほぼ測れます。本番用の設定（php.ini-production）は E_DEPRECATED を報告しない既定になっているので、移行作業の間は、コンテナに専用の設定を足してすべて出します。

error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log = /app/var/php-upgrade.log

mkdir -p var && : > var/php-upgrade.log
docker run --rm -v "$PWD":/app -w /app \
  -v "$PWD/docker/php-upgrade/zz-upgrade.ini":/usr/local/etc/php/conf.d/zz-upgrade.ini \
  php:8.4.27-cli vendor/bin/phpunit

# 種類ごとの件数（ファイル名と行番号を落として、同じ通知をまとめる）
grep 'PHP Deprecated' var/php-upgrade.log \
  | sed -E 's/^\[[^]]*\] PHP Deprecated: +//; s/ in \/.* on line [0-9]+$//' \
  | sort | uniq -c | sort -rn | head -30

# ファイルごとの件数（どこから直すかを決める）
grep -oE 'PHP Deprecated: .* in /app/[^ ]+' var/php-upgrade.log \
  | sed -E 's/.* in //' | sort | uniq -c | sort -rn | head -30

テストが pdo_mysql などの拡張を必要とするなら、公式イメージをそのまま使わず、下の「コーディングエージェントに一括で任せる」にある Dockerfile で拡張を足したイメージに置き換えてください。PHPUnit のテストが無い、あるいは画面を通らないと動かない処理が多い場合は、同じ設定をステージングの PHP-FPM に入れ、普段の操作を一通り流してからログを集計します。8.0 起点で件数が膨らみやすいのは Passing null to parameter（8.1 の null 渡し）と Creation of dynamic property（8.2 の動的プロパティ）です。どちらもごく普通の書き方から出る通知なので、件数の多い順に直し、0 件になるまで繰り返します。

php.ini の error_reporting では、ビット演算の | や &、~ の組み合わせも書けますが、移行作業中は E_ALL だけにしておくと、何かを除外したまま見落とす心配がありません。

5. 静かに壊れる項目は、旧版との出力比較で確かめる

8.1 の htmlspecialchars() の既定値、PDO のネイティブ型、8.4 の round() は、通知が出ないので 4. のログには現れません。8.0 の環境と 8.4.27 の環境に同じリクエストを送り、返ってきた HTML や JSON を比べるのが確実です。

# urls.txt に主要な画面と API の URL パスを 1 行ずつ書いておく
mkdir -p out/old out/new
while read -r path; do
  name=$(echo "$path" | tr '/?=&' '____')
  curl -s "https://old.example.test$path" > "out/old/$name.html"
  curl -s "https://new.example.test$path" > "out/new/$name.html"
done < urls.txt
diff -r out/old out/new

差分に ' が増えていれば 8.1 の ENT_QUOTES、JSON の "1" が 1 になっていれば PDO のネイティブ型です。差が出たら、新しい出力を正とするのか、フラグや PDO::ATTR_STRINGIFY_FETCHES で旧来の出力を保つのかを決めます。この判断はエージェントには任せず、画面や API の利用者を知っている人が行います。

6. ステージングで切り替えてから本番へ

ステージングの PHP を 8.4.27 に替え、4. のログが 0 件、5. の差分が説明のつくものだけになったら、本番を切り替えます。php.ini や FPM のプール設定は 8.0 のものを持ち込まず、8.4.27 の php.ini-production から作り直し、必要な値だけを移します。切り替え後もしばらくは log_errors を有効にしたまま、E_DEPRECATED と E_WARNING の件数を見ておくと、テストで通らなかった経路の問題を拾えます。

コーディングエージェントに一括で任せる

このページの一覧は、人が読むチェックリストであると同時に、Claude Code や Codex にそのまま渡せる作業指示の材料でもあります。8.0 系から 8.4.27 までの変更は項目数が多いので、全部を手で追うより、機械で拾えるものは静的解析と Rector に任せ、エージェントには「一覧と突き合わせて残りを探し、直した理由を項目 id で説明する」ところまでを頼むのが現実的です。

ただし、エラーを出さずに結果だけが変わる種類の変更は、ツールでもエージェントでも見落としが出ます。この節の最後にある「検収で人が見るところ」は、エージェントの報告を受け取ったあとに必ず人が確認してください。

※ツール名・設定の書き方・コマンドは、2026年10月時点の各公式ドキュメントで確認したものです。

任せる前に用意しておくもの

• 作業ブランチ。git switch -c php-upgrade-8.4 のように移行専用のブランチを切り、エージェントには main を直接触らせない。
• 今の動きを記録したテスト。テストが無いなら、移行前（8.0.30 のサーバーやステージング）で主要な画面・API・バッチの出力を保存しておく。移行後に同じ入力で比べられれば十分で、立派なテストでなくて構いません。
• 移行先の PHP を動かすコンテナ。Docker の公式イメージには php:8.4.27-cli のようにパッチ版まで固定したタグがあります。ホストの PHP ではなく、このコンテナで解析とテストを動かします。
• 参照資料の保存。このページを docs/php-upgrade/reference.html として保存しておくと、エージェントがネットワークに出られない設定でも一覧を読めます。

FROM php:8.4.27-cli
RUN apt-get update && apt-get install -y --no-install-recommends git unzip \
    && rm -rf /var/lib/apt/lists/*
# アプリが使う拡張をここで足す（例: MySQL）
RUN docker-php-ext-install pdo_mysql mysqli
COPY --from=composer/composer:2-bin /composer /usr/bin/composer
WORKDIR /app

git switch -c php-upgrade-8.4
mkdir -p docs/php-upgrade
curl -sL -o docs/php-upgrade/reference.html "https://shinichi.noguchi.jp.net/feature/phpupgrade/8.0.html"
docker build -t php-upgrade:8.4.27 docker/php-upgrade
# 以降のコマンドはこのコンテナの中で動かす
docker run --rm -it -v "$PWD":/app php-upgrade:8.4.27 bash

機械的に洗い出す道具

エージェントに頼む前に、決まった規則で拾える変更はツールで拾っておきます。エージェントにもこれらを実行させ、その結果を作業の起点にさせると、読み落としが減ります。

PHPCompatibility は、README が案内する 10 系を入れます。安定版の最新 9.3.5 は 2019年12月の版で、PHP 8.0 の正式リリースより前のものです。10 系は2026年10月時点でまだプレリリース（10.0.0-alpha2）で、PHP 7.2 以上と PHP_CodeSniffer 4.0.2 以上が必要です。古いアプリの composer.json に入れると依存が衝突することがあるので、その場合は tools/ のような別ディレクトリに解析用の composer.json を作って入れてください。

composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/php-compatibility:"^10.0.0@dev"
# 移行先だけで動けばよい場合
vendor/bin/phpcs -ps . --standard=PHPCompatibility --runtime-set testVersion 8.4 --ignore=*/vendor/*
# 切り替えの間、旧版と移行先の両方で動かす必要がある場合は範囲で指定する
vendor/bin/phpcs -ps . --standard=PHPCompatibility --runtime-set testVersion 8.0-8.4 --ignore=*/vendor/*

Rector は、composer.json の "php" 指定から移行先を読ませる書き方が公式の推奨です。先に composer.json の require.php を ^8.4 にしてから、引数なしの withPhpSets() を使います。composer.json をまだ変えられないときは、名前付き引数で版を 1 つだけ指定します（名前付き引数なので、Rector は PHP 8.0 以上で動かします）。差分が大きすぎて読めない場合は、規則を安全なものから 1 つずつ足していく withPhpLevel(0) から始め、数字を 1 ずつ上げる方法も公式に用意されています。

<?php

use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([
        __DIR__ . '/src',
        __DIR__ . '/public',
    ])
    // composer.json の "require": {"php": "^8.4"} を読み、その版までの規則をまとめて適用する
    ->withPhpSets();
    // composer.json を先に変えられない場合は、上の行の代わりに版を 1 つだけ指定する
    // （8.4 なら php84、8.5 なら php85。withPhpSets() は 1 回しか呼べない）
    // ->withPhpSets(php84: true);

composer require rector/rector --dev
vendor/bin/rector process --dry-run   # 差分を見るだけ
vendor/bin/rector process             # 確認してから適用

PHPStan は、phpVersion を指定しないと PHPStan を動かしている PHP の版が前提になります。移行先のコンテナで動かすならそのままでも合いますが、設定ファイルに書いておくほうが取り違えがありません。古いコードにいきなり高いレベルを当てると指摘が多すぎて読めないので、0 から始めて上げていきます。

parameters:
    level: 0
    phpVersion: 80400 # PHP 8.4。8.5 なら 80500
    paths:
        - src
        - public

Claude Code に頼む

Claude Code は、リポジトリ直下の CLAUDE.md を毎回読み込みます。移行の間だけ守らせたい約束をここに書いておくと、指示のたびに繰り返さずに済みます。

## PHP 移行のルール（8.0.30 → 8.4.27）

- 参照資料は https://shinichi.noguchi.jp.net/feature/phpupgrade/8.0.html（保存版: docs/php-upgrade/reference.html）。8.0 系から 8.4 までに入った削除・非推奨・挙動変更の一覧で、各項目に id（例: v80-05）がある。
- 実行・解析・テストは Docker の php-upgrade:8.4.27 イメージ（docker/php-upgrade/Dockerfile）で行う。ホストの php は使わない。
- 変更の根拠は、参照資料の項目 id で示す。
- 1 コミットに 1 種類の変更。Rector の自動変換と手作業の修正を同じコミットに混ぜない。
- @ 演算子、error_reporting の変更、空の catch で警告やエラーを隠さない。
- テストの期待値を変えるときは、変える理由を必ず報告する。
- vendor/ 配下は編集しない。依存パッケージは composer で更新する。
- 次の作業の前には止まって確認を求める: composer.json の require の変更、DB のスキーマ・文字コードに関わる変更、php.ini・.htaccess・FPM 設定など本番環境の設定の変更、業務上の計算結果が変わりうる修正。

一括依頼のプロンプトです。段階ごとに止まって報告させる形にしています。一度に最後まで走らせると、途中の判断を人が確かめる機会がなくなるためです。

このリポジトリの PHP を 8.0.30（8.0 系）から 8.4.27 へ移行します。CLAUDE.md（Codex の場合は AGENTS.md）の移行ルールに従ってください。

参照資料: https://shinichi.noguchi.jp.net/feature/phpupgrade/8.0.html（保存版: docs/php-upgrade/reference.html）
参照資料の「起点から移行先までに入った変更の全一覧」が、8.0 系から 8.4 までに入った削除・非推奨・挙動変更のチェックリストです。移行先 8.4.27 より新しい版のブロックは対象外です。各項目の id（例: v80-05）を作業記録に使ってください。

作業は次の 6 段階で進め、段階ごとに止まって報告してください。私の返事があるまで次の段階に進まないでください。

① インベントリ
- composer.json と composer.lock、使っている PHP 拡張、php.ini の設定に依存している箇所、PHP ファイルの数、テストの有無と実行方法を調べ、docs/php-upgrade/inventory.md にまとめる。
- composer why-not php 8.4.27 と composer outdated --direct を実行し、移行先で動かない依存パッケージと、その更新先の版を一覧にする。
- この段階ではコードを変更しない。

② Rector による自動変換
- rector.php を用意し、vendor/bin/rector process --dry-run の差分を規則ごとに要約して見せる。
- 私が承認した規則だけを適用する。規則ごとにコミットを分け、コミットメッセージに規則名を入れる。

③ 参照資料の一覧との突き合わせ
- 一覧の項目を上から順に 1 つずつ取り上げ、該当しそうな関数名・定数名・INI 名・構文をリポジトリ全体から grep で探す（vendor/ は除く）。
- 結果を docs/php-upgrade/checklist.md に表で残す。列は「項目 id・区分・内容・該当箇所（ファイル:行）・対応（該当なし／修正済み／要判断）」。全項目を 1 行ずつ埋め、飛ばさない。
- エラーにならず結果だけが変わる挙動変更（== の比較、文字コードの既定値、round() や range() の結果など）は、直す前に「要判断」として私に見せる。

④ Deprecated と警告の全件収集
- php-upgrade:8.4.27 のコンテナで error_reporting=E_ALL、display_errors=stderr、log_errors=On にしてテストと主要な画面・バッチを動かし、E_DEPRECATED・E_WARNING・E_NOTICE を全件ログに出す。
- 1 件ずつ原因を直し、最後にログが 0 件になったことをログの実物で示す。@ 演算子や error_reporting の変更で隠すことは禁止。

⑤ テスト
- 既存のテストと、移行前の出力を記録したスモークテストを移行先で実行し、移行前と結果が一致することを確かめる。一致しないものは差分をそのまま見せる。
- vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.4 と vendor/bin/phpstan analyse を実行し、残った指摘を一覧にする。

⑥ 変更報告
- 変更内容を表で報告する。列は「項目 id・ファイル・変更前・変更後・理由・テストで確認したか」。
- 自信のない変更、業務ロジックの意味が変わりうる変更、DB や文字コードに関わる変更は別の表に分け、「人の確認が必要」と明記する。

差分ができたら、作業した会話とは別のセッションでレビューさせます。同じ会話の中だと、自分が下した判断をそのまま追認しがちだからです。

これは PHP 8.0.30 から 8.4.27 への移行作業の差分です。git diff main...HEAD を読み、レビューしてください。参照資料: https://shinichi.noguchi.jp.net/feature/phpupgrade/8.0.html（保存版: docs/php-upgrade/reference.html）

次の観点で問題のある箇所を探し、「ファイル:行・問題・根拠になる参照資料の項目 id・修正案」の表で返してください。観点ごとに、問題がなければ「なし」と書いてください。

1. 変更の前後で結果が変わる箇所: == と === の置き換え、文字列と数値の比較、round()・range()・文字列関数の戻り値、PDO で取得した値の型
2. 内部関数に null が渡る箇所を、(string) などのキャストや ?? '' で黙らせていないか。本来 null が来ないはずの値なら、null が来る原因の側を直すべき
3. 動的プロパティを #[\AllowDynamicProperties] で逃がしていないか。逃がした場合はその理由が書かれているか
4. @ 演算子、error_reporting の変更、空の catch で警告やエラーを隠していないか
5. 文字コード: htmlspecialchars() の既定値、mb_* の内部エンコーディング、DB 接続の charset が移行前と同じ結果になるか
6. テストが変更箇所を実際に通っているか。期待値を書き換えて通しただけのテストがあれば指摘する

コードは変更せず、レビュー結果だけを返してください。

非対話で動かす場合は claude -p を使います。段階を区切って 1 段階ずつ実行し、出力を人が読んでから次を流します。--allowedTools に挙げたツールは確認なしで使われるので、最初は読み取りと書き出しだけに絞っておくと安全です。

# ③の突き合わせだけを、コードを変更させずに実行する
claude -p "docs/php-upgrade/reference.html の変更一覧（8.0 系から 8.4 まで）を上から 1 項目ずつ取り上げ、リポジトリ（vendor/ を除く）を grep して該当箇所を探し、docs/php-upgrade/checklist.md に「項目 id・区分・内容・該当箇所・対応」の表で書いてください。コードは変更しないでください。" \
  --allowedTools "Read,Grep,Glob,Write"

# 差分のレビュー（レビュー用プロンプトを docs/php-upgrade/review-prompt.md に保存しておく）
git diff main...HEAD | claude -p "$(cat docs/php-upgrade/review-prompt.md)" > docs/php-upgrade/review.md

レビュー役は、サブエージェントとして定義しておくと何度でも同じ観点で呼び出せます。.claude/agents/ に置いたファイルはチームで共有できます。

---
name: php-upgrade-reviewer
description: PHP 8.0.30 から 8.4.27 への移行差分をレビューする。移行作業のコミット後や PR 作成前に使う。
tools: Read, Grep, Glob, Bash
---

あなたは PHP の版移行のレビュー担当です。git diff main...HEAD を読み、docs/php-upgrade/reference.html の変更一覧（8.0 系から 8.4 まで）と照らして、次を確認してください。

1. 変更の前後で結果が変わる箇所（== と ===、文字列と数値の比較、round()・range()、PDO の取得値の型）
2. null を内部関数に渡す箇所をキャストで黙らせていないか
3. 動的プロパティを #[\AllowDynamicProperties] で逃がしていないか
4. @ 演算子・error_reporting の変更・空の catch で警告を隠していないか
5. 文字コードの既定値の変化が結果に出ていないか
6. 期待値を書き換えただけのテストがないか

結果は「ファイル:行・問題・根拠の項目 id・修正案」の表で返し、コードは変更しないこと。

hooks を使うと、Claude Code がファイルを編集するたびに PHPStan を走らせ、指摘をその場で Claude に返せます。PostToolUse の hook が終了コード 2 で終わると、標準エラーの内容が Claude に渡されます（編集そのものは取り消されません）。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/phpstan-changed.sh"
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# 編集されたファイルのパスを標準入力の JSON から取り出す（jq が必要）
file=$(jq -r '.tool_input.file_path // empty')
case "$file" in
  *.php) ;;
  *) exit 0 ;;
esac
project="$(cd "$(dirname "$0")/../.." && pwd)"
rel="${file#"$project"/}"
out=$(docker run --rm -v "$project":/app php-upgrade:8.4.27 \
  vendor/bin/phpstan analyse --no-progress --error-format=raw "$rel" 2>&1)
if [ $? -ne 0 ]; then
  echo "$out" >&2
  exit 2
fi
exit 0

Codex に頼む

Codex は AGENTS.md を読みます。リポジトリのルートから作業ディレクトリまでの各階層の AGENTS.md が順に結合され、作業場所に近いものが優先されます。内容は CLAUDE.md の移行ルールと同じで構いません。

# AGENTS.md

## このリポジトリで進めている作業
PHP を 8.0.30（8.0 系）から 8.4.27 へ移行している。
参照資料: https://shinichi.noguchi.jp.net/feature/phpupgrade/8.0.html（保存版: docs/php-upgrade/reference.html）。8.0 系から 8.4 までに入った削除・非推奨・挙動変更の一覧で、各項目に id（例: v80-05）がある。

## 実行環境
- 解析とテストは Docker の php-upgrade:8.4.27 イメージで行う（docker/php-upgrade/Dockerfile）。ホストの php は使わない。
- 静的解析: vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.4 --ignore=*/vendor/* .
- 静的解析: vendor/bin/phpstan analyse
- 自動変換: vendor/bin/rector process --dry-run で差分を確認してから適用する

## 守ること
- 変更の根拠は参照資料の項目 id で示す。
- 1 コミットに 1 種類の変更。Rector の自動変換と手作業の修正を混ぜない。
- @ 演算子、error_reporting の変更、空の catch で警告を隠さない。
- テストの期待値を変えたときは理由を報告する。
- vendor/ 配下は編集しない。
- composer.json の require、DB のスキーマや文字コード、php.ini などの本番設定に関わる変更は行わず、提案として報告に書く。

codex exec は非対話で動き、既定では読み取り専用のサンドボックスで実行されます。ファイルを書き換えさせるときは --sandbox workspace-write を付けます。上の一括依頼プロンプトを docs/php-upgrade/prompt.md に保存し、段階を指定して流します。

# ①インベントリだけ（読み取り専用のまま。最後の報告を -o でファイルに残す）
codex exec -o docs/php-upgrade/01-inventory-report.md \
  "docs/php-upgrade/prompt.md を読み、①インベントリだけを実行して結果を報告してください。①以外の段階には進まないでください。"

# ③突き合わせ（checklist.md を書かせるので workspace-write）
codex exec --sandbox workspace-write -o docs/php-upgrade/03-checklist-report.md \
  "docs/php-upgrade/prompt.md を読み、③参照資料の一覧との突き合わせだけを実行してください。コードは変更せず、docs/php-upgrade/checklist.md だけを書いてください。"

# プロンプト全体を標準入力から渡すこともできる
cat docs/php-upgrade/prompt.md | codex exec --sandbox workspace-write -

MCP サーバーとプラグイン

必須ではありませんが、次のものは移行作業で役に立ちます。どれも公式のリポジトリかドキュメントで存在と導入方法を確認できたものだけを載せています。Claude Code 向けには、Anthropic の公式プラグインマーケットプレイス（claude-plugins-official）に PHP 向けのプラグインもあります。

Context7・GitHub・Playwright・Serena・Laravel Boost は、同じ公式マーケットプレイスの外部プラグイン（external_plugins）としても登録されています。外部プラグインの中身は Anthropic が検証したものではない、と README に書かれているので、入れる前に各プロジェクトのページを確認してください。

検収で人が見るところ

エージェントの報告が「テストはすべて通過」でも、次の項目は人が差分と実際の出力を見て確かめます。どれもエラーを出さずに結果だけが変わる種類のものです。

• == による比較。PHP 8.0 で数値と数値でない文字列の比較規則が変わり、0 == "a" が true から false になった。switch や in_array() の判定も同じ影響を受ける。
• 文字コードの既定値。htmlspecialchars() などの既定の文字コードやフラグの変化、mb_* の内部エンコーディング、DB 接続の charset。
• round() と range() の結果。金額や件数の端数処理、ページ送りの範囲を、移行前の出力と突き合わせる。
• PDO で取得した値の型。文字列で返っていた数値が int や float で返るようになると、=== の比較や JSON の出力が変わる。
• 内部関数に null を渡している箇所。キャストで警告を消しただけになっていないか。
• 動的プロパティ。#[\AllowDynamicProperties] で逃がした箇所が、本当にそのままでよいか。
• E_DEPRECATED がゼロであること。エージェントの報告ではなく、移行先のコンテナで error_reporting=E_ALL にして取ったログの実物で確認する。

公式の移行ガイド

8.0 系から 8.5 までに経由する各版の、php.net の移行ガイドと php-src の UPGRADING です。このページの一覧は、これらを項目ごとに整理したものです。

• PHP 8.1：移行ガイド（日本語） ／ 後方互換性のない変更 ／ 非推奨 ／ その他の変更 ／ ChangeLog 8.1.0 ／ UPGRADING
• PHP 8.2：移行ガイド（日本語） ／ 後方互換性のない変更 ／ 非推奨 ／ その他の変更 ／ ChangeLog 8.2.0 ／ UPGRADING
• PHP 8.3：移行ガイド（日本語） ／ 後方互換性のない変更 ／ 非推奨 ／ その他の変更 ／ ChangeLog 8.3.0 ／ UPGRADING
• PHP 8.4：移行ガイド（日本語） ／ 後方互換性のない変更 ／ 非推奨 ／ 削除された拡張モジュール ／ その他の変更 ／ ChangeLog 8.4.0 ／ UPGRADING
• PHP 8.5：移行ガイド（日本語） ／ 後方互換性のない変更 ／ 非推奨 ／ その他の変更 ／ ChangeLog 8.5.0 ／ UPGRADING
• 起点 8.0.30 の ChangeLog：https://www.php.net/ChangeLog-8.php#8.0.30
• 移行先の ChangeLog：8.4.27 ／ 8.5.12 ／ 8.3.36 ／ 8.2.35
• 2026-10-21 のセキュリティ勧告：php.net News Archive 2026 ／ 8.0 向けソースバックポート：PHP-8.0-CVE-2026-109618-109619

※2026年10月時点の公開情報に基づきます。バックポートのブランチの中身（版番号、コミット）は 2026-10-23 に php-src のリポジトリで確認しました。

PHP アップグレード特集のトップへ戻る