OptimizelyのOptimizely CMS 13のウェビナーで公開された仕様とデモ内容を踏まえながら、その主要機能と、導入前に確認しておくべき論点を整理する。
「マーケターが自分で動ける」を実現する二つの柱
Visual Builder：自由度とガバナンスを両立させる設計
CMS 13の中核的な機能が「Visual Builder」だ。画面を水平方向のセクションと列・行のグリッド構造で区切り、左側のアウトラインでコンポーネントを操作しながら右側でリアルタイムプレビューを確認できる仕様になっている。
注目すべきは、この編集環境が「何でもできる」設計ではない点だ。管理者が事前に許可したスタイルの範囲内でのみ操作できる制限がかかっており、デザインの崩れを防ぎながら現場のマーケターが自律的に動ける仕組みになっている。エンタープライズ運用で常に問題になる「自由度とガバナンスのトレードオフ」に対する一つの回答として設計されている。
なお、新しいVisual Builderと従来の編集画面は併存する形をとっており、既存ユーザーへの強制移行は求めない設計になっている。
GraphとOpal AI：自社データをAIのコンテキストに変える
CMS 13の設計で最も特徴的なのが、「Graph」と呼ばれるデータ統合層だ。自社コンテンツや外部システムのデータをGraphという一つの基盤に集約し、そこに格納されたデータをAIエージェント「Opal」のコンテキストとして直接読み込ませる構造になっている。
Opalは、事前設定したブランドガイドラインやトーン・アンド・マナーを踏まえたうえで、文章生成・翻訳・SEOに関する提案を行う。自社独自のデータをAIが参照できる状態にする仕組みは、汎用AIツールとの差別化として明確なメリットがある。
検索最適化の観点では、クリック率やゼロ件ヒットキーワードを確認できるダッシュボードを備えており、特定ページの固定表示や同義語の登録を画面から直接操作できる。
さらに、検索エンジンやAIボットが自社サイトをどのようにクロールしているかを可視化する独自のダッシュボードも提供しており、他社がまだ手をつけていない分析領域に踏み込もうとしている点は評価できる。
デモが示した外部連携の範囲と確認すべき実態
Shopify連携デモが見せたものと見せなかったもの
ウェビナーでは、Shopify上の商品データをGraph経由でCMSに取り込み、ページの見出しや説明文のフィールドにマッピングする流れがデモとして紹介された。開発なしで外部データ連携ができる点は訴求として明快だ。
ただし、デモで示されたのは商品名・説明文といったテキストフィールドのシンプルなマッピングにとどまっていた。大規模ECサイトの運用現場では、価格・在庫・キャンペーン情報など、リアルタイム性が求められるデータを扱うケースが日常的に発生する。Graphを通じてデータを「取り込む」アーキテクチャが、数万件規模の商品マスタへのリアルタイム更新にどう対応するか（同期タイミングや処理負荷）については、デモ内で具体的な説明がなかった。
DAM統合と、複数買収製品を束ねるアーキテクチャへの視点
CMS 13では、ツールを切り替えずにCMS内で画像の編集や一括アップロードができるデジタルアセット管理（DAM）機能も訴求されている。ただし実態は、買収した別製品の画面をCMS内に埋め込む形での統合であり、ネイティブに一体化した設計とは異なる。
CMS 13は複数の買収製品をGraphで束ねながら構成された大規模なシステムだ。機能の網羅性は高い一方で、このアーキテクチャは導入後の運用負荷、バージョンアップ時の影響範囲、長期的な保守体制という観点での確認事項が生じやすい構造でもある。選定段階で技術スタックの整合性を確認しておくことが重要になる。
また、既存の編集画面とVisual Builderの併存という設計は移行時の安心感を与えるが、現場では二つの編集環境が並存することになる。運用ルールの整理と学習コストの見積もりは、想定よりも重くなる可能性がある。
効率化の裏で、ウェビナー全体を通じて語られなかったこと
CMS 13が一貫して強調しているのは、コンテンツをいかに素早く・大量に・品質を保って作れるかという効率化の軸だ。Visual BuilderによるBlueprint再利用、Opalによる文章生成・翻訳、コンテンツマーケティングプラットフォームとの連携による企画から配信の自動化。これらはいずれも「静的コンテンツの量産を高速化する」機能として設計されている。
一方で、ウェビナー全体を通じて、個々のユーザーの行動や属性に基づいてコンテンツをリアルタイムに切り替える「動的なパーソナライズ」への言及はほぼなかった。
マーケターが素早くページを作れることと、訪問したユーザーごとに最適なコンテンツが動的に出し分けられることは、別の機能だ。コンバージョン改善を目的にCMSを選定・リプレイスする場合、どちらの課題が自社の本質的なボトルネックなのかを先に整理しておかないと、導入後に「できないこと」が明らかになる。
加えて、AIが生成したコンテンツの正確性や品質をどう担保するかというガバナンスの設計（承認ワークフローとの連携や、ハルシネーション対策の具体的な仕組み）についても、今回のウェビナーでは詳細が示されなかった。AI生成コンテンツを実運用に乗せるうえでは、この点の確認が別途必要になる。
エンタープライズCMS選定で起点にすべき問い
CMS 13が提供しようとしている価値は明確だ。開発者への依存を減らし、AIとデータ統合によってコンテンツ制作の速度と品質を上げる。この軸に課題を感じている組織にとっては、検討に値する選択肢になる。 ただし、選定を本格化させる前に以下の問いを起点にすることで、自社ニーズとの整合性をより早く見極められる。
「コンテンツの量と速度」と「個別最適化」のどちらが自社の本質的な課題か。 コンテンツを大量・迅速に生産・配信することに主眼があるなら、CMS 13の設計思想は合致する。訪問ユーザーの行動データに基づくリアルタイムな出し分けが核心にあるなら、その対応力を別途確認する必要がある。
外部システムとの連携に、どの程度のリアルタイム性と規模が求められるか。 ノーコードでの外部連携は明確なメリットだが、Graphを通じた「取り込み型」のアーキテクチャが、自社のデータ規模・更新頻度・レイテンシ要件を満たせるかは技術検証が必要な論点だ。
複数製品を統合した巨大なシステムの保守・移行コストをどう評価するか。 機能の網羅性は高い一方で、ヘッドレス環境への移行コストや、複数買収製品が束ねられたアーキテクチャの長期的な保守負荷は、ウェビナーでは具体的な数字が示されなかった論点だ。エンタープライズの意思決定では、ここを曖昧にしたまま進めないことが重要になる。
まとめ
Optimizely CMS 13は、マーケターの自律性向上とAI統合による効率化を明確な設計思想として持った製品だ。GraphというデータコンテキストとOpal AIの組み合わせや、検索クロールの可視化ダッシュボードなど、他社との差別化として機能する要素も備えている。
一方で、外部連携の実態として示されたのはシンプルなマッピングにとどまり、動的パーソナライズの設計は現時点の製品から切り離されている。複数の買収製品を統合する構造が持つ運用・保守上のリスクも、選定段階で確認が必要な論点として残る。
「機能の充実度」ではなく、「自社の課題と設計思想がどこで交わるか」を軸に評価することが、エンタープライズCMS選定では判断を誤らないための出発点になる。