AIエージェントのためのリアルタイム意思決定：まず顧客コンテキストレイヤーが必要な理由

Scott Brinker氏によるDatabricksとの最新レポートは、私が長年形作られるのを見てきたことを明確にしています。つまり、マーケティング技術（martech）の「スタック」、つまりお馴染みのテトリスのようなボックス配置が崩壊し始めているということです。その代わりに現れているのは、Scott氏が「コンポーザブル・キャンバス」と呼ぶものです。これは、AIエージェントとカスタムソフトウェアが、インテグレーションパイプラインで苦労するのではなく、共有データ上で動作する、流動的でデータ中心のアーキテクチャです。

レポートを読み進めるうちに、何度も頷いてしまいました。それは、この考え方が容易に受け入れられるものではないから（実際、企業がマーケティング技術について考える方法を根本的に再構築するものです）ではなく、私たちSnowplowが、しばしばそのための共通語彙がないうちから、ずっと前にコミットしていたアーキテクチャの方向性を示しているからです。

いくつか私の考えを共有したいと思います。レポートが強く共鳴する点、Snowplowがそのアーキテクチャでどのように適合するか、そしてAIエージェントが顧客インタラクションでより大きな役割を担うにつれて重要になると私が考える、モデルへの一つの次元の追加についてです。

データプラットフォームがリアルタイム意思決定の中心的な重力源に

レポートの中心的な構造的議論は、データプラットフォーム（Databricks、Snowflake、BigQueryなど）が、martechスタック全体の重力中心になったということです。アプリケーション、エージェント、分析はもはやデータの「上に」存在するのではなく、その「中で」動作します。データプラットフォームは、スタックの底にあるリポジトリではなくなりました。それがスタックなのです。

これは、私たちがSnowplowで長年抱いてきた見解であり、製品の初期の多くの意思決定を形作ったものです。2012年にSnowplowを最初に構築していた頃、一般的なモデルは、ベンダーシステム内に顧客データを蓄積し、それに管理されたアクセスを提供することでした。私たちは反対の立場を取りました。あなたのデータはあなたのインフラストラクチャに属し、あなたのルールによって管理され、あなたが選んだどのツールでもクエリ可能であるべきだと。当時は、それは原則的なアーキテクチャ上のスタンスであり、おそらく少し逆張り的なものでさえあったと感じました。このレポートが明確にしているように、それは現在、大規模で意味のある唯一のアーキテクチャなのです。

カスタマーコンテキストレイヤーとは何か？そしてリアルタイム意思決定がそれに依存する理由

レポートでは、統合された基盤に収束する5つのデータクラスについて説明しています。顧客データ、企業データ、コンテンツデータ、コードデータ、制御データです。顧客データ：「個人およびアカウントプロファイル、取引履歴、行動シグナル（ウェブ訪問、製品利用）」がその中心にあります。

これはSnowplowが動作する場所です。しかし、私はレポートが提示するよりも少しだけフレームを押し広げたいと思います。

顧客レコードと顧客コンテキストの間には、意味のある違いがあります。CRMやCDPは、前者（顧客が誰であるか、どのような取引があるか、どのセグメントに属するか）を長年うまく管理してきました。一貫して提供するのが難しかったのは後者、つまり、顧客が「現在何をしているのか」、そしてその行動が顧客の意図について何を教えてくれるのか、ということです。

行動イベントストリーム、つまり顧客が製品、ウェブサイト、アプリとどのようにインタラクションするかを継続的かつ詳細に記録したものは、意思決定を行おうとするAIエージェントにとって利用可能な最もリッチなリアルタイムシグナルです。そして、それらを正しく取得することは非常に困難です。イベントは収集時に構造化され、スキーマに対して検証され、データ基盤に到達する前にエンリッチされる必要があります。もし、統合プラットフォームに入力される行動データがノイズが多く、一貫性がなく、または不適切にモデル化されている場合、それを操作するAIエージェントは、それらのエラーを大規模に増幅させることになります。

Snowplowはカスタマーコンテキストレイヤーです。顧客が何かをした瞬間（クリック、製品イベント、検索、スクロール）と、それに対応する必要があるデータプラットフォームの間に位置します。私たちの仕事は、行動データが作成された瞬間から、構造化され、適切に管理され、意味的に一貫していることを保証することです。

