冒頭は記事のために生成したイメージ映像です。実機、実在施設、観測データを示すものではありません。
商品のことを初めて知ったのは、ある人が何日もかけて書いた比較記事だった。
その記事には、公式仕様の言い換えだけでは分からないことが書いてある。実際に使って困った点。条件を変えて測った結果。向いている人と、買わない方がいい人。
読者はその場では買わなかった。後日、AIへ相談した。
AIは複数の情報源を読み、候補を絞り、長所と注意点を説明する。利用者は納得し、そのままAgentに購入を任せた。
商品は売れた。merchantには注文が入り、AI platformにも「購入を完了させた」という成果が残る。
けれど、最初の判断材料を作った記事のaffiliate dashboardは、0円のままだ。
不具合ではない。リンクが一度も踏まれていないからである。
では、この売上を作ったのは誰だろう。
最後に決済を通したAgentか。商品を並べたmerchantか。候補を推薦したAIか。それとも、比較できるだけの一次情報を現実から運んできた発信者か。
Agent時代のaffiliateで問われるのは、clickが残るかどうかではない。
購買判断へ貢献した履歴を、決済まで運べるか。
Affiliateは「成果」に払っていたのではなく、観測できたclickに払っていた
Affiliate marketingは、成果報酬の仕組みとして説明される。
記事や動画で商品を紹介する。読者が専用linkを踏む。click IDやcookieが残る。一定期間内に購入されれば、publisherへcommissionが支払われる。
この仕組みはよくできている。広告枠を先に買うのではなく、実際のsaleやleadへ費用を払える。小さな発信者も、大きな営業組織を持たずに、自分の解説と購買を結びつけられた。
ただし、ここには省略されがちな前提がある。
Affiliateが直接測ってきたのは「誰が人の判断を作ったか」ではない。誰の識別子を付けたclickが、購入の前に観測されたかである。
Awinの2026年版Tracking FAQでも、affiliate linkがclickされるとbrowserへcookieを置き、複数のaffiliate linkがclickされた場合、標準では最後のclickを送ったaffiliateへsaleを帰属すると説明されている。
Last-clickは、単純で、速く、精算しやすい。
しかし、最後にcouponを探したsiteと、購入候補そのものを発見させたreviewが別なら、最後のclickだけで貢献の全体は表せない。
IABの2026年版measurement whitepaperも、last-clickはconversion直前のtouchpointへすべてのcreditを与え、それ以前のchannelを落とすため、bottom funnelへ偏り得ると注意している。
Affiliate業界自身も、この歪みを知らないわけではない。
Awinはbrowser extensionなど一部の接触を低優先度のSoft Clickとして扱い、content publisherやinfluencerの通常clickを最後の瞬間に上書きしない仕組みを説明している。Advanced向けのAttribution Managerでは、publisher、期間、first/last clickなどに応じてruleも変えられる。
つまり、Agentが来る前から、業界は気づいていた。
最後に現れた人と、最も価値を作った人は、同じとは限らない。
Agentは、購買導線を短くする。そしてclickの札を落とす
これまでのWebでは、発信者のsiteからmerchantへ移動する瞬間があった。
そこにaffiliate IDを載せられた。誰が送った訪問かを、merchant側へ引き渡せた。
Agentic commerceでは、この境界が消え始める。
利用者はAIへ条件を話す。AIが複数siteを読み、比較し、候補を出す。Agentが在庫と価格を確認し、checkoutを作り、利用者の承認を得て購入する。
OpenAIは2025年にChatGPT内のInstant CheckoutとAgentic Commerce Protocolを発表した。その後2026年3月には、初期のInstant Checkoutだけではmerchantが求める柔軟性を十分に満たせなかったとして、merchant自身のcheckoutも選べるようにし、product discoveryへ重点を移している。
GoogleのUniversal Commerce Protocolも、AI ModeやGemini上で、発見から直接購入へ進めるための共通言語を目指す。merchantはMerchant of Recordのまま、checkout、payment、order lifecycleをAI surfaceとやり取りする。
これらは、利用者にとっては自然な進歩だ。tabを何枚も開き、同じspecを見比べ、住所と決済情報を何度も入力する必要が減る。
しかし、購買導線を一つの会話へ畳むほど、従来のaffiliate linkを踏む場面も減る。
商品は売れる。Agentの成果も記録できる。だが、AIが候補を作る時に読んだ記事は、transactionから切り離される。
これは「送客が少し減る」というだけの話ではない。
購買判断を作った上流と、購入を完了した下流の間で、識別子が途切れる。
紹介リンクを通らない購買経路の概念例。すべてのAgent購入で報酬がゼロになるという実測結果ではない。 図を大きく開く
決済のレシートは作れても、貢献のレシートはまだ空白である
Agent commerceのprotocolは、何も記録できないわけではない。
むしろ、決済の安全性とaccountabilityは急速に整備されている。
GoogleのAgent Payments Protocol（AP2）は、利用者の意図、確定したcheckout、payment authorizationを改ざんしにくいcredentialでつなぎ、transactionの監査証跡を作る。誰が何を買う権限をAgentへ与え、merchantがどの条件で販売し、どの決済が実行されたかを確認しやすくする。
UCPも、Googleの実装ではUCP-Agent:Profile headerやGoogle/UCPで始まるuser-agent、checkout・order・transactionのAPI lifecycleにより、通常のWeb trafficとAI surface由来の取引を区別できるとしている。
これは重要である。Agentが勝手に買ったのか、利用者が承認したのか分からない世界では、commerceそのものが成立しない。
ただし、ここで作られているのは主にpayment receiptだ。
誰が購入を承認したか。
どのmerchantが、何を、いくらで売ったか。
どのAgent・commerce surfaceを通ったか。
決済とorderがどう完了したか。
一方、発信者に必要なのはcontribution receipt――貢献のレシートである。
最初に候補を発見させた情報源はどれか。
specの違いを整理したのは誰か。
riskや失敗条件を説明し、選択を変えた記事はどれか。
最終推薦で、どの一次検証が根拠になったか。
2026年8月20日時点で確認できるUCP/AP2の一次資料は、merchant integration、user intent、payment、order accountabilityを中心にしている。第三者のreview、blog、動画など、上流の情報源へcommissionを分配する共通標準を約束するものではない。
決済のレシートが精密になっても、貢献欄が空白なら、発信者の経済は戻らない。
UCP/AP2は2026年8月時点の一次資料に基づく整理。貢献側の共通規格はまだ存在しないと本文は明記。 図を大きく開く
広告のmeasurementが進んでも、organic sourceの対価とは別会計である
AI内広告では、結果を測る仕組みも進んでいる。
OpenAIは2026年5月、ChatGPT AdsへCPC biddingを加え、Conversions APIとpixel-based measurementを導入したと発表した。広告を見た後のpurchase、lead、sign-upなどを、集計された形でadvertiserが理解しやすくする。
広告主にとって必要な機能である。AIで商品を知った人が実際に行動したか分からなければ、広告費を投じ続けられない。
しかし、ここでも二つの線を混ぜてはいけない。
広告のclickやconversionを測ることと、organic answerの材料になった情報源へcreditを戻すことは別である。
AIが独立したproduct resultを出し、その比較材料として複数のreviewを使い、別枠のSponsored広告がclickされて購入へ至ったとする。
advertiserとAI platformはconversionを観測できる。
では、比較の土台を作ったpublisherはどうなるのか。
「広告が売れた」というmeasurementをどれだけ高度にしても、organic sourceとの接続を設計しなければ、そのpublisherはreportに現れない。
Pay Per CrawlとRSLは、「clickの前」に値札を置く
情報源への対価を、購入後のcommissionだけで考えない動きも始まっている。
Cloudflareが2025年に始めたPay Per Crawlは、publisherがAI crawlerごとにallow、charge、blockを選び、取得requestへ価格を付けるprivate betaだった。支払い意思を示さないcrawlerへHTTP 402 Payment Requiredを返し、認証された取得が成立した時に課金eventを記録する。
ただしCloudflare自身が2026年、crawl回数は価値を測るには粗いと認めている。
一度取得した記事が何千件のanswerへ使われることもあれば、何度取得されても一度も使われないこともあるからだ。
そこで同社はPay Per Useへ進める実験を発表した。Ceramic.aiの構想では、publisherがopt inし、そのcontentがsearch resultへ現れたquery単位で支払いを行う。発表時点では実験であり、Web全体へ普及した制度ではない。
Really Simple Licensing（RSL）1.0も、contentの機械可読な利用条件として、crawlごとの支払い、AI outputへのuseごとの支払い、attributionなどを表現できる。robots.txt、HTTP header、HTML、RSSからlicenseを発見できる設計だ。
これは、二択だったWebに重要な中間領域を作る。
「無料で全部読ませる」でも、「AIを全部blockする」でもない。何に使ってよいか、どの利用ならcreditやpaymentが必要かを、機械同士で伝えられる。
ただし、RSL fileを置けば自動的に収益が振り込まれるわけではない。crawlerが条件へ準拠し、license取得・利用報告・精算・監査が実装される必要がある。
そして、pay-per-useもaffiliate attributionと同じではない。
回答へ表示されたことに払うのか。購入候補へ入ったことに払うのか。最終的なsaleへ何％寄与したかに払うのか。測っている価値が違う。
次の単位はlinkではなく、「貢献のレシート」である
従来のaffiliate linkには、三つの役割が詰め込まれていた。
publisherを識別する。
利用者の移動をmerchantへ伝える。
後の購入と結び、commissionを精算する。
Agentが移動を代行し、人がlinkを踏まなくなるなら、この三役を分解して別の場所へ実装すればよい。
必要なのは、少なくとも四つの層である。
1. Source identity
canonical URL、publisher、author、公開・更新日、content ID、licenseを一意にする。AIが文章の断片を持ち出しても、どの正本から来たかを戻せるようにする。
2. Contribution event
情報源が、発見、evidence、比較、risk説明、推薦のどこで使われたかを記録する。「取得した」と「判断を変えた」を同じにしない。
3. Transaction link
Agent sessionからmerchant orderまで、個人の会話内容を晒さないopaque IDで接続する。UCP/AP2が作るtransaction trailへ、上流sourceのreceiptを合流させる。
4. Settlement rule
last-clickだけでなく、最初の発見、途中のassist、最後のclose、content useやlicenseを、programの目的に合わせて配分する。重み、lookback、除外理由、異議申立てを説明できるようにする。
これは、すべてのsourceへ均等に小銭を撒く提案ではない。
薄い言い換え記事と、数週間の実機検証を同じにすれば、質の低いsourceを大量生産する動機になる。互いの文章を引用し合い、AI回答へ顔を出す回数だけ増やす「citation laundering」も起き得る。
だから、貢献のレシートは、表示回数だけでなく、originality、freshness、検証可能性、decision impactを区別しなければならない。
同時に、その評価をplatformの秘密のscoreだけにしてはいけない。
Last-clickの次が、Last-platformになってはいけない
AI attributionを導入すれば、自然に公平になるわけではない。
むしろ小規模な発信者にとっては、新しい従属が始まる可能性がある。
これまでは検索順位とaffiliate networkのruleを気にしていた。これからは、AIのretrievalに入ったか、引用されたか、推薦のweightを何％もらったか、支払対象に分類されたかまで、platform側の見えない判断へ依存する。
「あなたの記事は回答に使われました。しかし購入への貢献は0.3％未満なので支払い対象外です」と言われても、計算式も母数も見えなければ検証できない。
Multi-touch attributionも、真実そのものではない。
touchpointを全部並べても、単に同じpathに居合わせただけかもしれない。Google Analyticsのdata-driven attributionは、conversionしたpathとしなかったpathを比較してfractional creditを割り当てるが、それも観測できたinteractionとmodelの条件に依存する。
IABが提案するように、attributionだけでなく、modeling、experiment、incrementalityを組み合わせて校正する必要がある。
さらに、privacyも守らなければならない。
利用者がAIへ何を相談し、どの健康問題や家計事情を話したかを、commissionのためにpublisherへ渡すべきではない。必要なのはraw conversationではなく、source ID、役割、時刻、license、匿名化されたtransaction anchorといった最小限の情報である。
公平な分配には、透明性が要る。透明性には、privacyを壊さない設計が要る。
発信者が今日からできる、六つの準備
共通protocolが完成するまで、何もできないわけではない。
1. 「誰の、いつの情報か」を機械にも分かる形で固定する
canonical URL、署名、公開日、更新日、製品名・型番、根拠linkを一貫させる。記事を転載する場合も正本を示す。
2. Affiliate link以外の識別方法を持つ
独自coupon code、campaign ID、sub ID、server-side postback、Conversion APIに対応するprogramを選ぶ。人がlinkを踏まなくても、orderへpublisher IDを渡せる余地を作る。
3. AI referralとcrawlerと購入を、同じ数字にしない
bot request、AIからのhuman visit、指名検索、coupon利用、問い合わせ、saleを別々に見る。「AIに読まれた回数」を売上の代わりにしない。
4. Last-click以外のreportをmerchantへ求める
first discovery、assist、closeを分け、content publisherの通常clickをcheckout直前のextensionやcouponに上書きさせないruleがあるか確認する。
5. 貢献を実験で確かめる
unique code、期間を分けたholdout、購入後survey、指名検索の変化を使う。attribution dashboardの数字だけで、自分の記事がsaleを生んだとも、生んでいないとも決めない。
6. 一社の精算ruleだけで生きない
Affiliate commissionに加え、membership、newsletter、相談、独自商品、license、sponsorshipなど、読者や利用者と直接つながる還流路を持つ。
リンクが消えても、貢献まで消してはいけない
Affiliate linkは、永遠の形式ではない。
かつては、Web上の移動を観測し、発信者の貢献をpurchaseへ結ぶ、現実的で安価な発明だった。
Agentが探索、比較、推薦、checkoutを代行するなら、その移動は見えにくくなる。最後のclickへ100％を載せる精算は、さらに現実から離れていく。
だからといって、情報発信の価値がなくなるわけではない。
AIが勧める商品にも、判断の材料が要る。
誰かが実際に買い、使い、測り、失敗し、比較し、何が違うかを言葉にする。その一次の仕事がなければ、Agentはmerchant catalogと古い評判を混ぜるだけになる。
新しい体験と情報を生む側に、creditとmeritが戻らなければ、媒体は持たない。
媒体が持たなければ、AIの回答も、commerceの候補も、やがて薄くなる。
次に作るべきなのは、clickを無理に延命する仕組みではない。価値がどこから来て、どの判断を動かし、何が売れたかをつなぐ、貢献のレシートである。
