Snowplow Signalsを使う4工程｜接客AIに今の行動を渡す

「サイトに置いた接客のAIが、いま料金ページを何度も見ている人にも、初めて来た人にも同じ答えを返している」「顧客データ基盤は入れたのに、AIに渡せるのは昨日までの集計だけだ」——サイト内の案内や営業支援にAIエージェントを置いた会社のマーケと情シスから、ここ半年でよく届くようになった声です。顧客のデータを整えればAIは顧客を理解できる、と考えられがちですが、エージェントに足りないのは顧客の名簿ではなく「いまこの人が何をしているか」という数分単位の文脈です。英国の Snowplow が提供する Snowplow Signals は、まさにこの文脈を計算してAIに渡すための仕組みです。この記事では、Snowplow Signals を使ってエージェントに顧客の直近の行動を渡すまでを4つの工程に分け、各工程で決めること、人が確認する範囲、費用とやめ方を整理します。

Snowplow Signals とは：行動の記録から「いまの顧客」を計算してAIに渡す層

Snowplow は、ウェブサイトやアプリ上の行動（どのページを見たか、何をクリックしたか、何を検索したか）を細かく記録し、自社のデータの倉庫に届ける収集基盤として知られてきました。その上に2025年に加わったのが Snowplow Signals です。公式の文書は Signals を、行動データから利用者の属性を即時に計算し、それをAPIでアプリに渡す仕組みと説明しています。属性は、届いた行動の流れから計算するものと、倉庫の表から同期するものの2種類があります。

ここでいう属性とは、「直近10分で見た商品の数」「この訪問で料金ページを開いた回数」「最後に資料を請求してからの日数」のような、行動から計算した値のことです。計算された値は「プロファイルの保管庫」と呼ばれる場所にまとまり、接客のAIや推薦の仕組みはそこから必要な値を読み出します。さらに、条件を満たしたときに自動で動きを起こす「介入」の仕組みもあり、公式は例として、高額のカートを放置した人に割引を出すといった使い方を挙げています。

公式の位置づけは、AIで動く製品のための「顧客の文脈の層」です。読み出しの速さを強く打ち出していて、2026年1月の更新では単純な属性の読み出しで、ほぼすべての要求が10ミリ秒未満に収まるようになったと発表しました。ただし、この数字は同社の計測です。自社のサイトで同じ速さが出るかは、属性の数や期間の長さで変わると同社自身も書いているので、試用で確かめる項目に入れておきます。

2025年秋の一般提供から、2026年10月のMCPサーバーまで

公式のリリースノートを追うと、Signals は短い間隔で機能を足してきました。2025年5月に発表、2025年9月30日に一般提供、11月5日には試してみるための試用環境と、よくある使い方を組み立て済みの導入テンプレートを公開しました。12月には倉庫につながずに、流れの計算だけで動かす構成にも対応しています。2026年1月には読み出しの高速化と、取引・商品閲覧・キャンペーンの貢献・基本的なウェブ行動・閲覧環境の5種類の属性をまとめて作るテンプレートを加えました。

2026年に入ってからも、3月に介入の事前確認、6月に過去の行動から属性をさかのぼって計算する機能、8月に機械学習の学習用データを作る機能と Databricks への対応、最後の行動からの経過時間や時間帯といった属性の追加、10月7日に一つの行動の中の複数の項目を組み合わせて新しい値を作る機能と続きます。そして2026年10月15日に、Signals の属性をMCPで読み出せるサーバーが加わりました。

このMCPサーバーは、Signals のAPIの住所の下にそのまま置かれ、別途インストールする必要はないと説明されています。提供される道具は読み取り専用で、公開済みの属性のまとまりの一覧と値、そして「エージェント向けの文脈」と呼ばれる直近の生の行動の並びを読み出せます。なお Snowplow には、Claude などの開発用AIから計測の設計や設定を操作するための別のMCPサーバーもあり、こちらは管理用、10月の Signals のものは自社製品のエージェントに顧客の文脈を読ませる用と、役割が分かれています。

