タグアーカイブ Claude

AI検索で消えるブランド、SEO上位でもAI回答に登場しない実態。Fractl調査が明かす視認性格差

AI検索で消えるブランド、SEO上位でもAI回答に登場しない実態。Fractl調査が明かす視認性格差

SEOで上位を獲得しているブランドの一部が、AIチャットの回答にはほとんど登場しない。検索エンジン向けの最適化だけでは、生成AI時代のブランド視認性を確保できないことが明らかになってきた。

Fractlの調査では、GPT-4o、Gemini 2.5 Flash、Claude Sonnet 4.6の3つのモデルに96種の業界別プロンプトを投げ、4,320件の回答と8,500件超のブランド言及を分析した。SEO指標とAI回答での言及頻度を突き合わせ、その乖離を数値化している。

この記事では、AI検索から消えつつあるブランドの特徴、逆にAIで過剰に登場するブランドの共通点、そしてブランド戦略に必要な対応を解説する。

AI回答に潜む「デフォルトブランド」の存在

調査対象の全業界に共通して、プロンプトの言い回しを変えても繰り返し登場する「デフォルトブランド」が存在した。ただし、その顔ぶれは検索エンジンの上位表示とは必ずしも一致しない。ドメイン評価が高く、大量のキーワードで上位表示されているブランドが、AI回答では自社カテゴリにすら登場しないケースが目立つ。

逆に、従来のSEO指標では目立たないブランドが、AI回答では頻繁に推奨される事例も多かった。注目すべきは、デフォルトブランドの顔ぶれが業界ごとに大きく異なる点だ。

旅行カテゴリではBooking.com(285回)、Airbnb(227回)、Expedia(215回)の3ブランドが、カテゴリ全体の言及量の約20%を占めた。3社で推奨の5分の1を握る集中度だ。保険カテゴリではLemonade(213回)がState Farm(172回)を上回り、Root Insurance(165回)がProgressive(114回)を超えた。デジタルネイティブの保険会社が先に挙げられ、従来の大手は代替案として扱われている。

ライフスタイルカテゴリでは、Patagonia、Allbirds、Eileen Fisher、Everlaneといったサステナビリティ系D2Cブランドが、SephoraやSamsung、Whirlpoolを上回った。Fractlの記事では、この傾向は第三者コンテンツで語られるブランドストーリーがAIの訓練データに強く反映された結果だと指摘している。

従来のSEO検索(Before)
大手保険ブランド Google検索1位
ドメイン評価 80以上、月間訪問数 数百万
キーワード 数十万件で上位表示
AIチャット回答(After)
デジタル保険ブランド AI回答で先に登場
大手保険ブランドは言及なし、または代替案としてのみ
従来のSEO上位  AI回答で優先  言及なし

このデモが示す通り、検索エンジンでの強さとAI回答でのプレゼンスは一致しない。AI回答内の競争集合は、検索結果ページよりはるかに小さい。自社カテゴリでAIが想起する上位5〜10ブランドに入れなければ、Googleで上位表示できていても、AIが生成する検討リストには載らない。

伝統的なSEO権威性とAIリコールの乖離

伝統的なSEO権威性とAIリコールの乖離

Fractlの分析によれば、データセット全体の9割超のブランドでは、従来の検索権威性とAI視認性がほぼ連動していた。つまり、SEOの基本原則が無効になったわけではない。ただし、データの端に位置するブランド群にこそ戦略の変化が見える。

全体の約5%、471ブランドが「AI過少露出」だった。ドメイン評価が高く、オーガニック流入も多く、大量のキーワードで上位表示しているにもかかわらず、AIモデルからはほとんど参照されなかった。SEO指標上は市場リーダーに見えるのに、LLMからの言及では「誰も書いたことがない企業」のように映る。

一方、全体の約4%、377ブランドが「AIオーバーパフォーマー」だった。控えめなSEO指標に比べて、AIモデルからの参照が大幅に多かった。さらに9%は、第三者コンテンツでの言及頻度とAI視認性が一致した。

ここから見える最大の示唆は、自社が発信するコンテンツよりも、外部サイトが繰り返し語ってきた内容の方がAIの回答に強く影響するという点だ。まとめ記事、専門家リスト、比較レビューに登場する頻度が高いブランドほど、AIモデルの訓練データに取り込まれやすい。

カテゴリ誤分類で消える大手ブランド

カテゴリ誤分類で消える大手ブランド

AI過少露出のブランドには、従来の指標ではカテゴリの勝者とみなされてきた大手が並ぶ。ドメイン評価80以上、月間訪問数数百万、数十万のキーワードで上位表示しているブランドが、自社カテゴリのプロンプトで一切言及されない。

この問題の根底にあるのが、カテゴリ分類のズレだ。MicrosoftとSpotifyはFinTechのプロンプトで言及されなかった。両社とも伝統的な視認性は巨大だが、AIモデルはFinTechカテゴリに分類していない。Microsoftは生産性ソフトやクラウドの文脈では頻繁に引用される。FinTechの回答セットには含まれないだけだ。

同様の構図は保険、小売、ヘルスケアでも見られた。Aetna、Cigna、Humana、Liberty Mutualはドメイン評価80以上でも、AI回答ではLemonadeやRootに置き換えられた。Sephora、Samsung、Whirlpoolも、ライフスタイルのプロンプトではPatagoniaやAllbirdsに劣位した。

言及されない理由は、AIがブランドを知らないからではない。検索者が使うカテゴリと異なる引き出しに、そのブランドがしまわれているからだ。コンテンツ量を増やすだけでは解決しない。AIモデルがブランドを正しいカテゴリに結び付けるための外部シグナルが必要になる。

ブランド分類のズレが示すもの
Microsoft 検索側の見立て 生産性ソフト
Microsoft FinTechプロンプトでは 言及なし
Spotify FinTechプロンプトで 言及なし
ブランド  AIが認識するカテゴリ  カテゴリ不一致

AIモデルがブランドをどのカテゴリに分類しているかを把握し、ズレがあれば修正する方が先だ。カテゴリの結び付きを強化するには、アナリスト記事、業界メディア、比較ページ、パートナーページ、カスタマーストーリー、レビューサイトでの露出が有効になる。

AIで際立つオーバーパフォーマーの戦略

AIオーバーパフォーマー377ブランドの動きは、マーケターにとって他山の石になる。小さいSEOプロフィールでも、AIの回答に繰り返し登場するブランドは、共通してAIモデルの訓練データに使われた第三者コンテンツに複数回登場している。

データセット最大のオーバーパフォーマーはMonday.comだ。AI視認性スコアは0.71を記録した。オーガニック訪問数は約100万、上位キーワードは5万以上。すでに大きなSEO基盤を持ちながら、SaaSプレイヤーの平均を大きく上回る頻度でAIに参照されている。

保険カテゴリではRoot Insuranceが突出した。大手保険会社の規模に遠く及ばないにもかかわらず、AI参照数ではすべての従来型保険会社を上回った。オーバーパフォーマーの上位15ブランドのうち6つは教育分野で、Stanford、MIT、Khan Academy、LinkedIn Learning、IBM Data Science、Google Career Certificatesが並ぶ。AIモデルは商用的なプラットフォームではなく、信頼性の高さで教育ブランドを参照している。

共通項は「良いSEO」ではなく、他者のコンテンツにカテゴリレベルで登場していることだ。製品まとめ記事、エキスパートリスト、比較記事に取り上げられる頻度が、AI視認性を押し上げる。AI視認性の向上は、デジタルPRやカテゴリ権威性の構築に近づいている。

モデル間で異なるAI視認性の実態

モデル間で異なるAI視認性の実態

調査対象のうち、3モデルすべてに参照されたブランドは11%、900ブランドにとどまった。2モデルに登場したのは12%。残りの77%は、1つのモデルにしか登場しなかった。これはAI視認性の測定に深刻な課題を突き付ける。

ChatGPTで勝てるブランドがGeminiでは消える。Claudeで登場してもChatGPTからは出てこない。1つのモデルの回答を制しても、別のモデルではほとんど登録されない。AI視認性の「総合スコア」だけで改善を判断すると、実態を見誤る原因になる。

3モデルすべてに参照されたブランド(11%)
900ブランドが該当
2モデルに参照されたブランド(12%)
データセットの約12%が該当
1モデルだけに参照されたブランド(77%)
大多数がここに集中
全モデルで一致  2モデルで一致  1モデルのみ

