Rails・WordPress・Djangoが10日で相次いで緊急修正｜保守契約に「フレームワーク更新」は入っているか

システムを外注している会社にとって、今回の10日間が突きつけているのは個別の脆弱性ではない。「土台のソフトウェアが更新されたとき、それを自社のシステムに適用するのは誰の仕事か」が契約書に書かれているか、という問いである。

2026年7月末から8月上旬にかけて、Webシステムの土台になるソフトウェアの重大な修正が立て続けに公開された。

このうちDjangoについて、公式のセキュリティリリースは4件を挙げている。深刻度が「高」とされるCVE-2026-15307は、空間ルックアップを経由したサーバー側でのファイル書き込みとリクエスト偽造に関するもので、報道ではCVSS 8.8、環境によってはリモートコード実行に至るおそれがあるとされている。残る3件は、管理画面のURLField値を経由したクロスサイトスクリプティング（CVE-2026-15920、中）、ネストされたジオメトリコレクションによるサービス拒否（CVE-2026-15830、中）、check_for_language()関数における潜在的なサービス拒否（CVE-2026-15337、低）である。対象はDjango 6.0、5.2、および6.1のリリース候補とmainブランチとされている。

個別の対応手順は、それぞれの製品ごとに公式情報を確認すればよい。この記事が扱うのは、その手前にある問題である。これらの情報が公開されたとき、自社のシステムに適用されるまでの経路が、契約として存在しているか。

この記事を読むべき人

• 業務システムやWebサービスを開発会社に外注し、月額の保守費を払っている経営者
• 保守費を払っているのに、脆弱性対応が別見積になった経験がある会社
• システムが何で作られているか（言語・フレームワーク・バージョン）を把握していない会社
• 開発会社との契約書を、締結後に読み返していない会社
• これから新しいシステムの発注を検討していて、契約条件を詰めたい会社

「保守」という言葉には3つの中身がある

保守契約という同じ名前でも、含まれる範囲は会社によって大きく違う。**以下の3分類は業界標準でも法的分類でもなく、保守範囲を確認するためにGXOが整理したものである。**自社の契約がどれに近いかを見るための道具として使ってほしい。

**類型1：瑕疵対応型。納品したものが仕様どおりに動かない場合に直す。期間が定められていることが多い。この型では、納品後に公開された脆弱性への対応が含まれないことが多い。ただし納品後に公表された脆弱性が契約上どう扱われるかは、契約書、仕様書、保証期間、セキュリティ要件の定めによって異なる。**納品物の適合性の問題として争点になる場合もあるため、一律に「対象外」と決めつけず条項を確認する必要がある。

**類型2：稼働維持型。**サーバーが落ちていないか、エラーが出ていないかを監視し、障害時に復旧する。可用性を守る契約であり、脆弱性の有無は監視項目に入っていないことが多い。「動いている＝正常」と判定されるため、脆弱なまま動き続けている状態は検知されない。

**類型3：更新込み型。**土台のソフトウェアやライブラリの更新情報を追跡し、影響を評価し、適用まで行う。ここまで含んで初めて、今回のような公表に自動的に反応する体制になる。

脆弱性が公表されたときに「別途お見積もりします」と言われて驚くケースがあるが、これは開発会社が不誠実とは限らず、契約の範囲外の作業を求めているために起きる。自社の契約がどの範囲まで含むかは、契約書の名称ではなく、業務範囲・成果物・セキュリティ更新・ライブラリ管理の各条項で確認する。

自社の契約がどれかは、契約書の業務範囲の条項を読めば判定できる。「障害対応」「稼働監視」としか書かれていなければ1か2、「セキュリティアップデートの適用」「使用ソフトウェアのバージョン管理」といった記載があれば3である。

「10日で3件」は異常事態ではない

今回のように短期間で複数の公表が重なると、特別な事態が起きているように見える。しかし実際には、広く使われているソフトウェアでは修正の公開が定期的に行われており、重なるのは偶然の産物である。

この認識は、体制を考えるうえで重要になる。「珍しいことが起きたから今回だけ対応する」のか、「毎年繰り返されることだから仕組みを作る」のかで、投じるべき労力が変わる。

年間を通じて見れば、自社が使っているソフトウェアの数だけ、公表の機会がある。フレームワーク、CMS、データベース、Webサーバー、OS、クラウドサービス、そして数十から数百に及ぶライブラリ。それぞれに独自の公表サイクルがある。

したがって、現実的な目標は「すべての公表に即座に対応する」ことではない。**「自社に該当するものを選別できる状態を作る」ことである。**選別さえできれば、該当しないものは読むだけで終わり、該当するものだけに労力を集中できる。前掲のシステム一覧が価値を持つのは、この選別を可能にするからだ。

