Drupal サポート: 保守契約がカバーすべき範囲

Drupal のサポートを探している人の多くは、すでにそのサイトを所有しています。手を引いた制作会社から引き継いだか、辞めた開発者から引き継いだかで、いまや更新は期限を過ぎ、フォームは送信されなくなり、セキュリティアドバイザリが出ても、それが自分に当てはまるのかを誰も答えられません。その人たちが求めているのは営業ページではありません。作業とは何か、公正な契約には何が書かれているのか、そしていくらかかるのかという、スコープの文書です。

この記事はそれです。Drupal サイトが毎月本当に必要とする作業、保守契約に価値があるかどうかを決める運用上の事実、そして英国での現実的な価格帯を並べます。取引先の提案書を横に開いて読んでください。役に立つのは、その提案書がどの問いに答えていないかに気づく部分だからです。

一般的なウェブサイト保守と Drupal を分ける点は二つあります。セキュリティアドバイザリが公開された時間割で動くため、危険にさらされる時間の幅が測定でき、契約に書き込めること。そしてサイトが独立したメンテナを持つコントリビュートモジュールの集合体であるため、動き続けるアップグレードの的を誰かが代わりに追い続けなければならないことです。

Drupal の保守契約は何をカバーすべきか。 あなたのモジュール構成に正確に当たるセキュリティアドバイザリの監視、ステージングを通した決められた周期でのコアとコントリビュートモジュールの更新、バックアップが本当に復元できることの検証、稼働とアプリケーションエラーの監視、そして小さな作業のための明示された変更予算です。英国では、単純なブローシャーサイトでおおよそ月 250 ポンドから、複雑なサイトでは 2,000 ポンド以上になります。その帯より下で買えるのはサポートではなく監視です。

Drupal のサポートとは、毎月どんな作業なのか

三社に見積もりを頼めば、Essential、Business、Enterprise と名づけられた三つのパッケージが返ってきて、どれも名詞の箇条書きです。名詞は作業ではありません。作業とは、予定に沿って起きるか、まったく起きないかのどちらかである一連の反復タスクであり、役に立つ進め方は、その一つひとつを担当者と頻度のついた活動として説明させることです。

その活動は八つあります。セキュリティアドバイザリの監視とパッチ適用。コアとコントリビュートモジュールの更新。依存関係とプラットフォームのバージョンアップ。バックアップの検証と復元テスト。稼働とアプリケーションエラーの監視。性能劣化のチェック。コンテンツと編集の支援。そして必ずやってくる小さな作業のための変更予算です。

八つすべてを挙げた契約が自動的に良いわけではありませんが、四つしか挙げていない契約は確実に不完全で、落ちる四つはたいてい同じです。復元テスト、性能劣化、プラットフォームのアップグレード、変更予算。費用のかかるものばかりで、だから消えます。

パッケージ名が作業を隠す理由

「無制限のサポートチケット」は、月の第3水曜日に誰がコアのセキュリティパッチを当てるのかについて何も言っていません。「プロアクティブな監視」は、深夜二時にアラートを人間が読むのか、それとも月曜まで積まれるのかについて何も言っていません。「ベストエフォート」は何も言っていません。

それぞれの表現を三つの事実に置き換えてください。活動、その頻度、そしてそれを実行する名前のついた役割です。ほとんどのパッケージページはその処理で溶けてなくなり、残ったところが話す価値のある取引先です。

パッチ適用の窓こそが商品そのもの

Drupal はセキュリティリリースを時間割に沿って公開します。これは珍しく、そして非常に役に立ちます。コアのセキュリティリリースは毎月第3水曜日 の枠で出て、America/New York の 1200 に始まり、季節によって 1600 か 1700 UTC にあたります。コントリビュートプロジェクトには毎週水曜日のセキュリティリリース枠 があるため、コントリビュートのアドバイザリはコアよりはるかに頻繁に、まとまって届きます。

結果として、脆弱性そのものはリスクではありません。Drupal を動かしている全員が同じ脆弱性を同じ瞬間に、公開の場で受け取ります。リスクは、アドバイザリが公開されてからパッチが本番サイトに載るまでの隙間です。その隙間のあいだ、欠陥は文書化され、索引され、あなたの取引先より速くアドバイザリを読んだ人たちに探索されているからです。

