この記事のポイント
- AIエージェントがサイトへ入れない原因には、運営方針による拒否と自動アクセス対策の誤検知が混在しています。
- MetaやSierraなどは個人の代理AIと企業をつなぐ公開標準を設計中。本人確認や連携方法を扱う計画です。
- サイト側は受け入れ条件を、利用側は相手が認める接続方法を確認。標準化と個別の利用許可は分けて考えます。
報道と各社発表をもとに、エージェントと外部サイトの接続を紹介します。利用する側と受け入れる側で、確認する条件を分けて整理します。
ボット対策とサイト側の意図的な拒否が混在
TechCrunchの2026年10月6日報道によると、Meta「Muse」やChatGPTのエージェント機能を使って航空券予約や買い物を代行させようとしたユーザーが、Amazon・Walmart・Delta航空などのサイトでアクセスを拒否される事例が相次いで報告されています。報道では、サイト側の対応を2つに分けています。1つはAmazonのように方針としてAIエージェントを明示的にブロックするケース、もう1つはWalmartのように提携関係にあるにもかかわらず、迷惑な自動アクセスを防ぐためのボット対策（人が操作しているかを確かめるCAPTCHA認証など）が誤ってAIエージェントまで締め出してしまうケースです。ひとことで言うと、「狙ってブロックしている」場合と「別の目的の防御策に巻き込まれている」場合が入り混じっている状態です。
自社サイトの受け入れ条件と標準化を分けて検討
Metaは2026年10月6日の公式発表で、SierraやWalmart、Stripeなどと「Personal Agent Protocol」を設計中だと説明しました。個人の代理で動くエージェントと企業側の連携方法を定める公開標準で、本人確認や、サイトから外部プログラム用の窓口（API）などの連携手段への案内などを扱います。（10月6日の発表時点では設計段階です。）別の取り組みとしてCloudflareは、エージェント向けブラウザ「Kitesurf」をベータ公開しています（サイトが認めないアクセスを許可する仕組みではありません）。自社ECやサポート窓口で代理アクセスを受け付ける場合は、利用を認める条件と、不正な通信を防ぐ対策を分けて考えるとよいでしょう。
まとめ: サイト運営側と利用側で確認点が異なる
サイトを運営する側なら、代理の注文・予約を受け付けるか、その際にどの認証や連携手段を使うかが検討の出発点になります。受け入れる方針の場合は、正当なアクセスまで拒否していないかをサイトの管理担当と点検するとよいでしょう。
外部サイトをエージェントで利用する側では、相手の利用規約や認められた接続方法が判断材料になります。標準化の進展と、個々のサイトの利用許可は分けて捉える必要があります。
利用者側の機能を知るにはMetaのMuseの紹介、商取引の仕組みを検討する場合はClaudeで作る商取引エージェントの解説も参考になります。
自社がどちらの立場かを明確にすれば、標準の完成を待つ間にも確認する範囲を絞れます。連携を予定していない場合まで、一律にボット対策を変更する必要はありません。
※2026年10月7日時点の情報です。
