AEM as a Cloud Serviceへの最適化ロードマップ｜成功へ導く事前調査

企業のWeb戦略において、常に最新の機能を利用でき、インフラの保守負荷から解放されるAEM as a Cloud Service（以下、AEMaaCS）への注目がこれまで以上に高まっています。

しかし、AEMaaCSの持つ強力なポテンシャル（自動スケール、継続的なアップデート、強固なセキュリティなど）を最大限に活かすためには、単に既存のコードやコンテンツをそのまま「引っ越し」させるだけでは不十分です。結論から言えば、AEMaaCSへの刷新を成功させる鍵は、プロジェクトの初期フェーズに行う「徹底的な事前調査」にあります。

Web基盤担当者やDX推進担当者から見ると、AEMaaCSへの移行はスムーズに進むように思えるかもしれません。しかし、長年改修を重ねてきたAEM環境には、過去のレガシーコードや使われていない膨大なアセットなど、多くのブラックボックスが潜んでいます。これらを残したまま移行を進めると、AEMaaCS固有の厳格なモダンアーキテクチャと衝突し、ビルドエラーや本番直前の手戻りを引き起こす原因になります。

この記事では、AEMaaCSの本質的な価値を活かすために、なぜ「事前調査」のステップが不可欠なのか、その具体的なアプローチを解説します。

AEM as a Cloud Serviceが求める「前提の変化」

AEMaaCSは、クラウドネイティブに再設計されたWebコンテンツ管理（CMS）基盤です。オンプレミス版AEM 6.xで許容されていた運用の「柔軟さ（グレーゾーン）」が、AEMaaCSでは最新のクラウド標準仕様へと統一されます。

オンプレAEMの延長で考えると何がずれるのか

オンプレミス版AEM 6.xでは、企業ごとにサーバー構成やデプロイ手順、運用ルールを柔軟に変えることができました。

• 緊急時に本番サーバーへ直接パッケージをインストールして修正する
• CRXDE Liteを使って本番環境のノードを手作業で書き換える
• 運用チーム独自のシェルスクリプトをサーバー内で直接実行する

こうした、いわゆる「個別のサーバー運用」は、AEMaaCSでは実施できません。

また、AEMaaCSではリポジトリ構造も「変更可能な領域」と「変更不可能な領域」に分離されます。

成功へのファーストステップ：「事前調査」

AEMaaCSへの道を安全に進めるために、プロジェクトの最初期に配置すべき2つの重要なステップが「事前調査」です。

ステップ①：Best Practices Analyzer（BPA）

Adobeは、現行のオンプレミス環境がAEMaaCSの制約にどの程度適合しているかを測定する公式ツール Best Practices Analyzer (BPA) を提供しています。これを現行環境に導入してスキャンをかけることで、以下のような課題がレポートとして自動抽出されます。

• 非推奨・削除されたAPIの使用（例：旧式の検索クエリや、Adobe内部APIへの直接依存）
• 無効なJCRリポジトリ構造（/apps 以外の場所にコードが配置されているなど）
• 互換性のないカスタムサーブレットやOSGi設定 

このBPAレポートを精査することで、エラーが何件あり、どれが重大な修正を要するのかをあらかじめ可視化することで、後半の工程で予期せぬトラブルに遭遇するリスクをゼロに近づけることができます。

ステップ②：コンテンツデータやソースコードの資産棚卸し

長年運用されたAEM環境には、以下のような移すべきではない資産が大量に溜まっています。

• 数年前のキャンペーン用の古いテンプレートや独自コンポーネント
• 既に使われていない期限切れの巨大なPDFや画像アセット
• 過去の担当者の古い権限設定や、形骸化した承認ワークフロー

これらを何もせずにAEMaaCSへ全量移行しようとすると、移行データ量が膨れ上がり、本番切り替え時のコンテンツ凍結期間（ダウンタイム）が無駄に長期化します。また、移行後もクラウドのストレージや検索インデックスに余計な負荷をかけ続けることになります。「何を移行し、何を捨てるか」の棚卸しルールを、初期段階で策定することが極めて重要です。

◼︎関連資料：

既存資産（コンポーネント）の評価・仕分け基準

事前調査を経て課題が見つかった既存コンポーネントを、AEMaaCSへどのように適応させるかの仕分け基準をあらかじめ決めておきます。すべてを作り直す必要はありませんが、問題を抱えた実装をそのまま持ち込むのも危険です。

[既存コンポーネントの仕分けフロー]

   │

   ├─► 利用頻度・ビジネス影響度が【高い】

   │     ├─ 現行実装のままで移行可能 ───► 【1. 継続利用】(最小限の修正)

   │     └─ 技術負債・Cloud違反がある ──► 【2. 改修利用】(コード修正)

   │                                   └──► 【3. 置き換え】(Core Componentsへ移行)

   │

   └─► 利用頻度・ビジネス影響度が【低い】（過去の特設サイト用など）

         └─ 移行対象から除外 ──────► 【4. 廃止・静的化】