サポート契約の他のすべての条項は、その隙間の時間数の隣では飾りです。だから見込みの取引先への最初の質問は、哲学ではなく算術になります。来月の第3水曜日、何時に人がアドバイザリを読み、いつまでにパッチが本番に載るのか。「当社の標準 SLA の範囲内で」は、その問いへの答えになっていません。

Drupal はリスクをどう採点し、それが契約に何をもたらすべきか

Drupal のアドバイザリにはすべて数値が付いていて、その数値はこのプラットフォームでもっとも使われていない条項作成の道具です。Drupal はNIST の Common Misuse Scoring System、NISTIR 7864 で脆弱性を採点し、六つの指標から 0 から 25 までの点を出します。攻撃の複雑さ、認証、機密性への影響、完全性への影響、エクスプロイトの入手可能性、そして対象の分布です。

スコアは公開された五つの区分に対応します。0 から 4 は重大ではない、5 から 9 は軽度に重大、10 から 14 は中程度に重大、15 から 19 は重大、20 から 25 はきわめて重大です。この区分は公開されていて安定しており、どちらの当事者の解釈にも開かれていません。

だからこそ、これはサポート SLA の自然な背骨になるのですが、ほとんど誰も使いません。あとで取引先が言い争える私的な重大度の定義を発明するのではなく、応答の約束を Drupal のスコアに直接ぶつけて書いてください。きわめて重大は時間外を含めて明示した時間数以内に適用、重大は一営業日以内、中程度に重大は次の定期サイクルで、それ以外はまとめて処理する。第三者がすでに決めているので、どちらの側も「緊急」の意味を蒸し返せません。

きわめて重大は、運用上まったく別の出来事

きわめて重大なコアリリースはまれで、Drupal はそれを別扱いにします。セキュリティチームは事前に公開の予告 を出し、サイト所有者が体制を組めるようにします。PSA-2026-05-18 はまさにそれを行い、2026年5月18日に、5月20日水曜日に予定された、サポート対象のすべてのブランチに影響するきわめて重大なコアリリースについて警告しました。

その事前通知こそ、保守契約を組み立てる軸にすべきものです。緊急事態を予約に変えるからです。月曜に PSA を知り、水曜のデプロイ枠を確保している取引先はサポートサービスを運営しています。木曜に知る取引先はメーリングリストを運営しています。

知っておく価値のある緩和策もあります。Drupal Steward は Drupal Association とセキュリティチームが運営する有償の分散型ウェブアプリケーションファイアウォールで、きわめて重大なコアの脆弱性に対してネットワーク層の仮想パッチを提供し、更新をテストしているあいだサイトを守ります。価格は米ドルで公開され、トラフィックに応じて上がります。月あたりの HTTP リクエストが 100 万件ほどのサイトで月 20 ドル未満、1000 万件を超えると月 100 ドル未満です。買えるのは時間であって免疫ではなく、良い保守契約は誰がその費用を持つのかを書いています。

セキュリティアドバイザリの方針がカバーしないもの

セキュリティアドバイザリの手続きと権限に関するポリシー にある三つの除外が、保守契約のやるべきことを変えます。そしてほとんどのサポート契約は、三つとも黙っています。

アドバイザリは安定版リリースに対してのみ発行されます。サイトのモジュールがアルファ版、ベータ版、リリース候補版、開発版で動いている場合、それについてのアドバイザリは決して公開されず、知らせがないことは何の意味も持ちません。対象範囲もプロジェクトごとの任意加入であって自動ではないため、対象外のコントリビュートモジュールは、通知の経路がまったくないまま既知の欠陥を抱えていられます。

そして人を捕まえるのがこれです。外部ライブラリについてはアドバイザリが発行されません。コントリビュートプロジェクトがそのインストールを要求している場合でもです。依存として引き込まれた JavaScript や PHP のライブラリはあなたの問題で、あなたが追跡するものであり、Drupal のフィードには現れません。

対象範囲は取り消されることもある

