CMSの画面でページに文章や画像を流し込み、公開できる状態に組み立てる。この作業をオーサリングと呼びます。AEMでページを1つ作るのに、どれだけの操作が必要でしょうか。コンポーネントを置き、プロパティを開き、画像を選び、リンク先を指定する。1ページにこうしたコンポーネントが数十個並ぶような複雑なページでは、その繰り返しだけで半日が過ぎることもあります。

この作業をAIエージェントに任せられないか。Adobeが提供するContent MCP Serverを使い、試してみました。公開中のページを取り込む、AEM内の複数ページをまとめて修正する、原稿から記事にする、逆にCMSの中身を読み出して文書にする。入力と出力の向きが異なる使い方を試した結果と、実際に使って見えてきたことを紹介します。

AEMのオーサリングは、なぜ手間がかかるのか

今回検証したページの一つには、42個のコンポーネント（見出し・本文・画像といった、ページを組み立てる部品の単位）が並ぶページがありました。1つずつの操作が難しいわけではありません。ただ、コンポーネントを選び、プロパティパネルを開き、値を入れて閉じる。この往復が数十回続きます。今回のような定型的なオーサリングにおいて、手間の大きな要因は、判断の難しさよりも操作の往復にあります。

同じ修正を複数ページに広げる場面では、この往復がページ数だけ増えることになります。リンク先の変更やフォルダ構成の見直しなどが、その典型です。

MCPとは。AIエージェントがAEMを直接操作する仕組み

こうしたオーサリング作業をAIに任せるためには、AIがAEMの中にあるページやコンポーネントを読み取り、必要な操作を実行できる仕組みが必要です。その役割を担うのが、今回利用したMCPサーバーです。

MCP（Model Context Protocol）とは、AIエージェントと外部システムをつなぐための共通仕様です。対応したサーバーを登録すると、エージェントがその機能を道具として呼び出すことができるようになります。

Adobeは、AEMのコンテンツを操作するMCPサーバーを提供しています。接続すると、Claude CodeなどのAIエージェントから、AEM内のページ一覧を取得したり、ページの構造を読み取ったり、内容を更新・公開したりできるようになります。

画面を自動操作するのではなく、APIを呼ぶ点が特徴で、画面操作を自動化する方法に比べて、画面のレイアウト変更などの影響を受けにくい仕組みです。

今回の環境では、サーバーのURLを登録し、Adobe IDでログインすることで接続できました。APIキーを発行して、配って、保管するといった段取りは必要ありませんでした。

Claude Codeでは、以下のコマンドでMCPサーバーを登録し、Adobe IDで認証しました。

claude mcp add --transport http aem-content https://mcp.adobeaemcloud.com/adobe/mcp/content

操作は、ログインしたアカウントの権限で行われます。

今回の検証環境（参考）

今回は、AEM as a Cloud ServiceとEdge Delivery Servicesを組み合わせたサイトで検証しました。AIエージェントにはClaude Codeを使用し、Adobe IDで認証しています。

検証対象は、トップページ、記事一覧、ヘッダー、フッター、共通パーツ3つ、コラム記事23ページの計30コンテンツです。

検証したのは2026年9月時点の仕様です。今回利用したContent MCP Serverは、早期アクセスへの申し込みなどは必要なく、ドキュメントに記載されたURLを登録してAdobe IDでログインすることで接続できました。コンテンツ操作には、AEMのリリースバージョン26309以降が必要です。

なお、この領域は仕様の更新が速く、2026年7月には複数の機能をまとめた統合AEM MCP Serverが提供され、現在はこちらの利用が推奨されています。最新の仕様については、Adobe公式の「Using MCP with AEM as a Cloud Service」をご確認ください。

【検証1】公開中のWebページをAEMへ移植する

まず、公開中の記事ページのURLを1件だけAIに渡し、その内容をAEM上にどこまで再現できるかを確かめました。指示したのは「このページをここにオーサリングして」という一文と、AEM上の作成先だけです。

