UCPとACPの違いとは？EC事業者が2026年に取るべき対応

UCPとACPの違いとは？EC事業者が2026年に取るべき対応

この記事の結論: UCP（Google主導、商品発見から決済・購入後まで一気通貫の開放型プロトコル）とACP（OpenAI・Stripe主導、決済に特化した先行実装）は設計思想も収益構造もまったく異なる。2026年3月にOpenAIがInstant Checkoutを縮小した一方、GoogleはUCPをAI Mode・Gemini・YouTube Shoppingに実装済みで、5月にはUniversal Cartまで拡張した。EC事業者は「どちらか一方に賭ける」のではなく、まず商品データと構造化データを整備し、両プロトコルに対応できる基盤を作ることが2026年の現実的な一手になる。

最終更新日: 2026年7月4日

はじめに

「UCPとACP、結局どちらに対応すればいいのか」——2026年に入ってから、この問いを持つEC担当者が急速に増えた。

きっかけは2026年1月にGoogleが全米小売業協会（NRF 2026）で発表した「Universal Commerce Protocol（UCP）」だ。すでに2025年9月からOpenAIとStripeが「Agentic Commerce Protocol（ACP）」を先行させていたところに、Googleが対抗規格を投入した形になり、ニュースやSNSでは両者が並べて語られるようになった。

だが名前が似ている割に、両者の設計思想・対応範囲・手数料構造はまったく異なる。片方だけを見て対応を決めると、必要な投資を見誤りかねない。本記事では一次情報をもとに両プロトコルの違いを整理し、EC事業者が2026年時点で実際に着手すべきことを段階別に解説する。

UCPとは何か：Google主導の「開かれた」商取引プロトコル

UCP（Universal Commerce Protocol）は、Googleが2026年1月11日のNRF 2026で発表した、AIエージェントが商品発見からチェックアウト、購入後のサポートまでを一気通貫で実行できるようにするオープン標準だ。Shopify・Etsy・Wayfair・Target・Walmartと共同で策定され、Adyen・American Express・Best Buy・Stripe・Visaなど20社を超えるパートナーが賛同を表明している。

UCPの最大の特徴は「事前登録なしの発見可能性」にある。事業者は自社ドメインの /.well-known/ucp にJSON形式のビジネスプロファイルを公開するだけでよく、どのAIエージェントもプラットフォームの承認を経ずにその情報へアクセスできる。認証まわりはOAuth 2.0のサーバーメタデータを別途公開する仕組みで、決済にはトークン化と検証可能な証明書（Verifiable Credentials）を用いる。加えてUCPはAgent2Agent（A2A）、Agent Payments Protocol（AP2）、Model Context Protocol（MCP）といった既存のエージェント連携規格と互換性を持つよう設計されており、単独の決済規格というより「業界横断のインフラ」に近い立ち位置を狙っている。

2026年7月時点でUCPはGoogle検索のAIモード・Gemini・YouTube Shoppingに実装済みで、Etsyなどの商品がすでに購入可能になっている。5月20日のGoogle Marketing Liveでは複数の小売事業者をまたいで買い物できる「Universal Cart」、AffirmやKlarnaによる後払い（BNPL）対応、カナダ・オーストラリア・英国への展開拡大も発表された。

ACPとは何か：OpenAI・Stripeが先行させた決済特化プロトコル

ACP（Agentic Commerce Protocol）は、OpenAIとStripeが2025年9月29日に共同で発表したオープン標準で、ChatGPT上での「Instant Checkout」機能を支える仕組みとして先行実装された。仕様はApache 2.0ライセンスで公開されており、購入者・AIエージェント・事業者をつなぐプログラム可能な購買フローの実現を目的としている。

UCPとの最大の違いはスコープの狭さだ。ACPは商品発見の仕組みを持たず、純粋にチェックアウト（決済完了）だけを担う。事業者側は商品カタログをOpenAIの検索インデックスに提出し、ユーザーはChatGPTの会話の中で商品を見つけて購入を完結させる。初期はEtsyの米国内出品者を対象に始まり、Shopify加盟店100万社以上への展開を見据えていた。

UCPとACPの違い一覧：比較表で見る7つのポイント

数字が示す通り、統合の速さでは当初ACPに分があったが、事業者が負担する手数料と対応範囲の広さではUCPが優位に立つ設計になっている。

2026年の展開タイムライン：NRFからGoogle Marketing Live、そしてOpenAIの方向転換