セキュリティの対象範囲は永続ではありません。PSA-2026-07-22 は QA Accounts モジュールからアドバイザリの対象範囲を外しました。使いやすさをセキュリティより優先しており、インターネットから到達できないサイトだけを想定しているという理由です。

これがリスクの形です。何年も前に対象範囲のもとで入れたモジュールが静かにそれを失うことがあり、サイト側では何も変わらないので気づけません。導入済みのすべてのプロジェクトについて、現在の対象範囲の状態とリリースの安定度を含む台帳を保つことは本物の反復作業であり、保守契約に文字として入るべきものです。

依存関係とプラットフォームのアップグレードはサポート作業

Drupal のサポート契約でもっともよく除外される項目は、最終的にサイトが生き残るかどうかを決めるものです。Drupal のプラットフォーム要件は動き、しかも composer update ではなくホスティングの変更を必要とする段差で動きます。

PHP では、Drupal 10 が少なくとも PHP 8.1 を要求し 、Drupal 11 は 11.1 以降 PHP 8.3 を最低条件としてきました。PHP 8.5 のサポートは Drupal 11.3 で入り、Drupal 12.0 は PHP 8.5 のみをサポートします。この最後の一点は見た目より重要です。いま PHP 8.1 で快適に動いているサイトは、Drupal 12 までに強制的なプラットフォーム移行を二回はさむからです。

データベースの要件も同じだけ動きました。Drupal 11 が必要とするのは MySQL 8.0 以降、MariaDB 10.6 以降、PostgreSQL 16 以降、または SQLite 3.45 以降です。Drupal 10 は MySQL 5.7.8、MariaDB 10.3.7、PostgreSQL 12 を受け入れていました。MySQL 5.7 をいまも提供しているマネージドホストは、細部ではなくアップグレード経路上の障害物であり、何が実際に Drupal をうまく動かすのか についての記事が、どこへ移るべきかを扱っています。

Drupal 10 のサポート終了は、すでに保守契約の問題

Drupal 10 は 2026年12月9日にサポートを終了し 、Drupal 12 は同じ週、12月7日から始まる週にリリースされます。11.3.x と 10.6.x のブランチに対するセキュリティサポートもその時点で終わります。2026年9月の時点でセキュリティリリースを受けているブランチは 11.4.x、11.3.x、10.6.x です。

暦に照らせば、それはおよそ三か月です。2026年9月の時点で見積もり付きのアップグレード計画を持たない Drupal 10 のサイトは、12月に割増料金を払うか、サポートのない状態で動かすかのどちらかに費やすことになります。そして後者は、流されて決まるのではなく、誰かが意識して選ぶべき決定です。

料金に見合う保守契約なら、すでに四つのものを出しているはずです。現在のアップグレード状況の報告、カスタムモジュールとテーマの非推奨コードの走査、すべてのコントリビュートモジュールについての Drupal 11 と 12 への対応可否の確認、そして書面の見積もりです。取引先がいまだにそのどれも出していないなら、それが調査結果です。Drupal 移行の費用、選択肢、期限 についての分解が作業の中身を示していて、同じ計画は当社のウェブサイト開発 の案件のなかにも入っています。

バックアップは復元を試すまで何の価値もない

Drupal のサポート契約はほぼすべてバックアップを約束します。復元を約束するものはごくわずかで、その違いがこの項目の価値のすべてです。NCSC は小規模組織向けの手引きではっきり書いています。バックアップを取ったあとは 、それをどう戻すかを知り、大事なものがすべて入っているかを確かめる必要がある、と。

Drupal の復元には動く部品が三つあり、部分的なバックアップは二つ目でうんざりするほど規則正しく失敗します。データベース、公開および非公開のファイルディレクトリ、そして設定が必要です。データベースは取れているのにファイルディレクトリが取れていないバックアップは、コンテンツは無事で画像のないサイトを復元します。監視スクリプトには動いているサイトに見え、顧客には災害に見えます。

日付の入った復元テストを、使い捨ての環境に対して実施し、どれだけ時間がかかり何が欠けていたかを書面で残すよう求めてください。多くのサイトでは四半期に一度が妥当な頻度です。取引先が一度もやったことがないなら、彼らは自分たちの復旧時間を知らず、あなたも知りません。