指示を出してから公開が完了するまで、9分18秒でした。できあがったページは見出しレベル2（H2）が8つ、見出しレベル3（H3）が10個で、見出しの数も並び順も元の記事と完全に一致していました。段落や箇条書きまで数えると、本文には89個の要素が並ぶページです。本文中の図版3点とメインビジュアルも公開されているURLから取り込まれ、代替テキスト（ALT）も元の記事のまま正しく引き継がれていました。

特に違いを感じたのが、画像の扱いです。普段のオーサリングでは、アセット管理の画面に移って画像をアップロードし、ページに戻って配置するという作業が発生します。今回の検証では、この工程を人が行う必要はありませんでした。公開中の記事から画像を取得し、DAM（AEMが画像や動画を保管しておく場所）への取り込みからページへの配置まで、AIエージェントで処理が完結しました。

【検証2】複数の記事ページをまとめてAEMへ移植する

次に、検証1と同じ方法を複数の記事に広げたときの速さと安定性を確認しました。

AIに渡したのは、移植したい12件の記事ページのURLを並べたテキストファイルだけです。「このURLの内容をオーサリングして」と指示し、記事の構造を指定したデータ（マークダウン形式などの構造化データ）は渡していません。

AIエージェントはそれぞれのページを読み取り、見出し・本文・箇条書き・画像などを判別して、AEMのコンポーネントに割り当てました。ページ自体は、AEM上にある同じ構造の記事ページを複製し、本文やページ情報を差し替える方式としました。記事中の画像も、公開中のページから取得してDAMへ取り込みました。

12件の記事ページが43分で公開まで完了

12件の記事が、着手から公開まで43分で完了しました。1件あたりに換算すると3分35秒です。ページの作成から本文や画像の流し込み、公開までを含んだ時間です。非常に短い時間で処理できました。

今回対象とした記事には、1ページに最大42個のコンポーネントが並んでいました。同じ作業をAEMの画面から1件ずつ行う場合と比べ、大幅に作業を減らせる結果となりました。再現精度も高く、そのまま使える品質でした。

安定性の面では、同じ構造の記事ページを複製し、中身だけを差し替える方法が有効でした。ゼロからページ構造を組み立てるのではなく、すでにある型を使うことで、コンポーネントの種類や配置を誤る可能性を減らせます。

サイト移行という観点でも収穫がありました。一般的には、移行元のページを読み取り、その内容を新しいCMSのどの部品に当てはめるかを考える必要があります。今回の検証では、その作業の多くを、URLの一覧と指示だけでAIに任せることができました。

一方で、エラーへの対応には注意が必要でした。ページの複製時にタイムアウトが表示されたものの、AEM側では処理が完了していたケースがありました。そのまま再実行すると、同じページが重複して作成されてしまいました。エラーが表示されても、再実行する前にAEM側の状態を確認する必要があります。これも今回の検証で得られた知見の一つです。

複数ページのリンクや参照先をまとめて書き換える

もうひとつ、複数ページをまたいだ修正も試してみました。今回行ったのは、コンテンツが置いてあるフォルダ名の変更にともなう、リンクや参照先の書き換えです。これも運用ではよくあるケースです。

フォルダを移動しただけでは、各ページに設定されているリンク（内部リンク）や参照先のパスは、変更前のまま残ってしまいます。今回の検証では、7ページに58か所あり、トップページとフッターだけでも38か所ありました。これらをAIに指示し、まとめて書き換えてもらう狙いでした。

結果としては、一括置換の呼び出し1回で処理が完了しました。ただし、どこまでを書き換えるかには注意が必要でした。対象を広く指定しすぎると、画像の保存先まで書き換えてしまい、画像が表示されなくなるケースがありました。どこを変更し、どこを変更しないかという線引きは、人が決めてAIに指示する必要がありました。

とはいえ、今回のような複数ページをまたいだ修正では、作業時間を短縮できるだけでなく、修正漏れを減らせる点にも大きなメリットを感じました。

【検証3】Googleドキュメントの原稿から記事ページを作る

検証1では1件、検証2では複数件の公開済みWebページをもとに、AEM上の記事ページを作りました。次は、まだWebページになっていない原稿から記事ページを作れるかを試しました。

