Agent Readinessは新しいWeb標準になる, Cloudflare動向から読む実装指針
Cloudflareが公開したAgent Readiness scoreは、検索最適化の次に来る「エージェント最適化」の本格化を示しています。ブラウザ向け最適化、検索クローラ向け最適化に続き、次はAIエージェント向けの契約設計が求められる段階です。
2026年4月のCloudflare発信では、特に次が重要でした。
- Agent ReadinessスコアとRadarの採用状況データ
- robots拡張、markdownネゴシエーション、機械可読カタログなど標準群
重要なのは、これを単なるSEOの拡張だと見ないことです。現在のエージェントは、比較、問い合わせ、購入補助、業務操作の入り口になりつつあります。エージェントが読めない、認証できない、操作できないサイトは、ユーザー到達前に機会損失が発生します。
いま起きている変化
検索時代は「見つけてもらう」最適化が中心でした。エージェント時代は、見つかった後に完了できるかが主戦場になります。
ここでいう完了とは、以下を安全に満たすことです。
- 情報を誤読なく解釈できる
- 必要な認証フローに到達できる
- 意図した操作を機械的に実行できる
- 失敗時の再試行ルールが明確
最低限の5チェック
- ポリシー明示性: robotsやコンテンツシグナルが曖昧でない
- 機械可読性: markdown/構造化レスポンスの提供
- 機能発見性: APIカタログや契約情報が追える
- 認証・課金経路: エージェントが実際に通れる設計
- 失敗セマンティクス: status codeと再試行指針が一貫
実務では3〜5が弱点になりやすいです。理由は、従来のクローラ前提設計のままだからです。
推奨パターン: Dual Surface
有効なのは、配信面を2層化する設計です。
- Human Surface: リッチUI、JS中心、体験最適化
- Agent Surface: 決定的なテキスト/markdown、安定した操作エンドポイント
ただしコンテンツ源泉とポリシーは共通化します。別管理にすると、説明内容と実操作の乖離が発生し、誤作動リスクが上がります。
運用で起きる3つの事故
1. 過剰公開
「エージェント対応を急ぐ」過程で、内部資料や未安定APIを露出しがちです。分類タグとdeny-by-defaultで先に境界を作るべきです。
2. 参照元不整合
エージェント経由で要約流通が増えるほど、正規URLや引用整合が重要になります。Canonical運用とリダイレクト整備を同時に進める必要があります。
3. 可観測性不足
既存Web分析はエージェント成功率を測れないことが多いです。最低でも次を追加します。
- エージェント系UA別リクエスト量
- 意図別の完了率
- 認証失敗率
- エージェント起点の課金/CVR
90日導入プラン
- 1〜15日: 主要URLの棚卸しと現状スキャン
- 16〜35日: 高価値ページでポリシー信号とmarkdown対応
- 36〜60日: 能力カタログ公開、機械操作エンドポイント整備
- 61〜90日: 完了SLOとエラーバジェット運用開始
避けるべき進め方
- 「AI向けLP」だけ作り、実際の操作契約を整備しない
- 人間向け導線に依存した認証フローのまま放置
- API挙動変更時に機械向けバージョン通知を出さない
まとめ
Agent Readinessは、モバイル対応が必須化したときと同じ種類の転換点です。今のうちに機械可読契約と運用監視を整える企業ほど、流入効率とサポート効率を先に積み上げられます。
参考リンク:
