目的に合わせてWebを組むAgentic Sites、速さ以外に必要な設計

完成ページから、管理された部品へ

イノベトピアが取り上げたのは、AdobeのCarlos Sanchez氏による、既存サイトを情報源としてページを組み替える実演だ。目的に応じて商品、案内、見出しなどのブロックを選ぶ。記事で報告された平均1.1秒やライブでの1.64秒という値は、その実演・評価の条件での数字であり、全利用者の表示時間を保証するものではない。

この説明の技術的な土台を考える際には、AdobeのEdge Delivery Services公式資料が参考になる。AEMの一部としてコンテンツを高速に配信し、HTML、CSS、JavaScriptを用いた開発を支える。既存の管理・配信基盤があることと、実演された自動構成機能の一般提供は区別して扱う必要がある。

本稿で確認した公式資料だけから、Agentic Sitesの一般提供日、利用料金、契約プランは確定できない。新しいサイト運営の考え方を試す材料として読み、完成済み製品の導入案内にはしない。

RAGは情報源を制限するが、誤りを消すわけではない

実演では、既存サイトをRAGの参照元として用いる構成が説明されている。企業が管理する情報を探してから出力を作る方法は、モデルの記憶だけで商品情報を生成させる場合より、参照先を限定しやすい。しかし、古い価格を取得する、条件の一部を落とす、複数商品の仕様を混ぜる、といった失敗は別途確認しなければならない。

運用側が管理する対象も変わる。完成ページだけでなく、各ブロックの利用条件、参照データの版、組み合わせてはいけない要素を用意する。申込条件や契約上の注意を、生成したレイアウトの都合で省かせない仕組みが必要になる。重要な金額や在庫は、文章生成と切り離した確定データから表示する方法も考えられる。

高速な推論と、速いページは同じではない

CerebrasのGemma 4紹介は、高い出力速度と画像入力を組み合わせた処理を説明している。こうした基盤は、対話的なページ構成の待ち時間を短くする候補になる。ただし、モデルのトークン出力速度は、検索、通信、ブラウザの描画、画像の取得まで含む時間ではない。

ページ単位の試験では、最初の表示まで、操作可能になるまで、情報の検証を終えるまでを分けて測りたい。速さと正確さも一つの点数にまとめない。大量アクセス時の待ち時間、再生成の回数、失敗時の固定ページへの切替を含めて、利用者の体験は決まる。

自由に組むほど、変えてはいけない部分が重要になる

本稿の考察として、動的なページでも、問い合わせ先、会社情報、価格条件、アクセシビリティ上の構造などは安定して残すべきだ。利用者によって表示が変わるなら、問い合わせ対応のために、どの情報と版を提示したかを追跡できることも必要になる。

検索エンジンや支援技術に読める基本ページを用意し、その上で目的別の案内を付ける段階的な導入が考えられる。生成に失敗した際に空白になる構成より、管理された静的な情報へ戻せる方が業務を継続しやすい。個人情報を推測して表示を変える場合には、そのデータの扱いも別の確認が要る。

評価には、購入に近い質問だけでなく、条件に合う商品がない場合や情報が欠けている場合も含める。Promptfooの公式ガイドが説明するような、複数のプロンプトとモデルを同じ入力で比べる方法は参考になる。ただし、本稿で外部モデルの評価を実行したわけではない。

Web制作の仕事がなくなるというより、情報を構造化し、利用条件を付け、表示を検証する工程の比重が増す可能性がある。生成回数に応じた費用と、既存のルールベース表示で足りる範囲も比べて導入を判断したい。

AIを使ったサイト運営や公開前確認の相談先・会社情報は、運営会社RO合同会社の公式サイトで確認できる。

参考報道：イノベトピア。実演の数値は参考報道に基づく。配信基盤と推論・評価ツールは上記一次資料を確認し、導入設計への提案は本稿の考察として記した。