本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント等と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

Drupal の管理画面に「セキュリティーアップデートが入手可能です」の赤帯が出続けていることに気付き、状況を確認したところ、Automatic Updates モジュールは導入済みなのに自動適用が一切走っていない、という現象に遭遇しました。原因は単純で「cron 中の自動適用ポリシーがデフォルトで無効になっていた」だけだったのですが、モジュール名から動作を推測すると外す典型例だったので記録に残します。

観測した状況

サイトのバージョンは Drupal 10.6.3、最新は 10.6.7（同一マイナー内のセキュリティパッチ）。Automatic Updates モジュールは有効化済みで、ステータスレポートにも以下の通り「自動更新の準備完了」と表示されていました。

項目状態
Drupal core10.6.3（10.6.7 にセキュリティ更新あり）
Composer version2.6.5（要件 ^2.6 を満たす）
最後の Cron 実行数時間前（cron は走っている）
Update readiness checksYour site is ready for automatic updates.

cron も動いている、Composer も検出されている、readiness チェックも通っている。にもかかわらず自動更新が走らない、という状態でした。

期待値の整理

Automatic Updates モジュールの説明によれば、cron 実行時に 同一マイナーバージョン内のパッチレベル更新（例: 10.6.3 → 10.6.7）は自動適用される設計です。マイナーバージョンをまたぐ更新（例: 10.6.x → 10.7.x）は互換性リスクがあるため UI からの手動操作のみ対象になります。

今回の 10.6.3 → 10.6.7 は同一マイナー内のパッチ、しかもセキュリティ更新なので、本来なら cron 実行時に自動的に当たるはずのケースでした。

原因: cron 中の自動適用ポリシーが「無効」

/admin/config/automatic-updates を開くと、Unattended background updates（cron 中の自動適用ポリシー）に三択がありました。

  • 無効 ← これになっていた
  • Security updates only
  • All patch releases

「Automatic Updates」という名前から「入れたら自動で動く」と勘違いしていましたが、cron で何を適用するかは別途明示的にオンにする必要がある 仕様でした。デフォルトが「無効」なのは、勝手に更新が走って事故るより明示的にオプトインさせる方が安全、という設計判断として理解はできるものの、名前から動作を推測すると外す典型例です。

When background updates are applied, your site will be briefly put into maintenance mode. の説明書きが下に小さく書かれている通り、自動更新中はサイトが一時的にメンテナンスモードに入る副作用があり、これが「明示オプトイン」になっている主な理由と思われます。

対応手順

1. ポリシーを Security updates only に変更

セキュリティパッチだけ自動で当て、機能パッチは手動で確認したい運用に合うのがこの選択肢です。All patch releases はテスト環境を持たない単一サーバー運用だと稀に互換性問題で立ち上がらなくなるリスクがあるため、ステージング環境がない場合は避けたほうが無難です。

2. readiness check の再実行

設定保存後、画面に以下のメッセージが出ました。

Your site has not recently run an update readiness check. Rerun readiness checks now.

Automatic Updates は安全のため「直近の readiness check が成功していること」を自動適用の前提条件にしています。設定変更で状態が動いたので再走査が必要、という挙動です。リンクから再実行すると数秒で完了し、

No issues found. Your site is ready for automatic updates

になりました。

3. cron 実行（手動）

このサイトの cron 間隔は 3 時間ごとに設定されていたので、検証目的で /admin/config/system/cron から手動で「cron を実行」しました。バックアップ（DB と web/、vendor/ ディレクトリ）を取ってから実行するのが安全です。

4. 適用結果の確認

cron 実行後、ステータスレポートを確認すると Drupal バージョンが 10.6.3 から 10.6.7 に更新され、エラーは 0 件、Drupal コアの更新状況は「最新」表示になりました。セキュリティアップデートの赤帯エラーも消えました。

補足: 間の 10.6.4 10.6.5 10.6.6 はあったのか

10.6.3 から 10.6.7 まで一気にジャンプしたので、「間のバージョンは存在しなかったのか?」という疑問が湧きました。Drupal の「利用可能なアップデート」画面は、コア更新の場合 同一マイナー内のパッチ更新のみをインストール導線として案内する 仕様（マイナーまたぎは Composer 経由が必須）です。中間バージョンは更新案内として並ばないので、画面からは存在が見えにくくなっています。

公式のリリース一覧（drupal.org/project/drupal/releases）で確認したところ、10.6.x の系譜は以下のようになっていました。

バージョン種別ステータス
10.6.7セキュリティ更新最新（安全）
10.6.6バグ修正Insecure
10.6.5バグ修正Insecure
10.6.4バグ修正Insecure
10.6.3バグ修正Insecure（サイトが居た場所）
10.6.2バグ修正Insecure
10.6.1バグ修正Insecure
10.6.0マイナーリリース（新機能含む）Insecure

つまり間の 10.6.4 10.6.5 10.6.6 はすべて実在しており、サイトは 4 つ分のパッチ（バグ修正 3 + セキュリティ 1）を溜め込んでいた状態でした。Automatic Updates はそれを一気に 10.6.7 まで持っていったことになります。

「Insecure」タグが 10.6.2 〜 10.6.6 全部に付いているのは、10.6.7 で修正されたセキュリティ脆弱性が、それ以前のすべての 10.6.x に含まれている ことを示しています。バグ修正版（10.6.4 など）に「途中下車」してもセキュリティ上の意味はなく、結局は最新の 10.6.7 まで上げる必要がある構造です。Drupal の更新案内が中間バージョンを示さず最新だけを提示するのも、Automatic Updates が中間を経由せず最新へ直接ジャンプするのも、この事情と整合的です。Drupal 8 以降のパッチ番号は連番で振られている（Drupal 7 時代の偶数=バグ／奇数=セキュリティ といった慣習はない）ので、欠番もありません。