稼働とエラーの監視、そして稼働率が本当に測っているもの

サーバーが動いていることと、サイトが動いていることのあいだには大きな隔たりがあり、Drupal はその真ん中に座っています。PHP の致命的エラー、使い切ったメモリ制限、失敗したデータベース接続、壊れたキャッシュの再構築は、どれも素朴なチェックが成功と読むページか、誰も見張っていないただの 500 を生みます。

サーバーで測る監視は、箱が応答することを教えます。アプリケーションで測る監視は、実際のページを要求し、リダイレクトを追い、期待した内容がレスポンス本文にあることを検証します。この二つは価格の違う別の商品で、どちらなのかを言わずに「稼働監視」と書くサポート提案は、安いほうを説明しています。

その下には Drupal 自身のログがあります。最近のログメッセージのレポートと PHP のエラーログは、失敗している cron 実行、非推奨の関数、毎リクエストで例外を投げるモジュールが、訪問者の苦情よりずっと早く現れる場所です。誰かが定期的に読まなければなりません。意味のある稼働率 SLA についての記事が、パーセンテージが許容される分数にどう翻訳されるかを扱っています。

Drupal のサポート SLA を批判的に読む

ほとんどのサポート SLA は、使われるためではなく合意されるために書かれていて、速く読まれるからこそ合意されます。重みのほぼすべてを担っているのは三つの条項で、それを注意深く読むのに十分ほどしかかかりません。

応答時間は解決時間ではない

二時間の応答を約束する SLA は、たいてい二時間以内に誰かがチケットを受け付けることを約束しています。誰かがあなたのサイトを見ることは約束していません。本気の取引先は解決の目標に、少なくとも診断と回避策の目標にコミットし、修正までの時間は別に示します。

作業を本当に時間で区切れない場合、誠実な契約はそう書き、代わりに解決までの継続的な取り組みを約束します。それは本物の約束です。「二時間応答」だけなら、メールを送る約束です。

重大度の定義がすべてを決める

どの SLA にも重大度の表があり、重大度を割り当てるのはたいてい取引先です。それが抜け穴です。優先度1の定義が「サイトが利用不能」なら、顧客の三分の一で決済が失敗しても優先度3になり、来週見てもらえます。

定義を技術的な状態ではなく事業への影響を軸に書き、実例を契約に入れてください。失敗する決済手順、入れない管理画面のログイン、問い合わせページの壊れたフォーム。そのうえで、誰が重大度を割り当て、その割り当てにどう異議を唱えるかを合意します。

対応時間は営業時間ではない

「営業時間」と「対応時間」は違うものを指すのに、しばしば混ぜて使われます。対応時間とは、時計が動き、誰かが動く義務を負う時間帯です。対応時間が営業日の 09:00 から 17:30 なら、12月の水曜日の 1700 UTC に公開されたアドバイザリは、早くても翌朝に拾われます。

Drupal に限って言えば、コアのセキュリティの枠が 1600 または 1700 UTC に開くことに注意してください。17:30 に対応時間が終わる英国の取引先は構造的にその縁にいるので、きわめて重大なアドバイザリのための時間外の取り決めは、別に名指しして価格を付ける必要があります。

何がインシデントで、何が除外されるのか

除外の節は、保守契約が見た目より静かに安くなる場所です。よくある除外は単体では完全に妥当で、組み合わせると不当になります。第三者のホスティング障害、顧客側の担当者が原因の問題、取引先が入れていないモジュールの不具合、有償テーマに関わるもの、そして取引先が不具合ではなく変更に分類するものすべてです。

最後のものが鋭い縁です。不具合の修正に設定変更が必要で、設定変更が課金対象なら、ほとんどどんな不具合も課金の側に分類し直せます。取引先が不具合と変更をどう区別しているかを直接尋ね、自社の最近の仕事からそれぞれ二つの例を出してもらってください。

第三者が絡むときにどうなるかも確認してください。決済ゲートウェイ、CRM の連携、ホストに原因があるとき、取引先は修正を調整するのか、それともチケットは対象外として閉じられるのか。調整は本物の作業で、支払う価値がありますが、それは契約にそう書いてある場合だけです。

