Adobeのプリンシパルサイエンティスト、Carlos Sanchez氏が示したのは、訪問者の意図を読み取り、その人向けにWebページをリアルタイムで組み立てる「エージェンティックサイト（agentic site）」のプロトタイプです。あらかじめ設定した「アウトドア派」「リピーター」といったセグメントにページを出し分けるのではなく、目の前の訪問者を一人のオーディエンスとして扱う発想です。27

ただし、現時点で確認できるのは動作するデモと関連するAdobe製品群です。訪問者ごとに本番ページを生成する一般提供サービスが、すでに大規模運用されているという意味ではありません。434

デモで何が起きたのか

AI Engineer World's Fair 2026で行われたSanchez氏のセッションは、「Agentic Sites: Building Hyper Personalized Websites」と題されていました。33

デモの題材はコーヒーメーカーのWebサイトです。訪問者が「キャンプで使えるコーヒーメーカー」を探すと、システムはその検索意図を読み取り、アウトドア利用に適したコンテンツ、商品候補、ページの見せ方へと画面を切り替えました。133

重要なのは、AIに白紙からサイトを作らせているわけではない点です。検索語や閲覧行動などのシグナルから訪問者の意図を推定し、企業がすでに保有するコンテンツ群から関連情報を取得したうえで、ページを構成します。234

仕組みは「検索・判断・構成」のループ

簡略化すると、処理は次のように進みます。

1. 意図を推定する：検索語や閲覧状況から、情報収集中なのか、比較検討中なのか、購入に近いのか、あるいはキャンプのような具体的な用途なのかを判断します。
2. 承認済みの情報を取得する：RAG（検索拡張生成）を使い、企業の既存コンテンツ、商品情報、ブランド資産などから関連資料を取り出します。
3. ページの部品を選ぶ：ページ全体を一枚の固定文書として扱わず、ヒーロー、カード、商品フィード、ナビゲーション、CTA（行動喚起）などのブロック単位で選択・調整します。
4. 画面に反映する：推定した意図に合うコピー、商品、レイアウトを組み合わせて、訪問者に表示します。

この方式は、ブランド管理の面でも意味があります。AEMなどの企業コンテンツや承認済みアセットを根拠にすることで、根拠のない商品説明を抑え、既存の編集方針やビジュアルアイデンティティから大きく逸脱しにくくなります。公開されたデモの説明でも、AIがページを無から発明するのではなく、既存コンテンツを取得して再構成する仕組みだとされています。434

CerebrasとGemma 4が支える速度

報告された実装では、GoogleのGemma 4モデルをCerebrasの推論基盤上で動かしています。Cerebrasのモデルカタログでは、Gemma 4 31Bの出力速度は約1,850トークン毎秒とされています。また、CerebrasはGemma 4を使った事例で約2,300トークン毎秒を報告しています。36

この速度が注目されるのは、1回のWebアクセスの中で複数の処理を行う必要があるためです。訪問者の意図を解釈し、情報を検索し、使用する部品を決め、コピーを生成または修正し、結果を返す――という「取得・推論・構成」のループを、オフラインのコンテンツ制作ではなく、対話的な体験の中で実行する必要があります。

もっとも、トークン生成速度とページ全体の表示速度は同じではありません。ネットワーク、検索処理、商品カタログへの問い合わせ、同意確認、キャッシュ、ブラウザー描画、バックエンドからの配信なども、訪問者が感じる待ち時間に影響します。

報告された応答時間とコスト

Sanchez氏の説明についての報道では、キャンプ向けコーヒーメーカーの検索に対して、パーソナライズされたページを1.64秒で生成し、そのうちモデル呼び出しは約1秒だったとされています。別の構成では4.6秒かかったという比較も報じられ、生成コストは1ページあたりおよそ0.01～0.02ドルと見積もられています。1

これらは、公開されたプロトタイプのベンチマークと推定値として読むべきです。監査済みのサービス品質保証や、Adobeが発表した本番向けの料金表を示すものではありません。すべてのページ、訪問者、トラフィック条件で同じ結果になることも意味しません。

1～2秒以内なら何が変わるのか

パーソナライゼーションは、訪問者が「遅い」と感じる前に完了しなければ、体験上のメリットを失います。意図の分類、情報検索、部品の選定、生成、配信までをおよそ1～2秒に収められれば、検索、サイトへの到着、閲覧中の目的の変化に合わせて、その場でページを変えられる可能性があります。

従来の「新規顧客」「リピーター」「アウトドア愛好者」といった大きな区分より細かく、訪問者の直近の目的に応じられるわけです。たとえば、キャンプ用の商品を探しているのか、複数商品を比較しているのか、購入候補をすぐに見たいのかで、表示する商品やCTAを変えられます。