AIに渡したのは、Googleドキュメントから書き出した原稿ファイル1つだけです。原稿には、記事の目的や想定ターゲットといった記事の企画についての情報と、実際に掲載する本文とが混在していました。見出しの階層はドキュメント上の書式で表現され、図版の代替テキストとファイル名は表で指定されています。CMSへの入稿用に整えたデータではありません。

指示したのは「このファイルの内容をもとにオーサリングして」という一文と、AEM上の作成先だけです。

指示を出してから公開が完了するまで、6分20秒でした。
結果として、20個のコンポーネントからなる記事ページが無事に作成されました。H1が1つ、H2が3つ、H3が1つという見出しの階層は原稿どおりです。太字で書かれた「メンバーの感想：」のようなラベル、本文中の外部リンク、表で指定された代替テキストも、そのまま引き継がれました。読了目安も本文から自動で算出されました。

どの情報を記事として掲載するかという判断も、追加の指示なしで処理されました。企画情報は本文に含めない、原稿にない著者紹介や目次は追加しない、公開日はページの情報として設定する、といった処理が自動で行われました。

今回使用したのはお知らせ用の原稿で、コラム記事とは構成が異なりややシンプルなものではありました。それでも、見出し・本文・図版といった原稿の構造をAIが読み取り、AEMの適切なコンポーネントに割り当てることができました。CMSへの入稿用にデータを整えていなくても、原稿の構造を読み取って記事ページに反映できることが確認できました。

【検証4（特別編）】既存ページから設計書を復元する

最後は、これまでとは逆方向の使い方です。AEM上にある既存ページの構造をAIに読み取らせ、そこから設計書を作れるかを試しました。

AEMでは、ページの構造をJSON形式で取得できます。この情報とリポジトリ側の定義を照らし合わせることで、どのセクションにどのコンポーネントが配置され、どのような設定値が入っているのかを整理できます。

今回は3ページを対象に、オーサー画面に表示される設定項目と、実際に設定されている値を整理した簡易的な設計書を生成しました。引き継ぎ資料やCMSの操作マニュアルを作るイメージでおこなった検証でしたが、ベースとしては問題なく使える精度でした。

さらに、ページの構造を読み取る過程で、リンク先が存在しているか、見出しと遷移先が一致しているか、使われていない古い設定が残っていないかといった確認もできました。1ページずつ目視で確認するには手間がかかるため、設計書の作成だけでなく、既存サイトの棚卸しにも活用できそうです。

実際の運用で気をつけたいこと

ここまでの検証で、AIにオーサリングや修正作業を任せられることが確認できました。一方で、実際の運用に取り入れるには、誤った更新や公開を防ぐための仕組みも重要です。まず、AEM側に安全性を担保するための仕組みがどのように用意されているのかを整理します。

1. ほかの人の変更を意図せず上書きしにくい
   AIエージェントは、事前に読み取ったページの状態をもとに更新します。その際、ページの状態を表す識別子もあわせて確認しており、読み取った後に別の人が内容を変更して識別子が変わっている場合は、更新されない仕組みとなっています。そのため、ほかの担当者が先に編集した内容を、気づかず上書きしてしまう事故を防ぎやすくなっています。
2. 変更前の状態に戻せる
   AEMにはページのバージョン管理機能があり、必要に応じて以前の状態に戻すことができます。
3. 編集と公開を分けられる
   AEMでは、ページの編集と公開は別の操作になります。AIエージェントがページを書き換えただけでは、公開中のページには反映されません。そのため、AIが編集した内容を人が確認してから公開する運用とすることが可能です。

人の確認をどこに挟むか

AIに業務を任せるうえで重要になるのが、「どこで人が確認するか」です。今回は、AIエージェントに任せるのは下書きを作るところまでとし、公開前に人が確認するという線引きにしました。

AEMでは、オーサリングと公開が別の操作になっているため、AIエージェントが下書きを作成し、人がプレビューで内容を確認したうえで公開できます。この流れにすることで、AIが作成した内容をそのまま公開せず、人の確認を挟むことが可能になります。

