クライアントから昨年10月に連絡をもらいました。彼はパニックに陥っていました。彼のeコマースサイトはアナリティクスに「ダイレクト」訪問として記録された大量のトラフィックを受け取っていましたが、コンバージョンは低下していたのです。サーバーログを1時間ほど掘り下げた後、そのトラフィックの大部分が人間ではなく、AIエージェント、特にショッピングアシスタントとLLM搭載の比較ツールであることに気付きました。彼らは製品ページをクローリングしていましたが、コンテンツを正しく解析できないため、すぐに去ってしまっていました。構造化データは混乱していました。価格はJavaScriptの中に埋め込まれていました。製品名は<h2>に見えるようにスタイリングされた<h3>タグに存在していました。エージェントたちはやってきて、ノイズを見つけて、去っていったのです。
今、私たちはこの状況にいます。AIエージェントは来ようとしているのではなく、すでにここにいて、すでにあなたのサイトを読んでいて、抽出できるもの、できないものに基づいて決定を下しています。そして、Seahawk Mediaで長年にわたって構築または関わった12,000を超えるサイトのほとんどは、これを念頭に置いて構築されていません。あなたのサイトも、おそらくそうではないでしょう。
「エージェント対応」の実際の意味
はっきり言わせてください。エージェント対応というのは、曖昧なマーケティング的意味での「AI対応」を意味するのではありません。マシンがURLに到達して、3層のJavaScriptを実行することなくコンテンツを解析して、探しているものを抽出して、それに基づいて行動できるということです。それだけです。
人間は寛容です。私たちはスキャンして、推測して、料金ページで大きな数字を見れば、それが<div class="fancy-number">で囲まれていても価格であることを知っています。構造化されたワークフローに従うAIエージェントですか？そこまで寛容ではありません。それはシグナル、階層、予測可能性が必要です。
こうした業務を現在行っているエージェントには、OpenAIのブラウジングツール、Perplexityのオンラインモード、LangChainやAutoGenなどのフレームワークで構築されている数十のカスタムエージェントが含まれます。すべてに共通する必要性があります。クリーンで解析可能なセマンティック的に有意義なHTMLと、それをサポートする構造化データが必要です。
本当の問題：JavaScriptファースト・アーキテクチャ
これが最も頻繁に見かけるパターンです。エージェンシーやフリーランサーがReactやNext.js（またはVue、Svelt、どれでもいいのですが）でサイトを構築し、クライアントサイドレンダリングを行い、仕事は完了と考えています。サイトは美しく見えます。Googlebotが今ではヘッドレスChromeレンダラーを内蔵しているため、Googleはある程度はクロールできます。
しかし、ほとんどのAIエージェントはヘッドレスChromeを実行していません。HTTPで生のHTMLを取得しています。コンテンツがJavaScriptの実行後にのみ存在する場合、エージェントは空白ページまたはテキストとしてシリアル化されたローディングスピナーを取得します。
2022年にSeahawkには、React SPAで料率と製品比較セクション全体を構築していたフィンテック系クライアントがいました。SSRもスタティックフォールバックもなし。URLに対してシンプルなcurlを実行したところ、文字通り14行のHTMLが返されました。<div id="root">といくつかのスクリプトタグです。エージェントが見るのはこれです。14行です。
修正は必ずしもJSフレームワークを放棄することではありません。サーバーサイドレンダリング（SSR）またはスタティックサイトジェネレーション（SSG）です。getServerSidePropsまたはgetStaticPropsを使ったNext.js。VueならNuxt。SvelteKit。レガシー設定に固定されている場合でも、Prerender.ioのようなもので重要なページを事前レンダリングするだけでも構いません。コンテンツは初期HTMLペイロードに含まれている必要があります。
セマンティックHTMLはもはやオプションではありません
わかります。2009年からセマンティックHTMLを使えという話は聞いてますよね。でも今、SEOの理由で言っているわけではありません。エージェントがセマンティックタグを使って、何を見ているのかを理解しているから言っているのです。
<article>、<nav>、<main>、<aside>、<header>、<footer>は装飾的ではありません。これらはシグナルです。ページのメインコンテンツを抽出しようとしているエージェントは、まず<main>を探します。ネストされた<div>だけでレイアウトを構築している場合、エージェントは推測する必要があります。推測が悪いエージェントはユーザーに間違った答えを返します。
現在すべてのサイトで監査している項目は以下の通りです。
- 1ページに正確に1つの<main>要素がありますか?
- 見出しが論理的な階層(<h1>から<h2>から<h3>へ)に従い、レベルをスキップしていませんか?
- ナビゲーションメニューが<nav>要素に含まれていますか?
- 補足的なコンテンツ(サイドバー、関連記事)が<aside>に含まれていますか?
- アイテムのリストが実際に<ul>または<ol>で、<div class="item">の羅列ではありませんか?
これらは基本的なことのように感じられます。しかし実際のところ、私がレビューするWordPressサイトの60%は、このうち少なくとも3つに失敗しています。見出しの階層に関しては、ほぼ全例といえます。デザイナーが<h3>を大きく、<h2>を小さく見えるようにスタイル設定し、誰も下のマークアップを修正しないのです。
Schema Markup: ここで実際の作業をしましょう
ここはほとんどのガイドが一般的になります。できるだけそうならないように努めます。
Schema.org構造化データは、エージェント(検索エンジンなど)にページの内容だけでなく、そのタイプが何であるかを伝えます。製品か、レシピか、地元企業か、FAQか、イベントか。そして、そのデータを散文を解析することなくエージェントが消費できる形式で提供します。
現在のところ、私の経験では最も重要なタイプは次のとおりです:
- 商品（オファー、価格、在庫状況、この3つすべてを常に含める）
- ローカルビジネス（単なるアドレス文字列ではなく、openingHoursSpecification と地理座標を含める）
- 記事（datePublished、dateModified、および著者を単なるプレーンテキストではなく Person タイプとして含める）
- FAQPage（以下を参照）
- BreadcrumbList（過小評価されているが、エージェントにサイト階層のマップを提供する）
- HowTo（チュートリアルまたはプロセスドキュメンテーションを公開する場合）
WordPress サイトの場合、基本的には Yoast SEO または Rank Math を使用してから、それらがカバーしていないものについては <script type="application/ld+json"> ブロック内でカスタムスキーマを手動で拡張します。使うべきフォーマットは JSON-LD です。RDFa ではなく、microdata でもなく、JSON-LD です。マークアップをクリーンに保ち、エージェントはプレゼンテーション層に手を加えることなくそこからデータを取得できます。
2021年に私が犯した過ちの1つは、クライアントの商品ページにスキーマを配置しましたが、価格が「見積もり依頼」だったため price フィールドを空のままにしてしまったことです。スキーマバリデーターはそれをパスしました。しかしエージェントは空白の価格を抽出してユーザーに「価格：不明」として返し、信頼を失ってしまいました。修正方法は、minPrice / maxPrice を使った現実的な価格範囲を含めるか、offers ブロックを完全に削除することでした。部分的なデータは、データなしより悪い場合があります。
コンテンツ構造：スキャン可能な抽出のために書く
エージェントがどのように散文を読むかについて、ポイントはこうです。彼らはあなたのように読みません。彼らは質問への回答を探し、取り出すことができる事実を探し、主張間の明確な関係性を探しています。
つまり、コンテンツ構成は答えを最初に配置すべきということです。「配送にはどのくらい時間がかかるか？」と誰かが（あるいは何かが）尋ねた場合、ページには「配送時間」といった見出しがあり、その直下の最初の文で実際の数字を述べるべきです。倉庫運用についてのコンテキストの段落ではなく、数字を最初に、その後にコンテキストを置くのです。
クライアントサイトでこのようにコンテンツを構成し始めました。各セクションの逆ピラミッドのようなものです。
- 見出し直下の最初の文で事実または答えを直接述べる
- 1～2文のサポートコンテキストを追加する
- トピックが必要であれば、より詳細なリソースにリンクする
以上です。導入段落はいりません。「良い質問ですね。このトピックを一緒に探索しましょう」といったものも不要です。エージェントはそのようなノイズをスキップし、実際の答えがどこから始まるのか誤認識することもあります。
昨春に再構築した旅行サイトでは、約6週間かけて80記事をこのように再構成しました。これらのページのPerplexity引用が目立って増えました。さらに重要なのは、引用が指していた答えが実際に正確だったということです。関連する事実が見つけられたからです。
Robots.txt、llms.txt、アクセス制御
こちらはより新しいものです。llms.txtというファイルをドメインのルートに配置する、まだ標準ではない成長中の慣例があります。Jeremy Howardが提案した考え方で、LLMに対してサイトの最も重要なコンテンツとアクセス設定を含むプレーンテキストのマップを提供するというものです。クローラーボットではなく言語モデルエージェント向けに英語で書かれた robots.txt のようなものと考えてください。
実装すべきか？正直なところ、そうすべきです。書くのに20分かかります。サイトがエージェント対応であることを示す信号になりますし、より多くのエージェントがそれを探すようにトレーニングされるにつれ、意味のある信号になります。
robots.txtについて具体的に言えば、意図的であること。サイト所有者の中にはAIクローラーをすべてブロックするのが反射的になっている人もいます。それはあなたの判断ですが、一括ブロックはあなたのコンテンツがAIが生成する回答にも表示されなくなるということです。つまり、配信チャネルを手放しているわけです。2005年にGooglebotをブロックすることをどう考えたかと同じように考えてください。おそらく良い考えではないでしょう。
内部リンクとクローラアーキテクチャ
ワークフローに従うエージェントは1ページに着陸するだけではありません。リンクをたどります。内部リンク構造の質が、エージェントが実際にサイトを巡回してその意味を理解できる程度を決めます。
内部リンクが不十分だと、エージェントはサイトの1ページか2ページをインデックスしてから停止します。あなたが提供するものの全体像は得られません。
良い内部リンクは以下を意味します：
- すべての重要なページがホームページから3クリック以内でアクセス可能である
- アンカーテキストが説明的であり、「ここをクリック」や「詳しく読む」ではない
- 関連コンテンツがウィジェットサイドバーだけではなく、本文にコンテキストとして含まれている
- 孤立したページが存在しない（もしくは存在しても、あなたがそれを認識しており、そのまま置くことを意識的に選択している）
クライアントのサイトでエージェント可読性作業を行う前に、Screaming Frogのクローリングを実行しています。孤立ページレポートだけでも、クライアントが公開済みで検出可能だと思っているコンテンツが実は違うことが明らかになることがほとんどです。あるクライアントには34ページの孤立ページがありました。そのメインケーススタディが含まれていました。誰もそれらにリンクしていませんでした。エージェントも人間も。
よくある質問
サイト全体をエージェント対応に作り直す必要がありますか?
いいえ。まずは最もトラフィックが多いページと、コンバージョンに直結するページから始めてください。通常はホームページ、メインのサービスまたは商品ページ、そして現在ランキングしていてリードを生み出しているコンテンツです。まずこれらを正しく設定してください。サイト全体の監査は最終的には有用ですが、最初の段階ではそこから始めません。
スキーママークアップは実際にAIエージェントの回答に役立ちますか?
クライアントサイト全体で観察した結果から言えば、そうですね。構造化データを抽出するエージェントは、スキーマが存在するとき、より正確な回答を返し、ソースをより確実に属性付けします。とはいえ、これは魔法のスイッチではありません。基礎となるコンテンツは依然として正確で、よく構造化されている必要があります。スキーマはエージェントがデータを見つけて信頼するのを助けます。悪いデータを修正することはできません。
ペイウォールのあるサイトはどうですか?
Article タイプで isAccessibleForFree スキーマプロパティを使い、hasPart / isPartOf パターンを使ってどのセクションがペイウォール対象かを示してください。これでエージェントに何を使用できるのかを伝えます。Googleのペイウォールコンテンツ構造化データに関するドキュメントではこれを明確に説明しており、同じロジックが非Googleエージェントにも適用されます。
llms.txt は広くサポートされていますか?
普遍的ではありません。しかし実装するコストはほぼかかりませんし、llms.txt のような規約を早期に採用すれば、通常は報酬を得られます。2024年初期からSeahawkクライアントサイトに追加しています。現在は小さなシグナルです。12ヶ月後にはより重要になります。
エージェントが自分のサイトを読めるかどうかをテストするには?
ターミナルで curl -A "Mozilla/5.0" [your URL] を実行して、返ってきた内容を確認してください。メインコンテンツがその出力に含まれていなければ、レンダリングの問題があります。次に、ページを Google の Rich Results Test でスキーマ検証を実行します。そして Chrome の Lighthouse アクセシビリティ監査をチェックしてください。エージェントの読み取り可能性とアクセシビリティは、ほとんどの人が認識しているよりも重なっているからです。
---
ウェブは人間のために構築され、その後、検索エンジン向けに改造されました。今、別の改造が必要です。今回は、人間がブラウズしない方法でブラウズしないエージェント向けです。これは危機ではありません。次のラウンドの作業です。率直に言うと、ほとんどは、サイトを人間にとってもより良くする良い慣行です。マークアップがよりクリーン、コンテンツがより明確、JavaScript のスプロールが少ない。おそらく、どちらにせよ実施すべきでした。