Drupal 12: 変わる点と移行のタイミング

Drupal 12 は 2026年12月7日の週にリリース予定で、Drupal 10 は 2026年12月9日にサポート終了を迎えます。どちらの日付も Drupal コアのリリーススケジュールという同じページに二行だけ離れて並んでいますが、Drupal 10 のサイトを動かしている人のほとんどはそのどちらにも気づいていません。新しいメジャーの最初のアルファは 2026年9月2日にタグ付けされているので、このリリースの姿はもう推測ではなく記録の問題です。

この衝突こそが話のすべてです。メジャーバージョンが出ること自体は、ふつうサイトの持ち主にとって緊急ではありません。エコシステムが追いつくまで一年か二年は前のメジャーに座っていられるからです。ところが今回は、新しい方が出るのと同じ週に前のメジャーがセキュリティ勧告を受け取らなくなります。技術的な出来事が、コンプライアンスの刃を帯びた締め切りに変わるということです。

以下では、drupal.org が公開しているカレンダー、コードで実際に変わること、新しいプラットフォーム要件がホスティングに強いること、費用帯を添えた現実的な三つのアップグレード経路、そして12月から逆算した計画を扱います。安心できる部分は先に来ます。Drupal のメジャーバージョン更新は、その大半が作り直しではなく削除です。

Drupal 12 はいつ出るのか、そして移行は必須なのか。 Drupal 12.0.0 は 2026年12月7日の週に、Drupal 11.5.0 と並んでリリースされる予定です。Drupal 10 はその二日後、2026年12月9日にサポート終了を迎え、以後そのためのセキュリティ勧告は一切出ません。Drupal 11 のサイトなら小さなアップグレードで済みます。Drupal 10 のサイトはまず Drupal 11.4 以降を通る必要があるため、作業は一段ではなく二段になります。

次の半年を決める二つの日付

リリースマネージャはサイクル全体を前もって公開しており、今回のものは珍しく整っています。Drupal 11.4.0 は 2026年6月29日の週に出て、その時点で Drupal 11.2.x と Drupal 10.5.x の両方のセキュリティサポートが終わりました。12.0.0-alpha1 のタグは 2026年9月2日に付いています。ベータ要件は 2026年9月11日までに満たす必要があり、12.0.0-beta1 と 11.5.0-beta1 が9月14日の週、リリース候補が11月9日の週という並びでした。

そして12月7日の週に三つのことが同時に起きます。Drupal 12.0.0 が出て、Drupal 11.5.0 が並んで出て、Drupal 11.3.x と Drupal 10.6.x の両方でセキュリティサポートが終わります。その二日後、2026年12月9日に Drupal 10 は全体としてサポート終了を迎え、以後そのリリースが作られることは一切ありません。

Drupal 10 と Drupal 12 が同じ週に重なる理由

これは偶然ではなく方針です。リリースプロセスの概要には、メジャーバージョンは偶数年に二年ごとに出ること、そして各メジャーはさらに二つのメジャーが出るまで最低四年間サポートされることが書かれています。Drupal 10.0.0 は 2022年12月15日に出ました。Drupal 11 は 2024年8月に、Drupal 12 は 2026年12月に出ます。後者がその「さらに二つ目のメジャー」であり、四年も経過しています。時計はきっかり予定どおりに鳴ったわけです。

同じ方針がマイナーも支配しています。各マイナーは一年間サポートされ、最初の半年はバグ修正とセキュリティ修正、後の半年はセキュリティ修正だけです。今日まだ勧告を受け取れるのが 10.6.x だけである理由も、11.5.0 が出た瞬間に 11.3.x が対象から外れる理由も、これで説明がつきます。

Drupal 11 は Drupal 12 が始まったところで止まるわけではありません。同じ週に 11.5.0 を出すことは、方針が長期サポート期と呼ぶ段階の始まりです。前のメジャーは API を合わせたマイナーを保ち、Symfony の LTS リリースへ移り、範囲を狭めながら半年ごとに保守マイナーを受け取ります。drupal.org は Drupal 11 のサポート終了日を確定的には公表していませんが、同サイトの非推奨拡張機能のドキュメントには、Drupal 11 は 2028年半ばから後半までサポートされると書かれています。

