CentOS EoL 対応_AlmaLinux 移行・PHP アップグレード・AI によるソースコード変換（Rust 化を含む）の実現可能性と注意点
1. エグゼクティブサマリー
CentOS は 7 系・8 系ともにサポートを終了しており、OS だけでなく同梱・追加導入された PHP（5.x / 7.x 系）も既にセキュリティ修正が提供されない状態にあるケースが大半です。本資料では、①OS の AlmaLinux への置き換え、②PHP のサポート版へのアップグレード、③AI を用いたソースコード変換（同一言語内のモダナイズ、および Rust など他言語への変換）について、実現可能性と注意点を整理します。
| テーマ | 実現可能性 | 要点 |
| ① OS：CentOS → AlmaLinux | 高い | RHEL 互換で移行実績が豊富。新規構築＋アプリ移設を推奨。In-place（ELevate）も選択肢。 |
| ② PHP：5.x/7.x → 8.3/8.4 | 高い | Rector 等の決定論的ツール＋AI＋テストで現実的に実施可能。互換性破壊の洗い出しが鍵。 |
| ③-a AI による PHP モダナイズ | 高い | 同一言語内の変換は AI が得意な領域。大規模事例でも工数削減効果が報告されている。 |
| ③-b AI による PHP → Rust 変換 | 条件付きで可能 | 稼働事例あり。ただし「テストで同等性を証明できる範囲」に限定し、段階的に進めることが前提。 |
推奨方針（結論）
Step 1： まず「OS 移行＋PHP 8.x へのアップグレード」でサポート切れリスクを早期に解消する（守りの施策）。
Step 2： その上で、性能・保守性・セキュリティ上の効果が大きい機能から、AI を用いて Rust へ段階的に置き換える（攻めの施策）。
理由： 一度に「OS・言語・コード」すべてを変えると、障害発生時に原因の切り分けが困難になり、移行期間中も脆弱な旧環境が残り続けるため。
2. 背景と現状のリスク
2.1 CentOS のサポート終了
CentOS Linux 8 は 2021年12月31日に、CentOS Linux 7 は 2024年6月30日にそれぞれサポートを終了しました。以降、OS パッケージ（カーネル、OpenSSL、glibc、httpd 等）へのセキュリティ修正は提供されていません。CentOS Stream は RHEL の開発ブランチという位置づけで、長期安定運用を前提とした置き換え先とは性質が異なります。
2.2 PHP のサポート状況
PHP は 2024年3月にリリースサイクルが変更され、各ブランチは「2年間のバグ修正＋2年間のセキュリティ修正」の計4年間サポートされます。2026年10月時点の状況は以下のとおりです。
| バージョン | リリース | アクティブサポート終了 | セキュリティサポート終了 | 状態（2026/10） |
| PHP 5.x / 7.x | — | — | 7.4：2022/11/28 | EoL（危険） |
| PHP 8.0 | 2020/11 | — | 2023/11/26 | EoL（危険） |
| PHP 8.1 | 2021/11 | — | 2025/12/31 | EoL（危険） |
| PHP 8.2 | 2022/12 | 終了 | 2026/12/31 | 残り約2か月 |
| PHP 8.3 | 2023/11 | 2025/12/31 | 2027/12/31 | セキュリティ修正のみ |
| PHP 8.4 | 2024/11 | 2026/12/31 | 2028/12/31 | サポート中 |
| PHP 8.5 | 2025/11 | 2027/12/31 | 2029/12/31 | サポート中（最新） |
出典：php.net / endoflife.date（2026年時点）。ディストリビューション（AlmaLinux 等）が提供する PHP は、上流 EoL 後もディストリビューション側でバックポート修正が続く場合があります（2.3 参照）。
2.3 「OS 同梱 PHP」と「上流 PHP」のサポート期間の違い
RHEL 系の AppStream で提供される PHP は、上流（php.net）の EoL とは別に、ディストリビューション側の「アプリケーションストリームのライフサイクル」に従ってセキュリティ修正が提供されます。一方で、AppStream のモジュールストリームは OS 本体（10年）より短いサイクルで提供終了となるため、「OS が 2032年までサポートされる＝PHP も 2032年まで使える」ではない点に注意が必要です。Remi リポジトリ等で上流の最新版を入れる場合は、上流の EoL に従います。
2.4 放置した場合のリスク
● 公開済み脆弱性（OS・PHP・ミドルウェア）が修正されず、既知の攻撃手法で侵害されるリスクが継続的に増大する。
● PCI DSS、ISMS、各種ガイドライン（IPA 等）・取引先のセキュリティ監査で「サポート切れソフトウェアの使用」が指摘事項となる。
● Composer パッケージやフレームワークが旧 PHP のサポートを打ち切り、ライブラリ側の脆弱性修正も適用できなくなる。
● 旧 OS 上では新しい TLS 設定・証明書・暗号ライブラリに追随できず、外部 API 連携が突然停止する。
3. 移行先 OS：AlmaLinux
3.1 AlmaLinux の概要
AlmaLinux は非営利の AlmaLinux OS Foundation が所有・運営する、RHEL とバイナリ互換を目指したエンタープライズ Linux です。RHEL と同様に各メジャーバージョンが約10年のライフサイクルを持ち、RHEL の更新から概ね1営業日以内に追随することを目標としています。商用サポートはサードパーティ各社から提供されています。
3.2 バージョン別の比較
| 項目 | AlmaLinux 8 | AlmaLinux 9 | AlmaLinux 10 |
| サポート終了 | 2029年5月末 | 2032年5月末 | 2035年5月末 |
| 標準 PHP（AppStream） |
7.2（既定） モジュールで 7.4 / 8.0 / 8.2 等 |
8.0（既定） モジュールで 8.1 / 8.2 / 8.3 |
8.3 （モジュール機能は廃止） |
| Remi による新版 | 可 | 可 | 8.4 / 8.5 可 |
| CentOS 7 からの In-place | 可（ELevate：7→8） | 可（7→8→9 の2段階） | 不可（直接は想定外） |
| 推奨度（新規構築時） | 低（残り期間が短い） | 中〜高 | 高（最長サポート） |
注：AlmaLinux 10 は RHEL 10 と異なり x86-64-v2 世代の CPU もサポートしています。古いハードウェア・仮想基盤上での利用可否は事前に確認してください。
3.3 移行方式の比較
| 方式 | 概要 | メリット | デメリット・注意点 |
| A. 新規構築＋アプリ移設 （推奨） |
AlmaLinux 9/10 を新規に構築し、アプリ・データを移す | クリーンな環境。旧来の不要設定・不要パッケージを持ち込まない。切り戻しが容易（旧環境を残せる） | サーバ台数分の構築工数。設定の棚卸しが必要 |
| B. In-place 変換 （ELevate / Leapp） |
既存 CentOS 7 を AlmaLinux 8 → 9 へその場でアップグレード | IP・構成を維持しやすい。物理サーバで有効 | 2段階アップグレードが必要。サードパーティ RPM・カスタム設定で失敗しやすい。失敗時はバックアップから復旧 |
| C. コンテナ化 | アプリを AlmaLinux ベースのコンテナに移す | 環境の再現性が高く、以後の OS 更新が容易 | 運用体制（イメージ更新・監視）の整備が必要 |
3.4 ELevate（In-place 変換）の手順概要
ELevate は Red Hat の Leapp フレームワークをベースに、AlmaLinux が他ディストリビューション間の移行用に拡張したツールです。代表的な流れは以下のとおりです。
1. 対象サーバのフルバックアップ／スナップショット取得（必須）
2. CentOS 7 を最新状態に更新し再起動（EoL 後はアーカイブリポジトリを参照）
3. elevate-release、leapp-upgrade、leapp-data-almalinux をインストール
4. leapp preupgrade を実行し、/var/log/leapp/leapp-report.txt の阻害要因（inhibitor）を解消
5. leapp upgrade → 再起動で AlmaLinux 8 へ。同様の手順を繰り返して AlmaLinux 9 へ
6. 残存する el7 パッケージの確認・削除、サービス動作確認
現場での注意点
ELevate による OS 変換が成功しても、PHP は OS 側の既定バージョンへ強制的に変わる（例：7.x → AlmaLinux 8 の 7.2 → 9 の 8.0）。アプリが動く保証はないため、PHP アップグレード作業（第4章）とセットで計画すること。
Remi / IUS / 独自ビルドの PHP、ionCube 等の暗号化ローダ、独自カーネルモジュールは阻害要因になりやすい。
3.5 AlmaLinux 9 / 10 で影響が出やすい OS 側の変更点
| 領域 | 変更内容 | 影響例 |
| 暗号ポリシー（crypto-policies） | DEFAULT ポリシーで SHA-1 署名、TLS 1.0/1.1 等が無効化 | 古い取引先システム・古い SSH 鍵・旧証明書との接続失敗 |
| OpenSSL 3.x | レガシーアルゴリズムは legacy プロバイダ扱い | PHP の openssl_* 関数で古い暗号方式（DES、RC4 等）が使えない |
| SELinux（Enforcing 既定） | httpd/php-fpm の外部接続・書き込み先が制限される | DB や外部 API への接続失敗、アップロード失敗。「とりあえず無効化」は厳禁 |
| ファイアウォール | firewalld が標準 | iptables 前提の運用手順の見直し |
| PHP 実行方式 | mod_php ではなく PHP-FPM が標準 | .htaccess の php_value 設定が効かない、実行ユーザーの変化 |
| ネットワーク設定 | NetworkManager（keyfile 形式）へ移行 | ifcfg ファイル前提のスクリプトの修正 |
4. PHP アップグレード
4.1 ターゲットバージョンの選定
| 選択肢 | 想定ケース | 注意点 |
| AlmaLinux 10 標準 PHP 8.3 |
OS ベンダの修正提供に乗りたい。 運用をシンプルにしたい |
上流サポートは 2027年末まで。以降はディストリ側のバックポートに依存 |
| Remi の PHP 8.4 | 上流サポート期間を長く確保したい（2028年末まで） | サードパーティリポジトリの信頼性評価・更新運用が必要 |
| Remi の PHP 8.5 | 最新機能・最長サポート（2029年末まで）を優先 | 一部の拡張・商用ローダ・フレームワークの対応状況を要確認 |
推奨：新規構築なら AlmaLinux 10 ＋ PHP 8.4（Remi）または 8.3（標準）。フレームワーク・拡張の対応状況で決定する。PHP 8.2 は 2026年12月末で EoL のため新規採用は避ける。
4.2 主な互換性破壊（PHP 5.x / 7.x → 8.x）
| 移行元 | 代表的な破壊的変更 | 典型的な症状 |
| PHP 5.x → 7.0 | mysql_* 関数、ereg 系関数の削除。PHP 4 形式コンストラクタの非推奨 | 致命的エラーで画面が真っ白になる |
| 7.x → 8.0 | each()、create_function() の削除。文字列と数値の比較ルール変更（"abc" == 0 が false に）。多くの警告が例外（TypeError 等）に昇格 | 認証・分岐ロジックが静かに変わる（最も危険） |
| 8.0 → 8.1 | 内部関数への null 渡しが非推奨 | 大量の Deprecated ログ |
| 8.1 → 8.2 | 動的プロパティの非推奨 | 古いクラス設計でログが溢れる |
| 8.2 → 8.4/8.5 | 暗黙の nullable 型の非推奨など | 将来バージョンでのエラー化 |
セキュリティ観点で特に注意すべき点
比較演算子の挙動変更（PHP 8.0）は、認証・権限チェック・トークン比較のロジックを「エラーを出さずに」変える可能性がある。== を使った比較箇所は全件レビューし、=== と hash_equals() へ置き換えること。
mysql_* から mysqli/PDO へ機械的に置き換える際、文字列連結による SQL 組み立てをそのまま残すと SQL インジェクションが残存する。プリペアドステートメント化を同時に行うのが望ましい。
日本の業務システムでは Shift_JIS / EUC-JP のデータやソースが残っていることが多い。mbstring の既定設定変更（mbstring.func_overload の廃止等）で文字化け・データ破損が起きやすい。
4.3 ツールと進め方
| ツール | 用途 | 特徴 |
| Rector | 自動リファクタリング・アップグレード | AST ベースの決定論的変換。PHP 5.3 → 8.4 までのルールセットあり。バージョンを段階的に上げて適用するのが定石 |
| PHPCompatibility（PHP_CodeSniffer） | 非互換箇所の静的検出 | 対象バージョンを指定して、削除関数・構文の使用箇所を一覧化 |
| PHPStan / Psalm | 静的解析・型検査 | レベルを段階的に上げ、型の不整合や未定義変数を検出 |
| 生成 AI（Claude 等） | ルールで変換できない箇所の修正、テスト生成、Rector カスタムルールの作成 | 柔軟だが非決定的。必ず差分レビューとテストで検証 |
推奨される順序： ① 静的解析で非互換箇所を一覧化 → ② 特性テスト（現状の振る舞いを記録するテスト）を整備 → ③ Rector でバージョンを1段ずつ上げる → ④ Rector で処理できない箇所を AI で修正 → ⑤ テスト・差分レビュー → ⑥ ステージング環境で本番相当データによる検証。
「Rector の決定論的変換を主、AI を従」とすることで、AI 特有の揺らぎ（同じ入力でも出力が変わる、不要な変更を混ぜる）を最小化できます。
5. AI によるソースコード変換
5.1 2つのパターン
| パターン | 内容 | 難易度 | 実現可能性 |
| 同一言語内のモダナイズ | 旧 PHP → PHP 8.x、旧フレームワーク → 新フレームワーク | 中 | 高い |
| 異言語への変換 | PHP → Rust / Go / Java 等 | 高 | 条件付きで可能 |
5.2 大規模事例：Google のコード移行
Google は社内の大規模コード移行（32bit ID から 64bit ID への変更）に LLM を活用した事例を論文で公開しています。1年間のケーススタディで、提出された 595 件の変更（93,574 箇所の編集）のうち、約 74% の変更が LLM によって生成され、開発者は移行時間が約 50% 短縮されたと評価しました。
重要なのは、この仕組みが「AI に丸投げ」ではなく、変更箇所の機械的な特定 → LLM による修正 → 複数段階の自動検証 → 人間のレビューという構成になっている点です。検証に通らなかったファイルは人手での対応に回されています。また論文では、LLM の非決定性やハルシネーション（不要な変更の混入）が課題として挙げられています。
5.3 PHP → Rust 変換について
(1) 稼働事例
相談者が把握している範囲では、AlmaLinux への切り替え後に PHP の利用をやめ、AI を用いてソースコードを Rust に変換し、問題なく稼働している企業が存在します。これは、適切な進め方をとれば PHP → Rust の AI 変換が実運用レベルで成立し得ることを示す有力な事例です。お客様への提案時には、可能であれば当該事例の「対象システムの規模・種類」「テストの整備状況」「変換に要した期間と体制」を確認し、お客様の環境との比較材料にすることを推奨します。
(2) 学術研究から見える傾向
LLM による異言語変換の研究は C → Rust を中心に急速に進んでいます。2026年に発表された MinsC2Rust の評価では、コンパイル成功率 98.4% に対し、実行結果が正しかった割合は 42.6% でした。つまり、「コンパイルが通る」ことと「元のプログラムと同じ動作をする」ことの間には大きな差があるため、検証の仕組みが成否を分けます。
また、Java/PHP/C などから Python/Go/Rust への LLM 変換をセキュリティ観点で評価した研究では、変換の過程で脆弱性が混入しうることが報告されています。Veracode の 2025年の調査でも、AI 生成コードの約 45% のケースで OWASP Top 10 に分類される脆弱性が混入したと報告されています。
(3) PHP と Rust の違いから生じる変換上の落とし穴
| 領域 | PHP の性質 | Rust 変換時の注意点 |
| 型システム | 動的型付け・緩い型変換 | 暗黙の型変換（"10" + 5 等）の意図を明示的に再現する必要。仕様化されていない挙動の取りこぼし |
| 配列 | 順序付きハッシュマップ（リストと辞書を兼用） | Vec / HashMap / IndexMap の選択。キー順序の保持、数値文字列キーの自動変換 |
| 比較演算 | == の緩い比較 | 元コードが依存していた比較結果を正確に再現（認証系は特に重要） |
| 文字コード | バイト列として文字列を扱う。mb_* 関数 | Rust の String は UTF-8 必須。Shift_JIS/EUC-JP データは encoding_rs 等で明示的に変換 |
| 正規表現 | PCRE（後方参照・先読み可） | regex クレートは後方参照・先読みに非対応。fancy-regex 等の検討 |
| シリアライズ | serialize() / セッション形式 | DB・キャッシュに保存済みのデータとの互換性。移行期間中の PHP/Rust 共存 |
| パスワード | password_hash()（bcrypt 等） | 既存ハッシュを検証できる互換実装の採用。再ハッシュ方針 |
| テンプレート | HTML と PHP の混在 | Askama / Tera 等への分離。XSS 対策の自動エスケープ設定の確認 |
| 実行モデル | リクエストごとに状態が破棄 | 常駐プロセスでのグローバル状態・メモリ管理、非同期処理（tokio）の設計 |
| エコシステム | Composer パッケージ・フレームワーク | 同等のクレートの有無。メール送信、PDF、帳票、決済 SDK 等は代替の確認が必要 |
(4) Rust 化が向いているケース／向いていないケース
| 向いているケース | 慎重に判断すべきケース |
| 性能・リソース効率が課題（高負荷 API、バッチ処理） | お客様側に Rust を保守できる人材がいない／確保の見込みがない |
| メモリ安全性・型安全性による品質向上を重視 | 仕様書・テストがなく、現行の振る舞いが誰にも説明できない |
| 機能単位に分割しやすい API 中心の構成 | 画面（HTML）とロジックが密結合した大規模な画面系システム |
| テスト・ログ・本番トラフィックで同等性を検証できる | WordPress・EC-CUBE 等、既製 PHP パッケージをベースにしたシステム |
保守性の観点（お客様の長期的利益）
AI で変換したコードは「動く」だけでなく、お客様（または委託先）が将来も読んで修正できることが重要です。変換後のコードの所有者・保守担当・技術者育成の計画を、変換作業と同時に決めておくことを推奨します。
5.4 AI 変換を成功させるための進め方
1. 特性テスト（Characterization Test）を先に作る： 現行 PHP の入出力を記録し、「正解データ」とする。AI はテストケースの生成にも有効。
2. 機能単位で段階移行（Strangler Fig パターン）： リバースプロキシで一部の URL だけ Rust 側へ振り分け、少しずつ置き換える。
3. 差分テスト／シャドートラフィック： 本番リクエストを複製して PHP 版と Rust 版の双方に流し、応答の差分を自動比較する。
4. 決定論的な検証ゲート： cargo build / clippy / テスト / SAST / cargo audit をすべて通過したものだけを人間のレビューに回す。
5. 人間によるレビューを省略しない： 特に認証・認可・決済・個人情報を扱う箇所は、セキュリティエンジニアのレビューを必須とする。
6. 切り戻し手段を常に確保： 振り分け設定を戻すだけで PHP 版へ戻せる状態を維持する。
6. セキュリティ・ガバナンス上の注意点
6.1 ソースコードを AI に渡す際の注意
● 契約確認： お客様のソースコードを外部の AI サービスに入力することが、業務委託契約・NDA で許容されているかを事前に確認し、書面で合意を得る。
● サービス選定： 入力データが学習に利用されない法人向けプラン・API を利用し、データ保持期間・保存リージョンを確認する。
● 秘密情報の除去： DB パスワード、API キー、証明書、個人情報（テストデータ含む）がソースや設定ファイルに埋め込まれていないかをスキャン（gitleaks、trufflehog 等）し、除去・ローテーションしてから AI に渡す。
● ログ・証跡： どのコードをどの AI に、いつ、誰が入力したかを記録する。
6.2 生成コードの検証
| 観点 | 推奨する対策 |
| 静的解析（SAST） | PHP：PHPStan、Psalm（taint 解析）、Semgrep ／ Rust：clippy、Semgrep |
| 依存関係（SCA） | Composer：composer audit ／ Rust：cargo audit、cargo deny。SBOM（CycloneDX 等）を作成 |
| サプライチェーン | AI が提案した見慣れないパッケージ名（タイポスクワッティング・実在しないパッケージ）を必ず確認 |
| unsafe の管理 | Rust 版では unsafe ブロックを原則禁止（#![forbid(unsafe_code)]）。必要な場合は理由を明記しレビュー |
| 動的検査（DAST） | OWASP ZAP 等で移行前後の診断結果を比較。ペネトレーションテストの実施 |
| ロジック同等性 | 認証・認可・入力検証・出力エスケープ・CSRF 対策が移行後も欠落していないことを個別に確認 |
6.3 移行期間中のリスク
移行プロジェクトが長期化すると、その間ずっと EoL 環境がインターネットに露出し続けます。移行完了までの暫定策として、以下を検討してください。
● WAF の導入・ルール強化、管理画面へのアクセス元 IP 制限
● CentOS 7 向け延長サポート（商用 ELS）の一時的な利用
● 外部公開範囲の最小化、ログ監視・改ざん検知の強化
7. 推奨ロードマップ（例）
期間は中規模システム（数万〜十数万行程度）を想定した目安です。規模・テストの有無により大きく変動します。
| フェーズ | 主な作業 | 期間目安 | 成果物 |
| 0. 現状調査 | サーバ・ミドルウェア・PHP 拡張・外部連携・cron・文字コードの棚卸し。静的解析で非互換箇所を集計 | 2〜4週間 | 現状調査報告書、移行方式の決定 |
| 1. 暫定対策 | WAF・アクセス制限・監視強化。必要に応じて ELS 契約 | 並行 | 暫定リスク低減 |
| 2. テスト基盤整備 | 特性テスト・E2E テストの作成（AI 活用）、ステージング環境の構築 | 3〜6週間 | 回帰テスト一式 |
| 3. OS 環境構築 | AlmaLinux 9/10 構築、SELinux・crypto-policies・PHP-FPM 設定、構成管理（Ansible 等）化 | 2〜4週間 | 構築手順書、構成コード |
| 4. PHP アップグレード | Rector＋AI による段階的変換、テスト、性能確認 | 1〜3か月 | PHP 8.x 対応ソース |
| 5. 本番切替 | データ移行、切替リハーサル、切替、旧環境の一定期間保持 | 2〜4週間 | 切替完了報告 |
| 6.（任意）Rust 化 | 対象機能の選定、AI 変換、差分テスト、段階的振り分け | 機能単位で継続 | Rust 版機能、保守体制 |
8. リスクと対策一覧
| リスク | 影響 | 対策 |
| PHP 8 の比較演算変更による認証ロジックの変化 | 高 | == の全件レビュー、=== / hash_equals() への統一、認証系のテスト強化 |
| AI 変換コードへの脆弱性混入 | 高 | SAST・SCA・DAST、セキュリティレビューの必須化 |
| AI 変換で仕様の取りこぼし（静かな不具合） | 高 | 特性テスト、シャドートラフィックによる差分比較 |
| 文字コード（Shift_JIS 等）の扱いによるデータ破損 | 高 | 事前にデータ・ソースの文字コードを全数調査、変換テスト |
| ソースコード・機密情報の外部流出 | 高 | 契約確認、法人向け AI サービス、秘密情報の事前除去 |
| ELevate の In-place 変換失敗 | 中 | スナップショット取得、事前に複製環境でリハーサル |
| SELinux / 暗号ポリシーによる接続障害 | 中 | ステージングで外部連携を全件テスト。SELinux は無効化せずポリシーで対応 |
| Rust 化後の保守人材不足 | 中 | 保守体制・教育計画を事前に合意。段階移行で知見を蓄積 |
| 商用ローダ（ionCube 等）・独自拡張の非対応 | 中 | ベンダの対応状況確認、代替手段の検討 |
9. お客様へのヒアリング項目
| 区分 | 確認事項 |
| インフラ | サーバ台数・物理／仮想／クラウドの別、CentOS のバージョン、ハードウェア世代（CPU） |
| PHP 環境 | PHP バージョン、導入元（標準 / Remi / 独自ビルド）、使用中の拡張、ionCube 等の有無 |
| アプリケーション | フレームワークとバージョン、コード行数、Composer 利用有無、パッケージ製品（WordPress 等）か独自開発か |
| データ | DB 種別・バージョン、文字コード、serialize 形式データの有無、ファイル保存先 |
| 外部連携 | 外部 API・メール・決済・帳票・バッチ（cron）・ファイル連携の一覧 |
| 品質 | 仕様書・テストコードの有無、現行の不具合・性能課題 |
| 体制・契約 | 保守担当者のスキル（PHP / Rust）、AI 利用に関する社内規程・契約上の制約 |
| スケジュール・予算 | 期限（監査・契約更新等）、許容停止時間、予算規模 |
10. まとめ
CentOS からの移行は、OS 単体の問題ではなく、PHP・ミドルウェア・アプリケーションコードまで含めた「プラットフォーム全体の更新」として捉える必要があります。AlmaLinux への移行と PHP 8.x へのアップグレードは実績・ツールともに成熟しており、実現可能性は高いと評価できます。
AI によるソースコード変換は、同一言語内のモダナイズでは既に大きな効果が実証されており、PHP → Rust のような異言語変換も稼働事例が出てきています。成功の鍵は AI の性能そのものよりも、「同等性を機械的に証明するテスト」「段階的な移行と切り戻し手段」「セキュリティレビュー」という周辺の仕組みにあります。
お客様の状況（規模・テストの有無・保守体制）を第9章のヒアリング項目で把握した上で、まずは守りの施策（OS＋PHP 更新）でリスクを早期に解消し、その後に攻めの施策（Rust 化）を段階的に進めることを推奨します。
参考資料
1. PHP: Supported Versions（php.net）
2. endoflife.date - PHP
3. endoflife.date - AlmaLinux OS
4. CERN Linux - Which distribution should I use?（AlmaLinux 8/9/10 サポート終了日）
5. AlmaLinux Wiki - ELevating CentOS 7 to AlmaLinux 9
6. Linux Magazine - AlmaLinux's ELevate Migration Tool
7. ComputingForGeeks - Install PHP on AlmaLinux 10 / Rocky Linux 10 / RHEL 10
8. Rector（GitHub）
9. Migrating Code At Scale With LLMs At Google（論文要約）
10. MinsC2Rust: LLM-driven project-level code migration from C to safe Rust（Empirical Software Engineering, 2026）
11. When Code Crosses Borders: A Security-Centric Study of LLM-based Code Translation（arXiv）
12. Veracode 2025 GenAI Code Security Report（プレスリリース）
記載者：片山 昌樹（セキュリティ＆マネージド事業部 アイズオンフォレンジックチーム）