三つの保守契約モデルを正直に比べる

Drupal のサポートの取り決めは、ほぼすべて三つの形のどれかで、それぞれ違う状況への妥当な答えです。間違いは、ある形を買いながら別の形の振る舞いを期待することです。

月あたりの固定時間

八時間や十六時間といった時間の塊を買い、取引先はそれをあなたが頼んだ何にでも使います。透明で、見積もり同士を比べやすく、小さな変更が細く流れ続け、優先順位を付けられる人が社内にいる組織に向いています。

弱点は、保守が機能と同じ財布を奪い合うことです。忙しい月には、セキュリティのパッチ適用がキャンペーンのランディングページに静かに負けます。時間を使う人には締切があり、パッチには締切の感触がないからです。このモデルを買うなら、時間の一部を契約そのもので保守に囲い込んでください。

無制限の修正と個別見積もりの変更

取引先は月額固定で保守と小さな修正を引き受け、合意した閾値を超えるものは別に見積もります。これは多くの制作会社が推すモデルで、安定したサイトと心配性の所有者にとっては本当に正解です。変動するリスクを予算上の固定した一行に変えるからです。

弱点は境界です。「小さな修正」は誰かが必要とするまで未定義で、閾値はその月の具合によって動きます。書面の定義を、できれば三十分未満といった時間の区切りで求め、何を引き受けたかを示す月次の報告を求めてください。

純粋な時間と材料

保守契約なし、日単価、頼んだときに作業する。これは、更新を本当に自分で追いかける所有者のいる低リスクなサイトと、社内に能力があって、対応そのものより時々の専門的な助けを必要とする組織にとっての、正直な選択です。

弱点は、能動的なことが何も起きないことです。見るために誰も払われていないからです。時間と材料は待ち行列にも弱く、保守契約を結んだ顧客と同じエンジニアを取り合うので、悪い日の応答は時間ではなく週で測られます。

定額サポートに潜むインセンティブの問題

定額のサポートには、業界の誰も話したがらない構造的な問題があります。サイトが何時間消費しても取引先の受け取りが同じなら、あなたのサイトに使う一時間はすべて彼らの利益を削るので、商業的に合理的な振る舞いはできるだけ使わないことです。

それはたいてい放置としては現れません。正しい修正より速い修正を好むこと、原因をたどるより症状を抑えること、一日の回帰テストを要するモジュールの更新を先送りすることとして現れます。安いプランでは逆向きにも現れます。そこでは、サイトに本当に一度も触らない場合だけ料金が成り立つからです。

釣り合いを取るのは報告の義務です。消費した時間、適用した更新、評価したアドバイザリ、閉じたチケットを並べた月次報告は、消費を双方に見えるようにし、儲からない顧客をゆっくりしたサービス低下ではなく会話にします。モデルに自信のある取引先なら同意します。抵抗する取引先は、そのモデルが本当は何のためのものかを教えています。

運用面で良いとはどういうことか

あなたのサイトを安全に支えられる Drupal の取引先と、その場しのぎでやっている取引先を分ける技術的な習慣が三つあります。どれも珍しいものではなく、三つとも簡単に尋ねられます。

Composer か、さもなくば何もなし

Drupal 自身の文書は更新方法を混ぜることについて率直で、Composer の更新を他の方法と組み合わせるとサイトが重大な更新の問題に遭う可能性がある こと、そして一度 Composer がひとつのモジュールを管理したらコアも管理しなければならないことを警告しています。いまだに FTP でモジュールのフォルダをアップロードしている取引先は、いつかコントリビュートモジュールが依存していた vendor ディレクトリを消します。

composer.json と composer.lock がバージョン管理に入っているか、Composer が本番で動くのか、それともビルド成果物をデプロイするのかを尋ねてください。どちらの答えも正解になり得ます。答えがないことは正解になり得ません。

本番と一致するステージング環境

PHP のバージョンが違う、データベースのバージョンが違う、モジュールの構成が違うステージングサイトは、役に立つ何も検証しません。ステージングの意味は、セキュリティパッチをお金のかからないところで失敗させることにあり、それができるのは二つの環境が壊れる軸で一致している場合だけです。

