サイレントエージェントは、すでにあなたのサイトに存在している

ユーザーに代わって商品を購入し、予約を取り、ログインするサイレントエージェントが、自らの正体を明かさないままサイトにアクセスするようになっています。こうしたエージェントを一律にブロックすれば、顧客を一人失うことになります。一方、無条件に許可すれば、深刻なセキュリティリスクを招きかねません。このブログ記事では、第3の選択肢である「選択的なアクション制御」について解説します。

エージェントを許可するか、それとも拒否するか。AIエージェントによるトラフィックをめぐる問題の多くは、企業がこの問いに対する答えをサイト全体に一律に適用していることに起因します。ほとんどの企業は、サイトのあらゆる場面で「許可」か「拒否」のどちらか一方を選ぶべきではありません。 

選択的なアクション制御は、一律にブロックまたは許可するよりも優れたアプローチです。選択的なアクション制御により、以下が可能になります。 

• すでに自社サイトにアクセスしているAIエージェントを把握する

• 自社が許容する利用の定義に基づいてポリシーを設定する

• 検証を許可の条件とする

• エージェントのアイデンティティを確認する仕組みが整うまで、サイトの閲覧を妨げない

サイレントエージェントであるMeta MuseとInstinctは、現在このような仕組みで動作しています。OpenAIのdotsは、状況をさらに複雑にしています。クラウド上では署名付きで動作しますが、顧客自身のコンピューターに切り替えて動作する場合はサイレントになります。OpenAIは顧客に対し、「Webサイトがクラウドブラウザーをブロックした場合は、接続済みのコンピューターを使って再試行するようにdotに指示する」ように案内しています。ここに課題があります。エージェントがリクエストに署名しない場合、実在する顧客に代わってスニーカーを購入するショッピングエージェントと、実在する顧客になりすました転売業者のボットは、見分けがつかないほどよく似た挙動を示すことがあります。

エージェントエコシステムは急速に進化しており、企業もいち早くその動向に注目しました。MetaがAmazonをエージェントの対象から外すことを拒否したため、Amazonは9月20日、Museによる自社ストアへのアクセスを遮断しました。Amazonは、Museが自身をエージェントとして識別せず、顧客の認証情報を保存しているように見えたと説明しています。JPMorganは10月13日、外部エージェントによる顧客アカウントへのアクセスをブロックしました。Citi、Schwab、Bank of Americaも、同じ週に同様の措置を講じました。 

Axiosは、銀行各社は顧客アカウント内でサードパーティ製エージェントの存在を確認しており、その一部は顧客の指示を超えた操作を行っているようだと報じています。一方、小売企業は別の問題に直面しています。エージェントを使った購入手続きが完了できないという顧客からの苦情です。その多くは、特定のエージェントを意図的にブロックした結果ではなく、ボット対策システムがそのアクセスを自動化によるものと判定したことが原因です。

これまでの対応は、大きく次の2つに分けられます。

1. ログイン時や資金移動時に、エージェントを全面的にブロックする 

2. 読み取り専用のアクセスを提供し、エージェントによるアカウント情報の閲覧は認める一方、操作は許可しない 

どちらも当面の対応策としては妥当です。しかし、いずれも戦略とは言えません。なぜなら、どちらも「許可するか、拒否するか」という二者択一の問いに答えているにすぎないからです。本当に問うべきなのは、エージェントにどの操作を許可すべきかということです。

当社の見解は、自動化されたトラフィックへの対応は、「エージェント」という言葉が当てはまるかどうかではなく、何を目的としてアクセスしているのか、また、サイト側がその正当性をどこまで検証できるのかに基づいて判断すべきだというものです。そのためには、次の3つの要素が順に必要となります。 

1. 可視性：エージェントによるトラフィックを一括りにするのではなく、その目的ごとに分類して把握する

2. 知見：自らエージェントであることを申告したものと、そのふるまいからエージェントと推定されたものを区別し、把握する

3. 選択的なアクション制御：エージェントによる商品カタログの閲覧を許可しながら、決済の試行については、その都度、自動化に伴うリスクを評価する

