「守る」から「見分ける」へ ── Cloudflare Precursor GAが変えるbot対策と、WEBディレクターが今週確認すべき3点

2026年7月13日、Cloudflareが新しいbot対策エンジン「Precursor」の一般提供(GA)を発表した。サンフランシスコ発のプレスリリースが謳うのは、「継続的行動検証」というこれまでのbot対策とは根本的に異なる仕組みだ。静的CAPTCHAでもJS実行チェックでもない。訪問者がページに滞在している間、ずっと「その動きは人間らしいか」を見続けるエンジンである。

この記事のもう一つの主役は、archives/103で当サイトが扱ったWebMCP・UCP(Universal Commerce Protocol)の話だ。Googleがこの仕組みを発表したのが2026年7月10日、当サイトがそれを追いかけて「検索は『クリックする場所』から『エージェントが代わりに動く場所』になった」と書いたのが7月15日。そしてその発表からわずか6日後の7月16日、Google自身がAI Modeの新機能「Connected Apps」として、この土台の上に立つ実装を世に出した。今日はその両方を、正直な自己実証を添えて記録する日だ。

Precursorとは何か — ワンクリックで動く「継続的行動検証エンジン」

Cloudflareの公式プレスリリース(2026年7月13日付)によれば、Precursorは「継続的行動検証エンジン(continuous behavioral verification engine)」と位置づけられている。導入方法は極めてシンプルで、コードの修正は一切不要。Cloudflareのネットワークを通じてコンパクトな動的スクリプトが自動的に注入され、ブラウザ上で実行される仕組みだ。管理画面でのワンクリック設定のみで有効化できる。

Cloudflare CTOのDane Knecht氏はこう述べている。

"Modern bots have gotten smart enough to fake their way through the front door."
(現代のボットは、正面玄関を偽って通り抜けられるほど賢くなった)

この一文が指しているのは、単一時点の「玄関チェック」――CAPTCHAを解く、JavaScriptを実行する――だけでは、もはや高度なボットを見分けられなくなったという現実だ。Precursorが変えたのは、検証のタイミングそのものである。訪問の入口で一度だけ確認するのではなく、セッション全体を通じて継続的に行動を観察する。

今回のGA発表は、単発の新機能リリースというより、Cloudflareが2026年に入って積み重ねてきた一連の刷新の延長線上にある。archives/93で報じたSearch/Agent/Trainingの三分類刷新(7月1日)、archives/94で報じたAttribution Business Insightsによる可視化(7月2日)、archives/96で報じたPay Per Useへの課金モデル転換(7月1日)――これらはいずれも「誰が来て、何をもたらし、どう対価を得るか」という経済圏の設計だった。Precursorはこの経済圏の手前、つまり「そもそもその訪問者は何者なのか」という一次判定の精度そのものを底上げする位置づけにある。約2週間というごく短いスパンの中で、身元の分類・価値の可視化・課金モデル・行動検証という4つの発表が連続したことは、Cloudflareがbotエコノミー全体を一つの設計思想のもとで作り替えようとしている証拠と読める。

何を見ているのか — ポインタ・スクロール・タイピング・クリップボード・フォーカスの5指標

Cloudflareが公開している情報によれば、Precursorがサーバー側でリアルタイムに評価する行動シグナルは、大きく分けて5種類ある。

検証項目	何を見ているか
マウス(ポインタ)操作	ポインタの活動そのものを継続監視
スクロール	スクロールのリズムと速度を分析
タイピング	打鍵のキャデンス(周期性・間隔)を記録。実際のキーストローク内容は記録しない
クリップボード活動	コピー&ペーストの操作パターン
ページ可視性・フォーカス挙動	ページの表示時間、テキストフィールドのフォーカス状態

興味深いのは、これらの指標を個別に見るのではなく、相互の整合性(合理性)を検証している点だ。たとえば「ポインタ活動がページ可視性と一致しているか」「タイピングをしている最中に、本当にテキストフィールドがフォーカスされているか」――こうした複合的な文脈チェックによって、ページを何度リロードしてもボットの行動署名をリセットできない設計になっている。人間なら当たり前に発生する矛盾のなさが、逆にボットにとっては再現困難なハードルになる。

Help Net Security(2026年7月13日付)の報道も、この「セッション全体を監視する継続的セキュリティ」という点を核として伝えている。単発の関門ではなく、訪問という時間の流れそのものを検証対象にする発想の転換が、この技術の要だ。