ただし、1～2秒という目標がWebシステム全体の課題を消すわけではありません。同意管理、ID連携、商品・価格情報の検証、検索やカタログの遅延、CDN、ページ描画、障害時の代替表示までを、同じ体験予算の中に収める必要があります。

Adobeの既存製品との関係

このプロトタイプは、Adobeが現在提供するすべてのAI製品と同一ではありません。Adobeが公開しているAEMエージェントは、AEM as a Cloud ServiceおよびEdge Delivery Servicesで利用可能とされており、環境によって提供状況や展開条件が異なります。17

Adobe Experience Platform Agent Orchestratorは、Experience Platformのデータを活用し、Adobe製およびサードパーティー製のエージェントを調整する推論・連携レイヤーとして説明されています。Adobeは同製品の一般提供を発表していますが、一部のエージェント機能については、申請制のアクセスや利用量に応じたトライアルも文書化されています。18192122

関連する機能には、次のようなものがあります。

• Brand Experience Agent：ページの更新、新規コンテンツの作成、既存デジタル体験のモダナイズを支援し、AIによる発見に対応した体験づくりを目指します。202344
• Content Advisor Agent：企業内の関連コンテンツを探し、承認済みの元アセットからビジュアルのバリエーションを作成します。202743
• Agent Orchestrator：Adobeや外部エコシステムのエージェントを管理・連携するプラットフォーム層です。182230

これらは、Adobeがコンテンツ、顧客データ、デジタル体験を軸にエージェント型の技術スタックを構築していることを示します。一方で、Sanchez氏が示した「訪問者ごとのページ組み立て」が、すでに標準機能として広く本番提供されていることを証明するものではありません。

大規模導入までに残る課題

今回のデモは、リアルタイムのページ構成が技術的に可能であることを示しました。しかし、すべてのサイトにとって運用面・経済面で合理的かどうかは、まだ別の問題です。

顧客ごとの検証が必要

企業は、自社のAEMリポジトリ、商品カタログ、ID基盤、同意ポリシー、コンバージョン目標を使って検証しなければなりません。速くページを生成できるかだけでなく、エラーや運用リスクを増やさずに、売上や問い合わせなどの有用な成果を改善できるかが問われます。

公開報道では、このエージェンティックサイトの概念は、まだ顧客サイトへ大規模に展開されていないとされています。4

幅広いシステム連携が必要

本番環境では、推論基盤、コンテンツ管理、顧客データ、ID・同意管理、コマースや商品カタログ、分析、実験基盤、CDN、ブランドアセットの各システムを安定して接続する必要があります。モデルの呼び出しが速くても、価格情報が古い、商品カタログの応答が遅いといった問題は解決できません。

ページ単位のコストをトラフィック規模で検証する必要

1ページあたり1～2セントという金額は小さく見えますが、大規模サイトで訪問者数を掛け合わせれば無視できない費用になります。訪問者の操作のたびにページを再生成するなら、コストはさらに膨らむ可能性があります。

そのため、キャッシュ、承認済みブロックの再利用、再生成する場面の絞り込み、そもそもモデルを呼び出さない条件の設計が重要になります。訪問者全員に固有の体験を返す場合の、Adobeの確定した商用料金モデルは公開情報からは確認できません。

生成された各ブロックにガバナンスが必要

実用的な導入には、少なくとも次の管理策が求められます。

• 利用できるコンテンツソースと検索範囲の制御
• 商品属性、在庫、価格の検証
• 使用可能なレイアウト、コンポーネント、CTAの制限
• ブランドボイスとビジュアルアイデンティティのルール
• アクセシビリティとローカライズの確認
• 禁止表現や規制対象となる主張の管理
• 承認履歴と監査ログ
• 監視、ロールバック、内容のドリフト検知
• 人による確認へ切り替える基準

つまり、この構想の現実的な姿は、制約のないAIサイトではありません。AIが訪問者の現在の意図に応じて、承認済みの部品をどれと組み合わせ、どう調整するかを高速に判断する、管理された構成システムです。

まとめ：プロトタイプから本番運用へ

Sanchez氏のデモは、Webサイトが固定されたページの集合ではなく、訪問者の目的に応じて実行時に判断するレイヤーになり得ることを示しました。Cerebrasの推論基盤とGemma 4は、その判断をWebインタラクション中に実行できる速度へ近づけ、AEMとRAGは、事実性とブランド管理を保つための土台になります。13617

ただし、現時点での見出しは「完成した製品」ではなく「実用性を検証中のプロトタイプ」です。次に問われるのは、実際の商品カタログ、同意要件、アクセシビリティ、ブランド規定、そして大量のトラフィックを前にして、速度・正確性・統制・事業効果を同時に維持できるかどうかです。

