Drupal 11.4.0

2026年7月2日にDrupal 11.4.0がリリースされました。早速、使用中のDrupal 11.3.13からDrupal 11.4.0にアップデートします。

Install

dry-runで確認します。package informationを見るとsymfony7の機能が目立ちます。Drupal 11.xがsymfony7を採用しているので、symfonyのアップデートと11.4.0で新たに採用された、symfonyの機能のインストールになります。

$ composer update --dry-run
Loading composer repositories with package information
Updating dependencies
Lock file operations: 5 installs, 33 updates, 0 removals
  - Upgrading asm89/stack-cors (v2.3.0 => v2.4.0)
  - Upgrading consolidation/site-process (5.4.2 => 6.1.0)
  - Upgrading drupal/core (11.3.13 => 11.4.0)
  - Upgrading drupal/core-composer-scaffold (11.3.13 => 11.4.0)
  - Upgrading drupal/core-project-message (11.3.13 => 11.4.0)
  - Upgrading drupal/core-recommended (11.3.13 => 11.4.0)
  - Upgrading drush/drush (13.7.3 => 13.7.4)
  - Upgrading guzzlehttp/guzzle (7.12.3 => 7.13.1)
  - Locking justinrainbow/json-schema (6.8.2)
  - Upgrading laravel/prompts (v0.3.18 => v0.3.21)
  - Locking marc-mabe/php-enum (v4.7.2)
  - Upgrading php-tuf/composer-stager (v2.0.2 => v2.1.0)
  - Upgrading psy/psysh (v0.12.23 => v0.12.24)
  - Upgrading symfony/console (v7.4.13 => v7.4.14)
  - Upgrading symfony/dependency-injection (v7.4.13 => v7.4.14)
  - Upgrading symfony/deprecation-contracts (v3.7.0 => v3.7.1)
  - Upgrading symfony/error-handler (v7.4.8 => v7.4.14)
  - Upgrading symfony/event-dispatcher (v7.4.9 => v7.4.14)
  - Upgrading symfony/event-dispatcher-contracts (v3.7.0 => v3.7.1)
  - Upgrading symfony/finder (v7.4.8 => v7.4.14)
  - Upgrading symfony/http-foundation (v7.4.13 => v7.4.14)
  - Upgrading symfony/http-kernel (v7.4.13 => v7.4.14)
  - Upgrading symfony/mailer (v7.4.12 => v7.4.14)
  - Upgrading symfony/polyfill-intl-grapheme (v1.37.0 => v1.38.1)
  - Upgrading symfony/polyfill-intl-normalizer (v1.37.0 => v1.38.0)
  - Upgrading symfony/polyfill-mbstring (v1.37.0 => v1.38.2)
  - Upgrading symfony/polyfill-php84 (v1.37.0 => v1.38.1)
  - Upgrading symfony/polyfill-php85 (v1.37.0 => v1.38.1)
  - Locking symfony/polyfill-php86 (v1.38.0)
  - Locking symfony/runtime (v7.4.14)   // このプラグインがエラーの原因になります。
  - Upgrading symfony/serializer (v7.4.10 => v7.4.14)
  - Upgrading symfony/service-contracts (v3.7.0 => v3.7.1)
  - Upgrading symfony/translation-contracts (v3.7.0 => v3.7.1)
  - Upgrading symfony/validator (v7.4.10 => v7.4.14)
  - Upgrading symfony/var-dumper (v7.4.8 => v7.4.14)
  - Upgrading symfony/var-exporter (v7.4.9 => v7.4.14)
  - Upgrading symfony/yaml (v7.4.13 => v7.4.14)
  - Locking twig/html-extra (v3.24.0)