モデルごとの「指紋」も異なる。ClaudeはSaaSと保険に偏り、Notion、Linear、Lemonadeが他モデルより頻繁に登場した。Geminiは旅行とヘルスケアに偏り、Booking.com、Teladoc、Livongoの言及が多かった。ChatGPTは3モデルの中で最も合意型で、他モデルとの重複が最も多い。

NotionはClaudeからの引用がGeminiの17倍に達し、Whoopは約4倍だった。State FarmはChatGPTに言及のほぼ半分を依存し、Geminiからは約4分の1しか得られなかった。総合スコアが同じでも、どこで差が出ているかを確認しないと対策は打てない。

ブランド戦略に必要な5つの視点

Fractlの記事は、この調査から導ける5つの教訓を提示している。実行しやすい順に並べると、次の通りだ。

1. 検索権威性とAIリコールを分けて測る

ドメイン評価、オーガニック流入、キーワード順位は引き続き重要だ。ただし、それだけでは全体像を捉えられない。Googleでの順位とAI回答での登場を別々に追跡し、乖離を探す。そのズレにこそ戦略のヒントがある。

2. 第三者による検証を増やす

自社サイトのコンテンツだけではAI回答への登場を保証できない。まとめ記事、ベストリスト、比較記事、専門家レビュー、アナリストページ、ポッドキャスト、YouTubeの文字起こし、コミュニティの議論など、外部コンテンツでの言及を積み重ねることが、AI視認性の実用的なレバーになる。

3. モデルごとに個別測定する

3モデルすべてに参照されたブランドは11%に過ぎない。「AI視認性」を1つの指標として扱うのは誤解を招く。ChatGPT、Gemini、Claudeを分けて計測し、プロンプトをカテゴリ別、購買意図別、比較セット別に分解する。どのモデルで、どの文脈で、どの競合と共に登場するかを追跡する。

4. カテゴリ分類の修正を優先する

ブランド全体の認知度が高くても、狙うカテゴリでのリコールが弱いなら、問題は分類にある可能性が高い。AIモデルはブランドを知っているが、重要なクエリの回答セットに含めるべき存在だとは考えていない。メディア報道、比較コンテンツ、パートナー参照、カスタマーストーリー、受賞歴、レビュー、第三者ページなどを通じて、ブランドとカテゴリの結び付きを繰り返し強化する必要がある。

5. デフォルト回答の枠が固まる前に動く

ウェルネス、ライフスタイル、ヘルステックの一部では、デフォルト回答の座がまだ空白だ。一方、旅行、主要SaaS、FinTechの一部では、AIが返す顔ぶれがすでに固定化しつつある。カテゴリとの結び付きを早期に築いたブランドほど、AIの回答に残りやすい。後発が割り込む余地は徐々に狭まる。

この記事のポイント

  • SEO上位でもAI回答に登場しないブランドが全体の約5%存在する
  • AI回答での競争集合は検索結果ページよりはるかに小さい
  • 第三者コンテンツでの言及頻度がAI視認性を左右する
  • 3モデルすべてに参照されるブランドは11%に過ぎない
  • カテゴリ誤分類の修正がAI視認性改善の近道になる
AnthropicのClaudeが画面録画から業務を学習、Record a Skill機能を追加

AnthropicのClaudeが画面録画から業務を学習、Record a Skill機能を追加

Anthropicが7月22日、Claude Coworkに「Record a Skill」機能を追加した。有料プランユーザーは、画面を録画しながらタスクの手順を実演し、それをClaudeが自動学習して同じタスクを再実行できるようになる。OpenAIのCodexが6月にリリースした「Record and Replay」に続く動きであり、AIによる業務自動化が大きく前進した形だ。

この機能の本質は「操作デモ→AI学習→自動実行」という流れにある。従来のAI自動化はコードやテキスト指示が前提だったが、今回の発表では画面録画という視覚情報から直接スキルを習得する点が新しい。中小企業のWeb担当者や個人事業主にとって、定型業務をAIに任せるハードルが一気に下がる可能性がある。

Record a Skillの仕組みと操作の流れ

Record a Skillの仕組みと操作の流れ

画面録画でAIに「仕事のやり方」を教える

Record a SkillはClaudeのデスクトップアプリ内にある「+」メニューから起動する。ユーザーが実際にPC上で操作しながら、その手順を音声で説明する。Claudeは画面の動きと音声を解析し、一連の操作を「スキル」として保存する仕組みだ。録画が終わると、Claudeはそのスキルを理解し、以降は同じタスクを自動で実行できるようになる。

たとえば、Googleスプレッドシートで毎週の売上データを集計する業務があるとする。「このセルを選択してSUM関数を入力し、グラフを作成してSlackに共有する」手順を一度録画すれば、Claudeがその一連の流れを記憶する。次回からは「先週の売上レポートを作成して」と指示するだけで、Claudeが自律的にタスクを完了させる。

対象プランと利用条件

Record a SkillはPro、Max、Teamの各プランで利用できる。無料プランやEnterpriseプランについては現時点で明示されていない。Anthropicは従来からClaude Coworkを「人間とAIの協働」を軸に開発しており、今回の機能もその延長線上にある。

利用環境はClaudeのデスクトップアプリに限定される。ブラウザ版やモバイルアプリでは使えない。WindowsとMacの両方に対応しているかについては、Anthropicの発表では明記されていないが、デスクトップアプリが両OSで提供されていることから、順次対応が進むと見られる。

従来のAI自動化(Before)
1 人間が操作手順をテキストで記述
2 コードやスクリプトに変換
3 AIが実行(指示の解釈ミスあり)
→ 定型業務の自動化には専門知識と工数が必要
Record a Skill(After)
1 画面録画を起動
2 実際の操作を実演+音声で説明
3 Claudeが操作を学習しスキル化
4 以降は指示だけでClaudeが自動実行
→ 専門知識不要、録画1回で自動化が完了

このデモで示したように、Record a Skillの最大の利点は「自動化のための自動化」を省けることだ。従来はRPA(ロボティック・プロセス・オートメーション / 定型業務をソフトウェアで自動化する技術)の導入にスクリプト作成や専用ツールの習得が必要だった。Claudeの新機能は、その前提を画面録画という直感的な操作に置き換えている。

OpenAI CodexのRecord and Replayとの比較

OpenAI CodexのRecord and Replayとの比較

先行するOpenAIの類似機能

画面録画からAIがタスクを学習するというアイデアは、Anthropicが初めてではない。OpenAIは6月18日にCodex向けの「Record and Replay」機能をリリースしている。こちらはApple Macユーザー限定で、欧州経済領域(EEA)、スイス、英国では利用できないという地域制限がある。Windows版の提供時期は未定だ。

AnthropicのRecord a Skillは、現時点で地域制限についての言及がない。また、ClaudeのデスクトップアプリはMacとWindowsの両方で提供されているため、Codexに比べて利用ハードルは低いと見られる。ただし、実際の動作環境や対応OSの詳細は今後のアップデートを待つ必要がある。

両者の違いを整理すると、CodexのRecord and Replayは開発者向けのCodex環境に統合されているのに対し、ClaudeのRecord a Skillはより幅広いビジネスユーザーを想定したClaude Coworkの一部として提供されている点が大きい。ターゲット層の違いが、今後の普及速度に影響を与える可能性がある。

機能面でのポイント

Record a Skillの特筆すべき点は、音声による説明を組み合わせる設計だ。単に画面をキャプチャするだけでなく、ユーザーが「このボタンを押す理由は〜」と話しながら操作することで、Claudeは操作の意図まで理解する。これにより、似た状況での応用や、イレギュラーケースへの対応力が高まる。

一方で、CodexのRecord and Replayはより開発寄りの文脈で設計されており、コード生成やAPI操作との親和性が高い。どちらが優れているかは、利用シーンによって異なる。Web制作やコンテンツ管理といった業務では、Claudeのアプローチがマッチするケースが多いだろう。

「仕事が奪われる」という反響と現実的な評価

「仕事が奪われる」という反響と現実的な評価

SNSで広がる懸念の声

Anthropicの発表に対し、SNS上では「これが一番簡単にクビになる方法だ」といった反応が相次いだ。画面録画で自分の業務をAIに教えることは、すなわち自分の仕事をAIに置き換える行為に見えるというわけだ。実際、定型作業の多い職種では、この機能が雇用に影響を与える可能性は否定できない。

