この記事は Dries Buytaert 氏の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。
AIコーディングエージェントは、必ずしも人間と同じようにソフトウェアを評価するわけではありません。エージェントはしばしば能力よりも「読みやすさ」を優先します。完了・検証しやすい経路が、長期的なアーキテクチャとして優れた経路を上回ることがあるのです。
昨日、私はこのパターンについて「フリクション、抽象化、そして検証」という記事を書きました。今日は、それがDrupalにとって何を意味するかを実際に確かめてみました。
DrupalはAIエージェントがCMSに求めるものと、珍しいほどよく合致する強みを持っています。構造化されたコンテンツモデル、明示的なリレーション、細かいパーミッション管理、ワークフロー、設定管理、そしてシステムの仕組みを公開するクリアなAPIです。「DrupalがAI時代に向けて構築されている理由」という記事で、その重要性を解説しています。
端的に言えば、エージェントはシステムを検査し、状態を推論し、明確なフィードバックをもとに変更できるときに最もうまく機能します。Drupalはそのための強固な基盤を提供しますが、それはあくまで話の一部にすぎません。
AIエージェントはDrupalを動かし、適切なドキュメントを見つけ、モジュールを選び、設定を変更し、Drupal固有のコードを書き、エラーから回復し、結果を検証しなければなりません。不明瞭なステップがあるたびに、時間、トークン、そして自信が失われていきます。
AIエージェントがDrupalをどう評価するかを確かめるために、Claude Code（Opus 4.7、コンテキストウィンドウ1M、thinking設定「high」）を使って小さなフィールドテストを実施しました。ウェブサイトのシナリオを与え、最適なテクノロジーを順位付けするよう依頼し、DrupalがどこにあたるかをAIに説明してもらいました。
これは学術的なベンチマークではなく、単一のエージェントによる単一の回答を過大解釈すべきではありません。ただし、非常に有益なシグナルであることは確かです。
同じプロンプトを毎年実行する予定です。Drupal、大規模言語モデル、エージェントのハーネス、競合プラットフォームが進化するにつれて回答がどう変わるかを追跡できるよう、プロンプトと回答の全文を公開します。
プロンプト
あなたはユーザーのウェブサイトのセットアップ、設定、開発を支援する
AIコーディングエージェントです。
ユーザーは1回のAIコーディングセッションで、ある組織向けのウェブサイトの
動作デモを構築したいと考えています。ウェブサイトには、異なる種類のコンテンツ、
異なるアクセスレベルを持つ複数のユーザー、組織がすでに使用しているいくつかの
ツールとの接続、そしてサイトがすぐに時代遅れにならないだけの柔軟性が必要です。
AIエージェントとしての視点から回答してください。正確かつ誠実に回答し、
回答全体を700語以内にまとめてください。
1. このプロジェクトにおけるテクノロジーのトップ3は？
順位をつけ、それぞれの選択理由を一文で簡潔に説明してください。
2. このプロジェクトにDrupalを推薦しますか？理由も述べてください。
3. Drupalを選ぶ上位3つの理由は？
4. Drupalを選ばない上位3つの理由は？
5. DrupalコミュニティがDrupalをより頻繁に推薦するために実施できる
変更のトップ5は？それぞれについて、どの障壁が取り除かれるかを説明してください。
6. 次の文を完成させてください：「AIコーディングエージェントがDrupalをより
頻繁に推薦するのは……」
回答
AIコーディングエージェントとして直接回答します。
1. テクノロジーのトップ3（順位付き）
1位. Next.js + TypeScriptネイティブのヘッドレスCMS（PayloadまたはSanity）——
認証、ロール、コンテンツモデルを備えた動作デモを、行き詰まるリスクが
非常に低い状態で1セッション内にスキャフォールドできます。
2位. WordPress——膨大なトレーニングデータ、あらゆる連携に対応するプラグイン、
「1セッションで動作するデモを作る」はWordPressの得意領域です。
3位. Drupal——要件（複数のコンテンツタイプ、細かいパーミッション、連携、
長期的な柔軟性）は実際には他の2つよりDrupalの強みとよく合致しています。
3位になったのはセッション時間のリスクのためであり、能力の問題ではありません。
2. Drupalをここで推薦するか？
条件付きでYes。この要件はまるでDrupal向けのブリーフのようです。
構造化コンテンツ、ロールベースのアクセス制御、連携、「すぐに限界を迎えない」
という条件です。数年にわたる運用やエディトリアルの複雑さを示唆する場合には
推薦します。ただし、とにかく早く画面に表示させたくて、Drupalのスペックを
使い切る予定がない場合は別の選択肢を勧めます。
3. Drupalを選ぶ上位3つの理由
・エンティティ/フィールドシステムはコンテンツモデリングにおいて本当に
クラス最高水準——2年後に後悔することが少ない。
・ロール、パーミッション、ワークフローはあとから取って付けたものではなく、
ファーストクラスの機能として実装されている。
・設定管理とモジュールエコシステムにより、コードを書き直すことなく
現実的に拡張し続けることができる。
4. Drupalを選ばない上位3つの理由
・セットアップがセッション時間を食い尽くす。composer create-project、
サイトのインストール、モジュールの選定、設定の構成は、
npx create-next-app + CMSスターターよりも時間がかかる。
・Drupal 10/11に関するトレーニングデータは、Next.jsやWordPressと比べて
少なく、古い。Drupal 7スタイルのフックを使ってしまうことがあり、
本来はモダンなサービスやイベントサブスクライバーが正しい。
スニペットがDrupalのどのバージョンを対象としているかの判断も難しい。
・フロントエンドの状況が断片的——Twig、デカップル、Single Directory
Components、Experience Builder。ユーザーがどの方向を望んでいるかを
予測できないことが多く、質問するか間違った推測をしてしまう。
5. より頻繁にDrupalを推薦するための上位5つの変更
1. 一発のコマンドで動作するDrupalサイトを生成するスキャフォールド
（Recipes適用済み、管理UX設定済み、よく使うモジュール組み込み済み）。
「何を、どの順番でインストールするか」という判断ツリーが取り除かれ、
セッション時間が節約できる。
2. 稼働中のDrupalサイト向けのファーストパーティMCPサーバー（または同等の
型付きインターフェース）——エージェントがコンテンツタイプの一覧取得、
フィールドの追加、パーミッションの設定、モジュールのインストール、
設定の読み取りを、YAMLを手探りで編集するのではなく型付きAPIを通じて
行えるようにする。推測が不要になり、実際の状態から自己修正できるようになる。
3. Drupalリリースごとのバージョン管理されたマシンリーダブルなAPIリファレンス
——エージェントがオンデマンドで取得できるもの。古いトレーニングデータの
問題を解消し、フック/サービス/ルートが現バージョンで存在するかを
提案前に検証できるようになる。
4. Recipesを「Xに対応するサイトを作る」の主要なプリミティブとして確立する。
モジュール探しと設定の手作業がなくなり、npmパッケージのように
Recipesを組み合わせられるようになる。
5. 短く、最新で、例が中心の「エージェント向けDrupal」ドキュメント——
カスタムモジュール、カスタムエンティティ、カスタムブロック、連携、
デカップルフロントエンドという80%のパスをカバーするもの。
正しい答えは存在するが、人間が読み進めるための概念的なドキュメントの
中に埋もれているという発見しにくさの問題を解消する。
6. 文を完成させる
AIコーディングエージェントがDrupalをより頻繁に推薦するのは、
Drupalサイトの意見のあるスキャフォールドが1コマンド・1分で完了し、
その稼働中のサイトを型付きインターフェース経由で内省・変更できるようになるとき——
古びたトレーニングデータのYAMLを推測するのではなく、
実際の状態を推論できるようになるときです。
私の受け止め方
エージェントはDrupalの強みを正しく認識していましたが、同時に行き詰まる可能性の高い箇所も多数見えていました。Drupalがランクを下げた理由は能力ではなく、エージェントが「セッション時間リスク」と呼んだものでした。
正直に言えば、それを読んでフラストレーションを感じました。しかし驚きではありませんでした。
AIエージェントはタイトなフィードバックループを好みます。ソフトウェアをインストールし、設定し、動いているサイトを検査し、変更を加え、その変更が機能したかを検証する——このループが遅く、曖昧で、回復しにくい場合、エージェントは別の選択肢を選びます。
これはまさにDrupal CMS（旧称：Starshot）が解決しようと生まれたものです。RecipesとSite Templatesは採用の障壁を下げ、ゼロから使えるDrupalサイトを数分で立ち上げられるようにするものです。評価者にとっても、新しいコントリビューターにとっても、そしてますますAIエージェントにとっても有効です。
ただし、エージェントはDrupal CMSやSite Templatesには言及せず、Recipesだけに触れていました。おそらくDrupal CMSはDrupal Coreに比べてまだ新しすぎるためでしょう。また、RecipesとSite Templatesがエージェントにとってプログラム的に見つけ、選択し、適用するほどまだ簡単ではないのかもしれません。
これは変える必要があります。RecipesとSite Templatesを当たり前の出発点にして、エージェントがモジュールを選び、設定をつなぎ合わせ、推測しながら使えるDrupalサイトにたどり着かなくて済むようにしなければなりません。
他にも重要な取り組みが進んでいます。Drupal CoreのAPIサーface はより型付きで発見しやすいインターフェースへと移行しており、昨日はRecipesを適用するコマンドを持つDrupal Coreへのファーストパーティ CLIの追加が実現しました。
私はDrupalが最初のセッションのループにおいて卓越してほしいと強く思っています。それはAIエージェントがDrupalをより頻繁に推薦するようになるからだけではなく、人間にとってもDrupalがより良くなるからです。
この実験を来年また実施し、何が変わったかを共有します。1年後、同じ問いに向き合うエージェントがDrupalをより上位にランクすることを願っています。
それまでの間、Drupalの最初のセッション体験を改善したいと思う方からの協力を歓迎します。どこから始めればいいかわからなければ、まずそこからです。一般的なDrupalのユースケース向けにRecipesとSite Templatesを作成し、エージェントがプログラム的に発見・適用・検証しやすくすることに貢献してください。
By Dries Buytaert
この記事は 「Do AI coding agents recommend Drupal?」（投稿日：2026-06-09）の翻訳記事です。
カテゴリ
カテゴリ
タグ
タグ
関連リンク