両プロトコルの立ち位置は、この半年で大きく動いた。

1. 2025年9月 — OpenAIとStripeがACPを発表し、ChatGPT上でInstant Checkoutの提供を開始。
2. 2026年1月11日 — GoogleがNRF 2026でUCPを発表。Shopify・Etsy・Wayfair・Target・Walmartなど業界大手を巻き込む形で仕様策定を進める。
3. 2026年3月 — OpenAIがInstant Checkoutの縮小を発表。Shopify加盟店100万社以上への展開を見込んでいたにもかかわらず、実際にチェックアウトを有効化していたのは約30店舗にとどまり、税務処理の未整備なども重なって購入完了までの導線がボトルネックになっていたことが明らかになった。以降ChatGPTでの購入は自社サイト誘導型に切り替わっている。
4. 2026年5月20日 — Google Marketing LiveでUCPの拡張機能「Universal Cart」を発表。複数事業者の商品を横断してまとめて購入できる仕組みに加え、BNPL対応や北米・オセアニア・欧州への展開拡大も表明した。

このタイムラインから読み取れるのは、「先行したから勝つ」わけではないという点だ。ACPは統合の速さを武器にしたが決済完結率が伸び悩み、UCPは統合により多くの時間を要する代わりに商品発見から購入後までを含む設計で着実に対応範囲を広げている。

先行事例に学ぶ：UCP初弾稼働とACPの躓き

抽象的な仕様比較だけでは判断がつきにくいため、実際に稼働した事例を具体的に見ておきたい。

EtsyとWayfairがUCP対応チェックアウトの第一陣に

2026年2月11日、GoogleはAIモードとGeminiアプリ上でUCP対応チェックアウトの提供を開始した。第一弾としてEtsyとWayfairの商品が対象になり、米国の利用者はAIとの会話を離れることなく商品の発見・比較・購入を完結できるようになった。Googleはこれに続きShopify・Target・Walmartとの統合も準備中であると表明しており、UCPの稼働事例は今後さらに広がる見通しだ。

Walmartの「Instant Checkout」縮小が示す教訓

一方でACP側には慎重に読むべき事例がある。WalmartはOpenAIのInstant Checkout（ACP）を通じて約20万点の商品をChatGPT経由で提供していたが、2026年3月にこの取り組みを事実上縮小した。Walmartの製品・デザイン部門を統括するダニエル・ダンカー氏は、チャット内で完結した購入のコンバージョン率が自社サイトへのクリックアウト経由の3分の1にとどまったと明かし、この体験を「不満足」と評価している。

原因として指摘されているのは、決済フローの設計そのものだ。エージェント経由の購入が既存のショッピングカートと切り離された独立トランザクションとして扱われ、複数商品をまとめて注文したい利用者の意図と噛み合わなかった。ChatGPT経由の新規顧客獲得自体は検索エンジン経由より効率的だったとされるが、その多くは会話内で購入を完結させず自社サイトへの遷移を選んでいたという。

この事例が示すのは、プロトコル対応そのものより、対応後の購買体験設計が成果を左右するという点だ。UCP・ACPいずれを採用する場合も、稼働後にコンバージョン率をクリックアウト経由と比較し、体験上のボトルネックを早期に特定する運用が欠かせない。

EC事業者が今すぐ着手すべきこと：フェーズ別対応ロードマップ

どちらのプロトコルが最終的に主流になるかを待つのではなく、両方に対応できる土台を先に作っておくのが現実的だ。フェーズ別に整理すると次のようになる。

1. 商品データの整備（2026年前半・最優先）: 商品名・画像・価格・在庫・SKU・GTINなど必須属性を欠損なく入力し、材質や寸法といったスペック情報を数値で明記する。AIエージェントは曖昧な表現より数値化されたデータを優先的に扱う。
2. 構造化データの実装: JSON-LD形式でSchema.org準拠のProduct・Offer・AggregateRating・BreadcrumbListをマークアップし、Googleのリッチリザルトテストで検証する。
3. Merchant Centerの最適化: データ品質スコアを高め、価格・在庫を15〜60分間隔で自動同期する体制を整える。配送・返品ポリシーも構造化して公開する。
4. llms.txtの設置: ルートディレクトリにllms.txtを配置し、AIエージェントが参照しやすい形でサイト構造を明示する。
5. プラットフォーム別の対応判断: Shopify利用者はAgentic Storefronts機能の有効化を検討し、WooCommerceなど独自構築サイトはREST API基盤とUCPマニフェストの整備を進める。
6. 引用・レビューエコシステムの強化: 第三者レビューやメディア掲載を増やし、AIエージェントが商品を推薦する際の裏付け情報を厚くする。