1. 継続利用: AEMaaCSの制約に違反しておらず、最小限の修正（パッケージ構成の変更など）だけでそのままクラウドへ移行できる優良な資産です。
2. 改修利用: 非推奨APIなど一部に修正が必要なものの、独自のUI/UXや業務要件を維持するために、内部コード（JavaやSling）を書き換えて延命するパターンです。
3. 置き換え: 独自に作り込まれた古いコンポーネントを廃止し、AEMaaCSが標準提供する高機能な 「Core Components（コアコンポーネント）」 やスタイルシステムへ作り直す方針です。将来の製品アップデートへの追従が容易になります。
4. 廃止・静的化: 利用頻度が低く、長年更新されていない過去のコンテンツは移行対象から外します。どうしても残す必要がある場合は、HTMLとして静的出力して別サーバーに逃がすことも検討します。

【事例】徹底的な事前調査が移行時の「致命的な手戻り」を防いだケース

コウェルが支援した、オンプレミス版AEM 6.xからAEMaaCSへの刷新を検討されていた大手企業サイトの事例です。

背景と課題

当初、お客様は「公式の移行ツール（Content Transfer Toolなど）を使えば、全データが自動的にクラウドへ移るだろう」と予想されていました。物理的なページデータやアセットを機械的に右から左へ転送するだけであれば、ツールの性能上、お客様の見立て通り数日で完了できることは確かでした。

しかし、現行環境のソースコードをお預かりしてコウェルで事前調査（BPAの実行とリポジトリ解析）を実施したところ、データ転送の先にある別の重大なハードルが浮かび上がりました。

既存のレガシーなソースコードをAEMaaCSのモダンな制約に適合するよう改修するにあたって、単にプログラム（JavaやHTL）を書き換えるだけでなく、クラウド側へ移行した既存のページデータに対しても「コンテンツ変換（ノードやプロパティの構造変換）」を行うステップが必要不可欠であることが判明したのです。

調査結果に基づく資産棚卸しと対策

もしこのコンテンツ変換のステップに気づかないまま、データをただツールで右から左へ転送していたら、コードが新しくなった一方でコンテンツ側のデータ構造が古いままになり、クラウド上でコンポーネントが一切動作しない（表示崩れや編集不可になる）という最悪の手戻りが発生するところでした。

そこで、事前調査の段階で資産棚卸しを行いました。

1. 改修に連動するコンテンツ変換の特定: どのレガシーコンポーネントのコード改修において、既存コンテンツのどのプロパティやノード構造を変換しなければならないかを事前にすべてマッピングしました。
2. 変換手順の事前検証: 数日でデータ転送を終えた直後に、新しいコードと適合させるための「コンテンツ変換処理」をスムーズに行えるよう、変換手順やスクリプトのシミュレーションをあらかじめ実施しました。

成果

「データは数日で移せる」というツールの強みを活かしつつ、ソースコード改修の裏で絶対に避けて通れない「コンテンツ変換」という隠れたステップを事前調査で特定できたことで、プロジェクト後半の予測不可能なバグや手戻りを未然に防ぐことができました。

◼︎AEM関連資料はこちら：

AEMaaCSを主軸に据えた現実的な移行ロードマップ

AEMaaCSへの刷新を成功させるためには、以下のステップに沿って進めることで安全かつ確実な移行が可能になります。

【ステップ1: 事前調査】 (2〜4週間)

  └ BPA（Best Practices Analyzer）の実行、リポジトリボリュームの確認、レガシー資産の可視化

        ▼

【ステップ2: 資産棚卸し】 (2〜3週間)

  └ 移行対象コンポーネントの選別、不要アセットの削減・アーカイブ、新旧業務フローのギャップ確認

        ▼

【ステップ3: 移行設計・開発】

  └ AEMaaCS標準構造へのパッケージ分割、コードのリファクタリング、Cloud Managerパイプラインの構築

        ▼

【ステップ4: 移行リハーサル】（最低1〜2回）

  └ Content Transfer Toolを用いた実転送テスト、所要時間の計測、ユーザー受け入れテスト（UAT）

        ▼

【ステップ5: 本番切替】

\ AEMならコウェルにお任せください /

AEM as a Cloud Serviceへの刷新は、企業のデジタルマーケティングを加速させる強力な一歩です。だからこそ、その土台となる既存資産を正しく把握し、クラウドに適した状態でスタートを切ることが成功の条件となります。

コウェルでは、これまでの豊富な知見を活かし、現行環境の「事前調査（BPA診断）」から「資産の棚卸し支援」「AEMaaCS向けコード改修」、そして「本番移行・デプロイ」まで、一気通貫でサポートします。

特に、Adobe公式ドキュメントを読んだだけでは判断しにくい「自社環境ではどの変換を優先すべきか」「既存コンポーネント改修とコンテンツ変換をどう連動させるか」といった実務面を、経験に基づいて具体化できる点がコウェルの強みです。単なる手順代行ではなく、公式情報と現場実装の間にあるギャップを埋めるサポートを行います。

「現在のAEM環境をAEMaaCSへスムーズに移行させたい」「何が移行のリスクになるのか、まずはプロに診断してほしい」という担当者様、まずは事前調査しから始めてみませんか？

◼︎関連資料：