Drupal 10 に残っているサイトはどれだけあるか

数字は公開されていて、そして心地よくありません。drupal.org のコア利用統計によれば、2026年8月23日に始まる週にコアバージョンを報告したサイトは 468,877 件です。そのうち 205,568 件が Drupal 10 のいずれかのブランチ、168,857 件が Drupal 11 でした。報告済みインストールベースのおよそ 44 パーセントが、12月に勧告を受け取れなくなるバージョンの上に乗っています。

もっと鋭い数字はその内側にあります。まだセキュリティ対象なのは 10.6.x だけで、10.6.x はそのうち 139,911 件を占めます。残る 65,657 件は 10.0 から 10.5 の上にあり、つまり12月を待つまでもなく、この9月の時点ですでにサポート外のマイナーを動かしているということです。

この集計は Update Status モジュールを通じて自発的に報告したサイトから来ているので、実際の母数はもっと大きく、偏り方は同じです。実務的に読めば、非常に多くの組織が同じ四半期に同じアップグレード作業を入れようとするということであり、10月と11月の制約はコードではなく制作会社の空き枠になります。

サポート終了が Drupal サイトに実際もたらすこと

サポート終了はサイトを壊すスイッチではありません。あなたの Drupal 10 は 12月10日にも 12月8日とまったく同じようにページを返し続けます。変わるのは、Drupal セキュリティチームがそのコードについて勧告とパッチを出すのをやめることで、その日から Drupal 10 コアで新たに見つかる脆弱性はすべて永久に開いたままになります。

二つ目の影響はもっと遅く、もっと大きな傷を残します。コントリビュートモジュールのセキュリティ対象は、サポート中のコアブランチ向けの安定版があることに依存しています。メンテナが Drupal 10 対応を落としていくにつれて、あなたのサイトのモジュールも静かに勧告の枠組みから抜けていきます。そうなったという通知は届きません。モジュールがセキュリティリリースに現れなくなるだけで、自分のサイトの利用可能な更新レポートは緑のままです。

三つ目の影響は、待つほど出口が高くつくことです。11月にアップグレードされる Drupal 10 サイトは、保守されているコアブランチと機能する更新経路に対して作業されます。同じサイトを翌年6月にアップグレードすると、それは復旧プロジェクトになります。依存しているコントリビュートモジュールが、そのサイトを置き去りにしたまま半年余計に先へ進んでいるからです。

Cyber Essentials、保険、そして契約条項

ここが、サポート外の CMS が技術部門の心配事でなくなる地点です。NCSC の IT インフラ向け Cyber Essentials 要件 v3.3は、2026年4月付で、対象範囲の機器上のすべてのソフトウェアはライセンスされサポートされていなければならず、サポートが切れた時点で機器から取り除くか、インターネットとの通信をすべて遮断する定義済みのサブセットを用いて対象範囲から外さなければならないと定めています。この管理策はサーバ、IaaS、PaaS、SaaS に適用されるので、対象範囲のサーバ上の Drupal は真正面から含まれます。

公開されている Drupal 10 サイトをインターネットから遮断することはできません。したがって 2026年12月9日以降に取れる答えは二つ、アップグレードするか、その管理策を満たさないと認めるかです。組織が Cyber Essentials または Cyber Essentials Plus を保有して毎年更新しているなら、それは次の審査で書面で問われる質問になります。

それ以上のことを主張するのは慎重にしてください。特定のサイバー保険契約や顧客との契約が影響を受けるかどうかは、その文言に完全に依存します。効いてくる条項はふつう Drupal を名指しするものではなく、サポート対象のソフトウェアやベンダーがサポートするバージョンを求めるものです。事故のあとではなく12月より前に、自社の保険証券とマスターサービス契約を読んでください。安く済むのはそちらの時点です。

Drupal 12 で実際に違うところ

ほとんど何も違いません。それが正直で、しかも役に立つ答えです。12.0.0-alpha1 のリリースノートは率直に述べています。12.0.x は、非推奨コードが削除され、それも非推奨モジュールまるごとを含み、依存関係が新しいメジャーへ更新され、システム要件が引き上げられるという点を除けば、11.5.x とほぼ同一である、と。それ以外の変更については、11.5.x ブランチを読めと書かれています。