ここから、4つの重要な指針が導き出されます。その詳細は、この記事の最後で解説します。すでに自社サイトにアクセスしているエージェントを把握すること、サイト全体ではなくエンドポイントごとに判断すること、検証を許可の条件とすること、そして、業界全体でエージェントのアイデンティティを確認する仕組みが整うまで、サイトの閲覧を妨げないことです。

これは、そのセッションの先に何があるかを考えると重要な問題です。エージェントが商品カタログを閲覧するだけなら、問題はせいぜいプライバシーに関するものです。しかし、エージェントが顧客の認証情報を使ってログインしたとなると、違う話です。Instinctの利用規約では、法的拘束力を伴う取引において、同サービスがユーザーの代理を務めることが定められています。また、同社のプライバシー通知では、意図しない支払いや、隠された指示による操作が、サービス利用に伴うリスクとして挙げられています。初期テスターは、実際にこの両方の事例を記録しています。あるテスターはメールに指示を埋め込み、エージェントがその指示に従うことを確認しました。また別のテスターは、自分の承認なしにエージェントが自分の代わりにメールを送信したと報告しています。

したがって、銀行が「アカウント内で行われた操作が、顧客本人の指示によるものかどうかを判別できない」と述べるとき、それは実際に存在する根本的な課題を指しています。検知システムに投資すれば解決できるという類の問題ではありません。エージェントは、顧客から提供された認証情報を使用して、正当にセッションに参加しています。リクエストの内容にも、矛盾を示すものは何もありません。

銀行業界で懸念されているのは、認証済みセッション内でエージェントが行う操作です。Axiosは、米国の大手銀行は、顧客アカウント内でサードパーティ製エージェントが活動していることを検知しており、その一部は顧客の依頼内容を超える操作を行っているようだと報じています。10月中旬以降、各銀行が公表している方針には一貫した傾向が見られます。 

• JPMorgan：個人向けアカウントへの外部エージェントのアクセスを認めない方針です。

• Citi：外部エージェントによるアクセスを制限しています。

• Schwab：顧客資金を移動させようとするエージェントの操作を阻止するとしています。

• Bank of America：アカウントから資金を移動する際には、人間による承認を必須としています。 

• Chase：顧客に対し、認証情報を第三者に渡さないよう注意を促しています。 

• 複数の銀行が、妥協策として読み取り専用アクセスへの移行を進めています。

自律型AIエージェントをめぐる現在の動向は、金融アカウントのアグリゲーションの黎明期とよく似ています。消費者の需要に後押しされ、無秩序かつ未承認のUIスクレイピングが横行し、最終的には、プラットフォーム側も当初の積極的な拒絶姿勢から、標準化されたプロトコルの導入へと移行せざるを得なくなったという流れです。2010年代には、Plaid、Yodlee、Mintなどのアグリゲーターは、ユーザーの認証情報を収集し、人間によるブラウザーセッションを模倣するヘッドレススクリプトを起動して、データをスクレイピングし、セキュリティチェックを回避することで、銀行APIが利用できないという制約を乗り越えていました。 

今日、自律型ボットやエージェントも、まったく同じ手法を用いています。

コマース分野で懸念されているのは、顧客が購入手続きを完了できないという問題です。Amazonは9月にMuseをブロックし、現在では、エージェントが顧客のアカウントを使って商品を購入しようとした際に、顧客本人に通知しています。TechCrunchの報道では、エージェントによるアクセスが拒否されたと利用者が報告しているサイトとして、Yelp、eBay、Zillow、Pizza Hut、Adidasのほか、複数の航空会社が挙げられています。それが意図的なポリシーによる結果である場合もあります。一方、既存のボット対策機能が自動購入の動作を検知し、本来設計されたとおりに対処しているケースもあります。

銀行業界とコマース業界の双方に共通する背景には、こうしたエージェントが登場する以前から、すでに大規模なトラフィックが存在していたという事実があります。Akamaiの2026年7月「インターネットの現状」レポートによると、2025年7月から12月までの期間に、Akamaiのグローバルネットワーク全体で発生したAIボットトラフィックのほぼ半分（47.9%）がコマース分野に集中していました。また、コマース関連企業では、AIボットの活動の90%以上を「監視のみ」のカテゴリーに分類しており、残りの活動についても、およそ4分の3を制限なしで許可していたことが明らかになりました。 

