- はじめに——「AIに見つけてもらう」の次は「AIエージェントと正しく対話できるサイト」
- 前提知識——AIがあなたのサイトにアクセスする「3つのパターン」
- 【第1章】robots.txt——AIクローラー別の戦略的制御
- 【第2章】llms.txt——LLM向けサイト要約ファイルの書き方
- 【第3章】AIブラウジングエージェント向けのDOM設計
- 【第4章】MCPサーバー経由で自社データを安全に公開する
- 【第5章】レート制限と負荷対策——AIトラフィックから自社サイトを守る
- 【第6章】構造化フィード——AIに「正しい情報」を届ける
- 実践チェックリスト——今すぐ着手できる15項目
- よくある質問(Q&A)
- まとめ——「AIフレンドリー」は次のモバイルフレンドリー
- 参考リンク
はじめに——「AIに見つけてもらう」の次は「AIエージェントと正しく対話できるサイト」
「ChatGPTやPerplexityに自社の情報を引用してもらいたい」——AEO(AI Engine Optimization)の第一歩として、構造化データやFAQマークアップの整備に取り組む企業が増えています。
しかし2026年現在、AIとWebサイトの関係は「引用される」から「インタラクションされる」へと急速にシフトしています。
Claude in Chrome(Anthropicのブラウジングエージェント)やChatGPT agent(OpenAI)は、人間と同じようにブラウザを操作してサイトを訪問し、情報を取得し、ときにはフォーム送信やAPI呼び出しまで行います。さらに、MCP(Model Context Protocol)を介してAIエージェントが企業のデータに直接アクセスするユースケースも増えています。
つまり、いま求められているのは「AIに読まれやすい記事の書き方」だけではありません。AIクローラー、AIブラウジングエージェント、MCPサーバーという3つのアクセスパターンに対応した、サイト全体のアクセシビリティ設計です。
この記事では、robots.txt / llms.txt の設計から、AIブラウジングエージェント向けのDOM設計、MCPサーバー経由のエンドポイント設計、レート制限と構造化フィードまで、中小企業のWeb担当者が「今すぐ着手すべき」技術的な対応を網羅的に解説します。
前提知識——AIがあなたのサイトにアクセスする「3つのパターン」
まず、AIがWebサイトにアクセスする方法は、2026年現在、大きく3つに分類できます。それぞれの特性を理解することが、適切な対応の第一歩です。
パターン1:AIクローラー(学習・インデックス用)
従来のGooglebotと同じように、AIプロバイダーが運用するボットがWebサイトを巡回し、コンテンツを収集するパターンです。主な目的はモデルの学習データ収集とAI検索のインデックス構築です。
代表的なクローラーには以下があります。
| クローラー名 | 運営元 | 主な目的 |
|---|---|---|
| GPTBot | OpenAI | モデル学習 |
| OAI-SearchBot | OpenAI | ChatGPT検索のインデックス |
| ChatGPT-User | OpenAI | ユーザー指示によるリアルタイム取得 |
| ClaudeBot | Anthropic | モデル学習 |
| Claude-SearchBot | Anthropic | Claude検索のインデックス |
| Claude-User | Anthropic | ユーザー指示によるリアルタイム取得 |
| PerplexityBot | Perplexity | AI検索のインデックス |
| Google-Extended | Gemini学習(Google検索とは別) | |
| Applebot-Extended | Apple | Apple Intelligence学習 |
| Bytespider | ByteDance | TikTok AI機能向け学習 |
重要なポイント:2026年2月のAnthropicのドキュメント更新により、AIクローラーは「学習用」「検索用」「ユーザー指示用」の3階層に分化しています。OpenAIも同様の3階層構造(GPTBot / OAI-SearchBot / ChatGPT-User)を採用しており、「AIクローラーをまとめてブロック」という従来の方法では、意図しない結果を招く可能性があります。
パターン2:AIブラウジングエージェント
Claude in Chrome、ChatGPT agent、Perplexity-Userなど、実際のブラウザを操作してWebサイトを閲覧するAIエージェントです。人間のユーザーと同じようにページを表示し、DOM(Document Object Model)を解析して情報を取得します。
従来のクローラーとの最大の違いは、JavaScriptを実行してレンダリング後のページを「見る」ことができる点です。つまり、SPA(シングルページアプリケーション)やJavaScriptで動的に生成されるコンテンツにもアクセスできます。
パターン3:MCP経由のAPI/データアクセス
MCP(Model Context Protocol)は、2024年11月にAnthropicが公開し、2025年12月にLinux FoundationのAgentic AI Foundation(AAIF)に移管されたオープン標準プロトコルです。2026年4月現在、月間9,700万回のSDKダウンロード、10,000以上の公開サーバーが存在し、OpenAI・Google・Microsoft・AWSを含む146組織が参加しています。
MCPを使えば、AIエージェントは企業の提供するデータやサービスに、構造化されたインターフェースを通じて直接アクセスできます。Webサイトの画面を「見る」のではなく、データを「取得する」パターンです。
【第1章】robots.txt——AIクローラー別の戦略的制御
robots.txtは、Webサイト管理者がクローラーのアクセスを制御する最も基本的なメカニズムです。2026年のAI時代において、robots.txtの設計は従来のSEOとは異なる戦略的判断が必要になっています。
「まとめてブロック」が通用しない理由
2024年頃、多くのサイト管理者がAIクローラーを一括でブロックする対応を取りました。しかし、2026年現在のAIクローラーは「学習用」と「検索用」が分離されています。
学習用ボット(GPTBot、ClaudeBot、Google-Extended)をブロックしても、検索用ボット(OAI-SearchBot、Claude-SearchBot)は独立して動作します。逆に、検索用ボットまでブロックすると、ChatGPTやClaudeの検索結果に自社サイトが表示されなくなる可能性があります。
OpenAIは公式ドキュメントで、OAI-SearchBotをブロックしたサイトはChatGPT検索の回答に表示されないと明言しています。Anthropicも、Claude-SearchBotのブロックは「表示が減る可能性がある」としています。
推奨:3パターンのrobots.txt設計テンプレート
パターンA:AI検索での露出を最大化したい場合(中小企業・メディア向け)
# 従来の検索エンジン
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /
# AI検索用クローラー — 許可(AI検索結果に表示される)
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: Claude-User
Allow: /
User-agent: PerplexityBot
Allow: /
# AI学習用クローラー — 許可(学習データとして使われる代わりに露出が増える)
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: Google-Extended
Allow: /
User-agent: Applebot-Extended
Allow: /
# 管理領域は全ボット共通でブロック
User-agent: *
Disallow: /admin/
Disallow: /api/
Disallow: /wp-admin/
Sitemap: https://yoursite.com/sitemap.xml
パターンB:AI検索には載りたいが学習利用は拒否したい場合(出版・メディア向け)
# AI検索用クローラー — 許可
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: Claude-User
Allow: /
User-agent: PerplexityBot
Allow: /
# AI学習用クローラー — ブロック
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Bytespider
Disallow: /
Sitemap: https://yoursite.com/sitemap.xml
パターンC:ハイブリッド方式(公開コンテンツのみAI学習を許可)
# 学習用ボットは公開コンテンツのみ許可
User-agent: GPTBot
Allow: /blog/
Allow: /docs/
Allow: /guides/
Disallow: /members/
Disallow: /premium/
Disallow: /api/
User-agent: ClaudeBot
Allow: /blog/
Allow: /docs/
Allow: /guides/
Disallow: /members/
Disallow: /premium/
Disallow: /api/
# 検索用ボットは広く許可
User-agent: OAI-SearchBot
Allow: /
Disallow: /admin/
User-agent: Claude-SearchBot
Allow: /
Disallow: /admin/
Sitemap: https://yoursite.com/sitemap.xml
WordPress環境での設定方法
WordPressでrobots.txtを編集するには、いくつかの方法があります。Yoast SEOまたはRank Mathプラグインの「ツール」セクションにあるrobots.txtエディターを使う方法が最も簡単です。プラグインを使っていない場合は、WPCodeプラグインでスニペットとして挿入する方法や、テーマのfunctions.phpでフィルターを追加する方法もあります。
注意:Cloudflareを使っている場合、Bot Fight Modeがデフォルトで有効になっており、PerplexityBotやClaudeBotなどの正規のAIクローラーがCloudflareレベルでブロックされることがあります。Cloudflareダッシュボードの「セキュリティ」→「ボット」からBot Fight Modeの設定を確認してください。
【第2章】llms.txt——LLM向けサイト要約ファイルの書き方
llms.txtは、2024年9月にAnswer.AIの共同創設者Jeremy Howard氏が提唱した新しい標準です。robots.txtが「アクセスを制御する」ファイルであるのに対し、llms.txtは「AIに自社サイトの重要なコンテンツを案内する」ためのファイルです。
llms.txtとは何か
llms.txtは、Webサイトのルートディレクトリ(/llms.txt)に配置するMarkdownフォーマットのプレーンテキストファイルです。AIモデルやAIエージェントに対して、サイトの概要と重要なコンテンツへのリンクを提供します。
XMLサイトマップがGooglebotに「すべてのページの場所」を伝えるのに対し、llms.txtはLLMに「このサイトで特に重要なコンテンツはここです」と案内する役割を果たします。
現在の採用状況と注意点
2026年4月現在、llms.txtはまだ「公式標準」ではなく「提案(proposal)」の段階です。Anthropic(Claudeのドキュメント)、Cloudflare、Stripe、Vercelなど主要テック企業が自社サイトに実装しており、Mintlifyがホストする数千のドキュメントサイトにも展開されています。
一方で、Google検索チームのJohn Mueller氏は、Googleがllms.txtを検索ランキングに使用していないことを明言しています。つまり、llms.txtはSEO(Google検索順位)のためのツールではなく、AIエージェントにコンテンツを正しく理解してもらうためのツールです。
実装コストは非常に低く(1〜4時間程度)、デメリットもないため、「やっておいて損はない」施策と言えます。
llms.txtの書き方——実践テンプレート
llms.txtの仕様に従った基本構造は以下の通りです。
# あなたの会社名 / サイト名
> あなたのサイトの簡潔な説明(1〜2文)。AIが最初に読む要約部分です。
サイトの詳細な説明や、ファイルの読み方に関する補足情報をここに書きます。
## サービス・製品情報
- [サービス概要](https://yoursite.com/services.md): 提供サービスの一覧と概要
- [料金プラン](https://yoursite.com/pricing.md): 各プランの料金と機能比較
## ドキュメント・ガイド
- [導入ガイド](https://yoursite.com/docs/getting-started.md): 初めてのお客様向けセットアップガイド
- [API リファレンス](https://yoursite.com/docs/api.md): REST APIの仕様
## 会社情報
- [会社概要](https://yoursite.com/about.md): 会社の沿革、ミッション、所在地
- [お問い合わせ](https://yoursite.com/contact.md): 連絡先情報
## Optional
- [ブログ](https://yoursite.com/blog.md): 最新の技術記事
llms.txt作成のベストプラクティス
短く絞る:リンクは20〜50件に収めましょう。サイトマップのように全ページを列挙するのではなく、AIに「ここを読めば自社を理解できる」という厳選されたページだけを案内します。
Markdownで書く:リンク先もHTMLページではなく.mdファイルを用意するのが公式仕様の推奨です。HTMLからナビゲーション、広告、JavaScriptを除去したクリーンなテキストをAIに提供することで、トークン消費を最大10分の1に削減できるとの報告もあります。ただし、.mdファイルの用意が難しい場合は、HTMLページへのリンクでも機能します。
説明は簡潔に:各リンクの説明は短い括弧書き程度で十分です。「(初心者向けガイド)」のような簡潔な注釈が理想的です。
定期的に更新する:四半期に1回、主要コンテンツの公開やサイト構造の変更に合わせて更新しましょう。WordPress用のllms.txtプラグインを使えば自動生成も可能です。
WordPress環境での設置方法
手動で作成する場合は、llms.txtファイルをWordPressのルートディレクトリ(通常は public_html)にFTPまたはファイルマネージャーでアップロードします。
自動化したい場合は、「Website LLMs.txt」プラグイン(3万以上のインストール実績)やYoast SEOのllms.txt機能を利用できます。これらのプラグインは、投稿や固定ページの公開に合わせてllms.txtを自動更新します。
【第3章】AIブラウジングエージェント向けのDOM設計
Claude in ChromeやChatGPT agentのようなブラウジングエージェントは、人間と同じようにブラウザでページを開き、DOMツリーを解析して情報を取得します。ここでは、これらのエージェントが自社サイトと正しくインタラクションできるようにするためのDOM設計のポイントを解説します。
セマンティックHTMLの徹底
AIブラウジングエージェントは、アクセシビリティツリー(DOMからアクセシビリティ情報を抽出した構造)を主な情報源として利用します。したがって、セマンティックHTMLの使用は人間のアクセシビリティとAIアクセシビリティの両方に効きます。
やるべきこと:
<nav>、<main>、<article>、<section>、<aside>、<footer>などのランドマーク要素を正しく使う- 見出しタグ(
<h1>〜<h6>)を階層構造に従って正しく使う(見た目のスタイルのためにh3の後にh2を使うなどは避ける) - リストは
<ul>/<ol>で、表は<table>で、フォーム要素には<label>を関連付ける - 画像には意味のある
alt属性を必ず付ける - リンクテキストは「こちら」ではなく、リンク先の内容がわかる具体的なテキストにする
避けるべきこと:
<div>と<span>だけで構成されたレイアウト- CSSだけで見出しのように見せているが、実際にはh1〜h6タグを使っていないテキスト
- 重要な情報をJavaScriptのイベントハンドラー内に隠す
- クッキー同意バナーやポップアップが本文コンテンツを覆い隠す状態
構造化データ(Schema.org)の強化
Schema.orgの構造化データは、従来はGoogle検索のリッチスニペットを目的に実装されてきましたが、AIエージェントにとっても重要な情報源です。特にAIが頻繁に参照するスキーマタイプを以下に示します。
優先して実装すべきSchema.orgタイプ:
Organization/LocalBusiness:会社名、住所、営業時間、連絡先Product/Offer:商品名、価格、在庫状況、通貨FAQPage:よくある質問と回答のペアHowTo:手順付きガイドArticle/BlogPosting:記事のタイトル、著者、公開日、更新日BreadcrumbList:パンくずリスト
コンテンツの「AI可読性」を高める工夫
AIブラウジングエージェントがコンテンツを効率的に処理するための工夫を以下にまとめます。
最初の段落で結論を述べる:質問に対する直接的な回答を記事の冒頭に配置します。AIは回答を生成する際に、ページの冒頭部分を重視する傾向があります。
自然な質問形式の見出しを使う:「料金プラン」よりも「〇〇の料金はいくら?」のような、ユーザーが実際にAIに聞く形式に近い見出しが効果的です。
比較表を積極的に使う:AIは表形式のデータを正確に抽出する能力が高いため、プランの比較や機能一覧は<table>要素で提供します。
最終更新日を明記する:AIは情報の鮮度を重視します。記事やページに最終更新日を<time datetime="2026-04-10">形式で明示的に記載します。
【第4章】MCPサーバー経由で自社データを安全に公開する
MCP(Model Context Protocol)は、AIエージェントが外部のツールやデータソースに接続するための標準プロトコルです。自社のMCPサーバーを公開することで、AIエージェントがWebサイトをクロールするのではなく、構造化されたデータを直接取得できるようになります。
MCPの基本概念
MCPは「AIのためのUSB-C」と表現されます。1つのプロトコルで、あらゆるAIクライアント(Claude、ChatGPT、Cursor、VS Codeなど)が、あらゆるMCPサーバーに接続できます。
MCPサーバーは主に3つの機能を提供できます。
- Tools(ツール):AIが呼び出せる関数(例:商品検索、予約作成)
- Resources(リソース):AIが読み取れるデータ(例:商品カタログ、ドキュメント)
- Prompts(プロンプト):特定のタスクに最適化されたテンプレート
中小企業がMCPで公開すべきデータの例
MCPサーバーを通じてAIに公開することで効果が高いデータには、以下のようなものがあります。
商品・サービス情報:カタログ情報、料金、在庫状況をリアルタイムで提供。AIが「〇〇の料金はいくら?」と聞かれたとき、Webサイトをクロールするのではなく、MCPサーバーから最新の正確なデータを取得できます。
店舗・営業情報:営業時間、所在地、空き状況。「今日〇〇店は何時まで?」という質問に正確に回答できるようになります。
FAQ・ナレッジベース:よくある質問とその回答を構造化されたデータとして提供。
予約・申し込みAPI:AIエージェントがユーザーの代わりに予約を作成する機能(ただし、認証と認可の設計が必須)。
MCPサーバーのセキュリティ設計
MCPサーバーを外部に公開する場合、セキュリティ設計は最も重要な検討事項です。
認証(OAuth 2.1):MCPの仕様では、リモート接続(Streamable HTTP)にはOAuth 2.1 + PKCEが必須とされています。Auth0、Okta、Azure ADなどの既存のIDプロバイダーと統合できます。
スコープの最小化:公開するツールとリソースは必要最小限に絞ります。読み取り専用のデータ公開から始めて、書き込み操作(予約作成、注文など)は十分なテストと認可制御を経てから追加するのが安全です。
レート制限:MCPサーバーへのリクエストにレート制限を設けます。1つのクライアントからの過度なリクエストがサーバーに負荷をかけるのを防ぎます。
入力バリデーション:すべてのツール呼び出しに対して、入力パラメーターの厳格なバリデーションを行います。AIからの入力であっても、SQLインジェクションやSSRF(Server-Side Request Forgery)などの攻撃ベクトルは存在します。
監査ログ:すべてのツール呼び出しを監査ログとして記録します。誰が(どのクライアントが)、いつ、何のツールを、どのパラメーターで呼び出したかを追跡可能にしておきます。
MCPサーバーの構築方法
MCPサーバーの構築には、Python SDK(mcp)またはNode.js SDK(@modelcontextprotocol/sdk)を使用します。以下は、商品情報を公開するMCPサーバーの概念的な構造です。
# Python MCPサーバーの概念的な構造例
from mcp.server import Server
server = Server("my-company-mcp")
@server.tool()
async def search_products(query: str, category: str = None) -> str:
"""商品を検索して情報を返す
Args:
query: 検索キーワード
category: カテゴリでフィルタリング(オプション)
"""
# データベースから商品を検索
results = await db.search(query, category)
return format_results(results)
@server.tool()
async def get_business_hours(location: str) -> str:
"""指定された店舗の営業時間を返す
Args:
location: 店舗名または店舗ID
"""
hours = await db.get_hours(location)
return format_hours(hours)
開発環境ではstdio(ローカル通信)を使い、本番環境ではStreamable HTTP(HTTPS経由のリモート通信)でデプロイします。CloudflareがMCPサーバーホスティングをサポートしているほか、自社サーバーにデプロイすることも可能です。
【第5章】レート制限と負荷対策——AIトラフィックから自社サイトを守る
AIクローラーやAIエージェントからのトラフィックは、従来のWeb閲覧者とは質的に異なります。ある調査では、GPTBotなどの学習用ボットがサイトの帯域幅の最大40%を消費するケースも報告されています。
robots.txtのCrawl-delayディレクティブ
robots.txtのCrawl-delayディレクティブは、クローラーに対してリクエスト間の待機時間を指示するものです。Googlebotはこのディレクティブを無視しますが、一部のAIクローラーは尊重します。
# AIクローラーに5秒の間隔を指示
User-agent: ClaudeBot
Allow: /
Crawl-delay: 5
User-agent: PerplexityBot
Allow: /
Crawl-delay: 5
WAF(Web Application Firewall)によるボット管理
robots.txtだけでは十分な保護にはなりません。攻撃的なスクレイパーはrobots.txtを無視したり、User-Agentを偽装したりすることがあるためです。WAFやエッジでのアクセス制御を組み合わせることが推奨されます。
Cloudflare、AWS WAF、Akamai Bot Managerなどのサービスを使い、AIボット別にレート制限を設定できます。正規のAIクローラー(GPTBot、ClaudeBot等)のIPレンジは各社が公開しているため、User-Agentの検証と合わせてIPベースの確認も可能です。
MCPサーバーのレート制限
MCPサーバーにもレート制限を実装します。Express.jsやFastAPIのミドルウェアとして実装するか、API Gatewayのレート制限機能を利用します。OAuthのクライアントIDごとにレート制限を設定し、信頼できるパートナーには高い制限を、未知のクライアントには低い制限を設けるのが一般的です。
【第6章】構造化フィード——AIに「正しい情報」を届ける
AIエージェントに自社の情報を正確に理解してもらうためには、構造化されたフィードを提供することが効果的です。
JSON-LDによるサイト全体の情報提供
JSON-LD(JavaScript Object Notation for Linked Data)は、Schema.orgの構造化データをJSON形式で記述する方法です。HTMLの<head>内に<script type="application/ld+json">タグとして埋め込みます。
AI検索エンジンが特に参照するJSON-LDのパターンを以下に示します。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "あなたの会社名",
"url": "https://yoursite.com",
"description": "あなたの会社の簡潔な説明",
"address": {
"@type": "PostalAddress",
"addressLocality": "東京都",
"addressCountry": "JP"
},
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+81-3-XXXX-XXXX",
"contactType": "customer service",
"availableLanguage": ["Japanese", "English"]
},
"sameAs": [
"https://twitter.com/yourcompany",
"https://www.linkedin.com/company/yourcompany"
]
}
</script>
RSSフィード / Atom フィードの最適化
WordPressは標準でRSSフィードを生成しますが、AIエージェント向けにいくつかの最適化が可能です。
フィードに全文(content:encoded)を含める設定にすることで、AIが個別のページを訪問する必要がなくなります。WordPressの「設定」→「表示設定」→「フィードの各投稿に含める内容」で「全文を表示」を選択します。
カテゴリ別のフィード(例:/category/products/feed/)を活用すれば、AIが特定のトピックの最新情報を効率的に取得できます。
APIエンドポイントの設計
WordPress REST API(/wp-json/wp/v2/)は、すでにAIが利用可能な構造化データのエンドポイントとして機能しています。カスタム投稿タイプやカスタムフィールド(ACF等)のデータもREST APIで公開可能です。
公開すべきデータとそうでないデータを明確に分け、REST APIの認証設定を適切に行います。不要なエンドポイントはrest_endpointsフィルターで無効化し、攻撃面を最小化します。
実践チェックリスト——今すぐ着手できる15項目
本記事の内容を実践するためのチェックリストです。優先度の高い順に並べています。
今日やること(30分以内)
- 自社サイトのrobots.txtを確認し、AIクローラー(GPTBot、ClaudeBot、PerplexityBot等)の設定状況を把握する
- Cloudflareを使っている場合、Bot Fight Modeの設定を確認する
- WordPressの表示設定で、RSSフィードが「全文表示」になっているか確認する
今週やること(数時間)
- robots.txtを自社の方針に合わせて更新する(パターンA / B / Cのいずれかを採用)
- llms.txtファイルを作成し、ルートディレクトリに設置する
- 主要ページにSchema.org構造化データ(Organization、Product、FAQPage等)を追加する
- サイトのHTML構造を確認し、セマンティックHTMLに修正すべき箇所を特定する
今月やること(継続的な改善)
- セマンティックHTMLへの改修を実施する
- 主要ページの.md版を作成し、llms.txtからリンクする
- サーバーログでAIクローラーのアクセス状況を分析する
- コンテンツの「AI可読性」を見直す(冒頭に結論、自然な質問形式の見出し、比較表の活用)
- WordPress REST APIの公開範囲を確認し、不要なエンドポイントを無効化する
来四半期の検討事項
- MCPサーバーの構築を検討する(まずは読み取り専用のデータ公開から)
- WAFでのAIボット別レート制限を設定する
- AIブラウジングエージェントによる自社サイトの「見え方」をテストする
よくある質問(Q&A)
Q1. llms.txtを設置するとSEOに影響はありますか?
Google検索のランキングに直接影響を与えることはありません。llms.txtはGoogle検索ではなく、AIエージェントやLLMがサイトを理解するためのファイルです。SEOとは別の目的で設置するものと考えてください。
Q2. AIクローラーをすべてブロックしたほうが安全ですか?
一概には言えません。すべてブロックすると、ChatGPTやPerplexityの検索結果に自社の情報が表示されなくなります。AIを活用して自社の情報を広めたい場合は、「学習用クローラーはブロック、検索用クローラーは許可」というハイブリッド方式が現在の主流です。
Q3. MCPサーバーは中小企業でも必要ですか?
2026年4月現在、MCPサーバーの公開は必須ではありません。まずはrobots.txt、llms.txt、構造化データの整備から始めるのが現実的です。ただし、AIエージェントが商品検索や予約を代行する時代は近づいており、早期に検討を始めることには価値があります。
Q4. WordPress用のllms.txtプラグインはどれがおすすめですか?
「Website LLMs.txt」プラグインが3万以上のインストール実績があり、GPTBotやClaudeBotのアクセス状況もトラッキングできます。Yoast SEOもllms.txtの自動生成機能を提供しています。いずれも無料で利用可能です。
Q5. AIブラウジングエージェントのアクセスだけを制御することはできますか?
現時点では困難です。AIブラウジングエージェント(Claude in Chrome、ChatGPT agentなど)はユーザーの指示で動作するため、robots.txtによる制御が及ばない場合があります。OpenAIはChatGPT-Userがrobots.txtに従わない場合があると明記しており、Anthropicも同様の運用をする可能性があります。WAFでの制御やページのアクセシビリティ設計で対応するのが現実的です。
まとめ——「AIフレンドリー」は次のモバイルフレンドリー
かつてWebサイトが「モバイルフレンドリー」への対応を求められたように、2026年のWebサイトは「AIフレンドリー」への対応が求められています。
今回解説した3つのアクセスパターン(AIクローラー、AIブラウジングエージェント、MCP経由)への対応は、現時点では「やっている企業が差をつけられる」段階です。しかし、AIエージェントがWeb上の商取引を代行する時代が到来すれば、これらの対応は「やっていないと機会損失になる」ものに変わっていきます。
重要なのは、完璧な対応を一度に目指すことではありません。robots.txtの見直し、llms.txtの設置、セマンティックHTMLの確認——今日できることから始めて、四半期ごとに改善を重ねることです。
AIと自社サイトの「正しいインタラクション」を設計することは、AIエージェント時代における新たな競争優位の源泉になるでしょう。
参考リンク
- llms.txt公式仕様
- Model Context Protocol公式ドキュメント
- OpenAI クローラードキュメント(GPTBot / OAI-SearchBot / ChatGPT-User)
- Anthropic クローラードキュメント(ClaudeBot / Claude-SearchBot / Claude-User)
- Schema.org
免責事項:本記事は2026年4月時点の公開情報に基づく情報提供であり、各AIプロバイダーのクローラー仕様やプロトコル仕様は急速に変化しています。最新情報は各公式ドキュメントで確認してください。

コメント