知っておく価値のある本物の挙動変更もいくつかあります。既定のパスワードハッシュアルゴリズムは argon2id に切り替わり、argon2 が使えない環境ではカーネルパラメータ経由で bcrypt を使えます。コアの robots.txt はクエリパラメータを伴う検索結果ページをブロックするようになり、検索エンジンが無限のファセット組み合わせを巡回するのを止めます。robots.txt をカスタマイズしているサイトは、その disallow 行を手で足す必要があります。コアがすでに同梱している HTMX は、beta1 でバージョン2からバージョン4に上がります。

もう一つ、見落としやすいものがあります。本番環境で Windows 上に Drupal を直接ホスティングすることが Drupal 12 で非推奨になりました。自動化された Windows テスト環境がなく、そこでテストしている開発者もほとんどいないという理由です。ローカル開発での Windows は引き続きサポートされます。本番を Windows で動かしているなら、これはコードの変更ではなく、この数か月のうちに下すホスティングの判断です。

コアを離れる拡張機能

Drupal は狭い用途のモジュールをコアからコントリビュートプロジェクトへ移す作業を何年も続けており、Drupal 12 もそれを続けます。alpha1 のノートは、Ban、Contact、Field Layout、History、Settings Tray、Shortcut、Telephone を削除対象として挙げ、Stable 9 テーマも同じだとしています。Text with Summary のフィールドプラグインも独自のコントリビュートモジュールへ移りました。Ban は 11.3 の時点で非推奨、Contact、Field Layout、History、Telephone は 11.4、Settings Tray、Shortcut、Text with Summary は 11.5 で非推奨になっています。

このうち二つは驚かれるはずです。Shortcut と Settings Tray は、非常に多くの編集チームが日々使いながら任意の機能だと考えたこともない管理機能で、とくに Settings Tray はコンテンツ編集者が頼っているブロックのその場設定を支えています。

一覧そのものより、扱い方の作法のほうが重要です。正しい手順は、モジュールをアンインストールすることではなく、アップグレードの前に Composer の要件へコントリビュート版を追加することです。アンインストールすると拡張機能の設定が壊れますし、Drupal のモジュール探索はコアを最後に見るので、コントリビュートプロジェクトがそこにあれば Drupal はそちらを使います。なお Drush は update.php の拡張機能欠落に関する警告を回避できてしまうため、失敗はあとからステータスレポートのエラーとして表面化します。

いちばん深く噛むのは Migrate Drupal を失うこと

Migrate Drupal と Migrate Drupal UI の両モジュールは Drupal 12 で削除されます。しかも他と違い、コントリビュートプロジェクトへ移されるわけではありません。Drupal 12 は Migrate API と現行 Drupal 向けのデスティネーションプラグインは保ちますが、Drupal 6 と Drupal 7 のソースプラグインは保ちません。

Drupal 7 のサイトを持っているなら、もう一度読んでください。レガシーな Drupal データベースを読んで現行の Drupal へ書き込むツールは、Drupal 11 には存在し、Drupal 12 には存在しません。drupal.org の指針は明確です。移行 API を使うつもりの Drupal 6 または Drupal 7 のサイトは、引き続き Drupal 11 へ移行し、そのうえで通常の更新手順で Drupal 11 から Drupal 12 へ進むこと、とされています。

これは漠然とした意図を、順序についての硬い制約へ変えます。Drupal 11 がサポート外になったあとに着地する Drupal 7 の作り直しは、自前のソースプラグインを書くか、使い捨て環境で古いコアを復元して移行を走らせるか、別の手段でコンテンツを書き出して入れ直すかのいずれかになります。三つとも、Drupal 11 が現行の保守された移行先であるうちに移行を済ませるより高くつきます。この作業の全体像は、Drupal 移行の費用、選択肢、期限の記事で詳しく扱っています。

新しい依存関係の下限

