Adobe Experience Manager（AEM）の発注は、目的と要件の整理、契約と委託先の比較から始まります。その後に移行と運用を検証すると、現場で使い続けられる基盤につながります。
全体像はAdobe Experience Managerのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・Adobe Experience Managerのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Adobe Experience Managerの発注・外注で最初に決める事項
最初に決めるのは、AEMで変える業務とチャネルです。Sitesだけを使うか、AEM Assetsで画像・動画・文書を統合するかによって、必要な専門性が変わります。さらに、FormsやAdobe Analyticsとの連携も、専門性と費用を左右します。
発注目的と対象範囲の言語化
発注側は、「サイトを刷新したい」という要望を、業務上の目的に置き換えます。たとえば、更新の共通化、素材配布、PIMの商品情報の再利用などが挙げられます。
マーケティング部門だけで更新できる状態も、目的に含まれます。目的を明確にすると、必要な機能と不要なカスタマイズを分けられます。
- 対象規模：サイト数、国・言語、ページ数、アセット数、月間更新件数
- 運用条件：利用者の権限、承認経路、外部システム、旧URLの引き継ぎ
ヤマハ株式会社の例では、AEMで約10万点のアセットを管理し、世界の販社や特約店との共有に活用しています（出典: Adobe公式「ヤマハ株式会社のユーザー事例」、2020年掲載）。
約10万点規模のアセットを扱う案件では、メタデータ設計や権利管理も発注の対象になります。
内製と外注の分担
自社と開発会社で役割を分けます。自社は、移行対象、運用KPI、個人情報の扱いを決めます。
- 自社で担うこと：業務方針、コンテンツ責任、承認、運用判断
- 委託先へ任せること：AEMのアーキテクチャ設計、Cloud Manager、コンポーネント開発、Dispatcherや配信設計、データ移行自動化
発注側は、実際の編集者を交えて日常業務をデモで試し、誰がどの画面で何をするかを確かめます。機能一覧だけで決めると、教育や追加改修が増え、外注への依存も強まります。
AEMの発注形態の選び方
確定した要件には請負型、変化する要件には準委任型が合います。専門家を継続して確保する場合は、ラボ型や常駐型が候補です。また、企画から運用改善まで、性質に応じて契約を分けると、変更を判断しやすくなります。
一括請負型の成果物と上限
一括請負型は、要件定義書や基本設計書に基づいて、機能を納期と金額を決めて納品する契約です。仕様が確定している案件に適しています。
- 確定する内容：テンプレート、コンポーネント、権限、連携、移行件数、テスト項目
- 契約で確認する内容：受け入れ条件、仕様変更時の追加見積ルール
旧CMSの品質や現場運用が分からないまま移行まで請負にすると、ページの増加やURLの例外が後から見つかり、変更契約になりやすいため危険です。
先に現状診断と小規模な移行検証を準委任で行い、その結果から本開発を請負へ移す方法もあります。
準委任型が向く案件
準委任型は、稼働時間や役割を定めたうえで、設計・開発・移行支援を一定期間委託する形です。AEM Cloudへの移行方式や標準部品の採用範囲、Headlessと従来型配信の使い分けなど、調査中の課題に適しています。
- 作業計画：月間の作業時間、参加職種、成果物、報告方法
- 月次確認：決定・未決事項、消化工数、リスク、翌月の成果物の報告
準委任型は柔軟ですが、成果が見えにくい場合があります。そのうえで、導入の判断を先延ばしにせず、次の請負範囲を確定する調査契約として準委任型を使います。
段階発注によるリスクと責任の分担
発注側と開発会社は、各段階の終了条件と次へ進む基準を、あらかじめ決めておきます。承認の対象は、移行対象、サイト構造、部品方針です。連携先と非機能要件も承認してから、開発に進みます。
- 現状診断・RFP支援
- 要件定義・基本設計
- 開発・移行
- テスト・教育
- 運用改善
段階ごとに分けると、発注側は各段階で判断でき、受託側も、不確定な要件による過大なリスク費用を避けられます。ただし、責任の境界が曖昧だと、要件の抜けを押し付け合うことがあります。
設計書、移行仕様、テスト計画は、所有者と納品時期を決めます。ソースコードや運用マニュアルについても、納品時期と所有者を明確にしておきます。
AEMのRFPに書く内容と要件整理
RFPには、機能要件に加えて、移行と運用の要件を記載します。セキュリティと納品物も欠かせません。
Adobe公式のAEM Sites価格ページは、定額の価格表を示さず、機能やアドオンを確認して導入相談を受ける形式です（出典: Adobe公式「Adobe Experience Manager Sitesの機能と価格」、2026年参照）。そのため、RFPの情報が少ないと、各社の見積条件がばらつきます。
利用者と業務フローで書く機能要件
要件は「AEM Sitesを導入する」と書くのではなく、利用者ができることとして書きます。編集者の操作では、テンプレートの選択と配置、プレビューを定めます。承認依頼や公開後の履歴も、要件に含めます。
- Assets利用時：メタデータ、タグ、権利期限、派生画像、DL権限、外部共有期限
- システム連携時：データ方向、頻度、再送、認証、責任分界、API変更の通知手順
連携先には、CRMやPIM、MAなどがあります。分析や翻訳、検索、会員基盤との連携も、想定に入れます。
GraphQL API、イベント、Webhookそれぞれのデータモデルについて、管理者を定めます。また、担当者をRFP説明会へ招くと、想定外の作業を減らせます。
測れる形で書く非機能要件
非機能要件には、表示速度、可用性、ピーク時のアクセスを含めます。バックアップや災害復旧、監査ログも含めます。さらに、脆弱性対応、データ保持、サポート時間も対象になります。
- 性能・復旧：通常時とキャンペーン時のPV、同時接続、復旧目標時間、許容損失
- 運用・安全性：SSO、製品プロファイル、IP制限、ログ確認者、障害連絡先
数値を決められない場合は、受託側に前提条件と測定方法を提案してもらいます。
AEM as a Cloud Serviceは、Cloud ManagerのCI/CDや標準CDNに加え、自動拡張と継続アップデートも備えています（出典: Adobe Experience League「Introduction to Adobe Experience Manager as a Cloud Service」、2026年6月更新）。
企業側の設定、権限、コンテンツ運用までは、AEM as a Cloud Serviceでも自動で安全になるわけではありません。
移行要件と不要コンテンツの切り分け
現在のページ数をそのまま移す前提は避けます。代わりに、URLやタイトル、説明、見出し、画像altを一覧にして洗い出します。構造化データや公開日、言語、権利期限、リンク切れも、同じ一覧に加えます。
- 移行区分：移行、統合、再作成、廃棄のいずれかに分類
- 本番前検査：リダイレクト、公開状態、権限、翻訳、リンク先の確認
表記の揺れや古い画像が多いと、ページ数が少なくても、整備の工数が増えます。移行ツールを使う場合は、変換確認の責任者も決めておきます。
サンプルで変換を検証し、本番前には検索への影響も確かめます。さらに、対象外のコンテンツと例外処理は、仕様書に明記します。
AEM開発の契約形態と契約書で確認する項目
契約形態は、双方のリスクや仕様変更の扱いを決めます。契約書では、作業範囲、成果物、検収、再委託を確認します。さらに、知的財産や秘密保持、個人情報、損害賠償を確認し、終了時の引き継ぎについても取り決めます。
Adobeのライセンス契約と、開発会社との委託契約は別のものです。それぞれに何が含まれるかを、分けて管理します。
検収条件と仕様変更のルール
検収では、画面表示だけでなく、権限別の操作や承認・公開も確かめます。レスポンシブ表示や連携データ、移行URLも対象にします。さらに、性能やログ、エラー時の挙動も含めます。
- 受け入れテスト：シナリオ、実施者、期限、重大度別の不具合の扱い
- 変更管理：内容、影響範囲、追加費用、納期、承認者の記録
標準コンポーネントを独自仕様に変える場合は、AEMの更新や別サイトへの展開に、どう影響するかも評価します。そのうえで、要望の効果や標準機能での代替案も、定例会で判断します。
納品物と知的財産の帰属
画面以外の資料やコードも、納品の対象にします。資料の形式と更新責任者を定め、稼働後に使える状態で引き継ぎます。
- 設計・運用資料：要件、サイトマップ、画面・コンポーネント・連携・移行仕様、テスト結果、運用・教育資料
- 技術資産：Cloud Manager設定、ソースコード、ライセンス一覧
特定の会社しか保守できない設計を避けるため、コードや設定について、利用と改修の権利、第三者への引き継ぎ、再委託先の成果物を受け取れるかを確認します。
AEM標準機能と自社固有の成果物を分けて、一覧にします。終了時には、アカウントや環境、資料、未解決の課題も引き渡します。
保守・運用のSLAと内製化
保守契約では、受付時間、一次回答、復旧目標、対象環境を分けて定めます。点検や脆弱性対応、更新検証、バックアップ、問い合わせ対応も、分けて扱います。
- 責任分界：Adobe、開発会社、自社の担当範囲の表
- 内製化：編集教育に加え、開発者のリポジトリ、テスト、デプロイ、ログ、障害切り分けの範囲
AEM Cloudであっても、誤公開や権限、独自コード、外部連携の障害を、Adobeがすべて担うわけではありません。
一方で、電通デジタルの公開事例では、専門知識のないスタッフも更新でき、オウンドメディアの更新頻度が1.2倍になりました（出典: Adobe公式「株式会社電通デジタルのユーザー事例」、2026年参照）。
AEMの費用相場の目安
AEMの費用は、ライセンス構成と案件条件に応じた個別見積です。2026年時点のAdobe公式ページは、定額の日本円価格を公開せず、機能やアドオン、SLAを示して導入相談を受けています。
ここで示す数字は、公式の定価ではなく、公開情報による試算です。
ライセンスと導入・開発費の分け方
費用は、SitesやAssetsのライセンスと、導入・開発費に分けて考えます。導入・開発費には、要件定義・設計、部品開発、外部連携、コンテンツ移行が含まれます。テストや教育、運用改善も、費用の項目として見ます。
- 年額ライセンスの推定：エントリー層は約3万ドル、Sites・Forms・Assets構成は10万ドル超
- 実装費の推定：初年度ライセンスの2〜4倍が目安
これは、海外の実装パートナーが示した2026年の市場推定で、Adobe公式の価格ではありません（出典: scandiweb「Adobe Experience Manager for eCommerce in 2026」、2026年）。
為替や契約条件によって金額は変わります。1ドル=150円で機械的に換算すると、ライセンスは年450万円程度から、複数モジュールは年1,500万円超です。
ただし、これは為替を固定した試算で、実際の契約価格を保証するものではありません。移行や環境数、ストレージが別料金なら、3年間の総額は大きく変わります。追加機能や監視、保守が別料金の場合も、総額を左右します。
案件規模別の初期総額レンジ
公開推定と一般的な企業システムの費用感をもとにした、初期総額と期間の試算です。
- 単一サイトの小規模PoC：初期総額1,000万〜3,000万円程度、期間3〜8か月
- 中規模の企業サイト刷新：初期総額3,000万〜1.2億円程度、期間8〜18か月
- 大規模グローバル基盤：初期総額1.2億〜5億円以上、期間18〜36か月以上
小規模導入の試算には、ライセンスや設計、開発、少量の移行が含まれます。この金額は、公式の相場ではありません。
金額は、ページ・アセット数や言語数、PVなどの条件で変わります。連携や環境数、カスタム開発も、金額を左右する要因です。期間も、あくまで検討の目安です。
一例として、電通デジタルの事例では、サイト制作に約5か月、旧サイトのデータ移行に約2か月を要しました（出典: Adobe公式「株式会社電通デジタルのユーザー事例」、2026年参照）。
コンテンツの品質や承認体制が異なるため、この事例を自社の案件へそのまま当てはめることはできません。
3年TCOでの見積比較
初期費用だけでなく、ライセンス3年分と保守・改善を合算します。さらに、追加環境、監視、翻訳、アセット整理を加えます。セキュリティ診断や教育、社内工数も、同じ合計に入れます。
- 保守・改善枠：初期開発費の年10〜20%を確保する考え方もあるが、公式料金ではない
- 見積条件：作業範囲、除外条件、単価、再見積条件を同じ形式で示すこと
安い見積では、移行対象が少なく、追加のページや連携が時間単価で扱われる場合があります。一方で、高い見積には、移行リハーサルや教育、改善、更新検証が含まれる場合もあります。
Cloud Serviceの基盤運用に含まれる範囲と、自社が別途負担する運用作業を分けて確認します。
AEMの委託先を選ぶときのポイント
委託先は、販売代理店かどうかだけでなく、実装や移行、連携、運用を管理できるかで選びます。Cloud Manager、PIMやCRM連携、編集者教育の経験も確認します。
類似案件の実績と担当者
実績は、サイト数や言語、移行量の面から確認します。製品や期間、運用体制も対象です。さらに、公開事例と提案会社の実績が同じかどうか、担当範囲も確かめます。
- 案件条件：サイト、言語、ページ・アセット数、製品、移行量、連携先、期間、運用体制
- 担当体制：アーキテクト、AEM開発者、移行責任者、運用設計者、再委託の有無
社名を出せない場合は、規模と課題を匿名にして説明できるかを見ます。担当者の経験や、契約後の交代条件も質問します。
Cloud ServiceとAEM 6.5系の実績や、再委託の有無も確認します。技術者が早い段階から加わると、見積の前提と制約を合わせやすくなります。
標準機能とカスタム開発の境界
要望は、すべて独自開発にするのではなく、標準機能で実現できる範囲と、追加開発が必要な理由を提案書で確認します。
- 標準機能の候補：編集可能テンプレート、コア部品、スタイル、コンテンツフラグメント、翻訳・承認機能
- 追加開発の確認：費用、テスト、保守、更新影響、性能、アクセシビリティ、再利用性
標準機能を使うと、更新時の検証や別サイト展開の負担を抑えられます。「画面一式」などの見積は、部品数、状態、入力、権限を明細にしてもらいます。エラー処理や調整回数も、明細に含めます。
同じ前提にそろえた見積書の比較
各社に同じ回答フォーマットを渡し、発注側の作業量や承認待ち、データ提供期限、遅延リスクも確認します。
- 費用項目：ライセンス、要件定義、設計、開発、移行、テスト、教育、保守、追加単価
- 前提項目：除外事項、前提条件、体制、期間、発注側の作業
3年TCOに加えて、案件規模や変革の範囲、社内人材、公開時期との適合度で評価します。大規模な実績が、単一サイトに最適とは限りません。
国内の運用に強くても、複雑な連携や大量の移行を担えるとは限りません。そのうえで、価格と技術のバランスを判断します。
AEMの発注から稼働までの進め方
候補会社を探す前に、発注側の意思決定者、業務責任者、IT責任者、コンテンツ責任者をそろえておきます。業務の優先順位やブランド方針は、自社で決めます。
発注前のRFPと評価基準の準備
RFPには、背景、目的、範囲、現状構成、利用者を記載します。ページ・アセット数、言語、更新量、連携先も書きます。さらに、希望時期、予算の考え方、非機能要件、納品物も含めます。
- 想定ケース：予算未確定ならPoC、中規模刷新、全社基盤などを提示する
- 評価基準：価格、実績、技術、移行、標準活用、体制、内製化、セキュリティ、契約
価格だけで比べると、必要な作業を除いた見積が有利に見えることがあります。そこで、配点や最低条件を決め、提案説明会では同じ質問をして、回答の具体性を記録します。
設計・開発での標準の先行検証
契約後は、サイト構造、コンテンツモデル、権限、承認を設計します。テンプレートや部品、連携方式も、設計の対象です。また、編集者が作るコンテンツを、サイトやチャネルでどの単位で再利用するかも決めます。
- Cloud Service：Cloud Managerのパイプラインとコード品質チェックを前提にした環境設計
- 先行検証：代表ページや複雑な承認、外部連携、移行データでの試行
標準機能で足りない部分だけを開発し、更新検証と運用手順も確かめます。採用の判断は、業務効果、保守性、再利用性を基準にします。
移行・テスト・教育の発注範囲
移行は、サンプル、リハーサル、本番の順に行います。サンプルで変換ルールを決め、リハーサルでは件数や所要時間、エラーを検証します。リダイレクトや権限、公開状態も、リハーサルで確かめます。
- 本番移行の更新停止時間、差分データ、切り戻し条件の決定
- 関係者への連絡と業務シナリオの用意
- 編集者、承認者、IT部門、連携先によるテストの実施
- 操作教育での実コンテンツの作成と、質問が集中する箇所の修正
公開後は、検索やフォーム送信、分析計測を確かめます。画像や権限、翻訳、モバイル表示も確認します。マニュアルを渡すだけでなく、実際の作業を通じて運用準備を整えます。
セキュリティと運用ガバナンスの契約条項
AEM Cloudの基盤機能と、企業が設計・運用する範囲を分けます。そのうえで、IMSやSSO、役割と製品プロファイル、ネットワークを具体化します。コード品質や監査、脆弱性、障害連絡についても、契約書に書き込みます。
権限・監査ログ・個人情報の扱い
権限は、役職名ではなく業務ごとに分けます。管理やブランド別の編集、翻訳依頼、承認を区別します。さらに、公開やAssetsの閲覧・ダウンロードも、別の権限として扱います。
- アカウント管理：異動・退職時の削除、開発会社の作業申請・承認・記録の決まり
- 個人情報：保存場所、外部提供、再委託先、保持期間、削除手順の決定
監査ログには、変更者や承認者、公開時刻を残し、あとから追えるようにします。外部連携では、保存する情報を最小限にし、暗号化やマスキング、ログ出力の防止、テストデータの匿名化を確認します。
個人情報保護委員会のガイドラインを踏まえ、海外の第三者や再委託先へ提供する場合の確認責任も、契約に記載します。
稼働後の改善判断の定例化
更新時間や公開リードタイム、差し戻しを見ます。検索やアセット再利用率、フォーム完了率、障害件数も含めて、改善テーマを決めます。
- 会議：運用、IT、開発会社、Adobe製品担当者が参加する、月次または四半期ごとの会議
- 開発判断：標準機能や設定、運用ルール、外部ツールで代替できるかの調査
評価の観点は、機能の追加そのものより、コンテンツ品質や公開速度、ブランドの一貫性、問い合わせやコンバージョンへの効果です。更新前の回帰テストと変更履歴も、契約作業に含めます。
よくある質問
AEMの発注に関する費用や期間、委託先、クラウドの選び方について答えます。
AEMの導入費用を正確に知る方法は何ですか？
公式の価格は、一律には公開されていません。Sites、Assets、Formsなどの範囲や規模、環境数、アドオンを伝えて、Adobeまたは販売・実装パートナーに個別見積を依頼します。
開発費は、要件定義、開発、移行に分けて考えます。連携や教育、保守も含め、3年TCOで比較します。
AEM CloudとAEM 6.5系はどちらを選べばよいですか？
新規導入では、継続更新や自動拡張、Cloud Managerを提供するAEM as a Cloud Serviceを候補にします。
固定のインフラ要件や既存資産を、ネットワークやデータの所在、運用方針と照らし合わせます。
AEM 6.5系が必ず安いとは限らず、Cloudが必ず適するとも限りません。インフラの自由度と更新対応の負担を含めて、比べます。
AEMの開発会社は何社から見積を取るべきですか？
比較できるRFPがあれば、3〜5社程度へ同時に依頼すると、価格と提案を比べやすくなります。
社数よりも、自社の重要条件に合うかを重視します。最終候補には、実装担当者との技術確認と、過去案件の運用体制を質問します。
RFPがない状態でも開発会社へ相談できますか？
相談できます。目的や対象サイト、ページ・アセット数、言語をまとめ、既存システムや希望時期、困っている業務も書き添えると、提案の精度が上がります。
RFP作成支援や現状診断を準委任で頼む方法もあります。その場合は、調査成果物や費用、作成資料の利用範囲を確かめてから、本開発の見積に進みます。
まとめ
発注では、実現したい業務、移行対象、連携、運用体制を明確にします。そのうえで、Sites、Assets、Formsの範囲とCloudまたは6.5系を整理し、機能・非機能・移行の要件と納品物を、RFPに記載します。
発注成功のための優先事項
契約は、調査、要件定義、開発、移行、教育、運用改善の段階に分けます。確定した範囲は請負とし、検証中の範囲は準委任とする方法もあります。
見積は、ライセンスや追加開発、保守、教育、社内工数を含む3年TCOで比べます。公開推定を公式価格と混同せず、個別見積で検証します。
次に行うべきアクション
現行サイトとアセットを洗い出し、関係者を整理してRFPの初稿を作ったうえで、3〜5社へ相談します。
提案では、標準機能と開発の境界、担当者を確認します。移行、検収、保守SLA、契約終了時の引き継ぎについては、提案の段階で確かめておきます。編集者も、デモと受け入れテストに参加します。
▼全体ガイドの記事
・Adobe Experience Managerのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。