この5指標を見て気づくのは、いずれも「ページを操作する」という行為そのものに紐づいている点だ。裏を返せば、ページを開いた瞬間に何も操作せず離脱する訪問者や、スクリーンショットだけを目的に一瞬で処理を終えるアクセスパターンについては、行動シグナルが極端に少なく、判定材料そのものが乏しくなる可能性がある。Cloudflareが「複合的な文脈により検出精度が段階的に向上する」と説明しているのも、この裏返しの弱点――行動データが少ない訪問ほど判定が難しい――を織り込んだ設計であることを示唆している。

行動検証は何を「見て」何を「見ない」のか — プライバシー設計の境界線

「継続的に行動を見張る」と聞くと、まず気になるのはプライバシーへの影響だろう。この点でCloudflareが明示しているのが、タイピングのキャデンス(周期性)は記録するが、実際に打鍵された文字そのものは記録しないという設計だ。パスワード入力欄で何を打っているかではなく、「打つリズムに人間らしい揺らぎがあるか」だけを見る。マウス操作についても同様で、座標の軌跡そのものではなく「ポインタ活動の有無とページ可視性との整合性」という粒度で評価している。

この設計は、生体認証のような「個人を特定する情報」ではなく、「その場に人間がいるかどうかを推定するための行動パターン」に限定している点で、フィンガープリンティング技術とは性質が異なる。とはいえ、行動データをサーバー側に送って評価する以上、EUのGDPRや日本の個人情報保護法における「行動データの取り扱い」という論点は今後も注視が必要だ。WEBディレクターとしては、Precursorのようなツールを導入する際に、自社のプライバシーポリシーに「行動検証のためにページ操作情報を収集する場合がある」旨の記載が必要かどうか、法務担当と確認しておく価値がある。

なぜ静的CAPTCHAとJS実行チェックは限界を迎えたのか

従来のbot対策の多くは、次の2つの手法のいずれか、あるいは両方に依存してきた。

• 静的CAPTCHA: 「私はロボットではありません」チェックボックスや画像選択問題。一度突破されれば、それ以降のセッションは無検証になる
• JS実行チェック: JavaScriptが正しく実行される環境かどうかを見る。現在のヘッドレスブラウザやAIエージェントの多くは本物のChromiumエンジンを積んでおり、JavaScript自体は問題なく実行できてしまう

この2つの手法は、いずれも「入口の一発勝負」という共通の弱点を持つ。CAPTCHAは画像認識AIの精度向上によって機械的に解かれるようになり、JS実行チェックはヘッドレスブラウザがPuppeteerやPlaywrightといったツールを通じて本物のブラウザエンジン(Chromium)をそのまま動かせるようになったことで、実行環境の差だけでは見分けがつかなくなった。Cloudflare自身も過去にTurnstileのような「見えないCAPTCHA」を展開してきたが、これも突き詰めれば入口での一回の判定という枠組みからは出ていない。

Cloudflareのプレスリリースが指摘するのは、まさにこの点だ。「本物のブラウザを使うbot」――つまり見た目にも技術的にも人間のブラウザと区別がつかないbotが増えたことで、入口での一発検証はほぼ無力化された。Cloudflare Radarの計測では、自動化されたボットトラフィックが人間の活動を初めて上回り、全ウェブリクエストの約57%を占めるに至っている。この数字は、当サイトが1か月前のarchives/83で報じた「ボットが世界の57.5%を占めた日」(Cloudflare CEO Matthew Prince氏、2026年6月3日発表)と、驚くほど近い水準で継続している。一過性のスパイクではなく、定着したトレンドであることが今回の一次情報で裏づけられた形だ。

「入口を固める」発想がもはや通用しないなら、残る手は「滞在中ずっと見張る」しかない。Precursorはその答えとして設計されている。

連載軸 — Cloudflareの「見分け方」三世代史、UA判定からPrecursorまで

当サイトはCloudflareのbot対策を、これまで複数のarchivesで追いかけてきた。今回のPrecursorを単発ニュースとして読むのではなく、この一連の変遷の「第3の世代」として位置づけたい。

第1世代 — UA判定とrobots.txtという自己申告制