メジャーバージョンは Drupal がプラットフォーム要件を引き上げてよい場所であり、Drupal 12 はその許可を全面的に使っています。これらの下限は交渉の余地がない部分です。インストール時に強制されるからです。

PHP 8.5、それより古いものは不可

Drupal 12 は PHP 8.5 を要求します。PHP 要件の表では、Drupal 12.0 が PHP 8.5 をサポートしそれ未満をすべて拒否する一方、Drupal 11.3 と 11.4 は 8.3、8.4、8.5 を受け入れます。この重なりが移行経路です。Drupal 11.4 のままサイトを PHP 8.5 へ移し、挙動を確かめてから Drupal を変える、という順序になります。

この下限は罰というより余裕のあるものです。PHP 8.5 は 2025年11月20日にリリースされ、php.net のサポート対象バージョンのページはアクティブサポートを 2027年12月31日まで、セキュリティサポートを 2029年12月31日までとしています。ここに着地すれば、この会話を次にするまで三年の猶予が買えます。

データベースと Symfony

Drupal 12 のデータベースサーバ要件は、MySQL 8.0 以降、MariaDB 10.11 以降、PostgreSQL 18 以降、そして json1 拡張を備えた SQLite 3.45 です。PostgreSQL のサイトは、この下限をとくに慎重に確かめるべきです。alpha1 のリリースノートが PostgreSQL 19 と書いている一方で、要件ページとインストーラのコードはどちらも 18 と書いているからです。データベース作業を発注する前に、beta1 の時点でもう一度確かめてください。

その下では Symfony が 7.4 から 8.1 へ、Guzzle が 7 から 8 へ上がります。doctrine/lexer 2、egulias/email-validator 3、guzzlehttp/psr7 2 など、いくつかの古いライブラリのメジャーはサポート対象から外れます。Symfony のクラスを直接型指定しているカスタムコードが、これが表に出てくる場所です。

下限がホスティングに強いること

共用ホスティングや管理型ホスティングでつまずくのは MariaDB の引き上げです。Drupal 11 は MariaDB 10.6 を受け入れますが、MariaDB のメンテナンス方針によればそのコミュニティ保守は 2026年7月6日に終わっています。つまり Drupal 11 のサイトは、いま堂々とサポート外のデータベースエンジンの上に乗っていられるわけです。Drupal 12 は下限を 10.11 に上げ、こちらは 2028年2月16日まで保守されます。ホスティング事業者が今日 PHP 8.5 と MariaDB 10.11 を出せないなら、Drupal の移行より先にホスティングの移転をやる必要があり、この順序の入れ替えこそが二週間の仕事を二か月に変えるものです。プラットフォーム側については、Drupal を実際にうまく動かすものにまとめてあります。

非推奨モデルが Drupal 12 を扱いやすくしている理由

ここが、サイトの持ち主にほとんど説明されたことのない仕組みで、Drupal のメジャーがもう恐ろしくない理由でもあります。メジャーバージョン間の継続的アップグレード方針は、コアに単純な約束をさせています。次のメジャーリリースは、前のメジャーの最後のマイナーリリースと同じ公開 API を持つ、というものです。新しい API はマイナーで追加され、古い API はマイナーで非推奨と印を付けられ、削除はメジャーの境界でだけ起きます。

その実務的な帰結は、平たい言葉で述べる価値があります。あなたのカスタムコードとコントリビュートモジュールが Drupal 11.5 で非推奨警告なしに動くなら、それらは Drupal 12 でも動きます。アップグレードは書き直しではなくなり、依存関係の更新とデータベース更新に変わります。壊れたはずのものはすべて、何か月も前に、好きなときに直せる警告としてあなたに報告されていたからです。

リリースノートが先に 11.4 以降へ上げろと言い、11.5 を強く勧めているのもこのためです。11.4.0 より前のリリースからのデータベース更新経路は Drupal 12 から丸ごと削除されているので、11.3 以前のサイトには 11 のブランチを先に上がるまで 12 への道がありません。それは助言ではなく、コード経路の不在です。

非推奨を報告してくれるツール