今回の検証でも、人の判断が必要な場面はありました。どのページを対象にするか、一括置換をどの範囲まで行うか、そして最終的に公開してよいかどうかの判断です。AIに任せたのは実際の作業で、どこまで任せるかという線引きは人が決めるようにしました。範囲を決めずに任せてしまうと、意図しない箇所まで変更するといった問題につながる可能性があります。

権限とセキュリティ

MCP経由の操作は、認証したAEMユーザーの権限に従います。AIエージェントが操作できる範囲も、そのユーザーがAEM上で許可されている範囲に限られます。そのため、AIに何を任せるかに応じて、どの権限を持つアカウントで接続するかを設計することが重要です。

今回利用したContent MCP Serverには、書き込みができる/contentと、読み取り専用の/content-readonlyが用意されています。調査や既存コンテンツの確認など、書き込みが不要な用途では、必要以上の権限を与えないことも重要です。

なお、2026年9月時点では、/content-readonlyの一部ツールで書き込み操作が利用できる既知の問題がAdobeから案内されています。詳細はAdobeの「AEM as a Cloud Service: Prevent write operations on Content (read-only) MCP Server」をご確認ください。

また、コンテンツの変更や削除を伴う実務利用では、MCPツールを直接利用する際の注意点も示されています。利用する際は、Adobe公式の「Using MCP with AEM as a Cloud Service」も確認したうえで、運用方法をご検討ください。

今後さらに検証したいこと

今回の検証では、元になるページや原稿があるオーサリングを中心に、実務でも活用できそうな手応えを得ることができました。今後は、この結果がどこまで広げられるのかを検証していきたいと考えています。

まず試したいのが、元になるページや原稿がないケースです。ゼロから指示だけでページを組み立てた場合に、どこまでの精度が出るのかを確認する必要があります。

次に、扱うページ数を増やした場合です。今回は12件でしたが、100件、1000件と規模が大きくなっても同じ精度や品質を保てるのか。途中で処理に失敗した場合の復旧方法も含めて検証したいところです。

さらに、多言語展開やキャンペーン時の一斉切り替えなど、ページ単位ではなくサイト全体にまたがる作業にも活用できるのか。今後は、こうしたより大規模な運用についても検証していきます。

まとめ。元になるページや原稿があれば、オーサリングは任せられる

今回の検証は、いずれも「すでにあるもの」をAIに読み取らせるところから始まっています。公開中のWebページ、手元の原稿、AEM内のコンテンツなど、入力の形は違っても、もとになる情報がすでに存在している点は共通していました。

検証した範囲では、元になるページや原稿がある場合、AEMのオーサリングを実用的な水準でAIに任せられることが確認できました。1件のWebページで再現精度を確認し、12件に広げて処理速度と安定性を確認しました。さらに、原稿からの記事ページ作成や、AEM内の情報を読み取って設計書として整理する使い方も試すことができました。

うまくいった理由の一つは、AIに判断させる範囲を絞りやすかったからだと考えています。元になるものがあれば、何を掲載するのか、どのような順序にするのか、どの画像を使うのかといった情報の多くはすでに決まっています。AIに任せるのは、それらを読み取り、AEMのコンポーネントに当てはめていく作業が中心になります。今回の検証では、これまで人が繰り返していた操作の多くをAIに任せることができました。

変わるのは、作業時間だけではありません。これまでCMSに習熟した担当者が中心となって行っていたオーサリング（ページ作成）や横断的な修正、サイトの構造把握といった作業についても、AIと進められることが分かりました。一方で、どこまでを対象にするのか、どの内容を公開するのかといった判断は、引き続き人が担う必要があります。

サイトリニューアルにともなうコンテンツ移行、複数ページの一括修正、原稿からの記事化、引き継ぎ資料の整備。まずは元になる情報がある作業から、AEMのオーサリングにAIを取り入れていけそうです。

Business Architectsでは、AEMをはじめとするWebサイトの構築・運用にAIをどう取り入れられるのか、実際の業務を想定した検証を進めています。今後も、AIに任せられる作業と人が判断すべき領域を見極めながら、Webサイトの運用やコンテンツ制作に生成AIを活用する方法を検証し、その結果を発信していきます。