ブログに戻る

エージェントは道具であり、人物ではない:第九区がAmazonのPerplexity禁止を撤回

2026年8月4日、第9巡回控訴裁判所は、Perplexity CometエージェントがAmazonアカウントにアクセスできないという禁止令を取り消しました。裁判所は、エージェントはツールであり、個人ではなく、CFAAによるアクセスはユーザーによって行われると判断しました。重要な論点は、リクエストが物理的にどのデバイスから発信されるかというネットワークアーキテクチャでした。判決と実践的な結論を分析します。

📅2026年8月19日
エージェントは道具であり、人物ではない:第九区がAmazonのPerplexity禁止を撤回

2026年8月4日、アメリカ合衆国第9巡回控訴裁判所は、エージェントブラウザPerplexity CometがAmazonのユーザーアカウントにアクセスすることを妨げていた仮差止命令を取り消しました。形式的には、これはAIを介した購入に関する2つの企業間の争いですが、実際にはエージェント商業の枠を超えた重要な質問に対する初の控訴裁判所の決定です:自動化がリクエストを送信する際、誰が他のサーバーに「アクセスする」のか。そして、裁判所の答えは、意外にも法律ではなく、ネットワークアーキテクチャに依存していました。

何が起こったのか:訴訟から仮差止命令の取り消しまで

争いの年表は以下のようになります:

  • 2025年11月 — AmazonはPerplexity AIに対して訴訟を提起し、連邦のコンピュータ詐欺および悪用防止法(CFAA)とそのカリフォルニア州の類似法を引用しました。主張は、エージェントCometがユーザーアカウントにログインし、商品を閲覧し、購入を開始すること、つまり、プラットフォームの許可なしにパスワードで保護された領域で活動しているというものです。
  • 背景 — Amazonによれば、同社は2024年11月から少なくとも5回、Perplexityに警告を発し、2025年8月に技術的な障壁を設けましたが、Perplexityはそれを回避する更新を24時間以内にリリースしました。別の指摘として、エージェントは通常のGoogle Chromeセッションを装っていました。
  • 2026年3月9日 — マキシン・チェスニー裁判官(カリフォルニア北部地区)が仮差止命令を出し、Amazonから得たデータの破棄を命じました。彼女の公式見解は、アクセスはAmazonのユーザーの許可によるものであったが、Amazonの承認なしに行われたというものでした。
  • 2026年8月4日 — 第9巡回控訴裁判所(事件番号26-1444)が仮差止命令を取り消しました:AmazonはCFAAに基づく主張で実質的に勝てない可能性が高いとされました。

Amazonはこの決定に同意せず、争いを続ける意向を示しました。Perplexityは、ユーザーが任意のAIを選択する権利を擁護すると応じました。この件は依然として解決しておらず、第一審の裁判は続いており、Amazonは再審を求めたり、上級裁判所に進むことができます。

重要なポイント:エージェントは道具であり、個人ではない

CFAAは、承認なしに「保護されたコンピュータ」にアクセスすることを罰します。争いは一つの動詞に集約されました:誰がアクセス行為を行ったのか。Amazonは、Perplexityがプラットフォーム上で行動したため、Perplexityが行ったと主張しました。Perplexityは、エージェントに指示を出したのはユーザーであると反論しました。

控訴裁判所は後者の立場を支持し、明確に述べました:どれほど高度なエージェントであっても、法律上の目的においては「それは道具であり、個人ではない」。ユーザーがAmazon.comでエージェントに何かをさせるとき、Amazonのコンピュータへのアクセスは実際にはユーザーによって行われます。

これは、Van Buren v. United States(2021)における最高裁判所の判断の論理的な延長であり、CFAAを狭めました:法律は、アクセスがまったくない場所への侵入を罰するものであり、「目的外での合法的なアクセス」の使用を罰するものではありません。Amazonのユーザーはアカウントを持ち、それにアクセスする権利があります。それを行うための道具は、単独でハッキングの主体にはなりません。

なぜトラフィックのアーキテクチャがすべてを決定したのか

実務者にとって最も興味深い決定の部分は技術的なものであり、裁判所はComet Assistantの物理的な構造を分析し、それが結果を決定づけました。

動作の仕組みは次の通りです:エージェントはユーザーのマシン上のブラウザウィンドウのスクリーンショットを撮影し、それをPerplexityのサーバーに送信し、そこからナビゲーションの指示がユーザーのコンピュータに戻され、ユーザーがその指示を実行します。Perplexityのサーバーは、Amazonのサーバーと直接通信しません。Amazonが自社で見るトラフィックは、すべてユーザーのデバイスとIPアドレスから来ています。

ここから裁判所の結論が導かれます。リクエストが物理的にユーザーから発信される場合、CFAAの意味での「アクセス」はユーザーによって行われたことになります。

これはPower Venturesとどう違うのか

これまで、ユーザーの同意による第三者アクセスの典型的な事例はFacebook v. Power Ventures(2016)でした。そこで裁判所は、プラットフォームはユーザーが自発的に自分の認証情報を提供した場合でも、第三者サービスからのアクセスを取り消すことができると判断しました。第一審の裁判官は、この先例を引用し、AIエージェントに適用しました。