仕事をするプロジェクトは二つあり、どちらも現在も保守されています。Upgrade Status はサイト全体のスキャナです。これはアップグレード先ではなくアップグレード元のサイトに入れます。呼び出しを見つけるには非推奨 API がそこに存在している必要があるからです。環境が次のメジャーのシステム要件を満たすかを確認し、コントリビュートプロジェクトを利用可能な更新と突き合わせ、非推奨の PHP API 利用について PHPStan を走らせ、Twig テンプレート、info.yml、composer.json、非推奨の設定キーを読みます。2026年7月2日のリリース 5.0.0-alpha3 は Drupal 10.4、11、12 との互換性を宣言しています。

見つけたものを分類してくれる点も、費用の面で効きます。問題は機械が直せるものと人が直さなければならないものに仕分けされるので、日付を約束する前に手作業の側を見積もれます。Drush では upgrade_status:analyze として動き、Code Climate 形式の JSON 出力は GitLab CI に差し込めます。

もう半分が Drupal Rector です。こちらはカスタムモジュールとテーマの中で機械的に直せる非推奨を書き換え、--dry-run フラグで差分を先に確認できます。バージョン 1.1.2 は 2026年8月7日にリリースされました。この二つを合わせれば、腕のある開発者は中規模サイトについて二日から三日で筋の通った準備状況レポートを作れます。

経路その一、Drupal 11 から Drupal 12 へ

Drupal 11.4 か 11.5 にいて、コントリビュートモジュールが最新なら、これは小さな作業です。公式アップグレードガイドの中身はほとんど Composer コマンドです。バージョン12のメタパッケージを --no-update で require し、明示的な drupal/core の要件があれば外し、composer update --dry-run を走らせ、それから本番で実行して drush updatedb でデータベース更新を当てます。

本当の作業はその前後にあります。前には、Upgrade Status を走らせ、実際に使っているコアの削除済み拡張機能についてコントリビュート版を足し、ホスティング事業者が PHP 8.5 を出せることを確かめます。後には、.htaccess を含むコアのスキャフォールドファイルがすべて変わっていることを見込んでおきます。それらに加えたカスタマイズは、盲目的にマージするのではなく意識して当て直す必要があります。

依存関係が解決を拒むときは、composer why-not drupal/core ^12 が原因を名指しします。composer.json でモジュールのメジャーを二つ許す書き方、たとえば "^6.1 || ^7.0" は、移行途中のプロジェクトを橋渡しする定番のやり方です。動くパッチはあるがタグ付きリリースがないモジュールが必要なら、Drupal Lenient Composer のエンドポイントがまさにそのために存在し、いまも保守されています。

経路その二、Drupal 10 から Drupal 12 は二段跳び

Drupal 10 から Drupal 12 への直接アップグレードはありません。Upgrade Status のドキュメントがそう明言していますし、11.4 より前のデータベース更新経路が削除されたことがそれを強制しています。Drupal 10.6 から Drupal 11.4 か 11.5 へ進み、サイトを検証し、そこから Drupal 12 へ進みます。

きちんと計画すれば、これは二倍の作業ではありません。Drupal 10 から Drupal 11 への段がリスクのほぼすべてを背負っています。コントリビュートモジュールの互換性問題が住んでいるのも、カスタムコードが削除済み API に出会うのもそこだからです。二段目は上で述べた小さいほうです。両方を一つの変更ウィンドウに押し込もうとするチームは、たいてい二つの段のどちらが何を壊したのか分からなくなります。

うまくいく順序は、Drupal 11 への段をいま済ませ、11.4 か 11.5 の上で数週間サイトを動かして実際の編集作業とトラフィックから異常を浮かび上がらせ、コントリビュートモジュールが Drupal 12 向けの安定版をタグ付けした年明けに Drupal 12 を取ることです。12月より前に一段目を済ませることが要点で、サポート外のコードから抜け出させるのがその段だからです。

経路その三、Drupal 7 や 8 はアップグレードではなく作り直し

Drupal 9 より古いものは別の作業です。Drupal 7 は 2025年1月5日に、Drupal 6 は 2016年2月にサポート終了を迎えました。どちらもその場ではまったくアップグレードできません。現代的なアーキテクチャよりも前のものだからです。これらは移行されます。つまり現行の Drupal で新しいサイトを作り、Migrate API でコンテンツをそこへ運びます。Drupal 8 のサイトには技術的にはその場での経路がありますが、四つのメジャーを連続して通り、すべてのコントリビュートモジュールがその一つ一つを生き延びなければならないので、ふつうは作り直しとして扱うほうが安く済みます。