つまり、多くの企業は、エージェントが決済ボタンに手を伸ばし始めるずっと前から、AIトラフィックを監視するにとどまり、積極的な制御を行っていなかったのです。

3つ目の対応策、つまり、エージェントが識別されたという理由でアクセスを許可する方法は、実は最も大きなリスクを暗黙のうちに抱えています。現在、識別は主に「シグネチャ」との照合によって行われています。シグネチャとは、既知のエージェントが通常生成するヘッダー、フィンガープリント、ふるまいなどのパターンのことです。シグネチャは模倣できます。特定のシグネチャを根拠に例外を認めれば、そのシグネチャを十分に模倣できるものにも同じ例外が適用されてしまいます。そして、ショッピングエージェントを最も積極的に模倣しようとするトラフィックこそ、新製品の発売時に小売企業が決済段階で最も排除したいトラフィックなのです。

これが落とし穴です。一律にブロックすれば収益を失い、一律に許可すれば、同じ外見を装った次の模倣者にも例外を与えることになります。読み取り専用にすれば、判断を先送りするだけです。エージェントを許可するか否かを問うのではなく、どのアクションを許可するかを決めるべき時です。

エージェントのオペレーターにも、果たすべき役割があります。Akamaiに登録すれば、オペレーターはトラフィックの検証を受けることができます。これにより、推測に基づくシグネチャを、マーチャントがポリシーの適用対象として指定できる、身元を申告したエージェントのアイデンティティ情報へと変えることができます。現在、決済時にブロックされているエージェントの大半は、まだこの検証を完了していないエージェントです。サイレントエージェントは、この検証が完了するまではアクセスを許可することができません。

この取り組みはまだ進行中であり、その間も企業は自社サイトの運営を続けなければなりません。そのため、現時点ではアクションごとに制御し、エージェントのアイデンティティ確認の仕組みが整うにつれて、許可できる範囲を広げていく必要があります。すでに決済のコンテンツとログインを分けて管理している企業であれば、検証の仕組みが自社のエッジに導入された段階で、身元が確認されたエージェントを許可できるようにできます。一方、「すべてブロック」か「すべて許可」かという二者択一でまだ判断に迷っている企業は、ゼロから取り組みを始めることになります。

AIトラフィックをカテゴリー別に抽出し、コンテンツページ、ログイン画面、決済画面、アカウント情報の変更ページなど、どこにアクセスしているかを把握します。多くのチームは、トラフィックの量の多さだけでなく、その多くが明確な判断を伴わないまま監視され続けていることに驚きます。測定していないトラフィックに対して、ポリシーを定めることはできません。

閲覧、取引、認証済みセッションについて、それぞれ個別に判断します。この3つすべてに同じ判断を適用するのであれば、それは従来の設定をそのまま引き継いだ結果ではなく、検討したうえで導き出した結論であるべきです。

パートナーやエージェントオペレーターから決済時のアクセス許可を求められた場合、シグネチャに基づく例外を認めるのではなく、登録とアイデンティティの確認を求めるべきです。エージェントオペレーターには、登録手続きを案内してください。特定のパターンに基づいて設定した例外は、そのパターンを模倣できるあらゆるものにも適用されてしまいます。

実際の顧客に代わって動作するエージェントは、企業の商品やサービスを見つけるための新たな経路として、ますます重要になっています。こうしたエージェントを締め出すことで生じる代償は、セキュリティインシデントではなく、売上の損失という形で現れます。資金が動く場面では管理を徹底する一方、商品カタログには引き続きアクセスできるようにしておきます。

• AIボットトラフィックに対するより詳細な制御機能の導入

• エージェント型時代のボット管理

• Web Bot Authenticationで「信頼」の概念を再定義する

• Akamai、エージェント向けセキュリティフレームワークを発表

• エージェント型ストアフロントのセキュリティ確保：コマース業界を狙う攻撃

• お使いのボットまたはAIエージェントをAkamaiが検証します