誤解：「顧客データ基盤があれば、エージェントに顧客を教えられる」

よくある誤解は、顧客データ基盤（CDP）や顧客管理にある情報をAIに渡せば、接客は個別化できるというものです。CDPが得意なのは、複数の出どころのデータを一人の顧客にまとめ、セグメントを作って配信の道具に送ることです。多くの場合、その更新は数時間から一日単位の処理で行われます。一方、サイトの案内役のAIが答えを変えたいのは、同じ訪問の中で数分前に起きたことです。料金ページを3回行き来した、導入事例を2本読んだ、問い合わせの入力欄を途中でやめた、といった事実です。

もう一つの違いは、誰を単位に数えるかです。CDPは名寄せした「顧客」を単位にしますが、BtoBのサイトを訪れる人の多くはまだ名前の分からない訪問者です。Signals は、ログインした利用者だけでなく、ブラウザ単位の訪問者や1回の訪問（セッション）単位でも属性を計算できます。公式の説明では、個人に合わせたいときは訪問者の単位、その場の訪問だけに合わせたいときはセッションの単位を使うとされています。

つまり、CDPと Signals はどちらかを選ぶものではなく、「昨日までに分かっている顧客像」と「いまの訪問で起きていること」を別の層で持つという設計です。CDPのAIに任せる範囲や承認の閾値の話は別の記事で扱ったので、ここでは Signals で「いま」を渡すときの手順に絞ります。なお、属性の名前や指標の定義をAIに正しく伝える意味の層の話も別の論点で、ここでは扱いません。

全体像：エージェントに顧客の「いま」を渡す4工程

手順は4つに分けると整理しやすくなります。どの工程も、決めるのは技術の担当だけではありません。マーケが「どの判断に使うか」を決め、法務と情シスが「何を、どれだけ持つか」を決め、データの担当が「どこで計算するか」を決めるという分担になります。最初の工程を飛ばして、取れる属性を全部渡すところから始めると、後の3工程がすべて重くなります。

以下、工程ごとに決めることを見ていきます。工程4の後に、MCPで渡すときの追加の確認、効果の測り方、CDPとの分担、費用とやめ方を続けます。

工程1：エージェントにさせたい判断から、渡す属性を逆算する

最初に書き出すのは属性ではなく、エージェントにどんな判断を手伝わせたいかです。たとえばBtoBのサイトの案内役なら、「導入を比較している段階の人には事例と比較資料を案内する」「料金を調べている人には見積りの前提を説明する」「既存顧客がサポートの記事を何本も読んでいたら、問い合わせ窓口を先に示す」といった判断です。判断が決まれば、必要な属性も自然に決まります。料金ページの閲覧回数、事例の閲覧本数、サポート記事の閲覧本数、といった具合です。

属性は増やすほど良くなるわけではありません。エージェントに渡す文脈が長くなると、AIがどの値を重く見たのか、人が後から説明しにくくなります。最初は5〜10個に絞り、それぞれに「どの判断に使うか」を一行で書いておくと、後で効果が出なかったときに見直す場所が分かります。2026年1月に加わった属性のテンプレートは、取引なら5個、キャンペーンの貢献なら12個といったまとまりで属性を作れますが、テンプレートをそのまま全部使うのではなく、判断に要るものだけを残す使い方が向いています。

BtoBで気をつけたいのは、行動が少ないことです。BtoCの通販と違い、一人の訪問者が月に数回しか来ないことも珍しくありません。「直近10分の閲覧数」のような短い窓の属性は、BtoBではほとんどの人が0か1になり、判断の材料になりにくいことがあります。短い窓はその場の訪問の文脈に、長い窓は検討の深さにと使い分け、どちらが判断に効くかは工程4の測定で確かめます。