費用を支配するのはコンテンツ以外のすべてです。テーマは作り直し、カスタムモジュールはまったく別の API に対して書き直し、外部連携はつなぎ直します。私たちの経験では、コンテンツ移行そのものはたいてい予算の小さいほうの半分で、見積もりを求める持ち主の予想とはちょうど逆です。これらをアップグレードではなくウェブサイト開発の案件として見積もる理由もそこにあります。

これらのサイトにとって12月の期限は違う効き方をしますが、Migrate Drupal の削除のせいでやはり効きます。目標は Drupal 12 ではなく Drupal 11 でなければならず、Drupal 11 は drupal.org 自身のドキュメントによれば 2028年半ばから後半までサポートされます。Drupal 7 の持ち主にはそれが本物の猶予を与えますが、終わりの決まった猶予です。2028年の目標に間に合わせるために2028年に半年の作り直しを始めるのは、計画とは呼べません。

各経路が英国でいくらかかるか

これらは公開料金ではなく、私たち自身の納品からの社内見積もりです。各帯の中の幅は、サイトの規模よりもコントリビュートモジュールの健康状態でほぼ決まります。英国の制作会社はこの種の作業に一日おおよそ 600 から 900 ポンドを請求します。手入れされたサイトでの Drupal 11 から 12 へのアップグレードはテストを含めて三日から八日で、2,000 から 6,000 ポンドあたりに着地します。同じサイトでもコントリビュートモジュールが古びていれば、二週間から四週間と 6,000 から 12,000 ポンドを見ておきます。

Drupal 10 のサイトは両方の段の費用を払います。よく手入れされていれば、Drupal 10 から 11 の段が 6,000 から 15,000 ポンド、Drupal 12 の段がさらに 2,000 から 6,000 ポンドで、四週間から八週間にわたって合計 8,000 から 21,000 ポンドです。放置されていれば一段目だけで 15,000 から 35,000 ポンドになり、合計は 17,000 から 41,000 ポンドの間に落ちます。Drupal 7 の作り直しは三か月から六か月、一般に 40,000 から 120,000 ポンドで、規模の大きいサイトや作り込みの多いサイトではそれ以上です。

日付を決めるのはコントリビュートモジュールの棚卸し

アップグレード案件がコアで死ぬことはめったにありません。死ぬのは一覧の十四番目、誰も入れた覚えのないモジュールで、次のメジャーに対応するリリースがなく、メンテナが最後にコメントしたのが2023年、というやつです。日付を約束する前にこの棚卸しをしてください。日付を生むのはこの棚卸しだからです。

Upgrade Status を走らせてレポートを書き出し、モジュールを四つの箱に仕分けます。一つ目は目標のメジャーに対応した安定版があるプロジェクトで、費用はかかりません。二つ目は課題キューにパッチか開発版があるプロジェクトで、少しの統合作業と、そのパッチが結局取り込まれないというリスクを伴います。三つ目は課題は立っているがパッチのないプロジェクトで、誰かが書く必要があります。四つ目はまったく動きのないプロジェクトです。

日程を決めるのは四つ目の箱で、その大きさは11月ではなく今日わかります。コントリビュートモジュールが三十あって四つ目の箱が空のサイトは、素直な案件です。同じサイトで四つ目の箱に四つ入っていれば、それは予算の違う別の案件であり、その二つの見積もりの差はスキャン一日分です。

放棄されたモジュールにどう対処するか

正直な選択肢は四つあり、正解はそのモジュールが何をしているかによります。提供している機能がもう使われていないなら、外す。数年ぶんの編集方針の変化のあとでは、チームが思うより高い頻度でこれが当てはまります。同じ仕事をする保守されたプロジェクトに置き換える。その場合は設定の移行が付いてくることを受け入れます。