そして、アイデンティティのないコンテキストはノイズです。リッチな行動ストリームは、タッチポイント、デバイス、セッション全体（匿名および認証済み状態間の移行を含む）で、既知の解決済み個人にそれを紐付ける能力と同じくらいしか役に立ちません。SnowplowのIdentitiesは、データがプラットフォームに着地する前に、収集レイヤーでこの作業を行います。その結果は、単なるイベントストリームではありません。それは、データプラットフォーム、アナリスト、AIエージェントがすべて自信を持って操作できる、各顧客のジャーニーの解決済みで連続的な画像なのです。

コンポーザビリティは常にアーキテクチャであり、機能ではなかった

レポートのコンポーザビリティに関する議論は、最も強力な点の1つです。真にコンポーザブルなキャンバスの前提条件として、オープンデータフォーマット（Delta Lake on Linux Foundation、Apache Iceberg）、オープンプロトコル（エージェント用のMCP）、およびオープンスタンダードを提唱しています。原則は、その上で動作するすべてを多様化できるように、基盤を標準化することです。

私たちはこれを深く信じており、最初からSnowplowをその周りに構築しました。私たちはオープンコアスタンダードを信じています。当社のデータ構造は、Delta Lake on Linux FoundationおよびApache Iceberg上でネイティブに動作します。お客様のクラウドアカウント（Scottの記事ではハイパースケーラーとして言及されています：AWS、GCP、またはAzure）内で動作するため、行動データがお客様の環境を離れることはありません。依存関係や移行リスクとなるような、独自のSnowplowデータストアはありません。スタックのいずれかの部分を置き換えたり拡張したりしたい場合、行動データはすでに適切な場所にあります。つまり、お客様のプラットフォーム内に、オープンフォーマットで、コンポーズする準備ができています。

レポートは、「コンポーザブルCDPは、データをCDPに取り込むのではなく、データにCDP機能をもたらす」ことで、従来のモデルを「反転させる」と指摘しています。Snowplowは、そのカテゴリに名前が付く前からこれを実行していました。なぜなら、私たちにとってコンポーザビリティは、追加した機能ではなく、製品が構築された創業の原則だったからです。

セマンティックレイヤーはプラットフォームより前に始まる

レポートが展開する最も重要なアイデアの1つは、セマンティックレイヤーの役割、特に「一貫性の維持者」と呼ばれるものです。これは、データがそれに触れるすべてのエージェントやアプリケーション全体で、データを意味のある一貫したものにする共有語彙です。「顧客」がチーム間で何を意味するか。「コンバージョン」がどのように計算されるか。「適格なリード」を構成するもの。

私たちの視点から、1つの実践的な観察を加えます。これらの質問のほとんどは、データがプラットフォームに「入った後」ではなく、「入る前」に答えられる必要があります。特に行動データは、悪く収集するのが驚くほど簡単です。イベントは、一貫性のない名前、欠落したプロパティ、未定義のスキーマで到着します。データがプラットフォームに到達する頃には、すでに一貫性がなくなっています。悪いデータの上にセマンティックレイヤーを構築することはできますが、それは構造的な問題を解決するのではなく、覆い隠しているだけです。

SnowplowのスキーマレジストリとEvent Studioによるイベント検証は、収集時にセマンティックな一貫性を強制します。データプラットフォームに着地する前に、定義された構造に準拠しないイベントを拒否またはフラグ付けします。レポートが説明するコンポーザブル・キャンバスでは、数十のエージェントやアプリケーションがすべて同じ行動データから引き出すため、その上に構築されたすべてのものを信頼できるかどうかは、ソースでのデータの品質によって決まります。

エージェントフィードバックループ：リアルタイム意思決定が実際に完了する方法

レポートは、さらに強調する価値のある点を指摘しています。AIエージェントは「コンテキストに飢えている」ということです。顧客レコードが必要なだけでなく、その瞬間に何が起こっているのか、つまり、意図、緊急性、機会を示す行動シグナルを理解する必要があります。