このロードマップは一度作って終わりではなく、UCP・ACPそれぞれの仕様変更に合わせて継続的に見直す前提で運用するとよい。

UCPプロファイルの実装詳解：capability・schema・transportの技術要件

ロードマップの2番目に挙げた構造化データの実装を、UCP側の技術仕様に沿ってもう一段具体化しておく。

プロファイルの基本構造

/.well-known/ucp に公開するビジネスプロファイルは、大きく3つの要素で構成される。

• ucpオブジェクト: 対応する仕様バージョン（例: 2026-04-08）、Googleとの通信に使うservices、対応機能を宣言するcapabilitiesを含む。
• payment_handlers: Google Payなど、実際に処理できる決済手段の設定を記述する。
• signing_keys: JWK形式の公開鍵で、Webhookなどの署名検証に使われる。プロファイル自体がディスカバリー（機能確認）と認証（鍵取得）を同時に担う設計になっている点は見落とされやすい。

capabilityは逆ドメイン名で宣言する

UCPのcapabilityはdev.ucp.shopping.checkoutのように逆ドメイン名で識別され、それぞれが独立してバージョン管理される。基本のcheckoutに対して、fulfillment（配送・受け取りオプション）やdiscount（割引適用）はcheckoutを拡張する形で追加され、order（注文管理）やidentity_linking（利用者認証のスコープ設定）は別系統のcapabilityとして宣言する。

capabilityごとの仕様書（schema）は、その名前空間を管理するドメインから配信される必要がある。dev.ucp.*名前空間のschemaはucp.devから配信されなければならず、この対応関係が崩れているプロファイルはプラットフォーム側の検証で拒否される。実装時にドメインの権限バインディングを最初に確認しておくと、後工程の手戻りを防げる。

transportは1つに絞らなくてよい

同じサービス（例: dev.ucp.shopping）に対して、事業者は複数のtransport bindingを同時に宣言できる。サーバー間連携向けのREST（OpenAPI 3.1.0）、AIエージェント向けのMCP（OpenRPC）、エージェント間連携向けのA2A（Agent Card）の3種類があり、どのtransportを使うかはプラットフォーム側が文脈に応じて選択する。事業者側は自社のシステム構成に合わせて対応可能なtransportを絞り込みつつ、将来的な拡張余地としてMCP・A2Aの選択肢も残しておくのが無難だ。

バージョン管理を運用に組み込む

UCPの仕様自体が2026-04-08のように継続的に更新されているため、旧バージョンのプロファイルを使い続ける事業者はsupported_versionsフィールドで対応バージョンを明示する必要がある。プロファイルは一度作って終わりではなく、半期に一度は仕様変更を確認し、対応バージョンを更新する運用ルールを社内に設けておくとよい。

ACP側の実装はStripeのAgentic Commerce Suiteが土台になる

ACP側は2025年12月にStripeが提供を始めた「Agentic Commerce Suite」を使うのが最短経路になる。商品カタログをStripeに接続し、Stripeダッシュボード上で販売を許可するAIエージェントを選択するだけで、商品・価格・在庫のほぼリアルタイムな連携、チェックアウトセッションの作成・更新・完了、決済処理、不正検知までをStripe側が担う。注文が成立すると事業者の既存システムにイベント通知が届く設計になっており、既存のバックエンドがある事業者であれば大きな改修なしに8〜16時間程度で組み込める。

UCP/ACP対応とLLMO・構造化データ対策の関係

見落とされがちだが、UCPやACPへの対応は、既存のLLMO（AI検索最適化）施策の延長線上にある。UCPのビジネスプロファイルもACPの商品カタログも、結局は構造化された商品データを土台にしているからだ。

すでに構造化データやJSON-LDを用いてschema.org準拠のマークアップを実装しているサイトは、UCPのプロファイル作成やACPのカタログ提出において必要な作業量が大幅に少なくて済む。逆に商品説明が定性的な文章中心で、価格・在庫・スペックが構造化されていないサイトは、エージェントコマース対応の前段階としてまずLLMO・構造化データの基礎整備からやり直す必要がある。つまりUCP/ACP対応は新しい取り組みではなく、これまでのAI検索対策の到達点として位置づけるのが正しい理解だ。