Adobeのプリンシパルサイエンティスト、Carlos Sanchez氏が示したのは、訪問者の意図を読み取り、その人向けにWebページをリアルタイムで組み立てる「エージェンティックサイト（agentic site）」のプロトタイプです。あらかじめ設定した「アウトドア派」「リピーター」といったセグメントにページを出し分けるのではなく、目の前の訪問者を一人のオーディエンスとして扱う発想です。27

ただし、現時点で確認できるのは動作するデモと関連するAdobe製品群です。訪問者ごとに本番ページを生成する一般提供サービスが、すでに大規模運用されているという意味ではありません。434

デモで何が起きたのか

AI Engineer World's Fair 2026で行われたSanchez氏のセッションは、「Agentic Sites: Building Hyper Personalized Websites」と題されていました。33

デモの題材はコーヒーメーカーのWebサイトです。訪問者が「キャンプで使えるコーヒーメーカー」を探すと、システムはその検索意図を読み取り、アウトドア利用に適したコンテンツ、商品候補、ページの見せ方へと画面を切り替えました。133

重要なのは、AIに白紙からサイトを作らせているわけではない点です。検索語や閲覧行動などのシグナルから訪問者の意図を推定し、企業がすでに保有するコンテンツ群から関連情報を取得したうえで、ページを構成します。234

仕組みは「検索・判断・構成」のループ

簡略化すると、処理は次のように進みます。

1. 意図を推定する：検索語や閲覧状況から、情報収集中なのか、比較検討中なのか、購入に近いのか、あるいはキャンプのような具体的な用途なのかを判断します。
2. 承認済みの情報を取得する：RAG（検索拡張生成）を使い、企業の既存コンテンツ、商品情報、ブランド資産などから関連資料を取り出します。
3. ページの部品を選ぶ：ページ全体を一枚の固定文書として扱わず、ヒーロー、カード、商品フィード、ナビゲーション、CTA（行動喚起）などのブロック単位で選択・調整します。
4. 画面に反映する：推定した意図に合うコピー、商品、レイアウトを組み合わせて、訪問者に表示します。

この方式は、ブランド管理の面でも意味があります。AEMなどの企業コンテンツや承認済みアセットを根拠にすることで、根拠のない商品説明を抑え、既存の編集方針やビジュアルアイデンティティから大きく逸脱しにくくなります。公開されたデモの説明でも、AIがページを無から発明するのではなく、既存コンテンツを取得して再構成する仕組みだとされています。434

CerebrasとGemma 4が支える速度

報告された実装では、GoogleのGemma 4モデルをCerebrasの推論基盤上で動かしています。Cerebrasのモデルカタログでは、Gemma 4 31Bの出力速度は約1,850トークン毎秒とされています。また、CerebrasはGemma 4を使った事例で約2,300トークン毎秒を報告しています。36

この速度が注目されるのは、1回のWebアクセスの中で複数の処理を行う必要があるためです。訪問者の意図を解釈し、情報を検索し、使用する部品を決め、コピーを生成または修正し、結果を返す――という「取得・推論・構成」のループを、オフラインのコンテンツ制作ではなく、対話的な体験の中で実行する必要があります。

もっとも、トークン生成速度とページ全体の表示速度は同じではありません。ネットワーク、検索処理、商品カタログへの問い合わせ、同意確認、キャッシュ、ブラウザー描画、バックエンドからの配信なども、訪問者が感じる待ち時間に影響します。

報告された応答時間とコスト

Sanchez氏の説明についての報道では、キャンプ向けコーヒーメーカーの検索に対して、パーソナライズされたページを1.64秒で生成し、そのうちモデル呼び出しは約1秒だったとされています。別の構成では4.6秒かかったという比較も報じられ、生成コストは1ページあたりおよそ0.01～0.02ドルと見積もられています。1

これらは、公開されたプロトタイプのベンチマークと推定値として読むべきです。監査済みのサービス品質保証や、Adobeが発表した本番向けの料金表を示すものではありません。すべてのページ、訪問者、トラフィック条件で同じ結果になることも意味しません。

1～2秒以内なら何が変わるのか

パーソナライゼーションは、訪問者が「遅い」と感じる前に完了しなければ、体験上のメリットを失います。意図の分類、情報検索、部品の選定、生成、配信までをおよそ1～2秒に収められれば、検索、サイトへの到着、閲覧中の目的の変化に合わせて、その場でページを変えられる可能性があります。

従来の「新規顧客」「リピーター」「アウトドア愛好者」といった大きな区分より細かく、訪問者の直近の目的に応じられるわけです。たとえば、キャンプ用の商品を探しているのか、複数商品を比較しているのか、購入候補をすぐに見たいのかで、表示する商品やCTAを変えられます。