工程1の続き：数える単位と、期間の窓の決め方

Signals の属性は「属性のまとまり」ごとに定義し、まとまりごとに何を単位に数えるか（属性の鍵）を決めます。公式の文書では、ログイン後の利用者の識別子、ブラウザの訪問者の識別子、ネットワーク上の識別子、1回の訪問の識別子が組み込みの単位として挙げられています。同じ「直近10分の閲覧数」でも、単位を利用者にすればその人の閲覧数、単位を商品にすればその商品が見られた回数になる、と説明されています。

単位の選び方は、そのままプライバシーの重さにつながります。セッション単位の属性は、その訪問が終われば意味を失うので、比較的軽い扱いで済みます。訪問者単位やログイン利用者単位の属性は、同じ人を時間をまたいで追うことになるので、工程2の同意と保存期間の決めごとがより重要になります。迷ったら、まずセッション単位で始めるのが安全です。セッション単位で効果が見えてから、訪問者単位に広げるかを決めても遅くありません。

期間の窓にも注意点があります。公式の文書によると、一定期間内の行動を数える属性は流れの計算でしか作れず、倉庫の表から同期する属性では使えません。また、2026年1月の更新以前は、期間つきの属性は直近の100件の行動だけで計算されていたと同社自身が説明しており、その後、行動の量や期間の長さにかかわらず正確になる方式に変わりました。以前の試用で作った属性の値を、そのまま効果の比較の基準にしないほうがよいということです。

• 属性のまとまりには版があり、アプリが読むのは「サービス」と呼ばれる窓口を通して固定した版。定義を変えるときは窓口の版を差し替える形になると公式は説明している
• 定義を変えた日付と理由を記録しておくと、効果の数字が動いたときに、行動が変わったのか定義が変わったのかを分けて読める

工程2：どの同意の状態の行動を使い、どれだけ残すか

行動の記録から属性を計算することは、日本では個人情報保護法の個人関連情報や、電気通信事業法の外部送信規律に関わる論点になり得ます。法令の一般論は別の記事に譲りますが、Signals を使うときに具体的に決めるのは次の3点です。どの同意の状態の訪問者の行動を属性の計算に使うか、計算した属性をどれだけの期間残すか、属性をAIの提供元に送ってよいかです。

1点目は、同意管理の仕組みと計測の設定を突き合わせて決めます。分析目的の計測には同意していても、個別化の目的には同意していない訪問者がいる、という設計のサイトもあります。その場合、属性の計算そのものを止めるのか、計算はしてもエージェントに渡さないのかを決め、同意の区分ごとに「計算する／渡す」の表を作っておくと、後で監査に聞かれたときに説明できます。

2点目の保存期間について、公式の文書は、全期間を対象にした属性には保存期間（TTL）が適用され、保管庫は設定に従って古いデータを消すと説明しています。つまり、消す期間は製品が勝手に決めてくれるものではなく、自社が設定するものです。プライバシーポリシーに書いた保存期間と、Signals の設定と、倉庫に残る元の行動の記録の保存期間が食い違っていないかを、法務と情シスで一度並べて確認します。

工程2の続き：生の行動の並びをAIに渡すかどうか

10月に加わったMCPサーバーでは、計算済みの属性に加えて、「エージェント向けの文脈」として直近の行動を生のまま順番に並べたものも読み出せます。計算済みの属性が「料金ページを3回見た」という要約だとすれば、生の並びは「何時何分にどのページを開き、次に何をクリックしたか」という記録そのものです。AIにとっては材料が豊かになりますが、渡す情報の量と細かさも一気に増えます。

公式の説明では、MCPサーバーはエージェントに、両方の一覧を先に確かめ、計算済みの値で答えられるならそちらを優先するよう指示しているとされています。自社の判断でも同じ順番をおすすめします。まず計算済みの属性だけで始め、生の並びは「属性では足りない」と分かった用途に限って開くという順です。生の並びには、検索窓に入れた語や入力途中の内容など、本人が人に見せるつもりのなかった情報が混じる可能性があるからです。

