GoogleがGemini 4 Argonを発表、出力100万トークンとサイバー防御に特化
Google DeepMindが次世代フロンティアモデル「Gemini 4 Argon」を発表した。信頼できるサイバー防御者向けのFairwind Programを通じて、まず限定的な提供を開始している。
このモデルは出力トークン上限を100万に拡大し、ソフトウェアエンジニアリングのベンチマークであるDeepSWE v1.1で77.9%を記録した。サイバーセキュリティのCWE-bench v1では68%で同率1位となっている。
一般提供の前には段階的な安全性検証を進める方針だ。本記事では発表された性能、Google社内での活用事例、価格、今後の展開予定を整理して解説する。
Gemini 4 Argonの概要と段階的な提供
Gemini 4 Argonの大きな特徴は、複雑で長期にわたるワークフローで深い推論を持続できる点にある。実世界のソフトウェアエンジニアリング、法律や金融などの企業知識作業、サイバーセキュリティ防御の各領域で最高水準の性能を発揮するとしている。
段階的な提供アプローチ
このレベルのフロンティア能力を安全に提供するには段階的な進め方が必要になる。Google DeepMindは米国政府のモデル事前アクセスに関する自主的なプロセスに積極的に関与しており、アクセスを徐々に拡大している。
早期テスターからフィードバックを集めながらガードレールを改善した上で、できるだけ早く開発者、企業、一般消費者に提供する方針だ。
このデモは提供の段階を示している。現在はサイバー防御者向けの提供が始まっており、フィードバックを反映した後に一般向けへ拡大する計画だ。
導入価格
料金は入力トークン100万個あたり2ドル、出力トークン100万個あたり10ドルに設定された。キャッシュ済みの入力トークンは入力価格から95%引きになる。
Google社内でのエージェント活用事例
Gemini 4 ArgonはすでにGoogle社内のワークフローで実用されている。数千人規模のGooglerが専門的なコーディング作業、深い調査、文章作成でモデルの強みを報告しているという。
量子アルゴリズムの最適化
量子コンピューティングの研究者は、重要なアプリケーションのボトルネックとなるサブルーチンについて、時空リソース（量子ビット×ゲート）を最適化する目的でArgonを使用している。ある例では公開されているベースラインを数分で40%上回った。
データセンターのメモリ効率化
Argonエージェントのチームがフリート全体のプロファイリングテレメトリを解析し、Googleのデータセンター全体でメモリ最適化を自律的に特定して適用した。展開後には300TiB超のメモリを解放し、合計の削減量は500TiBから1PiBと見積もられている。
大規模コードベースの移行
ArgonエージェントはGoogle全体でC/C++コードベースのRustへの移行に取り組んでいる。対象はコアライブラリのre2やlibgav1では数万行、Fuchsia Zirconカーネルでは80万行超に達する。
これらの大規模書き換えは、本番環境への展開前に厳格な自動監査と手動監査、エミュレーションテスト、レビューを受けている。
libgav1の例では、Argonエージェントが既存のRustポートをベースにSIMDコード32K行を置き換えた。多くのプロファイル誘導実験を繰り返し、コンパイラの出力を調査して、自動ベクトル化される安全なRustコードを生成した。結果として、同一の映像出力でRustポートより2.7倍高速なメモリ安全な動画デコーダが完成した。
技術仕様とベンチマーク結果
出力トークン上限を100万に拡大
長く複雑なユースケースを支えるため、出力トークンの上限は従来の64Kから業界最高水準の100万に大幅拡大された。モデルが深く思考し、1回の軌道で数十万トークンを生成できる余裕があると、難しい問題を一括で解く新しい推論の深さが生まれる。
主要ベンチマークの結果
ソフトウェアエンジニアリングの実世界タスクを測定するDeepSWE v1.1では77.9%を記録し、新たな最高水準を樹立した。Googleエンジニアは日々のデバッグから大規模コード移行、アルゴリズム設計までArgonを日常的に使用している。
コード生成以外でも、金融、コーディング、法律、税務作業の経済的影響を測定するVals Indexで首位を獲得した。Vals Finance Agent v2（多段階の金融リサーチ）やHarvey’s Legal Agent Benchmark（法的調査と文書作成）でも首位級の結果を出した。
ZapierのAutomationBench（主要なビジネス機能のエンドツーエンド実行を測定）では51.3%で1位となった。長尺動画の理解力を測定するLVBenchでは91.7%で最高水準を記録している。
DeepSWE v1.1とLVBenchでは最高水準、AutomationBenchでは単独1位、CWE-bench v1では同率1位という結果になっている。
サイバーセキュリティ防御への特化
新時代のサイバー攻撃に備えて、Gemini 4 Argonはサイバーセキュリティ防御に高い能力を持つように訓練された。重大なソフトウェア脆弱性を自律的に発見、検証、修正できる。信頼できる防御者とGoogle社内チーム向けには、サイバーガードレールなしで提供され、フロンティア級の防御能力を完全に活用できる。
脆弱性の発見と修正
CWE-bench v1（セキュリティ脆弱性の修正能力を評価するベンチマーク）では68%で首位タイを記録した。これは3.8 Flash CyberのCWE-bench v0でのフロンティア性能を基盤にしている。
内部の包括的な脆弱性ベンチマークでは、20のプログラミング言語にわたる複雑なコードベースから広範囲の露出を発見した。Wizの内部ブラックボックス侵入テストベンチマークでは、ソースコードなしでライブWebシステムを解析する能力が試され、攻撃対象の発見、脆弱性の特定、検証用の概念実証の生成において3.8 Flash Cyberを上回った。
Wizとの連携実績
クラウドセキュリティ企業のWizは、無償で重要な公共インフラを保護する取り組み「Scan for Good」を通じてArgonをサイバーセキュリティ防御に利用している。初期のデモでは、世界中の病院で使われる医療ソフトウェアに個人情報を漏えいさせる重大な脆弱性を発見した。これは以前のフロンティアモデルが見逃していた深刻なリスクだった。
Argonは従来モデルが見逃していた脆弱性を発見し、検証から修正まで自律的に対応できる点が実用上の大きな違いだ。
包括的な安全対策と展開ロードマップ
フロンティアモデルを広く提供する前に、Google DeepMindは四つの主要領域で安全性対策を強化している。それぞれの取り組みは、モデルの能力が高まるほど悪用や誤動作のリスクも高まるという前提に基づく。
誤用の防御
サイバー攻撃や化学・生物・放射性物質・核（CBRN）攻撃への悪用を防ぐため、Argonは有害な要求を拒否しつつ、正当なデュアルユース科学研究を保持する設計になっている。これはFrontier Safety Frameworkに沿ったものだ。
社内外のレッドチームによる手動および自動の攻撃手法を組み合わせた堅牢性テストを通じて、対策の効果を検証している。
プロンプトインジェクションへの耐性
悪意ある指示や文脈で外部からモデルの動作を乗っ取る間接的プロンプトインジェクションに対して、Argonはこれまでで最も高い耐性を持つ。自動レッドチーミングと敵対的トレーニングを通じて、Gray SwanのIndirect Prompt Injection（IPI）ベンチマークで最高水準を記録した。
システムの強化
モデルの思考連鎖と行動を監視し、ユーザーの意図を超えた行動を取ろうとした場合に実行を停止する仕組みも導入された。同様のシステムをトレーニング実行の監視にも使用し、専任のインシデント対応チームにアラートを送る運用を行っている。
エージェント制御ロードマップに沿って、高リスクのトレーニングや評価の前にサンドボックス環境を隔離・封印する対策も進めている。これらのベストプラクティスはパートナーと共有し、業界全体の安全性向上を目指す。
一般提供は有料API顧客とGoogle AI Ultra加入者から始まり、その後開発者、企業、一般消費者へと順次拡大される予定だ。
この記事のポイント
- Gemini 4 Argonは出力トークン上限100万、DeepSWE v1.1で77.9%を記録した
- Google社内では量子計算の最適化、メモリ300TiB削減、C/C++からRustへの大規模移行で実績を上げている
- サイバーセキュリティ防御に特化し、CWE-bench v1で68%の首位タイを達成した
- 価格は入力100万トークンあたり2ドル、出力同10ドルから始まる
- 一般提供は段階的に進められ、有料API顧客とGoogle AI Ultra加入者から開始される
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Shopifyが全AIショッピングチャネルに自動登録。デフォルト設定の全容
Shopifyが2026年1月から、対象ストアを新しいAIショッピングチャネルへ自動登録する仕組みを本格稼働させている。2026年9月8日のMeta「Muse」ローンチ当日には、対象ストアの商品情報が即座にMetaへ共有された。
現在、ChatGPT・Google・Microsoft Copilot・Metaの主要4チャネルでAIエージェント経由の販売が可能だ。チャット内で決済まで完了する「ダイレクトチェックアウト」もデフォルトで有効になっている。
この記事では自動登録の仕組み、ダイレクトチェックアウトの影響、アナリティクス計測で発生する盲点、停止手順までを解説する。
ShopifyのAIショッピングチャネル自動登録の仕組み
このデモは「Shopifyに管理を任せる」設定のオン・オフで表示がどう変わるかを示している。オフにすると3つの独立したスイッチが現れ、細かな制御が可能になる。
Shopify管理画面の「販売チャネル → Agentic」ページには「Allow Shopify to manage for me（Shopifyに管理を任せる）」という設定がある。この設定がオンの場合、Shopifyは対象ストアを新しいAIショッピングチャネルへ自動で登録する。デフォルトで有効だ。
Shopifyの公式ドキュメントによると、この設定では次の3つが自動的に行われる。Shopify Catalogを通じた商品アクセスの提供、関連チャネルでのダイレクトチェックアウトの有効化、新しいエージェンティックストアフロントチャネルへの自動登録だ。
Shopify Catalogは、多くのAIアプリが商品リストを取得する仕組みだ。Googleは例外で、Google Merchant Centerから商品情報を読み取る。
自動登録の最初の大規模適用は2026年1月12日に実施された。その後2026年9月8日のMeta「Muse」ローンチ時に、対象ストアの商品が即座にMetaへ共有された。MuseはMetaのAIエージェントで、ブラウザの操作やフォーム入力、価格交渉まで行える。2026年9月20日には、AmazonがMuseを自社ストアからブロックしている。Shopifyの自動共有からわずか12日後のことだ。
自動登録の対象となる主要チャネル
管理画面には「その他のチャネル」という行もあり、PerplexityのようなAIプラットフォームや、実験的なショッピングエージェントを開発するスタートアップが含まれる。この行もデフォルトでオンになっている。
ダイレクトチェックアウトで店舗訪問不要の購入が可能に
従来フローではサイト訪問が必須だったが、ダイレクトチェックアウトではチャットアプリ内で決済まで完了する。この違いがアナリティクス計測に影響を与える。
ダイレクトチェックアウトとは、顧客がAIチャットアプリ内のShopifyチェックアウトで決済を完了し、自社サイトを一切開かない購入方法だ。条件を満たすストアではデフォルトで有効になっている。
- Meta、米国・カナダ・メキシコ向けに販売するストア
- Google AI ModeとGemini、米国のストアが米国顧客向けに販売し、Google Merchant Centerアカウントを持つこと
- Microsoft Copilot、米国内で販売するストア
ChatGPTは仕組みが少し異なり、顧客を自社ストアのチェックアウトへ誘導する。ChatGPTアプリ内ブラウザで表示されるか、Web版なら新しいタブでチェックアウトが開く。
アナリティクス計測に生じる盲点
カスタムピクセル あり
サーバーサイド計測 あり
カスタムピクセル なし
サーバーサイド計測 あり
Shopify管理画面の注文記録 あり
ダイレクトチェックアウトではクライアントサイドの計測が止まる一方、Shopify管理画面には注文が記録される。売上分析の際は計測経路の違いを理解しておく必要がある。
ダイレクトチェックアウトでの購入では、自社サイトのトラッキングコードが実行されない。Shopifyによると、Google AnalyticsとカスタムピクセルはGoogle・Copilotのチェックアウトで発火せず、サーバーサイドトラッキングのみが機能する。Metaのチェックアウトではサードパーティ製アナリティクスピクセルが発火しない。
ただしShopify管理画面には注文が記録される。Meta経由の注文も「他の販売チャネルと同じ方法で」表示されるため、Shopifyの管理画面を見ていれば売上自体は把握できる。
このため、Google Analyticsや広告ダッシュボードで売上を確認しているストア運営者は、AI経由の売上を見落とす可能性がある。月に1回程度、注文リストをチャネル別にフィルタして確認する運用が推奨される。
自動登録を停止する手順と注意点
「Shopifyに管理を任せる」設定をオフにすると、次の3つのスイッチが表示される。
- Shopify Catalogアクセス
- 新しいストアフロントの自動登録
- ダイレクトチェックアウト
「新しいストアフロントの自動登録」をオフにすれば、既存チャネルは維持しつつ新規チャネルへの自動登録だけを停止できる。
チャネル別にも設定がある。MetaとCopilotはカタログアクセスとダイレクトチェックアウトのそれぞれにスイッチを備える。ChatGPTはカタログアクセスのみ、Googleはダイレクトチェックアウトのみだ。
カタログアクセスをオフにした場合、Shopifyは商品データの共有が停止するまで最大7日かかるとしている。即時に共有が止まるわけではない点に注意が必要だ。
特定商品だけをAIアプリから隠すには「unlisted（非公開）」に設定する。ただし非公開にするとサイトマップやGoogle検索、自社サイト内検索からも除外される。AIチャネル限定の除外はできない。
手数料は当面無料、Metaは将来の手数料徴収を示唆
2026年9月時点で、ChatGPT・Google・Microsoft Copilot・Metaはいずれも手数料を請求していない。ストア運営者が支払うのは通常の決済処理手数料のみだ。販売者としての立場も変わらず、発送・返品・カスタマーサービスは引き続きストア側が担当する。
ただしMetaは将来の手数料徴収を明確に示唆している。Mark Zuckerberg氏は2026年9月8日公開のポッドキャストで、Museについて「時間の経過とともに、取引額のごくわずかなカットを徴収するビジネスモデルを期待している」と発言した。手数料はMuseが取引を仲介する事業者から徴収する形になる見通しだ。
GoogleとMicrosoftからは同様の手数料計画は明らかにされていない。No HacksのポッドキャストEpisode 233では、MetaがMuseについて述べた内容と手数料の見通しを詳しく検証している。
AI参照トラフィックは急増中
Agenticページ上部に表示される「ショッパー数」は、AIアプリから自社ストアへの訪問数を表す。Shopifyのドキュメントでは「指定期間内にAIチャネルからオンラインストアへの総訪問数」と定義されている。
ただしダイレクトチェックアウトでの購入はWebサイトを開かないため、この数には含まれない。つまりこの数値は「AIエージェントが購入した数」ではなく「AIチャットアプリの回答からリンクをクリックして訪問した人数」だ。
Search Engine Journalの記事では、このショッパー数を「エージェンティックショッピングではなくLLM参照トラフィック」と整理している。AIチャットアプリの回答経由でストアに送られてきた訪問者という位置づけだ。
Shopifyは2026年8月、2026年第2四半期に「AI参照セッションが前年同期比197%増、注文数も3倍に増加した」と発表している。一方、AIエージェントがチャットアプリ内で完了した購入の具体的な件数は、Shopifyからも他社からも公表されていない。
Search Engine Journalの記事は、当面はすべての設定をオンにしたまま、Shopifyがチャネルリストに追加する項目を注視することを推奨している。ダイレクトチェックアウトの売上は、チャネル別にフィルタした注文リストでしか把握できないためだ。
この記事のポイント
- Shopifyの自動登録設定はデフォルトで有効、対象ストアは新AIチャネルに自動参加する
- ダイレクトチェックアウトではGAやピクセルが発火せず、計測の盲点が生じる
- 自動登録は「Shopifyに管理を任せる」設定をオフにすれば停止できる
- 現在は手数料無料だが、Metaは将来の手数料徴収を示唆している
- AI参照トラフィックは前年比197%増と急成長している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
CloudflareがAI決済2製品をベータ公開、サイト運営者が知るべき課金モデルとは
CloudflareがAI決済分野で動きを加速させている。9月30日に2つの製品をベータへ移行した。Monetization GatewayとPay Per Useだ。いずれもサイト運営者がAIエージェントやAI企業から収益を得るための仕組みである。
Monetization GatewayはAIエージェントからのリクエスト単位で課金する。Pay Per UseはAI企業がコンテンツを使用した際にパブリッシャーへ支払う。どちらも現在は米国拠点の利用者に限定したクローズドベータだ。
AI検索の普及でコンテンツの無断利用が問題視される中、この発表はサイト運営者にとって新たな収益化の選択肢となる。本記事では仕組みと実務への影響を解説する。
CloudflareがAI決済製品をベータ公開、収益化の選択肢が拡大
この比較図は3つの支払いモデルの課金タイミングを示している。縦に並んだ各モデルは、それぞれ異なる課金ポイントを持つ。
Cloudflareは7月1日にMonetization Gatewayを発表し、順番待ちリストを開設していた。今回のベータ移行で実際の利用が始まった形だ。Pay Per Useも同じくベータ段階に入っている。
3つの支払いモデルが揃った
Cloudflareが提供するAI関連の支払いモデルはこれで3つになった。既存のPay Per Crawlに加え、今回の2製品が加わった。それぞれ課金のタイミングと主体が異なる。
- Pay Per Crawlはクローラーがアクセスした時点でサイト所有者が設定した料金を支払う
- Monetization GatewayはAIエージェントからのリクエストごとに売り手が設定した料金を請求する
- Pay Per UseはAI企業がコンテンツを使用したと報告した時点でAI企業が設定した料金をパブリッシャーに支払う
この3モデルを理解すると、AI時代のコンテンツ課金の全体像が見えてくる。
Monetization Gatewayの仕組み
このフロー図はMonetization Gatewayの処理手順を示している。支払いが完了するまでコンテンツは提供されない。
Monetization GatewayはAIエージェントに対してリクエスト単位で課金する仕組みだ。API、MCPツール、データセット、サイトなど、リクエストがあるたびに使用が発生するリソース向けに設計されている。MCPツールとは、AIアシスタントが外部の機能を呼び出すための標準規格Model Context Protocolに対応したツールを指す。
リクエスト単位の課金フロー
このゲートウェイはx402プロトコルとHTTP 402 Payment Requiredステータスコードを使用する。x402プロトコルは、HTTP 402を利用した機械支払いのための規約だ。人間の介入なしにAIエージェント同士が支払いを処理できるよう設計されている。
HTTP 402は「支払いが必要」という意味のレスポンスコードだ。AIエージェントが保護されたリソースへアクセスすると、まず支払い条件を受け取り、支払い承認に署名してから再試行する。支払いはこのリクエスト内で処理され、売り手のサーバーが応答する前に検証される。つまり、支払いが確認できなければコンテンツは提供されない仕組みだ。
料金設定は固定と変動の2種類から選べる。固定価格は入力が同じなら常に同じ料金になる。変動価格は上限額を設定し、実際の使用量に応じて売り手側が請求額を報告する。決済は1回0.001ドルから100ドルまで対応する。
支払い処理にはUSDCステーブルコインを採用した。Baseブロックチェーン上でCoinbaseのx402 Facilitatorを経由する。将来的には他の支払い方法も追加する予定だ。
導入に必要な条件
現在はクローズドベータのため、利用するには条件がある。売り手と買い手の双方が米国に拠点を置く必要がある。売り手側はクレジットカードの登録、確認済みメールアドレス、開設から60日以上経過したアカウントが求められる。
さらにサイトがCloudflare経由でプロキシされており、作成から30日以上経過していること、ゾーンのセキュリティチェックを通過することが条件だ。アクセス申請はダッシュボードから行う。
4つのライブ実装も公表されている。Ceramic.aiはエージェント向けのWeb検索APIを固定価格で提供する。AI Gatewayは4つのオープンモデルで推論リクエストごとの支払いを受け付ける。Stocktwitsは市場シグナルをリクエスト単位で課金する。API2PDFはリクエストの計算量と帯域幅に基づく変動価格でPDF生成APIを提供する。
API2PDFの事例は示唆的だ。初月無料の後にクレジットカードを要求すると変換率が50%以上低下したという。AIエージェント向けの決済はスムーズさが重要だと示している。
Pay Per Useの仕組み
このフロー図はPay Per Useの役割分担を示している。AI企業が使用を報告し、Cloudflareが照合してパブリッシャーへ支払う流れだ。
Pay Per Useは別のアプローチを取る。パブリッシャーがコンテンツを提供し、AI企業がそのコンテンツを使用したと報告した場合に、AI企業からパブリッシャーへ支払いが発生する。
使用報告の流れ
役割分担は明確だ。AI企業が支払う用途と価格を定義する。パブリッシャーは提示されたオファーを承認するか拒否するかを決める。承認後は自分のコンテンツがどれだけ使われ、いくら稼いだかを確認できる。Cloudflareは登録、使用記録、請求、支払いを担当する。
使用の記録はAI企業側が自己申告する。タイムスタンプ、ソースURL、イベントIDを報告し、Cloudflareが各使用報告が登録済みパブリッシャーのものか照合する。そこから買い手に請求し、毎月パブリッシャーへ支払う流れだ。
ベータ期間中、Cloudflareは個々の買い手および参加を選択したパブリッシャーと直接連携している。買い手の企業名はまだ公表されていない。
パブリッシャーが注意すべき点
Pay Per UseではAI企業が使用用途と価格を設定する。パブリッシャーはオファーを承認するか否かの判断のみで、価格交渉はできない。また、使用データは買い手の報告に依存するため、実際の使用頻度との乖離があり得る。
各プログラムの規約には、AI企業がコンテンツをどう扱えるか、学習用途の制限なども含まれる。参加前に規約を確認する必要がある。
サイト運営者への実務的な影響
これら2製品は、AIエージェントの台頭でコンテンツ収益が脅かされているサイト運営者に新たな選択肢をもたらす。特にMonetization GatewayはAPIやデータセットを提供する事業者との相性が良い。Pay Per Useはコンテンツメディア向けだ。
SEO観点での評価
SEO対策の観点では、AI検索エンジンがコンテンツを読み取る動きが加速する中、その利用に対して対価を求める仕組みが整ってきた点が重要だ。これまで無断でクロールされ、引用される一方だったパブリッシャーに交渉の余地が生まれる。
ただし現段階では取引件数や支払い実績は公表されていない。収益化の効果を実証するデータはまだない。ベータ期間中の成果報告が待たれる。
導入を検討する際のチェックポイント
現時点で導入できるのは米国拠点の事業者に限られる。日本からはまだ利用できない。地理的な拡大は予告されているが、時期は明らかではない。まずは動向を追い、仕組みを理解しておくことが現実的だ。
- 自社コンテンツがAIエージェントに利用される頻度を把握する
- Pay Per Crawl、Gateway、Pay Per Useの違いを理解する
- Cloudflareを利用しているか、利用予定があるか確認する
- ベータが日本に開放された際にすぐ試せるよう準備する
今後の展開と注目ポイント
CloudflareはPay Per Useのベータで、パブリッシャーが買い手の提示価格に対抗してカウンターオファーを出したり、用途別に異なる料金を設定したりする方法を模索している。
また、Pay Per Useで購入するAI企業の社名が公表されるかも注目点だ。Gatewayについては新たな地域への対応が予告されている。日本からの利用開始時期も気になるところだ。
AIエージェント経済のインフラが整いつつある。サイト運営者はこの変化を収益化のチャンスと捉え、早期に情報をキャッチアップしておくべきだ。
この記事のポイント
- Cloudflareが2つのAI決済製品をベータ公開した
- Monetization Gatewayはリクエスト単位でAIエージェントに課金する
- Pay Per UseはAI企業の使用報告に基づきパブリッシャーへ支払う
- どちらも現段階では米国拠点の限定ベータである
- AI時代のコンテンツ収益化に新たな選択肢が加わった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce Dual APIが専用プラグインに移行、コアから削除へ
WooCommerce 11.2で、実験的なDual APIエンジンがコアから削除され、専用プラグインとして提供される。10.9から11.1まで利用できた検証用の商品・クーポンAPIも廃止されるため、使っていた開発者は対応が必要だ。
Dual APIとはPHPクラスからGraphQLエンドポイントを自動生成するコードファーストな仕組みで、WooCommerce 10.9で実験機能として導入された。今回の変更は、開発の自由度を高めるための構成変更である。
WooCommerce 11.2でDual APIの提供形態が変わる
WooCommerce 10.9で導入されたDual APIは、PHPクラスを定義するだけでGraphQLエンドポイントを生成できる実験的な拡張機能だった。これまではWooCommerce本体に組み込まれ、フィーチャーフラグで有効化する方式だった。
WooCommerce 11.2では、このDual APIエンジンがWooCommerceコアから削除される。代わりに、WooCommerce Dual APIプラグインとして独立したリポジトリで提供される形だ。
この変更により、WooCommerce本体のリリースサイクルに縛られず、Dual APIだけを柔軟にアップデートできるようになる。Dual APIエンジン自体は、独自のAPIを開発したいエクステンション開発者にとって引き続き有用だ。
検証用の商品・クーポンAPIは削除される
WooCommerce 10.9から11.1まで、商品とクーポンに関する検証用APIが組み込みで提供されていた。このAPIはWooCommerce 11.2で削除される。
この検証用APIを使っていた開発者は、利用を停止するか、自前のエクステンションで同等のAPIを構築する必要がある。注意点として、Dual APIプラグインをインストールしても、この検証用エンドポイントが復活することはない。
Dual API移行で開発者が知るべき変更点
独自のDual APIを開発しているエクステンション開発者には、いくつか重要な変更がある。フィーチャーフラグの廃止、APIビルダースクリプトの移設、ドキュメントの場所変更、そして依存関係の宣言方法だ。
プラグイン依存関係をヘッダーに宣言する
これまでDual APIエンジンを有効化していたフィーチャーフラグは利用できなくなる。代わりに、Dual APIプラグインをインストールして有効化することでエンジンが使えるようになる。プラグインの要件はWooCommerce 11.2以上、PHP 8.1以上だ。
エクステンションがDual APIエンジンに依存する場合、プラグインのヘッダーで両方の依存関係を宣言する必要がある。具体的には以下のように記述する。
Requires Plugins: woocommerce, woocommerce-dual-apiこの記述により、エクステンションのインストール時にWooCommerce本体とDual APIプラグインの両方が必要であることが明示される。依存関係の宣言は、プラグインの動作に必要な前提条件をユーザーに伝える重要な役割を果たす。
APIビルダーとドキュメントの場所が変わる
APIビルダースクリプトは、WooCommerce Dual APIプラグインのリポジトリに移動した。利用するには、プラグインをインストールするか、リポジトリをローカルにクローンする。
ドキュメントもDual APIプラグインのリポジトリ内に移設された。GitHub Pagesでも閲覧できる形で提供されている。開発者は最新のドキュメントをプラグインリポジトリで確認することになる。
エンドポイント登録のコード例
Dual APIプラグインはエンジンを提供し、エクステンション側で独自のGraphQLエンドポイントを登録する。WooCommerceのシンプルイベントサンプルプラグインから、登録方法のコードを示す。
use Automattic\WooCommerce\Api\Infrastructure\Main as DualApiMain;
add_action(
'plugins_loaded',
static function () {
if ( method_exists( DualApiMain::class, 'register_graphql_endpoint' ) ) {
DualApiMain::register_graphql_endpoint(
__DIR__,
'wc',
'/graphql/simple-events'
);
}
}
);このコードは、プラグインの読み込み時にDual APIエンジンが利用可能か確認し、利用可能であればGraphQLエンドポイントを登録する。エンドポイントのパスや名前空間はエクステンションごとに自由に設定できる。
Dual APIは引き続き実験的ステータス
Dual APIはプラグインに移行した後も、実験的なステータスは変わらない。Automattic\WooCommerce\Api名前空間以下のすべての要素は、後方互換性のない形で変更される可能性がある。
つまり、将来のリリースでAPIの構造が変わったり、削除されたりする可能性があるということだ。このため、本番環境のエクステンションでDual APIを使用することは推奨されていない。開発用途や検証目的に限定して使うべきだろう。
開発者コミュニティへのフィードバック募集
WooCommerceチームは、Dual APIエンジンが実際に有用かどうか、非実験的な状態でWooCommerce本体に含めるべきか、改善点はないかについて、開発者からの意見を求めている。
フィードバックはGitHubの専用ディスカッションページで受け付けている。Dual APIを試した開発者は、実際の使用感や要望を共有することで、今後の方向性に影響を与えることができる。
この記事のポイント
- WooCommerce 11.2でDual APIエンジンがコアから削除され、専用プラグインとして独立した
- 10.9〜11.1の検証用商品・クーポンAPIは削除されるため、利用者は移行が必要
- プラグインの要件はWooCommerce 11.2以上、PHP 8.1以上
- 依存関係はプラグインヘッダーで宣言する
- 引き続き実験的ステータスであり、本番利用は推奨されない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.6でPHP 8.1必須化。11.3から警告表示、11.5まで利用可能
WooCommerce 11.6が2027年2月にリリース予定で、このバージョンからPHP 8.1以上が必須要件になる。PHP 7.4または8.0で動かしているストアは、それまでに移行準備を進める必要がある。
移行期間を確保するため、WooCommerce 11.3では管理画面に警告通知が追加される。通知は現在のPHPバージョンとホスティング事業者への相談を促す内容で、閉じることもできる。11.5までは従来のPHP環境でも更新を継続できる仕組みだ。
WooCommerceが公開した利用統計によれば、追跡対象ストアの約7％がPHP 7.4、約2％がPHP 8.0で稼働している。この記事では移行の背景、通知の内容、具体的な手順、影響範囲を整理する。
PHP 8.1必須化の背景にある3つの理由
セキュリティサポートの終了
PHP 7.4と8.0は、PHP公式のセキュリティサポートがすでに終了している。サポートが切れたバージョンでサイトを運営し続けると、新しい脆弱性が発見されても修正パッチが提供されない。WooCommerce側でパッチを出しても、PHPランタイム自体のリスクは残る。
依存関係の更新とコードパスの削減
PHP 7.4と8.0に対応し続けるには、古い依存パッケージを固定し、バージョンごとの分岐コードを維持する必要がある。PHP 8.1を最低ラインにすることで、開発者とエクステンション製作者は新しいPHP機能を使え、テスト対象の環境も減らせる。WooCommerceはすでにPHP 8以上での動作を長年サポートしてきた実績がある。
今回の変更は、最低ラインを引き上げて将来のリリースの土台を作るものだ。コミュニティからのフィードバックを受けて、対象リリースをWooCommerce 11.6に設定した。繁忙期の後に十分なテストとアップグレードの時間を確保できるよう配慮されている。
デモで示したように、最低要件の引き上げは単なる制限強化ではなく、開発基盤を健全化するための措置だ。PHP 8.1以降には型システムの改善やJITコンパイラの成熟など、パフォーマンスと保守性の面で有利な機能が揃っている。
WooCommerce 11.3で表示される警告通知
WooCommerce 11.3から追加される通知は、PHP 7.4または8.0で稼働するストアの管理画面にのみ表示される。現在のPHPバージョンを表示し、ホスティング事業者にアップグレードを相談するよう案内する。通知は閉じられる仕組みで、11.3の利用自体は従来のPHPでも継続できる。
通知の役割はあくまで予告だ。実際に最低要件が変わるのはWooCommerce 11.6がリリースされたタイミングになる。それまでは通常どおり11.3、11.4、11.5へと更新を続けられる。
通知を閉じた後でPHPバージョンを確認したい場合は、管理画面の「WooCommerce」→「ステータス」を開き、「サーバー環境」にある「PHPバージョン」を確認すればよい。ホスティング環境が更新済みなら、WooCommerceの推奨はPHP 8.3以上だ。
通知を確認した後の移行手順
通知が表示されたストアは、以下の手順でPHPアップグレードを進める。焦らず、ステージング検証を挟むのが安全だ。
PHPバージョンの確認
管理画面の「WooCommerce」→「ステータス」を開き、「サーバー環境」にある「PHPバージョン」を確認する。PHP 7.4または8.0が表示された場合は、移行の対象になる。WooCommerceのPHPアップデートガイドも参考になる。
ステージング環境での検証
バックアップを取得し、ステージング環境でPHP 8.3以上に切り替える。決済と支払い方法、配送計算、税計算、注文管理、スケジュールジョブ、テーマ、拡張機能、カスタムコードを一通り検証する。互換性の問題があれば、本番を変更する前に解決する。
本番環境の切り替えと確認
ステージングで問題がなければ本番を切り替え、再度「WooCommerce」→「ステータス」と重要フローを確認する。その後、WooCommerce 11.6への更新が可能になる。
ステージング検証は省略しがちだが、決済や配送計算の不具合は売上に直結する。特に拡張機能やカスタムコードを多用するストアでは、本番前に必ず検証したい。
アップグレードが間に合わない場合の選択肢
WooCommerce 11.5はPHP 7.4と8.0に対応する最後のリリースになる予定だ。ホスティングや拡張機能の制約で移行が遅れる場合は、11.5に留まって作業を進められる。WordPressはPHP要件を満たさないプラグインの更新を通常ブロックするため、11.6への更新はサーバー側のPHPバージョンが8.1以上になるまで制限される。
11.5に留まるのは一時的な選択肢だ。WooCommerceのセキュリティパッチサポートポリシーでは、CVSS 9以上の重大な脆弱性の修正は、直近21メジャーリリースシリーズにバックポートされる。しかしそれ以外の修正は最新版にしか提供されない。加えてPHP 7.4と8.0自体のセキュリティサポートも終了しているため、WooCommerceのパッチだけではランタイムのリスクを解消できない。
移行が遅れる理由として、特定の拡張機能がPHP 8.1以上に対応していないケースがある。その場合は拡張機能開発者に互換性の状況を確認し、代替手段を検討するのが現実的な対応だ。
ストアと拡張機能への影響範囲
利用統計から見る影響
WooCommerceが公開した統計によると、追跡対象ストアの約7％がPHP 7.4、約2％がPHP 8.0で稼働している。直近1年間にWooCommerceを更新したストアに限ると合計約6％で、この数値は継続的に減少している。実際に要件が変わる2027年2月にはさらに低くなると見られる。使用状況の追跡はオプトイン方式のため、この数値はサンプルであり全ストアの正確なカウントではない。
拡張機能マーケットの静的解析
WooCommerceは全拡張機能マーケットプレイスを対象にPHP 8.1互換性の静的解析を実施した。購入可能な1,357個の拡張機能のうち、0.22％に潜在的な問題が見つかり、開発者と手動で確認中だ。ただしこのスクリーニングはすべての拡張機能、テーマ、カスタム統合の動作を保証するものではない。各ストアは自分の環境でテストする必要がある。
拡張機能開発者と制作会社向けには、WooCommerce 11.6が使うPHP 8.1と推奨PHPバージョンの両方でテストするよう案内がある。互換性の問題を見つけた場合は、PHPとWooCommerceのバージョン、影響する拡張機能、再現手順をGitHubのイシューかコメントで共有することが推奨されている。
影響範囲は限定的だが、該当するストアにとっては計画的な移行が欠かせない。PHPアップグレードは早めに着手し、繁忙期に入る前に完了しておくのが安全だ。
この記事のポイント
- WooCommerce 11.6からPHP 8.1以上が必須になり、11.3で警告通知が追加される
- PHP 7.4と8.0は公式セキュリティサポートが終了しており、移行は不可避だ
- 11.5までは従来のPHP環境で更新可能だが、あくまで一時的な選択肢だ
- 移行前にはバックアップとステージング検証を必ず実施する
- PHP 8.3以上への更新がWooCommerceの現在の推奨だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ShopifyがWebMCPをチェックアウトに拡張、AIエージェントが注文確定まで対応
Shopifyが9月28日、WebMCPツールをチェックアウトに拡張した。ブラウザエージェントは購入者のタブで開いているチェックアウトを読み取り、更新し、購入者の確認を得た上で注文を確定できるようになった。
8月時点のWebMCPは商品検索とカート管理が中心だった。チェックアウトページへの誘導はできたが、注文の確定は購入者自身が行う必要があった。今回の拡張でAIエージェントが購入完了まで関与する形になる。
この記事では4つの新ツールの役割、購入者が制御を取り戻す場面、ブラウザ自動化との比較テスト結果を解説する。
WebMCPチェックアウト拡張の概要
8月の展開からの進化
WebMCPとは、ブラウザ内でAIエージェントがWebサイトの機能を利用するための仕組みだ。Shopifyは2026年8月に最初のWebMCPツールを公開した。当時は商品検索とカート管理が中心で、エージェントは購入者をチェックアウトページまで誘導するに留まっていた。
9月28日の拡張により、ブラウザエージェントはチェックアウトの状態を読み取り、配送先や支払い方法を更新し、購入者の確認を得た上で注文を確定できる。Shopifyの開発者向けチェンジログは「新しいAPIを公開するわけではなく、マーチャントの設定も不要」と説明している。
新しいツールの仕組み
新しいツールは購入者が見ているチェックアウトページと同じ状態を利用する。エージェントが裏側で別のセッションを操作するのではなく、実際に開いているチェックアウトの状態を読み書きする仕組みだ。
これにより購入者とエージェントの間で情報のずれが生じにくい。チェックアウトは各更新時に独自の検証を行い、エージェントが注文の商品を変更することはできない設計になっている。
このデモは8月時点と9月28日以降のWebMCPの機能差を示している。エージェントが「誘導役」から「取引実行役」に変わった点が今回の拡張の本質だ。
チェックアウトで利用できる4つのツール
各ツールの役割
ShopifyのチェックアウトWebMCPドキュメントによると、対象となるチェックアウトには4つのツールが登録される。
- get_checkoutはチェックアウトを読み取り、購入後は注文詳細も取得する
- update_checkoutは連絡先、配送または受け取り方法、割引コード、支払い方法、税番号などの追加項目を変更する
- complete_checkoutは注文を確定する
- navigate_to_storefrontはタブをストアに戻す
4つのツールは役割が明確に分かれている。読み取り、更新、確定、移動という一連の流れをエージェントが実行できる設計だ。
支払い方法の制限
これらのツールは新しいカード情報を受け付けない。エージェントは保存済みのShop Payカードを選択するか、ゲストチェックアウトが許可している場合はエージェントが持っているShop Pay承認を利用して支援できる。
それ以外の支払い方法は購入者がチェックアウトページで直接選択する必要がある。エージェントはあくまでもShop Payの範囲内で支払いを支援する形だ。これはエージェントがクレジットカード情報を扱うリスクを避ける設計といえる。
また、エージェントはWeb Bot Authを使用してブラウザリクエストに署名する必要がある。Web Bot AuthとはShopifyがエージェントを認識するための署名方式だ。署名がない場合、リクエストは優先度が下がったり、ボット検出システムによってブロックされたりする可能性がある。
購入者が制御を取り戻す場面
注文確定前の同意
Shopifyのドキュメントは、complete_checkoutを呼び出す前に現在の注文と合計を購入者に表示し、「注文の許可を得ること」をエージェントに指示している。
注目すべきは、Web Bot Auth署名、Shop Pay承認、準備完了ステータスはこの同意には該当しない点だ。エージェントが技術的に注文を確定できる状態であっても、人間の購入者が最終確認を行わない限り注文は実行されない。
これはAIエージェントの暴走を防ぐ安全設計として評価できる。自動化が進んでも、最終的な購入判断は人間が行うという原則を守っている。EC事業者にとっては、エージェントが勝手に注文を確定してしまうリスクを抑えられる仕組みだ。
支払いチャレンジとUI拡張
Shop Payログインや3D Secureなどの支払いチャレンジは、購入者にページ上での制御を戻す。3D Secureとはオンラインカード決済の追加認証方式で、不正利用を防ぐためにパスワードや生体認証を求める仕組みだ。
ブロッキングUI拡張機能やレビューステップも同様に、購入者が直接操作する場面となる。購入者はアプリが定義するチェックアウト拡張機能とのやり取りも管理する。エージェントがすべてを代行するのではなく、特定の場面では必ず人間が介入する仕組みになっている。
対象チェックアウトの条件と利用環境
Shop Pay必須の制限
Shopifyの標準3ページチェックアウトは、購入者がShop Payでチェックアウトする場合を除き、WebMCPツールを取得しない。B2Bチェックアウト、埋め込みチェックアウト、モバイルチェックアウトSDK内のチェックアウトも対象外だ。
他のショップの商品を含むチェックアウト、ドラフト注文、注文編集、支払い回収も除外される。この制限はマーチャントにとって重要な意味を持つ。すべてのチェックアウトでAIエージェントが注文を確定できるわけではない。
現時点ではWebMCPチェックアウトの適用範囲は「Shop Payを使う標準チェックアウト」に限られる。Shop Pay以外の支払い方法を選ぶ購入者には、エージェントはチェックアウトの支援ができない。この制限がWebMCPチェックアウトの普及にどの程度影響するかは、今後の利用データを見る必要がある。
Chromiumブラウザ限定
現時点では、エージェントがWebMCPを使用できるのはChromiumベースのブラウザのみだ。ChromiumとはGoogleが開発するオープンソースのブラウザエンジンで、Google ChromeやMicrosoft Edgeが採用している。
FirefoxやSafariでは利用できない。この制限はWebMCPの普及に影響を与える可能性がある。ただしChromeとEdgeがブラウザ市場の大部分を占めていることを考えると、実用上の影響は限定的かもしれない。
Checkout WebMCPとCheckout MCPの選択
2つのルートの違い
Shopifyはチェックアウトでのエージェント向けに2つのルートを文書化している。サーバーベースのCheckout MCPと、ブラウザ内で動作するCheckout WebMCPだ。
ShopifyはサーバーベースのCheckout MCPを推奨している。この方式ではエージェントが自身のサーバーからチェックアウトセッションを管理する。Checkout WebMCPは「エージェントがすでに購入者のブラウザで動作している場合のみ」使用するよう案内している。
両方ともUniversal Commerce Protocolのチェックアウト機能に依存し、同じチェックアウトオブジェクトを使用する。Universal Commerce ProtocolとはShopifyが提唱する商取引の共通プロトコルで、異なるシステム間で取引情報をやり取りするための標準仕様だ。
Checkout WebMCPはチェックアウトページが購入者のブラウザに登録するツールを通じて動作する。一方、Checkout MCPはサーバー側でリクエストを処理する。実行場所が異なるだけで、扱うデータは同じだ。
マーチャントの立場
どちらの方法でも、Shopifyはマーチャントが記録上のマーチャントのままであると説明している。エージェントが仲介者になっても、販売者としての責任はマーチャントに残る。
これは法的・会計的な観点で重要なポイントだ。AIエージェントが注文を確定しても、取引の主体はあくまでもマーチャントである。エージェントが誤った注文を確定した場合の責任の所在も、マーチャントが負うことになる。
ブラウザ自動化との比較テスト
成功率と速度の差
Shopifyのエージェンティックコマース担当チームに所属するGil Greenberg氏は、WebMCPとブラウザ自動化を比較する社内テストの結果を公開した。ブラウザ自動化とは、エージェントがページを読み取ってクリック操作を行う方式だ。画面上の要素を視覚的に認識して操作する必要があるため、処理が遅くなりがちだ。
テストはGPT-6 Solを使って、同じプロンプトと開始条件で実施された。2つのテストショップで合計10のチェックアウトタスクを実行した結果、WebMCPは60回すべて成功した。一方、ブラウザ自動化は60回中56回の成功だった。
ページセットアップ時間を除いた1回あたりの時間は、WebMCPが10.3秒、ブラウザ自動化が27.4秒だった。WebMCPが約2.7倍高速だった計算になる。
1回あたり 10.3秒
コスト 58%削減
1回あたり 27.4秒
コスト 基準値
この比較はWebMCPの優位性を示している。成功率、速度、コストの3つの指標すべてでWebMCPが上回った。
コスト面の優位性
コスト面でもWebMCPが優位だった。OpenAIのリスト価格で比較すると、WebMCPのコストは1回あたり58%低かった。速度が速いだけでなく、API呼び出し回数やトークン消費量も抑えられるためだ。
ただし、この結果には注意点がある。テストはShopifyのテストショップと単一モデルで行われたもので、実際の注文やコンバージョン率などの実データは含まれていない。また、Greenberg氏の投稿には1行だけ60回の試行と一致しない合計値が含まれている。
とはいえ、WebMCPが「有望な方向性」を示していることは間違いない。ブラウザの画面を読み取ってクリックする方式よりも、専用のツールを介して直接操作する方式のほうが効率的であることは、このテスト結果から十分に裏付けられている。
この記事のポイント
- Shopifyが9月28日、WebMCPをチェックアウトに拡張した
- エージェントがチェックアウトの読み取り、更新、注文確定まで実行できる
- 注文確定には購入者の明示的な同意が必須
- Shop Pay必須の制限があり、対象チェックアウトは限定的
- ブラウザ自動化との比較テストで成功率100%、速度2.7倍、コスト58%削減を達成
- マーチャントが個々のツールをオフにできるかは未確認
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AI検索時代のGEO対策、ChatGPTやPerplexityに引用されるための技術SEOとコンテンツ戦略
AI検索エンジンが情報取得の主流になりつつある。ChatGPT、Perplexity、Geminiなどの生成系エンジンは、質問に対する答えを直接生成する。従来の検索結果一覧からリンクをクリックする流れが変わり始めた。
この変化に対応するには、キーワード中心のSEOから生成エンジン最適化（GEO）への転換が必要だ。GEOとは、AIが回答を生成する際に自社コンテンツを一次情報源として引用してもらうための施策群である。従来SEOがブルーリンクのクリック獲得を目指すのに対し、GEOはAIの回答内で引用されることを目指す。
本記事ではAIクローラーへの技術対応と、AIに引用されやすいコンテンツ戦略の両面から具体的な施策を解説する。ECサイト運営者とWeb制作担当者に向けた内容だ。
GEOの基本を理解する
生成エンジン最適化（GEO）は、AI検索エンジンが回答を合成する際に、自社サイトのコンテンツを情報源として検出・理解・引用されることを目的とする。従来SEOが「検索結果のクリック数」を評価指標にするのに対して、GEOは「AI回答内での引用率」を重視する。
従来SEOからGEOへの考え方の転換をBeforeとAfterで対比した。
AI検索エンジンがサイトを選ぶ仕組み
AI検索エンジンは検索拡張生成（RAG）という仕組みで回答を作る。RAGとは、事前学習済みの大規模言語モデル（LLM）にリアルタイムのWeb情報を取り込ませ、最新の情報を含む回答を生成する技術だ。AIは質問を受けると、関連するWebページを取得し、その内容を引用しながら回答を合成する。
つまりAI検索で自社サイトが引用されるには、AIが「このページは信頼でき、回答に使える」と判断できる状態にしておく必要がある。そのために技術SEOとコンテンツ戦略の両面から対策を進める。
AIクローラー対応の技術SEO
AIプラットフォームは専用のクローラーとRAGパイプラインを使ってWebコンテンツを取り込む。技術チームは、独自データを保護しながらコンテンツへのアクセスを確保する必要がある。
AI検索の裏側では、このようにクローリングから引用までの5段階の処理が走る。
robots.txtでボットを区別する
AI関連のクローラーは用途別に分かれている。学習用クローラー（GPTBotなど）とリアルタイム検索用クローラー（ChatGPT-User、PerplexityBotなど）を区別し、robots.txtで個別にアクセス制御する。学習用ボットをブロックすれば独自データを保護でき、検索用ボットを許可すればAI回答への情報提供を継続できる。
ECサイトの場合、商品の仕様データや価格情報は検索用ボットに公開しつつ、学習用ボットのアクセスを制限する運用が現実的だ。
構造化データでAIに文脈を渡す
Schema.orgの語彙を使った構造化データの実装範囲を広げることが重要だ。Organization、Product、HowTo、TechArticle、FAQPageなどのタイプを適切に付与すると、LLMのパーサーがエンティティ間の関係性を明示的に理解できるようになる。
ECサイトであれば商品ページにProductスキーマを付与し、価格、在庫状況、レビュー評価を機械可読な形式で伝える。AI検索エンジンが「この商品はいくらか」という質問に答える際、構造化データが整っているページが優先的に引用される。
RAGチャンキングを意識したHTML設計
RAGパイプラインはWebページを小さな単位（チャンク）に分割し、ベクトルデータベースに格納する。この分割処理を意識して、ページ構造を論理的なHTML階層で設計することが有効だ。<h2>や<h3>の見出しを適切に使い、各段落を独立して理解できる簡潔な長さに保つ。
見出しが明確で段落が短いと、RAGの分割処理が正確になり、回答生成時に該当箇所だけをクリーンに抽出・引用できる。長い段落に複数の話題を詰め込むと、チャンクの境界が曖昧になり引用精度が下がる。
表示速度とインデックス性の確保
AI検索エンジンはライブ検索の際、高速かつ安定したページ取得を優先する。モバイル対応を徹底し、サーバー応答時間（SRT）を短く保つことが重要だ。取得がタイムアウトすると、そのページは回答生成の候補から除外される。
SRTとはサーバーがリクエストに応答するまでの時間である。画像最適化、キャッシュ活用、CDN導入などでSRTを短縮しておくと、AIクローラーによるリアルタイム取得の成功率が上がる。
生成AIに引用されるコンテンツの作り方
AI検索エンジンはハルシネーション（誤情報生成）のリスクを減らすため、権威性の高い情報源を優先的に参照する。コンテンツ戦略は「検証可能な情報密度」を軸に再設計する必要がある。
AIが回答に使いやすいコンテンツ構成への変更点を示した。
エンティティベースの権威性構築
エンティティとは、人物、組織、商品、概念など明確に定義できる対象のことだ。自社ブランドの中核となるエンティティを中心に、関連する業界用語やトピックを密度高くまとめたトピッククラスターを作る。
具体的には、主語と述語が明確で断定を含む文章を心がける。「当社の商品Aは業界最高水準の耐久性を持つ」のような曖昧な表現ではなく、「商品Aは10万回の開閉テストに合格した」と具体的な事実を書く。このような文章はAIが抽出しやすく、引用時の信頼性も高い。
独自データとオリジナルリサーチの発信
AIモデルは集約された二次情報よりも、独自の統計、調査結果、オリジナルレポートを優先的に参照する。自社で実施したアンケート結果、商品の性能テストデータ、業界動向の独自分析などを公開することで、一次情報源としての地位を確立できる。
ECサイト運営者であれば、自社商品の比較テスト結果、顧客満足度調査、購入データから見える傾向などを記事化すると効果的だ。競合が真似できない独自データは、AI検索で安定的に引用される資産になる。
直接回答抽出フォーマットの採用
技術記事や教育コンテンツでは、ページの冒頭に要約表、箇条書きのポイント、明確な定義を配置する。検索意図の高い質問には、背景説明の前に直接回答する構成が有効だ。
たとえば「商品Aの防水性能はどの程度か」という質問を想定したページでは、冒頭に「IPX7等級で水深1メートルに30分間耐える」と明記し、その後に試験方法や比較データを展開する。この構成ならAIが回答をそのまま引用できる。
マルチモーダル検索への対応
AI検索エンジンは音声や画像を使った検索にも対応し始めている。マルチモーダル検索とは、テキスト以外の入力手段を含む検索のことだ。画像検索AIが商品を認識して回答するケースが増える。
商品画像や図表には説明的なalt属性を付与し、構造化されたキャプションを添える。画像の内容をAIが理解できるようにすることが、将来のマルチモーダル検索での可視性につながる。
AI検索を味方につける運用の転換点
従来のオーガニック検索トラフィックは、AIが直接回答を返すようになるにつれて集約化が進む可能性がある。ただし、技術インフラを最適化し、高密度な一次情報を公開し続ければ、ブランドはAI検索の裏側で推奨される情報源としての地位を維持できる。
重要なのは、目先のクリック数ではなく「AIに引用される確率」を評価指標に加えることだ。AI検索時代のブランド可視性は、回答の出典として選ばれる頻度で測られる。ECサイト運営者は、商品情報の構造化と独自データの発信を組み合わせ、この変化に対応すべきである。
SEO担当者と技術チームが協力し、クローラー管理からコンテンツフォーマットまでを一貫して整備すること。これがAI検索時代に競争優位を保つための実践的なアプローチだ。
この記事のポイント
- AI検索時代には従来のキーワード中心SEOからGEO（生成エンジン最適化）への転換が必要
- robots.txtで学習用ボットと検索用ボットを区別し、独自データを保護しつつ引用機会を確保する
- 構造化データの拡充とRAGチャンキングを意識したHTML階層設計が技術SEOの柱になる
- 独自データとオリジナルリサーチの発信がAIからの一次情報源としての地位を確立する
- 冒頭に要約と結論を置く直接回答フォーマットがAIによる引用率を高める
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Neonがリアルタイム機能を追加へ。Electricチームが語る開発の狙いと課題
NeonがバックエンドプラットフォームのGAを発表した直後、次の大きなステップとしてリアルタイム機能の追加を計画している。開発を担当するのは、2026年8月にNeonへ加わったElectricのチームだ。PostgreSQL上でのリアルタイムデータ同期に5年以上取り組んできたメンバーが中心となる。
Electric共同創業者のJames Arthur氏へのインタビューを基に、開発の狙いと技術的な課題を解説する。リアルタイム同期がなぜ本番環境で崩れやすいのか、その根本的な原因とNeonが目指す解決策が見えてくる。
Neonがリアルタイム同期をバックエンドに追加
NeonはPostgresを基盤としたサーバーレスデータベースサービスだ。2026年9月にバックエンドプラットフォーム全体のGAを発表したばかりである。このプラットフォームにリアルタイム機能が加わることで、データベースからアプリケーションへのデータ同期が自動化される。開発者はデータベースの変更を手動でポーリングする必要がなくなる。
リアルタイム同期とは、データベースに変更が発生した瞬間にアプリケーションへ反映する仕組みだ。従来のアプリケーションは一定間隔でデータベースに問い合わせて変更を取得していた。リアルタイム同期では、変更が発生した時点でクライアントへ通知される。チャットや共同編集ツールなど、即時性が求められるアプリケーションで重要になる。
このデモはポーリング方式とリアルタイム同期の違いを示している。左側ではアプリが定期的にデータベースへ問い合わせるため、変更がなくても通信が発生する。右側ではデータベースに変更が起きた時だけ通知が届く。無駄な通信がなくなり、遅延も短縮される。
開発を担当するElectricチームは、PostgreSQL上でのリアルタイムデータ同期に長年取り組んできた。Neonのブログ記事によると、James Arthur氏は大手企業への参加について「これほど強固なエンジニアリング文化を持つ環境は想像していなかった」と語っている。直属の上司がAWS Auroraを構築した人物であることにも触れ、意思決定の質の高さを実感しているという。
リアルタイム同期が本番環境で崩れる根本的な課題
リアルタイム機能には共通の弱点がある。デモでは美しく動作するが、本番環境では性能が落ちて崩れる傾向がある。James Arthur氏はこの問題を「表現力と性能の間に根本的なトレードオフがある」と表現する。
デモ環境では少量のデータと少数のクライアントで動作する。本番では大量のデータと多数のクライアントが同時に接続する。この環境で同期の正確性と速度を両立させるのは難しい。同期できる内容を増やせば表現力は上がるが、システムの性能は下がる。性能を優先すれば、同期できる内容が限られる。この二律背反が、リアルタイム同期が数十年研究されながらも主流にならない理由だ。
デモと本番の差を視覚化した。デモでは少量のデータと少数のクライアントで快適に動作する。本番では大量のデータと多数のクライアントが同時に接続し、性能が崩れる。このギャップがリアルタイム同期の導入を難しくしている。
ElectricがNeonに加わった本当の理由
Electricは同期を専門とするインフラツールとしてスタートした。しかし、ここ数年でインフラスタートアップの市場環境は大きく変わった。James Arthur氏はNeonのブログ記事で、専門的なインフラツールへの投資が減り、エージェントがより高レベルの抽象化を求めるようになったと説明する。
Electricのチームがたどり着いた結論は明確だ。同期はバックエンド・アズ・ア・サービスの機能であるべきだ。同期を中心にした製品を構築するのではなく、既存のプラットフォームを強化する方が合理的だと判断した。Neonは開発者向けに大きなリーチを持つ。Databricksは大企業向けの流通基盤と商業体制を持つ。この2つの強みを活用することで、同期技術をより早く主流にできる。
方針転換の比較を示した。Electric単独で同期ツールを販売する時代は終わり、NeonとDatabricksの流通基盤を使って同期を主流にする戦略に変わった。同期は独立した製品ではなく、バックエンドプラットフォームの一部として提供される。
Neonのバックエンド戦略とリアルタイムの位置づけ
Neonのバックエンドプラットフォームにリアルタイム機能が加わることで、Postgresを選択しない理由がなくなる。現代のアプリケーションとエージェントは、リアルタイムデータとエンドツーエンドのリアクティブ性を必要とする。CTOやテックリード、コーディングエージェントは、バックエンドを選ぶ際にリアルタイム機能の有無を確認する。
リアルタイム機能はNeonとLakebaseにネイティブに動作する。スケールトゥゼロとブランチングにも対応する予定だ。スケールトゥゼロとは、利用がない時にリソースを自動的にゼロまで縮小する仕組みだ。ブランチングはデータベースの分岐を作る機能で、開発やテストを安全に行える。これらの機能とリアルタイム同期が統合されることで、開発者は環境を意識せずにリアルタイム機能を利用できる。
リアルタイム機能がNeonに加わることで、バックエンド選定の流れが変わる。開発者は標準機能としてリアルタイム同期を利用でき、AIコーディングエージェントもNeonを推奨するようになる。これがNeonの目指す完全なバックエンドプラットフォームの姿だ。
Neonのブログ記事によると、James Arthur氏は具体的な技術仕様について「まだ詳細は言えない」としながらも、NeonとLakebaseにネイティブに動作し、スケールトゥゼロとブランチングにネイティブ対応すると明言している。正式な発表は今後行われる予定だ。早期アクセスに興味がある開発者は、NeonのDiscordコミュニティで情報を追える。
この記事のポイント
- Neonがリアルタイム同期機能をバックエンドに追加し、Electricチームが開発を担当する
- リアルタイム同期はデモでは動くが本番で崩れやすく、表現力と性能のトレードオフが根本課題
- Electricは単独の同期ツールから、NeonとDatabricksのプラットフォーム戦略に方向転換した
- リアルタイム機能はNeonとLakebaseにネイティブ対応し、スケールトゥゼロとブランチングもサポートする
- 正式な技術仕様は今後発表予定で、早期アクセスはNeonのDiscordで募集している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
カード不正利用の地域差が鮮明に。3Dセキュア義務化の効果と残る課題
カード不正利用の発生率が地域によって大きく異なる現状を、Stripeが2022年1月から2026年3月までの数十億件の取引データを分析して明らかにした。2026年第1四半期にはアジア太平洋地域が初めて欧州・中東・アフリカを下回り、3Dセキュア義務化の効果が数字で裏付けられた形だ。
一方で、中南米は依然として高水準が続く。2025年のカード不正率は欧州・中東・アフリカと比べて160%高く、アジア太平洋と比べても151%高い。国境を越えてサービスを提供する事業者にとって、地域ごとのリスク環境の違いを理解することは避けて通れない課題になっている。
この記事では、Stripeの分析結果を基に、アジア太平洋・欧州・中南米の3つの地域で何が起きているのか、どのような対策が有効なのかを、システム開発やEC運営の実務者の視点で解説する。
上の図は、2025年時点の地域別カード不正率の立ち位置を概念的に示したものだ。以降の章では、それぞれの地域で何が起きているのかを詳しく見ていく。
アジア太平洋で不正率が初めて欧州を下回った
Stripeの分析によると、アジア太平洋地域の不正率は2022年から2025年にかけて最も一貫した低下傾向を示した。そして2026年第1四半期には、分析対象期間で初めて欧州・中東・アフリカ地域を下回る水準に到達している。この地域で進められてきた3Dセキュア義務化の政策効果が、データとして明確に現れた形だ。
3Dセキュアとは、オンラインカード決済時に「購入者が正当なカード所有者本人であるか」を追加認証する仕組みだ。クレジットカード番号と有効期限だけで支払えていた従来の方式に対し、ワンタイムパスワードやアプリでの承認など、もう一段階の確認を挟むことで不正利用を防ぐ。
マレーシアの3DS義務化で不正率74%減
アジア太平洋地域の中でも特に目立つのがマレーシアだ。2022年から2025年にかけて、カード不正率が74%も減少した。これはアジア太平洋地域で最大の減少幅である。
背景には、マレーシア中央銀行による比較的厳格な3Dセキュア義務化がある。金融機関には多要素認証の導入、SMSベースのワンタイムパスワードから安全なアプリベースの承認への移行、カード所有者が即座にアカウントを凍結できる機能の提供が求められている。この積み重ねにより、未認証の取引が通り抜ける余地が他市場より少なくなっている。
この改善は、単に認証を追加しただけではなく、SMSからアプリ承認へ移行した点が大きい。SMSのワンタイムパスワードはSIMスワッピングや転送攻撃の対象になりやすく、アプリベースの承認はこれを大幅に抑える。認証手段の設計が不正率に直接影響する好例だ。
日本の4月義務化も効果を確認
日本の企業も、2022年から2025年にかけて毎年不正率が低下した。この背景には2025年4月に施行された3Dセキュア義務化がある。Stripeの紛争データ分析によると、2025年の紛争率は前年同期比で30%以上低かった。
紛争率とは、カード所有者が不正な取引だと気づいて支払いに異議を申し立てる割合だ。不正利用が発生すれば紛争につながるため、紛争率は不正率と強い相関を持つ指標として使われる。日本の義務化は施行から短期間で効果を出している。
欧州は改善基調、国ごとの差が大きい
欧州全体では、カード不正率が2022年から2025年にかけて21%減少した。ただし改善ペースは国によって大きく異なる。フランスとイギリスは着実に減らしている一方で、イベリア半島は逆行して悪化している。
フランスとイギリスは着実に減少
フランスは2022年から2025年にかけて不正率が40%減少、イギリスは27%減少した。両国とも欧州の主要市場であり、決済エコシステムの成熟度が改善の原動力になっている。
ここで重要なのがSCA（Strong Customer Authentication / 強力な顧客認証）規制の存在だ。EUの決済サービス指令に基づくこの規制は、オンライン決済時に二要素認証を義務付けるものだ。イシュア（カード発行会社）に高度な不正対策インフラへの投資を促し、認証の枠組みと時間を与えてきた。
フランスには先行的な土壌もある。チップとPINによる認証をいち早く導入した国のひとつで、二要素認証が他国より何年も前から一般化していた。カード所有者が認証フローに慣れており、離脱せずに完了できる率が高いことが不正率の低下に寄与している。
イベリア半島は例外的に悪化
一方、イベリア半島（スペインとポルトガル）は、2022年から2025年にかけて不正率が毎年増加した。欧州で例外的な悪化傾向を示した地域だ。
スペインとポルトガルは、認証手段としてワンタイムパスワードを多用している。SMSベースのパスワードは生体認証やアプリ承認と比べて不正に脆弱だ。さらに、両国は金融機関を装ってSMSでカード情報を盗む「スミッシング」攻撃の標的にもなっている。認証手段の脆弱性と攻撃の集中が重なり、欧州の改善トレンドに乗れていない。
中南米は構造的要因で高止まり
中南米のカード不正率は、Stripeの分析対象地域の中で2022年1月以降一貫して最も高い。2025年時点でも、北米より65%、アジア太平洋より151%、欧州・中東・アフリカより160%高い水準だ。
一部の国では改善が見られる。エクアドル、パナマ、ブラジルでは2022年から2025年にかけて不正率が低下した。しかし地域全体では、いくつかの構造的要因が高止まりの原因になっている。
現金経済と紛争ルールの複雑さ
中南米は他地域と比べて現金ベースの経済が根強い。これはカード不正検知システムが参照できる過去データの蓄積が少ないことを意味する。機械学習による不正検知は学習データの量と質に依存するため、取引データが少ない地域では精度を上げにくい。
紛争処理の枠組みも複雑だ。この地域のカード紛争ルールはカード所有者に有利なケースが多く、異議申し立てが発生した場合の立証責任は事業者側に重くのしかかる。正当な取引であっても、事業者が証拠を提示できないとチャージバック（取引の強制取消）につながりやすい。
電子請求書の要件も国ごとに異なる
中南米の規制環境も運用負荷を高めている。多くの国で電子請求書の義務化が進んでいるが、適用範囲、フォーマット、成熟度はバラバラだ。メキシコでは、デジタルサービス提供者に対して税務当局への取引データへの恒久的なアクセス提供が義務付けられている。
メキシコのケースでは、税務当局が独自のスケジュールで事業者システムにログインし、個別の取引を検索できる。取引は1日以内に検索可能で、5年間の保存が義務付けられている。この種の要件が事業者のオペレーションを複雑にし、不正対策へのリソース配分を難しくしている。
国際展開における不正対策の実務ポイント
地域ごとに不正環境が異なる以上、単一のセキュリティポリシーを全市場に適用するのは危険だ。では、複数国でサービスを展開する事業者はどのような対応を取るべきか。データと規制の両面から、実務的なポイントを整理する。
3DS認証の最適化で不正と誤検知のバランスを取る
SCA規制の対象地域では、3Dセキュア認証の導入が不正対策の基本になる。Stripeの分析によると、SCA地域の事業者はAIによる最適化を活用することで、全取引の不正率を平均7.67%削減しつつ、コンバージョンを平均1.20%向上させられる。
ここで重要なのは、すべての取引に同じ強度の認証を求めるのではなく、リスクに応じて認証を出し分けることだ。低リスクの取引に認証を強制すると離脱につながり、高リスクの取引に認証をかけないと不正が通ってしまう。AIによるスコアリングでこのバランスを取る。
認証の出し分けは、不正率と誤検知率のトレードオフを調整する実務的な手法だ。すべてに認証をかければ不正は減るが購入完了率が下がり、認証をなければ購入はスムーズでも不正が増える。AIの精度がこのバランスの成否を左右する。
AIによる不正検知を全決済手段に拡大
カードだけでなく、銀行引き落とし、ステーブルコイン決済、デジタルウォレット、即時決済、現金バウチャーなど、決済手段は多様化している。Stripeの不正防止プロダクトは、これらすべての決済手段を保護対象に含めるよう拡大された。決済手段ごとにセキュリティの仕組みが異なるため、不正検知のレイヤーを横断的に設けることが重要だ。
企業が国際展開する際は、進出先ごとの規制要件と不正パターンを事前に把握し、認証の設定と検知ロジックを地域別にチューニングする必要がある。マレーシアや日本の3Dセキュア義務化は効果を上げており、規制が先行する地域では「義務化される前に自主的に導入する」ことで、競合より低い不正率を実現できる可能性がある。
この記事のポイント
- アジア太平洋地域のカード不正率が2026年第1四半期に初めて欧州・中東・アフリカを下回った
- マレーシアと日本の3Dセキュア義務化が不正率を大きく押し下げた
- 欧州は全体で改善基調だが、イベリア半島はSMS依存とスミッシングで逆行
- 中南米は現金経済、紛争ルール、規制の複雑さで不正率が高止まりしている
- 複数国展開ではAIによる認証の出し分けと決済手段横断の不正検知が有効
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AI検索がECを変える。検索クエリは6語から24語へ拡大
AI検索エンジンの台頭により、ECサイトの商品発見の仕組みが根本から変わりはじめている。消費者は短いキーワードの組み合わせではなく、文脈や使用シーンを盛り込んだ長い自然言語で商品を探すようになった。
従来の検索エンジンでの平均クエリは約6語だった。一方、大規模言語モデル（LLM、人間のように自然な文章を理解・生成できるAIモデル）を活用したAI検索では、平均約24語にまで拡大している。この4倍の変化は、商品カタログとプロダクトページの設計思想そのものの見直しを迫るものだ。
この記事では、AI検索がECサイトに与える具体的な影響、対応策、そしてマーケティング担当者が見直すべき思考法について解説する。WooCommerceをはじめとするECプラットフォームを運営する事業者にとって、今後12ヶ月の優先課題が見えてくるはずだ。
AI検索が変える検索クエリの姿
消費者が検索窓に入力する言葉が劇的に変化している。かつては「防水 ランニング シューズ 軽量」のような短いキーワードの羅列が一般的だった。いまは「雨の日でも滑りにくくて、通勤でも使える軽いランニングシューズを探しています。週末は10キロ走るのでクッション性も欲しいです」といった会話調の質問に変わっている。
6語から24語へ、検索行動の変化
MarTechのポッドキャスト「Conversations with MarTech」に出演したOpiversalのCEO、Lucas Tieleman氏は、この変化を具体的な数字で示している。従来のGoogle検索での平均クエリは約6語だった。ところがLLMを活用した検索では平均約24語に拡大している。ユーザーは検索エンジンに「単語を投げる」のではなく「相談する」姿勢に変わったのだ。
会話的クエリが商品発見に与える意味
検索クエリが会話的になるということは、商品が文脈で選ばれる時代の到来を意味する。「軽いランニングシューズ」という単語だけでは用途が見えなかった。しかし「通勤で使える」「週末に10キロ走る」といった文脈が加わることで、同じ商品が異なる理由で選ばれる可能性が生まれる。Tieleman氏は「同じ商品でも、人によって異なる意味を持ちうる」と述べている。この多義性が、これからのECサイトの設計を難しくする一方で、差別化の余地も広げている。
検索クエリが短いキーワードから会話的な長文へ変化したことを示している。ECサイト側もこの変化に対応した情報設計が必要になる。
旧来の商品カタログが抱える限界
多くのECサイトの商品ページは、青いリンクとキーワード検索の時代に作られたものだ。商品名、価格、カテゴリ、簡単な説明文という最小限の属性を並べた静的ページが中心だった。この設計は、消費者が「単語を入力して結果の一覧から選ぶ」という行動パターンを前提にしている。文脈や使用シーンを含む24語のクエリに対して、こうした静的ページは十分な回答を提供できない。
ボットトラフィックの急増が見せる新しい現実
Tieleman氏が指摘するのは、AIエージェントによるボットトラフィックの急増だ。自律型AIエージェントが実際に購入を行う段階にはまだ至っていない。しかし、ユーザーの質問に答えるためにECサイトを巡回するLLMのトラフィックは爆発的に増えている。マーケティング担当者は、インプレッション（表示回数）とセールスの関係を従来とは異なる視点で捉え直す必要がある。表示回数が増えても、それが人間の目に触れているとは限らないからだ。
文脈的な属性情報とFAQを加えることで、AIが商品を理解しやすくなることを示している。
ECサイトがAI検索に対応するための3つの施策
AI検索時代において、ECサイトが取るべき具体的な対策は3つに集約できる。構造化データの整備、動的なランディングページ生成、そしてFAQの戦略的拡充だ。どれも特別なツールなしで今日から着手できる。
構造化データと会話的属性情報の整備
商品フィードの重要性はかつてないほど高まっている。構造化データとは、商品名や価格、属性などが機械に読み取りやすい形式で整理されたデータのこと。検索エンジンとAIプラットフォームに商品の存在を知らせるためには、高度に構造化されたデータを継続的に供給する必要がある。商品名と価格だけでは不十分だ。使用シーン、解決できる課題、関連するFAQなど、会話的な属性情報を追加することで、AIが商品を文脈に応じて提案しやすくなる。
WooCommerce運営者であれば、商品データの拡張は比較的容易だ。商品説明欄を充実させるだけでなく、カスタム属性やカテゴリタクソノミーを使って使用シーンや解決課題を明示的に登録できる。属性情報は商品のタイプごとに設計し、サイト全体で一貫した命名規則を保つことが重要だ。
動的なランディングページ生成
AIがコンテンツ制作の限界費用を大幅に下げたことで、EC事業者は変動するソーシャルトレンドや自然言語のクエリに合わせてカスタムランディングページを大量に生成できるようになった。Tieleman氏は「ウェブサイトは生きた有機体である」と表現している。固定された商品ページだけでなく、検索文脈に応じたランディングページを動的に用意することが、これからのECサイトには求められる。
FAQの戦略的拡充
FAQセクションは、AI検索対策の隠れた有力手段だ。商品に関する具体的な疑問と回答を構造化して掲載することで、AIエージェントが商品のユースケースを理解しやすくなる。「このシューズは幅広の足型に対応していますか」といった具体的な質問と回答は、まさに24語クエリの世界で求められている情報だ。FAQはユーザーが実際に抱く疑問を想定して作成し、商品データの一部として機械に読み取らせる意識が重要になる。
AIエージェントが商品データを巡回し、文脈に合う商品を提案する流れを示している。各ステップで構造化データが正しく読み取れるかが成否を左右する。
エージェント型購買の現実とマーケティングの再考
Tieleman氏との対話から浮かび上がるのは、AIエージェントが本当に「購入」を行うのはまだ先だという現実だ。現在はあくまで調査・比較の段階で、ボットが商品情報を収集しているにすぎない。しかし、この段階で商品データがAIに正しく理解されているかどうかが、将来の購入決定に直結する。準備を怠れば、AI検索の世界で商品が存在しないのと同じ扱いを受けるリスクがある。
単一の正解に執着することの無意味さ
Tieleman氏は「マーケティング業界が信じている最大の嘘」として、単一の正解を探し求めることへの執着を挙げている。現実には、現代のテクノロジーを使えば複数の施策を並行して検証し、効率的に失敗しながら最適解に近づくことができる。同氏の「いまのテクノロジーを使えば、もっと効率的に間違えることができる」という指摘は、マーケティングの思考法を変える視点だ。A/Bテストを繰り返すことへの心理的障壁を下げ、失敗をデータとして蓄積する姿勢が求められる。
商品を文脈で選ばせる設計へ
「AppleはUXとデザインの重要性を示す好例だ。Amazonはそうではないことを示している」というTieleman氏の発言は、ECサイト設計の2つの方向性を端的に表している。徹底したUXで差別化するのか、価格と品揃えで勝負するのか。AI検索時代には、どちらの戦略を選ぶにせよ、商品データが文脈を伝えられるかどうかが成否を分ける。デザインの優劣ではなく、データの伝達力が新しい競争軸になるのだ。
この記事のポイント
- 検索クエリは平均6語から24語に拡大し、会話調の質問へと変化している
- 従来の静的カタログは、文脈を含む長いクエリに十分応えられない
- AIエージェントによるボットトラフィックが急増し、商品データの構造化が必須になっている
- 構造化データ、会話的属性情報、FAQの拡充がAI検索対策の3本柱となる
- 単一の正解を求める思考を捨て、複数の施策を効率的に検証する体制が有効
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験