ステージングを本番からどう、どれくらいの頻度で更新するのか、実データの匿名化した写しを持っているのかを尋ねてください。テスト用のノードが三つしかないステージングサイトでは、40,000 行にわたるビューを壊す更新は表に出ません。

設定をバージョン管理に置く

Drupal は既定で設定をデータベースに保持し 、設定管理の仕組みは、それをコミットでき、レビューでき、別の環境に取り込めるファイルへ書き出すために存在します。それを使っているチームはサイトの設定を決定的に再現できます。使っていないチームは、本番の管理画面をクリックしながら祈っています。

これは取引先との会話でもっともはっきりした信号です。ステージングで加えた変更が本番にどう届くのかを尋ねてください。答えが沈黙ではなく説明なら、残りの会話はたいてい問題ありません。

デプロイを説明できないなら、それが答え

これを丁寧に言う方法はありません。開発者の手元のマシンからあなたの本番サイトへコードがどう動くのかを、急がず一分で説明できない取引先は、デプロイが場当たりだと教えています。場当たりのデプロイこそ、セキュリティパッチが遅れる理由です。水曜の夕方に危なっかしい手作業を走らせたい人はいません。

誰も読まない解約時の条項

いつかあなたは取引先を替えます。その瞬間を律する条項は、全員が友好的なうちに書かれ、誰も友好的でないときに読まれます。そこには四つのことが平たく書かれているべきです。

カスタムモジュールとテーマの作業を含めてコードを誰が所有し、どのライセンスによるのか。リポジトリがどこにあり、アクセスがどう移るのか。データベース、ファイル、設定の完全な書き出しが、示された形式で、示された営業日数のうちに提供されること。そして DNS、ホスティング、第三者サービスの資格情報が抱え込まれずに引き渡されることです。

失敗の形はたいてい悪意ではありません。あなたのサイトを自社のアカウントで動かし、リポジトリの唯一の写しを持ち、あなたがもう支払う顧客ではないので返事に六週間かかる取引先です。署名する前に解約条項を求め、渋りを情報として扱ってください。

Drupal 7: サポート終了、延長サポート、そのあいだの隙間

Drupal 7 のセキュリティサポートは 2025年1月5日に終わりました 。コミュニティはパッチの生産をやめ、Drupal 7 を使えるものにしていた膨大なコントリビュートモジュールの生態系も、それに合わせて保守されなくなりました。

Drupal Association は Extended Security Support Provider Program を運営していて、HeroDevs と Tag1 Consulting がその認定ベンダーです。今年どうしても移行できない組織にとって、そのサポートを買うのは正当な判断で、何もしないよりは意味のある差があります。

それがしないのは、通常の意味でサイトを安全にすることです。商用ベンダーは、自分が見つけたか知らされた脆弱性を、自分の日程で、カバーすると合意したモジュール構成について修正します。公開のアドバイザリ手続きを取り戻すわけではなく、あなたがたまたま入れているすべてのコントリビュートモジュールを覆うわけでもなく、それらのモジュールが依存する外部ライブラリまで届くわけでもありません。延長サポートは、サポートのないプラットフォームを統制された形で動かす手段であって、サポート契約は安全であることの同義語ではありません。

2026年9月に Drupal 7 の上にいるなら、正直な助言は、家賃ではなく移行にお金を使うことです。2026年の Drupal ウェブ開発の手引き がいまのプラットフォームを扱い、アドバイザリ手続きの深い部分はDrupal のセキュリティ、アドバイザリと本当のリスク についての記事にあります。

コンテンツ支援と変更予算

境界を決めにくいという理由でサポート契約から押し出される項目が二つあり、どちらも顧客が実際に気づくものです。

コンテンツと編集の支援とは、コンテンツタイプを追加でき、絞り込みが効かなくなったビューを直せ、担当替えのあとに編集者を訓練し直せ、画像スタイルが顔を切っている理由を突き止められる人がいることです。派手さがなく頻度が高く、それのない保守契約は、尋ねるのをやめてサイトを迂回して仕事をする顧客を生みます。