archives/86「Cloudflareのデフォルト『AI botsブロック』があなたのGEOを殺している」で書いたのは、User-Agent文字列とrobots.txtに基づく古典的な仕分けの限界だった。robots.txtは自主規制プロトコルであり、クローラーがサーバーに到達したあとに初めて意味を持つ。一方でCloudflareのインフラ層ブロックは、リクエストがサーバーに届く前にHTTP 403で弾く。この二層の違いに加え、当サイトの調査ではSuper Bot Fight Mode(SBFM)という第5の隠れたレイヤーが、管理画面のトグルとは独立にAI botのUAを一括ブロックしていた実態も判明している。UAという「自己申告される名乗り」だけに頼る仕組みは、名乗りを偽装できる相手には無力という教訓が、この第1世代の限界だった。

第2世代 — Search/Agent/Training三分類と「Verified」の意味転換

archives/93「Cloudflareが『検証』の定義を変えた日」で扱ったのは、2026年7月1日の「Content Independence Day 2026」でCloudflareが打ち出した刷新だ。AIクローラーを目的別に「Search(検索・インデックス化、デフォルト許可)」「Agent(ユーザー代理の即時操作、デフォルトブロック)」「Training(モデル訓練用データ取得、デフォルトブロック)」の三分類に再編し、当サイトはこの新体系のもとで37体のVerified AI Agentを個別に許可リストへ登録した。ここで大きかったのは、「Verified」という言葉の意味そのものが変わったことだ。従来は「Verified=デフォルトで許可される」だったが、新定義では「そのボットが属するカテゴリの中でだけ許可対象になりうる」という限定的な意味になった。これは「誰であるか」の検証を、より細かく仕分ける方向への進化であり、まだ「身元の検証」の枠の中にとどまっている。

この第2世代の延長線上には、検知結果を可視化するarchives/94「Cloudflareが『価値』を可視化し始めた日」(BotBase・Attribution Business Insights)と、検知を経済モデルへ接続するarchives/96「Cloudflareが『稼ぎ方』を変えた日」(Pay Per CrawlからPay Per Useへ)がある。「誰が来たか」を仕分け、「どれだけの価値をもたらしたか」を可視化し、「その価値に見合う対価を求める」――この3本の記事は、身元検証を土台にした一つの経済圏の設計図として読める。

第3世代 — 「誰であるか」から「何をしているか」へ

Precursorが踏み出したのは、この土台そのものを変える一歩だ。UA判定もSearch/Agent/Training分類も、突き詰めれば「このリクエストの送り主は誰を名乗っているか」という身元の検証だった。名乗りが本物の人間のブラウザと区別のつかないbotによって偽装されるなら、身元の検証はそこで頭打ちになる。Precursorが見ているのは身元ではなく行動だ。ポインタが動いているか、スクロールにリズムがあるか、タイピング中にフィールドがフォーカスされているか――これは名乗りを偽ることはできても、行動そのものを偽ることは技術的に格段に難しい。

世代	検証対象	当サイトでの実装
第1世代	UA文字列・robots.txt(自己申告)	archives/86
第2世代	Search/Agent/Training分類・37体allow(身元の仕分け)	archives/93
第3世代	継続的行動検証(Precursor)	🔧検討中(本記事)

「誰であるか」から「何をしているか」へ――これは単なる技術のアップデートではなく、bot対策という営みの前提そのものが変わったことを意味している。

この転換は、GEO(生成エンジン最適化)やAI可視性計測を追いかけてきたWEBディレクターにとっても他人事ではない。正規のAI検索クローラー(GPTBot・ClaudeBot・PerplexityBotなど)の多くは、静的なHTTPリクエストでページを取得するだけで、ブラウザ内での操作は行わない。行動検証エンジンの目線から見れば、これは「ポインタ操作もスクロールもフォーカス挙動も一切ない訪問」であり、悪意あるヘッドレスブラウザbotの挙動パターンと機械的には見分けがつきにくい場面が出てくる可能性がある。第2世代の身元検証(Search/Agent/Training分類・Verified登録)と第3世代の行動検証は、本来は補完関係にあるべきだが、運用によっては身元は正規でも行動が「静かすぎる」ことがノイズとして扱われるリスクを、当サイトとしても注視していきたい。

【self-proof-loop技術コラム】archives/103の予言が6日で現実化した日