Installing dependencies from lock file (including require-dev)
Package operations: 5 installs, 33 updates, 0 removals
  - Installing symfony/runtime (v7.4.14)   // このプラグインがエラーの原因になります。
  - Upgrading drupal/core-composer-scaffold (11.3.13 => 11.4.0)
  - Upgrading drupal/core-project-message (11.3.13 => 11.4.0)
  - Upgrading symfony/polyfill-mbstring (v1.37.0 => v1.38.2)
  - Upgrading symfony/polyfill-intl-normalizer (v1.37.0 => v1.38.0)
  - Upgrading symfony/polyfill-intl-grapheme (v1.37.0 => v1.38.1)
  - Upgrading symfony/deprecation-contracts (v3.7.0 => v3.7.1)
  - Upgrading symfony/service-contracts (v3.7.0 => v3.7.1)
  - Upgrading symfony/console (v7.4.13 => v7.4.14)
  - Installing twig/html-extra (v3.24.0)
  - Upgrading symfony/yaml (v7.4.13 => v7.4.14)
  - Upgrading symfony/translation-contracts (v3.7.0 => v3.7.1)
  - Upgrading symfony/validator (v7.4.10 => v7.4.14)
  - Upgrading symfony/polyfill-php84 (v1.37.0 => v1.38.1)
  - Upgrading symfony/serializer (v7.4.10 => v7.4.14)
  - Upgrading symfony/http-foundation (v7.4.13 => v7.4.14)
  - Installing symfony/polyfill-php86 (v1.38.0)
  - Upgrading symfony/polyfill-php85 (v1.37.0 => v1.38.1)
  - Upgrading symfony/event-dispatcher-contracts (v3.7.0 => v3.7.1)
  - Upgrading symfony/event-dispatcher (v7.4.9 => v7.4.14)
  - Upgrading symfony/mailer (v7.4.12 => v7.4.14)
  - Upgrading symfony/var-dumper (v7.4.8 => v7.4.14)
  - Upgrading symfony/error-handler (v7.4.8 => v7.4.14)
  - Upgrading symfony/http-kernel (v7.4.13 => v7.4.14)
  - Upgrading symfony/finder (v7.4.8 => v7.4.14)
  - Upgrading symfony/var-exporter (v7.4.9 => v7.4.14)
  - Upgrading symfony/dependency-injection (v7.4.13 => v7.4.14)
  - Upgrading php-tuf/composer-stager (v2.0.2 => v2.1.0)
  - Installing marc-mabe/php-enum (v4.7.2)
  - Installing justinrainbow/json-schema (6.8.2)
  - Upgrading guzzlehttp/guzzle (7.12.3 => 7.13.1)
  - Upgrading asm89/stack-cors (v2.3.0 => v2.4.0)
  - Upgrading drupal/core (11.3.13 => 11.4.0)
  - Upgrading drupal/core-recommended (11.3.13 => 11.4.0)
  - Upgrading psy/psysh (v0.12.23 => v0.12.24)
  - Upgrading laravel/prompts (v0.3.18 => v0.3.21)
  - Upgrading consolidation/site-process (5.4.2 => 6.1.0)
  - Upgrading drush/drush (13.7.3 => 13.7.4)
45 packages you are using are looking for funding.
Use the composer fund command to find out more!
No security vulnerability advisories found.

dry-runによるチェックは問題なさそうなのでアップデートを行います。

$ composer update "drupal/core-*" --with-all-dependencies
---中略---
symfony/runtime contains a Composer plugin which is currently not in your allow-plugins config. See https://getcomposer.org/allow-plugins
Do you trust "symfony/runtime" to execute code and wish to enable it now? (writes "allow-plugins" to composer.json) [y,n,d,?] 
// yを選択
---中略---
45 packages you are using are looking for funding.
Use the composer fund command to find out more!
No security vulnerability advisories found.
// drush updatedb
// drush cr
を実行しアップデートは完了

無事アップデートが完了します。

Error

無事アップデートが完了したと考えていましたが、ブラウザを見ると公開サイトと管理画面に下記のエラーが出てしまいます。

Warning: require_once(autoload_runtime.php): Failed to open stream: No such file or directory in /your-server/.../public_html/your-domain/recommended-project/web/index.php on line 13 Fatal error: Uncaught Error: Failed opening required 'autoload_runtime.php' (include_path='.:/.../php-8.3.30/data/pear') in /your-server/.../public_html/your-domain/recommended-project/web/index.php:13 Stack trace: #0 {main} thrown in /your-server/.../public_html/your-domain/recommended-project/web/index.php on line 13

エラー内容は

/your-server/.../public_html/your-domain/recommended-project/web/index.php on line 13

/web/index.phpが読み込む、autoload_runtime.phpが見つからないとの事なので、探してみます。

autoload_runtime.phpは、vendor直下に生成されます。