よくある誤解と注意点

「UCPとACPのどちらか一方だけ実装すればよい」という発想には注意が必要だ。GoogleのAIモード・Gemini経由の流入とChatGPT経由の流入は消費者層が異なり、両方を無視できるほど規模が小さいとは言い切れない段階にある。また「Shopifyを使っていれば自動的に対応済みになる」という誤解も多いが、実際にはストア側でAgentic Storefrontsなどの機能を能動的に有効化し、商品データ品質を継続的に高める作業が欠かせない。

UCP/ACPと隣接する概念：AP2・MCP、そして日本市場の現在地

UCPとACPの比較にばかり目が向きがちだが、周辺には見落とせない規格と地域差がある。

UCP・ACP・AP2・MCPは対立ではなく階層関係

業界の論点整理でしばしば指摘されるのは、UCP・ACP・AP2・MCPを「どれか一つを選ぶ選択肢」として語る誤りだ。実際にはそれぞれが1つの取引を構成する異なる階層を担っている。UCP・ACPは主に商品発見からチェックアウトまでの商取引フロー、AP2（Agent Payments Protocol）はエージェントが代理で決済を実行する際の認可・権限委譲、MCPはAIエージェントが外部ツール・データソースと会話する際の接続規格という役割分担になる。UCP自体がA2A・AP2・MCPと互換性を持つ設計であることは前述の通りで、これらは競合規格というより1つのスタックを構成する部品と捉えるほうが実態に近い。

事業者にとって重要なのは、この階層のどこに自社の対応が不足しているかを見極めることだ。商品データが未整備なら発見層（UCP・ACP）から着手すべきだし、決済まわりの認可設計に不安があるならAP2の仕様を確認する必要がある。

日本市場はまだ「準備期間」

2026年7月時点で公開情報を確認する限り、UCP・ACPいずれについても日本の大手小売事業者による稼働事例は確認できていない。Googleは2026年5月のUniversal Cart拡張発表でカナダ・オーストラリア・英国への展開拡大を表明したが、この時点で日本は対象に含まれていない。これは日本のEC事業者が出遅れているという意味ではなく、地域展開が始まる前に商品データと構造化データの土台を整えておける猶予期間と捉えるべきだ。Amazon RufusやRakuten AIのように、日本市場ではすでに自社ECプラットフォームが独自のAIショッピングアシスタントを提供し始めている点も踏まえると、UCP・ACPへの対応と並行して、プラットフォーム個別のAI機能にも目を配る必要がある。

よくある失敗と対処：8つのアンチパターン

UCP・ACP対応を進める過程で実際に起きやすい失敗パターンを、原因と対処法つきで整理する。

1. 二者択一思考で片方にリソースを集中させる。原因は限られた開発リソースの中で意思決定を単純化しすぎることにある。対処としては、プロトコル固有の実装を薄いアダプタ層に閉じ込め、商品データ基盤を共通化しておく。どちらが主流になっても土台の作り直しが不要になる。
2. 商品フィードと商品詳細ページの価格・在庫が食い違う。原因はフィードと詳細ページの更新経路・更新頻度が別々になっていることにある。対処としては、単一の商品データソースからフィードと詳細ページの両方を生成し、更新間隔を15〜60分以内に統一する。エージェントは情報の不一致を検知した商品を信頼性が低いと判断し、比較対象から除外する傾向がある。
3. エージェント経由の購入を独立トランザクションとして設計する。原因はWalmartの事例のように、チャット内購入を既存のカートと切り離して扱ってしまうことにある。対処としては、既存カートとの統合や同梱発送の選択肢を用意し、利用者が「別々の箱で届く」不安を持たない購買体験を設計する。
4. 構造化データを断片的にしか実装しない。原因はProduct情報だけをマークアップし、AggregateRating・在庫可用性・FAQなどを後回しにすることにある。対処としては、schema.org準拠のProduct・Offer・AggregateRating・BreadcrumbListを一括で整備し、Googleのリッチリザルトテストに加えてUCP・ACP双方のバリデーション手順で確認する。
5. 新しい規格が出るたびに個別に作り込む。原因はUCP・ACP・AP2・MCPそれぞれに一から個別実装を行い、エンジニアリングコストが膨らむことにある。対処としては、商品データ層とプロトコル変換層を分離し、新しい規格への対応は変換層へのアダプタ追加だけで済む構成にしておく。
6. 導入後の効果測定を怠り「様子見」のまま放置する。原因は対応さえ終えれば十分だという思い込みにある。対処としては、GA4などでエージェント経由トラフィックを分離計測し、月次でコンバージョン率や引用状況を確認する体制を先に決めておく。
7. 第三者評価やレビューの蓄積を軽視する。原因は自社サイトの情報整備にばかり注力し、外部からの信頼シグナルを後回しにすることにある。対処としては、E-E-A-Tを意識したレビュー獲得やメディア掲載を継続し、AIエージェントが商品を推薦する際の裏付け情報を厚くする。
8. プロファイルやカタログのバージョン更新を怠る。原因は仕様が継続的に更新されていることを認識せず、公開時点のプロファイルを放置することにある。対処としては、半期ごとに仕様変更を確認し、UCPのsupported_versionsやACPのカタログ形式を最新の要件に合わせて更新する運用ルールを設ける。