ここでもう一つ、記録しておきたい出来事がある。当サイトは2026年7月15日、archives/103「検索は『クリックする場所』から『エージェントが代わりに動く場所』になった」を公開した。この記事が扱ったのは、Googleが2026年7月10日に発表したWebMCP・UCP(Universal Commerce Protocol)・Universal Cartという3つの仕組みだ。記事の中核となる主張はこうだった。

「ユーザーは検索結果をクリックせず、エージェントが商品を探し、カートに入れ、決済まで完了させる」

そして実務チェックリストとして、「フォーム導線が単一ページで完結する構造か」「SearchActionで機械可読化を宣言しているか」「既存カート基盤のUCP対応状況を確認しているか」といった棚卸し項目を挙げていた。

archives/103の公開からわずか1日後――Googleが土台となる仕組みを発表した2026年7月10日から数えると6日後にあたる2026年7月16日、Google自身がAI Modeの新機能「Connected Apps」を発表した。TechCrunchとSearch Engine Landの両方が報じているとおり、米国ユーザー向けにロールアウトが始まり、ローンチパートナーはInstacart(食材購入)・Canva(デザイン作成)・YouTube Music(プレイリスト管理)の3社だ。Search Engine Landが引用するGoogle公式ブログの言葉を借りれば、「ユーザーは安全にサポート対象サービスを接続でき、Search体験内からこれらと相互作用できる」。

具体例として挙がっているのは、BBQの計画を立てながら食材リストを作成し、そのままInstacartのカートに追加してチェックアウトまで進める、というシナリオだ。まさにarchives/103が書いた「エージェントが商品を探し、カートに入れ、決済まで完了させる」という予言と、一言一句とは言わないまでも、構造として重なっている。

ここで正直に書いておきたいのは、archives/103はWebMCP・UCPという「仕組みの発表」を扱った記事であり、Connected Appsという「実装として世に出た機能」そのものを予知していたわけではないということだ。予言というより、土台となる技術発表を追いかけていたら、その延長線上の実装がすぐ後に続いた、というのがより正確な言い方になる。それでも、記事を書いた翌日にその土台の上に立つ実サービスが動き出したという時間差の近さは、当サイトが掲げるself-proof-loop――「書いたことを、自分自身の観察と実践で検証し続ける」――の実例として記録する価値がある。

なぜ同じ1週間に起きたのか — bot対策とエージェント検索、同じコインの両面

Precursor(7月13日)とConnected Apps(7月16日)は、発表元も技術領域も別々でありながら、同じ1週間のうちに世に出た。これは偶然の重なりというより、業界全体が同じ現実に押されて動いた結果と見るべきだ。その現実とは、「人間の代わりに何かを実行する存在」――botであれAIエージェントであれ――が、Webトラフィックの中で無視できない比率を占めるようになったことである。

Cloudflareの視点から見れば、この存在の増加は「防御すべき脅威」の顔をしている。archives/83で報じた57%という数字が示すとおり、ボットはもはや例外的な訪問者ではなく、人間より多くのリクエストを送る主役になっている。だからこそ、身元の名乗りだけでは足りず、行動そのものを見なければならなくなった。

一方でGoogleの視点から見れば、同じ現象は「ユーザー体験を進化させるチャンス」の顔をしている。エージェントが人間に代わって検索し、比較し、カートに入れ、決済する――archives/103が予言した世界がConnected Appsとして動き出したのは、この「代行する存在」を敵としてではなく味方として設計に組み込んだ結果だ。

つまり、Precursorは「代行する存在の中から悪意あるものを見分ける」技術であり、Connected Appsは「代行する存在を信頼して業務を任せる」機能である。同じ『代行者』という主語に対して、防御側と活用側という正反対の答えを、同じ週に業界の両端が出した――ここに今回の一次情報2本を並べて読む意味がある。WEBディレクターにとっては、どちらか一方ではなく、両方に同時に備える必要が出てきたということでもある。

WEBディレクターが今週確認すべき3点

この前提に立って、WEBディレクターが今週のうちに確認しておきたい3点を挙げる。

1. Cloudflareを使っているなら、Precursorの適用範囲と挙動を確認する

Precursorはワンクリックで有効化できる設計になっているが、正規ユーザーの操作性を損なわないかどうか、まずはtest環境やステージング環境で動作を観察したい。具体的には、以下の3点を確認しておきたい。