第9巡回控訴裁判所は、これらの事例を一つの基準で分けました — 再びアーキテクチャ的な観点からです。Power Venturesでは、被告のシステムがユーザーのマシンをバイパスしてFacebookプラットフォームに直接メッセージを送信していましたが、Perplexityにはそのようなチャネルはありません。トラフィックのトポロジーが異なるため、「誰がアクセスしたのか」という質問に対する答えも異なります。

この区別の実務的な意味は非常に大きいです。これは、システムの設計 — ユーザーのデバイス上のクライアントエージェントまたは自らのインフラからプラットフォームにアクセスするサーバーサービス — が単なるエンジニアリングの選択ではなく、法的な議論の根拠となったことを意味します

決定が何をしなかったのか

裁判所は、影響範囲を最大限に制限し、エージェントAIのための新しい法的枠組みを作成しないことを明言しました。以下の点は考慮されていませんでした:

  • ユーザー契約の違反。 契約、侵害、プラットフォームの規則に基づく主張は、この決定で閉じられるものではなく、別途提起可能です。
  • ユーザーに対する訴訟。 アクセスを行うのがユーザーである場合、プラットフォームはそのユーザーを訴えることができます。
  • サーバーアーキテクチャ。 この結論は特定のスキームに基づいています。クラウドスクレイパーや自らのインフラからプラットフォームにアクセスするSaaSエージェントは、この論理に自動的には該当しません。
  • 技術的なブロック。 決定の中には、Amazonが自動化を検出し、ブロックすることを禁止する言葉は一切ありません。ブロックする権利は消えていない — 刑事法によってブロックを支える可能性が消えたのです。

これは、実際には従来の状況を逆転させるものです:以前は、自動化を行う側に法的リスクがあり、技術的な保護が第二の防衛線と見なされていました。今や、プラットフォームにとって技術的な保護が第一の防衛線となりました。

これが実務に何を変えるのか

データを収集したり、アカウントを自動化したり、エージェントを構築したりするすべての人にとって、この決定からは3つの実務的な結論が導かれます。

1. トラフィックの出口地点が法的な重みを持つようになった

以前は、「すべてを自社のデータセンター経由で運ぶ」と「ユーザーのものと区別できないアドレスから作業する」という選択は、通過性とコストに関する問題でした。今や、それはリクエストが誰の行動と見なされるかという問題でもあります。プラットフォームへのリクエストがユーザー側から発信されるアーキテクチャは、裁判でより保護されることが判明しました — 同時に、歴史的にボットフィルターを通過しやすいのです。これは、法的および技術的なインセンティブが一致し、同じ方向を指す稀なケースです:レジデンシャルプロキシとユーザーの出口地点を選ぶことが求められます。公開価格のモニタリングや地域ごとの検索結果の確認などの中立的なタスクには、引き続きデータセンタープロキシが十分です — そこにはログイン領域も、誰かのアカウントに関する争いもありません。

2. CFAAが弱まり、契約と検出が強化された

この決定を「今はできる」と読むべきではありません。最も厳しい武器 — 刑事的な潜在能力を持つ連邦法が取り除かれました。残ったのは、ユーザー契約、アカウントのブロック、市民訴訟、そして何よりもボット対策のスタックです。法的な手段を一部失ったプラットフォームは、検出によってそれを補うでしょう:フィンガープリンティング、行動分析、署名されたエージェントによって。業界が「良い」ボットを技術的手段で合法化しようとする様子については、Web Bot Authと署名されたエージェントに関する資料で詳しく説明しています。

3. リスクが最終ユーザーに移った

Perplexityの勝利の裏側:ユーザーが行動する場合、ユーザーが責任を負います。クライアントに自動化を製品として提供するサービスにとっては、どの名前で、どのIPから行動が実行されるのか、そしてどのプラットフォームのルールが関与するのかを文書で明確にする理由があります。

今すぐ何をすべきか

  1. アクセスのトポロジーを説明してください。 一つの質問に答えてください:ターゲットプラットフォームがログに見るIPは、あなたのサーバーのものか、ユーザーのものか。これによって法的立場と検出のプロファイルが決まります。
  2. 公開とログインを分けてください。 公開ページの収集と他のアカウント内での行動は、リスクの観点から根本的に異なる話です。それらを一つのパイプラインで混ぜるべきではありません。
  3. 直接の禁止後に攻撃的にマスクしないでください。 この件では、設定された障壁を回避し、Chromeにクライアントを偽装することがAmazonにとって最も強力な証拠を提供しました。CFAAの主張は崩れましたが、他の根拠は生きています。
  4. タスクに応じた出口のタイプを選んでください。 エージェントをPlaywrightやMCPで立ち上げ、トラフィックを適切にラップする方法については、AIエージェント用プロキシのガイドで詳しく説明しています。

結論

第9巡回控訴裁判所は自動化を合法化せず、エージェントにどこにでも行くためのパスを与えませんでした。彼らは「アクセス」という概念を、リクエストが物理的にどこから発信されるかに結びつける、より狭いが重要なことをしました。ユーザーのマシン上で動作する道具はアクセスを行わず — それを行うのは人間です。自らのインフラからプラットフォームにアクセスするインフラは、古いリスクの範囲に留まります。

市場にとって、これは重心の移動を意味します。「できるかどうか」という法的な争いは、ますます「ログに誰のアドレスがあるのか」というエンジニアリングの質問にぶつかることになるでしょう。そして、アクセスを巡る戦いは、これまで通り、ボット対策、フィンガープリンティング、出口地点の質に移行します。