導入後の効果測定：見るべき指標と判断基準

対応を終えたら、次に必要なのは効果測定の仕組み化だ。感覚的な評価に頼ると、Walmartのように体験上の問題を放置したまま撤退判断が遅れるリスクがある。

• エージェント経由トラフィックの分離計測: 通常の検索流入と区別してAIエージェント経由の訪問・購入を可視化する。GA4での識別・セグメント化の具体的な手順はAIエージェントトラフィックのGA4可視化ガイドで解説している。
• チャット内コンバージョン率とクリックアウト経由コンバージョン率の比較: Walmartの事例では前者が後者の3分の1にとどまった。この数値を参考値として、自社の比率が大きく下回る場合は決済体験の設計を見直す判断基準にする。
• 商品フィードのエラー率・データ品質スコア: Merchant Centerの診断機能で欠損・不整合の件数を定期チェックし、しきい値を超えたら担当チームにアラートが飛ぶ体制にする。
• 構造化データのリッチリザルトテスト合格率: 実装後だけでなく、商品追加・更新のたびに合格率をモニタリングする。
• AIエージェントからの引用・言及頻度: AI可視性を計測するツールを使い、自社商品がAIエージェントの回答や提案にどの程度登場しているかを追跡する。

これらの指標を月次でレビューし、コンバージョン率が想定を下回る場合はUCP・ACPどちらの体験設計に問題があるのかを切り分けてから改善に着手するのが望ましい。

よくある質問

Q1. UCPとACPはどちらが主流になりますか?

2026年7月時点では判断材料が出そろっておらず、両対応の土台作りが現実的な選択だ。 GoogleはUCPをAI Mode・Gemini・YouTube Shoppingに実装済みで対応範囲を拡大中、一方でOpenAIはACPの決済機能を縮小し方針転換した。優劣が固まるまでは商品データ整備を優先するのが合理的である。

Q2. 小規模ECサイトでも対応する必要がありますか?

規模を問わず、まず構造化データの整備から着手する価値がある。 UCP・ACPどちらの仕組みも商品データの品質が前提条件になるため、小規模事業者ほど早期に土台を作ることで将来の実装コストを抑えられる。

Q3. UCPとACPは同時に対応できますか?

技術的には両立可能で、多くの大手事業者は並行対応を選んでいる。 UCPの /.well-known/ucp プロファイルとACPのカタログ提出は独立した仕組みのため、片方を選ぶ二者択一ではない。

Q4. Shopifyを使っていれば自動的に対応済みになりますか?

自動では対応済みにならず、Agentic Storefrontsなどの機能を個別に有効化する必要がある。 プラットフォーム側の対応は基盤にすぎず、商品データの品質改善は事業者自身の作業として残る。

Q5. UCPの/.well-known/ucpとは何ですか?

事業者が自ドメインで公開する、AIエージェント向けの商品・決済情報プロファイルのことだ。 プラットフォームへの事前登録なしに、任意のAIエージェントがこのURLを参照して商品情報や対応機能を把握できる仕組みになっている。

Q6. ACPの手数料が高いのはなぜですか?

Stripeの決済処理手数料に加え、OpenAIのプラットフォーム利用料が上乗せされる構造だからだ。 合計はおおむね7%台になり、処理手数料のみのUCP(約3%台)より事業者負担が大きくなりやすい。