• 対象プランの確認: 公式プレスリリースには無料プランと有料プランの区分について明記がない。自社の契約プラン(Free/Pro/Business/Enterprise)でPrecursorがどこまで提供されるのか、Cloudflareダッシュボードまたはサポート窓口で確認する
• フォーム自動化ツールへの影響: 社内の業務効率化ツール(RPA・入力補助拡張機能など)がある場合、行動検証によって正規の自動化まで誤検知しないか、test環境で事前に動作確認する
• アクセシビリティへの配慮: スクリーンリーダーやスイッチデバイスなど、支援技術を使うユーザーの操作パターンは、一般的なマウス・キーボード操作と異なる場合がある。誤検知が起きた場合の申告・解除フローが用意されているかを確認する

実務メモ: Cloudflareダッシュボードでの一般的な確認手順は、①対象ドメインを選択 →②「Security」または「Bots」メニューを開く →③新機能・ベータ機能の一覧にPrecursorの提供有無が表示されているか確認、という流れになる。プレスリリース段階では対象プラン(Free/Pro/Business/Enterprise)の切り分けが明記されていないため、ダッシュボード上の実際の表示が最も確実な一次情報になる。

2. 「Verified」なbotであっても、行動検証の対象になりうることを前提にする

archives/93で扱った第2世代の分類(Search/Agent/Training)は、あくまで身元カテゴリの仕分けだった。Precursorのような行動検証は、この身元検証とは独立したレイヤーで動く可能性が高い。自社サイトが受け入れているAI botのアクセスパターンが、行動検証の観点から見て「人間らしくない」と判定されるリスクがないか、UAの許可リストだけでなく実際のクロール挙動もあわせて点検したい。とくに、正規のAI検索クローラー(GPTBot・ClaudeBot・PerplexityBotなど)が静的なHTTPリクエストのみを送る設計である場合、「マウス操作もスクロールも一切ない」という挙動そのものが行動検証の対象になりうる点は、身元ベースの許可リスト運用だけでは見落としやすい盲点だ。

3. Connected Apps的な「エージェント実行型」導線への準備を、棚卸しから始める

archives/103のチェックリストがそのまま活きる場面だ。今すぐUCPやWebMCPを実装する必要はないが、「自社サイトのどの機能がエージェントに代行してほしいものか」「フォーム導線は単一ページで完結しているか」を棚卸ししておくことは、Connected Appsのような実装が広がったときの初速に直結する。実装より先に、まず棚卸しから始めるという姿勢は、archives/103で示した距離の取り方と変わらない。あわせて、自社が今後Precursorのような行動検証を導入した場合に、Connected Apps経由でやってくる「正規のエージェント操作」まで誤ってブロックしてしまわないか――防御と活用が同じサイトの中で衝突しないかという視点も、今のうちに持っておきたい。

当サイトの現在地 — 正直な自己開示

self-proof-loopの原則に従い、当サイト自身の実装状況をここで開示する。

• ✅ 実施済み: Cloudflareの検知体系刷新(Search/Agent/Training三分類)への対応として、archives/93で報告したとおり37体のVerified AI Agentを個別allow登録済み。第1世代(UA/robots.txt)・第2世代(身元カテゴリ分類)への対応は完了している
• 🔧 検討中: Precursor(継続的行動検証エンジン)の導入は、現状ではまだ着手していない。対象プランやコスト影響についてCloudflareの公式プレスリリースには明記がなく、当サイトが契約しているプラン階層での提供有無・料金面を含めて評価中の段階にある。行動検証という性質上、AI Ronブログの読者(人間の訪問者)の操作性を損なわないかの検証も必要で、拙速な有効化は避けたい
• 🔧 検討中: Connected Apps的な「エージェント実行型」導線については、archives/103で棚卸しチェックリストを示した段階にとどまり、実装には至っていない

「守る側の設計思想」を掲げてきた当サイトとして、まだ実装していないことを実装したかのように書かない――この姿勢はarchives/110で改めて確認した「宣言と実装のギャップは物証で塞ぐ」という規律の延長線上にある。Precursorについても、導入したらこの記事に追記して答え合わせをする。

この「宣言と実装のギャップを埋め続ける」実践は、今回が初めてではない。archives/98で公表した宿題の答え合わせから始まり、archives/105・archives/108・archives/109・archives/110と、当サイトはself-proof-loopという一つの連載軸を積み重ねてきた。共通しているのは、「やった」と書く前に「本当にやったのか」を自分自身で検証し、まだやっていないことは正直に🔧のまま残す、という単純だが継続しにくい規律だ。本記事のPrecursorについても、同じ規律で扱う。