変更予算はもう半分です。どのサイトにも小さな作業の待ち行列がたまります。フォームの項目ひとつ、ページを移したあとのリダイレクト、問い合わせを誰が受け取るかの変更。その待ち行列に月あたりの許容量を時間で名づけることが、四半期ごとの緊急プロジェクトへの変化を止めます。小さなサイトなら月に二時間から四時間、忙しいサイトなら八時間から十六時間が現実的な数字です。

英国での Drupal サポートの費用

以下の数字は、公開された調査ではなく英国の制作会社の仕事にもとづく 2026 年の当社の見積もりで、サポート受付の付いた監視サブスクリプションではなく、上に述べた八つの活動を行う取引先を前提にしています。

散文で言えば、小さなブローシャーサイトはおおよそ月 250 から 600 ポンドで、アドバイザリの監視、月次のパッチ周期、バックアップの検証、そして一、二時間の変更が買えます。外部連携のある中規模のサイトはおよそ 700 から 1,800 ポンドです。連携がひとつ増えるたびに、コアの更新のあとで再テストしなければならない回帰の面が増えるからです。カスタムモジュールを持つ複雑なサイトや多言語のサイトは 2,000 ポンド前後から始まり、6,000 ポンド以上に達します。

取引先がアドバイザリを見張って何が当てはまるかを伝えるだけで展開はしない監視のみの取り決めは、それより低くおよそ月 250 から 450 ポンドです。英国の制作会社の日単価 600 から 900 ポンドに対してその帯を置けば、1,500 ポンドの保守契約でエンジニア二日分に近いところが買えます。単価の詳細はDrupal 開発者の単価、技能、見極め についての記事に、より広い予算の見取り図はソフトウェア保守の費用 にあります。

サイトを一つ上の帯に押し上げるもの

本能はサポートをトラフィックで値付けすることですが、トラフィックはほとんど無関係です。モジュールが二十本で外部連携のない月間 20 万訪問のサイトは、CRM 連携と決済ゲートウェイとカスタム移行を持つ月間 2,000 訪問のサイトより支えるのが安上がりです。

実際に費用を動かすのは三つです。モジュール数。コントリビュートモジュールはひとつずつが見張るべきアドバイザリの流れであり、コアの更新のたびの互換性リスクだからです。外部連携の数。ひとつずつが自分の下で変わりうる外部との契約であり、やり直すべき回帰テストだからです。そして編集量。忙しい編集チームは、サポートの質問、権限の変更、コンテンツモデルの調整を一定の速さで生むからです。

カスタムコードは三つすべてにかかる掛け算です。カスタムモジュールのコードが 12,000 行あるサイトは、マイナーリリースのたびに非推奨の走査と回帰の通しが必要で、それは純粋にコントリビュートだけのサイトが負わない一日の作業です。上の帯はそこから来ていて、それは当社のソフトウェア開発 の案件がたいてい引き受けるよう求められる作業です。

見込みの取引先に尋ねるべきこと

六つの質問と、心配すべき答えです。

うちのサイトはいまどの Drupal バージョンとどの PHP バージョンで動いていて、アップグレードの経路はどうなりますか。調べに行く必要がある答えなら問題ありません。一週間後に届く答えは問題です。セキュリティアドバイザリがうちに当てはまるとどうやって知りますか。「drupal.org を監視しています」は弱く、サイトごとのモジュール台帳が欲しい答えです。

デプロイの手順を説明してください。ここでのためらいは会話全体でもっとも強い否定的な信号です。このサイトを最後にバックアップから復元したのはいつですか。「毎日バックアップを取っています」はその質問への応答ではありません。保守契約から何が除外され、何かが不具合か変更かをどう決めますか。そして最後に、私たちが離れるとき、何をどれくらいの速さで受け取れますか。

保守契約がないと何が起きるか

これは警告というより順序で、サポートのないどの Drupal サイトでもだいたい同じ速さで進みます。

最初の数か月は何も起きません。それが問題です。何も起きる必要がないと全員が学ぶからです。六か月目から十二か月目のどこかで、更新の滞留が、更新が個別に安全でなくなる点を越えます。あるモジュールが新しいコアを必要とし、それが新しい PHP を必要とし、ホストがそれを提供していないからです。パッチをひとつ当てることがプロジェクトになりました。

