LASSIC Media らしくメディア
Apacheバージョンアップとは？影響調査と更新の進め方を解説
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Apacheのバージョンアップには、2.4系の中の更新と、2.2系から2.4系への移行の2種類があります。
- Linuxのパッケージで入れた場合は、版の番号が古くても配布元が修正を移して配っています。
- 上げる前に入れ方と使っているモジュールを棚卸しし、影響調査の結果を検証の項目につなげます。
※ 本記事は2026年11月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
Webサーバーの版が古いと脆弱性の診断で指摘されたが、上げると何が止まるのか分からない。OSの更新で入ったApacheの版の番号が、公式の最新版と合わない——。Webサーバーを長く動かしている会社では、こうした戸惑いが起こりがちです。Apache HTTP Server（略してhttpd）は、Webページや業務システムの画面をブラウザへ届けるオープンソースのWebサーバーです。
版を上げれば、修正済みの脆弱性への対策が入り、公式の保守の範囲にとどまれます。ただし万能ではなく、入れ方や上げ幅によっては、設定の書き直しや追加の部品の作り直しが要ります。本記事では、Apacheを保守している情報システムの担当者に向けて、版の考え方、公式とLinuxの版の違い、影響調査で見るところと進め方、そして外部に頼むときに確認したい点を整理します。
目次
Apacheのバージョンアップとは
Apacheの版は「2.4.69」のように、数字を点で区切って表します。公式サイトは2026年10月1日に2.4.69を公開し、2.4系を現在の安定版として案内しています。*1 どこからどこへ上げるかで、作業の重さは大きく変わります。
- 同じ2.4系の中の更新（例：2.4.58から2.4.69へ）：主に脆弱性や不具合の修正を取り込む更新で、定期的な保守に組み込めます
- 2.2系から2.4系への移行：設定の書き方が変わるため、設定ファイルの見直しが必要になります*4
- 2.2系の保守はすでに終わっています。最後の版は2017年7月の2.2.34で、以後は修正も脆弱性への対応も出ず、公式は2.4系へ上げるよう求めています*1
公式は、2.4系より前の版はもう脆弱性の修正を受けておらず、使うべきではないとしています。*2 2.2系以前が残っているなら、更新ではなく移行として計画を立てます。
公式の版とLinuxの版の違い
Apacheは、公式サイトから入手して自社で組み立てる（ビルドする）方法と、Red Hat Enterprise Linux（RHEL）・Debian・UbuntuといったLinuxの配布元（ディストリビューション）が用意したパッケージを入れる方法のどちらかで使われます。どちらで入れたかによって、版の番号の読み方と、修正の受け取り方が変わります。
| 入れ方 | 版の番号 | 修正の受け取り方 |
|---|---|---|
| 公式から入手してビルド | 公式の番号そのまま（例：2.4.69） | 修正の入った新しい版を入手し、組み立て直して入れ替える |
| Linuxのパッケージ | OSの版を出したときの番号のまま | 配布元が修正を古い番号の版に移して配り、それを当てる |
Red Hatは、新しい版の修正を自社が配る古い版へ移すことをバックポートと呼び、パッケージの版の番号を見るだけでは脆弱性があるかどうかは分からないと説明しています。番号だけで判断する診断ツールは、誤って脆弱と判定することもあるとしています。*5 Debianも、修正によって動きが変わったり壊れたりしないよう、安定版に入れた版のまま修正を取り込むと説明しています。*6
ただし、配布元の保守にも期限があります。たとえばUbuntuの長期サポート版（LTS）は、5年間の標準のセキュリティ保守を受けられます。*7 OSの保守が終われば、Apacheの修正も届かなくなるため、OSの保守期限もあわせて見ておきます。
影響調査で見るところ
版を上げる前に、何が変わり、それが自社の設定やシステムのどこに当たるかを調べます。これが影響調査です。公式は、2.4系の版ごとに直した脆弱性の一覧と、その重大度の評価を公開しています。たとえば2.4.69では20件の脆弱性（CVE：脆弱性ごとに振られる共通の番号）が直され、評価は5件が中程度、15件が低でした。この評価は環境によって変わりうる、と公式は断っています。*3
- 脆弱性の一覧：自社で使っている機能（モジュール）に当たるものがあるか。外部から接続される範囲か
- 変更点の一覧：版ごとに公開される変更履歴に、初期の設定値や動きの変更が無いか
- 設定の書き方：2.2系から上げる場合、アクセスの許可と拒否の書き方が新しくなり、.htaccess（フォルダごとの設定ファイル）も初期の設定では読まれなくなります*4
- 追加の部品：公式以外が作ったモジュールは、2.4系に合わせて作り直す（再コンパイルする）必要があります*4
- つながる仕組み：Apacheの後ろで動くTomcatやPHPなどのアプリケーション、通信を暗号化する証明書の設定
Apacheの後ろでTomcatを動かしている構成なら、その版も同じ時期に確かめておくと検証が一度で済みます。Tomcat側の考え方はTomcatバージョンアップの進め方で扱っています。
バージョンアップの進め方
Apacheのバージョンアップは、次の4つの段階で進めると、切り替えの当日に慌てずに済みます。
- ステップ1：いまの版と入れ方を棚卸しする（公式からのビルドかLinuxのパッケージか、使っているモジュール、変えた設定）
- ステップ2：影響を調べる（脆弱性の一覧と変更履歴を読み、自社の設定と照らし合わせる）
- ステップ3：検証用の環境で試す（業務の画面の表示、ログイン、ファイルのアップロードなど）
- ステップ4：本番を切り替える（元に戻す手順と、戻すかどうかを判断する人を決めてから）
つまずきやすいのはステップ1です。同じサーバーに、パッケージで入れたApacheと、以前の担当者が公式から組み立てたApacheが両方残っている場合があります。確かめずに更新すると、使っていない方だけを上げかねません。公式から入手する場合は、ファイルが改ざんされていないことを署名で確かめるよう、公式は求めています。*8
外部に頼むときに確認しておきたい点
Apacheの版上げは、入れ替えよりも、影響の調査と検証に手間がかかります。保守や移行を外部に頼むときは、見積もりの前に次の点を確かめておきます。
- どこまで頼むか：棚卸し、影響調査、検証、本番の切り替え、切り替え後の定期的な更新のうち、どれを任せるか
- 入れ方の方針：Linuxのパッケージに寄せるか、公式からのビルドを続けるか。続けるなら誰が組み立て直すか
- 脆弱性の知らせの受け取り方：公式のお知らせや配布元の勧告を誰が読み、いつまでに対応を決めるか
- 検証と切り戻し：どの業務の操作を誰が試すか。不具合が出たとき元に戻す手順と、判断する人
- 診断の結果の扱い：版の番号だけで脆弱と出たとき、バックポートの有無を誰が確かめるか
特に脆弱性の知らせの受け取り方は、決めないまま運用に入りやすい点です。公式は、新しい脆弱性の修正が出たことをお知らせのメーリングリストで受け取れると案内しています。*2 知らせが届いても読む人が決まっていなければ、更新は止まったままになります。
まとめ：Apacheのバージョンアップで確かめておきたい3つの点
Apacheのバージョンアップを進めるうえで、確かめておきたい点は3つに整理できます。第一に、いま動いているApacheの版と、公式からのビルドかLinuxのパッケージかという入れ方を棚卸しすること。第二に、脆弱性の一覧と変更履歴を読み、自社の設定とつながるシステムへの影響を調べること。第三に、検証の範囲と切り戻しの手順、切り替え後の更新の担当を、作業の前に決めておくことです。この3点を踏まえておけば、「版を上げたら業務の画面が開かなくなった」という事態を避けやすくなります。影響調査や検証の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
LinuxのパッケージのApacheも公式の最新版に上げるべきですか
必ずしも公式の番号に合わせる必要はありません。配布元は修正を古い版の番号のまま取り込んで配るため、配布元の更新を当て続けていれば、番号が古くても修正が入っていることがあります。*5 ただし、OSの保守期間が終われば修正は届かなくなるので、OSごとの移行を計画しておきます。
2.2系のまま使い続けても大丈夫ですか
勧められません。公式は2.2系の保守を終えており、今後は修正も脆弱性への対応も出ないとしています。*1 外部から接続できる範囲を確かめたうえで、2.4系への移行を早めに計画してください。
バージョンアップにかかる期間はどう見積もればよいですか
同じ2.4系の中の更新か、2.2系からの移行か、使っているモジュールの数や検証する業務の範囲によって大きく変わるため、一律には決まりません。まず棚卸しと影響調査を行い、その結果から作業の量を見積もるのが確実です。
Apacheのバージョンアップのご相談
Apacheの版と入れ方の棚卸しから、影響調査と検証、切り替え後の定期的な更新まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：The Apache Software Foundation「The Apache HTTP Server Project」公式サイト トップページ（https://httpd.apache.org/）。出典：2.4.69のリリース（2026年10月1日）と2.4系が安定版であること、2.2系の保守終了（最後の版は2017年7月の2.2.34）と2.4系への移行の呼びかけを参照（2026年11月確認）
- *2 参考：The Apache Software Foundation「Reporting Security Problems with Apache」（https://httpd.apache.org/security_report.html）。出典：以前の版は脆弱性の修正を受けておらず使うべきでないこと、お知らせのメーリングリストで修正の知らせを受け取れることを参照（2026年11月確認）
- *3 参考：The Apache Software Foundation「Apache HTTP Server 2.4 vulnerabilities」（https://httpd.apache.org/security/vulnerabilities_24.html）。出典：2.4.69で直された20件の脆弱性（中程度5件・低15件）と、重大度の評価が環境によって変わりうるとの注記を参照（2026年11月確認）
- *4 参考：The Apache Software Foundation「Upgrading to 2.4 from 2.2」（https://httpd.apache.org/docs/2.4/upgrading.html）。出典：2.2系から2.4系への移行で設定の変更が要ること、アクセス制御の書き方の変更、AllowOverrideの初期値の変更、他者が作ったモジュールの再コンパイルの記述を参照（2026年11月確認）
- *5 参考：Red Hat「Backporting Security Fixes」（https://access.redhat.com/security/updates/backporting）。出典：バックポートの説明、版の番号だけでは脆弱性の有無が分からないこと、番号だけで判断する診断ツールの誤検知についての記述を参照（2026年11月確認）
- *6 参考：Debian「Debian security FAQ」（https://www.debian.org/security/faq）。出典：安定版に入れた版のまま修正をバックポートする理由についての記述を参照（2026年11月確認）
- *7 参考：Canonical「Ubuntu release cycle」（https://ubuntu.com/about/release-cycle）。出典：LTSが5年間の標準のセキュリティ保守を受けることの記述を参照（2026年11月確認）
- *8 参考：The Apache Software Foundation「Download – The Apache HTTP Server Project」（https://httpd.apache.org/download.cgi）。出典：入手したファイルの完全性を署名で確かめる必要があることの記述を参照（2026年11月確認）
