SitecoreAIは、2025年のSymposiumでXM Cloudの後継としてSitecoreがリリースした統合プラットフォームであり、従来のSitecore XP/XMからの脱却を象徴するイベント駆動型統合モデルを維持しています。カスタム.NETパイプラインプロセッサやイベントハンドラを管理されたコンテンツ管理レイヤーにデプロイすることはできません。代わりに、アイテムの保存、ワークフローの進行、フォームの送信、パブリッシュの完了など、すべての意味のあるオーサリングアクションが、JSON（またはXML）ペイロードを外部（Azure Functions、AWS Lambda、Logic Apps、Power Automate、CRM、検索インデックス、AIサービスなど）へ送信するアウトバウンドHTTPリクエストをトリガーします。
本ガイドでは、SitecoreAIのCMSレイヤーで現在ドキュメント化されているすべてのwebhook機能について、アーキテクチャ、ペイロード、セキュリティガイダンス、および本番パターンを解説します。
SitecoreAIにおける3つのWebhookエコシステム
SitecoreAIのwebhook機能は、プラットフォームの異なるレイヤーをカバーする3つのカテゴリに分類されます。
- CMS & Workflow Webhooks：アイテム変更、パブリッシュ、ワークフロー遷移などのオーサリングアクティビティをカバー。Content Editor/Pagesで設定します。
- Forms Webhooks：フォーム上での閲覧、操作、送信などの訪問者行動をカバー。
- Experience Edge Admin API Webhooks：パブリッシュ完了後、コンテンツがEdgeに配置された後にトリガーされます。
関連する4つ目の機能として、Sitecore Cloud Portalレベルにaudit-log webhooksが存在します。これはSitecore製品全体を横断するテナント全体のセキュリティ機能であり、CMSコンテンツwebhookではないため、上記3つとは別に後述します。
1. CMS & Workflow Webhooks
これらはコンテンツツリー内の/sitecore/system/Webhooks配下に存在し、表示または作成には開発者または管理者ロールが必要です。このカテゴリには3つの異なるメカニズムがあります。
Webhook Event Handler：Fire-and-Forget通知
サブスクライブしたシステムイベントが発生した瞬間に非同期で発火し、オーサリングをブロックしません。検索インデックス作成、キャッシュ無効化、CRM同期、アナリティクスピングなど、編集体験を阻害すべきでない用途に適しています。
Sitecoreは18のwebhookイベントを文書化しています（アイテムライフサイクル14件、パブリッシュ4件）。
アイテムレベルイベント：
item:added, item:cloneAdded, item:copied, item:deleted, item:deleting, item:locked, item:moved, item:renamed, item:saved, item:sortorderChanged, item:templateChanged, item:unlocked, item:versionAdded, item:versionRemoved
パブリッシュレベルイベント：
publish:begin, publish:end, publish:fail, publish:statusUpdated
最もよく使用されるもの： item:saved（編集セッションごとに複数回発火する可能性あり）、item:added、item:deleted、publish:end。
ルールなしでサブスクライブしないでください。 スコープのないitem:savedハンドラは、コンテンツツリー全体のすべてのマイナーなフィールド編集やツリー再配置で発火します。Rules Engineを使用して、特定のテンプレート、ブランチ、サイト、言語に実行を制限してください。
Webhook Submit Action：ワークフロー遷移通知
/sitecore/System/Workflows配下のワークフローステートまたはコマンドに直接アタッチされます。アイテムがそのステートに入ったとき、またはコマンドが実行されたときに発火します。コンテンツが「Approved」になったときにTeamsやSlackにメッセージを投稿したり、「Ready for Translation」に移動した瞬間にSmartlingやPhraseの翻訳ジョブを開始したりする用途に使用します。
Webhook Validation Action：同期ゲートキーパー
このアクションは他の2つとは動作が異なります。Event HandlerとSubmit Actionが通知のみを行うのに対し、Validation Actionはワークフローコマンドを一時停止し、応答を待ってから変更を実行します。
Author clicks "Submit for Approval"
│
▼
SitecoreAI sends a synchronous
Validation webhook request
│
▼
External service evaluates
the item
│
┌───────┴───────┐
▼ ▼
HTTP 200 Timeout / Error /
Non-2xx
│ │
▼ ▼
Workflow Workflow blocked;
advances error shown to author
Enter fullscreen mode Exit fullscreen mode
典型的な用途：SEO検証、アクセシビリティチェック、AIコンテンツモデレーション、ブランドボイス準拠、法的承認、メタデータ完全性確認。エンドポイントが失敗、タイムアウト、または成功以外のレスポンスを返した場合、コマンドは中止され、アイテムのステートは変更されません。
ペイロードリファレンス：SubmitおよびValidation Actions
両アクションタイプは同じペイロード形状を送信します。
| プロパティ | 型 | 説明 |
|---|---|---|
ActionID |
GUID | webhookを送信したプロセッサアイテムのID |
ActionName |
String | そのプロセッサアイテムの名前 |
Comments |
Array of Key/Value objects | 遷移時に入力されたコメント |
DataItem |
Object | 完全なアイテム：言語、バージョン、ID、テンプレート、フィールド |
Message |
String | 追加のメッセージテキスト（存在する場合） |
NextState |
Object | アイテムが遷移するワークフローステート |
PreviousState |
Object | アイテムが離れるワークフローステート |
UserName |
String | コマンドを開始したアカウント |
WorkflowName |
String | アクティブなワークフローの名前 |
WebhookItemId |
GUID | webhookアイテム自体のID |
2. SitecoreAI Forms Webhooks
Formsは最初からwebhookサポートを搭載しており、カスタム開発は不要です。Form BuilderのSettingsタブからフォームごとに設定するか、Webhooksダッシュボードから一元管理できます。公開済みフォームにバインドされたwebhookは削除がロックされ、誤って削除してライブフォームを破損することはありません。
Formsは3つの組み込みイベント（VIEWED、INTERACTED、SUBMITTED）を発火し、より細かいトラッキング用のカスタムイベントもサポートします。これはSitecore CDPなどのプラットフォームへデータを送信する場合に便利です。
認証オプション：
| タイプ | 設定 | 最適な用途 |
|---|---|---|
| OAuth 2 | Client ID、secret、認証エンドポイント | 動的JWTが必要な企業統合 |
| Basic | ユーザー名 & パスワード | 軽量なテスト統合 |
| API Key | 静的ヘッダーキー/値 | 固定キーを用いたサーバー間通信 |
| 認証なし | なし | ローカルデバッグのみ、本番非推奨 |
フォームを有効化する前に必ずwebhookをテストしてください。Test Webhookフローは実際の訪問者データが到達する前にURL、ペイロード、ヘッダーを表示し、テスト送信に"test": trueを付与して後でフィルタリングできます。
3. Experience Edge Admin API Webhooks
パブリッシュがExperience Edgeにコンテンツを配置した後、2つの実行モードで下流システム（静的サイト再構築、CDNパージ、検索インデックス更新、データレイク同期）をトリガーできます。
| モード | 動作 | 用途 |
|---|---|---|
| OnEnd（デフォルト） | パブリッシュジョブ全体完了後に1回発火 | CI/CDトリガー、完全キャッシュパージ |
| OnUpdate | エンティティごとに発火し、具体的な変更がペイロードに含まれる | 増分/差分検索更新、イベントストリーミング |
チュートリアルに必ずしも記載されない2つのポイント：レガシーなスナップショットパブリッシュ（v1）ではなくEdgeランタイムパブリッシュ（v2）を使用している場合、v2は1回の実行でパブリッシュするアイテムセットが小さいため、ジョブあたりのwebhook発火回数が少なくなります。また、Edgeは独自にwebhookの健全性を監視しており、webhookが30秒以内に10回連続で応答しなかった場合、自動的に無効化されます。受信側を修復した後、Admin API経由で再有効化する必要があります。
CMSを超えて：Sitecore Cloud PortalのAudit Log Webhooks
異なるレイヤーではありますが、知っておく価値がある機能です。Sitecore Common Audit LogはSitecore Cloud Portalから管理され、すべてのサポート対象Sitecore DXPアプリケーションからのセキュリティおよびアクセスイベント（ログイン、ロール変更、レコード作成/編集/削除）を、独自のWebhook REST API経由でSIEMなどの外部システムへストリーミングできます。テナント全体（SitecoreAIコンテンツだけでなく、組織内のすべてのSitecore製品）をカバーし、Bearerトークン認証を使用し、コンテンツツリーとは完全に別途に設定されます。統合ロードマップに集中型セキュリティ監視が含まれる場合は検討してください。ただし、上記のコンテンツレベルwebhookとは無関係のシステムである点に注意してください。
エンタープライズアーキテクチャパターン
パターン1：検索インデックス同期
Author publishes content
│
▼
Experience Edge processes
the publish
│
▼ (OnEnd webhook)
Azure Function
│
▼ (queries Edge GraphQL
for rendered fields)
Search index (Algolia / Coveo)
(partial update)
Enter fullscreen mode Exit fullscreen mode
- Experience Edge Admin webhookを
OnEnd（またはCMSレベルのEvent Handlerをpublish:endにスコープ）に設定して作成します。 - 実際にインデックス化が必要なテンプレート（例：Article Page）に制限します。
- 受信側は変更されたアイテムIDを抽出し、Experience Edge GraphQLエンドポイントからレンダリング済みフィールドをクエリし、通常パブリッシュ後数秒以内にインデックスへ部分更新をプッシュします。
利点：ニアリアルタイムのインデックス化、小さなペイロード、最小限の常設インフラ。
パターン2：AIを活用したワークフロー検証ゲートキーパー
Author clicks "Submit for Approval"
│
▼
Webhook Validation Action
fires synchronously
│
▼
Azure Function + LLM evaluator
checks DataItem.Fields
│
┌───────┴───────┐
▼ ▼
Criteria met Criteria failed
HTTP 200 HTTP 400 +
{"message": "..."}
│ │
▼ ▼
Workflow Workflow blocked;
advances error shown to author
Enter fullscreen mode Exit fullscreen mode
- 関連するワークフローコマンドにWebhook Validation Actionを追加します。
- 受信サービスは
DataItem.Fieldsを評価します（メタディスクリプション欠落、タイトル長、アクセシビリティギャップ、ブランド外言語など、ルールでカバーする内容）。 - 成功時はHTTP 200を返し、失敗時は明確なメッセージとともにHTTP 400を返します。SitecoreAIはそのメッセージをUI上で直接オーサーに表示します。
本番ベストプラクティス
高速応答、非同期処理
SitecoreAIのCMSレベルwebhookリクエストのデフォルトタイムアウトは10秒です。エンドポイントがインラインでこれを超える処理（大量画像生成、マルチページクロール、低速LLMコール）を行うとタイムアウトします。HTTP 202 Acceptedで即座に応答し、ペイロードをキュー（Azure Service Bus、Azure Storage Queue、Amazon SQS、RabbitMQ、Kafka）へ引き渡した後、バックグラウンドで処理してください。
べき等性の設計：正しい理由で
受信側を何度同じイベントを処理しても同じ結果を生成するよう設計することは依然として重要ですが、SitecoreAIが失敗した配信を再試行するからではありません。再試行は行いません。 エンドポイントがエラーまたはタイムアウトした場合、Sitecoreは自動的にリクエストを再送信せず、その失敗は自身のログ以外には表示されません。べき等性を構築すべき本当の理由は、単一のオーサリングアクションが同じイベントを複数回発火する可能性があるためです。たとえばitem:savedは1回の単純な編集で複数回トリガーされる可能性があるため、受信側は重複を適切に処理する必要があります。適切なべき等性キー： WebhookItemId、アイテムID＋リビジョン、パブリッシュジョブID。
すべてのエンドポイントを保護
- 常にHTTPSのみを使用
- すべてのwebhookに認可アイテム（APIキー、OAuth 2.0、Basic）を設定：匿名の本番エンドポイントを公開しない
- シークレットをローテーションし、アプリケーション設定ではなくAzure Key VaultやAWS Secrets Managerに保存
- インフラがサポートする場合はIP許可リストを設定
意図的にwebhookをスコープ
グローバルでスコープのないイベントハンドラは、チームが自らの統合を過負荷にする最も一般的な原因です。Rules Engineを使用してテンプレート、コンテンツブランチ、サイト、言語で実行を制限してください。スキップしたルール1つ1つが、不要なHTTPトラフィック、重複処理、インフラコストになります。
すべてを監視
Application Insights、Datadog、Splunk、Elastic、Grafanaなど、すでに使用している可観測性ツールで応答時間、失敗回数、キュー深度を追跡してください。SitecoreAIは失敗したCMSレベルwebhookを代わりに再試行しないため、監視がサイレント障害と古い検索インデックスやCRMへの通知漏れの間に立つ唯一の手段です。
サンプル受信側：Azure Function (.NET 9, Isolated Worker)
[Function("SitecoreAIWebhookReceiver")]
public async Task<HttpResponseData> Run(
[HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequestData req,
[ServiceBusOutput("sitecoreai-events", Connection = "ServiceBusConnection")]
IAsyncCollector<string> queue)
{
string payload = await new StreamReader(req.Body).ReadToEndAsync();
// Push immediately, don't process inline
await queue.AddAsync(payload);
// Acknowledge well within the 10-second window
var response = req.CreateResponse(HttpStatusCode.Accepted);
await response.WriteStringAsync("Webhook received.");
return response;
}
Enter fullscreen mode Exit fullscreen mode
このパターンは、下流処理がどれだけ長くかかっても受信側をSitecoreAIのタイムアウトウィンドウ内に収めます。
最終考察
webhookはSitecoreAIのCMSレイヤーの主要な統合サーフェスであり続けます。XM Cloudが導入したイベント駆動型モデルが、AI機能を重ねて新しい名称で動作しています。検索インデックスの同期、AI評価器によるワークフロー遷移のゲートキーピング、フォームリードのCRMへのルーティング、監査イベントのSIEMへの転送など、どのような用途でもパターンは変わりません：高速に応答し、非同期で処理し、厳密にスコープし、すべてを認証し、Sitecoreが失敗を再試行すると仮定せず重複イベント向けに設計してください。
2026年7月時点のSitecore公式SitecoreAIドキュメント（doc.sitecore.com）に基づき検証済み。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.