逆に、選別ができない状態では、二つの失敗のどちらかに落ちる。すべてのニュースに反応して疲弊するか、すべてを無視して該当分も見逃すか。多くの会社は後者になる。そして見逃したことは、見逃している間は分からない。

更新が止まる4つの構造

契約の問題とは別に、技術的・実務的に更新が止まる構造がある。自社がどれに当たるかで、必要な手当てが変わる。

**構造1：バージョンが古すぎて、修正版が提供されていない。**フレームワークにはサポート期間があり、期間を過ぎた版には修正が提供されない。今回のDjangoの修正も、対象として挙げられているのはサポート中の系統である。サポート切れの版で動いているシステムは、脆弱性が公表されても適用できる修正版が存在しない。この場合の対応は、フレームワーク自体のバージョンアップになり、規模も費用も桁が変わる。

**構造2：依存関係が固定されている。**フレームワークを上げると、連動する他のライブラリも上げる必要があり、そのどれかが対応していないと止まる。長く運用したシステムほど、この連鎖が長い。

**構造3：自動テストがない。**更新後に既存機能が壊れていないかを確認する手段が、人手による動作確認しかない。すると更新のたびに検証費用が発生し、金額を理由に見送られる。自動テストの有無は、開発時の品質の話に見えて、実は運用期間中の更新コストを決める要因である。

**構造4：稼働環境が把握されていない。**そもそも本番環境で動いているバージョンが分からない。開発時の資料が残っておらず、担当者も入れ替わっている。この状態では、公表された脆弱性が自社に該当するかの判定すらできない。

構造1と4は、いま調べれば分かる。構造2と3は、調べた結果として費用の見通しが立つ。いずれも、脆弱性が公表されてから調べるより、平時に調べておくほうが安く早い。

開発会社に聞く5問

自社のシステムがどの状態にあるかを把握するための質問を挙げる。1つのシステムにつき、これだけ聞けば判定できる。

1. このシステムは何のフレームワーク（またはCMS）の、どのバージョンで動いているか。本番環境の実際の値を教えてほしい。
2. そのバージョンは、提供元のサポート期間内か。サポート終了はいつか。
3. 直近1年で、フレームワークやライブラリの更新を何回適用したか。適用していない場合、その理由は何か。
4. 更新後の動作確認は、自動テストで行われるか、人手による確認か。
5. 当社との契約では、脆弱性が公表された際の情報収集・影響評価・適用は、どこまでが含まれるか。含まれない部分は、どういう費用体系になるか。

**質問2の答えが「サポートは終了している」だった場合、それが最も重い課題になる。**今回のような公表があっても、適用できる修正が存在しないためだ。この状態は、脆弱性が出るたびに悪化するのではなく、既に悪化しきっている。フレームワークのバージョンアップか、再構築かの判断に入る必要がある。

**質問5の答えがあいまいな場合、それは契約の不備であって、開発会社の落ち度とは限らない。**発注時に決めていなかったなら、双方に責任がある。ここは責任追及ではなく、次の契約更新で明文化する項目として扱うのが建設的である。

深刻度が「中」「低」のものは、後回しにしてよいか

今回のDjangoの4件のうち、深刻度が高いとされているのは1件で、残りは中が2件、低が1件である。ここで「高だけ直して、あとは次回まとめて」という判断が出てくる。

**結論から言えば、この選り分けは費用の面で割に合わないことが多い。**理由は、更新作業のコスト構造にある。

そもそも通常は、個別のCVEだけを選んで直すのではなく、提供元が出した修正版リリースへ更新する。更新作業と回帰試験という共通の工程が発生するため、費用は脆弱性の件数に単純比例しない。

ただし「まとめても費用は同じ」と言い切ることもできない。確認すべき範囲は、利用している機能、依存ライブラリ、独自に当てているパッチ、停止可能時間によって変わるからだ。件数ではなく、確認範囲がどう変わるかを見積もりの前提として確認するのが正確である。

さらに、選り分けて後回しにすると、次に高深刻度の修正が出たときに、前回見送った分と合わせて上げることになる。その頃には差分が大きくなり、動作確認の範囲がむしろ広がっている。

したがって実務的な原則はこうなる。**修正版が出ているなら、深刻度で選り分けずに最新の修正版へ上げる。**選り分けが必要になるのは、更新に伴う業務停止が許容できない場合や、依存関係の都合で上げられない場合であり、深刻度が理由になることは少ない。

この考え方は、開発会社との会話でも使える。「高の1件だけ対応します」という提案が来たら、「4件まとめて上げる場合の費用差はどれくらいか」と聞いてみてほしい。差がほとんどないなら、まとめたほうが合理的である。