保守を引き継ぐ。これは Drupal では現実的な選択肢で、聞こえるほど大変ではありません。drupal.org にはサポートされていないプロジェクトのメンテナになるための手順が文書化されていて、事業が依存している小さなモジュールなら、引き取るほうが置き換えるより安いこともあります。費用は一回きりではなく継続的なので、そこは正直に見込んでください。

あるいは、実際に使っている範囲に絞ったカスタムモジュールとして振る舞いを作り直す。コントリビュートモジュールは万人のために一般解を解いていますが、必要なのはたいていその狭い一切れです。その一切れを現行の API に対して実装し直すのは、二週間の移植に対して二日の仕事で済むことがよくあり、依存関係を恒久的に取り除けます。この種の判断ができる人をどう見極めるかは、Drupal 開発者の採用についての記事で扱っています。

2026年12月9日から逆算した工程表

終わりの日付から始めれば、計画は自然に書けます。9月下旬までに、本番のコピーに対して Drupal 12 向けの Upgrade Status を走らせ、四つの箱を紙の上に出します。これは二日から三日の作業で、ほかのすべてを正直に見積もれる唯一の成果物です。

10月半ばまでに、ホスティングが PHP 8.5 とデータベースの下限を出せるかを確かめ、出せないなら移転を始めます。コントリビュートモジュールについての判断もここで下します。どれにもリードタイムが付いているからです。11月初めまでに、Drupal 10 のサイトなら Drupal 11.4 か 11.5 へのアップグレードを完了させ、新しいブランチの上で本番を動かしている状態にします。

12月初めには、12.0.0 のリリースに反応するのではなく、それを眺めている側に回れます。その時点で Drupal 11 にいるなら、コントリビュートプロジェクトが Drupal 12 向けの安定版をタグ付けした2027年1月か2月に Drupal 12 を取ります。リリース週にアップグレードしても賞は出ませんし、Drupal 11.5 はその後もサポートされます。賞が出るのは、勧告が止まるときに Drupal 10 の上にいないことに対してです。

何もしない場合の費用

直接の費用は、2026年12月9日以降に公表される Drupal コアの脆弱性が、あなたのサイトで永久に開いたままになることです。Drupal の勧告の歴史には、公表から数時間で悪用されるほど深刻なリモートコード実行の問題が含まれていますし、公開 IP 上のパッチ未適用の CMS は、あなたを選んだ攻撃者ではなく自動スキャンに見つけられます。

間接的な費用のほうが早く来て、たいてい大きくなります。Cyber Essentials の審査でサポート対象ソフトウェアの管理策を満たせないと、その認証を必須とする契約の資格に影響しかねません。英国の公共調達ではそれはよくあることです。コントリビュートモジュールはあなたのブランチ向けの修正を出さなくなります。そしてアップグレードそのものが毎月高くなります。誰も何も触らないのに、コードベースと保守されたエコシステムとの隔たりが広がっていくからです。

もっと静かな費用もあります。誰もアップグレードを許されないサイトは、誰も変更を許されないサイトになりがちで、機能開発は止まります。どの変更も、消えていく API に対して作らなければならないからです。五年ものの Drupal サイトがアップグレードではなく作り直しになるのは、こうしてです。その判断を量っているなら、見積もりよりも私たちの Drupal 開発ガイドのほうが良い出発点です。

待つことが正当だと言える二つの理由

待つことが弁護できる状況は二つあり、意識して待つ場合に限ります。一つ目は、すでに Drupal 11.4 か 11.5 にいる場合です。これらのブランチはサポートされており、Drupal 12 のために用意された発射台であり、コントリビュートプロジェクトがまだリリースをタグ付けしている最初の数週間に真新しいメジャーを取る利点はありません。2027年の第一四半期まで待つのは、怠慢ではなくプロの選択です。

二つ目は、資金の付いた作り直しがすでに予定されている Drupal 7 のサイトです。Drupal 7 を Drupal 11 へ移行して、そのまま Drupal 12 へ入れるのは無駄な動きです。Drupal 11 に着地し、それを走らせ、Drupal 12 はあとから通常の保守として取ってください。