また、一部のユーザーからは「アカウントの利用制限に達していて新機能を試せない」という不満も上がっている。有料プランでも一定の利用上限があることは、実務での継続的な活用を考える上で注意が必要な点だ。

自動化と人間の役割はどう変わるか

「AIが仕事を奪う」という議論には、二つの対立する見方がある。一つは「完全自動化できる仕事は、そもそも人間がやる必要がなかった」という考え方だ。もう一つは「AIが介在しても、最終的なアウトプットの質を決めるのは人間のスキルと経験である」という立場である。

Record a Skillは、この議論に新たな視点を加える。画面録画という行為自体が、人間の暗黙知を形式知に変換するプロセスだからだ。ベテラン担当者が「なんとなくやっている」操作のコツや判断基準を、AIが学習可能な形で記録できる。これは単なる自動化ではなく、属人化したノウハウの可視化と継承につながる側面もある。

懸念される見方(Before)
担当者 画面録画で業務をAIに教える 雇用喪失
自分の仕事を自らAIに移譲する行為と捉えられる
建設的な見方(After)
担当者 定型業務をAIに委任 高付加価値業務に集中
属人化したノウハウを可視化し、チームで共有可能に
■ AIに任せる定型業務(データ入力・レポート生成・定例チェック等)
■ 人間が注力すべき領域(戦略立案・クリエイティブ判断・顧客対応等)

実際のところ、Record a Skillが真価を発揮するのは「完全自動化」ではなく「部分自動化」の領域だ。すべてをAIに任せるのではなく、繰り返し発生する定型部分だけを切り出してClaudeに委ね、人間は判断や創造性が求められる部分に集中する。この使い分けができるかどうかが、導入効果を左右する。

Web担当者・個人事業主にとっての活用法

Web担当者・個人事業主にとっての活用法

SEOやコンテンツ管理での具体的な利用シーン

Search Engine Journalの記事はSEO担当者向けにこのニュースを報じているが、実際にどのような業務がRecord a Skillに向いているのか、具体的に考えてみたい。以下のようなタスクは、手順が定型的で繰り返し発生するため、相性が良い。

  • Googleサーチコンソールからのデータ取得とレポート作成
  • WordPressの投稿下書きから公開前チェックリストの実行
  • 競合サイトの定期巡回と変更点の記録
  • Googleビジネスプロフィールの投稿作成とスケジュール設定
  • アクセス解析ツールからの定期レポートの自動生成

これらの作業は、手順さえ明確であればAIによる再現が可能だ。特に「毎週月曜日に同じレポートを作成する」といったルーティン業務では、一度録画するだけで継続的な時間削減が見込める。

導入前に確認すべき制約と注意点

ただし、Record a Skillは万能ではない。現時点ではデスクトップアプリ限定であり、ブラウザベースの業務には直接適用しにくい。また、録画した操作の再現性は、対象アプリのUI変更やネットワーク状況に左右される。Webサイトの管理画面のように、頻繁にUIがアップデートされる環境では、スキルが陈腐化する可能性にも注意が必要だ。

また、セキュリティ面の検討も欠かせない。画面録画にはパスワードやAPIキーといった機密情報が映り込むリスクがある。Anthropicは録画データの取り扱いについて明示していないため、社内のセキュリティポリシーと照らし合わせた上での導入判断が求められる。

この記事のポイント

  • AnthropicがClaude Coworkに「Record a Skill」機能を追加、画面録画でAIにタスクを学習させられる
  • Pro、Max、Teamプランで利用可能、デスクトップアプリから操作する
  • OpenAI CodexのRecord and Replayに続く動きだが、Claudeはより幅広いビジネスユーザーを想定
  • 定型業務の自動化ハードルが大幅に下がる一方、雇用への影響を懸念する声もある
  • Web担当者にとってはSEOレポート作成やコンテンツ管理の定型作業で活用の余地が大きい
GA4にAI Assistantチャネル追加、ChatGPT流入を可視化

GA4にAI Assistantチャネル追加、ChatGPT流入を可視化

Google Analytics 4(GA4)に2026年5月、生成AIプラットフォームからの流入を可視化する「AI Assistant」チャネルが追加された。ECサイト運営者にとって、ChatGPTやClaudeが商品情報を紹介した結果のトラフィックを正確に把握できる初めての標準機能だ。

この記事ではAI Assistantチャネルの基本的な仕組みと、ECサイトでの具体的な活用法を解説する。設定不要でデータが自動収集される一方、AI Overviewsは含まれないといった注意点もあるため、正しい読み方を押さえておく必要がある。

WooCommerceサイトを運営する中小企業の担当者や、ECのアクセス解析を担当するWeb担にとって、これまで「参照元不明」だったAI経由の流入を可視化できる意味は大きい。

AI Assistantチャネルとは何か

AI Assistantチャネルとは何か
これまでの課題
AIチャットボット 商品情報を回答 ユーザーがクリック 参照元不明
ChatGPTやClaudeからの流入が「Direct」や「Referral」に混ざり、実態が見えなかった
AI Assistantチャネル導入後
ChatGPT Claude Gemini
生成AIプラットフォーム経由の流入が「AI Assistant」チャネルに自動分類される

AI Assistantチャネルは、GA4のデフォルトチャネルグループに追加された新しい分類項目だ。ChatGPTやGemini、Claudeといった主要な生成AIプラットフォームからのトラフィックを自動的に判別し、ひとつのチャネルとして集計する。

計測対象となるプラットフォーム

Googleの公式ヘルプドキュメントによると、AI Assistantチャネルに含まれるのは「ChatGPT、Gemini、Claudeといったチャットボット」からのトラフィックだ。具体的な全リストは公開されていないが、主要な生成AIサービスはおおむねカバーされていると見てよい。

ここで重要な注意点がある。Google検索のAI Overviews(旧SGE)やAI Modeは、このチャネルには含まれない。これらは引き続き「Organic Search(オーガニック検索)」チャネルとして報告される。同じAI由来の流入でも、検索エンジン経由かチャットボット経由かで扱いが異なるわけだ。

ECサイトにとっての意味

ECサイト運営者にとって、AIチャットボット経由の流入は従来のSEOとは異なる文脈で発生する。たとえば「予算3万円で買えるおすすめのワイヤレスイヤホン」といった自然言語の質問に対し、ChatGPTが具体的な製品名とURLを提示するケースだ。この流入経路を正確に把握できれば、AIに自社商品がどのような文脈で言及されているかを分析できる。

AIトラフィックの確認手順

AIトラフィックの確認手順

GA4でAI Assistantチャネルのデータを見るための手順を解説する。初期設定は不要で、GA4が自動的に分類を開始しているため、すぐに確認できる。WooCommerceサイトでGA4を導入済みであれば、追加のコード実装も必要ない。

トラフィック全体像の把握

まずはECサイト全体で、AI経由の流入がどの程度あるのかを確認する。GA4管理画面で「レポート」→「集客」→「トラフィック獲得」の順に開き、「セッションのデフォルトチャネルグループ」ディメンションを選択する。ここで「AI Assistant」という行が表示されていれば、すでにAI経由のトラフィックが発生している。

表示される指標はエンゲージメント率、セッションあたりのイベント数、平均セッション時間などだ。これらの数字をOrganic Searchチャネルと比較することで、AI経由ユーザーの行動特性が見えてくる。

ランディングページの特定

AIがどの商品ページを参照しているのかを特定するには、「レポート」→「エンゲージメント」→「ページとスクリーン」を開く。画面上部の「フィルタを追加」から、以下の条件で絞り込む。

  • ディメンション:セッションのデフォルトチャネルグループ
  • マッチタイプ:完全一致
  • 値:AI Assistant

このフィルタを適用すると、AIプラットフォームからのクリックが多いページが上位に表示される。WooCommerceの商品ページやカテゴリページのうち、どのURLがAIに評価されているかを把握できるはずだ。

AIトラフィックと他チャネルの比較

同じ「ページとスクリーン」レポートで「比較を追加」ボタンを使うと、AI経由とオーガニック検索経由のトラフィックを横並びで比較できる。Practical Ecommerceの記事著者Carlo Daniele氏の検証によれば、オーガニック検索で上位のページとAI Assistant経由で上位のページは重複しなかったという。