ここにScottが提示したモデルに何かを追加したいと思います。レポートは、データがエージェントに「向かって」流れるものとしてフレーム化しています。エージェントが意思決定を行うために引き出す基盤です。しかし、エージェントが行動した「後」に起こるループ、そしてそのループを閉じることなぜがmartechにおいてますます戦略的に最も重要なデータ問題になるのかについては、十分に展開されていません。これは、Snowplowで私たちが非常に多く考えていることであり、コンポーザブル・キャンバスが実際にどのように機能するかの中心です。

ループは4つのステージで構成されています:

1. Collectステージは、人間とAI駆動のインタラクションの両方からの行動イベントを、データプラットフォームに継続的に流れる構造化されスキーマ検証済みのデータとしてキャプチャします。 しかし、「行動データ」の定義は、ほとんどのアーキテクチャがまだうまくキャプチャできていない第二のクラスのアクティビティを含めるように拡張する必要があります。この第二のクラスには、2つの異なる側面があります。1つ目はAIエージェント分析です。顧客が会話型エージェントと対話したり、パーソナライズされた推奨を受け取ったり、自動化された意思決定システムによって旅が形成されたりする場合、それらのエージェント駆動のインタラクション自体が、人間の行動と同じ厳密さで収集する必要があるイベントです。2つ目はエージェンティック分析です。ユーザーの代わりにAIが調査を行っている場合です。AIがあなたの製品ページを閲覧したり、ドキュメントを読んだり、顧客の代理としてオプションを比較したりするとき、そのトラフィックは意図ですが、非人間的なアクターを介して表現されています。それをフィルタリングすべきボットノイズとして扱うことは、顧客が評価していることについての真実を伝えるシグナルを破棄することを意味します。Snowplowは、これら両方を、直接的な人間のインタラクションとは別に、意図の理解と意思決定のための情報提供に等しく意味のある、構造化された行動イベントとして区別してキャプチャします。
2. Resolve and Enrichステージは、ID解決、セッション、デバイス、タッチポイントを既知の個人に結び付けることによって、生のイベントストリームを首尾一貫した顧客像に変換します。 ここで行動ストリームは首尾一貫した像になります。「ユーザーが3ページを訪問した」ではなく、「現在評価の終盤にいるこのアカウントでは、過去48時間で3人の幹部が価格設定を調査しました。」
3. Serveステージは、リアルタイムでのセッション内パーソナライゼーションと、AIエージェントの意思決定のためのリアルタイムと履歴の組み合わせという2つの同時モードで、強化された行動コンテキストを提供します。セッション内パーソナライゼーションの場合、それはリアルタイムです。データプラットフォームは、この顧客に現在表示されているエクスペリエンスが、このセッションで行っていることを反映するのに十分な速さで行動シグナルを表面化します。AIエージェントの意思決定の場合、それはリアルタイムと履歴の両方です。アカウントの次のベストアクションを調整するエージェントは、ライブ行動ストリームと完全な顧客履歴レコードの両方を活用します。問題は「この顧客は何をしていますか？」だけでなく、「この行動は、彼らのような顧客について私たちが知っていることを考えると、何を意味しますか？」です。
4. Learnステージは、すべてのエージェント決定の結果を最初のクラスの行動イベントとしてデータ基盤にルーティングすることにより、フィードバックループを閉じます。 すべてのエージェント決定の出力、すべてのパーソナライズされたエクスペリエンス、すべての自動化されたアクションは、それ自体が行動イベントです。推奨された製品はカートに追加されましたか？パーソナライズされたメールは開封されましたか？セッション内介入はセッションの軌道を変えましたか？AI調査エージェントのブラウジングセッションは最終的にコンバージョンしましたか？これらの結果は、元の決定を推進したのと同じデータ基盤にフィードバックされる必要があります。このフィードバックなしでは、AIエージェントは日々古くなる履歴データで動作しています。それがあれば、システムは真に自己改善します。

これは、AIエージェント分析とエージェンティック分析がループを完了する場所です。AIエージェントの行動イベントを最初のクラスのデータとして収集しました。これで、人間の行動に適用するのと同じ厳密さで分析できます。どのエージェントがパフォーマンスを発揮していますか？どの意思決定モデルが劣化していますか？AI生成の調査トラフィックはどこでコンバージョンし、どこでドロップオフしていますか？これらの質問は、最初から収集が正しく行われていない限り答えることができません。AIエージェントおよびエージェンティック分析は、後で追加するレポートレイヤーではありません。それらは、そもそもデータをどのように収集したかの結果です。