用語集

用語	意味
Precursor	Cloudflareが2026年7月13日にGA(一般提供)を発表した、継続的行動検証エンジン。セッション全体を通じてポインタ・スクロール・タイピング等の挙動を監視し、bot判定を行う
継続的行動検証(Continuous Behavioral Verification)	入口の一時点だけでなく、訪問セッション全体にわたって行動シグナルを観察し続ける検証方式
SBFM(Super Bot Fight Mode)	Cloudflareのbot対策機能の一つ。archives/86で扱った、「Block AI bots」トグルとは独立して動く隠れたブロックレイヤー
Verified AI Agent	Cloudflareが身元を確認し、許可リストに登録したAIボット。archives/93で解説した「Search/Agent/Training」の三分類に紐づく
WebMCP	サイトが自身の機能を「エージェントが呼び出せる構造化ツール」として宣言する仕組み。archives/103で解説
UCP(Universal Commerce Protocol)	商品発見からチェックアウトまでをエージェント経由で行うための共通言語。Googleが2026年1月11日に発表
Connected Apps	Google AI Modeの新機能。Instacart・Canva・YouTube Musicなど連携先アプリと直接やりとりし、検索結果を離れずにタスクを完了できる。2026年7月16日発表

まとめ — 「守る」から「見分ける」への転換点で

Precursorが体現しているのは、bot対策の重心が「侵入を防ぐ」ことから「この動きが本物の人間かどうかを見分け続ける」ことへ移ったという変化だ。同じ週に発表されたGoogleのConnected Appsもまた、検索の重心が「情報を探す場所」から「エージェントが代わりに動く場所」へ移ったことを示している。どちらも、人間の代理として振る舞う存在が当たり前になった世界への適応だ。

UA判定という「名乗り」の時代から、行動検証という「振る舞い」の時代へ。archives/98以来、当サイトが積み重ねてきたself-proof-loopの実践は、この転換点をただ観察するのではなく、自分自身のサイトで実際に確かめながら記録し続けることに意味がある。Precursorをどう評価し、どう向き合うかは、次のarchivesで答え合わせをしたい。

今週確認すべき3点で挙げたとおり、やるべきことは大掛かりな実装ではない。ダッシュボードを開いて提供状況を見る、身元検証と行動検証が独立したレイヤーであることを頭に入れる、エージェントに代行させたい機能を紙に書き出してみる――どれも1時間かからずに着手できる。bot対策とエージェント検索という2つの潮流が同じ週に動いた今、まず必要なのは大きな決断ではなく、小さな確認を積み重ねることだ。

【関連archives】

• archives/83 — ボットが世界の57%を占めた日(AIクローラー時代のアクセスログ)
• archives/86 — Cloudflareのデフォルト「AI botsブロック」があなたのGEOを殺している(第1世代・UA判定の限界)
• archives/93 — Cloudflareが「検証」の定義を変えた日(第2世代・37体allow)
• archives/94 — Cloudflareが「価値」を可視化し始めた日(BotBase・Attribution Business Insights)
• archives/96 — Cloudflareが「稼ぎ方」を変えた日(Pay Per CrawlからPay Per Useへ)
• archives/98 — self-proof-loopの起点(1,238記事の8割が土俵に上がっていない)
• archives/103 — 検索は「クリックする場所」から「エージェントが代わりに動く場所」になった(WebMCP・UCP)
• archives/109 — SNS投稿もGoogle検索に測れる日(Search Console「Platform Properties」)
• archives/110 — 宣言と実装のギャップは物証で塞ぐ日(self-proof-loopの実装型)

【本記事の一次情報出典】

• Cloudflare公式プレスリリース(2026年7月13日)「Cloudflare Introduces Precursor: One-Click Behavioral Defense Against Modern Bots」 — cloudflare.com/press
• Help Net Security(2026年7月13日)「Cloudflare Precursor」 — helpnetsecurity.com
• TechCrunch(2026年7月16日)「Google's AI Mode now lets you link and interact with select apps」 — techcrunch.com
• Search Engine Land(2026年7月16日、Danny Goodwin)「Google AI Mode adds Instacart, Canva and YouTube Music integrations」 — searchengineland.com