エージェント型ワークフローにおけるDrupalの役割

この記事は Dries Buytaert 氏の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。

AIワークフローにおけるDrupalの未来には2つの側面があります。Drupal内でAIを使って人を支援することと、外部からエージェントやワークフローツールがDrupalを活用できるようにすることです。

2025年6月にDrupal AIイニシアチブに取り組み始めたとき、AIの機能のほとんどはDrupalの内部に置かれるものだと想定していました。

2026年3月のDrupalCon Chicagoキーノートでは、その考えが変わっていました。「内から外へ」対「外から内へ」というフレームでこの転換を整理し、すべてのAI機能がDrupalの内部に属するわけではないという結論に至りました。AIツールがより速く動き、必要なときにDrupalへ接続できる、CMSの外で行ったほうが良い仕事もあるということです。

先週、「AIとCMSの大アンバンドリング」でこれらのアイデアをより詳しく掘り下げました。あの記事では、AIはCMSを制作ツールとして見ると中心的な存在ではなくなる一方、コントロールレイヤー——コンテンツが構造化・統治・再利用され、信頼を持って公開される場所——としてより重要になると論じました。

この記事はその続きです。コントロールレイヤーとしてのDrupalの役割がより重要になるなら、Drupal内で動くAI駆動のワークフロー、Drupalの外から始まるワークフロー、そしてその両方にまたがるワークフローをサポートする必要があります。つまり、Drupalを呼び出す外部ワークフローと、外部システムが安全に依存できるDrupalネイティブワークフローです。

DrupalがCMSを超えたワークフローに参加する

まず、DrupalはCMSの外のツールとうまく連携する必要があります。Claude CodeやCursorのようなコーディングエージェント、そしてSalesforce Agentforce、n8n、Activepiecesのようなオーケストレーションプラットフォームとです。

2025年10月のDrupalCon Viennaキーノートでは、その姿を実際にお見せしました。その短いクリップはこちらです：

概念実証のデモで、楽しい仕掛けも入れました。しかし、デモそのものよりもその背後にあるパターンの方が重要でした。外部ツールが作業を主導してDrupalにタスクを渡し、DrupalはStructuredコンテンツと状態を返す、というパターンです。

このデモを見れば、同じパターンが実際のマーケティングユースケースでも使えると容易に想像できます。キャンペーンは通常マーケティングブリーフから始まり、メール、ウェブサイトのランディングページ、ソーシャルメディア、有料広告など、多くのツールとチャネルにまたがります。

外部のエージェントプラットフォームがキャンペーンのコピーを生成し、Drupalにランディングページの構築を依頼することができます。Drupalはコピーを適切な構造化コンテンツタイプにマッピングし、Drupal Canvasで承認済みのコンポーネントに配置し、下書きとして保存し、公開前に不足しているフィールド・メタデータ・翻訳を示すことができます。

Drupalがヒーロー画像の不足を報告したら、エージェントプラットフォームはデジタルアセット管理システム（DAM）を検索し、承認済みのキャンペーン画像を見つけて渡すことができます。DrupalはそれをメディアモデルでアタッチしてAltテキストを付与・検証し、ページが要件を満たしていることを確認し、編集ワークフローを通じて下書きを進めることができます。

これはDrupalがうまくサポートする必要があるパターンです。外部プラットフォームがより広いデジタルスタック全体で作業を調整できますが、コンテンツを組み立て・検証・統治・公開するシステムはDrupalであり続けるべきです。

外部ワークフローがDrupalネイティブワークフローを呼び出す

より大きなキャンペーンワークフローはDrupalの外に置かれるかもしれませんが、Drupalネイティブワークフローにも同様に重要なケースがあります。

外部エージェントはシステム間の作業調整が得意です。しかし、ワークフローがDrupalのコンテンツやデータに対して処理を行う必要が生じたとき、Drupalの外でそれを再現するのではなく、Drupalネイティブのコンテンツモデル・パーミッション・バリデーションルール・モデレーション状態・リビジョン・公開ワークフローを使うべきです。

そこでECA、FlowDrop、Maestroといったプロジェクトがより重要になります。これらはDrupalがサイト固有のプロセスを、外部システムが呼び出せる繰り返し可能なマルチステップワークフローに変えることを可能にします。

たとえば、これら3つのシステムのいずれかが、下書きの検証・5言語への翻訳調整・レビュアーへのアサイン・必要な承認がすべて揃った後にのみコンテンツを公開するという、単一のDrupalワークフローを動かすことができます。

タスクに応じて、これらの内部Drupalワークフローは決定論的なもの、AI支援のもの、または完全にエージェント的なものにすることができます。Drupalは今日それをサポートしています。

