AIエージェントフレンドリーなサイトを作るチェックリスト【43項目】

「自社サイトはAI時代に対応できているのだろうか」。

そんな不安を、Web担当・マーケ責任者の方からここ半年で急に多くいただくようになりました。

現在、一つの大きな変化が進行しています。

それは、AIエージェントが、人の代わりに買い物や予約を始めている、という事です。

航空券、ホテル、ECでの購買が、ユーザーの代わりにAIによって実行される時代が、もう始まっています。

つまり、サイト側も以下の2つの変化が必要となっています。

• 自社サイトはAIに「選ばれる側」になれるか
• 自社サイトはAIエージェントが「使いやすい状態」になれるか

そこで本記事では、Google公式のweb.devガイド「Build agent-friendly websites」や、Vercel/MERJの5億回超のクローラー実測データ、そして2026年に表面化したエージェンティック・コマースの最新動向を統合し、エージェントフレンドリーなサイトを作る43項目のチェックリストを整理しました。

印刷で見やすいPDF版の資料も用意しています

【PDF版】エージェントフレンドリーなサイトを作る43項目のチェックリストをダウンロードする 

読み終えた頃には、以下が明確になっています。

• AIエージェントが自社サイトをどう「見て」どう「使う」のか
• 8カテゴリ43項目のうち、自社の型に応じて何から着手すべきか
• 「人間向けのUX」と「AI対応」が同じ方向を向いている理由

なお、自社サイトのエージェント対応度を診断したい方向けに、シュワットではLLMO無料診断サービスにエージェントフレンドリー診断もご用意しています。ぜひご活用ください！

Webサイトに「新しい訪問者」が来ている

これまでWebサイトの訪問者は、基本的に人間とGooglebotなどの検索エンジンクローラーの2種類でした。

しかし2025年以降、第三の訪問者が急速に存在感を増しています。それが AIエージェント（Agentic AI） です。

第三の訪問者：AIエージェントとは？

AIエージェントは、ユーザーの代わりに自律的にWebを操作する存在です。

たとえば対話型AIに、こんな依頼をしたとします。

「来月の金曜夜に東京から福岡へ飛びたい。予算3万円以内で、朝食付きのホテルも一緒に押さえて」

数年前なら、ユーザー自身がGoogleフライト、Skyscanner、複数の航空会社サイト、楽天トラベル、Booking.com、と10タブ以上を行き来していました。

今は違います。AIエージェントが複数サイトを横断巡回し、情報を抽出し、比較表として整理し、場合によっては予約まで実行します。

2026年3月には、Perplexityのブラウザ「Comet」が曖昧なプロンプトから自律的に航空便とAirbnbを比較するライブデモが大きく報じられました。

これからのWebサイトに求められる視点は変わります。

「人間にとって美しいか」だけでなく、「AIエージェントにとって読み取りやすいか」「操作しやすいか」 という評価軸が、新しく加わるのです。

AIエージェントは「情報収集型」と「行動代行型」の2種類に分類できる

AIエージェントは、タスクの目的によって、以下の2つの類型に分類できます。

類型	目的	代表例
情報収集型	引用・要約・回答生成	ChatGPT検索、Google AI Overview、Perplexity Search
行動代行型	購買・予約・フォーム送信	ChatGPT Operator、Perplexity Comet、Amazon「Buy for Me」

情報収集型のAIは、「あなたのサイトを 引用・参照 する」側です。こうしたAIへの対応として求められるのは、構造化された情報・明確な出典・読み取りやすいHTMLです。

行動代行型のAIは、「あなたのサイトで 行動を実行する 」側です。こうしたAIの対応として求められるのは、上記に加えて、ボタンやフォームの操作可能性・予約や決済フローの透明性・在庫や価格情報の構造化などです。

サイト側は両方への対応が必要ですが、自社サイトの性質によって優先度が変わります。

例えば、ECサイトや予約系サイト、求人サイトでは「行動代行型」への対応が事業に直結しますし、BtoBメディアでは「情報収集型」への対応が中心になります。

ゼロクリック化と「AIが人間の代わりに商品を買う」時代

AI Overviews（Googleの生成AI検索結果）やChatGPT検索の普及により、ゼロクリックと呼ばれる、ユーザーが検索結果のリンクをクリックせず、AIの回答内で意思決定を完結させることが増えました。

そして次の段階として、決済・予約まで含めてAIが完結させる流れが、既に始まっています。

2026年4月、AnthropicはClaudeにInstacart、Booking.com、Uber、Spotifyなど15のconnectorsを実装し、エージェンティック・コマース機能を本格展開しました。

PerplexityはPayPal連携で2025年11月25日にチャット内で直接購入できる「Instant Buy」をローンチしています。

つまり、これからのWebサイトは2つの問いに同時に答える必要があります。

• 自社サイトはAIに 選ばれる側 になれるか
• 自社サイトはAIが アクションを完了する場 になれるか

エージェンティック・コマースの台頭｜既に始まった「AIが買う」時代

「AIが買い物や予約をする」というのは、もはや未来の話ではありません。

2026年現在、すでに動いているエージェンティック・コマースの具体例を見てみましょう。