生の並びを開くと決めた場合は、どの種類の行動を含めるか、何件までさかのぼるかを絞ります。公式の文書は、エージェント向けの文脈は件数と期間の上限を設定して絞ると説明していますが、具体的な上限値は確認できませんでした。上限は自社で決める値として、工程2の表に書き込んでおきます。

• 取れる行動をすべて生のまま、件数の上限なしでエージェントに渡す
• 検索窓やフォームの入力途中の内容を、属性や生の並びに含める
• 個別化に同意していない訪問者の属性も、計算できるからとエージェントに渡す
• プライバシーポリシーの保存期間と、Signals の保存期間の設定を突き合わせていない

工程3：計算をどこで持つか（流れ・倉庫・倉庫なし）

Signals の計算には二つの道があります。一つは流れの計算で、収集した行動を整えた直後に読み、属性を即時に計算して保管庫に入れます。もう一つは倉庫からの同期で、自社のデータの倉庫にある計算済みの表を一定の間隔で保管庫に写します。後者は即時ではありませんが、Snowplow 以外の出どころのデータ、たとえば顧客管理にある契約の状況や、過去の購買の集計も属性として渡せます。

どちらで持つかの目安は、「数分以内に変わる値は流れで、日単位で変わる値は倉庫で」です。料金ページの閲覧回数は流れで、契約の更新月や業種は倉庫で、という分け方です。公式の案内では、Signals は AWS か Google のクラウド上で動かし、Snowflake や BigQuery の倉庫につなぐ構成が示されており、2026年8月には Databricks にも対応し、倉庫から同期する頻度を選べるようになりました。2025年12月からは、倉庫につながずに流れの計算だけで動かす構成も選べます。

ここで情シスが確かめたいのは、どのデータがどの会社の管理する環境に置かれるかです。元の行動の記録が自社の倉庫に入る構成でも、保管庫やMCPサーバーがどこで動き、誰が運用するのかは契約の形によって変わり得ます。公式の資料だけでは自社の契約の場合を判断できないので、保管庫の置き場所の地域、運用する主体、障害時に誰が値を見られるかの3点を、導入前に書面で確認します。

流れの計算には、もう一つ見落としやすい性質があります。公式の文書によると、流れの属性は公開した時点から計算が始まり、それ以前の行動は、さかのぼりの計算を有効にしない限り反映されません。さかのぼりの計算には倉庫への接続が必要です。倉庫なしの構成で始めると、属性は公開した日からしか積み上がらないので、効果の測定をいつから始めるかの計画に織り込んでおきます。

工程4：属性を受け取ったエージェントに、してよいこと・いけないこと

属性を渡した後に起きる問題の多くは、AIが属性から「この人はこういう人だ」と決めつけてしまうことから生まれます。料金ページを何度も見た訪問者に、AIが「ご予算でお悩みですね」と言い出せば、見られていると感じた相手は離れていきます。属性は答えの内容や順番を選ぶための材料にとどめ、属性の値そのものを相手に言わない、という線を最初に決めます。

もう一つの線は、結果が重い行動をAIの判断に任せないことです。Signals の介入の仕組みは、条件を満たしたときに割引や働きかけを起こせますが、値引きの提示、営業担当への引き渡し、資料の個別送付のように結果が残るものは、人が決めた規則で起こし、AIには起こさせないのが安全です。公式の文書でも、介入は事前に条件を決めておく規則型が基本で、条件を初めて満たしたときに1回だけ起きると説明されています。AIの会話の中で臨機応変に値引きを決めさせる設計にはしない、ということです。