やがてサイトはプラットフォームのサポートから完全に外れ、ブラウザか PHP の変更が目に見える何かを壊します。修理はいまや誰も予算を取っていないアップグレードから始まり、緊急作業として見積もられ、文書のない部分は直されるのではなく作り直されます。その途中で侵害が起き個人データが関わるなら、ICO は 72 時間以内の通知を求めます 。人の権利と自由へのリスクを生じさせる可能性が高い場合に、それを知ってからの期限であり、持っているか持っていないかのどちらかであるログとバックアップで守る期限です。

復旧の請求書は、それを防いだはずの保守契約の何倍にもなるのが常で、その差は労力ではありません。計画された作業は火曜にロールバック手順とともに起き、緊急の作業は日曜にそれなしで起きるという差です。

署名する前にスコープを正しくする

ここまでの目的は、取引先を疑わせることではありません。二つの提案書の比較に意味を持たせることです。いまのところ、ほとんどの Drupal サポートの見積もりは設計からして比べられません。言葉が違い、除外が違い、毎月の作業が何かについての共通の定義がないからです。

八つの活動、Drupal のリスク区分、三つの保守契約モデル、六つの質問を取り、机の上にあるものにぶつけてください。それを生き延びたものが本物の提案です。

Mecanik はウェブサイト開発 とソフトウェア開発 の仕事の一部として Drupal のサイトを支えています。最初の案件はたいてい修理ではなく棚卸しです。当社のところへ来るサイトのほとんどが、自分のモジュールのどれがまだセキュリティアドバイザリのフィード の対象なのかを言えないからです。

よくある質問

Drupal の保守契約には何を含めるべきですか。 八つの活動です。あなたのモジュール構成に正確に当たるセキュリティアドバイザリの監視、決められた周期でのコアとコントリビュートモジュールの更新、依存関係と PHP プラットフォームのアップグレード、復元を試したバックアップの検証、稼働とアプリケーションエラーの監視、性能劣化のチェック、編集の支援、そして時間で示された変更予算です。四つしか挙げていない契約は不完全で、たいてい欠けるのは復元テスト、性能のチェック、プラットフォームのアップグレード、変更予算です。

英国での Drupal サポートの月額はいくらですか。 2026 年の当社の見積もりでは、小さなブローシャーサイトがおおよそ月 250 から 600 ポンド、外部連携が一つか二つある中規模のサイトが 700 から 1,800 ポンド、カスタムモジュールを持つ複雑な多言語サイトが 2,000 から 6,000 ポンドです。監視のみの取り決めは 250 から 450 ポンド前後になります。英国の制作会社の日単価 600 から 900 ポンドに対して、1,500 ポンドの保守契約はおよそエンジニア二日分です。

Drupal のセキュリティパッチはいつ公開されますか。 Drupal コアのセキュリティリリースは毎月第3水曜日の枠で出て、America/New York の 1200 に始まり、季節によって 1600 か 1700 UTC にあたります。コントリビュートプロジェクトには毎週水曜日のセキュリティリリース枠があります。きわめて重大なコアリリースの前には公開の予告が出るので、サイト所有者は事前に体制を組めます。

Drupal 7 の延長サポートは、安全であることと同じですか。 いいえ。Drupal 7 のセキュリティサポートは 2025年1月5日に終わり、Drupal Association は Extended Security Support Provider Program のもとで HeroDevs と Tag1 Consulting を認定しています。これらのベンダーは、カバーすると合意した範囲を、自分の日程で修正します。公開のアドバイザリ手続きを取り戻すことも、あなたが入れているすべてのコントリビュートモジュールを覆うことも、外部ライブラリまで届くこともありません。

Drupal 10 のサポート終了はいつですか。 Drupal 10 は 2026年12月9日にサポートを終了し、同じ週、12月7日から始まる週に Drupal 12 がリリースされます。11.3.x と 10.6.x のブランチのセキュリティサポートも同じ時点で終わります。Drupal 12 は PHP 8.5 のみをサポートするので、古い PHP のサイトはアップグレードの後ではなく前にホスティングの変更が必要です。