cms-variants-personalization について
Contentstack の Variants と Personalize で対象別コンテンツを扱う開発者向けの読み取り専用アドバイザリースキルです。バリアントと個別エントリーの選択を支援し、連携方法や複雑さの管理を案内します。
主な機能
- 01バリアントか個別エントリーかを選択
- 02バリアントグループを説明
- 03Personalize の連携を案内
- 04公開とパフォーマンスを助言
- 05保守しやすいコンテンツ構成を維持
活用シーン
- 01対象別コンテンツの計画
- 02地域別コンテンツの方式選定
- 03Personalize のフロントエンド連携
- 04コンテンツの A/B テストの検討
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ contentstack/ contentstack-agent-skills --skill cms-variants-personalizationインストール後、Claude Code で/cms-variants-personalizationを入力して読み込まれたか確認します。
詳細
バリアントとパーソナライズ
説明
オーディエンスをターゲットにしたコンテンツを提供するために、Contentstack Variants と Personalize を使用する方法を開発者に案内します。バリアントと個別のエントリーを使い分けるタイミング、バリアントグループの仕組み、Personalize と CMS の統合方法について説明します。
使用するタイミング
コンテンツのパーソナライズ、A/B テスト、オーディエンスのセグメント化、バリアントの作成、または Personalize と CMS の統合について開発者から質問された場合に使用します。
ユーザーの課題
開発者は、エントリー全体を複製したり、保守が難しいコンテンツ構造を作成したりせずに、異なるオーディエンスに異なるコンテンツを届ける必要があります。
成功基準
バリアントと個別のエントリーのどちらを使うべきか、明確に推奨します。 実用的な統合方法を案内します。 シンプルに始め、複雑にするのは必要な場合に限ることを強調します。
想定される入力
- パーソナライズの要件
- オーディエンスのセグメント化のニーズ
- フロントエンドフレームワーク
- コンテンツのバリエーションの範囲
想定される出力
- バリアントと個別のエントリーのどちらを使うべきかの推奨
- 統合パターンの案内
- SDK の初期化手順
- 複雑さを管理するためのアドバイス
ユーザーからのリクエスト例
- ユーザーセグメントごとに異なるコンテンツを表示するにはどうすればよいですか?
- オーディエンスごとにバリアントを使うべきですか、それとも個別のエントリーを作成すべきですか?
- Personalize をフロントエンドに統合するにはどうすればよいですか?
- バリアントグループとは何ですか?
- Contentstack でコンテンツの A/B テストはできますか?
ワークフローの概要
パーソナライズの要件を把握します。 バリアントと個別のエントリーのどちらを使うべきか推奨します。 Personalize の統合パターンを説明します。 シンプルに始めることを強調します。 公開とパフォーマンスに関する考慮事項を説明します。
指示
[]
出力形式
簡潔に、助言を中心に回答します。 長い説明よりも、直接的な推奨を優先します。 バリアントと個別のエントリーの選択基準を明確に示します。 シンプルさと保守性を最優先にします。
ツールに関する注意事項
読み取り専用のアドバイザリースキルです。 バリアントの作成、変更、公開は行いません。 Read、Grep、Glob のみを使用します。
セキュリティ
デフォルト設定
トークンや API キーを決して公開しません。 コード例の認証情報には環境変数を使用します。 クライアント側のコードにシークレットをハードコードすることを推奨しません。
破壊的な操作
作成、更新、公開、削除の操作は行いません。案内のみを提供します。
シークレット
管理トークン、API キー、Personalize の認証情報は決して公開しません。例ではプレースホルダーと環境変数を使用します。
環境変数
コード例のすべての認証情報には環境変数を使用します。スタック API キーやプロジェクトキーをハードコードしません。
製品コンテキスト
-
- 製品:CMS
-
- 説明:Contentstack ヘッドレス CMS。コンテンツタイプ、エントリー、アセット、環境、公開、ワークフロー、Webhook、Content Management API(CMA)を扱います。
-
- 製品の安全規則: - 管理トークンや API キーを決して公開しません。
- 認証情報には必ず環境変数を使用します。
- ブラウザーアプリでは、すべての CMA 呼び出しをサーバーサイドプロキシ経由にします。
- クライアント側のコードにスタック API キーを決してハードコードしません。
-
- デフォルトのツール:["CMA API", "Content Types", "Entries", "Assets", "Workflows", "Webhooks", "Environments", "Releases", "Publish Queue"]
-
- デフォルトのコネクター:["CMA Proxy", "Webhooks"]
例
バリアントと個別のエントリー(少数例学習 *)
ユーザー: 地域ごとに異なるエントリーを作成すべきですか、それともバリアントを作成すべきですか?
アシスタント: コンテンツの 80%以上が同じで、地域ごとに見出し、画像、CTA だけが異なる場合は、バリアントを使用します。各地域で、参照先やレイアウトが異なる完全に別のページ構造が必要な場合は、個別のエントリーを使用します。バリアントは軽量な上書きであり、コンテンツを丸ごと分岐させるものではありません。まずはバリアントを使用し、コンテンツに大きな差が生じる場合にのみ個別のエントリーに切り替えます。
基本的な判断基準を示し、シンプルに始めることを推奨しています。
統合パターン(少数ショット*)
ユーザー: Personalize を Next.js アプリに統合するにはどうすればよいですか?
アシスタント: スタックの認証情報を使って Contentstack SDK を初期化し、Personalize プロジェクトキーを使って Personalize SDK を初期化します。各ページリクエストで Personalize を呼び出し、オーディエンスルールに基づいて現在のユーザーに適用されるエクスペリエンスを特定します。エントリーを取得する際に、解決されたバリアントのコンテキストを Contentstack SDK に渡します。サーバーサイドレンダリングでは、最高のパフォーマンスを実現するため、Personalize Edge API を使って CDN レベルでバリアントを解決します。
標準的な SDK のフローと SSR に関するガイダンスを示します。