弁護できないのは、予約された計画のないまま Drupal 10 に座っていることです。それが自分だというなら、9月末までに最低限あるべきものは、スキャンレポート、名前の決まった目標ブランチ、そしてカレンダー上の日付です。ほかはすべて動かせます。その評価を一度やったことのある人にやってほしいなら、私たちのソフトウェア開発チームがバージョン監査を範囲固定の作業として引き受けます。

どこから始めるか

まずスキャンしてください。世の中の出来の悪い Drupal アップグレード見積もりのほぼすべてはスキャンなしに作られており、だからこそその多くが上にも下にも外れています。Upgrade Status と Drupal Rector の出力を二日から三日ぶん読めば、上の五つの費用帯のどれに実際にいるのかが分かります。そしてその一つの数字は、メジャーバージョンについての一般論をいくら並べるよりも、役員会との会話を変えます。

Mecanik はそうした監査と、その先のアップグレードを引き受けています。12月に直面している Drupal 10 のサイトでも、2027年に落ち着いた移行を計画している Drupal 11 のサイトでもです。カスタムモジュールの作業、外部連携、非推奨の片付けは私たちのソフトウェア開発部門が、作り直しやホスティングの移転はウェブサイト開発が引き受けます。この件が机に来た理由がセキュリティ体制なら、Drupal のセキュリティ勧告と実際のリスクから始めてください。バージョン移行中の自然検索流入が心配なら、Drupal の SEO 設定が守るべきものを扱っています。

よくある質問

Drupal 12 はいつリリースされ、Drupal 10 はいつサポート終了になりますか。 Drupal 12.0.0 は 2026年12月7日の週に Drupal 11.5.0 と並んでリリースされる予定で、Drupal 10 は 2026年12月9日にサポート終了を迎えます。どちらの日付も Drupal コアのリリーススケジュールで公開されています。同じ週に 11.3.x と 10.6.x のマイナーブランチでもセキュリティサポートが終わります。Drupal 12.0.0-alpha1 は 2026年9月2日にタグ付けされました。

Drupal 10 から Drupal 12 へ直接アップグレードできますか。 できません。Drupal 11.4.0 より前のリリースからのデータベース更新経路は Drupal 12 から削除されているため、Drupal 10 のサイトはまず Drupal 11.4 以降へ移り、そのあとで Drupal 12 へ進む必要があります。drupal.org はメジャー移行の前に 11.5.0 以上を勧めています。二段の作業として計画してください。リスクと費用のほぼすべては Drupal 10 から 11 の段が背負います。

Drupal 12 のシステム要件は何ですか。 Drupal 12 は PHP 8.5 を要求し、PHP 8.4 以前のサポートを打ち切ります。データベースの下限は MySQL 8.0、MariaDB 10.11、PostgreSQL 18、そして json1 拡張を備えた SQLite 3.45 です。Symfony は 8.1 へ、Guzzle は 8.0 へ上がります。本番環境で Windows 上に Drupal を直接ホスティングすることは非推奨ですが、ローカル開発での Windows は引き続きサポートされます。

Drupal 11.5 と比べて Drupal 12 は実際に何が新しいのですか。 設計上、ほとんど何もありません。alpha1 のリリースノートは、12.0.x が非推奨コードの削除、依存関係のメジャー更新、システム要件の引き上げを除けば 11.5.x とほぼ同一だと述べています。押さえておく価値のある挙動の変更は、既定のパスワードハッシュアルゴリズムが argon2id になること、HTMX がバージョン4へ上がること、そしてコアの robots.txt がクエリパラメータ付きの検索結果ページをブロックすることです。

英国で Drupal 12 のアップグレードはいくらかかりますか。 手入れされた Drupal 11 のサイトなら、英国の制作会社の標準的な単価である一日 600 から 900 ポンドで三日から八日ぶん、つまりおおよそ 2,000 から 6,000 ポンドです。Drupal 10 のサイトは両方の段の費用を払い、よく手入れされていれば 8,000 から 21,000 ポンド、放置されていれば 17,000 から 41,000 ポンドに落ちます。Drupal 7 の作り直しは三か月から六か月で、一般に 40,000 から 120,000 ポンドです。これらは公開料金ではなく社内見積もりです。