契約に入れておくべき5条項

これから発注する場合、あるいは契約を更新する場合に、書き込んでおくと後の争いが減る条項を挙げる。いずれも特別なものではなく、書いていないから曖昧になっているだけの項目である。

**条項1：使用するソフトウェアとバージョンの一覧を、納品物に含める。**言語、フレームワーク、主要ライブラリ、ミドルウェアと、それぞれのバージョンとサポート終了予定日。これがあると、以後の脆弱性公表に自社で反応できる。

**条項2：脆弱性情報の通知義務。**使用しているソフトウェアについて重大な脆弱性が公表された場合、開発会社から自社へ通知する。通知の期限（例：認知から何営業日以内）を定める。

**条項3：影響評価の実施範囲。**通知後、自社のシステムが影響を受けるかを評価する作業が、定額の保守に含まれるか、別費用か。含まれない場合の単価。

**条項4：適用作業の費用体系と対応時間。**深刻度に応じた対応時間の目安（例：緊急の場合は何営業日以内に着手）と、費用の扱い。

**条項5：サポート終了への対応。**使用しているフレームワークのサポート終了が近づいた際、何か月前に通知し、どのような選択肢を提示するか。

**このうち条項1と2だけでも入れておくと、状況は大きく変わる。**自社が対象かどうかを判定でき、公表を見逃さなくなるからだ。3から5は費用の話であり、交渉によって落としどころが変わるが、1と2はほとんど費用を伴わない。

「作って終わり」の見積もりと、「持ち続ける」見積もり

もう一段深い論点に触れておきたい。システムの発注時に比較されるのは、たいてい初期開発費である。しかし実際に会社が払うのは、初期費用に加えて、運用期間中の維持費の総額である。

そして今回のような更新対応は、**初期開発費が安い提案ほど、後から高くつく傾向がある。**理由は前述の構造3にある。自動テストを書かず、環境構築を手作業で行い、依存関係の整理を省略すれば、初期の見積もりは下がる。しかしそのシステムは、更新のたびに人手による確認が必要になり、依存関係の絡まりを解く作業が発生する。

**発注側がこの差を見抜くのは難しい。**提案書には「自動テストを省略しています」とは書かれないからだ。しかし質問はできる。「更新作業の際、動作確認はどのように行いますか」「5年間運用した場合、フレームワークの更新は何回想定されますか」。この2つに具体的に答えられる提案と、答えられない提案の間には、運用期間全体で見たときの差がある。

**初期費用の比較だけで発注先を決めた結果が、数年後に「更新できないシステム」として返ってくる。**今回のように土台のソフトウェアが立て続けに更新される状況は、その差が表面化する場面である。

既に「更新できない」システムを抱えている場合

質問2の答えが「サポート終了済み」だった場合、更新という選択肢が最初から存在しない。この状態のシステムを抱えている会社は珍しくなく、しかも業務の中核を担っていることが多い。放置も再構築も選べない、という板挟みになる。

この場合に取れる手は、順に3つある。

**外部からの到達を絞る。**インターネットから直接アクセスできる状態なら、社内ネットワークやVPN経由に限定する。利用者が社内に限られる業務システムであれば、この措置だけでリスクは大きく下がる。恒久対策ではないが、再構築の期間を稼ぐ手段としては現実的である。

**機能を切り分けて縮退させる。**外部からの入力を受け付ける機能（フォーム、ファイルアップロード、公開検索）だけを切り離し、別の仕組みへ移す。攻撃の入口になりやすいのはこうした機能であり、本体を残したまま入口だけ差し替えられる場合がある。

再構築の計画を立てる。上の2つで時間を稼いでいる間に、置き換えの計画を進める。ここで重要なのは、「全部を一度に作り直す」以外の選択肢を検討することである。業務単位で切り出して段階的に移行できれば、一度に必要な投資は小さくなる。

避けたいのは、3つのどれも選ばずに「いつか直す」のまま数年が経つことだ。**サポート終了済みのシステムは、時間とともに危険度が上がる。**新たな脆弱性が公表されても修正が提供されないため、既知の弱点が積み上がっていく。動いているうちは実感が伴わないが、状態は毎年悪くなっている。

経営判断としては、このリスクを金額に置き換えて考えるのが分かりやすい。そのシステムが3日止まった場合に失う売上と、復旧に要する費用を見積もる。その金額が再構築の費用を上回るなら、先送りの合理性はない。

自社のシステム一覧を作る

最後に、今回を機に作っておくと以後ずっと効く一覧を提案する。項目は最小限でよい。

