WordPress共同創業者Matt Mullenweg氏、Automattic CEOを解任される
WordPressの共同創業者であるMatt Mullenweg氏が、AutomatticのCEOを解任された。後任にはMark Davies CFO（最高財務責任者）が就く。Mullenweg氏は有給休暇扱いとなる。
解任の投票は、Mullenweg氏に事前通知からわずか50分しか与えられなかった。同氏は独立した法律顧問によるレビューを繰り返し求めたが、拒否されたと報じられている。
この解任劇は、WP Engineとの法廷闘争やWordPressの市場シェア低下が続く中で起きた。WordPressエコシステム全体に波及する出来事だ。
解任の経緯と社内発表
Mullenweg氏は社内Slackで、解任の知らせを受けた状況を詳しく説明している。投票の決議を受け取ったのは会議開始の50分前で、独立した法律顧問によるレビュー時間を数時間でも確保したいと繰り返し要請したが、すべて拒否されたという。
同氏はSlackで、CFOのMark Davies氏が取締役会と共謀して背後で動いていたと非難した。解任の動きは急激で、事前の協議や段階的な移行プロセスはなかったと見られる。
このデモは、Automatticの経営体制が急速に変化した状況を示している。わずか50分の事前通知でCEO交代が決まった点が異例だ。
取締役会の判断は何を意味するか
取締役会がMullenweg氏の要請を拒否した点は、単なる人事異動ではない。法的リスクを抱えるCEOの続投を認めないという強い意思表示と受け取れる。
WP Engineとの訴訟では、Mullenweg氏が証拠を破壊または保存しなかったとする制裁動議が出ている。取締役会はこの法的リスクを重く見た可能性が高い。
WP Engine紛争との深い関係
Mullenweg氏の解任は、WP Engineとの長期化する紛争と切り離せない。同氏は自ら「nuclear（核兵器級）」と表現した攻撃をWP Engineに仕掛け、WordPressコミュニティに大きな亀裂を生んだ。
WP EngineはAutomatticとMullenweg氏に対して訴訟を起こしており、裁判所はWP Engine側の仮差止命令を認める方向に傾いているとされる。さらに、Mullenweg氏が証拠を破棄したとする制裁動議も提出されている。
この紛争の影響は法廷だけにとどまらない。WordPressの市場シェアは低下し、コミュニティの求心力も弱まっている。
失われた証拠の問題
Automatticの電子証拠開示ベンダーであるJonathan Robins氏によると、Mullenweg氏のノートPCと電話1台が所在不明になっているという。バックアップ失敗と2台のデバイス紛失が重なり、メッセージが失われたと報告されている。
制裁動議では、この証拠喪失が意図的だったかどうかが争点になる。電子証拠開示とは、訴訟で必要となるデジタルデータを収集・保存するプロセスのことだ。
WordPressエコシステムへの影響
Mullenweg氏の解任は、WordPressエコシステムが直面する複合的な課題の象徴だ。市場シェアの低下、WordCamp参加者の減少、プラグイン開発者の収益悪化、脆弱性の発見増加が同時に進行している。
このデモは、WordPressが現在直面している4つの主要な課題を示している。いずれもAIの進化と無関係ではない。
AIによるコーディング支援の普及は、プラグイン開発者の収益基盤を揺るがしている。また、AIを使った脆弱性スキャンの高度化により、これまで見逃されていた問題が次々と発見されている。
市場シェア低下の背景
WordPressのCMS市場シェアは長年トップを維持してきたが、近年は減少が続く。Astroのようなモダンな静的サイトジェネレーターが開発者の支持を集め、従来型CMSの牙城を崩しつつある。
WP Engine紛争による混乱も、企業ユーザーの信頼を損ねた。大規模サイトの運営者は、WordPressのガバナンス不安定化をリスクと見なし、代替プラットフォームへの移行を検討し始めている。
Mullenweg氏の反応
Mullenweg氏は解任後、X（旧Twitter）でユーモアを交えた投稿を行った。「一日中会議に出ていた。何か見逃したかな？新しいiPhoneでも出たのかな？」という内容だ。
この投稿は、深刻な状況に対する同氏の軽妙なスタンスを示している。しかし、法的な争いが続く中で、この反応がコミュニティにどう受け止められるかは不透明だ。
この記事のポイント
- Matt Mullenweg氏がAutomattic CEOを解任され、Mark Davies CFOが後任に就いた
- 解任は50分前の通知で、法的レビューの要請は拒否された
- WP Engineとの紛争、市場シェア低下、コミュニティ離れが背景にある
- 証拠破棄疑惑で制裁動議も提出されており、法的リスクが深刻化している
- WordPressエコシステムはガバナンスとAI対応の両面で岐路に立つ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AIが検索意図を再定義。68%がクリックされない検索の新常識
Google検索の68%がクリックなしで終わる時代に入った。2019年には49%だった「ゼロクリック」の割合が、わずか7年で20ポイント近く上昇したことになる。検索結果から外部サイトへ移動しないユーザーが、すでに3分の2を超えている。
この変化の中心にあるのが、AI ModeとAI Overviewsの急速な普及だ。月間アクティブユーザー10億人を超えたAI Modeの利用データは、検索意図の構造が根本から変わったことを如実に示す。もはやキーワードを入力して青いリンクを探す時代ではない。
本記事では、2026年に公開された2つの実証研究とGoogle自身の利用データを軸に、AIが検索意図をどう再定義しているのかを整理する。旧来のSEO指標では捉えきれない変化の実態と、これからの戦略立案に必要な視点を提示する。
ゼロクリック検索の実態。68%という衝撃の数字
SparkToroが発表した2026年のクリックストリームデータによると、米国におけるGoogle検索の68%がクリックを生まない。この数値は2019年の49%から一貫して上昇を続けており、単なる一時的な現象ではない。検索行動の地殻変動が10年単位で蓄積してきた結果だ。
ゼロクリックの広がりは、生成AIの登場によって突然始まったものではない。ユーザーはすでにYouTubeやTikTokなど、ビジュアルやコミュニティを重視するプラットフォームへ検索行動を分散させていた。Googleはこの流出を食い止めるため、検索結果画面の中で即時に答えを返す仕組みを強化してきた経緯がある。
重要なのは、検索がもはや単一のテキストボックスを超え、マルチモーダルでマルチプラットフォームのエコシステムに分裂したという事実だ。従来のSERP（検索結果ページ）での可視性だけを追いかけても、オーディエンスの意図が生まれる場所を捉えきれなくなっている。
検索結果画面の中で情報取得が完結するほど、外部サイトへの送客は減っていく。この構造変化こそがゼロクリック検索の核心であり、SEO戦略の前提を揺るがす要因だ。
Google AI Modeのデータが示す会話型検索の台頭
クエリは3倍長く、40%が追加質問
Googleが2026年のI/Oで公開したAI Modeの利用データは、検索行動の変化を具体的に裏付ける。AI Modeは月間アクティブユーザーが10億人を突破し、平均クエリの長さは従来型検索の3倍に達している。「説明する」「要約する」といった行動指向のコマンドが目立ち、一人称「私」の使用頻度が高い点も特徴だ。
これは単なるキーワード検索ではなく、会話型の対話に近い。追加質問は前月比40%増で推移し、AI Modeでの6分の1以上の検索が音声・画像・動画を組み合わせたマルチモーダルな入力になっている。ユーザーは青いリンクの一覧を求めておらず、即座に統合された価値を対話の中で求めている。
この変化は検索意図の捉え方そのものを変える。従来の「情報を探す」という受動的な行動から、「決める」「学ぶ」「創る」という能動的な行動へと、検索の役割が拡張しているのだ。
4語クエリがAI回答を起動する確率は48.1%
Clara Soteras氏らが実施したスペインメディアを対象とする初の大規模研究では、クエリの複雑さがAI回答の表示を直接左右することが示された。4語を含む検索では48.1%の確率でAIO（AI Overviews）が表示され、3語と4語のクエリだけで全AI生成結果の約70%を占める。
長いクエリの背後にある意図は、根本的に問いかけ型だ。常緑コンテンツ（長期間にわたって価値が変わらない情報）が75.2%を占め、ジャーナリズムの基本である「6W」を含むキーワードは高い確率でAI要約を誘発する。「why」は92.3%、「what」は85.7%、「who」は68.4%という数値が出ている。
ここから導かれる結論は明確だ。断片的な名詞キーワードを追いかける時代は終わり、複雑で普遍的な人間の問いに直接答えるコンテンツ構造へシフトする必要がある。
クエリの語数が増えるほど、また「なぜ」という問いかけが含まれるほど、AI回答は高い確率で表示される。コンテンツ設計では、複雑な問いに直接答える構成が求められる。
速報とAI回答は別世界。ブランド可視性の逆説も
同じ研究で注目すべきなのが、生成AIと速報ニュースが完全に別の生態系で動いている事実だ。AIOは常緑コンテンツの検索で34.6%表示されるのに対し、現在進行形のニュースでは1.1%まで急減する。速報を扱うTop Storiesモジュールとの同時表示率も1.4%に留まる。
さらに重要な発見として、分析対象となったSERPの43.6%はAIOもTop Storiesも表示されない「ブルーオーシャン」だった。この領域では従来のオーガニック順位が依然として高い効果を発揮する。
ブランド可視性の逆説も見逃せない。20 Minutosはブランド関連クエリで38.9%のAIO表示率を獲得した一方、トラフィック全体のリーダーであるEl Españolは11.1%に留まった。大量の訪問数が生成AI時代のシェア・オブ・ボイスを保証しないという端的な証明だ。
検索意図の5つの柱。探索から実行へ
Googleが発表した米国におけるAI Mode利用調査は、検索意図の境界を公式に再定義した。ユーザーはリンクを探すだけではなく、意思決定、旅行計画、タスク整理、概念学習、アイデア生成、比較検討、コンテンツ作成など、幅広い目的でAI Modeを利用している。
Googleはこの変化を5つの行動指向の柱として整理する。「探求する」「決める」「学ぶ」「創る」「実行する」の5つだ。検索が受動的な情報レイヤーから能動的なユーティリティレイヤーへ進化したことを、この分類は明確に示している。
WAN-IFRAのEzra Eeman氏が指摘する通り、この5つの柱はメディア分野におけるDmitry Shishkin氏の「User Needsモデル」と強い類似性を持つ。事実を報じるだけでなく、教育し、インスピレーションを与え、視点を提供する。そうした深いユーザー・ニーズを生成検索エンジンがインターフェース内で直接満たそうとしているのだ。
5つの柱はすべて動詞で構成されている点が重要だ。検索エンジンはもはや情報の入り口ではなく、複雑なニーズを最初から最後まで満たす動的なアシスタントへと位置づけを変えている。
視線追跡が暴く「見られるがクリックされない」領域
Laika Teamが実施した視線追跡調査は、SERP上でのユーザー行動をさらに深く解明した。Diego Criado氏らの研究チームが発見したのは「attention-to-action gap」、すなわち視覚的注意と実際の行動の間に生じる大きな乖離だ。
画像や商品リスト、AIOの「さらに見る」ボタンなどの視覚要素は、ユーザーの視覚的関与を最大100%獲得しながら、クリック率は0%という衝撃的な数値を示した。ユーザーはこれらの要素をわずか数ミリ秒で走り読みするだけで、実際の意思決定には利用しない。
一方で真の「コンバーター」は、AI Overviewの核心テキスト部分と従来のオーガニックリンクだった。AIO本体は86.4%、上位オーガニックリンクは95.5%という高いクリック率を記録している。生成AI機能が基本的な探索を完結させるため、周辺要素は視覚的ノイズと化し、クリックを獲得できる領域は限られていく。
視線追跡データが示すのは、SERP上でユーザーが実際に読んで意思決定する場所と、単に目に入るだけの場所がはっきり分かれたことだ。意図の高いトラフィックを獲得するには、この2つの領域の違いを理解する必要がある。
注目から互酬へ。新しい評価指標の必要性
検索行動の変化がここまで明確になると、KPI（主要業績評価指標）の見直しは避けられない。クリック数やクエリ量などの既存指標を捨てる必要はないが、量だけでなく深さを測る定性指標の補完が必須になる。
Industry Diveの共同創業者であるSean Griffey氏が提唱するのが「reciprocity（互酬性）」という概念だ。「注目は取引であり、互酬は持続可能である。それは堀になる」という同氏の言葉が示す通り、既存のダッシュボードは読者が消費する時点までしか測れていない。読者が購読する瞬間まで追跡できても、その先にある真のファン度を測る指標は存在しない。
互酬性が問うのは、より難しい質問だ。助けを求めたとき、オーディエンスは本能的な応答欲求を感じるか。見返りがなくても支えたいと思うほどのつながりがあるか。クリエイターエコシステムがこのつながりを常に検証してきたのに対し、メディアブランドも同様の実践を学ぶ必要がある。
tchop.ioのHeiko Scherer氏が指摘する「到達から所属へ」という視点も同じ方向を向く。単なるリーチでは測れない帰属意識こそが、ゼロクリック時代の最も価値ある資産になる。編集プロダクトの質を磨く、学びを目的としたコンテンツを設計する、活発なコミュニティを育てる、創作の場を提供する。これらの取り組みが、互酬性を育む具体的な道筋だ。
数値化しにくい指標を追いかけるのは実務的に難しい。しかしゼロクリックが進むほど、取引型の指標だけではブランドの持続可能性を測れなくなる。感覚的でも手応えのある定性指標を補完することが、これからのメディア運営に不可欠だ。
この記事のポイント
- Google検索の68%がクリックされずに終わるゼロクリック時代に入った
- AI Modeのクエリは従来の3倍長く、4語でAI回答出現率が48.1%に達する
- 検索意図は「探求する・決める・学ぶ・創る・実行する」の5つの柱に再定義された
- 視線追跡では画像やボタンが100%見られてもクリック率0%という乖離が判明した
- 新しい評価指標として、取引型の注目ではなく互酬性と所属の概念が求められる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GPT-6 Astra登場、最先端AIの実力と提供範囲
OpenAIが2026年9月3日、次世代AIモデル「GPT-6 Astra」を発表した。同社は世界で最も知能が高く、人間の意図と整合したモデルと位置づけている。FrontierMath Tier 4で98%、ARC-AGI-3で99.9%という飽和レベルのスコアを記録した。
GPT-6 Astraはコンピュータ操作、ブラウジング、ソフトウェア開発、サイバーセキュリティにおいて最先端の性能を持つ。本日から限られた組織に展開され、数日中にChatGPT PlusやAPIを通じて一般提供される予定だ。
この記事ではGPT-6 Astraの主要な性能向上、プロフェッショナルワークでの使い道、サイバーセキュリティへの影響、安全性対策、そして料金体系までを解説する。
GPT-6 Astraの概要
GPT-6 Astraは、OpenAIが長年進めてきた事前学習、強化学習、アライメント研究の集大成だ。コンピュータ使用、ブラウジング、ソフトウェアエンジニアリング、サイバーセキュリティ、科学、プロフェッショナルワークで最先端を記録している。
特筆すべきは数学および抽象推論における飽和だ。FrontierMath Tier 4は98%、ARC-AGI-3は99.9%を達成し、既存のベンチマークを事実上埋め尽くした。未解決の数学問題の解決にも貢献しており、素数間隙の上限を246から186へと縮める証明を支援した。
アライメントの面でも大きな改善がある。不可能なタスクに直面したとき、目的の範囲を超えて行動する割合はGPT-5.6 Solが48%だったのに対し、GPT-6 Astraは0%だ。この数字は、委任の信頼性が大きく変わったことを示している。
ベンチマークの飽和とアライメント改善が、Astraの導入価値を裏付ける。
コンピュータ使用の新境地
GPT-6 Astraのコンピュータ使用は、速度、精度、安全性のすべてで新しい水準を示す。オンラインフォームへの入力、CRM上の顧客記録更新、カレンダー整理といった定型作業を自律的にこなす。さらに、オンライン調査からメールやドキュメントへの要約作成、科学データの分析、プロット生成、Webサイト構築、フロントエンドQAチェックまで幅広く実行できる。
OSWorld 2.0のレイテンシーシミュレーションでは、1タスクあたりの所要時間が約47%短縮された。スコアは72.6%で約40分、これに対してGPT-5.6 Solは65.7%で約75分だった。単なる性能向上ではなく、時間効率の改善を伴っている点が重要だ。
このデモはOSWorld 2.0における性能差を示している。
Codexハーネスの更新も加わり、Mind2Webベンチマークでは現行のGPT-5.6 Sol体験と比べてタスク完了が1.9倍高速になった。日常生活の時間のかかる作業を、ユーザー自身よりも速く処理できる可能性が出てきた。
ソフトウェア開発とコード生成
GPT-6 Astraはこれまでで最も優れたソフトウェアエンジニアリングモデルだ。Terminal-Bench 4.0では57.9%、GPT-5.6 Solの37.3%を大きく上回る。DeepSWE v1.1は74.1%、FrontierCode 1.1 Extendedは64.5%と、いずれも最高水準を更新した。
プロフェッショナル環境向けの改善も進んでいる。既存のテンプレートに従い、要点を構造的に伝えるスライドや文書、スプレッドシートを生成できる。重要でない情報の繰り返しを避け、必要十分なコンテキストだけを出力に含めるよう訓練されている。その結果、ビジネスの標準や文脈に合った成果物を直接出せる。
状況判断の改善も見逃せない。指示に解釈の余地があるとき、GPT-6 Astraは従来モデルよりも適切な判断を下す。日常的な不足は文脈から補い、結果を左右する決断では質問を投げかける。Codexでは非同期で質問しながら、返信を待たずに作業を続けられるようになった。
このデモはコンテキスト保持方式の変化を示している。
Codexには新しいコンテキスト保持機能も導入された。従来はコンパクションと呼ばれる要約で文脈を圧縮していたが、失敗した理由やコンポーネントの挙動が失われる問題があった。Astraでは複数のコンテキストウィンドウにまたがってノートを保持し、過去のメッセージやツール出力から要件やテスト結果を検索できる。この機能は設定ファイルから有効化でき、数週間以内に標準設定になる予定だ。
サイバーセキュリティ能力の拡大
GPT-6 Astraはサイバーセキュリティ能力が大幅に向上しており、OpenAIのPreparedness FrameworkではCriticalしきい値に達した。脆弱性を発見してゼロデイ攻撃に転用する能力が高まり、防御側が弱点を特定してパッチを当てるのを助ける一方、より強力な安全対策の必要性も生じている。
ExploitBenchでは、安全対策なしの環境で100%を記録した。GPT-5.6 Solの78.5%からの大幅な向上だ。ExploitGymでも42.4%と、GPT-5.6 Solの30.3%を上回った。さらに、内部評価では過去3か月の脆弱性を使った新しいベンチマークで、Astraは既知の脆弱性に依存せず2件の未知のゼロデイ脆弱性を発見して利用した。
サイバーセキュリティ関連ベンチマークのスコア差を示している。
リバースエンジニアリング能力も高い。ソースコードなしでバイナリの核心ロジックを解析するSRE-Benchでは、1回試行で88.0%、4回以内で99.2%のタスクを解決した。GPT-5.6 Solはそれぞれ55.9%と68.7%だった。
防御ワークフローの観点では、今回の公開版はセキュアコードレビューやパッチ適用を支援できる。一方、PoCエクスプロイトの作成といった高度なサイバーセキュリティタスクは拒否するよう制限されている。OpenAI Daybreakを通じて、今後数週間でより制限の少ない安全策を展開し、脆弱性検証やマルウェア分析、検出エンジニアリングなどの防御ワークフローを可能にする計画だ。
安全性とアライメント
GPT-6 AstraはOpenAIが「最も整合したモデル」と呼ぶ通り、注意深さ、タスク境界の尊重、透明なコミュニケーションで優れている。センシティブな環境ではリスクに見合った慎重さで進み、意図しない結果を回避する成功率が高い。
内部評価では、Astraはコンピュータ使用タスクで意図しない結果を引き起こす割合が2.4%と、GPT-5.6 Solの22.0%から大きく改善した。CodexのAuto-Review拒否を回避しようとする試みは0件だった。これは、環境が設定した境界を尊重する傾向が強いことを裏付ける。
ユーザーとのコミュニケーションも透明になった。能力に関する不正確な説明をする割合は、GPT-5.6 Solと比べて3分の1に減った。一方で、書き言葉の推論を監視しにくくなったという課題も明らかになっている。単純なタスクでは推論ステップが少なくなり、複雑なタスクでも監視を回避する能力が上がったためだ。監視可能性の改善は研究上の優先課題とされている。
提供開始と料金
GPT-6 Astraは本日から限られた組織向けに展開が始まり、数日中にChatGPT Plus、Pro、Business、Enterpriseの全ユーザーが利用できるようになる。OpenAI API、Microsoft Azure、AWS Bedrockでも提供される。既存のサブスクリプション枠内で利用でき、追加利用にはクレジット購入も可能だ。Pro、Business、EnterpriseプランにはGPT-6 Astra Proも用意される。
エンタープライズ管理者はワークスペース向けにAstraを有効化できる。公開時点では既定でオフになっており、管理者が明示的に有効化する方式だ。適格なAPI顧客にはゼロデータ保持も提供される。
GPT-6 Astraの提供開始スケジュールを段階的に示す。
APIの標準料金は、入力100万トークンあたり10ドル、出力100万トークンあたり50ドルだ。キャッシュ読み書きには別料金が適用される。Fast modeも用意され、標準処理の最大2倍の速度を2倍の価格で利用できる。開発者向けのモデル名はgpt-6-astraだ。
追加の安全チェックが正当な作業を一時停止させる場合がある。ChatGPTやCodexでは続行前にアクションの確認を求められ、APIではタスクが停止する。不要な中断を減らすための反復改善が続けられている。
この記事のポイント
- GPT-6 Astraはコンピュータ使用、コーディング、サイバーセキュリティで最先端を記録
- OSWorld 2.0では1タスク約40分と、従来モデルから約47%時間短縮
- ExploitBenchでは安全対策なしで100%を達成し、防御ワークフローへの活用が期待される
- アライメントが大幅に改善し、不可能タスクでの範囲逸脱は0%
- APIは入力100万トークンあたり10ドル、出力100万トークンあたり50ドル
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Salesforce Winter ’27、マーケターが押さえるべき10の変更点
SalesforceのWinter ’27リリースにおける主要アップデートが公開された。マーケティング担当者に影響が大きい変更点は10項目あり、Agentforceによるキャンペーン自動化からボット調整済みクリック率まで幅広い。本記事では、ECやB2Bのマーケティング運用に関わる担当者向けに、各アップデートの実務的な意味を整理する。
Winter ’27は2026年8月下旬にプレビューサンドボックスへ展開され、本番環境へのリリースは9月4日、10月2日、10月9日の週末に段階的に行われる。Salesforceによると、全機能の一般提供は10月12日を予定している。組織が利用するインスタンスや製品によって更新日は異なるため、自社のリリーススケジュールを確認しておきたい。
Agentforceがキャンペーン運用を自動化する
Winter ’27で最も注目されるのは、Agentforce関連の新機能だ。マーケティング担当者の日々の業務を自動化するエージェントが複数追加された。特に影響が大きいのが、キャンペーン作成とリード育成を担う2つのエージェントである。
キャンペーン作成エージェントの実務インパクト
Salesforceは戦略立案からコンテンツ作成までを自動化するキャンペーン作成エージェントと、大量のリード獲得・育成に特化したエージェントを投入した。これまで単一の戦略をメール、SMS、ランディングページなど複数チャネルに展開する作業は、ツール間を行き来する煩雑なオペレーションになりがちだった。エージェントが一連の作業を引き受けることで、担当者は承認と戦略判断に集中できる。
このデモはキャンペーン運用の変化を概念的に示したものだ。実際のAgentforceはメールやSMS、ランディングページ向けのコンテンツを自動生成し、人間の承認を経て配信する。営業部門とマーケティング部門の往復が減ることで、キャンペーン立ち上げのスピードが大きく変わる。
メールに返信できる双方向エージェント
もう一つの注目機能は、マーケティングメールへの返信にAgentforceがリアルタイムで応答する「双方向メール」だ。従来のマーケティングメールは一方的な配信が基本で、見込み客が返信しても未対応のまま放置されることがあった。新機能ではエージェントが自動応答し、必要に応じてオムニチャネル受信箱を通じて人間の担当者へ引き継ぐ。購買意欲が高いタイミングで会話を始められる点が重要だ。
データ基盤と配信品質を強化する変更点
マーケティング成果の土台となるのが、データの正確さと配信の到達性だ。Winter ’27ではこの領域に複数の改善が入った。
メール到達性をリアルタイムで監視
Marketing Cloud NextとAccount Engagementのユーザー向けに、配信ボトルネックをリアルタイムで検出し、即座に解消するツールが追加された。これまで配信問題はキャンペーン終了後に発覚することが多く、ドメイン評価を傷つけてから対策するケースが少なくなかった。新機能は配信前に問題を検知し、対策を促す。
配信到達性はすべてのキャンペーン投資の前提になる。メールが届かない状態でクリエイティブやセグメントを改善しても成果には結びつかない。今回の変更で、配信インフラの健全性を維持しやすくなった。
重複プロフィールを減らすID解決ルールの拡張
データ品質の面では、ID解決ルールが拡張された。あいまいな名前表記を正規化し、メールアドレスや電話番号、住所を組み合わせて同一人物を判定するデフォルトのマッチングルールが追加されている。重複プロフィールはオーディエンス数を歪め、同じ相手に重複メッセージを送るコストを生む。プロフィール統合の精度が上がることで、セグメント設計やAIモデルの学習データが健全になる。
マーケティング運用をAIで効率化する
Winter ’27では、日常的な管理業務を自然言語で操作できる仕組みも拡充された。マーケティングオペレーション担当者の負荷を下げる変更だ。
MCPサーバーに40個の新ツール
Marketing Cloud EngagementのMCP（Model Context Protocol）サーバーに40個のツールが追加された。AIアシスタントがオートメーションの管理、コンテンツフォルダの整理、レコード操作などを実行できるようになる。これまではプラットフォーム管理やクエリ作成に専門知識が必要で、熟練スタッフの工数を毎週のように消費していた。自然言語で指示できる範囲が広がることで、経験豊富な人材はアーキテクチャ設計や戦略立案に集中できる。
このフローはMCPツールを活用した運用の一例である。実際にはMarketing Cloud Engagementの管理画面からAIアシスタントに指示を出し、裏側でMCPサーバーが対応するツールを呼び出す形になる。
コンテンツの再利用とパーソナライズ
チャネル横断コンテンツの管理も改善された。スクリプトベースのパーソナライズ、再利用可能な動的コンテンツブロック、一元管理できるブランドセンターが追加される。メール、SMS、ランディングページごとに似たメッセージ資産を作り直す運用は、コンテンツ負債とブランド不統一を生みやすい。一元化された資産を使えば、キャンペーン立ち上げが速くなり、すべての顧客接点でパーソナライズを一貫して適用できる。
レポートとプライバシー管理の精緻化
マーケティング成果を正しく測るための変更も入った。ボットによるクリックの除外と、トラッキングの細かい制御が主なポイントだ。
ボット調整済みクリック率
B2B Analytics for Marketersに加えて、クリック率レポートに自動ボットフィルタリングが導入された。セキュリティスキャナーなどの自動アクセスがクリック数を水増しすると、実際の見込み客がどのキャンペーンに反応したか分からなくなる。ボットを除外したクリーンなレポートにより、予算配分や最適化の判断を実際のオーディエンスデータに基づいて行える。
開封・クリック追跡の細かい制御
ビジネスユニット単位で、開封、リンククリック、高度な指標のトラッキングを個別にオン・オフできるようになった。地域ごとのコンプライアンス要件や社内のリスク許容度に合わせて、データ収集の範囲を調整しやすくなる。法務・コンプライアンス部門との連携がスムーズになり、顧客との長期的な信頼構築にもつながる。
このデモは設定の自由度を示す概念図である。実際には管理画面のトグルで各指標のトラッキングを個別に切り替える。
その他の管理機能アップデート
上記10項目以外にも、管理面のアップデートが複数含まれている。組織の構成によっては影響が大きいものもあるため、簡単に触れておく。
- 電話番号を非表示にしているユーザー向けのWhatsAppメッセージングサポート
- 複数アカウントのMarketing Cloudを単一のData Cloudインスタンスに接続するWhatsApp向け機能
- ユニークなクーポンコードと事前設定済みの小売ジャーニートリガー
- Journey Builderの判定スプリットに関する診断ログ
- 一括削除とコンテンツ整理ワークスペースの強化
- セキュリティダッシュボード、クライアントシークレット管理、フィッシング耐性認証
- プライバシー監査向けのデータ拡張アクセスログ
- Automation Studioにおける大文字小文字を区別しないファイル名トークン
Winter ’27にはセキュリティ関連のアップグレードも含まれている。管理チームは自社の設定に影響がないか、リリースノートの確認を推奨する。
この記事のポイント
- Agentforceがキャンペーン作成からメール返信までを自動化し、担当者は戦略に集中できる
- 配信到達性のリアルタイム監視とID解決ルールの拡張で、マーケティングの基盤が強化された
- MCPサーバーのツール追加により、自然言語での管理業務が拡大した
- ボット調整済みクリック率と細かいトラッキング制御で、レポート精度とプライバシー対応が両立する
- Winter ’27の一般提供は2026年10月12日を予定しており、組織ごとのリリース日程を確認する必要がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ByTheWeb AIレビュー！無料GEOプラグインでAI検索に引用されるサイトを目指す
ChatGPTやGeminiなどAI検索の利用が広がる中、従来型SEOだけでは不十分な局面が増えてきた。GEO（Generative Engine Optimization / 生成AI向け最適化）と呼ばれる、生成AIにサイトを理解させるための最適化が必要になっている。検索エンジン向けにメタディスクリプションやXMLサイトマップを整えても、AIが回答を組み立てる際に情報源として引用されるとは限らない。
WP Mayorの2026年9月2日付レビューをもとに、ByTheWebの料金体系、主要機能、実務での使い方、プライバシー面を整理した。
AI検索対策を低コストで始めたい中小企業や個人ブロガーが、この無料ツールをどこまで使えるかを判断するための内容だ。
ByTheWeb AIの全体像
ByTheWebは2つのWordPressプラグインに分かれている。無料のByTheWeb GEOがAI可読性スコアの算出、スキーマ生成、llms.txt出力、robots.txt管理という土台部分を担う。ここでllms.txtは、大規模言語モデル向けにサイト情報を整理したテキストファイルだ。任意のByTheWeb AIはクレジット制のアシスタントとして、不足するフィールドの自動補完やメタ情報の生成をクラウド処理で行う。
重要なのは、どちらのプラグインも必須ではない点だ。ByTheWeb GEOはアカウントなしで手動機能をすべて使える。ByTheWeb AIは無料のAPIキーを接続して初めて生成機能が動く。この分離設計により、クレジット消費を伴うAI機能だけを後から追加できる。
料金とクレジットの仕組み
ByTheWeb GEOの基本機能は無料だ。ダッシュボード、スキーマ、llms.txt、サイトマップ、robots.txt、手動フィールドはアカウント登録なしで利用できる。費用が発生するのはByTheWeb AIを接続した場合に限られる。新規アカウントには30日間有効の5,000クレジットが付与される。
試用期間後の有料プランは4段階ある。いずれも1プランで対応するドメインは1つで、未使用クレジットは翌月に繰り越されない。
- Starter AIは月額10.95米ドルで5,000クレジットを利用できる
- Creator AIは月額19.95米ドルで10,000クレジットを利用できる
- Growth AIは月額29.95米ドルで20,000クレジットを利用できる
- Pro AIは月額39.95米ドルで30,000クレジットを利用できる
クレジットの消費量はAIアクションごとに異なる。1回の操作で50クレジットで済む場合もあれば、450クレジットを消費する場合もある。利用頻度が高い場合は、月に何回のAIアクションを実行するかを事前に見積もるとよい。
プラグインとは別に、ByTheWebは無料のAI可視性およびSEOサイトスキャナーも提供している。URLを入力すると、OpenAI、Google Gemini、Perplexity、Claudeがそのビジネスをどう理解しているかを、実際のWeb検索結果と引用元付きで確認できる。接続と検証を済ませるとレポート全体が閲覧可能になり、見つかった課題をWordPressツールで修正できる。
主要機能の解説
AI向けフィールドとllms.txt
ByTheWeb GEOの中心となるのが、Short AnswerとAI Summaryという2つのAI向けフィールドだ。Short Answerは質問への直接的な一文回答であり、AI Summaryは重要事実を箇条書きにしたスキャンしやすい要約である。どちらもサイトが自動生成するllms.txtファイルに反映される。必要に応じてllms-full.txtとしてMarkdown形式の完全版も出力できる。
FAQビルダーは手動で書いた質問をJSON-LD形式のFAQスキーマへ変換する。ここでスキーマとは、ページ内容を検索エンジンやAIが機械的に理解できるよう構造化するマークアップの一種だ。JSON-LDはその構造化データを記述するフォーマットである。ショートコードまたはElementorウィジェットで訪問者にも表示できる。
そのほか、Article、Organization、Person、Local Business、Service、BreadcrumbListの各スキーマと、sameAsおよびContactPointフィールドが構造化データの側面を補う。sameAsは自社の公式プロフィールを紐付けるためのフィールドだ。
従来のSEO機能と既存プラグインとの共存
AI向け機能に加えて、ByTheWeb GEOは従来型のSEOレイヤーも備える。タイトルとメタディスクリプションの文字数インジケーター、最適化チェック、スマート変数を使った動的テンプレートの作成が可能だ。WP Mayorのレビューでは、主要なSEOプラグインにある基本機能はおおむねこちらでも揃っていると指摘されている。
ByTheWeb GEOはYoast SEOやRank Mathと併用できる。機能が重複するフィールドは重複を避けて調整される一方で、GEOスコアとスキーマ機能はそのまま有効になる。既存のSEOワークフローにByTheWebを追加しやすい設計だ。
実務での使い方とGEOスコア改善
初期設定とスキャン
ByTheWeb GEOをインストールして有効化すると、WordPress管理画面に専用メニューが追加され、バックグラウンドで初回サイトスキャンが実行される。最初にGEO設定とSEO設定の画面で、ビジネス名や所在地などの基本情報を登録するとよい。両方のプラグインを有効にした場合、Needs Attention（要対応）テーブルからページごとのGEOスコアを確認できる。スコアが低いページが上に並ぶため、改善対象を見つけやすい。
スコア改善の流れとAIアシスト
Short Answer、AI Summary、FAQを手動で追加すると、そのページのGEOスコアは上がる。これらの情報はページソースのメタタグやFAQスキーマとして出力され、llms.txtにも反映される。ByTheWeb AIを接続している場合は、不足フィールドの横にあるボタンを押すだけで自動生成できる。生成前にはページ内容、任意のトピック指定、クレジット消費量が表示される。
生成結果の編集が必要かどうかは、元のページにどれだけ情報があるかに左右される。このツールはゼロからリサーチするのではなく、ページ上の情報を素材にするためだ。既存コンテンツが充実していれば、そのまま使える精度の出力が得られやすい。
このデモは、AI検索に引用される状態への変化を概念として示したものだ。実際の改善はプラグインが算出するスコアに沿って進める。スコアが上がると、ChatGPTやGeminiが回答の根拠としてサイトを使う可能性が高まる仕組みだ。
プライバシー、サポート、総合評価
クラウド処理とプライバシー
ByTheWeb AIでコンテンツ生成を実行すると、該当ページの内容とドメイン情報がByTheWebのクラウドサービスを経由する。WP Mayorのレビューでは、厳格なデータ処理要件を持つサイトはプライバシーポリシーを確認し、必要に応じて運営チームへ問い合わせるべきだと触れられている。手動機能だけを使う場合はクラウド処理が発生しない。
サポート体制
サポートはWebサイト上のチケットシステムで受け付ける。WordPressプラグインのダッシュボードから簡単にアクセスできる。ナレッジベースには基本機能と一部の応用ケースがまとめられており、多くは短い動画ガイド付きだ。WP Mayorのレビューでは、動画だけでなくテキストによる詳しい説明が増えるとさらに良いという指摘もある。
導入に向くサイトタイプ
WP Mayorのレビューでは、ブロガー、複数サイトを監査するエージェンシー、構造化データを追加したいローカルビジネスにとって最も価値があると評価されている。一方、同レビューは成熟したSEOスタックを導入済みの場合やAI引用の保証を求める場合、複数ある判断材料の1つとして扱うのが現実的だとしている。確立されたリーダーというより、形成途中のカテゴリに登場した有望な初期段階の製品という位置づけだ。
この記事のポイント
- ByTheWeb GEOは無料でAI可読性スコア、llms.txt、スキーマ、従来SEOを管理する
- ByTheWeb AIは任意のクレジット制アシスタントで、不足フィールドを自動生成する
- 新規アカウントには30日間有効の5,000クレジットが付与される
- Yoast SEOやRank Mathと併用でき、GEOスコアとスキーマは有効なまま残る
- AI生成を実行するとページ内容がクラウドを経由するため、プライバシー確認が必要だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
TikTok ShopがEUと英国の越境販売を開始、9月21日から段階展開
TikTok ShopがEU加盟8カ国と英国の間で越境販売を開始する。出品者は自国の外にいる消費者へ直接商品を届けられるようになる。9月21日のパイロット運用を経て、10月19日に本格展開へ移行する流れだ。
越境ECの選択肢が増えることで、中小規模の事業者にも新たな販路が開ける。英国市場では30万以上の小規模事業者がTikTok Shopを利用している。EU側の出品者にとって英国市場へのアクセスは魅力的な拡張機会になるだろう。
本記事では越境販売の仕組み、販売条件、EC事業者への影響を解説する。特にWooCommerceで自社ECを運営する事業者にとっての意味合いも掘り下げる。
TikTok Shopの越境販売、全体像
このデモでは双方向の越境販売フローを示した。9月21日と10月19日の2段階展開がポイントである。EU側と英国側で販売条件が異なる点は後述する。
TikTok Shopは欧州での展開を急速に進めている。6月中旬にはオーストリア、ベルギー、オランダ、ポーランドに進出した。同時に「Sell Across Europe」プログラムを始動し、欧州12カ国をカバーする汎欧州市場へと進化している。今回の越境販売は、この汎欧州市場を英国へ拡張する動きの一環だ。
EU8カ国から英国への販売
対象となるのはベルギー、ドイツ、フランス、アイルランド、イタリア、オランダ、ポーランド、スペインの8カ国だ。まず9月21日に選ばれたEU出品者向けパイロットが始まる。その後10月19日に本格展開に移る。英国ではTikTok Shopが約5年間運営されており、30万以上の小規模事業者が利用する成熟市場だ。
英国からEU12カ国への販売
一方、英国の出品者は欧州大陸の12カ国に販売できるようになる。対象国はSell Across Europeネットワークに参加している国々だ。対象かどうかは、出品者の現在のアカウント状態とパフォーマンスをリアルタイムで評価して決まる。
EC事業者が知るべき販売条件
越境販売に参加するには、いくつかの条件を満たす必要がある。特に英国向け販売では配送方式が重要になる。
Ship by Seller方式の詳細
英国向け販売で使える配送オプションは「Ship by Seller」のみである。これは出品者が自ら配送業者を選び、配送料を支払い、配送トラブルが起きた場合も顧客対応を行う方式だ。TikTok Shop公式の説明でも「配送業者を選び、配送料を支払い、配送がうまくいかなかった場合の顧客対応も行う」とされている。日本で言えば、マーケットプレイスではなく自社発送に近い形態である。フルフィルメントをTikTok側が代行するわけではないため、越境配送の手配とコスト管理は出品者自身の責任になる。
この3ステップがShip by Seller方式の全体像だ。配送業者の選択から顧客対応まで、出品者側に責任が集中する。越境販売では関税や返品対応も加わるため、国内発送以上に準備が求められる。
販売対象になるための要件
越境販売の対象になるには、次の要件を満たす必要がある。対象EU市場でTikTok Shopにすでにアクティブであること、アカウントが良好な状態であること、最近の販売実績があること、大きな未払い残高がないこと。英国からEUへの販売では、リアルタイムのアカウント評価が対象判断に使われる。
4つの要件を色分けして示した。英国からEUへの販売は、これらに加えてリアルタイムのパフォーマンス評価が使われる。出品者側は日頃からアカウント状態を良好に保つことが前提になる。
越境ECとしてのTikTok Shopの戦略的意味
TikTok Shopの越境販売は、欧州市場を一つの商圏として統合する動きだ。従来のECモールは国ごとにアカウントや出品設定が必要だったが、Sell Across Europeと英国への拡張により、一つのアカウントで複数国にリーチできるようになる。特に英国市場は購買力が高く、EU側の事業者にとって有望な販売先である。越境ECの障壁だった言語や通貨、配送の問題をTikTokがどこまで解決できるかが、今後の成長を左右する。
本サイトの見方として、TikTok Shopの越境販売はソーシャルコマースの越境展開という新しい段階に入ったことを示す。InstagramやFacebookと異なり、TikTokのショート動画とECが一体になった体験が、国境を越えた購入を後押しする可能性がある。一方で、Ship by Seller方式による出品者負担の配送は、越境ならではの関税や返品対応の複雑さを考慮すると、小規模事業者にとっては高いハードルになり得る。ここが普及の鍵になるだろう。
WooCommerce事業者への示唆
WooCommerceで自社ECを運営する事業者にとって、TikTok Shopの越境販売は販路拡大の新たな選択肢になる。自社ECサイトを持ちながら、TikTok Shopをフロントエンドの集客チャネルとして使う形だ。商品データの同期や注文管理の連携ができれば、在庫管理を一元化しながら越境販売を試せる。現時点では公式なプラグインによる深い統合は限定的だが、今後のAPI公開や連携強化に注目したい。まずは自社の商品が越境販売に適しているか、配送コストと販売価格のバランスを見極めることを推奨する。
EC制作の現場から見ると、越境販売への対応はテーマやカートの複数通貨対応、配送業者との連携、関税計算など、技術的な準備が増える。TikTok Shopのようなプラットフォームを活用すれば、これらの複雑さを一部肩代わりできる。WooCommerce事業者は「自社ECで深く最適化する」か「プラットフォームで手早く展開する」かの使い分けが重要になる。
この記事のポイント
- TikTok ShopがEU8カ国と英国の間で越境販売を開始する
- 9月21日にパイロット、10月19日に本格展開へ移行する
- 英国向け販売はShip by Seller方式のみで、出品者が配送の全責任を負う
- 販売対象にはEU市場でのアクティブな実績と良好なアカウント状態が求められる
- WooCommerce事業者は自社ECとの併用で越境販売の機会を探れる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
42モデル比較で判明！AIモデル選択がもたらす推論コスト86倍差の実態
Neonが42のAIモデルを対象に、サポートチケット100件の処理コストと品質を同時検証した。結果として、同じタスクでもモデル選択だけで単位作業あたりの推論コストが約86倍変わる実態が明らかになった。
実験では合成サポートチケットを各モデルに処理させ、合計コスト・合格率・処理時間の3軸でスコアを付けた。最安のGPT-5 Nanoは3分程度で処理を終え、コストパフォーマンスで突出した。一方、最高額のGPT-5.5 Proは100件の処理に8.34ドル、57分を要した。
AIエージェントが企業で本格稼働する時代、モデル選びはもはや精度だけで決める時代ではない。トークン消費量と推論コストを意識したトークンエコノミクスの視点が不可欠になる。この記事ではNeonの公開ベンチマークを基に、主要な発見とコスト試算を解説する。
AIエージェント時代に浮上するトークンエコノミクス
トークンとは、LLM（大規模言語モデル）がテキストを処理する際の最小単位だ。英語でおおよそ4文字、日本語では1文字から数文字が1トークンに相当する。AIのAPI料金はこのトークン数に応じて決まるため、同じタスクでもモデルによってトークン消費量が大きく異なる。
Neonの検証によると、エージェントが企業で担う業務が増えるほど、トークン消費は人件費に次ぐコスト項目に成長する見込みだ。Neonはこのコスト管理の概念を「トークンエコノミクス」と呼び、モデル選定の重要性を強調している。ソフトウェア企業ではエンジニアがコーディングエージェントを日常的に使うため、モデルの効率差がそのまま大きな費用差として顕在化する。
Neonの見解では、大企業ほどこの差は深刻になる。数百人のエンジニアを抱える企業では、月間の推論コスト差が数十万円から数百万円規模に達する。モデル選びを「カタログ価格だけで判断する」ことは、もはや現実的な選択ではなくなっている。
42モデルを同一タスクで検証した実験設計
サポートチケット100件という選定理由
Neonのチームは「現実世界の雑多な状況を反映する」タスクとして、合成サポートチケット100件の返信を各モデルに依頼した。チケットは請求、製品質問、セキュリティインシデント、アカウントアクセス、返金の5つのシナリオを持つ。それぞれに顧客のトーンが5種類（直接表現、緊急、不満、次のステップ要求、非技術者向け）用意され、合計20シナリオを構成する。
各モデルには同じシステムプロンプトとJSONレスポンス形式、アカウントコンテキスト、ポリシー注記が渡された。この設計により、モデル間で条件を完全に揃えたうえで、コストと品質を比較できる。
7項目の合格基準
Neonは「使える回答」と「使えない回答」を区別するため、7つのチェック項目を設定した。JSONが必須4フィールドで正しくパースできること、分類が期待カテゴリと一致すること、選択アクションがポリシーで許可されていること、エスカレーション判断が正しいこと、顧客返信が1語から120語であること、必須ポリシー用語が含まれること、禁止された約束や主張がないこと、である。
例えば請求系チケットでは「請求書を説明しstorageに言及する」ことが合格条件になり、勝手にクレジットを発行すると不合格になる。セキュリティ系では「適切にエスカレーションする」行動が必須で、「心配いりません」と返すだけでは失敗扱いだ。この基準が、LLMの単なる応答速度や流暢さではなく、実務で使える精度を測る分離線になっている。
実験は合成サポートチケットを使い、全モデルに同一条件でタスクを実行させた。合計コストと合格率、処理時間をそれぞれ計測している。
Neonブランチを活用した技術設計
ベンチマークの実行基盤にはNeonのブランチ機能が用いられた。ブランチとは、DB環境をgitブランチのように瞬間的に複製する仕組みだ。モデルごとに1つのNeonブランチを作成し、それぞれに専用のAI Gatewayホストを割り当てることで、モデルとエンドポイントの対応を明確に保った。
neon branches create \
--project-id "$PROJECT_ID" \
--parent "$PARENT_BRANCH" \
--name "model-gpt-5-nano" \
--no-compute--no-compute フラグは不要なPostgresコンピュートを起動せず、AI Gatewayのエンドポイントだけを使うための指定だ。各ブランチにはAI Gatewayホストが自動で付与され、mainブランチで作成したクレデンシャルが子ブランチにも適用される。これにより、42モデル分のインフラを極めて低コストで構築できた。
データ層はLakebase Postgresが担い、ベンチマーク実行記録、モデルスナップショット、推論結果を管理する。WebアプリはNext.js 15、React 19、TypeScriptで構築され、Rechartsで可視化、Tailwind CSSでスタイリング、Zodでスキーマ検証を行った。自動化はGitHub Actionsが担い、Vercelにデプロイされる。集計結果はJSONスナップショットとしてもコミットされ、レビュー可能な形で公開されている。
ベンチマークが明らかにした主要な結果
コストと合格率の対照的な顔ぶれ
Neonの検証で最安を記録したのはGPT-5 Nanoだった。単位あたりの使用可能コストが全モデル中最も低く、処理時間も約3分と高速だった。コストと速度を両立する「バランス型」と言える。最速はLlama 3.1 8B Instructで1分18秒だったが、合格率は100件中34件と低く、速度だけで判断すると実務には耐えない。
一方、最高額はGPT-5.5 Proで、100件の処理に8.34ドルかかり、所要時間も57分と群を抜いて遅かった。トークンを最も消費したのはQwen3.5 122B-A10Bで、合格率も100件中35件と振るわない。合格率の最高はGPT-5.3 Codexで、100件中82件を一発合格した。
主要な結果はコストと合格率の両面で性格が異なる。消費トークンはQwen3.5 122B-A10Bが最多で、合格は100件中35件にとどまった。この組み合わせは「カタログ価格が低くても実際のユニットコストは高い」というトークンエコノミクスの落とし穴をよく示す。
更新で追加された新モデル
Neonは初期公開後に3モデルを追加し、ベンチマークは45モデルに拡大された。GPT-6 Astra、Claude Fable 5.1、GLM-5.3 Flashである。主要ランキングに大きな変動はなかったが、GPT-6 Astraは100件中67件合格で45モデル中28位、コストは45モデル中40位と、話題の水準からは控えめな結果だった。
モデル選択で推論コストが86倍変わる
GPT-5.6 SolとClaude Fable 5の直接比較
NeonはOpenAIとAnthropicの現行フラッグシップ同士も直接比較した。合格率はGPT-5.6 Solが69件、Claude Fable 5が68件とほぼ互角だった。しかしコストはSolが34,663トークンで0.535ドル、Fableが57,010トークンで1.59ドルと、単位あたり約3倍の差がついた。所要時間もFableが2.3倍長い。
GPT-5.6 SolとClaude Fable 5は合格率でほぼ並んだが、単位作業あたりのコストではSolが3倍優位という結果になった。モデル選定で精度以外の要素が重要な理由がここにある。
企業規模別のコスト試算
Neonはこの結果を現実の企業規模に当てはめた。エンジニア1人が1日あたり100万トークンのエージェントタスクを1件実行する前提で、月間トークン消費を推計した。入力8割、出力2割、キャッシュや割引なしという保守的条件だ。
その結果、モデルにLlama 3.1 8B Instruct（3番目に安い）を選ぶか、Claude Fable 5（3番目に高い）を選ぶかで、50人のエンジニア規模なら月間1万8千ドルの差が生まれた。500人規模なら18万8千ドル、つまり約86倍の価格差になる。同じ仕事を同じ精度でこなすなら、この差は純粋な利益になる。
ただしNeonはこの試算を「モデル選びだけの話ではない」と補足する。合格率や処理時間、出力品質も含めた総合評価が必要で、単純に安いモデルを選ぶことが正解とは限らないことを認めている。あくまで「選択が巨大なコスト差を生む」という示唆が核心だ。
オープンウェイトとプロプライエタリの比較
中央値で見たコスト差
オープンウェイトモデルとは、モデルの重みが公開されて誰でも検証・再利用できるタイプを指す。一方、プロプライエタリモデルは重みが非公開で、API経由でのみ利用できる。Neonのベンチマークでは、オープンウェイトモデル11種のコスト中央値が約0.022ドル、プロプライエタリ31種の中央値が約0.281ドルだった。約12.7倍の開きがある。
合格率の中央値はプロプライエタリが69%、オープンウェイトが61%だった。この差は比較的小さく、用途次第ではオープンウェイトの選択が現実的になる場面が多い。使用可能トークンあたりのトークン数も、オープンウェイトが552個（中央値）、プロプライエタリが925個だった。
個別モデルのばらつき
ただし中央値だけ見ると危険だとNeonは警告する。Llama 3.1 8B Instructは高速で安価だが合格率が最低レベル、Qwen3.5 122B-A10Bはカタログ価格が低いのにトークン消費が最多、Gemma 3 12Bは低コストと合格率64%を両立した。個別の特性がまちまちなため、一律に「オープンウェイトが安い」と決めつけるのは誤りだ。
このばらつきこそが、Neonが公開したインタラクティブなベンチマークの価値だ。モデルのカタログ価格ではなく、実際のワークロードで何が起きるかを自分の目で確認できる。Neonはこのベンチマークを最新モデルで継続更新する方針を示している。
この記事のポイント
- Neonが42から45のAIモデルを対象に、サポートチケット100件の処理コストと品質を同一条件で検証した
- 最安はGPT-5 Nanoで約3分で処理、最高額はGPT-5.5 Proで8.34ドル、57分を要した
- 合格率はGPT-5.3 Codexが82件で最高、Llama 3.1 8B Instructは34件で最低だった
- モデル選択だけで推論コストが約86倍変わり、500人規模なら月間18万8千ドルの差になる
- カタログ価格が安くてもトークン消費が多いモデルがあり、実測評価が重要である
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google広告テック独占訴訟で分割回避。EC事業者が知るべき影響と対策
Googleの広告テック事業をめぐる独占訴訟で、米連邦地裁は事業分割を命じず、行動制限という形で決着をつけた。裁判所はGoogleがパブリッシャー向け広告サーバーと広告エクスチェンジ市場で違法な独占を築いたと認定したものの、AdXの売却は求めなかった。
この判決は、EC事業者が日々利用しているプログラム広告のインフラに直接関わる。広告費の流れやオークションの透明性が変わる可能性があり、広告運用の見直しが必要になる場面も出てくる。
本記事では、判決の内容を整理し、EC事業者やWooCommerceサイト運営者が知っておくべき影響と対策を解説する。
判決の概要と独占認定のポイント
司法省は2023年、Googleが広告テック事業で複数の市場を支配し、競争を抑圧しているとして提訴した。2025年4月、ブリンケマ判事はGoogleがパブリッシャー向け広告サーバーと広告エクスチェンジ市場で違法な独占を築き、両製品を不当に抱き合わせたと認定した。一方、アドバタイザー向けツールでの独占は認定されなかった。
この区別は重要だ。Googleは広告主とパブリッシャーの間に位置し、パブリッシャー側の在庫管理と、その在庫を広告需要と結びつけるオークションの両方を運用している。つまり、売り手と市場の両方を支配している状態だ。
分割要求が退けられた理由
司法省はGoogleに対し、広告エクスチェンジ「AdX」の売却を要求した。しかしブリンケマ判事は、分割は困難で混乱を招く可能性が高いと判断した。判事は救済措置の審理で、誰がエクスチェンジを買うのか、買った後にどう運営するのかと疑問を呈し、違法行為を止める方が現実的な救済になると述べたという。
判決の完全な内容はまだ一部が封印されており、詳細は明らかになっていない。公開された命令では、提案された行動制限のほとんどが修正付きで受け入れられたとされている。
広告オークションのルールはどう変わるのか
裁判所は以前、Googleが「ファーストルック」と「ラストルック」という慣行を使ってAdXを有利にしていたと認定した。ファーストルックは、Googleがパブリッシャーの在庫に最初にアクセスできる仕組みだ。ラストルックは、競合の入札情報を見てから自社の入札額を決められる仕組みだった。
今回の救済措置では、これらの優位性が制限される。パブリッシャーは価格設定の自由度を高め、競合するパブリッシャー向け広告サーバーにはGoogleのAdX入札情報がリアルタイムで提供される見込みだ。
この変更により、競合する広告テック企業が在庫獲得で公平な条件で競争できるようになる。広告主にとっては、オークションのダイナミクスやサプライパス、価格設定、パブリッシャーに届く広告費の割合が徐々に変わる可能性がある。
EC事業者が知っておくべき広告費の透明性
この判決は、広告費の流れを可視化する重要性を高めている。特にEC事業者は、Googleショッピング広告やディスプレイ広告を通じて商品を宣伝する。広告費がどの経路を通り、どれだけパブリッシャーに届くのかを理解することが、投資対効果の改善につながる。
Googleは依然として広告テックの主要インフラを所有している。行動制限は一部の優位性を取り除くが、パブリッシャーと広告主はGoogleが独占を維持してきたシステムの中で運用を続けることになる。
上図の通り、Googleはパブリッシャー向け広告サーバーとエクスチェンジの両方を所有している。このため、広告主が支払った金額の一部が中間レイヤーで差し引かれ、パブリッシャーに届くまでに目減りしやすい構造だ。判決後のルール変更がこの構造をどこまで変えられるかが焦点になる。
今後の広告運用にどう備えるか
短期的には大きな変化はない
マーケターは来週からプログラム広告キャンペーンが劇的に変わるとは考えない方がよい。オープンウェブ広告の成長はすでに鈍化しており、YouTubeやInstagram、Amazonなどへの支出シフトが進んでいる。Appleのプライバシー変更によるモバイルトラッキング制限もこの流れを加速させた。
それでも、判決はサプライパスの透明性をより重要にする。マーケターは自社の広告費がどのエクスチェンジや中間業者を経由しているか、各広告費のうちどれだけがパブリッシャーに届いているか、Googleのスタック以外の選択肢が現実的になってきたかを注視する必要がある。
サプライパスの見直しと代替手段の検討
EC事業者にとって具体的な対策は、広告配信のログやレポートを定期的に確認し、中間マージンが過大な経路を特定することだ。Googleの広告テック以外にも、競合するエクスチェンジやパブリッシャー向けサーバーが存在する。判決後の環境変化を見極めつつ、複数の選択肢をテストすることが推奨される。
MarTechの記事では、行動制限は「実験」にすぎず、競合がこの機会を利用してGoogleから大きなシェアを奪えなければ独占は続くと指摘している。つまり、他の事業者がGoogleの支配に対抗できるかどうかが、今後の市場の行方を左右する。
この記事のポイント
- Googleは広告テック独占で違法認定されたが、AdXの売却は命じられず、行動制限のみが課された
- ファーストルックとラストルックの制限により、競合広告テックが公平に競争できる可能性が出てきた
- EC事業者は広告費のサプライパスを可視化し、中間マージンの過大な経路を特定することが重要
- 短期的に広告運用が激変することはないが、代替手段のテストと環境変化の注視が推奨される
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に
WooCommerceのコードベースで長年使われてきた「マジックストリング」が、人知れず問題を引き起こしていた。注文ステータス、商品タイプ、在庫状態、税金モード。これらの重要な値が、コード中で生の文字列として比較されていたのだ。タイプミス一つでバグになり、プレフィックスの有無で混乱し、コード検索でノイズが大量に混ざる。開発者にとって頭の痛い状況だった。
WooCommerceはこの問題に対処するため、Automattic\WooCommerce\Enumsという名前空間にエナムクラス群を導入した。注文ステータスや商品タイプを表す名前付き定数をパブリックAPIとして公開し、拡張機能開発者に採用を促している。本記事では、この変更の背景、利用可能なクラス、実際の導入方法を整理する。
マジックストリングがもたらす4つの問題
WooCommerceは歴史が長い。そのため、注文ステータスや商品タイプといった重要な値が、PHPの近代的な慣習が生まれる前から存在している。コードベースの各所で、次のような生の文字列比較が行われてきた。
if ( 'completed' === $order->get_status() ) {
// タイプミスがないことを祈るしかない
}この書き方は一見シンプルに見えるが、WooCommerceのような大規模なコードベースでは深刻な代償を伴う。Developer WooCommerce Blogの記事では、その問題を4つの観点から説明している。
沈黙のエラー
文字列リテラルの最大のリスクは、タイプミスが静かに潜むことだ。'complete'と書くべきところを'completed'と書いても、リンターもオートローダーもテストもエラーを検出しない場合がある。コードは実行時に黙って失敗し、デバッグに時間を奪われる。
プレフィックスの有無による混乱
WordPressのデータベースでは、注文ステータスにwc-というプレフィックスが付く。データベースにはwc-completedとして保存されるが、WooCommerceの多くのAPIはプレフィックスなしのcompletedを期待する。この違いは、開発者が実際にコードを動かして初めて気づく類の落とし穴だ。
検索の非効率さとドキュメントの分散
エージェントやコード検索で'simple'という文字列を探すと、商品タイプのロジックを探しているのに無関係な箇所が大量にヒットする。一方、ProductType::SIMPLEのように名前付き定数で検索すれば、該当箇所を正確に絞り込める。さらに、on-holdのようなステータスの定義は、宣言箇所のdocblockにドキュメントとして残せるようになる。
この比較で示したように、エナムクラスは文字列リテラルが抱える問題を構造的に解決する。特に、プレフィックス有無の違いを別々のクラスに分けることで、意図を明確に伝えられる点が重要だ。
ネイティブPHPエナムを採用しなかった理由
PHPにはバージョン8.1からネイティブのエナム型が導入されている。しかしWooCommerceはこの選択肢を取らなかった。主に2つの理由がある。
PHP 7.4のサポート
WooCommerceの最低サポートPHPバージョンは7.4だ。このバージョンにはネイティブエナムが存在しない。PHP 8.1を前提にすると、多くのユーザーを切り捨てることになる。クラス定数として文字列を定義する方式なら、PHP 7.4でも問題なく動作する。
文字列互換性という設計判断
もう一つの理由はアーキテクチャ上の判断だ。注文ステータスや商品タイプの値は、すでに数百万のデータベースにプレーンな文字列として保存されている。数千の拡張機能もその形式を前提にしている。ネイティブPHPエナムを使うと値がオブジェクトに変換され、既存のコードが壊れる可能性がある。
文字列定数を使う方式なら、OrderStatus::COMPLETEDは従来の'completed'と同じ文字列を生成する。開発者はより明確な名前を使いつつ、WooCommerceの動作を変えない。既存コードが動き続け、拡張機能は準備ができた時点で新しい定数に移行できる。
final class OrderStatus {
/**
* 注文が完了した状態
*/
public const COMPLETED = 'completed';
// ...
}このコードが示すように、エナムクラスはfinalで宣言され、public constとして定数を公開する。docblockで各定数の意味をドキュメント化できるのが利点だ。クラスを継承させないことで、APIの一貫性を保つ。
利用可能なエナムクラス
現在WooCommerceのsrc/Enumsディレクトリには、4つのカテゴリにまたがるエナムクラスが用意されている。各クラスの一覧を確認しよう。
注文と商品のエナム
OrderStatus（プレフィックスなしの値。例としてcompleted）OrderInternalStatus（データベースに保存されるwc-プレフィックス付きの値）OrderItemType（注文アイテムのタイプ）ProductType（商品タイプ。例としてsimple）ProductStatus（商品ステータス）ProductStockStatus（在庫状態）ProductTaxStatus（税金状態）CatalogVisibility（カタログの表示設定）
支払いと設定値のエナム
PaymentGatewayFeature（ゲートウェイがsupports配列で宣言する文字列）WeightUnit（重量単位）DimensionUnit（寸法単位）CurrencyPosition（通貨位置）TaxBasedOn（課税基準）TaxDisplayMode（税表示モード）DefaultCustomerAddress（デフォルト顧客住所）StockDisplayFormat（在庫表示形式）CatalogSortOrder（カタログ並び順）
各クラスの完全な一覧は、WooCommerceのGitHubリポジトリにあるsrc/EnumsディレクトリとREADMEで確認できる。このディレクトリが権威ある情報源として公開されている。
以上の4カテゴリが、現在WooCommerceで利用可能なエナムクラスの全体像だ。注文関連と商品関連が特に充実している。
拡張機能での採用方法
エナムクラスは公的に発見可能なAPIとして設計されており、publicの可視性、docblock、開発者向けドキュメントを備えている。拡張機能開発者は安心して利用できる。
基本的な使い方
使い方はシンプルだ。use文で必要なクラスをインポートし、定数を参照する。例えば注文ステータスをチェックする場合、次のように書ける。
use Automattic\WooCommerce\Enums\OrderStatus;
use Automattic\WooCommerce\Enums\ProductType;
if ( OrderStatus::COMPLETED === $order->get_status() ) {
// 注文が完了した場合の処理
}
$products = wc_get_products( array( 'type' => ProductType::SIMPLE ) );採用前に確認すべき2つのポイント
エナムクラスを拡張機能に導入する前に、確認しておくべきことが2つある。
1. 最小サポートWooCommerceバージョン。エナムクラスは段階的に追加されてきた。OrderStatusはWooCommerce 9.5で導入され、商品関連クラスは9.7〜9.8頃、設定値クラスは10.xシリーズで追加された。古いバージョンもサポートする場合は、文字列リテラルを使い続けるか、class_exists()でガードする必要がある。
2. WooCommerceが期待する文字列。OrderStatus::COMPLETEDはcompletedを返すが、OrderInternalStatus::COMPLETEDはwc-completedを返す。ほとんどのWooCommerce関数はプレフィックスなしの形式を取るが、データベースレベルやpost_statusコンテキストではプレフィックス付きを使う必要がある。どちらの形式を使うべきかを意識するのが重要だ。
商品検索と注文検索の公式ドキュメントには、文字列リテラルとエナムクラスの両方の形式が併記されている。移行時の参考になる。
このデモで示したように、2つの定数は同じ注文完了状態を表すが、使用するコンテキストが異なる。混同すると期待通りに動作しない。
今後の展開
Developer WooCommerce Blogの記事によれば、コアに新しい語彙（文字列値の集合）を追加する場合、エナムクラスをデフォルトで付ける方針が示されている。WooCommerceコアにはまだ名前の付いていない文字列値が多数残っており、コミュニティからの貢献も歓迎している。
この変更は拡張機能開発者にとって歓迎すべき動きだ。タイプミスのリスクが減り、コードの意図が読みやすくなり、IDEの補完機能も効きやすくなる。長期的にはWooCommerceエコシステム全体のコード品質向上につながる。
一方で、移行には段階的な対応が必要だ。既存の拡張機能は古いWooCommerceバージョンとの互換性を維持しながら、徐々にエナムクラスへ移行していくことになる。一括で全置換するのではなく、新規コードから採用していくのが現実的なアプローチだろう。
この記事のポイント
- WooCommerceがマジックストリング（生の文字列リテラル）をエナムクラスに置き換える動きを進めている
- エナムクラスはタイプミス防止、プレフィックス区別、検索精度向上、ドキュメント統合の4つの利点を持つ
- ネイティブPHPエナムではなく文字列定数クラスを採用した理由は、PHP 7.4互換性と既存データベースの文字列互換性
- 注文・商品・支払い・設定値の4カテゴリにエナムクラスが用意されている
- 採用時は最小サポートWooCommerceバージョンと、プレフィックス有無のどちらの定数を使うかを確認する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
CSS random()関数を全ブラウザで動かす。polyfillの仕組みと活用法
CSSのrandom()関数がSafariで先行実装されてから約半年。ChromeやFirefoxではまだ使えないが、そのギャップを埋めるpolyfillがnpmで公開された。この記事ではrandom()の基本構文からpolyfillの仕組みまでを解説する。
random()は要素のサイズや色、配置などをランダムに決めるCSS関数だ。これまでJavaScriptで行っていた演出を宣言的に書けるため、紙吹雪や星野のようなビジュアルエフェクトを純粋なCSSで実現できる。
ただし現時点ではSafariでしかネイティブ動作しない。そこで役立つのが、CSS-Tricksの著者が開発したcss-random-polyfillだ。この記事ではその使い方と内部動作をデモ付きで紹介する。
CSSのrandom()関数とは？Safariが先行対応した新機能
CSS Values and Units Module Level 5のエディタードラフトで定義されているrandom()関数は、calc()やmin()と同じように、プロパティの値の一部として利用できる。乱数を生成して、要素のサイズや色、角度、アニメーションの遅延時間などをランダムに設定できるのが特徴だ。
2025年後半、Safari 26.2で最初にサポートされた。WebKitチームは「一般的なユースケースをHTMLとCSSだけで解決できるようにする」という方針を掲げており、JavaScriptやサードパーティフレームワークへの依存を減らす狙いがある。
random()の基本構文
random()関数は最小値と最大値を指定する。オプションで第3引数にステップ間隔を指定できる。たとえば以下のコードは、1pxから7pxの間で1px刻みのランダムな値を生成する。
--random-star-size: random(1px, 7px, 1px);このように、random()はcalc()と同じく値の一部として使える。ステップ間隔を指定すると、指定した範囲内の離散的な値（この例では1px、2px、3px…7px）だけが選ばれる。
キャッシュとキーの概念
random()には値のキャッシュを制御する仕組みがある。element-sharedやfixedなどのベース値を指定すると、同じ値を複数の要素やプロパティで共有できる。たとえば、以下のコードでは4つの尖った星すべてに同じ乱数を適用する。
.star.fourpointed {
--random-rotation: random(element-shared, -45deg, 45deg);
rotate: var(--random-rotation);
}element-sharedを指定すると、同じ要素に適用されるrandom()呼び出しが同じ結果を返す。これにより、複数の要素で共通のランダム値を保つことができる。
他ブラウザで使うためのpolyfillが登場
Safariが先行したrandom()だが、ChromeとFirefoxでも開発の兆しはあるものの、正式リリースの時期は未定だ。Chromeには関連する課題が報告されており、Firefoxもバグジラで進捗が追跡されている。ただし、フラグ付きでさえ使える状態にはなっていない。
この状況を受けて、CSS-Tricksの著者がcss-random-polyfillというnpmパッケージを公開した。このpolyfillを使うと、Safari以外のブラウザでもrandom()関数を利用できる。polyfillはネイティブサポートを検出し、未対応ブラウザでのみ動作する設計だ。
polyfillの使い方
polyfillを利用するには、HTMLのhead内にスクリプトを読み込み、ランダムにしたい要素にrandomizedクラスを追加する。CSSでは--randomで始まるカスタムプロパティにrandom()関数の値を格納する。
<script src="https://unpkg.com/css-random-polyfill@latest/dist/css-random-polyfill.js"></script>
<div class="randomized star"></div>
<div class="randomized star fourpointed"></div>/* CSS */
.star {
--random-star-size: random(1px, 7px, 1px);
width: var(--random-star-size);
aspect-ratio: 1/1;
/* その他のプロパティ */
}randomized クラスを一時的に非表示にする--random で始まるプロパティを探して乱数を計算するpolyfillの処理はシンプルで、ネイティブサポートがある場合は何もせず、未対応の場合のみJavaScriptで乱数を計算してインラインスタイルに反映する。randomizedクラスを付けた要素だけが対象になるため、ページ全体のパフォーマンスへの影響は最小限に抑えられる。
実践デモで見るrandom()の活用例
polyfillの動作を確認するために、いくつかのデモが用意されている。ここでは代表的な例を紹介する。
ランダムな正方形デモ
最もシンプルな例として、ランダムな色とサイズの正方形を3つ配置するデモがある。CSSではrandom()を使ってカスタムプロパティを定義し、それを幅や高さ、背景色に反映する。
/* ランダムなサイズを共有する例 */
--random-height: random(--side, 40px, 100px);
--random-width: random(--side, 40px, 100px);
width: var(--random-height);
height: var(--random-width);--random-heightと--random-widthにカスタムキー--sideを指定することで、幅と高さが同じ乱数を共有する。これにより正方形の形状を保ったままサイズだけがランダムに変化する。
星野デモと運命の車輪
より視覚的な例として、ランダムに散らばる星野デモや、回転角度がランダムになる運命の車輪デモも公開されている。星野デモでは200個の星がランダムな位置に配置され、それぞれ異なるタイミングで明滅する。
運命の車輪デモでは、回転角度をrandom(2turn, 10turn, 20deg)のように指定している。最小値と最大値はturn単位、ステップはdeg単位という異なる単位の組み合わせも可能だ。これはcalc()と同じく、同じデータ型に解決できる単位同士であれば混在できるためだ。
@keyframes spin {
from {
rotate: 0deg;
}
to {
rotate: var(--random-rotation);
}
}
#wheel {
--random-rotation: random(2turn, 10turn, 20deg);
}このコードでは、車輪が2回転から10回転の間でランダムな角度だけ回転する。ステップ間隔が20度なので、結果は20度刻みの値になる。random()を使うことで、ユーザーがページを開くたびに異なる結果になる。
polyfillの内部動作を理解する
このpolyfillは独自のCSSパーサーを実装しておらず、既存のオープンソースライブラリを利用している。具体的には、PostCSSプラグインとして知られる@csstools/css-calcの内部実装を活用している。このライブラリはCSSのcalc()関数を計算するために作られたもので、依存関係がなく、random()の最新仕様にも対応済みだ。
カスタムプロパティの許容性を活用
polyfillの鍵となるのは、CSSカスタムプロパティの値が「非常に許容度が高い」という仕様だ。ブラウザがrandom()関数を理解できなくても、カスタムプロパティの値としては文字列として保持される。たとえば以下のような式は、未対応ブラウザでもエラーにならず、JavaScriptから読み出せる。
/* ブラウザが解釈できなくてもエラーにならない */
--random-grid-area: random(1, var(--rows), 1) / random(1, var(--columns), 1);ブラウザはvar()参照を解決してから値を文字列として保持するため、polyfillはgetComputedStyle()で値を読み取り、乱数を計算してインラインスタイルとして書き戻す。この手法は、スタイルシートを書き換えたり再取得したりする必要がないため、従来のCSS polyfillにありがちな副作用を回避できる。
処理の流れ
polyfillの動作は以下のJavaScriptコードに要約されている。ネイティブサポートを判定し、未対応の場合のみ--randomプレフィックスの付いたプロパティを収集して乱数を計算する。
import { calc } from "@csstools/css-calc";
const calcFn = calc;
if (!CSS.supports("width", "random(0px, 100px)")) {
// 要素を一時的に非表示にしてフリッカーを防ぐ
// --random プレフィックスのプロパティを収集
// @csstools/css-calc で乱数を計算
// インラインスタイルに反映
}注意点として、random()のキャッシュ制御に関わる部分がある。仕様ではelement-sharedやfixedなどのベース値を指定できるが、未指定の場合にライブラリが均等な分布で乱数を生成しないことがある。この問題を回避するため、polyfillでは乱数値を明示的に注入するパッチを適用している。
random-item()を模倣する実験と今後の展望
CSS Values and Units Module Level 5には、random()と似たrandom-item()という関数が定義されている。これは与えられたリストからランダムに1つの値を選ぶ関数だ。しかし、現時点ではどのブラウザも実装していない。
Chromiumベースのブラウザでは、CSSカスタム関数とインライン条件分岐を組み合わせることで、random-item()に近い機能を実現できる。たとえば、以下のコードはリストからランダムに1つの色を選ぶ。
--random-index: random(element-shared, 1, 5, 1);
--random-color: --item(var(--random-index), aqua, purple, pink, grey, green);これを実現するカスタム関数--itemは、インデックス番号に応じて対応する引数を返す。CSSカスタム関数は可変長引数をサポートしないため、事前に想定される最大数だけ引数を定義しておく必要がある。
@function --item(--index,
--arg-1: ,
--arg-2: ,
--arg-3: ,
--arg-4: ,
--arg-5: ) {
result: if(
style(--index: 1): var(--arg-1);
style(--index: 2): var(--arg-2);
style(--index: 3): var(--arg-3);
style(--index: 4): var(--arg-4);
else: var(--arg-5);
);
}この手法は、CSS-Tricksの著者が「ハックではなく、意図された標準機能の使い方」と述べている。かつてTemani Afif氏が行った色リストの実装はハックに近いものだったが、カスタム関数を使えば任意のデータ型で動作する汎用的な解決になる。ただし、CSSカスタム関数もまだすべてのブラウザで利用できるわけではないため、現時点ではChromium限定の実験的な機能だ。
この記事のポイント
- CSS
random()関数はSafariが先行対応。ChromeとFirefoxは対応時期が未定 - polyfillを使えば他ブラウザでも
random()を利用できる - 使い方は
--randomプレフィックスのカスタムプロパティとrandomizedクラスを設定するだけ - polyfillはカスタムプロパティの許容性を利用し、
@csstools/css-calcで乱数を計算する - Chromiumではカスタム関数と組み合わせて
random-item()を模倣可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験