これは、行動データインフラストラクチャを正しく構築することに固有のフィードバックループです。パイプラインではありません。フライホイールです。

分析から意思決定へ: リアルタイム意思決定のための適切なツール

レポートが示唆していることの中で、特にマーケティングおよびデータリーダーがAIがスタックに実際に何を要求するかを考えている場合に、より多くのスペースを割く価値があると思うのは、行動データを分析に使用することから意思決定に使用することへの移行は、単なるユースケースの拡張ではなく、意味のあるアーキテクチャ上の変更であるということです。

分析は過去を振り返ります。イベントを収集し、モデル化し、結果をクエリします。数分または数時間の遅延は許容されます。データは、決定を下す人間に情報を提供します。

意思決定は未来志向でリアルタイムです。AIエージェントは、この顧客に、このセッションで、今すぐ、どのエクスペリエンスを提供するべきかを判断するために、ミリ秒単位で行動コンテキストを必要とします。インフラストラクチャの要件は異なります。エラーは誰かが来週見つけるダッシュボードの異常として表面化するのではなく、即座に、大規模に提供される貧弱な顧客エクスペリエンスとして表面化するため、データ品質の要件は高くなります。

残念ながら、ほとんどのデータパイプラインはトレードオフを強制します。一部は速度を最適化しますが、履歴の深さを失わせます。他のものはリッチさを最適化しますが、リアルタイム意思決定が必要とするレイテンシヘッドルームを失わせます。

コンポーザブルキャンバスは、同じデータ上で、これら両方を同時に要求します。それは考えられているよりも難しいインフラストラクチャの問題であり、エージェントがミリ秒速で意思決定を行い、履歴コンテキストが別のストアにあることに気づいたときに、後でパッチを当てようとするよりも、基盤で解決する価値のある問題です。

コンテキストグラフと行動データについて

レポートは、私が本当に興味深いと感じた概念を紹介しています。コンテキストグラフです。これは、単に何が起こっただけでなく、なぜそれが起こることが許されたのかをキャプチャする、意思決定トレースの生きた記録です。意思決定の根拠、例外付与、承認チェーン。現在Slackスレッドや人々の頭の中に存在する、制度的記憶のようなものです。

行動イベントストリームは、顧客側のコンテキストグラフの自然な原材料であると主張します。顧客が関与するすべてのエージェントアクション（推奨、トリガーされたセグメント、送信されたメッセージ）は、それを促した行動シグナルにまでさかのぼって追跡可能であるべきです。Snowplowのイベントモデルは、どのシグナルが発火したか、どのデータが観測されたか、どのしきい値が超えられたかという、まさにこの因果関係をキャプチャするように構造化されています。

コンテキストグラフがアーキテクチャパターンとして成熟するにつれて、行動データレイヤーはそれらの基盤となります。何が起こったのかとなぜそれが起こったのかは、最初から正しく収集されていれば、両方ともイベントストリームにエンコードされています。

スケーラブルなリアルタイム意思決定基盤の構築方法

レポートが説明するコンポーザブルキャンバスに向けて構築するあらゆる組織にとって、行動データインフラストラクチャを正しく構築することは、最初で最もレバレッジの高い投資です。最もエキサイティングだからではなく、すべてがその上に実行されるからです。

それは、最初から4つのことを正しく行うことを意味します。

• 初日からスキーマ検証を組み込んだ構造化された収集
• コレクションレイヤーでのID解決、後で後付けするのではなく
• 同じデータでのリアルタイム意思決定と履歴分析のために構築されたパイプライン
• フィードバックループが最初から閉じられるように、AIエージェントのインタラクション出力を最初のクラスの行動イベントとして収集する規律

コンポーザブルアーキテクチャはまた、今日行うベンダーの決定は元に戻せるべきであることを意味します。行動データパイプラインが独自のクラウドインフラストラクチャのオープンフォーマットに書き込む場合、オプション性を保持します。プロプライエタリなストアに書き込む場合、スタックに関するすべての将来の決定を制約する依存関係を作成したことになります。

