Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金
広告型モデルの限界とAIエージェント向け従量課金
2026年7月1日、CloudflareはMonetization Gatewayを発表した。HTTPの402ステータスコードを拡張したオープンプロトコル「x402」を基盤に、ウェブ上のあらゆるリソースに対して従量課金を適用できる仕組みである。保護対象はウェブページ、データセット、API、MCPツールにおよび、代理店や大規模言語モデルが自律的に支払う時代を見据えている。
背景にはウェブビジネスモデルの構造変化がある。30年にわたり、コンテンツは広告や月額課金で収益化されてきた。しかしAIエージェントが人間に代わって情報を消費するようになると、バナー広告をクリックすることも、毎月のサブスクリプションを維持することもない。エージェントは必要なデータを一度取得すれば、数十回、数千回と繰り返しアクセスし始める。Cloudflareの発表資料によると、AIクローラーのリクエスト数は、そこからサイトへ誘導される訪問者1人あたり数百～数万回に達しているという。
従来のAPI従量課金は既存ユーザー向けに限定され、サブセント単位の少額決済には向かなかった。クレジットカードの手数料が取引額を上回るためだ。ここでCloudflareが着目したのが、ステーブルコインによる一瞬の決済である。Monetization Gatewayは、支払い検証と流量制御をエッジで完結させ、オリジンサーバーに過剰な負荷をかけずに課金を実現する。
CloudflareはすでにContent Independence DayでAIクローラーの制御機能を提供し、Pay Per Crawlでクローラーに課金する仕組みを導入していた。Monetization Gatewayはその延長線上にあり、クローラー以外の任意の呼び出し元に対して課金できる点が新しい。
エージェントが変える支払いの単位
AIエージェントが自律的に行動するようになれば、サービスの課金単位も座席数や月額から「リクエスト数」「トークン数」「成果物」へと移行する。Cloudflareが例示したのは、1回のウェブ検索あたり数セント、アップロードエンドポイントで0.001ドルの基本料金＋1MBあたり0.01ドル、サポートエスカレーション解決時に0.99ドルといった単位である。
これまで実現が難しかったサブセントの決済を、x402プロトコルとステーブルコインが可能にする。ステーブルコイン（Open USDやUSDC）は1秒未満で決済が完了し、手数料が無視できるほど小さい。従来の決済手段では、手数料が支払い額を上回る逆転現象が起きていたが、それが解消される。
Cloudflareが提供する課金インフラ
Cloudflareの強みは、すでに自社の課金システムや顧客向けアナリティクスで従量課金の会計基盤を構築してきたことにある。Monetization Gatewayでは、売り手と買い手の間に入り、支払い証跡をHTTPリクエストに埋め込む形で検証パスを統合する。メータリング、支払い交換、決済はすべてオリジンサーバーの外で完結し、サイト運営者は課金ルールと価格だけを定義すればよい。買い手のオンボーディングや請求システムの構築は不要だ。
x402プロトコルとは
x402はHTTPのステータスコード「402 Payment Required」を実際に活用するオープンプロトコルである。この規格はCloudflareがx402 Foundationのもとで25以上の業界リーダーと共同開発を進めている。従来の402は予約状態にあり、実際の決済フローには使われていなかった。
x402のやりとりは単純だ。クライアントが支払い必須のリソースをリクエストすると、サーバーは402 Payment Requiredとともに価格、受け入れ可能な通貨、支払い先を含む小さなペイロードを返す。クライアントは支払いを実行し、支払い証明を添えてリクエストを再送する。ファシリテーター（検証者）が証明を確認し、オリジンサーバーが最終的にリソースを返す。すべてが通常のHTTPリクエスト/レスポンスの中で完了し、決済ページへのリダイレクトも個別の決済API呼び出しも発生しない。
x402の利点は2つある。1つは最小単位がセント未満まで刻めること。プロトコルのオーバーヘッドが極めて低く、取引額が支払いコストを下回る逆転を防げる。もう1つは、買い手が売り手のアカウントを事前に取得する必要がないことだ。支払い自体が資格情報として機能するため、サインアップやAPIキー発行なしに取引が成立する。
サブセント決済と一瞬の決済
ステーブルコインを使う決済は、現在の主要な決済レールでは実現できなかったスピードと低コストを両立する。Cloudflareはサブセカンド（1秒未満）の決済を目標に掲げている。エージェントが数セントのデータを購入するために数ドルの手数料と数日の決済期間を待つ必要はなくなる。この速度と低コストが、AI時代の大量のマイクロペイメントを支える。
Monetization Gatewayの機能
Monetization GatewayはCloudflareのエッジネットワーク上で動作し、330以上の都市でリクエストを処理する。x402ハンドシェイクが買い手の近くで実行されるため、レイテンシが小さくなり、オリジンサーバーへの負荷も軽減される。
具体的な課金ルールの適用方法として、以下のような機能が計画されている。
- 特定のRESTメソッドへの課金。/api/premium/* へのGETやPOSTに0.01ドルを設定できる
- タスクの複雑さに応じた変動価格。画像生成などの処理負荷に応じて最大2ドルまでの課金が可能
- 認証されていない発信者への402 Payment Requiredの返却。オリジンが401を返した際に、自動で402と価格情報に置き換える
ルールはCloudflareのダッシュボードから設定するほか、Cloudflare APIやTerraformを通じてコードとして管理できる。課金エンドポイントの追加が、単なる別のインフラ設定として扱えるようになる設計だ。
Cloudflareはまた、Web Bot Authとの連携も予定している。エージェントに認証を求め、既存のアカウントに対して従量課金を適用する柔軟性を提供する方針だ。これにより、完全な匿名取引だけでなく、信頼関係に基づく課金も選択できるようになる。
売り手にとっての変化
Monetization Gatewayを利用する売り手は、蓄積したステーブルコインをそのまま別の取引に使うことも、銀行口座で法定通貨に換金することもできる。Cloudflareが発表した構想では、支払い検証はすべてエッジで完結し、オリジンには課金ルールと実際の収益だけが残る。
これはAPIプロバイダーにとって、販売可能市場を拡大する直接的な手段になる。AIエージェントはリソースを要求し、価格を提示され、支払い、結果を得る。サインアップもAPIキーも事前の関係も必要ない。Cloudflareは、いつでも買い手の認証や既存アカウントとの紐付けを追加できる柔軟性を残している。
この記事のポイント
- CloudflareがHTTP 402を利用した従量課金プロトコルx402を実用化。Monetization Gatewayによりあらゆるウェブリソースへの課金が可能に
- AIエージェントが大量にコンテンツを消費する時代、広告に依存しない収益モデルとしてマイクロペイメントが鍵を握る
- ステーブルコインによるサブセカンド決済で、サブセント単位の取引でも手数料が収益を上回らない
- 課金ルールはコードで管理でき、売り手は買い手のオンボーディングや請求システムを構築する必要がない
- Web Bot Authとの連携や変動価格設定など、エージェント経済向けの拡張機能が計画されている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
CSS Gap装飾とrandom()関数、select要素のサイズ制御の最新情報
2026年6月末、CSS-Tricksの定期コラム「What’s !important」第14回が更新された。ギャップ装飾、random()関数、select要素のサイズ制御、モダンテーマ構築など、今後のWeb制作に直結するトピックが盛り込まれている。
ブラウザの安定版に大きな機能追加がなかった時期にも関わらず、開発者コミュニティの実験や標準化の進展は目を見張るものがある。本記事では、これらの最新情報を実務の視点で整理し、各機能の具体的な活用法を示す。
ギャップ装飾とランダム関数 ー 隙間を彩るCSSの新表現
CSS Gap装飾でグリッドの隙間をデザインする
FlexboxやGridレイアウトでおなじみのgapプロパティは、要素間に一定の間隔を生み出す。これまではその隙間自体を装飾する手段がなかったが、CSS Gap Decorationの概念によって新たな表現が可能になった。Temani Afif氏がMaster.devで公開した記事では、gap部分に背景色やボーダー、画像を配置する方法が詳しく解説されている。
上記の例では、flexコンテナに背景色を設定することで、gapが作り出すスペースに色が適用されている。Temani Afif氏の記事では、疑似要素やボーダーを用いて、より複雑な装飾を実現する手法が紹介されており、実務での利用価値が高い。
CSS random()がもたらすランダムな表現
CSSのrandom()関数は、スタイルシートに乱数を導入する試験的な機能だ。現時点ではSafariのみが対応しており、他のブラウザでは動作しない。Polypaneのブログでは、この関数を活用した多彩な実験が公開されている。
Polypaneのデモでは、桜の花びらが舞い散るアニメーションやポラロイド写真の不揃いなスタックなどが実装されており、random()の実用性を感じさせる。ブラウザの対応が進めば、よりナチュラルなUI演出に活用されるだろう。
フォーム要素の可変サイズと動的テーマ構築
field-sizing: contentでselectの幅を動的に調整
Manuel Matuzović氏の記事で取り上げられたfield-sizing: contentは、フォームの見た目を柔軟にする新しいCSSプロパティだ。特に<select>要素に適用すると、選択された<option>のテキスト幅に合わせて自動的にサイズが変わる。Firefox 152のリリースにより、この機能はBaselineに加わり、主要ブラウザで使用可能になった。
なお、size属性を併用してスクロール可能なリストボックスにした場合、field-sizing: contentがsizeを上書きし、すべてのオプションを表示するようになる点には注意が必要だ。
モダンCSSテーマ構築の新たなスタンダード
GoogleのUna Kravets氏は、light-dark()関数やcontrast-color()関数、@property、@container style()を組み合わせた新しいテーマ構築手法を解説した。これらの機能はいずれもBaselineに到達しており、モダンブラウザで広く利用できる。
見出しテキスト
本文のテキストがここに入ります。背景は白、テキストは濃い色。
見出しテキスト
本文のテキストがここに入ります。背景は暗色、テキストは明るい色。
contrast-color()を用いれば、背景色に応じて最適な文字色を自動選択でき、アクセシビリティを確保しつつテーマ構築が容易になる。Una氏の記事は、これらの機能を組み合わせた実装パターンとして参考になる。
プラットフォームの多様性を受け入れたウェブデザイン
Bramus氏がブログで提唱した「ウェブサイトはすべてのプラットフォームで同一に動作する必要はない」という考え方は、レスポンシブデザインを超えた新たな視点だ。入力デバイスの違いや、OSごとのAPIの特性を無理に統一せず、それぞれに適した体験を提供することが重要だと説く。
入力モダリティの多様性に対応する
デスクトップではマウスとキーボード、モバイルではタッチが主要な入力手段だが、ユーザーはスタイラスやゲームパッド、音声入力を併用することもある。すべての操作を全デバイスで同一に再現しようとすると、かえって使い勝手が損なわれるケースがある。Bramus氏は、プラットフォーム固有のインタラクションを許容することで、より自然な操作感を実現できると指摘している。
プラットフォーム依存のAPIと設計
同氏は具体例として、interest invokers（興味を示すUI）やoverscroll actions（スクロールオーバー時の挙動）、Document Picture-in-Picture APIなどを挙げた。これらはOSやブラウザによってふるまいが異なるのが自然であり、無理にクロスプラットフォームで統一するよりも、各環境での最適化を優先すべきだという。
この考え方は、Webアプリの設計においても、無理に同一のUIを強制するのではなく、各環境が持つ強みを活かしたコンテキスト適応の重要性を示している。
クリエイティブな実験とコミュニティの熱
CSSの進化は技術仕様だけでなく、開発者コミュニティの創造的な取り組みによっても加速している。今回の!important #14では、いくつかの目を引くプロジェクトとイベントが紹介された。
CSS QuakeとHyperblam ー コードで遊ぶ
Layoutitが公開したCSS Quakeは、1996年の名作FPSゲーム「Quake」をCSSで再現したプロジェクトだ。PolyCSSを活用し、HTMLとCSSだけで3Dグラフィックス風の表現を実現している。この流れは、先日話題になったCSS DOOMに続くもので、CSSの表現力の高さを改めて示している。
また、Heydon Pickering氏が制作したHyperblamは、HTMLのWeb Componentsを用いて音楽を作るというユニークな試みだ。JavaScriptを一切使わず、HTMLタグだけでWeb Audio APIを操作する。CSSとの直接的な関係は薄いが、ウェブ技術の可能性を広げる実験として注目される。
Web Engines Hackfest 2026の熱気
6月にスペインのガリシア地方で開催されたWeb Engines Hackfestでは、ブラウザエンジンやウェブ標準の未来について活発な議論が交わされた。CSS-Tricksの!important #14では、参加者であるMarina Aísa氏のレポートが紹介されており、初日のハイキングから始まり、二日間にわたるトークやクライミング、アクセシビリティ改善に向けたディスカッションの様子が伝えられている。
こうした草の根の開発者会議は、標準仕様の策定やブラウザ実装に直接影響を与える場でもある。Marina Aísa氏のノートは、今後のWeb制作に携わる者にとって貴重な情報源となるだろう。
この記事のポイント
- CSS Gap装飾は、gapプロパティで生じた隙間に背景色やボーダーを適用し、レイアウトに新たなアクセントを加えられる
- random()関数はSafariのみの対応だが、ランダムな表現を実現する強力なツールであり、今後の普及が期待される
- field-sizing: contentにより、select要素の幅を選択肢に応じて動的に変更可能。すでにBaseline入りしており実務利用が進む
- light-dark()やcontrast-color()、@container style()を組み合わせたテーマ構築は、アクセシビリティと効率を両立する
- プラットフォームごとに異なる操作体系やAPIを尊重し、同一性ではなく最適性を追求する設計が重要視されている
- CSS QuakeやHyperblamといった遊び心のあるプロジェクトは、技術の可能性を広げ、コミュニティの活力を象徴している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Amazon FBM配送要件が厳格化、定時配達率90%維持が必須に
Amazon FBM販売者の配送要件が厳格化、定時配達率90%維持が必須に
Amazonが、自社で商品の発送を行うFBM（フルフィルメント・バイ・マーチャント）販売者に対する監視を強化している。ドイツでは定時配達率（OTDR）90%以上の維持が求められ、基準を下回った場合のペナルティも明確化された。イギリスでも同様の厳格化が進む。この動きはフランス、スペイン、イタリアにも波及しており、欧州のAmazonセラーにとって配送品質の向上が待ったなしの課題となっている。
日本国内でAmazon販売を展開する事業者にとっても、この欧州の政策変更は対岸の火事ではない。グローバルで足並みを揃えるAmazonのポリシーは、いずれ日本市場にも適用される可能性が高く、早めの対策が求められる。ここでは変更点の詳細と、販売者が取るべき具体的な対応策を解説する。
配送品質を担保する主体が販売者からAmazonへと移行しつつある状況を示している。FBM販売者は、単に発送するだけでなく、配送プロセス全体のパフォーマンスを数値で証明する責任を負うことになる。
OTDR 90%維持の義務化、その基準とペナルティの詳細
ドイツのAmazonセラー向け公式フォーラムで発表されたポリシー更新によると、FBM販売者は消費者向け注文において、定時配達率を90%以上に保つことが求められる。このOTDR（On-Time Delivery Rate）とは、顧客に約束した配達日までに商品が到着した注文の割合を指す。
消費者向け配送からB2B配送まで、段階的に強化
この要件は2026年9月1日から施行され、基準を満たせない場合、対象となる商品の出品が停止される可能性がある。さらに、FBM商品の新規出品自体ができなくなるリスクも示唆されている。
B2B取引、つまりAmazon Businessの注文についても同様の厳格化が予定されている。9月30日からは、企業向け配送の90%以上が、顧客の営業時間内に時間通り到着することが必須となる。このB2B配送指標が新たに導入され、10月30日からは基準未達の場合、企業向け出品の停止措置が取られる。この変更はイギリスのAmazon.co.ukセラーにもアナウンスされている。
このスケジュールから、Amazonが個人消費者向けと企業向けの両面で配送品質を底上げしようとする意図が明確に読み取れる。特に法人向けは、指定された営業時間内への配達が求められるため、配送業者の選定や在庫管理により一層の正確性が要求される。
イギリス市場でも監視が強化、猶予はここまで
イギリスでは、90%のOTDR要件自体は既に存在していた。しかし、これまでは形骸化していた側面があり、2026年9月からはより厳格に執行されることになる。移行期間は終わり、抜け道は塞がれつつある。
Amazonがドイツとイギリスという欧州最大の2市場で今回のルール変更を同時に進めることは、両市場でより正確な配送約束を表示し、セラーのコンバージョン率を高める狙いがあるというのが、Amazon自身の説明だ。
ハンドリングタイムの自動調整、販売者の甘えは許されない
配送要件の厳格化と並行して、ハンドリングタイムの設定ルールも大きく変わる。ハンドリングタイムとは、注文を受けてから商品を発送するまでの準備期間を指す。昨年も販売者間で議論を呼んだ問題だが、Amazonはここに再度メスを入れた。
デフォルトの2日間設定が1日へ自動短縮
2026年7月15日以降、アカウントのデフォルトのハンドリングタイムが2日間に設定されている場合、自動的に1日に短縮される。これまで多くのセラーが「念のため」と長めに設定していたバッファを、Amazonは認めなくなった。
実績ベースで自動調整される仕組み
さらに踏み込んだ施策として、9月1日からは自動ハンドリングタイム機能が本格的に稼働する。実際の発送実績よりも1日以上長くハンドリングタイムを設定している場合、その設定は30日後に自動的に短縮される。ステータス変更や再設定などの回避策は用をなさない。Amazonの説明を借りるなら「実際のパフォーマンスを反映した、より迅速な配送約束の提示を容易にする」ための仕組みだ。
このルール変更は、良心的なセラーにとっては強力な武器となる。配送品質の低い競合がふるい落とされることで、自社の「迅速な配送」という強みが際立つからだ。逆に、発送業務が属人的で安定しない事業者は、これまで以上に厳しい立場に置かれる。
FBM Ship+ との連動で配送体験はどう変わるか
これらのパフォーマンス要件の厳格化は、Amazonが昨年後半にドイツ、イギリス、フランス、スペイン、イタリアの5カ国で導入したFBM Ship+プログラムと密接に連動している。FBM Ship+は販売者がより迅速な配送オプションを提供するためのプログラムで、高速配送にかかるコストの一部をキャッシュバックする仕組みを備えている。Amazonはこのプログラムを「史上最も速く、かつ手頃な配送」と謳っている。
表面的には「配送の改善」だが、実態はAmazonプライムや企業購買担当者の期待値にFBM販売者を近づけるための構造改革だ。FBA（フルフィルメント・バイ・Amazon）に匹敵する配送スピードと信頼性を、自社発送でも実現せよというプラットフォームからの強い要求と解釈できる。
FBM Ship+のキャッシュバック制度は、こうした厳しい要求に対する飴として機能する。しかし、OTDR 90%維持という厳格な基準をクリアできなければ、そもそもプログラムの恩恵を受ける土台にも乗れない。
販売者が今すぐ取るべき3つの対策
欧州のルール変更を踏まえ、日本のAmazonセラーが準備すべきことを整理する。今のうちに対応を進めておけば、ポリシー変更が日本に上陸した際にスムーズに対応できる。
- 配送キャリアのパフォーマンスを可視化する。OTDR 90%を下回る原因の多くは、配送業者の遅延だ。複数キャリアの配達実績を比較し、信頼性の高いパートナーに絞り込む必要がある。
- ハンドリングタイムの実態を把握し、1日発送を標準化する。現在2日以上に設定している場合、自動調整の対象となる。在庫管理と出荷業務のフローを見直し、遅くとも翌営業日には発送できる体制を整える。
- 自社ECサイトとの二重管理を避ける。Amazonの在庫連動アプリやマルチチャネル管理ツールを活用し、販売機会を逃さず、かつオーバーセリングによる配送遅延を防ぐ仕組みを構築する。
自社ECサイトにおける「配送品質」の捉え方
Amazonだけの話ではない。この厳格化の波は、顧客の配送に対する期待値そのものを引き上げる。Amazonで「翌日配達が当たり前」という体験をした顧客が、あなたの自社ECサイトで買い物をした時、「配送が遅い」と感じれば二度と戻ってこない可能性がある。
WooCommerceなどで自社ECを運営している事業者は、カート落ち対策として配送スピードとコストのバランスを再考すべきだ。具体的には、一定金額以上の購入で送料無料かつ翌日配送を確約する、配送ステータスを自動通知するプラグインを導入するといった施策が有効になる。Amazonの基準は、もはや業界のデファクトスタンダードになりつつある。
この記事のポイント
- FBM販売者の定時配達率（OTDR）が90%以上必須となり、基準未達で出品停止の可能性
- 2026年9月1日から施行、B2B注文へも同様の厳格化が段階的に拡大
- ハンドリングタイムは実績を基に自動調整され、販売者による水増し設定が不可能に
- 配送品質の改善はコンバージョン率向上に直結するが、基準を下回れば販売権を失うリスクも
- 自社ECサイトでもAmazon並の配送体験が求められる時代へ、早急な業務フロー見直しが必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
MetaがInstagram埋め込みのトークン要件を撤回、WordPressで復活
Metaは2026年6月15日、約6年前に導入したoEmbed APIのアクセストークン要件を撤回した。Instagram、Facebook、Threadsの投稿URLをWordPressに貼り付けるだけで埋め込み表示が可能になる。2020年10月にそれまで動いていた機能が突然使えなくなって以降、多くのサイト運営者が埋め込み手段を模索してきたが、ようやく以前の手軽さが戻った格好だ。
今回の方針転換に合わせて、Metaは公式WordPressプラグイン「Meta Embeds」も公開している。トークン管理不要で動作し、コードはGitHubで公開されている。本記事では技術的な変更点と実務への影響、そしてこの変更がカバーしない領域についても整理する。
2026年6月15日の変更内容
今回の発表でトークン不要となったのは、以下の4つのエンドポイントだ。
- Threads oEmbed
- Instagram oEmbed
- Facebook oEmbed（投稿）
- Facebook oEmbed（動画）
従来は、これらのエンドポイントを呼び出すためにMetaの開発者アカウント登録、アプリ作成、App Review申請、そして毎回のアクセストークン付与が必要だった。2026年6月15日以降は、URLさえあれば直接APIを叩ける。レスポンスの形式自体は以前と同じで、埋め込みHTML、プロバイダ名、幅、コンテンツタイプが返ってくる。
ただし2つの注意点がある。1つ目はレート制限だ。トークンレスアクセスはトークン付きのルートよりも呼び出し回数が制限される可能性があり、高頻度で埋め込みを行うサイトでは影響が出るかもしれない。2つ目は、エンドポイントがパブリックな投稿にしか対応しない点だ。非公開アカウントや限定公開の投稿は対象外となる。
この比較図からもわかるように、開発者向けの複雑な手続きが不要になった。個人ブログの運営者でも迷わずにMetaの投稿を埋め込めるようになっている。
元の変更が起きた経緯
2020年10月の衝撃
2020年10月、Metaは同社のoEmbedエンドポイントにアクセストークンを必須とする変更を発表した。WordPressにとってInstagramやFacebookのURLを貼るだけで埋め込みが表示される機能は標準装備だったが、この発表で状況は一変する。WordPressのコアチームは、数千万ものサイト運営者にトークン管理を要求することは現実的ではないと判断し、FacebookとInstagramをoEmbedプロバイダーから削除した。
すでに埋め込まれていた投稿は、WordPressがoEmbedレスポンスをデータベースにキャッシュしていたため表示が維持された。しかし新規の埋め込みは一切動作しなくなった。影響はWordPressサイト全体に及び、埋め込み機能を前提にしていたコンテンツ戦略を大きく狂わせた。
プラグイン市場への波及
この混乱に対応するため、JetpackはAutomattic社が保有するトークン経由でリクエストをプロキシする仕組みを急遽導入した。oEmbed Plusのようなサードパーティ製プラグインも登場し、一般のサイト運営者が自前でFacebook App IDとシークレットキーを生成して設定する手順を案内していた。
しかし多くの運営者はこれらの対策を取らず、埋め込み自体を諦めるか、API接続を内部で処理する専用プラグインに移行した。WP Mayorの記事によれば、この一件だけで「壊れたInstagram埋め込みを修正する」ためのコンテンツやツール群が一つのカテゴリを形成するほどだったという。
6年ぶりの方針転換の背景
Metaが2020年に掲げていた理由はプライバシーとセキュリティの強化だった。しかし今回の発表では「パブリックなMetaコンテンツの埋め込みを容易にする」という簡潔な説明にとどまっている。WP Mayorの著者Mark Zahra氏は、このタイミングでの撤回について「各プラットフォームがユーザーの注意を奪い合い、AIによる回答がリファラルトラフィックを侵食する中で、Metaが自社コンテンツを再びオープンウェブ上で流通させたいという意図が透けて見える」と分析している。
Metaが公式WordPressプラグインを公開
APIの方針転換と同時に、Metaは公式のWordPressプラグイン「Meta Embeds」をリリースした。ソースコードはGitHubで公開されており、オープンソースで開発が進められている。
このプラグインは、Threads、Instagram、Facebookの投稿URLをエディタに貼り付けるだけでリッチな埋め込みを表示する。設定画面はなく、トークンも不要。ブロックエディタとクラシックエディタの両方に対応している。Metaが自社製のWordPressプラグインを公式リポジトリに直接公開するのは異例の動きだ。
プラグインのReadmeに含まれるFAQには、今後の展開をうかがわせる記述がある。このプラグインは、WordPressのバージョンがすでにThreadsのoEmbedプロバイダーを登録しているかどうかをチェックし、重複登録を回避する仕様になっている。WP Mayorの記事は、この実装を「Metaの埋め込み機能がWordPressコアに再統合される布石」と見ており、今後のWordPressリリースでInstagramとFacebookのネイティブ埋め込みが復活する可能性に注目すべきだと指摘している。
Meta Embedsプラグインを有効化するだけで、これまで埋め込みが動作しなかった環境でも即座に表示が改善する。WordPressコアへの統合が実現すれば、プラグインすら不要になる可能性もある。
今回の変更が影響しない領域
oEmbedは単一投稿のAPIである
「トークンレスになったならInstagramフィードプラグインは不要では」という見方が一部で出ているが、それは誤解だ。oEmbedはあくまで1つの公開投稿URLを受け取り、その1投稿の埋め込みコードを返すAPIに過ぎない。
アカウントの最新投稿一覧を取得する機能、ハッシュタグフィード、ストーリーズの表示、自動更新といった機能は、oEmbedでは提供されない。これらは従来通りInstagram Graph APIを使い、アクセストークンによる認証が必要となる。
ブログ記事の中に特定のInstagram投稿を1つだけ埋め込みたいケースでは、今回の無料ルートが再び使えるようになった。逆に、サイトのトップページに最新のInstagram投稿を自動表示したい場合、レイアウトやフィルタリング、モデレーション機能も含めて、Instagramフィード専用プラグインの出番は変わらない。
フロントエンドでのスクリプト読み込みとプライバシー
もう1つ理解しておくべき違いは、oEmbedから返される埋め込みHTMLの動作だ。MetaのoEmbedは、投稿をレンダリングするためにMetaのJavaScriptを訪問者のブラウザに読み込む。Meta EmbedsプラグインのReadmeにも、フロントエンドでのレンダリングはMetaのプライバシーポリシーに準拠すると明記されている。
これは、Metaのスクリプトを一切読み込まずにコンテンツをネイティブ表示するソリューションとは性質が異なる。EU圏のクライアント向けにサイトを構築している場合、GDPRの観点からこの違いは重要だ。埋め込みを有効にする前に、プライバシーポリシーとの整合性を確認しておく必要がある。
実務者への実践ガイド
ドキュメントとナレッジベースの更新
Instagram埋め込みにトークンやMetaアプリが必要だと説明しているコンテンツやドキュメントは、2026年6月15日以降は誤りとなった。WP Mayor自身も自社アーカイブの監査を進めていると述べており、チュートリアル記事や社内マニュアルを保有している場合は速やかな見直しが求められる。
クライアントサイトでの対応
クライアント向けにWordPressサイトを構築している場合、単発のMeta投稿埋め込みは開発者向けのセットアップなしで利用可能になった。Meta Embedsプラグインを導入すればすぐに動作する。WordPressコアへの統合が進めば、近い将来プラグインすら不要になる可能性も視野に入れておきたい。
Instagramフィードプラグインの利用者
既存のInstagramフィードプラグインを使用しているサイトには、今回の変更は一切影響しない。フィード機能はInstagram Graph APIに依存しており、oEmbedのトークン要件撤廃とは無関係だ。不安があればプラグインの開発元に確認するのが確実だが、WP Mayorの記事ではRebelCode社が開発するSpotlight Instagram Feeds（6万以上のアクティブインストールを誇る高評価プラグイン）を含め、APIベースのフィードソリューションはすべて影響を受けないと明言されている。
この記事のポイント
- Metaが2026年6月15日、oEmbed APIのトークン必須化を撤回。Instagram、Facebook、Threadsの埋め込みがURL貼り付けだけで動作する
- 併せて公式WordPressプラグイン「Meta Embeds」をリリース。コードはGitHubで公開され、WordPressコアへの統合も視野に入っている
- oEmbedは単一投稿APIであるため、アカウントの最新フィード表示やストーリーズ機能は従来通りAPIトークンが必要。Instagramフィードプラグインの役割は変わらない
- 埋め込み表示にはMetaのJavaScriptが読み込まれるため、GDPR対応が必要なサイトではプライバシーポリシーとの整合性確認が欠かせない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AWS Graviton5搭載EC2 C9gインスタンスが一般提供開始
計算負荷の高いワークロードを扱う企業にとって、「もう少しだけ処理が速ければ」という場面は多い。AWSが6月30日に発表したEC2 C9g/C9gdインスタンスは、その不満を根本から解決する新世代の計算特化型インスタンスだ。Graviton5プロセッサの投入により、前世代からvCPUあたり最大25%の性能向上を実現した。今回の発表で特に注目すべきは、クラウド最速級となるDDR5-8800MT/sメモリの採用と、正式検証済みのハイパーバイザー分離エンジン「Nitro Isolation Engine」の搭載だ。本記事では、CPU負荷の高いバッチ処理や動画エンコーディングを中心に、新しいインスタンスがどのような場面で威力を発揮するのかを詳しく解説する。
C9g/C9gdインスタンスの位置づけを見極める
AWSのEC2には多様なインスタンスファミリーが存在する。頭文字の「C」はCompute Optimized（計算最適化）を意味し、他のメモリ最適化（Rシリーズ）やストレージ最適化（Iシリーズ）とは設計思想が異なる。計算最適化インスタンスは、vCPUあたりの演算性能を最大化することに特化している。リアルタイム分析、機械学習の推論、動画エンコーディングなど、1秒でも短く計算を終えたい処理に適している。
今回発表されたC9g/C9gdは、2024年秋に登場したGraviton4搭載C8gの後継にあたる。AWS GravitonシリーズはArmベースの独自プロセッサで、x86系のIntel XeonやAMD EPYCと比較して、コストパフォーマンスに優れる点が強みだ。C9gの「g」はGravitonを示し、末尾に「d」がつくC9gdはNVMe SSDによる高速なローカルストレージを内蔵する。
Graviton5プロセッサの進化点を知る
Graviton5の最大の改良点は、メモリ帯域幅の拡張とレイテンシの低減にある。C9gインスタンスはDDR5-8800MT/sのDIMMを採用し、これは現在クラウド上で提供されているプロセッサインスタンスの中で最速のメモリ速度だ。数字だけでは実感しにくいが、これはメモリとCPU間のデータ転送速度が秒間8800メガトランスファー（MT/s）ということを意味する。前世代のC8gがDDR5-5600MT/sだったため、実に57%もの速度向上にあたる。
さらに、CPUのL3キャッシュ容量が5倍に拡張された。キャッシュはCPUとメインメモリの間に位置する超高速なデータ置き場で、容量が大きいほどメモリアクセスの待ち時間を減らせる。AWS News Blogの著者Seb氏によると、これらの改善により、インメモリ分析のスループット向上や、より応答性の高いエージェント型AIループが期待できるという。
ネットワーク面でも強化が施されている。パケット処理性能はGraviton4ベースのインスタンスと比較して最大3倍に向上し、インスタンスサイズ全体の平均でネットワーク帯域が約15%、EBS帯域が約20%増加した。
C9g/C9gdの主要スペック詳細と設計思想
スペック表を見ると、C9g/C9gdは最小のmedium（1vCPU/2GBメモリ）から、最大のmetal-48xl（192vCPU/384GBメモリ）まで11サイズで展開される。48xlargeではネットワーク帯域が100Gbps、EBS帯域が72Gbpsに達し、これは前世代の2倍にあたる。大規模な分散処理やリアルタイム分析基盤において、ネットワークがボトルネックになる状況を回避しやすくなるだろう。
C9gdシリーズには、ローカルのNVMe SSDストレージが追加される。容量は最小のmediumで59GB、最大の48xlargeでは3台合計で11,400GB（3×3,800GB）に達する。NVMe SSDはEBSよりもレイテンシが低いため、以下のような用途に適している。
- HPCシミュレーションのスクラッチスペース（一時的な作業領域）
- 機械学習推論の一時キャッシュ
- アドサーバーのローカルバッファ
ストレージ性能も向上しており、ローカルストレージのパフォーマンスは前世代比で約30%向上した。NVMe経由の詳細なI/Oパフォーマンス統計はCloudWatchやnvme-cli経由で取得可能で、I/Oサイズ別のレイテンシヒストグラムが1秒単位で確認できる。この機能は追加料金なしで利用できる。
Instance Bandwidth Configurationの実用性を測る
C9g/C9gdには、Instance Bandwidth Configuration（IBC）と呼ばれる帯域調整機能が搭載されている。これは、EBSとVPCネットワークの帯域配分を最大25%の範囲で調整できる仕組みだ。例えば、データベースやキャッシュ用途でEBSの帯域を優先したい場合、ネットワーク側を絞ってEBS側に割り当てを寄せることが可能になる。逆に、ネットワーク集約型の分散処理ではVPC側を優先すればよい。固定的な割り当てに縛られない柔軟性は、実運用のチューニングで大きな武器になる。
C9gとC9gdの使い分けフローを整理する
C9gとC9gdはスペックが似ているため、どちらを選ぶべきか迷う場面があるだろう。選択の決め手は「ローカルのNVMe SSDが必要かどうか」に尽きる。AWS News Blogでは、C9gを「バッチジョブ、動画エンコードパイプライン、分散分析」向け、C9gdを「HPCシミュレーションのスクラッチスペース、ML推論の一時キャッシュ、アドサーバーのローカルバッファ」向けとしている。EBSで十分な永続ストレージが足りるならC9g、一時的でも高速なローカルストレージが不可欠ならC9gdを選べばよい。
Graviton5がもたらすエージェント型AIへの適性を読み解く
AWS News Blogの発表では、C9gのワークロード例として「エージェント型AI（agentic AI）」が明記されている。エージェント型AIとは、単なる質問応答を超えて、コードを実行し、複数ステップのタスクを自律的に組み立てて完了させるAIシステムを指す。OpenAIのOperatorやAnthropicのComputer Useが代表例だ。
この種のワークロードでは、大規模言語モデル（LLM）の推論そのものに加えて、Pythonコードの実行、API呼び出し、結果の検証といったCPUバウンドな処理が連続的に発生する。Graviton5のコア数向上と大容量キャッシュは、こうした「思考と行動のループ」を高速化する土台となる。AWSの著者Seb氏によれば、アプリケーションがデータを待つ時間を削減し、結果的にエージェントループの応答性が高まるとのことだ。
AI推論といえばGPUの印象が強いが、実際には前処理、後処理、オーケストレーションの多くがCPU上で動く。ArmベースのGraviton5は、これらの処理を低コストでさばける点が実務的な魅力となる。
Nitro Isolation Engineのセキュリティ強化を理解する
C9g/C9gdは、計算最適化インスタンスとして初めて「Nitro Isolation Engine」を搭載した。これはAWS Nitro Systemの拡張機能で、仮想マシン間のメモリ空間、CPUレジスタ状態、I/Oデバイスへのアクセスを数学的正確さで強制的に分離する仕組みだ。
通常、ハイパーバイザーによる分離はソフトウェアの実装品質に依存する部分があるが、Nitro Isolation Engineは形式検証（formal verification）と呼ばれる数学的手法を用いて分離の正しさを証明している。形式検証とは、仕様を数理論理で記述し、実装がその仕様を厳密に満たすことを機械的に検証する手法だ。テストのように「見つかったバグがない」ではなく、「特定の前提条件下でバグが存在し得ない」ことを保証する。
AWSは2025年にこの技術を発表した際、ハイパーバイザーの分離を形式検証する取り組みについてホワイトペーパーを公開している。今回のC9g/C9gdで初めて、計算最適化インスタンスに実装されたことになる。
セキュリティ要件の厳しい金融サービスや医療データの分析をEC2上で行うケースでは、この正式検証済みの分離機構はインフラ選定の重要な判断材料になる。ソフトウェアレベルではなく、ハードウェア支援と形式検証の組み合わせで隔離を実現している点は、AWSの設計思想として特筆に値する。
利用可能リージョンと料金モデルを確認する
2026年6月30日時点で、C9g/C9gdは米国東部（オハイオ、バージニア北部）、米国西部（オレゴン）、欧州（フランクフルト）の4リージョンで利用可能だ。AWSは追加リージョンへの展開も予定している。
料金モデルはSavings Plans、オンデマンド、スポットインスタンス、Dedicated Instances、Dedicated Hostsに対応する。常時稼働させるワークロードではSavings Plans、短期的なバッチ処理ではスポットインスタンスと使い分けられる。EBSボリュームは仮想インスタンス1台あたり最大128個までアタッチ可能で、大規模データの処理でもストレージ不足に悩むことは少ない。
インスタンスの起動はAWSマネジメントコンソール、AWS CLI、AWS SDKのいずれからでも可能だ。GravitonはArmアーキテクチャのため、AMIやコンテナイメージはArm向けにビルドされたものを選ぶ必要がある。公式のAmazon Linux 2023やUbuntuのArm版AMIはすでに提供されているため、新規導入時の障壁は低い。
この記事のポイント
- C9g/C9gdはGraviton5搭載の計算最適化インスタンス、vCPUあたり25%の性能向上を達成
- DDR5-8800MT/sメモリと5倍のL3キャッシュにより、メモリ待ち時間を大幅に削減
- 48xlargeでは100Gbpsネットワーク帯域と72GbpsのEBS帯域、前世代比2倍に拡張
- Nitro Isolation Engine搭載、形式検証による仮想マシン分離を実現
- エージェント型AIやHPC、動画エンコードなどCPU負荷の高い処理に最適
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Prisma Compute vs Vercel、料金比較でわかるコスト差の全容
TypeScriptアプリのホスティング先を選ぶとき、Prisma ComputeとVercelが候補に挙がる。両者とも従量課金でゼロスケールするため、アイドル時のコストはかからない。だが料金単価と課金項目の設計思想が異なり、同じ負荷でも請求額に2倍以上の開きが出るケースがある。Prisma Computeはパブリックベータ中で現在無料、ここで示す料金は将来の本番適用が予定されている参考値だ。
本記事ではPrisma Blogが2026年7月1日に公開した料金比較をもとに、各メーターの単価差、20Mリクエストの実ワークロード試算、そしてなぜ同じ負荷で請求が変わるのかを掘り下げる。Vercelの価格にまつわる開発者の声も紹介し、自社のアプリに当てはめるときの判断材料を提供する。
料金体系の基本比較
両サービスともリクエスト数、メモリ消費、CPU時間、外向き帯域を課金対象とするが、単価には明確な差がある。Prisma Computeの価格はベータ版後の予定値であり、変更の可能性がある点に注意が必要だ。
リクエスト単価ではVercelが優位だが、サーバーワークの大半を占めるメモリとCPU、そして帯域ではPrisma Computeが大幅に低い単価を提示している。さらに開発者シートやエッジリクエストといったワークフローコストがPrismaには存在しない点が、後々の請求に大きく響く。
実ワークロードでのコスト試算
月間2000万リクエスト、常時2GBメモリ使用、実CPU 300vCPU時間、外向きトラフィック2TB、開発者1名という条件で両者を比較する。Vercel Proには1TBの帯域無料枠が含まれる点を織り込んだ試算だ。
メモリ (1460 GB時) $8.76
CPU (300時間) $19.20
外向き帯域 (2TB) $50.00
シート (1名) $0.00
合計 ~$98
メモリ (1460 GB時) $15.48
CPU (300時間) $38.40
外向き帯域 (2TB中1TB無料扱い) $150.00
シート (1名) $20.00
合計 ~$236
この試算ではエッジリクエストを除外し、開発者1名で固定している。実際にはチーム人数が増えるほどVercelのシート料金が積み上がり、格差はさらに拡大する。一方で外向き帯域がごく小さく、リクエスト単価の差が支配的になるシナリオでは両者の総額は接近する。
料金差を生む構造的要因
なぜ同じ負荷でこれほどの差がつくのか。理由は課金モデルの設計思想とアーキテクチャの2軸に集約される。
ワークとワークフローの分離
ホスティング料金は「アプリが稼働中に行う実作業（ワーク）」と「デプロイやプレビューなど開発プロセス（ワークフロー）」に分けられる。Prisma Computeはリクエスト、メモリ、CPU、帯域というワークのみに課金し、開発者シートやエッジリクエストといったワークフロー項目は一切請求しない。Vercelはワークに加え、シート料金とエッジリクエストをワークフローとして課金する。
Prisma Compute 課金
Vercel 課金
Prisma Compute 無料
Vercel 課金
Prisma Blogの著者Martin Janse van Rensburg氏は、AIエージェントがコードの変更→テスト→プレビューを繰り返す開発スタイルでは、Vercelのワークフロー課金が急速に膨らむリスクを指摘している。一方PrismaではデプロイのたびにイミュータブルなバージョンとプレビューURLが作られるが、それらに追加料金は発生しない。
データベース隣接配置によるエグレス抑制
Prisma Computeのアーキテクチャ上の特徴として、Prisma Postgresと同じインフラ上で動作する点が挙げられる。通常、アプリケーションサーバーとデータベースが別ベンダーや別リージョンにある場合、両者間の通信が外向き帯域として課金対象になる。Prisma Computeはデータベースとの通信が同一基盤内で完結するため、こうした隠れエグレスコストが発生しない。
アプリ-DB間通信が外向き帯域として課金
同一基盤内で通信が完結。エグレスコストなし
データベースとの通信量が多いアプリほど、この差は請求額に明確に現れる。大量のクエリを発行するAPIサーバーなどでは、Vercel＋外部DB構成のエグレス費用が無視できなくなる。
開発者の声と注意点
VercelのFluid Computeは適合するワークロードでは大幅な削減効果を発揮する。リンク短縮サービスdub.coの創業者Steven Tey氏は、Xで「Vercelの利用タブが壊れたのかと思った」と述べ、Fluid有効化後に請求が50%減少したと報告している。
しかし、一部の開発者からは予想外の料金跳ね上がりに関する声も上がっている。Redditのr/nextjsスレッドでは、あるCTOがフロントエンドのみのNext.jsアプリの月額請求が「100ドル未満から800ドル超」に急増し、Cloudflare Workersへ移行後は「同じトラフィックで20ドル未満」になったと述べた。同スレッドでは「Vercelのフロントエンドは素晴らしく安いが、バックエンドは高すぎる」という見方や、Deployment Protection Exceptionsで150ドル請求された事例も共有されている。
Fluid Computeを有効化 → 請求が50%減少
フロントエンドのみのNext.jsアプリ → 月$100未満→$800超に急増
Cloudflare Workers移行後 → 同トラフィックで$20未満
Prisma Computeはパブリックベータの段階であり、実際の課金が始まっていないため、利用者からの本格的なフィードバックはまだない。Prisma Blogの著者は、フィードバックが集まり次第、この比較記事を更新する意向を示している。
この記事のポイント
- Vercelはリクエスト単価で優位だが、メモリ、CPU、帯域ではPrisma Computeが大幅に安い予定価格を提示している
- 月間2000万リクエストの試算ではPrisma Computeが約98ドル、Vercel Proが約236ドルと2.4倍の開きがあった
- 請求差の主因はワークフロー課金（シート料金、エッジリクエスト）とデータベース隣接によるエグレス抑制
- VercelのFluid Computeは適切なワークロードで削減効果を発揮する一方、トラフィックに比例しない請求急増の事例も報告されている
- Prisma Computeはまだベータ版であり、本番利用のフィードバックを踏まえた判断が今後必要になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
大文字見出しがコンバージョンを下げる、CROプロが警告
ランディングページの見出しをすべて大文字にすることは、視覚的なインパクトを与える常套手段と思われている。しかし、CRO（コンバージョン率最適化）の専門家Nate Lagos氏は、それが逆効果になる可能性を指摘する。実際のA/Bテストでは、大文字をやめて各単語の先頭だけ大文字にしたところ、コンバージョン率が25%も向上した事例が報告されている。
これは、多くのECサイト担当者が見過ごしがちな落とし穴だ。本記事では、Practical EcommerceのポッドキャストでLagos氏が語ったテスト結果と、ボトムズアップアプローチに基づくCRO戦略の核心を解説する。
大文字見出しがコンバージョンを下げる意外な事実
Lagos氏が実践するCROは「ボトムズアップテスト」と呼ばれる。購入ボタンや商品説明文といった、コンバージョンに直結する部分からコピーを検証していく手法だ。トップページや認知向けの広告文よりも、まず「買うか離脱するか」の瀬戸際にある箇所を最適化する。
このアプローチの過程で浮かび上がったのが、大文字見出しの問題だ。Lagos氏はX（旧Twitter）で読んだアイデアをきっかけに、あるクライアントのランディングページでテストを実施した。それまですべて大文字だった見出しを、各単語の先頭だけ大文字にするパターンに変更したところ、驚くべき結果が出た。
25%のコンバージョン向上を実現したA/Bテスト
テスト結果は明確だった。大文字をやめたランディングページでは、コンバージョン率が25%向上した。しかも、CPA（顧客獲得単価）も低下した。トラフィックの多いページだったため、この変化はビジネスにとって大きなインパクトをもたらした。
Lagos氏によれば、これは「可読性」の問題だ。大文字だけのテキストは、単語の形状が均一になり、脳が素早く認識しにくくなる。結果として、ユーザーは読む前に離脱してしまう。見出しのフォントサイズを小さくした場合にも同様の傾向が見られ、読みやすさが購買行動に直結することが浮き彫りになった。
ボタンテキストへの応用は未検証
ただし、Lagos氏はボタンに大文字を使うことの影響まではテストしていない。CTAボタンでは大文字が効果的なケースもあるかもしれない。今回の発見は、あくまで見出しや本文レベルのテキストブロックに限定したものだ。サイトのコピーを最適化する際は、見出しから着手するのが良いだろう。
ボトムズアップアプローチの実践
Lagos氏が提唱するボトムズアップテストは、従来の広告戦略の考え方をひっくり返す。多くのマーケターは、まず認知獲得のためのトップファネルから手を付ける。しかし、購入から遠い場所にあるメッセージは、実際の購買動機とは無関係なケースが多い。だからこそ、まずは購入ボタンの近くから最適化するのだ。
購入ボタン直近のコピーを最適化する
具体的には、商品詳細ページの見出し、説明文、価格表示、そしてCTAボタンの周辺テキストをテストする。Lagos氏はOriginal Grain在籍時代、この手法で5年間にわたり収益をほぼ5倍に伸ばした実績を持つ。腕時計という「実用性が低い」商材でこれだけの成果を出せたのは、買い手の感情に響くコピーを突き詰めたからだ。
このプロセスを経ることで、「顧客が本当に求めているもの」が明確になる。腕時計の例では、時刻を知るためではなく「地位や達成感の象徴」としての価値が見えてきた。こうした深層心理を突いたコピーが、結果的にコンバージョン率や平均注文単価を押し上げた。
市場飽和を打破するターゲット拡大戦略
コアオーディエンスへのリーチが頭打ちになったブランドが次に取るべき打ち手は、商品を軸にしたターゲットの拡大だ。Lagos氏は「常に『他に誰に売れるか』を問い続けろ」と語る。
男性向け商品を女性に売る方法
Original Grainでの実例が示唆に富む。当初、同ブランドは男性向けにメッセージを打っていた。しかし、顧客データを分析したところ、実は約半数の購入者が女性だった。そこでLagos氏は女性向けのコピーライティングに注力し、最終的に顧客の80%を女性が占めるまでに至った。
成功の鍵は「ギフト需要」の掘り起こしだった。Practical EcommerceのインタビューでLagos氏が明かしたところによると、女性顧客は「夫やボーイフレンドへの感謝を示したい」という動機で腕時計を購入していた。特に父の日やクリスマス前の30〜45日間は、ギフト向けのメッセージに全面切り替え、年間を通じてはメインサイトを男性向けに戻すという柔軟な運用を行った。
女性向けマーケティングを成功させる鉄則
Lagos氏が強調するのは「女性の顧客を理解するには女性を雇え」というシンプルな原則だ。彼自身、コピーライターのSarah Levinger氏を迎え入れ、女性視点のメッセージ構築を一から学んだ。自社にない視点を取り入れることは、新しい市場を開拓するための最短ルートになり得る。
この事例は、商品そのものを変えずに、メッセージの受け手を変えるだけで大きな成長が可能なことを示している。自社のデータを見直し、思いがけない顧客層がいないかを探る価値は大きい。
CROテストを成功に導くツールと手法
Lagos氏がA/Bテストの実施に用いているのは、Intelligemsというツールだ。テストの信頼性を担保するため、統計的有意性は「対照群に勝つ確率が80%以上」を基準にしている。サイト訪問者数が数万から数十万、注文数が数千件に達するボリュームでなければ、意味のある結果は得られない。
ヒートマップで読者の行動を可視化
テストすべき箇所を特定するには、ヒートマップツールが有効だ。ユーザーが実際にどこを読んでいるのか、どこで離脱しているのかを可視化することで、コピー改善のインパクトが大きいエリアを見極められる。Lagos氏の経験では、ランディングページや商品ページの冒頭ブロックが最もレバレッジの効く領域だという。
A/Bテストは一度きりではなく、継続的な反復が前提となる。小さな改善を積み重ねることで、CVRやAOV（平均注文単価）、RPV（訪問単価）といった重要指標を持続的に押し上げていく。大文字見出しの回避は、その第一歩として取り組みやすい改善策と言えるだろう。
この記事のポイント
- ランディングページの大文字見出しをやめ、各単語の先頭だけ大文字にすることでCVRが25%向上した事例がある
- ボトムズアップテストでは、購入ボタン近くのコピーから最適化し、購買動機を明確にする
- A/BテストはIntelligems等のツールを用い、統計的有意性を確保できる十分なボリュームで実施する
- ターゲット拡大では、女性へのギフト訴求が男性向けブランドの顧客基盤を劇的に変える可能性がある
- 改善は継続的な反復が鍵。大文字見出しの見直しは、今日から始められる施策の一つだ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google、悪質な住宅用プロキシネットワークNetNutを継続的に破壊
NetNutとは何か、住宅用プロキシの仕組み
今回Googleが措置を取ったNetNut（別名Popa）は、世界最大級の住宅用プロキシネットワークだ。住宅用プロキシとは、一般家庭が契約するISP（インターネットサービスプロバイダ）のIPアドレスを経由してトラフィックを中継する仕組みである。大規模なボットネットによって実現され、NetNutは少なくとも200万台のデバイスを出口ノードとして抱えていたと見られている。
住宅用プロキシの大きな特徴は、一見すると正当な住宅回線からの通信に見える点だ。攻撃者はこの特性を悪用し、実際の位置や身元を隠蔽する。データセンター経由のプロキシとは異なり、ブラックリストに載りにくいため、アカウント不正アクセスやパスワードスプレー攻撃などに利用される。
■ 家庭のデバイスが踏み台にされる
Google Threat Intelligence Group（GTIG）の推計によると、NetNutには世界で200万台以上のデバイスが接続されていた。このボットネットは主にスマートテレビやストリーミングボックスなど、家庭に常時設置されるデバイスに潜むSDKを通じて構築される。KrebsOnSecurityの報道やGoogle自身の調査により、NetNutがこうしたデバイスを悪用してプロキシネットワークを肥大化させていた実態が明らかになっている。
Googleが取った具体的な対策とその効果
Googleは2026年7月2日、FBIやLumenなどのパートナーと連携し、NetNutの運営基盤に対して以下の施策を実施した。
Googleアカウントとサービスの無効化
NetNutがマルウェアのC2（コマンド＆コントロール）に使用していたGoogleアカウントと関連サービスを、利用規約違反として無効化した。これにより、攻撃者がボットネットを制御する主要な通信路が遮断された。
技術情報の共有とエコシステム全体への働きかけ
NetNutが利用していたSDKやバックエンドのC2インフラに関する技術情報を、プラットフォーム事業者や法執行機関、研究機関と共有した。この情報に基づき、各組織が同様のネットワークを監視・遮断できるようになり、より広範な防御が可能になった。
Google Play Protectによる自動防御
Androidの組み込みセキュリティ機能であるGoogle Play Protectが、NetNutのSDKを組み込んだアプリを検出し、ユーザーに警告を発するとともに自動で無効化する措置を取った。今後も新たなインストール試行に対して保護を継続する。これによって、一般ユーザーが意図せずボットネットの一部になるリスクが大幅に低減された。
これらの連携措置により、NetNutのプロキシネットワークから数百万台のデバイスが切り離され、可用性が著しく低下した。NetNutにはホワイトラベル（再販）プログラムも存在し、多くの有名住宅用プロキシブランドが実態としてNetNutのボットネットを利用していたことが分かっている。そのため、今回の措置はプロキシ業界全体に波及効果をもたらすと見られている。
ただしGTIGは、過去のIPIDEAネットワークの事例から、個別のネットワークが一見復元力を持つように見えることもあると指摘している。プロキシ事業者は自前のボットネットが弱体化すると競合からキャパシティを購入し、事実上の再販業者に転じる傾向がある。持続的な抑止には、複数の相互接続されたネットワークを同時に標的とするスケールした取り組みが不可欠だ。
なぜ住宅用プロキシがここまで危険なのか
NetNutのような住宅用プロキシは、攻撃者にとって理想的な隠れ蓑になる。2026年6月の1週間だけでも、GTIGはNetNutの出口ノードを疑われるIPから316もの異なる脅威クラスタを観測した。これにはサイバー犯罪グループだけでなく、国家支援が疑われるスパイ活動グループも含まれていた。
デバイス所有者への直接的な被害
感染したデバイスが出口ノードになると、その家庭のIPアドレスから不正な通信が行われる。最悪の場合、同じホームネットワーク内の他のプライベートデバイスにもアクセスされ、外部の脅威に晒される。ユーザーが気付かないうちに自宅の回線が犯罪に利用され、プロバイダからフラグを立てられ通信を制限されるなどの二次被害も発生する。
大規模DDoS攻撃の踏み台としての利用
SynthientやSpur、Nokia Deepfieldなどの公開レポートによれば、NetNutのインフラはMirai亜種などのDDoSボットネットにデバイスを感染させる経路としても使われていた。住宅用プロキシは単なる匿名化ツールにとどまらず、より破壊的なサイバー攻撃の温床になっている。
正規の住宅IPに見えるため、ログイン試行のブロックを回避
出口ノード化したデバイス経由で同一LAN内の機器にアクセス
多数の住宅デバイスから一斉にトラフィックを送り標的を圧迫
ISPに不正通信として検知され、正規の通信がブロックされる可能性
こうしたリスクは、一般消費者のデバイスが知らぬ間に犯罪インフラの一部と化す構造的な問題だ。「無料VPN」や「帯域を共有するだけで報酬」といった甘い言葉でインストールを促すアプリが、実は住宅用プロキシのSDKを仕込んでいるケースが後を絶たない。
一般消費者が今すぐ取るべき3つの対策
NetNutのような脅威から自分や家族のデバイスを守るために、以下の点に注意したい。
「未使用の帯域を共有する」アプリを警戒する
「帯域を貸すだけで収入が得られる」とうたうアプリは、悪質なプロキシネットワークへの参加を促す典型的な手口だ。こうしたソフトウェアは、意図せず自宅のIPを犯罪者に貸し出す結果になる。Googleは公式アプリストアの利用と、サードパーティVPNやプロキシの権限を厳格に確認するよう呼びかけている。
Google Play Protectを有効に保つ
Androidスマートフォンやテレビデバイスでは、Play Protectが自動的にNetNut関連の不正アプリを検出・無効化する。設定から保護機能が有効になっているか確認することが第一歩だ。Play Protect認証を受けていないデバイスは、セットトップボックスなどでも注意が必要だ。
信頼できるメーカーのデバイスを選ぶ
特にスマートテレビやストリーミング端末を購入する際は、公式のAndroid TV OSを搭載し、Play Protect認証を受けているかどうかを確認すべきだ。Android TVの公式サイトではパートナーメーカーの最新リストが公開されており、購入前のチェックに役立つ。
今後の展望と持続的な対策の必要性
今回のNetNut無効化は、2026年1月のIPIDEAネットワーク対策に続くGoogleの断固たる意思表示だ。しかし住宅用プロキシ業界は急速に拡大しており、単発の措置だけでは長期的な解決にならない。事業者同士がボットネットを再販し合う流動的なエコシステムでは、1つのネットワークを潰しても別のネットワークがカバーする。
GTIGも認めるように、持続的な抑止には複数の主要プロバイダのインフラを同時に標的とし、モバイルプラットフォーム、ISP、テクノロジー企業が継続的に情報を共有し、悪意あるC2サーバーをブロックする取り組みが必要だ。Googleは「業界全体の協調努力なくして根本的な解決は難しい」との立場を明確にしている。
我々一般消費者も、知らぬ間にサイバー攻撃の一端を担わされないよう、デバイスの購入元とアプリの権限に対して常に敏感でありたい。技術的な防御だけでなく、ユーザーリテラシーの向上が、悪質な住宅用プロキシの成長を鈍化させる最後の砦になる。
■ 技術的対策の要（プラットフォーム）
■ 法執行・インフラレベルでの遮断
Googleはこの発表の中で、同様の取り組みを加速させる意向を示しており、今後の脅威インテリジェンス共有の枠組みがさらに重要になるだろう。
この記事のポイント
- GoogleがNetNut（Popa）と呼ばれる世界最大級の住宅用プロキシネットワークをFBIなどと協力して無効化
- アカウント無効、SDK情報共有、Play Protectによる自動防御で数百万台のデバイスをネットワークから切り離し
- 住宅用プロキシは一般家庭のデバイスを踏み台にし、アカウント乗っ取りやDDoS攻撃の温床に
- 消費者は「未使用帯域の共有」アプリを避け、Play Protectの有効化や信頼できるデバイス選びが重要
- 業界全体での継続的な情報共有と協調した遮断が、長期的な対策には不可欠
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Amazon EKSにKubernetesロールバック機能、アップグレードの不安を解消
Amazon EKSにKubernetesバージョンロールバック機能が導入された。クラスタのバージョンアップグレードはこれまで戻り道のない一方通行だったが、今回の機能により最大7日間であれば以前のバージョンに巻き戻せる。AWSのDonnie Prakoso氏とChanny Yun氏が2026年7月1日付のAWS News Blogで発表した内容だ。
KubernetesコミュニティではKEP-4330に基づくエミュレートバージョンでロールバックを緩和する動きが進んでいる。しかしEKSのロールバックはエミュレーションではなく、本番環境で事前に検証済みの状態へ完全に戻る点が異なる。クラスタ管理者にとってはアップグレード作業の心理的ハードルを大幅に下げる機能だ。
本記事では、この新機能の仕組みや利用手順、EKS Auto Modeでの挙動の違いを中心に、運用現場へのインパクトを具体的に整理する。
Kubernetesバージョンロールバックの概要
この図はアップグレード失敗時の対応の違いを示している。従来はクラスタ再構築が必要だったが、新機能では「元に戻す」操作が可能になった。
ロールバックが求められてきた背景
Kubernetesは年に3回のマイナーバージョンアップがリリースされる。多数のクラスタを抱える組織、とりわけ金融や医療など規制の厳しい業界では、アップグレードに数か月単位の準備期間を設ける例も珍しくない。問題発生時に復旧できる確証がなければ、アップグレードそのものを先送りする判断になりやすい。
この結果、クラスタは古いバージョンに留まり、セキュリティパッチが未適用のまま延長サポート期間に突入するケースが増えていた。ロールバック機能はこうした「アップグレード恐怖症」を解消する安全装置として位置づけられる。
エミュレートバージョンとの違い
KEP-4330で提案されているエミュレートバージョンは、クラスタを移行用の中間状態に置くアプローチだ。対してEKSのロールバックは、実際に本番で稼働していた検証済みの状態へ戻る。エミュレーションではないため、ロールバック後の動作は以前のバージョンそのものになる。運用チームにとっては「テスト環境で確認済みの状態」に復帰できる点が安心材料だ。
基本的な制約と料金
ロールバック可能な期間はアップグレード後7日間である。バージョンは1つ前のマイナーバージョンのみ戻せる。たとえば1.34から1.35にアップグレードした場合、戻り先は1.34だ。1.33へ一気に下げることはできない。
料金はロールバック機能そのものに追加コストは発生しない。標準のEKS料金とコンピューティングコストのみで利用できる。全商用AWSリージョンで本日から提供開始されている。
ロールバックの実践的な利用手順
AWSのブログでは、Donnie Prakoso氏が実際にEKSコンソールからロールバックを試した手順が紹介されている。ここではその流れを整理しつつ、運用現場で意識すべきポイントを補足する。
この手順は標準的なアップグレード操作と大きく変わらない。所要時間は制御プレーンのロールバックが約20分で、通常のアップグレードと同程度だ。
ロールバックインサイトによる事前評価
EKSはロールバック実行前に、クラスタインサイト機能を使ってロールバックの準備状況を自動評価する。ノードのバージョン互換性やアドオン依存関係に問題があれば事前にフラグが立つ仕組みだ。事前評価をスキップして強制的にロールバックを進めたい場合は、--forceフラグが用意されている。
トラブルシューティング中の緊急時にはこの強制実行が有効だが、通常はインサイトの結果を確認してから進めるのが安全だ。互換性の警告を見落とすと、ロールバック後に別の問題が顕在化するリスクがある。
制御プレーンとノードのロールバック
制御プレーンのロールバックはすべてのEKSクラスタで利用できる。一方、ノードのロールバックはEKS Auto Modeを利用しているクラスタが対象となる。自分でノードを管理している構成では、制御プレーンだけがロールバックされ、ノード側は別途対応が必要になる点に注意したい。
EKS Auto ModeでのロールバックとキャンセルAPI
EKS Auto Modeはコンピューティング、ネットワーク、ストレージ管理を自動化するフルマネージドオプションだ。このモードでは制御プレーンと管理ノードの両方をロールバックする必要があり、ノードのロールバックはPod Disruption Budget（PDB）を尊重しながら進むため、設定によっては時間がかかる。
Auto Modeでは制御プレーンとノードが連動してロールバックされる。キャンセルAPIを使えば、所要時間が長すぎる場合に中断して戦略を練り直せる。
PDBを尊重する設計の意図
EKSはロールバック中にデフォルトでPDBをバイパスしない。ワークロードの安定性を最優先する設計思想だ。ノードの切り戻し中にPodが過剰に停止すると、アプリケーションの可用性が損なわれるからである。
ロールバックを急ぎたい場合は、運用者が自らPDBを修正または削除することで高速化できる。システムが一方的にPDBを無視しないため、安全性とスピードのバランスを利用者側でコントロールできる仕組みになっている。
キャンセルAPIの実用シナリオ
キャンセルAPIはノードロールバックの進行中に中断を指示できる機能だ。次のような状況で役立つ。ロールバックにかかる時間が想定以上に長く、ビジネスへの影響が懸念される場合。あるいはロールバック以外の代替手段（特定ノードだけの切り戻しなど）の方が適切と判断した場合だ。
中断後はPDBの調整やロールバック戦略の見直しを行い、再度実行するか別の手段を選ぶかを決められる。この柔軟性は、大規模クラスタを運用するチームにとって重要なセーフティネットになる。
運用現場へのインパクトと今後の展望
ロールバック機能の登場は、Kubernetes運用の前提を変える可能性がある。これまでは「アップグレードの前に数週間の検証期間を設けるのが常識」だったが、ロールバックが可能になったことで「まず上げてみて、問題があれば戻す」というアプローチが現実的になる。
アップグレードサイクルの短縮
Kubernetesのマイナーバージョンアップは年3回のペースで進む。これに追従するには、アップグレードサイクルを四半期以内に収める必要がある。ロールバック機能によって心理的ハードルが下がれば、検証期間を短縮しつつ最新バージョンへの追随速度を上げられる。
規制業界でも「7日間の戻し窓口がある」という事実が監査対応やリスク評価でプラスに働く可能性がある。セキュリティパッチの適用遅延リスクを低減する効果も見込めるだろう。
注意すべき制約
ロールバックは万能ではない。7日間の期間制限を過ぎると元に戻せないため、アップグレード後の監視と問題検知の仕組みは引き続き重要だ。またノードを自前管理している構成ではノードロールバックが自動化されないため、制御プレーンのみの切り戻しでは不十分なケースも想定される。
ロールバックインサイトが示す警告を無視して強制実行した場合、アドオンの互換性問題などが残る可能性もある。事前チェックを飛ばすのはあくまで緊急時の手段と心得たい。
この記事のポイント
- EKSの新機能「バージョンロールバック」はアップグレード後7日間、1つ前のマイナーバージョンに戻せる
- 制御プレーンのロールバックは全EKSクラスタ、ノードロールバックはAuto Modeクラスタが対象
- ロールバックインサイトで互換性リスクを事前評価し、
--forceでスキップも可能 - PDBを尊重する設計でワークロードの安定性を維持しつつ、キャンセルAPIで中断も選べる
- 追加料金は不要で全商用リージョンで提供開始。アップグレードサイクル短縮の追い風になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
CloudflareのAIクローラールールがGooglebotをブロックする危険性
CloudflareがAIクローラー対策の仕組みを抜本的に見直し、2026年9月15日から新たなデフォルト設定を適用する。この変更は単なるAIボット対策の強化にとどまらず、Googlebotのような検索クローラーまで巻き込む可能性がある。AIにコンテンツを学習されたくないという意図で設定したブロックが、結果的に検索エンジンからの流入を断つリスクをはらんでいるのだ。
特に影響が大きいのは、Cloudflareの無料プランを利用するWordPressサイトや中小企業のオウンドメディアだ。AI学習ブロックの意図がなくても、9月15日以降にデフォルト設定が自動適用され、知らぬ間にGooglebotのクロールが制限される可能性がある。本記事では3つの振る舞い分類、デフォルト変更の詳細、そして今すぐ取るべき対応策を解説する。
CloudflareがAIクローラー対策の方針を転換した背景
Cloudflareは2026年7月2日、第2回「Content Independence Day」の一環として、AIクローラー管理の新方式を発表した。従来の単一の「AIボットをブロック」スイッチを廃止し、クローラーの振る舞いに基づいた3つのカテゴリで制御する仕組みへ移行する。この変更は全顧客（無料プランを含む）に即時適用され、9月15日にはデフォルト設定も自動変更される。
背景にあるのは、AIクローラーによるコンテンツ収集の爆発的な増加だ。Cloudflareのネットワーク上では、AI訓練目的のクローラーリクエストが全体の過半数を占めるまでに成長した。2025年春時点では約20%だったが、1年で状況は一変した。AIエージェントのリクエスト数も前年比1700%増と、指数関数的な伸びを示している。
この急増に対し、多くのパブリッシャーやサイト運営者はAIクローラーを一律ブロックする方向に動いてきた。しかし、その「一律ブロック」が検索クローラーまで巻き込む副作用を生みつつあった。Cloudflareの今回の方針転換は、この問題に正面から取り組むものだが、同時に新たなリスクも生じさせている。
3つの振る舞い分類がクローラー制御を変える
Cloudflareの新方式は、クローラーを「AIかどうか」ではなく「サイト上で何をするか」で分類する。この考え方は、サイト運営者にとってクローラー制御の解像度を格段に上げるものだ。3つのカテゴリは以下のとおり。
Cloudflareは、ボット運営者に対して「振る舞いごとに別々のクローラーを用意すべき」と要求している。サイト側が「なぜそのボットが来ているのか」を判断し、許可・ブロックを適切に選択できるようにするためだ。この考え方自体は合理的だが、現実にはGooglebotのように検索とAI訓練の両方を行う「マルチパーパスクローラー」が存在する。この点が後述する問題の核心となる。
検索クロールとAI訓練クロールの同居がリスクを生む
Googlebot、Applebot、Bingbotは、いずれも検索インデックス作成とAIモデル訓練の両方に使用される。Cloudflareの新ルールでは、こうした「混合用途のクローラー」に対して最も厳しい制限が適用される。つまり、AI訓練目的のクロールをブロックしているサイトでは、同じクローラーによる検索目的のアクセスも自動的にブロックされるのだ。
これはrobots.txtとは根本的に異なる。robots.txtはクローラーへの「お願い」に過ぎず、無視されることもある。しかしCloudflareのブロックはネットワークレベルで動作するため、robots.txtよりはるかに強力だ。グーグルでさえバイパスできない。AI訓練を止めたい一心で設定したブロックが、検索流入というサイトの生命線を断ち切ってしまう皮肉な構造が生まれている。
9月15日のデフォルト変更が生む3つのリスク
2026年9月15日に自動適用されるデフォルト設定の変更は、Cloudflareを利用するあらゆるサイトに影響を及ぼす。特に注意すべきは以下の3点だ。
とりわけ危険なのはリスク3だ。従来の「AIボットをブロック」設定を有効にしたまま放置しているサイトは、9月15日以降にGooglebotのアクセスがネットワークレベルで遮断される可能性がある。検索クロールが停止すれば、新規コンテンツのインデックス登録が滞り、既存ページの再クロール頻度も低下する。検索順位への影響は数週間から数カ月かけて徐々に表面化するため、原因特定が遅れやすい。
robots.txtとの違いを理解しておくべき理由
多くのサイト運営者は「robots.txtでブロックしているから大丈夫」と考えがちだ。しかし、robots.txtはクローラーに対する紳士協定に過ぎず、グーグルも状況によって無視することがある。一方、Cloudflareのブロックはリクエストがオリジンサーバーに到達する前にネットワークエッジで遮断する。この違いは決定的だ。
robots.txtでのブロックは「できれば来ないでほしい」というお願いであり、Cloudflareのネットワークブロックは物理的な門番が門を閉ざすようなものだ。後者のほうが確実だが、その分だけ設定ミスの代償も大きい。AI訓練ブロックのつもりが検索クローラーまで締め出してしまうと、サイトの検索パフォーマンスは確実に悪化する。
実務者が今すぐ取るべき対応チェックリスト
9月15日までに対応を完了する必要がある。以下に具体的なアクションを時系列で整理した。
STEP 5のクロール統計監視は特に重要だ。9月15日以降にGooglebotのクロール頻度が急落した場合、Cloudflare設定に原因がある可能性が高い。Search Consoleの「クロール統計レポート」で1日あたりのクロールリクエスト数を確認し、急激な減少があれば即座にCloudflareダッシュボードを再確認する習慣をつけておきたい。
無料プランユーザーが特に注意すべきポイント
Cloudflareの無料プランを利用しているサイトは、9月15日までに一度もAIクローラー設定を変更していない場合、自動的に新デフォルトへ移行される。つまり「設定を触っていないから大丈夫」という認識が最も危険だ。何もしないことが、意図せずGooglebotブロックを招く可能性がある。
無料プランであっても、ダッシュボードから3カテゴリの設定を手動で確認・変更することは可能だ。Searchカテゴリだけは明示的に「許可」に設定し、TrainingやAgentはサイトのポリシーに応じて判断する。この一手間をかけるかどうかで、9月15日以降の検索パフォーマンスが大きく変わる。
今後の展望とサイト運営者が持つべき視点
Cloudflareは、マルチパーパスクローラーの運営者に対して「振る舞いごとにクローラーを分離する」ことを求めている。グーグルやアップル、マイクロソフトがこの要求に応じてGooglebotを用途別に分割するかどうかが、今後の分岐点となる。仮に分割が実現すれば、サイト運営者はAI訓練だけをブロックし、検索インデックスは許可するという選択が可能になる。
しかし、現時点ではその保証はない。9月15日以降もGooglebotは単一のクローラーとして動作し続ける可能性が高い。つまり、AI訓練をブロックするという選択は、当面の間「検索流入とのトレードオフ」であり続ける。この現実を直視した上で、サイト運営者は自社のコンテンツ戦略とAIポリシーを再定義する必要がある。
Cloudflareは新しいコンテンツ利用シグナルもテスト中だ。robots.txtに記述するContent Signalsの拡張で、immediate（保存しない）、reference（インデックスしてリンクバック、新デフォルト）、full（要約・複製を許可）の3段階を指定できるようにする。ただしこれは設定上の「希望表明」であり、単体ではブロック機能を持たない点に注意が必要だ。
サイト運営者が今から準備すべき3つのこと
AIにコンテンツを学習されることを完全に拒否するのか、それとも検索流入を優先するのか。この問いに明確な答えを持たないまま9月15日を迎えると、Cloudflareの新デフォルトによって想定外のブロックが発生し、検索パフォーマンスが毀損するリスクがある。サイトの規模や収益構造に応じて、今のうちに方針を固めておくことが重要だ。
この記事のポイント
- CloudflareのAIクローラー管理が3つの振る舞い分類（Search、Agent、Training）に再編された
- 9月15日から広告表示ページでTrainingとAgentがデフォルトブロックされ、無料プランユーザーも自動移行の対象
- Googlebotのような混合用途クローラーは、AI訓練をブロックすると検索クロールも停止する
- robots.txtと異なり、Cloudflareのブロックはネットワークレベルで動作しバイパスが困難
- Searchカテゴリの許可確認とSearch Consoleでのクロール統計監視が当面の最優先対応
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験