CMS 13 プレビュー 3: 主な変更点

CMS 13 プレビューをご覧になっている方は、前回の投稿で説明した初期アップグレード パスを実行したことがあるでしょう。プレビュー 3 により、本番環境に対応したリリースにまた一歩近づきます。プレビュー 2 に関するフィードバックに基づいて、次のように変更を加えました。 Content Manager と Optimizely Graph はデフォルトで有効ではなくなりました。

ただし、これらの機能は技術的な観点からオプトインされていますが、CMS 13 の可能性を最大限に活用するには、事実上 Optimizely Graph が必要であることを理解することが重要です。 実際には、プラットフォームの最も重要なイノベーションの多くが Graph に依存しているため、ほとんどのお客様が CMS 13 への移行の一環として Graph を採用すると予想されます。それが何を意味するのかを紐解いてみましょう。

プレビュー 3 の新機能は何ですか?

プレビュー 3 には通常の改善とバグ修正が含まれていますが、ここでは強調せず、代わりに公式ドキュメントを参照してください。 リリースノート。議論する価値があるのは、Optimizely Graph と Content Manager をオプトインによって有効にする変更点です。

Optimizely Graph が重要な理由

CMS 13 の新機能のいくつかは、Optimizely Graph 上に構築されています。より大きな例をいくつか見てみましょう。

• コンテンツ マネージャー: 新しい編集エクスペリエンスは、コンテンツの発見性を Graph に依存しています。

• 外部コンテンツ: CMS の外部の外部ソースからコンテンツを統合するには、Graph のインデックス機能が必要です

• コンテンツ バインディング: 外部コンテンツをレンダリングするアプローチでは、Graph の構造化クエリを利用します。

• RAG for Opal: グラフを使用すると、Opal はコンテンツを「見て」「理解」できます。 Opal がすべてのコンテンツをクエリしたり、声のトーンなどを理解したりできるようにします。

言い換えれば、CMS 12 と区別する新しい CMS 13 機能のいずれかを使用する予定がある場合は、Optimizely Graph が必要です。これなしでは機能しません。 Optimizely では、Optimizely Graph を 必須 CMS 13 を最大限に活用するための基本コンポーネントです。 Optimizely Graph を使用せずに CMS 13 を実行すると、より小さな新機能のサブセットを備えた .NET 10 用にコンパイルされた CMS 12 を実行することに非常に近くなります。 Optimizely Graph は、私たちが構築する機能のまさに中心となるため、時間の経過とともに CMS 13 以降での使用が増加するでしょう。

本当に Graph を導入できない組織の場合、主要なイノベーションのいくつかは CMS 13 なしでは利用できないため、短期的に CMS 13 に移行する価値を慎重に評価する価値があります。

Optimizely Graph は必要ですか?

これについては現実的になってみましょう。一部のシナリオでは、グラフなしで CMS 13 を実行できます。次に例を示します。

一例としては、オンプレミスまたはデータ常駐要件が厳しく、クラウド サービスの導入が不可能な顧客が挙げられます。とはいえ、現在 CMS を「オンプレミス」で実行している多くの顧客はすでにハイブリッド モデル (クラウド環境でのセルフホスト、パートナーホストのインフラストラクチャなど) で運用しており、そのような場合には Graph が依然として実行可能なオプションであることがよくあります。

新しい機能を求めて CMS 13 にアップグレードする場合は、Graph を採用する可能性があります。おそらく問題は、移行スケジュールにおいて「もし」ではなく、むしろ「いつ」なのかということです。

Content Manager と Optimizely Graph の有効化

これらの機能はほぼ確実に必要になるか、少なくとも試してみたいと思うので、簡単なオプトイン プロセスを次に示します。

ステップ 1: NuGet パッケージを追加する
プロジェクト内の適切なパッケージを参照します。

dotnet add package EPiServer.Cms.UI.ContentManager
dotnet add package Optimizely.Graph.Cms

ステップ 2: スタートアップ構成を更新する
Startup.cs (または Alloy ベースのプロジェクトでサービスを構成している場所) で、次の呼び出しをサービス登録に追加します。

public void ConfigureServices(IServiceCollection services)
{
  // ... your existing service configuration
  services.AddContentGraph();
  services.AddContentManager();
  // ... rest of your configuration
}

ここで順序が重要であることに注意してください。Content Manager は Graph のインフラストラクチャに依存しているため、AddContentGraph() は AddContentManager() より前に置く必要があります。

グラフの採用に関する私の見解

オプトイン アプローチのこの変更について私が考えていることは次のとおりです。Graph は、あれば便利な機能アドオンではありません。Optimizely エコシステムにおけるコンテンツ配信の基礎です。

• Content Manager は、Graph クエリを活用したパフォーマンスの高いコンテンツ検出エクスペリエンスを編集者に提供します。

• 外部コンテンツを使用すると、Graph のインデックス作成を通じて異種コンテンツ ソースを統合できます

• コンテンツ バインディングにより、開発者は Graph のスキーマに基づいて厳密に型指定されたコンテンツ モデルを操作できるようになります。

これらは孤立した機能ではありません。それらは共同の物語を語るパズルのピースです。そしてグラフはそれらを結合する結合組織です。

グリーンフィールド プロジェクトを構築している場合、または大幅な近代化の取り組みに取り組んでいる場合は、初日から Graph を採用するべきだと思います。後でコンテンツ マネージャーや外部コンテンツを導入するときに後付けしようとすると、最初から組み込むよりも手間がかかります。

ということで、合金テンプレート

学習ツールまたはプロジェクトの基盤として Alloy テンプレートを使用している場合は、両方の機能を有効にして完全な編集エクスペリエンスを得ることができます。 Alloy テンプレートは Content Manager の機能を示し、Graph はその検索機能と新しいコンテンツ配信パターンの両方を強化します。

これは実際、運用アーキテクチャを構築する前に、Graph がプラットフォームとどのように統合されるかを理解するための優れた学習環境です。

いつものように、Preview 3 は本番環境に対応していないことに注意してください。評価、実験、準備に使用しますが、正式な CMS 13 リリースまでは実稼働サイトを CMS 12 上に維持してください。

コーディングを楽しんでください!

2026 年 2 月 19 日