比較設定の手順
STEP 1 「比較を追加」→「新規作成」を選択
STEP 2 ディメンション:セッションのデフォルトチャネルグループ
STEP 3 マッチタイプ:完全一致、値:AI Assistant
STEP 4 「すべてのユーザー」を削除し、別チャネルを追加

これはEC担当者にとって示唆が大きい。Google検索で上位表示されている商品と、AIがユーザーに推薦する商品が異なる可能性があるためだ。AI経由の流入を伸ばすには、従来のSEO対策とは別のアプローチが必要になるかもしれない。

正規表現を使った詳細なソース分析

正規表現を使った詳細なソース分析

AI Assistantチャネルは便利だが、どのAIプラットフォームからの流入なのかまでは分解できない。ChatGPT経由なのかClaude経由なのかを個別に知りたい場合は、正規表現(regex)を使ったフィルタリングが有効だ。

AIプラットフォーム別の流入を可視化するregex
ChatGPT chatgpt.com
Perplexity perplexity
Microsoft Copilot edgepilot / copilot.microsoft.com
Google Gemini gemini.google.com
Claude claude.ai
Grok grok.x.ai
生成AIチャットボット

設定手順

「レポート」→「集客」→「トラフィック獲得」で、グラフ上部の「フィルタを追加」をクリックする。ディメンションに「セッションの参照元/メディア」、マッチタイプに「matches regex」を選択し、以下の正規表現を値欄に貼り付ける。

.*chatgpt.com.*|.*perplexity.*|.*edgepilot.*|.*copilot.microsoft.com.*|.*openai.com.*|.*gemini.google.com.*|.*claude.ai.*|.*grok.x.ai.*

このフィルタを適用すると、AIプラットフォームごとのセッション数やエンゲージメント指標を一覧できる。ただしPractical Ecommerceの記事でも指摘されているように、AI Assistantチャネルとの間にわずかなデータの不一致が生じる場合がある。これは「Organic」や「(not set)」と分類される一部のAIトラフィックが正規表現では拾えていないためだ。

WooCommerceサイトでの活用ポイント

正規表現フィルタを使えば、たとえば「ChatGPT経由では商品Aへの流入が多いが、Claude経由では商品Bが多い」といったプラットフォーム別の傾向を把握できる。AIによって得意とする商品カテゴリや、参照する情報ソースが異なる可能性があるためだ。

このデータをもとに、特定のAIプラットフォームで自社商品が言及されやすいコンテンツを強化するといった戦略が考えられる。Semrushなどの外部ツールで、どのようなプロンプトがAIの引用を生んでいるのかを調査するのも有効だ。

EC担当者が今すぐやるべき3つのアクション

EC担当者が今すぐやるべき3つのアクション

AI Assistantチャネルの登場を受けて、ECサイトのアクセス解析にすぐに組み込むべき施策を整理する。いずれも追加コストなしで今すぐ始められるものばかりだ。

アクション1 AIトラフィックの有無を即日確認
GA4のトラフィック獲得レポートで「AI Assistant」チャネルの有無をチェックする。すでに流入があれば、その規模とエンゲージメント率を基準値として記録する
アクション2 AI経由ランディングページの棚卸し
ページとスクリーンレポートでAI Assistantチャネルでフィルタリングし、AIに評価されている商品ページを特定する。そのページのコンテンツ品質を改めて見直し、情報の正確性や網羅性を高める
アクション3 AIプラットフォーム別の傾向を月次で追跡
正規表現フィルタをGA4の「探索」レポートに保存し、ChatGPT・Claude・Geminiごとの流入推移を月次でモニタリングする。AIプラットフォームのシェア変動がECサイトの流入構造にどう影響するかを定点観測する

特にアクション2は重要だ。AIは商品スペックや口コミ、価格情報を総合的に評価して回答を生成する。商品ページの情報が不十分だとAIに引用されにくくなるため、商品説明の充実や構造化データの実装はAI時代のECに不可欠な施策といえる。

AIトラフィックとECの未来

AIトラフィックとECの未来

GA4のAI Assistantチャネルは、ECにとって「AI経由の流入」という新たな指標を提供し始めた。現時点ではまだAIトラフィックの絶対量は小さいかもしれないが、ChatGPTやClaudeがデフォルトでWeb検索を行うようになり、AIを経由した商品発見は確実に増えていく。

AI OverviewsがOrganic Searchに含まれるという設計からもわかるように、GoogleはAIを「検索の拡張」と位置づけている。EC担当者はSEOとAI最適化を別物ではなく、同じ「検索体験」の両輪として捉えるべきフェーズに入ったといえる。

WooCommerceサイトであれば、GA4の標準機能だけでAIトラフィックの可視化は十分に可能だ。まずはデータを取得し、AIが自社商品をどう評価しているのかを把握することから始めてほしい。

この記事のポイント

  • GA4に2026年5月追加のAI Assistantチャネルで、ChatGPTやClaudeなど生成AIからの流入が自動分類される
  • AI OverviewsやAI Modeは含まれず、これらはOrganic Searchとして報告される点に注意が必要
  • ページとスクリーンレポートでAI経由ランディングページを特定し、商品情報の最適化に活かせる
  • 正規表現フィルタでAIプラットフォーム別の傾向を把握し、より細かな流入分析が可能
  • AIトラフィックはSEOと地続きの指標であり、商品ページの情報充実がAIからの引用を増やす鍵になる
Claude Fable 5がGoogle Cloudで一般提供開始。エージェント構築の新たな基盤を考察

Claude Fable 5がGoogle Cloudで一般提供開始。エージェント構築の新たな基盤を考察

Anthropicの最新モデル「Claude Fable 5」が、Google Cloud上で一般提供を開始した。このモデルは複雑な多段階推論や高度なコード生成を得意とし、長期間にわたって自律的に動作するエージェントの構築に適している。クラウドAIの基盤に何が起きているのかを読み解く。

Claude Fable 5の登場とその戦略的な位置付け

Anthropicのモデル群には、Haiku(軽量高速)、Sonnet(バランス)、Opus(超高性能)がある。今回登場したFableシリーズは、これらのニックネームとは明らかに異なる文脈を持つ。筆者の見解では、Fableは「物語(ストーリー)の生成」、つまり長文脈の一貫性維持や、複雑なオーケストレーションを必要とするエージェントタスクに特化した系統と位置付けられる。

このモデルは単に速度や知識量を競うだけでなく、「どれだけ複雑な仕事を最後までやり遂げられるか」を重視している。特に、長期稼働エージェントとしての使用が強く想定されている点が、他のモデルとの差別化要因だ。

Anthropic モデルラインナップの想定マッピング
Haiku 軽量・高速 Sonnet 標準・高品質 Opus 超高性能
特化型 Fable 5
長文脈の一貫性、複雑なオーケストレーション、長期稼働エージェントに特化
長文脈の一貫性 高度なコード生成 マルチモーダル分析

Fable 5は、単発のレスポンスを返すだけではない。途中で文脈を見失ったり、指示を忘れたりする問題を大幅に低減し、ソフトウェア開発や分析業務といった長時間の集中を要するタスクで真価を発揮する。

Fable 5の主要な能力と想定されるユースケース

Fable 5の主要な能力と想定されるユースケース

Google Cloudの公式発表とAnthropicのリリースノートから、Fable 5の中核的な機能強化点を読み解くと、以下の3つに集約される。

複雑な多段階推論と高度なコード生成

Fable 5は、数学的推論やコード生成ベンチマークで大幅な性能向上を達成している。これは単にコードを出力するだけでなく、既存のリポジトリ全体を理解し、アーキテクチャレベルの提案ができることを示す。典型的な「次のトークン予測」を超え、人間のソフトウェアアーキテクトのように数手先を読む能力が強化された。

長期稼働エージェントの実現

多くのLLMは文脈が長くなると応答精度が落ちる。Fable 5は「長時間にわたって自律的にツールを使い、タスクを完了させる」というエージェント動作に最適化されている。カスタマーサポートの自動化、継続的なデータ収集、IT運用の自動化など、数時間から数日単位で動くAIエージェント基盤として機能する。

深いマルチモーダル文書分析

テキストだけでなく、PDF内のグラフ、パワーポイントの図表、画像内のテキストまでを横断的に理解する能力が向上した。これにより、企業内に散在する非構造化データの分析ハードルが大幅に下がる。数百ページの契約書や仕様書を読み込ませ、瞬時に要約や矛盾点の洗い出しを行うといった使い方が視野に入る。