/vendor$ ls -al
total 8
drwxr-xr-x 1 your-server-name name 496 Jul  4 02:17 .
drwxr-xr-x 1 your-server-name name 172 Jul  3 05:25 ..
drwxr-xr-x 1 your-server-name name  20 Jul  2 07:31 asm89
-rw-r--r-- 1 your-server-name name 748 Jul  2 07:31 autoload.php
drwxr-xr-x 1 your-server-name name 210 Jul  4 02:17 bin

autoload_runtime.phpは見当たりません。

原因を調べてみます。困った時のAIに聞いてみます。

Gemini

『このエラーは、Drupal 11.4.0から導入された新しい起動（ブートストラップ）の仕様が原因で発生しています。Drupal 11.4以降、内部でSymfonyの symfony/runtime コンポーネントを使用するようになり、index.php 内で autoload_runtime.php を読み込むコードに刷新されました。』

『通常、このファイルはComposerのプラグイン（symfony/runtime）によって自動生成されるべきものですが、環境やアップデートの手順によって生成がスキップされてしまっている状態です。』

autoload_runtime.phpが生成されるようsymfony/runtimeの再インストールを行います。

vendorとcomposer.lockを削除して再インストールしてみます。

// 古いファイルを完全に消去します。
$ rm -rf vendor composer.lock
// Composerの内部キャッシュをクリアします。
$ composer clear-cache
// プラグインの再許可
$ composer config allow-plugins.symfony/runtime true
// 再インストール
$ composer install

autoload_runtime.phpが生成されているか確認します。

/vendor$ ls -al
total 8
drwxr-xr-x 1 your-server-name name 496 Jul  4 02:17 .
drwxr-xr-x 1 your-server-name name 172 Jul  3 05:25 ..
drwxr-xr-x 1 your-server-name name  20 Jul  2 07:31 asm89
-rw-r--r-- 1 your-server-name name 748 Jul  2 07:31 autoload.php
-rw-r--r-- 1 your-server-name name 985 Jul  2 07:31 autoload_runtime.php // 無事生成されています。
drwxr-xr-x 1 your-server-name name 210 Jul  4 02:17 bin

autoload_runtime.phpが生成されているので、ブラウザを確認しますが、依然エラーは消えていません。再度Geminiに聞いてみます。

Gemini

『エラーが消えない場合、Drupal 11.4が自動で解決しようとしているパスの紐付けが、現在のサーバー環境とうまく噛み合っていない（include_path に vendor が追加されていない）状態です。』

『対処としてはweb/index.php の手動修正を適用するのが一番確実で手っ取り早いです！』

『※コアのファイルを直接書き換えることになるため、あくまで応急処置としてお考えください。』

// web/index.php 13行目
require_once 'autoload_runtime.php';
// 以下に変更
require_once __DIR__ . '/../vendor/autoload_runtime.php';
// 念の為、キャッシュのクリアをします。
$ drush cr
// Xserverのキャッシュとブラウザのキャッシュもクリアします。

提案に従い、web/index.php 13行目の修正を行います。『autoload_runtime.phpを絶対パスで記述することで対応します』。この対処により無事エラーが無くなり、公開サイトも管理画面も復旧しています。

Summary

今回のエラーが何故出てしまい、どう修復したかをまとめてみます。

Root Cause 1

Drupal 11.4.0から、Symfonyの起動システム（symfony/runtime）を組み込むというコアの仕組みが変わる大きな変更が入りました。普通に composer update を叩いただけだと、新しく追加されたComposerプラグイン（symfony/runtime）の実行許可（allow-plugins）が自動で有効にならず、ファイル生成がスキップされてしまいます。

• composer update でDrupal coreのアップデートをしたことで『autoload_runtime.php』が生成されず。
• vendorを削除し再インストール行うことで、autoload_runtime.phpが生成される。

Root Cause 2

本来、Drupal 11.4.0の設計では、index.php が読まれる前に ComposerがPHPの設定（include_path）を自動で書き換えて、vendor ディレクトリを検索対象に追加する という賢い仕組み（symfony/runtime の標準的な挙動）を期待しています。

しかし、一部のレンタルサーバー環境などでは、セキュリティ上の理由やPHPの実行方式（CGIモードやFPMの固有設定など）によって、「プログラム側から一時的に include_path を書き換える操作」が制限されているか、正しく引き継がれない ことがあります。

デフォルトのままだとサーバーが「パスをそのまま受け取りweb/ ディレクトリの中に autoload_runtime.php なんてファイルは無い？」と判断しエラーを出していたわけです。