早期に投資した人にとって、第3の時代はすでにここにあります

レポートは、Martechの第3時代を3〜5年の視野としてフレーム化しています。ここで説明されているアーキテクチャ投資を行ったSnowplowの顧客、つまり、データプラットフォームを運用の中核とし、行動データがリアルタイムエージェントにフィードし、コンポーザブル基盤で実行される完全な意思決定から分析へのフィードバックループを実行している顧客にとって、これは未来の状態ではありません。それはすでに彼らが今日運用している方法です。

それはSnowplow specificallyに関する主張ではありません。それは、アーキテクチャが、それを優先する意思のある組織にとって、今達成可能であることの証拠です。コンポーザブルキャンバスは新しいテクノロジーを待っているわけではありません。それはアーキテクチャ上の決定とそれを行うための確信を待っています。

Scottのレポートは、それらの決定がどうあるべきかの明確で寛大な表現です。この会話がこのレベルの深さで行われていること、そしてその一部であることを嬉しく思います！

Scott Brinkerの完全な調査レポートはこちらをお読みください: The New Martech “Stack” for the AI Age

Scott Brinker、SamsaraのCMO、HPのマーケティングデータサイエンス担当VPを迎え、MartechがAIのためにどのように進化しているかについてのライブウェビナー: ウェビナーに登録

エージェンティック分析のためのデータ基盤が実際にどのようなものになる必要があるかについてさらに深く知りたい場合は、Snowplowのチームがここで詳細をカバーしています: What Is Agentic Analytics? A Guide for Data Leaders

FAQ:

リアルタイム意思決定とバッチ処理の違いは何ですか？ バッチ処理は、インタラクションが発生してから数時間後など、スケジュールされた間隔でデータを収集および分析します。リアルタイム意思決定は、行動シグナルが生成された瞬間にそれを処理し、同じセッション内、多くの場合ミリ秒単位でアクションをトリガーします。インフラストラクチャの要件、データ品質基準、およびレイテンシ許容範囲は、これら 2 つのアプローチで根本的に異なります。

AI エージェントが顧客コンテキストレイヤーを必要とするのはなぜですか？ セッション内意思決定を行う AI エージェントは、昨日の行動ではなく、顧客が現在行っていることを反映した行動コンテキストを必要とします。顧客コンテキストレイヤーは、AI エージェントがリアルタイムでクエリできる、構造化され、ID が解決された行動イベントストリームを提供します。これがないと、エージェントは古いデータに基づいて動作することになり、大規模な意思決定の質が低下します。

顧客レコードと顧客コンテキストの違いは何ですか？ 顧客レコードは、顧客が誰であるか（プロファイル、購入履歴、アカウントステータス、セグメントメンバーシップ）を説明します。顧客コンテキストは、彼らが現在何をしているか（どのページを訪問したか、何を検索したか、どのくらいの時間関与したか、その行動が意図について何をシグナルしているか）を説明します。リアルタイム意思決定には両方が必要ですが、ほとんどのデータスタックは後者よりも前者の方が得意です。

エージェントフィードバックループの 4 つのステージとは何ですか？ エージェントフィードバックループは 4 つのステージを実行します。(1) 収集 — 人間と AI によるインタラクションから行動イベントを構造化データとしてキャプチャします。(2) 解決とエンリッチ — イベントを既知の ID につなぎ合わせ、一貫した顧客像を構築します。(3) サーブ — エンリッチされたコンテキストをリアルタイムで AI エージェントおよびパーソナライゼーションシステムに配信します。(4) 学習 — すべてのエージェント決定の結果をデータ基盤にフィードバックし、システムが継続的に改善されるようにします。

リアルタイム意思決定に必要なデータインフラストラクチャは何ですか？ リアルタイム意思決定には、4 つの基本的な機能が必要です。キャプチャ時点でのスキーマ検証を伴う構造化イベント収集。収集レイヤーでの ID 解決（後から後付けするのではなく）。リアルタイムと履歴の両方のコンテキストを同時に提供できるデータパイプライン。そして、AI エージェントのインタラクション出力を、システムにフィードバックされるファーストクラスの行動イベントとして扱う規律。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事