Fable 5 能力のハイライト
🧠
多段階推論
複数の手順を踏む複雑な問題解決
⚙️
コード生成
リポジトリ全体の理解とアーキテクチャ提案
📊
文書分析
非構造化文書の横断的な解析
想定されるインパクト 「AIに任せる」から「AIがやり遂げる」へのパラダイムシフト

これらの能力は、もはや「優秀なアシスタント」ではなく「自立したチームメンバー」という表現が近い。開発現場ではコードレビューを完全自動化し、法務部門では契約書の精査を任せられる。人間が最終判断する仕事の質とスピードが、根本から変わる可能性をはらんでいる。

Google CloudのAgent Platformがもたらす実用性

Google CloudのAgent Platformがもたらす実用性

モデル単体の性能もさることながら、今回の発表で注目すべきはGoogle Cloudの「Agent Platform」上で提供される点だ。これは単なるAPIゲートウェイではない。エージェントの構築、テスト、デプロイ、監視までを垂直統合した基盤である。

具体的には、Googleが持つエンタープライズグレードのセキュリティ(IAM、VPC Service Controls)、Vertex AIのMLOps機能(モデル評価、メタデータ管理)、そしてCloud RunやBigQueryといった周辺サービスとの統合がシームレスに行える。Fable 5のような高度なモデルを「安全に」「堅牢に」本番環境で動かすために必要なピースがあらかじめ揃っている。

Google Cloud Agent Platform の構成概念図
ユーザー Agent Platform Claude Fable 5
ツール実行 BigQuery Cloud Run 外部API
開発者・利用者  エージェント基盤  推論エンジン  データ・サービス連携

ここで重要なのは、強力なモデルを手に入れることと、それをビジネスで使いこなすことの間にあるギャップが、Agent Platformによって埋められる点だ。認証基盤や監査ログが整っていない状態でAIエージェントに重要な業務を任せることは難しい。Google Cloudのプレゼンスは、企業のAI導入における「最後の1マイル」を解決する。

開発者が今日から試すべき3つのアプローチ

Fable 5とAgent Platformが利用可能になったことで、Web制作やシステム開発の現場で即座に試せる実験領域が広がった。筆者の視点から、特に費用対効果が高いと想定される3つのシナリオを提示する。

コードレビューの完全自動化プロトタイプ

GitHub連携をトリガーに、Fable 5がPull Request全体を解析する。コーディング規約のチェックだけでなく、コードの脆弱性、パフォーマンス劣化リスク、過去の類似実装との矛盾点までを自然言語でレビューコメントする。人間のレビューアは、Fable 5が出した指摘が正しいかどうかの最終判断だけに集中できる。

非構造化ドキュメントのデータベース化

クライアントから提供された古い仕様書のPDF、競合分析のスライド、展示会で撮影したホワイトボードの写真などをまとめてFable 5に投入する。モデルはこれらを横断的に解析し、共通する要求定義や矛盾する記述を抽出して構造化データとして出力する。データベースに格納することで、後続の検索やレポート作成が自動化される。

社内向け「なんでも調査エージェント」の起案

定型的なリサーチ業務をエージェント化する。例えば「3ヶ月以内に更新された特定分野の法改正情報を、週次で一覧化してSlackに投げる」といったタスクをFable 5に任せる。モデルが自律的にGoogle検索や社内Wikiを巡回し、複数ステップの推論を経て最終的なサマリーを生成するPoCは、数日あれば構築可能だ。

従来のコードレビュー運用(Before)
1. 開発者がPRを作成
2. レビューアがコード全体を確認(30分〜)
3. 見落とし・属人的な指摘に依存
4. 過去の知見が活かされない
Claude Fable 5 導入後のフロー(After)
1. 開発者がPRを作成
2. Fable 5が10秒で脆弱性・規約・矛盾を指摘
3. 人間のレビューアは「AIの指摘が正しいか」を判断
4. 企業全体のナレッジが常にレビューに反映される

このアプローチによって、人間の工数は「クリエイティブな問題解決」と「AIの提案に対する最終的な意思決定」に集中できるようになる。

この記事のポイント

  • Anthropicの最新モデルClaude Fable 5は、複雑な推論と長期稼働エージェントに特化してGoogle Cloud上で一般提供が開始された
  • 高いコード生成能力と深いマルチモーダル分析を持ち、単なるテキスト生成を超えたタスクの自動化が可能になった
  • Google CloudのAgent Platformとの統合により、エンタープライズレベルのセキュリティと運用基盤が整備されている
  • 人間はAIの最終判断に集中する働き方へシフトするため、コードレビューや文書分析のプロトタイプを早期に試す価値がある
Claude Fable 5がAWSで利用可能に。長時間実行と安全策を両立する新モデル

Claude Fable 5がAWSで利用可能に。長時間実行と安全策を両立する新モデル

AWSがClaude Fable 5のAmazon Bedrock対応を発表した。Anthropicの新モデルはMythosクラスの最高性能を備えつつ、有害利用リスクへの安全策を組み込んだ点が最大の特徴だ。ソフトウェア開発や文書解析など長時間の自律作業を任せられる設計になっている。

Fable 5はほぼすべてのベンチマークで最先端のスコアを記録する。注目すべきは、人間の介入なしで複雑なコーディングやナレッジワークを長時間継続できる実行能力だ。単発の応答を超えた「作業の持続」が可能になったことで、開発現場やビジネスプロセスへの組み込みが現実味を帯びてきた。

Claude Fable 5の3つの技術的特徴

従来のLLM(大規模言語モデル)が得意としてきた「質問への即答」とは異なり、Fable 5は「長時間タスクの遂行」にフォーカスしている。AWS公式ブログとAnthropicの技術発表から、その差別化要素を整理した。

長時間の非同期実行

従来のモデルは数分を超えるタスクで精度が低下したり、文脈を見失ったりする課題があった。Fable 5は複雑なコーディングや調査作業を長時間・自律的に続行できる。具体的には、複数ファイルにまたがる大規模なリファクタリングや、長大なドキュメントの横断的分析といった作業を途中で止めずに完了させる。

これは単にトークン数が増えただけではない。モデル内部のアーキテクチャが「途中経過の自己管理」を強化しており、タスクのゴールを見失わずに作業を継続する仕組みだ。AWSの発表では「長時間のコーディングや知識労働を継続的に実行する」と表現されている。

従来のLLMのタスク遂行
タスク開始 文脈喪失 精度低下
数分を超える作業で応答品質が徐々に劣化し、最終的に使えなくなる
Fable 5のタスク遂行
タスク開始 自己管理 完了まで持続
途中経過を内部で管理し、長時間にわたって安定した品質を維持する

この変化により、ソフトウェア開発における「任せっぱなし運用」の幅が広がる。たとえばコードベース全体のリファクタリングを夜間に任せ、朝には完了しているというワークフローが視野に入る。

高度なビジョン機能

Fable 5はテキストだけでなく、図表、グラフ、PDF内に埋め込まれた表などを高精度で理解する。金融や法務、建築、ゲーム開発など、文書や設計図を扱う業種での活用が期待される領域だ。

コーディングの文脈でも大きな意味を持つ。デザインファイルを読み取ってUIを実装したり、出力結果のスクリーンショットを自己チェックして「要件と合っているか」を検証したりできる。従来のモデルはテキスト情報だけを頼りにしていたが、Fable 5は「見て判断する」能力を作業フローに組み込める。

テキストベースの従来型
仕様書.txt → 「ヘッダーにロゴを配置」
コード生成 → 大まかに合うが細部は不明
ビジョン対応のFable 5
デザインカンプ.png → 配置や余白まで正確に読み取り
コード生成 → 見た目通りに再現し、自己チェックも実行

プロアクティブな自己検証

Fable 5はタスク実行中に得た学習をもとにスキルを自己更新し、自ら評価用のハーネス(テストフレームワーク)を作成する。AWSの発表では「自身の出力を目標と照らし合わせて批判的に評価する」と説明されている。

これはソフトウェアテストの自動化と深く関わる。たとえば「単体テストのコードを生成する」という指示ではなく「この機能を実装し、テストを作成し、通るまで修正を繰り返せ」という指示が現実的になる。モデルが自律的にPDCAを回すため、人間は成果物の最終確認に集中できる。

STEP 1 ユーザーが要件を指示
STEP 2 Fable 5がコードを生成しテストも作成
STEP 3 テストを実行し失敗箇所を自己修正
STEP 4 全テスト通過 → 最終成果物を提示

安全策の仕組みとMythos 5との棲み分け

安全策の仕組みとMythos 5との棲み分け

Fable 5の最大の独自性は「性能と安全策の両立」にある。同じモデルから安全性を引き上げたFable 5と、制限を外したMythos 5という2つのバリエーションが用意されている。

有害プロンプトは自動でOpus 4.8にルーティング

Fable 5はサイバーセキュリティ、生物学、化学、健康に関連する有害プロンプトを受け取ると、内部で自動的にOpus 4.8へルーティングする。AWSの公式発表では「安全策によって、ほぼすべての最先端機能へのアクセスを提供しつつ、誤用リスクの高い領域では応答を制限する」と説明されている。

重要なのは、ユーザー側で切り替えを意識する必要がない点だ。通常のAPIコールでFable 5を指定しておけば、安全と判断されたプロンプトにはFable 5が、リスクありと判断されたプロンプトにはOpus 4.8が自動で応答する。

通常のプロンプト(コーディング・文書作成等)
安全と判断される一般的な指示
ユーザー Fable 5 高品質な応答
Fable 5のフル性能で応答する
有害プロンプト(セキュリティ・生物学等の危険領域)
モデルがリスクを検知し自動で迂回
ユーザー Opus 4.8 安全な応答
自動ルーティングのためユーザーは切り替え不要。課金はOpusの価格で計算される

Mythos 5は限定的なプレビュー提供

Fable 5の制限を取り払ったMythos 5も、Amazon Bedrockで限定的に利用可能だ。ただしMythos 5はサイバーセキュリティやライフサイエンス(創薬、バイオディフェンススクリーニング等)といった専門領域向けであり、審査を受けた一部の顧客のみアクセスできる。一般提供は行われない。

この「制限付きスーパーモデル」と「制限なし最強モデル」の二層構造は、AIの社会実装における新たなパラダイムとなり得る。AWSの発表でも、Mythos 5はデュアルユース(軍民両用)の性質を持つため厳格な管理下に置かれていると明記されている。

Amazon Bedrockでの利用環境とセットアップ

Amazon Bedrockでの利用環境とセットアップ

Fable 5はAmazon BedrockとClaude Platform on AWSの両方で利用できる。ここではBedrock経由のセットアップ手順を中心に解説する。

データ共有へのオプトインが必須

Fable 5を利用するには、データ保持ポリシーでプロバイダーデータ共有(provider_data_share)にオプトインする必要がある。AnthropicはMythosクラスの全モデルで、入力と出力の30日間保持および人間によるレビューを必須としている。これは単一のやり取りでは検出できない誤用パターンを長期的に監視するためだ。

オプトインするとデータはAWSのセキュリティ境界を離れる。機密性の高いデータを扱う場合は、この点を事前に評価しておく必要がある。設定はAWS CLIで以下のように実行する(bedrock-mantleエンジン向け)。

curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \
  -H "x-api-key: <your-bedrock-api-key>" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "provider_data_share" }'

bedrock-runtimeエンジンを使う場合は、エンドポイントと認証方式が異なる点に注意が必要だ。詳細はAWSの公式ドキュメントを参照してほしい。

Python SDKからの呼び出し例

Anthropic SDKをインストールした後、Messages API経由でFable 5を呼び出すコードは以下の通りになる。リージョンは現時点で米国東部(バージニア北部)と欧州(ストックホルム)に対応している。

import anthropic

client = anthropic.Anthropic(
    base_url="https://bedrock-mantle.us-east-1.api.aws/anthropic",
    api_key=<your-bedrock-api-key>
)

message = client.messages.create(
    model="anthropic.claude-fable-5",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": "秒間10万リクエストを複数リージョンで処理するAWS分散アーキテクチャを設計してほしい"
        }
    ]
)

print(message.content[0].text)

BedrockのConverse APIを使う場合はBoto3経由となる。マルチモデル対応の統一インターフェースが使えるため、既存のBedrockワークロードとの統合が容易だ。

課金体系の注意点

有害プロンプトがOpus 4.8にルーティングされた場合、そのリクエストの課金はOpusの価格で計算される。また途中でブロックされた会話では、Fable 5が処理した初期トークンはFable 5の料金、それ以降はOpusの料金が適用される。大規模なワークロードを計画する際は、見積もりにこの変動要素を含めておく必要がある。

ソフトウェア開発の現場に与える影響

ソフトウェア開発の現場に与える影響

Fable 5の登場は、とりわけソフトウェアエンジニアリングのワークフローを変える可能性が高い。AWSの発表でも「長時間のコーディングタスク」と「自己検証」が前面に押し出されている。

「コードを書く」から「コードを任せる」へ

従来のLLMは「関数を1つ書いて」という短い指示には強かったが、プロジェクト全体を見渡すようなタスクには限界があった。Fable 5は「このリポジトリの全テストを補充し、カバレッジが90%を超えるまで繰り返せ」といった高レベルな指示を理解し、自律的に遂行できる。

これは開発者の役割を「実装者」から「設計者・監督者」へとシフトさせる。コードを書く時間が減り、アーキテクチャの意思決定やビジネスロジックの検討に集中できるようになる。ただし出力の品質チェックは依然として人間の責任だ。

従来のLLMとの関係
開発者
指示を細分化
LLM
1関数ずつ生成
開発者
結合とテストを手作業
Fable 5との関係
開発者
高レベルな指示のみ
Fable 5
設計→実装→テスト→修正を自動化
開発者
最終確認のみ

CI/CDパイプラインとの統合可能性

Fable 5の自己検証機能は、CI/CD(継続的インテグレーション/継続的デリバリー)の自動化範囲を拡大する。プルリクエストの自動レビュー、テスト自動生成、失敗時の自律的な修正までを一気通貫で行える可能性がある。

ただし現時点でFable 5は非同期実行向けに設計されており、リアルタイムのチャット応答を前提とした従来のCI/CDトリガーとはワークフローが異なる。ジョブキューと組み合わせたバッチ処理型の統合が現実的なアプローチになるだろう。

日本市場での受け入れと課題

国内のソフトウェア開発現場では、セキュリティ要件の厳しさから「データを外部に出せない」という制約が根強い。Fable 5の必須条件である30日間のデータ保持と人間によるレビューは、金融や医療分野での採用ハードルになる。AWSの東京リージョンでの利用可能時期も現時点では未発表だ。

一方で、スタートアップやゲーム開発のようにスピードを重視する領域では、Fable 5の長時間自律実行能力は強力な武器になる。日本でも段階的に導入が進むと見られる。

この記事のポイント

  • Claude Fable 5はMythosクラスの性能を持ちつつ、有害利用を自動遮断する安全策を内蔵している
  • 長時間の非同期実行により、コードの大規模リファクタリングや文書横断分析を自律的に完了できる
  • 図表やPDFを読み取るビジョン機能が加わり、金融・法務・建築など文書集約型の業種で活用が広がる
  • 有害プロンプトは自動でOpus 4.8にルーティングされ、ユーザーはモデルを意識せず使える
  • Amazon Bedrockでの利用には30日間のデータ保持オプトインが必須。機密データの扱いには注意が必要だ
CloudflareがClaude Managed Agentsと統合、エージェントの実行基盤を刷新

CloudflareがClaude Managed Agentsと統合、エージェントの実行基盤を刷新

CloudflareがAnthropicと連携し、Claude Managed AgentsをCloudflareのサンドボックス環境と統合した。この新たな統合により、エージェントのコード実行からブラウザ操作、プライベートサービスへの接続までを、Cloudflareのプラットフォーム上でより柔軟に制御できる。

従来、Claude Managed AgentsはAnthropic側のインフラに完全に依存していた。今回の発表で「頭脳」であるClaudeの推論ループと「手足」であるコード実行基盤が分離され、後者をCloudflare上で運用できるようになった。

開発者は数分でテンプレートをデプロイし、セキュリティ強化やミリ秒単位のサンドボックス起動、内部サービスへの安全な接続といったメリットを得られる。この記事では、統合の仕組みと実務への影響を具体的に掘り下げる。

Claude Managed AgentsとCloudflareが目指すもの