**この一覧の価値は、緊急時の初動が「委託先への問い合わせ」ではなく「該当の有無の即答」に変わることにある。**今回のように3つのソフトウェアで立て続けに公表があった場合、一覧があれば数分で自社の対象を絞り込める。なければ、3回それぞれで問い合わせと回答待ちが発生する。

作成にかかる時間は、システムの数にもよるが数時間程度である。委託先に依頼すれば、そちらでも作れる。ただし前述のとおり、保持するのは自社であることが重要になる。

よくある質問

Q. Djangoを使っていないので今回は関係ないと考えてよいか。 A. Django固有の対応としては関係ない。ただしこの記事の論点は、Django・Rails・WordPressのいずれを使っていても同じである。自社のシステムが何で動いていて、その更新を誰が担うのかという問いは、製品を問わず存在する。

Q. 保守費を払っているのに脆弱性対応が別料金なのは不当ではないか。 A. 契約の範囲による。範囲外の作業に費用が発生するのは不当ではない。問題は、発注側が「保守費に含まれている」と認識し、受注側が「含まれていない」と認識したまま数年が経っていることにある。認識の食い違いを解消する場が、契約更新のタイミングである。

Q. 開発会社が「調べるのに費用がかかる」と言う。妥当か。 A. 稼働バージョンの確認自体は短時間で済むことが多く、そこに大きな費用が発生するなら理由を確認したほうがよい。一方、影響評価（自社の実装が該当条件を満たすかの判定）は、コードを読む作業を伴うため相応の工数が発生する。両者を分けて見積もってもらうと、妥当性が判断しやすい。

Q. 社内に情シスが1名（または兼任）しかいない。誰がこの情報を受け取るのか。 A. 情報の収集と一次判定までを外部に委ね、判断と発注は社内で行う切り分けが現実的である。1名の担当者に「毎日情報を追う」ことまで求めると、本来の業務が回らなくなる。ただし前掲のシステム一覧だけは社内に置き、外部からの連絡が来たときに自社で該当判定できる状態にしておく。この一覧があると、外部への依頼も「該当するこの2システムについて評価してほしい」と具体的にでき、費用も抑えられる。

Q. 更新を続けると、いつまで費用が発生するのか。 A. システムを使い続ける限り発生する。これは避けられない費用であり、初期開発費と同様に事業計画へ織り込むべき性質のものである。逆に言えば、この費用を織り込んでいない事業計画は、システムが動き続ける前提を満たしていない。

保守範囲を確認したいとき

自社のシステムがどう作られていて、どこまでが保守に含まれているかを整理する作業は、開発会社に聞くだけでは完結しにくい。回答の妥当性を判断する材料が発注側にないためである。

現行の契約と稼働環境を第三者の立場で確認し、どこにリスクが残っているかを整理したい場合は、システム開発・DX推進の相談が対応範囲になる。既存システムの状態評価と、更新か再構築かの判断も同じ枠で扱える。

継続的に脆弱性情報の追跡と適用判断を委ねたい場合はセキュリティ保守・運用の継続支援、対策全般の整理から始めたい場合はセキュリティ関連サービスが該当する。これから新規発注を控えていて契約条件の詰め方を相談したい段階であれば、お問い合わせで受け付けている。発注前の準備は、発注後の是正よりはるかに安く済む。

参照した情報

• Django公式「Django security releases issued: 6.0.8 and 5.2.17」（2026年8月4日、CVE番号・深刻度・対象バージョン）: https://www.djangoproject.com/weblog/2026/aug/04/security-releases/
• Security NEXT「『Django』に4件の脆弱性 - セキュリティアップデートを公開」（2026年8月7日、CVSS値の報道）: https://www.security-next.com/188462
• JPCERT/CC 注意喚起「Ruby on RailsのActive Storageにおけるリモートコード実行につながる脆弱性（CVE-2026-66066）」: https://www.jpcert.or.jp/at/2026/at260021.html
• WordPress公式「WordPress 7.0.3 release」（2026年8月6日）: https://wordpress.org/news/2026/08/wordpress-7-0-3-release/

Djangoの各CVEの深刻度区分と対象バージョンはDjango公式のセキュリティリリース告知に基づく。CVSS値およびリモートコード実行の可能性に関する記述は上記報道に基づく二次情報である。保守契約の3分類、更新が止まる4構造、契約条項の提案は、いずれも発注側が保守範囲を確認するためにGXOが作った枠組みである。業界標準の分類でも、各ソフトウェア提供元が示した区分でもない。契約条項の文案は法務の確認を経て使用してほしい。ここに挙げたのは論点であって、条文そのものではない。