エージェントの Web 互換性はアドオン機能からデフォルト要件に移行しています

通常のコンテンツはブラウザに表示されますが、多くの場合、エージェント プログラムに渡されるときに完全に読み取ることができません。ページを開くことができるからといって、そのページを実際に利用できるわけではありません。人が見ることができるからといって、機械が安定して読み取り、検証、追跡できるとは限りません。

この問題は、かつては「サイトマップを埋める」とか「記事ページに構造化データを追加する」といった副次的な問題として捉えられていました。もはやコーナーではない。パブリック サイトが AI クローラー、自動検索、エージェント ベースのワークフローに直面すると、互換性のあるオブジェクトは単なるブラウザーや検索エンジンではなく、セマンティクスに基づいてページを分割し、リンクに基づいてジャンプし、ステータスに基づいて実行を継続できる一種のクライアントでもあります。ページが人間の読者に対してのみフレンドリーでありながら、そのようなクライアントに対する罠で満ちている場合、そのページは互換性が不完全な Web サイトのように見え始めます。

ページを開くことができるからといって、そのページを読み取ることができるとは限りません。

通常、最初の問題はコンテンツの品質ではなく、コンテンツの出力方法にあります。

ページがクライアント側のレンダリングに本文を埋め込み、アコーディオン パネルのキー フィールドを非表示にし、明示的な URL を使用せずにスクロール フローにページネーションを作成し、テーブルを画像にレンダリングする場合、エージェント プログラムは推測に頼ることしかできません。人間の場合、間違った推測は段落の欠落を意味する可能性があります。機械の場合、間違った推測によってその後のアクションが誤った方向に進む可能性があり、今後さらにいくつかのステップを進めると、間違った理解に沿って進むだけになります。

この種の問題は、ドキュメント サイトやコンテンツ サイトで特に顕著です。人間の読者は視覚的なレイヤーをたどり、コンテキストを自分自身で完成させます。エージェントはそうではありません。エージェントに表示されるのは、DOM、ヘッダー階層、リンク関係、フォーム コントロール、ステータス コード、およびクロール可能なテキストです。本文がこれらの基本的な信号から切り離されている場合、ページは厄介な状態で表示されます。モダンに見えますが、実際には不安定です。

過去にシングルページ アプリケーションを移行する場合、多くの場合、このレイヤーが最初に公開されました。最初の画面が表示され、対話は可能ですが、マシンがシェルをキャプチャするため、スクリプトが終了するまで実際のテキストは表示されません。遅延読み込み、無限スクロール、さまざまな「展開して表示」のデザインと組み合わせると、コンテンツ ページは一連の偶発的なイベントになります。ブラウザ ユーザーにとって、これはわずかな速度の低下にすぎません。エージェントにとって、それは信頼性の低いエントリの連鎖です。

マシンが望んでいるのは、視覚的なコンテンツではなく、安定した入り口です。

サイトを「エージェント対応」にすることは、新しいトリックを追加するのではなく、基本的に互換性の層を追加することです。

この互換性層の最も価値のある側面は、ページを「マシン用であるかのように見せる」ことではなく、最も基本的な事実、つまり、これがどのページであるか、テキストがどこにあるのか、現在のステータスは何か、ジャンプを続行できるかどうか、失敗した場合に何を返す必要があるのか​​を明確に記述することです。これらの事実が不安定である限り、エージェントは繰り返し境界をテストします。

コンテンツ サイトで最初に取り組むべき最も価値のあることは、通常、次のことです。

• テキストは、スクリプトに依存せずに、HTML から直接アクセスできる必要があります。
• タイトル階層は安定している必要があり、視覚的なスタイルが意味構造を置き換えないようにする必要があります。
• ページネーション、フィルタリング、および検索結果には、フロントエンド状態にのみ存在するのではなく、共有可能な URL が必要です
• 画像、表、コード ブロックには、読みやすい代替テキストまたは元のテキストが必要です
• 正規、サイトマップ、およびフィードの基本的なエクスポートはクリーンである必要があり、大量の一時パラメーターが混合されていない必要があります。