Claude Managed AgentsとCloudflareが目指すもの
従来の構成
Claude推論ループもコード実行も、すべてAnthropic側のインフラで処理されていた。
課題:インフラ選択の自由度が低く、自社サービスとの統合が難しい
今回の統合後
Claudeの推論ループはAnthropic側。コード実行基盤(サンドボックス)はCloudflareで動かせる。
効果:セキュリティ、スケール、観測性をすべてCloudflareでコントロール

この構成で得られるのは単なる「場所の変更」ではない。インフラをCloudflareに移すことで、エージェントの振る舞いを細かく監視し、内部サービスとの通信を暗号化し、必要なリソースだけを動的に割り当てられるようになる。

Cloudflare Blogの記事では、この仕組みを「頭脳から手足を切り離す」と表現している。開発者はClaudeの高い推論能力をそのまま活かしつつ、実行環境だけを自社ポリシーに合わせてカスタマイズできるわけだ。

Cloudflare環境の仕組み

Cloudflare環境の仕組み

統合をデプロイすると、Cloudflare上にWorkersベースのコントロールプレーンが立ち上がる。Claude Agentがセッションを開始するたび、このコントロールプレーンがサンドボックス環境を割り当て、コード実行やCLIツールの操作、ブラウザ操作などを代行する。

STEP 1
Claude Agentがタスクを開始し、コントロールプレーンへリクエストを送信
STEP 2
Workersがセッションごとに隔離されたサンドボックスを起動
STEP 3
コード実行やファイル操作を実施。セッション間で状態を保持
STEP 4
ダッシュボードやSSHで稼働状況をリアルタイムに確認可能

サンドボックスはセッションがスリープしても状態を自動的に保持する。コンテナイメージのカスタマイズやインスタンスサイズの調整もオプションで指定でき、既存の監視ツール(DatadogやSplunk)へのログ連携にも対応している。

特筆すべきは、Cloudflareのダッシュボードからエージェントの状態を可視化し、必要に応じてSSHでサンドボックス内部に入れる点だ。大規模なエージェント運用では、トラブルシューティングのしやすさが運用コストを大きく左右する。この設計は現場の要求をよく踏まえている。

インターネット規模のエージェント実行基盤

インターネット規模のエージェント実行基盤

エージェントが本格的に普及すると、企業は1人のユーザーに対して複数のエージェントを同時に動かす必要が出てくる。従来のマイクロVM方式では、エージェントの数だけVMを起動し続けるため、リソースとコストが線形に増加してしまう。

Cloudflareはこの課題に対し、V8 Isolateを使った軽量サンドボックスを提供する。Dynamic WorkersとCodemodeを組み合わせることで、ミリ秒単位でサンドボックスを起動し、フルVMよりはるかに少ないリソースで任意のコードを実行できる。

マイクロVMサンドボックス
Linuxベースのフル機能。アプリケーション開発やCLIツールの実行向け
起動時間:秒単位。リソース消費は比較的多い
vs
V8 Isolateサンドボックス
軽量な隔離環境。ファイルシステムも持つが、VMより遥かに小さなフットプリント
起動時間:ミリ秒単位。数万の同時実行も可能

エージェントのセットアップ時にバックエンドタイプとして「isolate」を選択するだけで、この軽量モードに切り替えられる。数万規模の同時エージェントを扱うユースケースでは、コスト効率が数十倍変わる可能性がある。

もちろん、Linuxツールをフル活用する開発エージェントには、引き続きマイクロVMベースのCloudflare Containersを使える。用途に応じて2種類の実行環境を選択できる点が、この統合の実用的な強みだ。

エージェントワークロードのセキュリティ

エージェントワークロードのセキュリティ

エージェントが組織の内部データやサービスにアクセスするとき、最大のリスクは認証情報の漏洩だ。Cloudflareの統合では、アウトバウンドプロキシを使い、サンドボックスから外部へ出る通信に対して動的に認証情報を注入する仕組みを備えている。

この設計のポイントは、エージェント自身はクレデンシャルを知らないことだ。プロキシがゼロトラストベースでリクエストに署名やトークンを付与するため、万が一サンドボックスが侵害されても、認証情報そのものが盗まれるリスクを抑えられる。

エージェント 外部サービスへリクエスト送信 プロキシ 認証情報を注入 内部API 安全に応答
エージェントはクレデンシャルを保持しない  プロキシがゼロトラスト認証を代行する

また、Cloudflare MeshとWorkers VPCを使えば、インターネットに一切公開していない内部サービスにも、ポスト量子暗号で保護されたトンネル経由で接続できる。VPNや踏み台サーバーなしでプライベートサービスと通信できる点は、インフラ担当者にとって大きな利点だろう。

プロキシはテナント単位やエージェント単位でポリシーを適用できる。特定のエンドポイントだけを許可リスト化し、それ以外の通信を遮断するといった細かな制御も、コード数行で実装可能だ。

エージェントに必要なツール群

エージェントに必要なツール群

ブラウザ操作の完全な制御

エージェントがウェブと対話する際、単純なHTTPリクエストでは不十分な場面が多い。JavaScriptを多用するモダンなウェブアプリケーションの操作や、QA用のスクリーンショット取得、フォーム入力の自動化には、実際のブラウザが必要になる。

CloudflareのBrowser Runは、エージェントにプログラム可能なブラウザを与える仕組みだ。検索、実行、スクリーンショット、ページのMarkdown変換など、複数のツールがデフォルトで利用できる。

セッションの録画機能も備わっており、エージェントがブラウザ上で何をしたかを後から完全に監査できる。許可リストや拒否リストを使ったアクセス制御も可能で、野放図なウェブアクセスを防げる。

メール送受信とプライベート接続

エージェントにメールアドレスを割り当て、送受信を自律的に行わせる機能も統合済みだ。Cloudflare Email Serviceと連携し、任意のドメインでエージェントがメールを送信できる。顧客対応の自動化や、転送されたメールへの返信といったユースケースに適している。

内部サービスへの接続にはcall_serviceツールが用意されており、Cloudflare MeshやWorkers VPC経由でプライベートAPIを安全に呼び出せる。Workers AIを使った画像生成ツールも標準で組み込まれており、Claudeのテキスト推論と組み合わせたマルチモーダルなワークフローを構築できる。

カスタムツールの追加

リポジトリをフォークし、独自のツールを追加するのも容易だ。例えばCloudflare R2にファイルをアップロードし、公開URLを返すツールを数行のコードで定義できる。以下はCloudflare Blogで示されたコード例を簡略化したものだ。

defineTool({
  name: "r2_host_file",
  description: "サンドボックスからR2にアップロードし公開URLを取得",
  inputSchema: z.object({
    key: z.string(),
    content: z.string(),
    contentType: z.string()
  }),
  run: async ({ key, content, contentType }, { env }) => {
    await env.PUBLIC_BUCKET.put(key, content, { httpMetadata: { contentType }});
    return `${env.PUB_R2_URL}/${encodeURI(key)}`;
  }
})

Workers AIを使ったエッジ推論や、Dynamic Workersによる動的なアプリケーションホスティング、Artifactsを使ったGit管理の追加など、Cloudflare Developer Platform全体をエージェントの拡張に活用できる。インフラ管理を意識せず、関数を書いてデプロイするだけで機能追加が完了する設計だ。

この記事のポイント

  • Claude Managed Agentsの実行基盤をCloudflare上に構築できるようになった
  • 「頭脳(Claude)」と「手足(Cloudflareサンドボックス)」の分離で、インフラ選択の自由度が向上した
  • V8 Isolateを使った軽量サンドボックスで、ミリ秒起動と低コストの大規模実行が可能
  • アウトバウンドプロキシによるゼロトラスト認証で、エージェントのセキュリティを強化
  • ブラウザ操作、メール送受信、内部サービス接続などのツールが標準装備されている
WooCommerceがClaude連携の実験プラグインを公開、AI店舗分析の新形

WooCommerceがClaude連携の実験プラグインを公開、AI店舗分析の新形

WooCommerceの開発チームが、AIアシスタント「Claude」とECサイトを直接連携させる実験的プラグインを公開した。このプラグインは、単にAIがサイトのデータを読み取るだけでなく、店舗運営者が実際に求める「売上の傾向分析」や「クーポンの効果測定」といった問いに、具体的で意味のある答えを返すことを目指している。