エージェントの行動	属性を使ってよいか	決める人
答える内容・案内する資料の順番を変える	使ってよい	マーケが規則を決め、AIが選ぶ
問い合わせ窓口やデモ予約への導線を先に出す	使ってよい	マーケが条件を決める
属性の値を相手に伝える（何回見ましたね、など）	使わない	－
値引きや特別条件を提示する	AIには使わせない	人が決めた規則で介入を起こす
営業担当に引き渡す・通知する	材料には使うが、通知は規則で	営業管理が条件を承認
業種や企業規模を推測して断定する	使わない	－

表の線を守るには、エージェントへの指示文に書くだけでは足りません。指示文はAIが守るとは限らないからです。エージェントに渡す属性そのものを、してよい行動に必要なものだけに絞ることが、いちばん確かな歯止めになります。値引きの判断に使う属性は、そもそも会話のAIには渡さない、という設計です。

MCPで渡すときに追加で確かめること

10月のMCPサーバーを使うと、属性を読む処理を自社のアプリに書かなくても、エージェントが自分で属性の一覧を調べ、必要な値を読み出せます。公式の説明では、エージェントは呼び出しのたびに道具の説明文を読むので、自社が書いた説明文が、どの属性を読むかを左右するとされています。新しく公開した属性は、アプリを変えなくても接続済みのエージェントから見えるようになります。便利な反面、公開した瞬間にAIの読める範囲が広がる、ということでもあります。

そこで、属性の公開を承認の手順に入れることをおすすめします。データの担当が属性を作っても、エージェントから見える状態にする前に、マーケと情シスが「どの判断に使うか」「同意の区分に合っているか」を確かめる、という一段です。説明文もAIへの指示の一部なので、「値引きの判断に使う」「この人の予算を推測する」のような、工程4で禁じた使い方を誘う書き方をしていないかを見ます。

認証についても確かめます。公式の説明では、MCPサーバーは既存の Snowplow のAPIの鍵で認証します。つまり、鍵を持つエージェントは、公開された属性を読めるということです。どの顧客の属性を読むかは、エージェントに渡すセッションや利用者の識別子で決まるので、会話の相手と違う人の識別子が渡らない作りになっているかを、開発の担当と一緒に試験します。鍵の管理者、鍵を替える周期、使わなくなったエージェントの鍵を止める手順も、ほかのAPIの鍵と同じ台帳で管理します。

効果の測り方：属性を使う群と使わない群を分ける

エージェントに文脈を渡した効果は、会話の満足度の印象では測れません。同じ時期に、属性を渡すエージェントと渡さないエージェントに訪問者を分けて比べるのが基本です。見る指標は、サイト内の案内なら資料請求やデモ予約への到達率、営業支援なら営業が引き継いだ案件の商談化の率、サポートなら有人の窓口に回った割合など、工程1で書いた判断に対応するものを選びます。

BtoBのサイトは訪問者が少ないので、比較に必要な期間が長くなりがちです。数週間で差が出ないからといって属性を足し続けると、何が効いたのか分からなくなります。一度に変えるのは属性のまとまり一つだけと決め、比較の期間と終える条件を先に書いておきます。Signals には2026年8月に、属性から機械学習の学習用データを倉庫に作る機能も加わりましたが、学習した予測をエージェントの判断に使う段階は、まず単純な属性で効果を確かめた後の話です。

数字と一緒に、会話の記録も定期的に読みます。AIが属性を変な形で使っていないか、たとえば属性の値をそのまま口にしていないか、属性から相手を決めつけていないかは、数字には出ません。月に一度、属性を使った会話を数十件抜き出して人が読む場を作り、問題があれば工程4の表と、渡す属性の範囲を見直します。

CDP・顧客管理との分担

Signals を入れると、顧客の情報を持つ場所がCDP、顧客管理、Signals の保管庫の3つに増えます。分担を決めずに始めると、同じ「最終接触日」が3か所で違う値になる、といった混乱が起きます。どの値の正本がどこにあるかを先に決めておきます。

持つ情報	正本の置き場所	Signals での扱い
会社名・業種・契約の状況	顧客管理	倉庫から同期して読むだけ
名寄せした顧客像・セグメント	CDP	必要なものだけ倉庫経由で同期
直近の訪問での行動・閲覧の深さ	Signals の保管庫	流れで即時に計算
同意の状態	同意管理の仕組み	計算と受け渡しの条件に使う

この分担で大事なのは、Signals の保管庫を「新しい顧客台帳」にしないことです。保管庫の値は即時性が強みですが、保存期間で消えていく前提の値です。営業が後から確かめたい情報や、監査で問われる情報は、正本の置き場所に残します。マーケの担当は、エージェントの判断に使う値と、レポートで使う値の出どころが同じかどうかを、月次の見直しで確かめます。

費用の増え方と、やめ方

Signals は Snowplow の収集基盤の上で動くので、前提として Snowplow の計測が入っている必要があります。公式の文書は無料の枠があると案内していますが、本番の料金は公開の資料からは確認できず、個別の見積りになると考えておいたほうがよいでしょう。費用の増え方を左右しそうなのは、計測する行動の量、属性のまとまりの数と期間の長さ、読み出しの回数です。エージェントは会話のたびに属性を読むので、会話が増えれば読み出しも増えます。

それとは別に、AIの側の費用も増えます。属性や生の行動の並びをエージェントの指示に足すと、1回の会話でAIに送る量が増え、モデルの利用料に跳ね返ります。属性を絞ることは、プライバシーのためだけでなく費用のためでもあるということです。試用の段階で、1会話あたりに渡す量と、その分の費用の増え方を測っておきます。

やめるときの手順も、始める前に書いておきます。まずエージェントの接続を止め、MCPサーバーや属性の読み出しに使っていた鍵を無効にします。次に、属性の公開をやめ、保管庫に残った値の削除を依頼して、削除の記録をもらいます。元の行動の記録は自社の倉庫に残るので、Signals をやめても、計測そのものを続けるかどうかは別に判断できます。この「層を外しても土台が残る」構造は、やめやすさの点では利点です。

よくある質問

Snowplow を使っていなくても Signals だけ導入できますか

公式の文書では、Signals を使うには Snowplow の計測の仕組みが必要とされています。倉庫の表から同期する属性は Snowplow 以外のデータも扱えますが、即時の属性を作るには Snowplow で行動を集めている必要があります。すでに別の計測の道具を使っている場合は、二重の計測になる期間をどう扱うかも含めて検討します。

AIエージェントの開発はどの道具でもよいのですか

属性はAPIでも、10月からはMCPでも読めるので、特定のAIの道具に縛られにくい作りです。公式の手引きには、Vercel の開発の道具や Google のエージェント開発の道具と組み合わせる例、Amazon のエージェントの実行基盤と連携する案内があります。手引きの一例では、チャットの要求のたびに属性を読み出し、AIへの指示文の末尾に付け足す形が紹介されています。

属性を渡せば、AIの答えの誤りは減りますか

誤りが減るとは限りません。属性が教えるのは相手の状況であって、製品の正しい情報ではないからです。答えの中身の正しさは、別に用意した資料と人の確認で担保する必要があります。属性で変わるのは、どの答えを先に出すか、どの資料を案内するかです。

まとめ

Snowplow Signals は、行動の記録から顧客の「いま」を計算して、AIエージェントに渡すための層です。2025年秋の一般提供から、2026年10月のMCPサーバーまで、渡し方は手軽になってきました。だからこそ、何を渡し、どれだけ残し、AIに何をさせないかを人が先に決めることが導入の中心になります。渡す属性を判断から逆算して絞る、同意の区分と保存期間を表にする、計算の置き場所と運用の主体を確かめる、結果の重い行動は人の規則に残す。この4工程を、属性を使う群と使わない群の比較で確かめながら少しずつ広げていくのが、失敗の少ない進め方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。