これらは決まり文句のように聞こえるかもしれませんが、現在ではその意味が変わりました。以前は、これらは検索エンジンとアクセシビリティのために追加されていました。現在、これらは、エージェントが安定してコンテンツを見つけ、ページ間の関係を判断し、手動プロンプトなしで次のステップに進むことができるように追加されました。それらはすべて同じことを示しています。ページは、1 回限りの視覚的な結果ではなく、別のクライアントによる明確な入力として扱われる必要があるということです。

これが、「AI ボタン​​の追加」があまり役に立たない理由です。ボタン自体はページをより使いやすくするものではありません。せいぜい、アクションを新しいエントリにラップするだけです。最下層が依然として視覚的なレイアウトと一時的な状態に依存して理解を維持している場合、エージェント プログラムは、更新、ジャンプ、ロールバック、および権限の変更時にグリップを失います。

インタラクションはプロンプトで停止するだけでなく、アクションを完了する必要があります

ページがコンテンツ表示のみを目的としている場合、互換性の問題は比較的簡単に対処できます。インタラクションや操作のレベルとなると、問題はさらに難しくなります。

エージェントが本当に必要とするのは、「ほぼ十分」ではなく、明確な行動境界です。送信、確認、取り消し、ダウンロード、サブスクライブ、ジャンプ、エクスポートなどのアクションには、明確な前提条件、失敗時の戻り値、および追跡可能な結果が含まれていることが望ましいです。アクションに多数のポップアップ、プロンプト、二次確認が混在している限り、マシンは何度も同じ場所でスタックしてしまいます。

ここから、公開サイトと内部システムの違いが大きくなり始めます。パブリック サイトは消耗品に直面し、内部システムは権限とリスク管理に直面します。前者は、外部クライアントが迂回路を回避できるように、情報構造とアクション セマンティクスを安定させるのに適しています。後者は、特に資金、公開、削除、許可の変更が関係する場合、「エージェントと互換性がある」ために境界を緩和すべきではありません。私たちは依然として保守的であるべきところでは保守的でなければなりません。

つまり、これはすべての Web ページをマシン インターフェイスに変換するということではありません。より現実的なアプローチは、本来外部での利用を目的としたページを、安定した検証可能で再生可能な入り口に変えることです。記事ページ、ドキュメント ページ、ナレッジ ベース、ヘルプ センター、オープン API、パブリック検索結果が最初に影響を受け、最初にメリットが現れます。

このレベルの互換性には明確な境界があります

エージェント対応は、万能の目標ではありません。

完全なイントラネットのバックエンド、強力な権限制御を備えたビジネス システム、ライフ サイクルの短いアクティビティ ページ、および一般消費用のコンテンツ ステーションは、同じレベルにありません。前者は制御を重視し、後者は可読性、インデックス作成可能性、追跡可能性を重視します。これら 2 種類のシステムを「マシンを使用可能にする」同じ標準セットに強制的に適用しても、最終的には管理コストが増加するだけです。

しかし、公開サイトで何も変わっていないふりをし続けるのは困難です。 AI クローラーはますますページを直接読み取るようになり、エージェントのワークフローは構造化されたコンテンツと安定したアクションにますます依存するようになります。サイトが依然として「人々に見られれば十分である」という考えに固執している場合、遅かれ早かれ、コンテンツの配布、検索、アーカイブ、自動統合に亀裂が生じるでしょう。

したがって、この変更は互換性のアップグレードに似ています。以前は、フロントエンドはさまざまなブラウザ、さまざまな画面、さまざまなネットワークを考慮する必要がありました。現在は、ページを独自に分割し、リンクをたどり、ステータスを検証できるクライアントの種類も考慮する必要があります。この互換性レイヤーが追加されると、サイトは真に新しいデフォルト要件に入ることができます。つまり、表示できるだけでなく、安定して利用できる必要があります。