発表元のWooCommerce Developer Blogの記事によれば、これは「Radical Speed Month」と名付けられた社内実験プロジェクトの一環だ。新機能の発表でも、将来のロードマップへのコミットメントでもない。あくまでアイデアを形にし、コミュニティからのフィードバックを得るための試金石である点が強調されている。

実験「WooCommerce for Claude」が解決しようとする課題

実験「WooCommerce for Claude」が解決しようとする課題

AIとWebサービスの連携は、APIを通じて生のデータを取得させるだけでは不十分だ。データの文脈や、事業者にとっての意味まで理解しなければ、役に立つ回答は得られない。

この実験の核心は、「どうすればAIを単なるデータ呼び出しツールではなく、店舗運営の実用的な相談相手にできるか」という問いにある。WooCommerceの開発チームは、この課題に対して3つの仕組みを基盤となるMCP(Model Context Protocol)の上に構築した。

MCPとは、AIモデルが外部のツールやデータソースと安全にやり取りするための共通規格だ。すでにWooCommerceのコアには開発者向けプレビューとしてMCPサポートが組み込まれている。この実験プラグインは、その仕組みを拡張し、AIに対してより深い店舗理解を与えることを狙っている。

従来のAI連携の課題
AIが生の受注データを取得 データの意味や事業文脈を理解できない
「先週の売上は?」という質問 単なる数字の羅列で終わる
WooCommerce for Claudeのアプローチ
事前集計された分析データ 「先週の売上は4%減、要因はカテゴリAの不振」
店舗知識レイヤー 事業内容や商品カタログの構造をAIが事前に把握
従来の課題  新しいアプローチ

このデモで示したように、AIに「考えるための材料」を構造化して与えることが、この実験の設計思想だ。単に問い合わせの窓口を作るのではなく、AIが店舗の状態を理解した上で回答できるようにする。

分析スキル

店舗運営者が本当に知りたい質問に対して、事前に集計された回答を返す仕組みだ。「今週の売上はどうだったか」「どの商品が売上を牽引しているか」「クーポンは効果を発揮しているか」といった質問が想定されている。

重要な点は、これらの分析が商品投稿(wp_posts)の生データを直接参照するのではなく、WooCommerceの分析用参照テーブルに対して実行されることだ。これにより、データベースへの負荷を抑えつつ、高速に意味のある集計結果を返せる。

知識レイヤー

AIがツールを呼び出す前に、店舗のプロフィール、カタログのスキーマ、ポリシー、拡張された商品データをMCPリソースとして露出させる層だ。これにより、AIは「どのような店舗なのか」という文脈を最初から理解した状態で対話を始められる。

たとえば、投資家に店舗を説明するような抽象度の高い質問や、返金が多い注文を洗い出すような具体的な調査にも、前提知識を持って対応できるようになる。

AI準備スコアリングエンジン

商品の完全性、スキーマの網羅率、コンテンツの品質、ポリシーの完全性という4つの要素を重み付けし、0から100のスコアを算出する。その上で、改善すべき項目を優先順位付きのリストとして提示する機能だ。

このスコアは、AIが店舗データをどれだけ正確に解釈できるかの指標となる。データが整備されていない店舗では、AIの回答精度も下がるという前提に立った、実用的な診断ツールといえる。

実際の使用感とセットアップ

実際の使用感とセットアップ

プラグインを導入すると、1つのエンドポイント(/wp-json/woocommerce-claude/mcp)がWordPressの「Abilities」として登録される。別プロセスやcronによる同期処理は一切不要で、MCPリクエストが来たときにだけ動作する省リソース設計だ。

Claude Desktopとの接続は、ワンクリックの.mcpbバンドルファイルで完結する。手動セットアップの場合も、読み取り専用のWooCommerce REST APIキーがあらかじめ埋め込まれたJSONスニペットが店舗ごとに生成されるため、煩雑な設定は不要だ。

接続後は、自然言語で以下のような質問を投げかけられる。

  • 過去7日間の売上が振るわないが、何が変わったのか?商品別、カテゴリ別、時間帯別に分解してほしい
  • 前回のプロモーションは収益を押し上げたのか、それとも定価販売からの付け替えにすぎないのか
  • 新しい投資家になったつもりで、この店舗の全体像を説明してほしい。強み、リスク、成長機会は何か
  • 現在の収益漏れはどこにある?最大の値引き、最大の返金、支払い保留や失敗で滞留している最古の注文を洗い出して
  • 売上のうちリピート購入者の割合は?どの商品が顧客を呼び戻しているのか
  • カタログのAI準備スコアを監査し、最も減点の大きい項目と、最初に改善すべき点を教えてほしい

これらの質問は、単なるデータの抽出ではなく、分析と洞察を求めるものだ。AIが「構造化された店舗知識」を持っているからこそ、意味のある回答が可能になる。

拡張開発者向けの設計思想

拡張開発者向けの設計思想

このプラグインが実験として公開された目的の一つは、エクステンション開発者からのフィードバック獲得だ。プラグインはプロバイダーパターンを採用しており、あらゆる拡張機能がAIの見る知識レイヤーに自らのデータを流し込める。

add_action( 'woocommerce_claude_register_providers', function( $registry ) {
    $registry->register( new My_Extension_Provider() );
});

このコードが示すように、開発者は独自のプロバイダーを登録するだけで、AIが参照できる情報を拡張できる。さらに、AI準備スコアに独自の評価基準を追加したり、出力される商品データをフィルタリングしたりすることも可能だ。

開発チームは、この「プロバイダー + アビリティ + 単一MCPエンドポイント」という設計図が、実際にエクステンション作者が採用したいと思える形かどうかを検証したいと考えている。

Before(ベースのMCP連携のみ)
AIが参照できるのは基本APIの範囲
店舗の文脈や事業知識はAI側にない
After(WooCommerce for Claude導入後)
拡張プラグインのプロバイダー登録 知識レイヤーが拡張される
カスタムAI準備スコア因子を追加 診断精度が向上
エンドポイントは1つに集約 シンプルな構成を維持
Before  After

デモで示したとおり、プロバイダーパターンの追加により、AIが店舗について持つ知識の幅が大きく変わる。このアーキテクチャがコミュニティに受け入れられれば、サードパーティ製プラグインとの連携も大きく加速するだろう。

この実験が探る実用性とリスク

この実験が探る実用性とリスク

開発チームは、この実験が公式機能でも完成品でもないことを明確にしている。Radical Speed Monthの成果物の一部は将来の正式プロダクトになるが、多くはならない。このプラグインがどちらの道をたどるかも、まだ決まっていない。

だからこそ、実店舗や制作会社の環境でのテストが求められている。特に知りたいのは、以下の3つの失敗モードだ。

  • AIが店舗運営者には実行不可能な提案をしてしまわないか
  • 集計データから個人情報や秘匿すべきビジネス情報が漏洩しないか
  • 大規模カタログ(シードされたデモ店舗よりはるかに大きい規模)でのパフォーマンスは許容範囲か

机上の設計では見えない問題を、実際の多様な店舗環境で洗い出すことが、この公開テストの最大の目的だ。

テスト環境と始め方

テスト環境と始め方

リポジトリはGitHubで公開されており、クローン後にcomposer installを実行して有効化するだけで試せる。ローカル開発環境は、npx @wordpress/env start コマンドでWordPress、WooCommerce、そして本プラグインが立ち上がる。

テスト用に、24ヶ月分・5000件の注文データを生成する決定論的シードスクリプトが付属している。これにより、分析機能が十分なデータを基に動作する様子を確認できる。

開発チームは、AIが自信満々に間違った回答をしたケースや、拡張機能の開発者体験に違和感があった場合など、あらゆるフィードバックをGitHubのIssueで求めている。この実験が将来の製品に繋がるかどうかを判断する材料として、コミュニティのテスト結果が重視されているのだ。

この記事のポイント

  • WooCommerce for Claudeは、AIと店舗の新しい連携形を模索するRadical Speed Monthの実験プロダクトである
  • 分析スキル、知識レイヤー、AI準備スコアの3層構造で、AIが「文脈を理解した回答」を返せるように設計されている
  • プロバイダーパターンにより、サードパーティ拡張がAIの知識ベースに自ら統合できる拡張性を持つ
  • 公式機能やリリース予定のものではなく、実店舗環境でのテストフィードバックを目的としている
  • データプライバシーと大規模カタログでのパフォーマンスが、現時点で確認すべき主要な論点である