外部エージェントがDrupalをフィールドごと・関数ごとに外から操作する必要はありません。単一の外部APIコールを通じてDrupalネイティブワークフローの実行をDrupalに依頼できるべきなのです。

それが上記のデモ動画でお見せしたもう半分です。Drupalはただコンテンツをエージェントへ露出させるだけでなく、外部オートメーションツールが呼び出せるカスタムのDrupalネイティブECAワークフローも公開していました。

昨秋のDrupalCon Viennaでも強力でしたが、エージェント型ワークフローが一般的になるにつれて、このパターンの重要性はますます高まるでしょう。

最高のエンドツーエンド体験が勝つ

何をどこに置くべきかという議論に陥りがちです。AIはDrupalの内部で行われるべきか、外部で行われるべきか？ワークフローはDrupalネイティブであるべきか、外部プラットフォームで管理されるべきか？

これらは有益な問いですが、答えは普遍的ではありません。AIとワークフローは、最高のエンドツーエンド体験を生み出せる場所に置かれるべきです。それがDrupalの内側になることも、外側になることも、多くの場合はその両方にまたがることもあるでしょう。

「最高」が何を意味するかは、ユースケース・ユーザー・スピード・信頼性・セキュリティ・ガバナンス・コスト・人によるレビューの要件によって異なります。ベストプラクティスはあるでしょうが、すべてのケースに当てはまる唯一のアプローチはありません。

誰が作業するかによって「最高」の姿は変わります：

• 開発者はClaude Codeのような外部コーディングエージェントを好むかもしれません。
• マーケターは、プレビュー・翻訳・モデレーション・公開に近い場所にいられるDrupalネイティブな体験を好むかもしれません。
• キャンペーンマネージャーは、メール・ソーシャルメディア・アナリティクス・DAM・CMSを調整する外部ワークフローを必要とするかもしれません。

作業はシステムと人をまたいで移動します。最高のエンドツーエンド体験は、各ステップを最もうまくできる場所で行いながら、引き継ぎを見えないものにすることで生まれます。

先行優位はそのまま勝利の計画にはならない

これらの未来のワークフローにおけるDrupalの役割を理解することで、Drupalが向かうべき方向が明確になります。Drupalは外部オーケストレーション・Drupalネイティブワークフロー・その両方を組み合わせた現実のハイブリッドをよりうまくサポートする必要があります。

Drupalが興味深いのは、これらのワークフローが必要とする地味で難しいインフラをすでに多く備えていることです。構造化コンテンツ・細かいパーミッション・リビジョン・ロールバック・JSON:API、そして他にも多くのものがあります。これらはまさにエージェントが必要とする機能であり、一から構築するのも後付けするのも本当に難しいものです。

概念的な明確さと強固な基盤は素晴らしいものですが、勝つためにそれだけでは十分ではありません。

AIコーディングエージェントがDrupalを推薦するかどうかを検証したとき、問題はDrupalの能力ではありませんでした。エージェントがプロンプトから動作するDrupalサイトに十分速く・簡単にたどり着けるかどうかでした。「フリクション、抽象化、そして検証」で書いたように、エージェントは最も少ないフリクションで実際に検証された結果に至る経路を選ぶ傾向があります。

経験豊富なDrupalチームにとって、課題は違います。彼らはすでにDrupalを選んでいます。エージェントにDrupalを推薦してもらう必要はありません。より速く構築・検証・リリースできるように助けるエージェントが必要なのです。

DrupalのアドバンテージをAdoptionに変えるためには、両方の経路を改善する必要があります。新規構築でエージェントがDrupalを選ぶようにすることと、既存のDrupalチームがより良い仕事をより速く出せるようにすることです。どちらも、エージェントが最初から最後までDrupalとより簡単に作業できるようにすることにかかっています。

つまり、Drupalはエージェントが正しいアクションを取り、結果を検証するために必要なベストプラクティス・サイトコンテキスト・ツール定義・制約・精密なバリデーションを公開する必要があります。

このうちの多くは、Recipes・Site Templates・Drupal AI・Drupal Canvas・ECA・FlowDrop・Maestro・MCP・CLIの改善など、すでにさまざまなプロジェクトで進行中です。

しかし目標はどれか一つのプロジェクトよりも大きいものです。Drupalはこれらの取り組みが積み重なって、エージェントにとって明確で調整された経路になる必要があります。セットアップから接続・コンテキスト・統治されたアクション・検証・リカバリー・ローンチまでの一本道です。

このブログ投稿のレビューと貢献をしてくれたJames Abrahams、Jürgen Haas、Randy Kolenko、Scott Falconer、Shibin Dasに特別な感謝を。

By Dries Buytaert

この記事は 「Drupal's role in agentic workflows」（投稿日：2026-06-23）の翻訳記事です。