Laravelのセキュリティ更新は「納品後に誰がやるか」から決める──公式のサポート期間、更新の2つの種類、契約で決める担当と費用

この記事は、Laravelのセキュリティ更新を中心に、フレームワークで作ったシステムを納品後に誰が、どの頻度で更新するかを扱います。

「Laravelで作ったシステム、今どの版ですか」

納品から2年たった顧客から、こう聞かれたとします。
担当したエンジニアはもう退職していて、リポジトリを開くまで、誰も答えられません。

フレームワークで作ったシステムは、作った瞬間から、サポート期間の残りが減っていきます。
納品の時点で更新の担当を決めていなければ、その期間は誰にも見られないまま過ぎていきます。

フレームワークのセキュリティ更新とは、開発元が修正を出してくれる期間のうちに、同じ大きな版の中の修正を当て続け、期間が切れる前に次の版へ移ることである

黒字化の外科医です。フレームワークの更新を、納品後の運用として解剖します。

なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。

運用として決めるべき理由は、三つあります。

第一に、フレームワークには、はっきりしたサポート期間があるから。
Laravelの公式のリリースノートでは、各版のバグ修正は18か月、セキュリティ修正は2年間と書かれています。

第二に、更新には、性質の違う2つの種類があるから。
同じ大きな版の中の小さな更新と、大きな版をまたぐ更新です。かかる工数も、顧客への説明も違います。

第三に、納品後の更新は、契約に書かなければ誰の仕事でもないから。
制作の契約が納品で終わるなら、更新は保守の契約で引き受けるか、顧客の社内に任せるかを、書面で決める必要があります。

Laravelのサポート期間：公式で確かめた日付

Laravelの公式のリリースノート（13.x）の表を、2026年10月に確かめました。

版　 対応PHP　 公開日　　　　　　 バグ修正の終了　　　セキュリティ修正の終了
10　 8.1-8.3　 2023年2月14日　　　2024年8月6日　　　 2025年2月4日
11　 8.2-8.4　 2024年3月12日　　　2025年9月3日　　　 2026年3月12日
12　 8.2-8.5　 2025年2月24日　　　2026年8月13日　　　2027年2月24日
13　 8.3-8.5　 2026年3月17日　　　2027年第3四半期　　2028年3月17日
（Laravel公式 Release Notes、2026年10月に確認）

2026年10月の時点で、Laravel 11 以前はセキュリティ修正の期間を過ぎています。
Laravel 12 は、セキュリティ修正だけの期間に入っており、2027年2月24日に終わります。

日付は変わることがあるため、顧客に伝える前に、必ず公式の表示を確かめてください。

更新の2つの種類

同じ大きな版の中の更新

公式のリリースノートでは、大きな版は毎年（おおむね第1四半期）、小さな版と修正の版は毎週出ることもある、とされています。そして、小さな版と修正の版には、互換性を壊す変更を入れない方針が示されています。

この種類は、月次の定期作業にまとめられます。ライブラリ全体の照合と合わせて行います。

▶ Composerの脆弱性管理、納品時のvendorのまま止めない──composer auditの位置づけ、lockファイル、更新の方針

大きな版をまたぐ更新

大きな版には、互換性を壊す変更が含まれます。公式は、そのため ^13.0 のような版の指定を使うよう案内しています。
こちらは、2年に一度ほどの「案件」として見積もります。

今すぐ試せる：納品済みシステムの更新担当を洗い出すプロンプト

私はWeb制作会社の経営者です。納品済みのフレームワークのシステムについて、更新の担当を整理してください。

【前提】
・システムごとの、フレームワークと版（例：Laravel 12）：〔記載〕
・公式で確認した、その版のセキュリティ修正の終了日：〔記載〕
・保守契約の有無と、契約に書かれた作業の範囲：〔記載〕
・顧客の社内に、開発の担当者がいるか：〔記載〕

1. システムを「自社が更新する」「顧客が更新する」「決まっていない」に分ける。
2. 「決まっていない」システムについて、顧客に送る確認の文を作る。
3. セキュリティ修正の終了が1年以内に来るものを、優先して一覧にする。
4. 大きな版をまたぐ更新を、いつ提案するかの目安を示す。

日付は推測で補わないこと。不明な項目は「不明」と書くこと。

更新担当工場：契約で決める3つの形と費用

担当の3つの形

〔形A〕保守契約で自社が更新する
　範囲：同じ大きな版の中の更新を、月1回の定期作業で行う
　大きな版をまたぐ更新：都度お見積り

〔形B〕顧客の社内で更新する
　自社の範囲：サポート終了の予定の案内（年1回）と、相談の受付（有償）

〔形C〕更新しないことを、顧客が選ぶ
　記録すること：案内した日、伝えた終了日、顧客の返答

形Cは、断られたことを記録に残すための形です。案内した事実がないまま事故が起きると、説明が難しくなります。

計算例：月次の更新と、2年に一度の移行

例：時間単価 8,000円

月次の更新（検証を含む）：月2時間
　2時間 × 8,000円 ＝ 月16,000円

大きな版をまたぐ更新：40時間と見積もった場合
　40時間 × 8,000円 ＝ 320,000円
　320,000円 ÷ 24か月 ≒ 月13,333円（積み立てた場合）

移行の費用を月額に含めるか、都度見積もりにするかは、契約で決めます。含めないなら、その旨を書いておきます。

構造的なリスク

逆説を指摘しておきます。

更新を保守で引き受けると、「更新したら動かなくなった」の責任も引き受けることになります。
だから、検証の範囲と、戻す手順と、顧客が確認する画面を、先に決めてから引き受けます。

▶ パッチ適用の手順を「本番でそのまま更新」で済ませない──検証環境、バックアップ、戻し方、顧客への告知までの本番反映フロー

よくあるQ&A

Q. 顧客の社内のエンジニアが更新するなら、自社は何もしなくてよいか？

契約の範囲が「案内まで」なら、年に一度、サポート終了の予定を知らせるだけで構いません。その案内を記録に残すことが、自社を守ります。

Q. サポート期間が切れた版のまま動いているシステムがある。

まず顧客に事実を伝え、移行の見積もりを出します。説明の型は、PHPのサポート終了の説明の記事が応用できます。

Q. Laravel以外のフレームワークも同じ考え方でいいか？

考え方は同じです。サポート期間は製品ごとに違うため、必ずそれぞれの公式の発表で確かめてください。

最後に

フレームワークのサポート期間は、納品した日から減り続けています。

納品の時点で更新の担当と費用を契約に書いた会社だけが、2年後の「今どの版ですか」に、即答できるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #Laravel #セキュリティ更新 #フレームワーク #サポート期間 #保守契約 #制作会社経営 #中小企業 #システム開発 #脆弱性対策