ただし、1～2秒という目標がWebシステム全体の課題を消すわけではありません。同意管理、ID連携、商品・価格情報の検証、検索やカタログの遅延、CDN、ページ描画、障害時の代替表示までを、同じ体験予算の中に収める必要があります。

Adobeの既存製品との関係

このプロトタイプは、Adobeが現在提供するすべてのAI製品と同一ではありません。Adobeが公開しているAEMエージェントは、AEM as a Cloud ServiceおよびEdge Delivery Servicesで利用可能とされており、環境によって提供状況や展開条件が異なります。17

Adobe Experience Platform Agent Orchestratorは、Experience Platformのデータを活用し、Adobe製およびサードパーティー製のエージェントを調整する推論・連携レイヤーとして説明されています。Adobeは同製品の一般提供を発表していますが、一部のエージェント機能については、申請制のアクセスや利用量に応じたトライアルも文書化されています。18192122

関連する機能には、次のようなものがあります。

• Brand Experience Agent：ページの更新、新規コンテンツの作成、既存デジタル体験のモダナイズを支援し、AIによる発見に対応した体験づくりを目指します。202344
• Content Advisor Agent：企業内の関連コンテンツを探し、承認済みの元アセットからビジュアルのバリエーションを作成します。202743
• Agent Orchestrator：Adobeや外部エコシステムのエージェントを管理・連携するプラットフォーム層です。182230

これらは、Adobeがコンテンツ、顧客データ、デジタル体験を軸にエージェント型の技術スタックを構築していることを示します。一方で、Sanchez氏が示した「訪問者ごとのページ組み立て」が、すでに標準機能として広く本番提供されていることを証明するものではありません。

大規模導入までに残る課題

今回のデモは、リアルタイムのページ構成が技術的に可能であることを示しました。しかし、すべてのサイトにとって運用面・経済面で合理的かどうかは、まだ別の問題です。

顧客ごとの検証が必要

企業は、自社のAEMリポジトリ、商品カタログ、ID基盤、同意ポリシー、コンバージョン目標を使って検証しなければなりません。速くページを生成できるかだけでなく、エラーや運用リスクを増やさずに、売上や問い合わせなどの有用な成果を改善できるかが問われます。

公開報道では、このエージェンティックサイトの概念は、まだ顧客サイトへ大規模に展開されていないとされています。4

幅広いシステム連携が必要

本番環境では、推論基盤、コンテンツ管理、顧客データ、ID・同意管理、コマースや商品カタログ、分析、実験基盤、CDN、ブランドアセットの各システムを安定して接続する必要があります。モデルの呼び出しが速くても、価格情報が古い、商品カタログの応答が遅いといった問題は解決できません。

ページ単位のコストをトラフィック規模で検証する必要

1ページあたり1～2セントという金額は小さく見えますが、大規模サイトで訪問者数を掛け合わせれば無視できない費用になります。訪問者の操作のたびにページを再生成するなら、コストはさらに膨らむ可能性があります。

そのため、キャッシュ、承認済みブロックの再利用、再生成する場面の絞り込み、そもそもモデルを呼び出さない条件の設計が重要になります。訪問者全員に固有の体験を返す場合の、Adobeの確定した商用料金モデルは公開情報からは確認できません。

生成された各ブロックにガバナンスが必要

実用的な導入には、少なくとも次の管理策が求められます。

• 利用できるコンテンツソースと検索範囲の制御
• 商品属性、在庫、価格の検証
• 使用可能なレイアウト、コンポーネント、CTAの制限
• ブランドボイスとビジュアルアイデンティティのルール
• アクセシビリティとローカライズの確認
• 禁止表現や規制対象となる主張の管理
• 承認履歴と監査ログ
• 監視、ロールバック、内容のドリフト検知
• 人による確認へ切り替える基準

つまり、この構想の現実的な姿は、制約のないAIサイトではありません。AIが訪問者の現在の意図に応じて、承認済みの部品をどれと組み合わせ、どう調整するかを高速に判断する、管理された構成システムです。

まとめ：プロトタイプから本番運用へ

Sanchez氏のデモは、Webサイトが固定されたページの集合ではなく、訪問者の目的に応じて実行時に判断するレイヤーになり得ることを示しました。Cerebrasの推論基盤とGemma 4は、その判断をWebインタラクション中に実行できる速度へ近づけ、AEMとRAGは、事実性とブランド管理を保つための土台になります。13617

ただし、現時点での見出しは「完成した製品」ではなく「実用性を検証中のプロトタイプ」です。次に問われるのは、実際の商品カタログ、同意要件、アクセシビリティ、ブランド規定、そして大量のトラフィックを前にして、速度・正確性・統制・事業効果を同時に維持できるかどうかです。