重要な注意: cron 自動更新は「公式サポート外」

ただし、自動適用が成功した直後のステータスレポートに、新しく警告が一つ出ます。

Cron installs updates automatically

Enabled. This is NOT an officially supported feature of the Automatic Updates module at this time. Use at your own risk.

要約すると、

  • 「cron で自動的に更新を当てる」機能は Automatic Updates モジュールの 正式サポート対象外
  • 「使うのは自己責任」と明記されている

つまり cron での無人更新は、Automatic Updates モジュール自身の文言としては experimental に近い扱いで提供されている、ということです。動作はしますし便利ですが、本番運用で想定外の挙動が起きた場合は自己責任で対処する前提が必要です。重要なサイトでは、

  • 直前にバックアップが自動取得される運用にしておく
  • メール通知を有効にして失敗を即時検知できるようにする
  • それでも不安なら手動運用（UI からの更新）に留める

といった備えを併用しておくのが現実的だと思います。この警告は導入時には目立たない場所にあり、有効化して初めて出てくるので、有効化するかどうかの判断材料として事前に知っておく価値があります。

なお、この「公式サポート対象外」という警告文は contrib 版 automatic_updates 3.1.x のソース（automatic_updates.install の hook_requirements）に由来します。一方で Drupal CMS 側のドキュメント configure-automatic-updates では cron 経由の無人更新が公式手順として案内されている ため、立場としては両義的です。今回触っているサイトは contrib 3.1.x を使っているのでこの警告がそのまま出ますが、Drupal CMS 文脈では同じ機能が「正規ルート」として扱われている、という温度差があります。記事中で「公式サポート外」と書いているのはあくまでこの contrib モジュールの自己申告に基づく表現で、Drupal プロジェクト全体としての方針を断じる意図ではない点だけ補足しておきます。

設定画面のもうひとつの選択肢: 実行方式

設定画面には How unattended updates should be run という項目もあり、自動更新の起動方法を二択から選べます。

  • By using the Automated Cron module or a request to /system/cron
    • Drupal の通常の cron に乗っかる方式
    • レンタルサーバーでも動く反面、PHP の max_execution_time に当たる可能性がある
  • By the auto-update command-line utility
    • サーバー側で CLI 経由で実行する方式
    • リクエストタイムアウトの制約を受けず、ユーザーアクセスに影響しない

レンタルサーバーで PHP リクエスト経由の cron に頼っている環境では、Composer の実行が長引くと中断される可能性があります。SSH で crontab を組める環境なら CLI 方式の方が安定すると思います。今回のサイトはレンタルサーバーで CLI cron が組みにくい環境だったため、/system/cron 方式のままにしました。

ハマりどころと学び

Automatic Updates「を入れる」と「が動く」は別

モジュール ON だけでは何も自動化されません。Unattended background updates を Security updates only 以上にして初めて意味を持ちます。同じように「入れたのに動かない」で悩んでいる場合、まず /admin/config/automatic-updates のポリシー設定を確認するのが近道です。

設定変更後は readiness check を再実行する必要がある

設定をいじった直後はチェック結果が古くなる扱いになり、自動適用は走りません。「環境が変わっているかもしれないのでもう一度確認させて」という安全側の挙動です。

マイナーバージョン更新は対象外

10.6.x → 10.7.x のようなマイナーアップは自動更新の対象ではなく、UI からの手動操作になります。「マイナーの境界では人間の判断を挟む」というポリシーは納得感があります。

Automatic Updates 自体がまだ進行中の取り組み

Automatic Updates と Package Manager は元々 contrib モジュールとして開発され、Drupal Association が統括する Auto Updates Initiative により Drupal コアへの統合が進められてきました。フェーズ 1 のメインスポンサーは欧州委員会（European Commission）で、Acquia / Tag1 Consulting / Mtech / Pantheon らがパートナーとして参加しています。

2026 年 5 月時点での状況を整理すると、

  • Package Manager: Drupal 11.2（2025-07）でコアに hidden experimental モジュールとして取り込まれ、11.3 でも experimental 継続中
  • Automatic Updates 本体: 依然 contrib モジュールとして提供（drupal/automatic_updates:^3）
  • Drupal CMS には Automatic Updates が同梱・有効化済み

つまり「Drupal コア標準機能になった」と言い切れる段階ではまだなく、通常の Drupal サイトでは contrib として導入する必要があります。stable 化・標準同梱のタイミングはバージョン次第なので、利用前に公式情報の確認をおすすめします。

まとめ

  • Automatic Updates モジュールは導入しただけでは何もしない
  • cron での自動適用は Unattended background updates の明示的なオプトインが必要
  • 設定変更後は readiness check の再実行が必要
  • 同一マイナー内パッチ更新のみが自動適用対象、マイナーまたぎは UI から手動
  • contrib automatic_updates 3.1.x は cron 無人更新を「サポート対象外」と自己申告するが、Drupal CMS 側では公式手順として案内されており立場は両義的

「インストール → ポリシー設定 → readiness check → cron」のパイプラインを意識して初めて自動適用が動き始めます。設定画面のチェックボックス一つの話ですが、ハマるとサイトが脆弱な状態のまま放置されることになるので、Drupal を運用している方は一度 /admin/config/automatic-updates の設定を確認してみると良いと思います。同時に「cron 自動更新は公式サポート外」という前提を踏まえた上で、バックアップやメール通知などの備えを併用するのが安心です。