• 航空券＋ホテル＋決済の一体化：Sabreの「Mindtrip Flights」では、チャット経由のフライト予約からPayPal決済までが完結します。
• EC：ChatGPT Operatorは Amazon・eBay・Instacartでの買い物代行が可能です。Amazon「Buy for Me」は外部サイトの商品をAmazonアプリ内で代理購入する機能を、それぞれ提供中です。
• Claudeで横断的な購買・予約：Claudeは2026年4月、Instacart・Booking.com・Uber・Spotifyなど15のサービスを連携。ユーザーが対話するだけで予約や注文を代行します。
• Shopifyの全店舗：2026年3月からShopifyに登録した商品情報が、ChatGPT・Google AI Mode・Copilot・Perplexityなど複数のAIプラットフォーム上に自動で配信され、それぞれの場所で商品として表示・購入可能になる ようになりました。

これまで私たちは買い物や予約をするのにたくさんのタブを開いて比較していましたが、「AIに頼めば、検索から決済まで代わりにやってくれる」時代 に切り替わりつつあります。

弊社の実務感覚でも、ここ数ヶ月で多くのサイトから「自社サイトがAIエージェントから買える状態になっているか診断してほしい」という具体的依頼が増えています。

まとめると、サイト側に求められる対応はこうなります。

• AIエージェントが「選ぶ」段階で勝てる状態にする（構造化・在庫・レビューの充実）
• AIエージェントが商品・サービスを「発見」できる状態にする
• AIから渡されたユーザーが、自社サイトで 決済・予約を完了 できる状態にする（操作可能要素）

また、上記の3つの状態を目指し、サイト内外を最適化する活動こそが、LLMOだとも言えるでしょう。

AIエージェントはサイトをどう見ているのか（3つの認識経路）

Google公式の「Build agent-friendly websites」ガイドによれば、AIエージェントがWebサイトを認識する経路は主に3つあります。

経路	内容	サイト側が意識すべきこと
① スクリーンショット	視覚モデルで画像として解析	ボタンサイズ・色・近接性
② DOM解析	生のHTMLを構造的に読む	セマンティックなタグ選択
③ アクセシビリティツリー	ロール・名前・状態を抽出	ARIA属性・ラベル設計

本章では各経路の特徴と、サイト側が備えるべき観点を解説します。

経路①：スクリーンショット（視覚モデルでの解析）

AIエージェントは、レンダリング済みページのスクリーンショットを取得します。そしてビジョンモデルで要素を識別します。

色・サイズ・近接性などの視覚的手がかりから、要素の重要度を推定します。

つまり、目立つボタンほどAIにも重要視される ということです。

一方で、スクリーンショット解析にはコスト面の弱点があります。画像トークンの消費が大きく、低速かつ高コストなのです。AIエージェントは、この方法だけに依存することは避けます。

経路②：生のHTML（DOM解析）

AIエージェントはDOMツリーも解析します。

要素のネスト関係、ID、クラス、データ属性から構造を理解するのです。

たとえば「Buy Now」ボタンが特定の商品コンテナの中にあれば、AIは「そのボタンが当該商品に紐づく」と推測します。このため、HTML構造そのものが意味を持つ書き方 が重要になります。

経路③：アクセシビリティツリー（A11yツリー）

ブラウザがネイティブに提供するアクセシビリティツリー（A11yツリー）は、AIエージェントにとって最も価値のある経路です。

A11yツリーは、DOMから「ロール、名前、状態」という意味的要素だけを抽出した高密度なマップです。本来はスクリーンリーダー向けに設計された仕組みです。ところが、この仕組みはAIエージェントにとっても極めて有用なのです。

弊社の実務感覚としても、A11y対応が進んでいるサイトは、AIエージェントからの引用率・操作成功率が体感的に高い 傾向があります。

単一モダリティでは不十分

実際のAIエージェントは、これら3つの経路を組み合わせて判断します。

• DOMだけ見ると、<div> で実装されたボタンが認識できない
• スクリーンショットだけ見ると、遷移先のリンク先が分からない
• A11yツリーだけ見ると、視覚的な強調が反映されない

つまり、すべての経路に対して、しっかりと対応する必要があるのです。

43項目チェックリストの全体像と優先順位マップ

ここからが本題です。

43項目を一度に対応するのは現実的ではありません。

本章では 「投資対効果×実装難易度」の2軸マップ と、サイト類型別の優先度 で着手順序を整理します。

8カテゴリ43項目の全体構造

カテゴリ	項目数	主な担当
カテゴリ1：戦略・前提	5項目	マーケ責任者・経営層
カテゴリ2：クロール許可・アクセス制御	4項目	インフラ・SEO担当
カテゴリ3：レンダリング・配信形態	6項目	フロントエンドエンジニア
カテゴリ4：セマンティックHTML・A11y	9項目	フロントエンドエンジニア・デザイナー
カテゴリ5：構造化データ・メタデータ	7項目	SEO担当・エンジニア
カテゴリ6：コンテンツ設計	6項目	コンテンツ責任者・ライター
カテゴリ7：サイト構造・ナビゲーション	4項目	情報設計者・SEO担当
カテゴリ8：新しい標準への対応	2項目	SEO担当・QA

優先順位マップ（投資対効果×実装難易度）

横軸に「実装難易度」、縦軸に「投資対効果」を取った場合、優先度は以下のように整理できます。

サイト類型別の優先度

サイト性質によって、強化すべき領域が変わります。自社の型に合わせて優先度をご確認ください。

サイト類型	主な目的	特に強化すべきカテゴリ
BtoB / メディア型	引用・流入・リード獲得	カテゴリ3（レンダリング）、カテゴリ4（A11y）、カテゴリ5（Article/Organization）、カテゴリ6（コンテンツ）
EC型	商品発見・購入完了	上記＋カテゴリ5の Product/Offer/AggregateOffer/Reviewスキーマ、カテゴリ4の 決済フローの操作可能性
予約系（航空券・ホテル・サロン・レストラン等）	在庫照合・予約完了	上記＋カテゴリ5の Reservation/LodgingBusiness/FoodEstablishment等のスキーマ、在庫・空き状況のリアルタイム反映、カテゴリ4の 予約フォームのアクセシビリティ

着手すべき順序の推奨

弊社の実務経験から、ROI観点では以下の順序での着手を推奨します。

1. カテゴリ3（レンダリング・配信形態） — JavaScript依存を解消しないと、他の施策が全て無効化される土台
2. カテゴリ4（セマンティックHTML・A11y） — 一度直せば長期間効果が持続。人間UXも同時に向上
3. カテゴリ5（構造化データ・メタデータ） — 比較的低コストで実装でき、AI引用率・選択率に直結
4. カテゴリ2（クロール許可・アクセス制御） — 設定不備の検知。1日で完了する場合も多い
5. カテゴリ6・7（コンテンツ・ナビゲーション） — 既存記事のリライト時に並行して進める
6. カテゴリ1（戦略・前提）・カテゴリ8（新標準） — 中長期の体制・標準対応

カテゴリ1｜戦略・前提（項目1〜5）

マーケ・事業責任者がまず押さえるべき、戦略レベルの5項目です。本章では以下を解説します。

#	項目	想定担当
1	AIエージェントを「新しい訪問者」と定義	マーケ責任者
2	AI経由トラフィックの計測体制	アナリスト
3	AI経由「言及数（メンション数）」の測定	マーケ責任者
4	AI経由トラフィックの分離KPI管理	アナリスト
5	情報提供と知財保護の方針整理	経営層

✅ 1. AIエージェントを「新しい訪問者ペルソナ」として定義している

人間ユーザーのペルソナと同様に、AIエージェントの「目的」「動線」「期待する情報」を仮説立てしているかを確認します。

最低限、ChatGPT・Claude・Perplexity・Geminiの4つは想定対象に含めるべきです。

ECサイトや予約系では、ChatGPT Operatorや Perplexity Cometといった「行動代行型」エージェントも別ペルソナとして定義しておくと、対応の解像度が上がります。

✅ 2. AI経由トラフィックを計測する仕組みがある

サーバーログやアクセス解析で、主要AIクローラーの訪問頻度を可視化できる状態にします。対象クローラーは以下です。

• GPTBot
• ClaudeBot
• PerplexityBot
• Google-Extended

あわせて、ChatGPT・Perplexity等のリファラーからの人間トラフィックも分離計測すると、AI経由の実需が見えてきます。

✅ 3. AI経由の「言及数（メンション数）」を測定している

主要LLM上で、自社ブランドや商品名がどれだけ言及されているかを定点観測します。利用できる主なツールは以下です。

• Ahrefs Brand Radar
• Semrush AI Optimization
• 専用ツール（Profound、Otterly.AI など）

SEOの順位と同様に、定量的な改善目標を立てられる状態が望ましいです。

✅ 4. AI経由のトラフィックを人間と分けてKPI管理している

弊社のクライアント支援でも、AI経由ユーザーには特徴的な傾向があります。商品詳細ページ・FAQ・仕様ページに深くランディングする 傾向です。

このため、コンバージョン率や直帰率を一律で評価すべきではありません。AI経由と通常検索経由を分離してダッシュボードを設計するのが、現実的な運用です。

✅ 5. AIへの情報提供と知的財産保護のスタンスが整理されている

robots.txt で、どのAIクローラーに何を許可するかを意図的に決めます。「全部許可」「全部ブロック」の二択ではなく、用途3層（訓練／検索インデックス／リアルタイム取得）×ページ階層別 に方針を持つのが望ましい状態です（3層構造の詳細は項目6で後述）。

なお llms.txt は2026年時点で主要LLMの参照率が極めて低く、Googleも公式に非サポートを表明しています。Limyの90日間調査では主要AIボットによる llms.txt 取得は5億訪問中わずか408件、ALLMO（2026年1月）の検証でもAI Search citation率の改善は確認されていません。Cursor／Claude Code等のIDEエージェント向けには実効性があるため、用途を絞って整備するのが現実的です。

カテゴリ2｜クロール許可・アクセス制御（項目6〜9）

技術と戦略の橋渡しになるカテゴリです。本章では以下を解説します。

#	項目	一行要約
6	robots.txt で主要AIクローラーを明示	許可・拒否の方針を意図的に書く
7	重要ページのブロック設定確認	過去設定の誤りを検出
8	CDN・WAFの誤検知確認	Cloudflare等で弾かれていないか
9	サイトマップへのパス記述	クローラー発見効率を高める

✅ 6. robots.txt で主要AIクローラーを明示的に許可（または拒否）している

主要AIクローラーは2025年以降、提供者ごとに「訓練用／検索インデックス用／リアルタイム取得用」の3層構造へ再編されています。OpenAIは2024年末から3層化、Anthropicも2026年2月20日に3層を公式ドキュメント化しました。用途を一括りで許可・拒否すると「訓練利用は拒否したいが検索表示は維持したい」という一般的な要件が実現できなくなるため、提供者×用途で個別に明示します。

提供者	訓練用	検索インデックス用	リアルタイム取得用
OpenAI	GPTBot	OAI-SearchBot	ChatGPT-User
Anthropic	ClaudeBot	Claude-SearchBot	Claude-User
Perplexity	—	PerplexityBot	Perplexity-User
Google	Google-Extended	—	—
Apple	Applebot-Extended	—	—
Common Crawl	CCBot	—	—

用途別の代表的な使い分けは以下です。

やりたいこと	正しい対応
AI訓練データへの利用を拒否し、検索表示は維持	GPTBot／ClaudeBotを Disallow、OAI-SearchBot／Claude-SearchBot は Allow
ChatGPT Searchで自社を表示させる	OAI-SearchBot を Allow（必須）
Claudeの検索回答に引用させる	Claude-SearchBot を Allow（必須）
ユーザー質問時のリアルタイム取得を許可	ChatGPT-User／Claude-User／Perplexity-User を Allow

robots.txt標準仕様では、未指定のクローラーは「許可」として扱われます。それでも明示する意義は4つあります。

1. 将来クローラー側の規約変更に追従しやすい — 新しいUser-Agentが登場した際の対応漏れを防げる
2. CDN/WAFのブロック設定との整合性が取れる — 「robots.txtでは許可、WAFでは拒否」のような矛盾を発見しやすい
3. 社内ガバナンス上の方針が明確になる — どのクローラーを許可するかの意思決定が記録に残る
4. ページ階層別・クローラー別の細かい制御ができる — 例えば「商品ページはGPTBotに許可、決済関連はDisallow」など

✅ 7. 重要ページが robots.txt や meta robots でブロックされていない

LLMOのご相談で最も多い「初歩的だが致命的」なミスがこれです。

AI向けに見せたいページが、過去の設定で誤ってDisallowされているケースは想像以上に多く発生します。弊社の支援でも、初回診断で1〜2件は必ず発見される項目です。

ECサイトの場合、商品ページがDisallowされているとAIエージェント経由の流入と引用機会を丸ごと失います。

✅ 8. CDN・WAFがAIクローラーを誤ってブロックしていない

Cloudflare、Akamai、AWS WAFなどのレイヤーで「不審なボット」として弾かれていないかを確認します。User-Agentベースで「AIクローラーは別レートリミット」を設定する運用が推奨されます。

✅ 9. robots.txt にサイトマップへのパスを記述している

以下の1行を robots.txt に入れているかを確認します。

Sitemap: https://example.com/sitemap.xml

たった1行ですが、AIクローラーを含むサイトマップ経由でのページ発見効率が、大きく変わります。

カテゴリ3｜レンダリング・配信形態（項目10〜15）｜★最優先カテゴリ

このカテゴリは43項目のなかで、最も投資対効果が高い領域です。ここでつまずくと、他の全ての施策が無効化されるためです。

本章では以下を解説します。

#	項目	一行要約
10	クリティカルコンテンツの初期HTML含有	JS実行前に主要内容が見える状態
11	SSR/SSGの採用	サーバー側でHTML完成
12	View Sourceで内容が見える	目視で簡単に確認可能
13	JS無効でも表示される	最も簡単な検査方法
14	curl での取得検証	UA別の挙動も確認
15	レイアウト安定性（低CLS）	視覚解析の精度向上

✅ 10. クリティカルなコンテンツが初期HTMLに含まれている

VercelとMERJの実測（5億回超のGPTBotリクエスト分析）で、重要な事実が明らかになっています。

GPTBotやClaudeBotはJavaScriptを実行しません。

つまり、クライアントサイドレンダリング（CSR）に依存するSPA構成は、AIエージェントから事実上不可視になります。

ECサイトで「商品名・価格・在庫がJS実行後にしか出ない」状態は、AIエージェントから商品が「存在しないもの」と扱われる致命傷です。

✅ 11. SSR（サーバーサイドレンダリング）またはSSG（静的生成）を採用している

理想は、初期HTMLレスポンス時点で主要コンテンツが完成している状態です。具体的な選択肢として、以下があります。

• Next.js / Nuxt / Remix（SSR・ハイブリッド）
• Astro / Gatsby（SSG）

既存のCSR構成を維持する場合は、Prerender.io等のプリレンダリングサービスでクローラー向けの静的HTMLを生成する選択肢もあります。

✅ 12. View Source（ページのソースを表示）でコンテンツが見える

ブラウザの「ソースを表示」で、主要情報が全てHTMLに含まれていることを目視確認します。確認対象は以下です。

• 商品名
• 価格
• 在庫状況
• 本文
• FAQの回答

ここで見えないものは、AIエージェントにも見えていないと考えてください。

✅ 13. JavaScript無効状態でもコンテンツが表示される

ブラウザの設定でJavaScriptをオフにし、主要情報が読めるか確認します。これが最も簡単かつ確実な、エージェントフレンドリー検査です。

✅ 14. curl で主要ページを取得して内容が確認できる

開発者向けですが、コマンドラインで主要クローラーのUser-Agentを偽装して取得します。

curl -A "GPTBot" https://yoursite.com/page

レスポンスHTMLに本文が含まれているかを確認します。CDN側でUA別に挙動が変わっている場合の発見にも有効です。

✅ 15. レイアウトが安定している（CLSが低い）

頻繁に位置が変わる要素は、スクリーンショット解析の精度を下げます。Core Web VitalsのCLS（Cumulative Layout Shift）改善は、人間のUX向上だけでなくエージェント対応の意味も持つのです。

カテゴリ4｜セマンティックHTML・アクセシビリティ（項目16〜24）

「人間UX」「A11y」「AIエージェント対応」が最も密接に重なるカテゴリです。特にECや予約系のサイトでは、購買・予約フローでの操作可能性が事業に直結します。

本章では以下を解説します。

#	項目
16	ボタンは <button>、リンクは <a>
17	やむを得ず <div> を使う場合の対応
18	<label> と入力要素の紐付け
19	インタラクティブ要素のサイズ
20	cursor: pointer の設定
21	ゴースト要素の排除
22	見出しの論理的階層
23	画像のalt属性
24	WCAG 2.2 AA レベル準拠

✅ 16. ボタンは <button>、リンクは <a> を使っている

<div onclick> や <span> での代用は、AIエージェントが「操作可能要素」と認識できません。Google公式の web.dev ガイドも明確に「<button> と <a> を優先せよ」と推奨しています。

これは行動代行型AIにとって決定的です。「カートに入れる」「予約する」「決済する」のボタンが <div> で実装されていると、エージェントは操作できません。結果として、購入や予約が完了しないという事業損失が発生します。

✅ 17. やむを得ず <div> などを使う場合は role と tabindex を付与している

以下のようにARIAロールとフォーカス可能性を明示します。

<div role="button" tabindex="0">クリック</div>

WAI-ARIA準拠の実装は、AIエージェントの操作精度を直接押し上げます。

✅ 18. <label> と入力要素が for 属性で紐づいている

以下の形式で、ラベルと入力欄が機械的に対応関係を持つ状態にします。

<label for="email">メールアドレス</label>
<input id="email">

これが欠けると、AIエージェントはフィールドの意味を推測する必要があります。特に予約フォームでは、出発地・到着地・日付・人数といった入力欄が機械的に識別できないと、行動代行型AIから「予約不可能なサイト」と判定されます。

✅ 19. インタラクティブ要素の可視サイズが8平方ピクセル以上ある

Google公式の web.dev ガイドは、視覚解析時にフィルタリングされないよう、操作可能要素は最低8平方ピクセル以上のサイズを推奨しています。実用上は、WCAG 2.5.8（AA基準）の24×24 CSS pixels、または44×44pxの「タップターゲット最小サイズ」を目安にすると人間にも優しい設計になります。

✅ 20. cursor: pointer が操作可能要素に設定されている

クリック可能であることをCSS上で表明することは、視覚モデルがアクションエリアを識別する強いシグナルになります。

✅ 21. 透明オーバーレイや「ゴースト要素」で操作要素が隠れていない

z-indexの不整合や、透明レイヤーで重要なボタンが覆われると問題が起きます。視覚解析でその要素が「不活性」と判断される可能性があるためです。

特にECサイトの「お気に入り」「カート追加」など、上層に重なりやすい要素は要注意です。

✅ 22. 見出しが論理的な階層（h1 → h2 → h3）になっている

スキップや逆転がなく、ページの情報構造がDOMだけで理解できる状態が理想です。アクセシビリティツリー経由でAIエージェントが構造を把握する際の、前提条件となります。

✅ 23. 画像に意味のある alt 属性が付与されている

• 装飾画像：alt=""
• 情報を持つ画像：その内容を簡潔に記述

AIエージェントは画像をビジョンモデルで解析することもありますが、alt属性は最も低コストで確実な情報伝達経路です。ECサイトでは商品画像のalt属性が「赤いランニングシューズ Nike 27cm」のように具体的だと、AIによる商品識別精度が向上します。

✅ 24. WCAG 2.2 AA レベルに準拠している

スクリーンリーダー対応は、AIエージェント対応とほぼ等価です。Lighthouseのアクセシビリティスコアが90点以上を、一つの目安としてください。

カテゴリ5｜構造化データ・メタデータ（項目25〜31）

ROI観点で特に高い、技術投資の領域です。ECや予約系サイトでは、ここの実装がエージェンティック・コマースでの勝敗を決めます。

本章では以下を解説します。

#	項目
25	Schema.org（JSON-LD）の実装
26	Organizationスキーマでの企業情報
27	FAQPageスキーマでのQ&A構造化
28	Articleスキーマの著者・日付
29	スキーマと表示内容の整合性
30	title・meta descriptionの設定
31	Open Graph・Twitter Card

✅ 25. Schema.org の構造化データ（JSON-LD）を実装している

ページ種別に応じて、適切なスキーマを実装します。

全サイト共通の基本：

• Article（記事）
• Organization（組織）
• BreadcrumbList（パンくず）
• FAQPage（Q&A）

EC型サイトで追加実装すべきもの：

• Product（商品）：name、image、description、brand
• Offer（販売条件）：price、priceCurrency、availability
• AggregateOffer（複数価格帯）
• Review / AggregateRating（レビュー・評価）

予約系サイトで追加実装すべきもの：

• Reservation（予約）
• LodgingBusiness / Hotel（宿泊）
• FoodEstablishment / Restaurant（飲食店）
• LocalBusiness（地域ビジネス）
• Service / Offer（サービス価格）

Schema.orgはAIにとっての「翻訳レイヤー」であり、最もROIの高い技術投資の一つです。特に行動代行型AIは、スキーマで明示された情報を最も信頼します。

✅ 26. Organization スキーマで企業情報を明示している

以下の情報を含めることで、知識グラフ上での名寄せが正確になります。

• name（名称）
• url（URL）
• logo（ロゴ）
• sameAs（SNSやWikipediaへのリンク）
• address（住所）
• contactPoint（連絡先）

✅ 27. FAQPage スキーマで Q&A コンテンツを構造化している

AI回答は質問応答形式で生成されるため、FAQスキーマは引用される確率を直接押し上げます。専用FAQページだけでなく、ブログ記事内のQ&Aセクションにも実装する価値があります。

ECや予約系では「キャンセルポリシー」「返品・交換」「配送日数」など、購買判断に直結する質問にFAQスキーマを当てることで、エージェント経由のCV率向上が期待できます。

✅ 28. Article スキーマに author / datePublished / dateModified を含めている

著者・公開日・更新日が構造化されていることで、AIは情報の鮮度と権威性を判断できます。E-E-A-T（経験・専門性・権威性・信頼性）のシグナルとしても機能するのです。

✅ 29. 構造化データと表示内容に矛盾がない

スキーマと表示で価格や著者名がズレているケースは要注意です。

NG例：

• スキーマに「Dr. Jane Smith」と書いて本文に「Jane」しかない
• 価格をスキーマと表示で取り違える
• 在庫切れなのにOffer.availabilityが「InStock」のまま

こうしたミスマッチは、AIに「信頼できないソース」と判定される原因になります。特に行動代行型AIは、表示と構造化データの不整合を「不正確な商人」のシグナルとして強く嫌います。

✅ 30. 適切な title タグと meta description を設定している

AIは生成回答での引用元紹介や、検索結果での要約にこれらを利用します。

• タイトル：55文字前後
• ディスクリプション：120文字前後

それぞれ、ページ内容を正確に要約してください。

✅ 31. Open Graph と Twitter Card を設定している

SNSのプレビューだけでなく、AIエージェントがソーシャル文脈でページを引用する際の参照情報となります。

カテゴリ6｜コンテンツ設計（項目32〜37）

エンジニアリングではなく、編集・ライティング側で取り組むカテゴリです。本章では以下を解説します。

#	項目
32	各セクションの独立理解性（チャンキング）
33	結論先出し（PREP法・逆ピラミッド）
34	数字・事例・出典の添付
35	著者情報・更新日の明示
36	専門用語の初出時定義
37	用語表記の統一

✅ 32. 各セクションが独立して理解可能（チャンキング対応）

AIはRAG（検索拡張生成）で、ページから「関連する一部分だけ」を切り出して引用します。そのため、各段落・各セクションが、それ単独で読んでも意味が通る構造が重要です。

✅ 33. 結論を先に書く（PREP法・逆ピラミッド構成）

各見出し直下に結論を配置し、その後に根拠・詳細を続ける構成は、AIが要約を生成する際の引用精度を高めます。弊社シュワットがコンテンツ制作の原則で「簡潔に書く」を掲げているのも、この観点と合致しています。

✅ 34. 主張に必ず数字・事例・出典を添えている

「効果的です」のような抽象表現は避けます。具体例として、以下のように書きます。

• ✗ NG：「効果的です」
• ◯ OK：「弊社の支援事例では平均CTRが2.3倍に改善しました」
• ◯ OK：「Vercel公開データではGPTBotの月間アクセスが急増しています」

定量情報と出典がセットで存在する状態が理想です。

✅ 35. 著者情報・更新日が明示されている

以下が明示されていることは、AIが「権威ある一次情報源」と判断する重要なシグナルです。

• 著者プロフィール
• 専門性を裏付ける経歴
• 最終更新日

✅ 36. 専門用語の初出時に簡潔な定義を添えている

以下のように、初出で略語と意味を併記しておきます。

LLMO（Large Language Model Optimization、大規模言語モデル向け最適化）

ACP（Agentic Commerce Protocol、エージェント経由の取引を標準化するプロトコル）

これにより、AIがエンティティとして正しく認識します。

✅ 37. 用語と表記が全ページで統一されている

「AI Overview」「AIオーバービュー」「AI概要」が混在すると、AIは別概念として扱う可能性があります。社内で表記ルールを定め、特に主要キーワードは厳密に統一してください。

カテゴリ7｜サイト構造・ナビゲーション（項目38〜41）

情報設計レベルで押さえる4項目です。本章では以下を解説します。

#	項目
38	クリーンで意味の読めるURL
39	パンくずリストの実装と構造化
40	内部リンクのアンカーテキスト
41	XMLサイトマップの整備

✅ 38. URL がクリーンで意味が読める

以下のように、URLを見ただけで内容が推測できる設計です。

• ◯ OK：/blog/agent-friendly-checklist
• ◯ OK：/products/running-shoes-nike-pegasus
• ✗ NG：?id=12345&cat=8

パラメータ依存のURLは、AIにとっても人間にとっても解読コストが高くなります。ECサイトでは特に、商品URLにブランド名・商品名を含めることがエージェント経由の認識精度を高めます。

✅ 39. パンくずリストを実装し、構造化データでマークアップしている

BreadcrumbListスキーマを併用することで、ページの階層的位置がAIに明示されます。サイト全体の情報構造の把握にも、寄与します。

✅ 40. 内部リンクが意味のあるアンカーテキストで張られている

以下のように、リンク先の内容を端的に示すアンカーテキストにします。

• ✗ NG：「こちら」「詳細」
• ◯ OK：「LLMO対策の具体的手法」

AIはアンカーテキストを通じて、関連性を学習します。

✅ 41. XMLサイトマップが整備され、最新の更新日が反映されている

<lastmod> が実態と一致していることが、特に重要です。古いサイトマップを送り続けると、AIクローラーの巡回優先度判断が狂います。

ECサイトでは在庫切れ商品の扱い、予約系サイトでは満室・売切商品の扱いをサイトマップ運用に組み込むことを推奨します。

カテゴリ8｜新しい標準への対応（項目42〜43）

最後は、まだ標準化途上の領域です。中長期で取り組むべき2項目を解説します。

#	項目
42	AIエージェントによる動作テスト
43	継続的な検証フロー構築

✅ 42. AIエージェントによる動作テストを実施している

ChatGPT、Claude、Geminiにブラウジング機能をオンにした状態で、自社サイトのURLを渡します。そして、以下のような質問をしてみます。

情報引用の確認：

• 「この製品の価格と機能を教えて」
• 「サポートへの問い合わせ方法を教えて」

行動代行の確認（EC/予約系）：

• 「この商品をカートに入れて、お気に入りに登録して」
• 「明日の予約枠を確認して、〇〇時に取って」

AIが正しく答えられない・操作できなければ、それは具体的な改善ポイントです。可能であれば、ChatGPT Operator や Perplexity Comet のような行動代行型AIでも検証します。

✅ 43. AIエージェント対応の継続的な検証フローを構築している

理想的には、CI/CDパイプラインにAIエージェント検証を組み込みます。そしてデプロイ前に、「主要ページがエージェントから正しく解釈できるか」を自動チェックします。

手動でも、月次でリリース後のAI解釈テストを定例化することで、デグレを防げます。

ACP（Agentic Commerce Protocol）、UCP（Universal Commerce Protocol）といった標準化プロトコルへの対応も、中長期で視野に入れておくべき領域です。現時点で強制ではありませんが、向こう1〜2年で対応必須化する可能性があります。

43項目を実装するための現実的ロードマップ

「43項目もある。自社だけで本当に進められるのか」。ここまで読んで、そう感じた方も多いはずです。

本章では、内製と外部支援の選択軸、そして弊社シュワットがどう関われるかをお伝えします。

内製で進めるべきか、外部に依頼するか

判断軸は2つです。

軸	内製向き	外部支援向き
技術リソース	フロントエンドエンジニア複数名在籍	リソース不足
スピード	半年〜1年の中期で取り組める	3ヶ月以内に成果が欲しい
独自性	業界特化の深いカスタマイズが必要	標準的な対応で十分

迷ったら、まず「カテゴリ3（レンダリング）」と「カテゴリ4（A11y）」だけ外部診断を受けるのが現実的です。ここが整えば、残りは内製でも進められます。

シュワットの支援事例

弊社シュワット株式会社では、BtoB SaaS・EC・予約系・メディア領域でLLMO/エージェントフレンドリー対応をご支援しています。直近の実務感覚としては、以下のような成果が出ています。

• AI Overview経由のサイト流入が前月比1.5〜2倍になったクライアントが複数
• ChatGPT・Perplexityでの自社ブランド言及数が、診断後3ヶ月で倍増した事例
• カテゴリ3・4の初回診断で平均6〜8項目の改善余地を発見
• EC・予約系では、Product/Offer/Reservationスキーマの欠落を解消し、商品ページがAI回答に引用される頻度が向上

診断サービス・コンサルティングのご案内

エージェントフレンドリー対応について、シュワットでは以下の3つのサービスをご用意しています。

1. LLMO無料診断：43項目のうち、優先順位の高い項目をチェック
2. チェックリストPDF：本記事の43項目を実務で使えるシート形式で配布
3. LLMOコンサルティング：戦略立案から実装・運用までの伴走支援

【改めて】エージェントフレンドリーが今、重要な3つの理由

本章ではエージェントフレンドリー対応が今必要な、3つの理由を解説します。

1. AI経由のトラフィックと取引が既に発生している
2. Googleが公式に「エージェント向け設計」を推奨
3. 「人間UX」「アクセシビリティ」「AIエージェント対応」は同じ方向を向いている

それぞれ見ていきましょう。

理由①：AI経由トラフィックと取引が既に発生している

VercelとMERJが公開した5億回超のGPTBotリクエスト分析では、主要AIクローラーのリクエスト量が月次で大幅に増加していることが報告されています。

そして「情報引用」だけでなく、「取引」も既に動いています。

理由②：Googleが公式に「エージェント向け設計」を提唱

Google公式の開発者向けサイト web.dev は、2025年以降「AIエージェントが見るWebサイト」という観点で記事を継続的に公開しています。

特に「Build agent-friendly websites」ガイドは、エージェント向け最適化を実装レベルで記載しており、SEO・アクセシビリティと並ぶ 「第3の設計軸」 として認識されつつあります。

弊社シュワットでも、LLMO関連のご相談件数はここ半年で急増しました。

領域を問わず「AI経由の言及数を増やしたい」「AIエージェント経由の予約に対応したい」という具体的な要件が、提案依頼に標準的に含まれるようになっています。

理由③：「人間UX」「A11y」「AIエージェント対応」は同じ方向を向いている

「人間向けのUX改善とは別に、AI向けの対応もやらないといけない」。そんな印象を持っている方も多いはずです。

しかし結論から言うと、この3つはほぼ同じ方向を向いています。

観点	求められること
人間UX	結論ファースト・明確な導線・読みやすい構造
アクセシビリティ（A11y）	セマンティックHTML・適切なARIA・スクリーンリーダー対応
AIエージェント対応	構造化された情報・操作要素の明示・出典の明確化

スクリーンリーダーが正しく読めるサイトは、AIエージェントもほぼ正しく解釈できます。人間にとって構造が明快なページは、AIにとっても理解しやすいページです。

つまり、エージェントフレンドリー対応は 「AI時代に新たに加わった負担」ではなく、Web本来あるべき基本原則への再コミットメント なのです。

まとめ｜「人間に優しい設計」と「エージェントに優しい設計」は同じ方向を向いている

本記事のポイントを振り返ります。

• AIエージェントは「情報収集型」と「行動代行型」の2類型に分かれる
• 行動代行型AIは既に航空券・ホテル・EC領域で稼働している（Skyscanner、Mindtrip Flights、Mavis、Operator）
• 一方、2026年3月にOpenAIが「discovery」に方針転換しており、楽観論への警鐘でもある
• AIは「スクリーンショット・DOM・A11yツリー」の3経路でサイトを認識する
• エージェントフレンドリー対応は、43項目8カテゴリで整理できる
• 着手順は「レンダリング → A11y → 構造化データ」がROI最大
• サイト類型（BtoB/EC/予約系）によって優先度が変わる
• 「人間UX」「A11y」「AIエージェント対応」は同じ方向を向いている

Google公式が明確に述べているとおり、エージェントフレンドリーなサイトを作るための施策は、ほぼ全てが従来のアクセシビリティ・セマンティックHTML・構造化データの実践と重なります。

つまり、本記事の43項目は 「AI時代に新たに追加された負担」ではなく、Webサイト本来あるべき基本原則への再コミットメント です。

弊社シュワットの実務経験からも、エージェント対応はSEOの否定ではありません。SEOの土台がある会社こそ、最も大きな成果を出せる領域です。

AI Overviewに載るとは、検索上位のさらに上に表示されること。そしてエージェンティック・コマース時代に「選ばれて買われる」サイトになることは、新しいフロンティアでもあります。

このチェックリストは網羅性を重視しているため、全項目を一度に対応するのは大規模サイトでは現実的ではありません。優先順位マップで示した順序で、着手することを推奨します。

エージェント対応の具体的な進め方や、自社サイトの診断にご関心がある方は、お気軽にお問い合わせください。

参考文献

Webサイト技術・エージェント認識：

• Google web.dev「Introduction to agents」
• Google web.dev「Build agent-friendly websites」
• Vercel「The rise of the AI crawler」：https://vercel.com/blog/the-rise-of-the-ai-crawler
• Schema.org 公式ドキュメント：https://schema.org/
• llms.txt 提案標準（Jeremy Howard et al.）：https://llmstxt.org/

エージェンティック・コマース動向：

• Stripe「Agentic Commerce Protocol（ACP）」発表（2025年9月29日）：https://stripe.com/newsroom/news/stripe-openai-instant-checkout
• Skift「Sabre, PayPal, and Mindtrip Partner on Agentic AI Travel Booking」（2026年2月12日）
• Sabre「Mindtrip launches travel’s first all-in-one agentic AI flight booking experience」（2026年Q2ローンチ）
• Ada「Malaysia Airlines Selects Ada’s Agentic Customer Service Platform」（2026年2月24日）
• Skyscanner「Skyscanner app in ChatGPT launches for flights」（2026年2月27日）
• Skift「ChatGPT Bails on Transactions」（OpenAIのcheckout方針転換、2026年3月）
• Conversations on Retail「Anthropic’s Instacart Deal」（2026年4月23日のClaude connectors展開）
• Constellation Research「How three hotel giants are playing agentic commerce」（Marriottの2026年デジタル投資計画）
• Shopify News「winter 26 edition agentic storefronts」（2025年12月10日初発表）
• Rentalscaleup「The Browser is the New OTA」（Perplexity Cometデモ事例）