• 環境により、インクルードパスが正しく動かなかったことが原因
• web/index.phpにautoload_runtime.phpの絶対パスを書き対応

が今回、Drupal 11.4.0のアップデートで発生したエラーと解決になります。

Notice

今回とったweb/index.php の直接修正は、今後のアップデート（ComposerのScaffold処理）で上書きされエラーが再発する可能性があります。

今後の対応は、Drupal Coreの開発での対応を待つか、対応がない場合以下の対応策が考えられます。

1. composer.json の extra.drupal-scaffold.excludes に web/index.php を追加して自動上書きを防ぐ『実現可能だが、今後のアップデートで上書きされない事で別の不具合を出す可能性あり』
2. サーバー側のPHP設定で include_path の制限を解除できるか確認し対応『Drupalの挙動に準拠するベストな選択だが環境による制限に左右されます。まさに今回の例』

制限の解除はインフラの変更が必要であったり、上書きを防ぐ対応のメリットデメリットを考えると、当面は、今回行った、都度状況に応じて対応する事が一番と考えています。

AI

今回、エラーが出たことで、AIに色々手伝ってもらい解決しています。現在、ClaudeとGeminiをメインにGPTも時折という形で使い分けています。

Claude

Claudeはエージェント型AIと言われ、仕事のルーティンを自動化したり、その応用で、プログラム開発や高度なデータ解析などを行う事ができます。専用アプリが用意され、ローカル上で動かせることと、ファイルのアクセス許可を行えることで処理の自動化や解析を行い、プロジェクトで必要な履歴や、変化する目的を必要に応じて、mdファイルに残してくれます。このことから、作業をルーティン化して効率よく進める利用に向いています。私は、ローカル上でWebサイト構築のモックなどを作るのに利用しています。

Gemini

GeminiはGoogle Work Spaceのものを使用しています。ブラウザを使い、Web上でのセッションになるので、Claudeのような、実作業は難しいのですが、他のAIBotより検索クローラーとそのノウハウで動くAIBotの情報収集能力の高さ、検索で培った、言葉の解釈や理解がLLMの推論に生きており、情報の速さや正確さ、意図の理解が優れています。ちょっとした質問やアイデアを膨らませたり、未知のものを自身のものに消化するきっかけを得るような形で利用しています。

適材適所で利用していますが、Geminiの凄さは、今回のケースのように、アップデートリリース当日に起きたエラーに対してもしっかり情報収集を行い（リリースから3時間程度で正規の情報はなく、一部のコミュニティでしか情報が公開されていないが、Geminiはしっかり必要な情報を収集済みで解決策の推論を組み立てています）、利用者に適切な処理を提案出来る能力は流石GoogleのAIと感銘を受けています。

Claude

逆に、今回のように、情報がまだ出回らないようなケースでは、エージェント型であるClaudeは情報そのもを持っておらず、集めるべき情報選定の甘さや判断の曖昧さが出てしまい、結果、解決に結びつかない提案をユーザーに押し付けるような挙動を示しています。Claudeは別作業では優秀ですが、今回のような、具体例がなく速効性が必要な案件より、じっくり腰を据えて、指示や結果が明快であるものの方がその能力を発揮できる事が確認できました。

この挙動についても、Claudeに尋ねたところ、AIの能力評価の基準にある、正しい答えを出すということが、今回のように、自身が出した回答の間違いを認めず、回答の表面的な正しさのみを整形してしまいユーザーの目的とかけ離れた結果を招いてしまう事が、AI開発の推論のロジックに関わる問題点の一つであるという認識を持っています。

自己の評価を冷静に行える事もClaudeの優秀さでもあります。（ただ、問題点を認識しながらもその間違いを犯してしまうという事が今回の問題ですが。。。）

AIの評価や認識は、優劣というより、何を相談し何を処理するか？により、選定するAIの特性を考え、柔軟に変える事が現時点でAI活用の一つの最善策であり、未知のエラーに対しても過去には考えられなかった早い対応につながるという事を認識した出来事でした。

Next

今回、Drupal 11.4.0のアップデートで出たエラーと修復について記事をまとめていますが、Drupal 11.4.0のアップデートにより、Civic Themeで使用するモジュールである、Search APIにもエラーが出てしまい修復しています。次回はこのSearch APIに出たエラーと修復をまとめていきます。