結論から書くと、Laravel の「セキュリティ更新だけ」の外注は、Laravel は同じメジャー（12.x の中など）、PHP は同じマイナー（8.3.x の中など）の中の更新と、既知の脆弱性（ソフトウェアの弱点）への対応だけを扱い、機能の追加・一般の不具合の修正・それより大きなバージョンの更新は扱わない と範囲を決めれば、依頼として成り立ちます。ただし受けてもらいやすくするには、(1) 環境を再現できる、(2) テストか確認手順がある、(3) 公式のセキュリティ修正の期間内のバージョンである の3つをそろえます。欠けている条件があれば、それを補う作業が先に入ります。
この記事では、保守の依頼全般が断られる理由（「「保守だけお願いしたい」が断られる理由と、受けてもらえる依頼の出し方」）、月額保守の範囲の決め方全般（「Laravel の月額保守で「含まれること・含まれないこと」を決める」）、システムが使う部品（パッケージ）を上げる具体的な手順は扱いません。
「セキュリティ更新だけ」に含むもの・含まないもの
Laravel はセマンティックバージョニング（「メジャー.マイナー.パッチ」の3つの数字で互換性を表す決まり）に従っています。公式の説明では、メジャーは毎年、マイナーとパッチは最短で毎週出ることがあり、マイナーとパッチには互換性を壊す変更を含めない方針です。そのため Laravel では「同じメジャーの中」が範囲の区切りになります。
composer audit は、Composer（PHP の部品＝パッケージを管理する道具）で入れたパッケージに、既知の脆弱性の情報が出ていないかを、既定では Packagist.org（Composer の主なパッケージの配布元）の情報で確かめるコマンドです。保守が止まったパッケージも検出し、現在の既定の設定ではどちらかが見つかると「問題あり」という結果を返すので、自動の確認にも組み込めます。保守が止まったパッケージでそうなるのは Composer 2.7 からなので、作業前に composer --version で版も確かめます。
| 作業 | 扱い |
|---|---|
| Laravel 本体の、同じメジャーの中の更新 | 含む |
composer audit で見つかった、脆弱性のあるパッケージの更新 |
含む（同じメジャーの中で直る場合） |
| PHP のパッチ更新（8.3.x の中など） | 含む（誰が PHP を更新できるかによる） |
| 修正版が次のメジャーにしか無いもの、保守が止まったパッケージ | 報告して別見積 |
PHP は 8.2 から 8.3 のような更新でも、公式の移行ガイドに互換性の無い変更が挙げられているため、別の作業として扱います。
表の最後の行が依頼の境界です。どちらも移行の作業になるので、見つかったら報告して別見積にすると、依頼の時点で決めておきます。機能の追加、メジャー更新、網羅的な診断を含めない点は、月額保守の分け方と同じです（冒頭で挙げた月額保守の記事を参照）。
受けてもらえる3つの条件
1. 環境を再現できる
依頼先が同じ環境を作れなければ、更新して壊れないかを確かめられません。渡すものは次の4つです。
- ソースコード一式: 本番で動いているものと同じもの
- composer.lock: 入っているパッケージの正確なバージョンの記録です。このファイルがあれば、
composer installでそこに書かれたバージョンが入ります - データベースの構造: テーブルの定義。データそのものの扱いは、必要になったときに相談します
- .env の項目名: .env は環境ごとの設定ファイルで、公式にソース管理に含めないよう書かれています。パスワードなどの値は渡さず、項目名だけにします
composer.lock が無い、または本番と一致しないなら、動いているバージョンを本番で確かめる作業が先に入ります。
2. テストか確認手順がある
互換性を壊さない方針の更新でも、個々のシステムで何も起きないとは言い切れません。自動のテストが無ければ、ログインや登録など、止まると困る操作を並べた確認手順で代わりにします。どちらも無いときは、最初に確認手順を作る作業と費用が加わります。
3. セキュリティ修正の期間内のバージョンである
Laravel 公式のサポート方針では、各メジャーの不具合修正は18か月、セキュリティ修正は2年です。2026年11月時点でセキュリティ修正が続いているのは Laravel 12（2027年2月24日まで。不具合修正はすでに終了）と 13（2028年3月17日まで）だけで、11 以前は終了しています。
期限が切れたメジャーは公式のセキュリティ修正の対象外になり、脆弱性が見つかっても修正版が出る保証がありません。そのため、先にバージョンアップが必要です。Packagist.org の laravel/framework の脆弱性の一覧にも、12・13 には修正版がある一方、9〜11 はすべての版が影響を受けるとされた項目があります。
Laravel 12 も期限まで4か月を切っています。セキュリティ更新と一緒に 13 への更新の計画も相談しておきます。PHP も同じで、PHP 公式のサポート表では 8.2 のセキュリティサポートは2026年12月31日までです。
条件を満たさないときの進み方
条件が欠けていても、すぐに断られるとは限りません。依頼先によって違いますが、次のような進め方があります。
| 欠けている条件 | 進み方 |
|---|---|
| 環境を再現できない | 先に調査を依頼する |
| 確認手順が無い | 確認手順を作る作業を最初に入れる条件付きで受ける |
| サポートが切れたバージョン | バージョンアップの見積に切り替わるか、断られる |
調査から段階的に頼む進め方は、冒頭で挙げた「保守だけお願いしたい」の記事で説明しています。
頼み方——渡す情報、周期、緊急時、報告
依頼のときに伝えること
「1. 環境を再現できる」で挙げた4つに加えて、次を伝えます。
- 本番の PHP のバージョンと、PHP を更新するのは誰か: レンタルサーバーでは、パッチ更新をサーバー側が行うのか利用者が切り替えるのかが、契約によって違います。契約しているサーバーのマニュアルで確認します
- 止まると困る機能: 更新の後に優先して確かめる箇所になります
作業の周期
更新は頻繁に出るので、毎回は追わず、定期 と 緊急時 の2本立てにします。定期は「月に1回 composer audit を実行し、同じメジャーの中で上げられるものをまとめて上げる」のように決めます。
緊急の脆弱性が出たとき
緊急の更新は周期を待ってくれません。2026年10月には、PHP の公式サイトで前日に予告があったうえで、認証なしに遠隔からコードを実行されるおそれのある重大な脆弱性2件を修正した版が公開され、すべての利用者にすぐ更新するよう強く勧められました。こうしたときの扱いを先に決めておきます。
- 誰が情報に気づき、誰に連絡するか
- 連絡から着手までの目安（約束できる速さは依頼先で違います）
- 定期の費用に含めるか、都度の費用にするか
- 緊急時の本番への反映を、誰が承認するか
情報の出どころは、Laravel と依存パッケージなら composer audit と Packagist.org の一覧、PHP なら公式サイトのニュースです。
報告の形
報告は、次の項目が毎回そろっていれば足ります。
【セキュリティ更新の報告（例）】
・実施日、作業した環境
・composer audit の結果（作業前・作業後）
・更新したもの：パッケージ名 旧バージョン → 新バージョン
・対応しなかった脆弱性と理由（例：修正版が次のメジャーにしか無い）
・実施した確認の項目と結果
・次に期限を迎えるものh-system でできること
h-system では、他社や前任者が作った PHP・Laravel のシステムについて、保守・改修の一環として、既知の脆弱性への対応や、古いバージョンのまま残っている PHP・ライブラリの更新を、開発者本人がお引き受けしています。確認の結果は懸念点と優先順位として整理してお伝えし、合意した項目から対応します。網羅的な脆弱性診断や侵入テスト、安全性の保証は行っていません。一人で対応しているため即日の対応はお約束していませんが、保守契約をいただいている方を優先して対応します。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。