Q7. 日本のEC事業者はいつから対応を始めるべきですか?

決済プロトコルの選定を急ぐより、2026年内に商品データと構造化データの整備を終えておくのが望ましい。 両プロトコルとも仕様変更が続いている段階のため、土台となるデータ品質の改善を先行させる方が投資対効果は高い。

Q8. UCPはMCP・A2A・AP2とどう違いますか?

MCP・A2A・AP2はAIエージェント連携の基盤規格で、UCPはその上に構築された商取引特化のプロトコルだ。 UCPはこれらの規格と互換性を持つ設計になっており、既存のエージェント連携インフラを土台に商取引フローを追加する位置づけになる。

Q9. 構造化データの対応は引き続き必要ですか?

必要であり、むしろUCP/ACP対応の前提条件として重要度が増している。 両プロトコルとも商品情報の正確な受け渡しが起点になるため、schema.org準拠のマークアップは今後もLLMO施策の中核であり続ける。

Q10. ACPの「Agentic Commerce Suite」とは何ですか?

Stripeが2025年12月に提供を始めた、ACP対応を簡略化するための統合パッケージだ。 商品カタログの接続からチェックアウトセッションの管理、決済処理、不正検知までをStripe側がまとめて担い、事業者は既存の商流を大きく変えずに導入できる。

Q11. Walmartの事例から学べる最大の教訓は何ですか?

プロトコル対応そのものより、対応後の購買体験設計が成果を左右するという点だ。 チャット内購入を既存カートと切り離して独立トランザクションとして扱ったことがコンバージョン率低下の一因になったとされ、決済フローの体験設計まで含めた導入計画が求められる。

Q12. UCP対応で最初に確保すべき人的リソースは何ですか?

専任のエージェントコマース担当者よりも、既存のバックエンド・データ整備を担当できるエンジニアの確保が先決だ。 REST APIやJSON-LDに習熟した担当者であれば、GoogleやStripeが提供するドキュメント・SDKを土台に既存のECチーム内で対応を進められる。

まとめ

• UCPはGoogle主導で商品発見からチェックアウト・購入後まで一気通貫を目指す開放型プロトコル、ACPはOpenAI・Stripe主導で決済に特化した先行実装であり、設計思想も収益構造も異なる。
• 2026年2月にはEtsy・WayfairがUCP対応チェックアウトの第一陣として稼働した一方、同年3月にはWalmartがACP経由のInstant Checkoutを事実上縮小しており、先行したプロトコルが必ずしも成果に直結するわけではないことが実例で示された。
• UCPのプロファイルはcapability・schema・transportという3つの技術要素で構成され、ACPはStripeのAgentic Commerce Suiteを使えば既存バックエンドに対して8〜16時間程度で組み込める。
• 対応を成功させる鍵はプロトコル選定そのものより、商品データの品質・購買体験の設計・導入後の効果測定という運用面にある。
• 日本のEC事業者にとって2026年7月時点はまだ地域展開前の準備期間であり、商品データと構造化データの整備を優先するのが合理的な次の一手だ。

次のアクションとしては、まず自社の商品データにおける必須属性の欠損率を洗い出し、構造化データの実装状況をリッチリザルトテストで確認するところから始めるとよい。土台が整ってから、UCP・ACPそれぞれのプロファイル作成やカタログ提出に着手するのが遠回りに見えて最も確実な進め方になる。

関連用語

• LLMO
• 構造化データ
• JSON-LD
• schema.org

関連記事

• AI検索対策完全ガイド｜ChatGPT/Perplexity/Gemini/Claude/AI Overview 統合戦略【2026年版】
• ChatGPT Shopping商品表示の仕組みとMerchant Center最適化【2026年版】
• Google AIモード公式最適化ガイド2026｜引用される条件を解説
• GEO・AEO・LLMO・AIOの違いをわかりやすく解説【2026年版】
• AI検索利用率が8か月で3.5倍に急増｜2026年白書が示す企業対策
• エンティティ最適化とAI検索：日本語サイトが取り組むべき実践ガイド
• LLMOツール 目的別・用途別 選び方ガイド｜やりたいことから逆引きするツール選定【2026年版】
• AI可視性アトリビューション完全ガイド：収益インパクトを計測する方法
• Visa×ChatGPTのエージェント決済にEC事業者はどう備えるか
• AIエージェント決済プロトコルx402にEC事業者はどう備えるか