米AI AGENT Act法案から考える、顧客代理エージェントの受け入れ設計

競争政策の法案として出てきた「エージェントの受け入れ」

2026年7月21日、米国上院にS.5051という法案が導入されました。

通称はAI AGENT Act of 2026、正式名称はArtificial Intelligence Access, Gatekeeper Exchange, and Nondiscriminatory Transfer Act of 2026です。

法案の正式な標題は「オンラインサービスの提供における競争を促進し、消費者のスイッチングコストを引き下げるための法案」であり、AIエージェント全般を規律するものとしては書かれていません。

背景として、Warner上院議員の事務所は2026年6月29日に討議草案を公表しており、今回の法案はその後に正式導入されたものです。

議会の記録上、この法案は2回の読会を経て商業・科学・運輸委員会へ付託された段階にあり、2026年8月時点で公開されている記録では、付託より先の公聴会や採決は確認できません。

条文には、成立した場合の施行時期として「連邦取引委員会（FTC）が規則を制定した日」か「成立から1年後」の早い方という規定も置かれています。

つまり現時点では、義務が動き出しているわけでも、条文が確定しているわけでもありません。

それでも私たちがこの法案を読む価値があると考えるのは、扱っている主題が「自社が動かすAIエージェント」ではなく、「顧客の代理として外から来るAIエージェントを、自社がどう受け入れるか」だからです。

エージェントの権限設計は、多くの場合、自社の業務エージェントに何をどこまで任せるかという話として語られます。

この法案が具体的に手続きまで書き下しているのは、その逆側、つまり受け入れる側の判断です。

誰の代理としてそのエージェントを認識し、どこまでの操作を許し、断るときは何を伝え、どうやって止めるのか。

以下では、法案テキストに書かれていることを受け入れ側の判断の順に読み直し、最後に、法案の適用範囲の外側で各社に残るものを私たちの見方として分けて整理します。

誰に義務がかかるのか——プラットフォーム側とCUA提供者側は別

まず、この法案の中心概念である「custodial user agent（以下CUA）」の定義を押さえます。

条文はCUAを、ユーザーから明示的に権限を与えられ、そのユーザーに代わって大規模オンラインプラットフォーム提供者とやり取りするソフトウェアベースのエージェントであって、透明・文書化され・範囲が限定され・取消可能な形で動作するもの、と定義しています。

特定のAI方式や実装技術は要件になっていません。

ここで重要なのは、義務の主体が2種類あり、それぞれ範囲が違うことです。

一方は「大規模オンラインプラットフォーム提供者」です。

大規模オンラインプラットフォームとは、直近12か月のいずれかの暦月において米国内の顧客または加入者が5,000万人を超える、オンラインプラットフォームが提供する製品・アプリケーション・サービスを指します。

それを提供・管理・支配するオンラインプロバイダーが、大規模オンラインプラットフォーム提供者にあたります。

条文は「5,000万人以上」ではなく「5,000万人を超える」と書いており、この規模の閾値が限定しているのは、あくまでプラットフォーム側のインターフェース提供義務であって、法案全体の適用範囲ではありません。

もう一方は「CUA提供者」で、こちらは1つ以上のCUAを運用または提供する事業者を指し、自分自身のためだけにCUAを運用するユーザーも含みます。

CUA提供者の側には規模の要件がなく、登録義務と行為義務がかかります。

なお、条文が名指しする「オンラインプロバイダー」は消費者向けの通信・小売・情報サービスの提供者で、SNS、電子商取引、個人金融、AIサービスの提供者が例示されています。

企業向けSaaSの管理画面を操作する業務エージェントがこの定義に当てはまるかどうかは、条文から直ちに導けるものではありません。

受け入れる前に確認することとして法案が置いたもの

外部のエージェントを受け入れる側から見ると、アクセスを許す前に関わる規定は大きく4つに分けて読めます。

この分け方は読みやすさのために私たちが付けたもので、条文がそう区分しているわけではありません。

1つ目は、提供者の登録です。

CUA提供者は、そのCUAがインターフェースにアクセスするための条件として、かつアクセスに先立って、FTCへ登録しなければならないと定められています。

FTCは統一的な条件と適用範囲を定めたうえで自己申告による登録を認めることができ、登録の提出から180日以内にFTCまたは認定を受けた認証機関が登録を評価します。

FTCは独立した認証機関を認定でき、良好な状態にある認証は、後述するCUAの義務を満たしていることの反証可能な推定として扱われます。

2つ目は、要求が本当にそのユーザーから出ているかの検証です。

条文は、成立から180日以内にFTCが、ユーザーに代わるアクセス要求が検証可能な要求であることを確保する規則と手続きを定める、としています。

3つ目は、ユーザーによる委譲と取消しです。

同じ規定の中で、ユーザーが事前の委譲を取り消すための透明で実装が容易な方法を持つこと、そして取消しの要求をプラットフォーム提供者へ速やかに伝える仕組みを含むことが求められています。

4つ目は、要求できる範囲です。

FTCは、プライバシー・金融面の安全・個人の安全への影響を踏まえて、特定の商用場面ごとに、委譲されるアクセスの範囲を含む専用の利用条件を定めることができます。

加えて条文には、この法律のいかなる規定も、CUAに対してユーザー本人がアクセスできる以上の権限を与えるものと解してはならない、という条項があります。

代理人は本人より強くならない、という当たり前の原則が明文で置かれている点は、受け入れ側の設計の出発点として使える整理だと私たちは考えています。

技術的な土台についても、条文は担い手を指定しています。

成立から180日以内に、米国立標準技術研究所（NIST）が、既存のオープンプロトコルを特定するか、それが存在しない場合は模範となる技術標準を策定・公表するとされています。

対象として挙げられているのは、オンラインメッセージング、マルチメディア共有とSNS、電子商取引、個人金融、AIサービスに加えて、検証可能な委譲、すなわち範囲を限定した取消可能な委譲資格情報、CUAの身元と登録状況の検証、取消しのリアルタイムでの伝達と実行、CUAが本人に代わって行った行動の監査可能な記録の作成です。

規則の制定は、成立から1年以内に、FTCが消費者金融保護局（CFPB）・連邦預金保険公社（FDIC）・通貨監督庁（OCC）と調整して行うとされています。

さらに成立から180日以内に、これらに財務省・国土安全保障省・商務省・司法省・証券取引委員会を加えた省庁横断のワーキンググループを設置し、詐欺・誤用・純粋な誤りによってCUAが本人に代わって行動した結果として企業や政府に生じる害を防ぐための提案を検討する、という規定も置かれています。

ここで挙げたFTCの登録制度も、認証機関の認定も、NISTの技術標準も、いずれも法案が成立した場合に整備されるものとして条文が定めているものです。

2026年8月時点で稼働している制度ではありません。

アクセスを許可した後に置ける制限

受け入れたあとの話も、条文はかなり具体的です。

一般義務として、大規模オンラインプラットフォーム提供者は、CUAがアクセスできるインターフェースを、公正・合理的・非差別的な条件に基づいて用意し維持しなければならないとされています。

一方で、無条件・無制限の開放を求めているわけでもありません。

プラットフォーム提供者は、CUAによる要求の頻度・性質・量について合理的なしきい値を設けることができ、それを超える分については合理的な手数料を課すことができます。

利用条件についても、公正・合理的・非差別的である限り設定でき、超過分の手数料や利用制限を含められます。

ただし手数料や利用制限は、アクセスを提供することにかかるコスト・複雑性・リスクに合理的に比例していなければならず、CUA提供者はその妥当性の審査をFTCに申し立てられます。

手数料や利用条件は公表し、変更には合理的な事前告知が必要です。

セキュリティについては、業界のベストプラクティスに沿って、プラットフォームやユーザーデータへの脅威に対処するために合理的に必要な範囲で、プライバシー・セキュリティ基準を設定することが義務として書かれています。

その基準はFTCへ届け出、FTCが公開します。

基準への違反が疑われる場合はFTCへ報告することも求められています。

インターフェースの変更にも制限があります。

認可されたCUAのアクセスを不合理に拒否したり弱体化させたりする「目的または実質的効果」をもってインターフェースや利用規約を変更することは、公正・合理的・非差別的な条件でアクセスを維持する義務の違反とみなされます。

ここは「目的」だけでなく「実質的効果」も含む書き方になっており、意図の立証を待たずに結果の側から問題にされうる条文だと私たちは読んでいます。

機能的同等性の規定は、すべての大規模プラットフォームに一律にかかる一般義務ではありません。

自社の大規模オンラインプラットフォームと、自社の他の製品・サービス・関連提供物のうちCUAに相当するサービスとの間で相互運用性を維持している場合に、そのインターフェースの機能的に同等な版を競合するCUAにも提供する、という条件付きの規定です。

このほか、成立から120日以内に、競合するCUA提供者に対して相互運用インターフェースへのアクセスを説明する完全かつ正確な文書を開示すること（ソースコードの開示までは求められません）、インターフェース変更の合理的な事前告知を行うことが定められています。

受け入れる側から見れば、これらは開けるか閉じるかの二択としては書かれておらず、開けたうえで頻度・量・コスト・セキュリティ基準という複数のつまみで運用する設計として読める、というのが私たちの受け取り方です。

CUAの側にも義務がある——放棄できない行為規範

受け入れ側の設計を考えるうえで見落とせないのが、CUA自身に課される義務です。

条文は、CUAに対して、ユーザーから提供された、またはユーザーに代わってアクセスしたユーザーデータのプライバシーとセキュリティを合理的に保護することを求めています。

そのうえで、ユーザーの不利益になってCUA自身が利益を得るような操作、合理的に予見できる害をもたらす操作、ユーザーの指示や合理的な期待に反する操作を禁じています。

データについては、委譲されたサービスの提供に合理的に必要な範囲を超えた収集・利用・共有を禁じ、広告・行動プロファイリング・販売その他の二次的な商業目的での利用・共有・保持も禁じています。

さらに、同様の立場にある通常の慎重な者に期待される注意・技能・勤勉さをもって行動する義務、ユーザーに代わって行った行動のリアルタイムの記録を保持し求めに応じてユーザーへ提供する義務、そしてユーザーの明示的・具体的・取消可能な承認なしに権限を他の主体へ再委譲しない義務が並びます。

これらの義務は、個々のエージェントの問題として閉じません。

CUA提供者は各エージェントが義務を守るための合理的な措置を確立・維持する責任を負い、違反のパターンや慣行は提供者に帰属するものとして、登録解除や執行の対象になります。

そしてこれらの義務は、契約によっても、利用規約によっても、いかなる形式のユーザー同意によっても、放棄・制限・変更できないと明記されています。

後述する私たちの整理でいう「監督者」に近い役割、つまり責任を負う組織上の主体は、CUA提供者という形で条文の側にも置かれています。

断るときの手続き——拒否理由の通知、14日の是正期間、FTCへの異議申立て

今回の主題に最も直接効くのは、ここだと私たちは考えています。

私たちが見てきた範囲では、外部からのアクセスを止める機能そのものより、止めた理由を相手に説明し、直す機会を与え、第三者に経緯を示せる手続きのほうが、用意されていないことが多いと感じているためです。

条文は、プライバシー・セキュリティ基準に基づいてCUAのアクセスを拒否した場合に、次の手順を求めています。

まず、拒否の根拠を記した報告書を、FTCが求める様式でFTCへ提出します。

次に、そのCUAがどの点でプライバシー・セキュリティ基準を満たさなかったのかという理由を記した通知を、CUA提供者へ渡します。

そのうえで、CUA提供者に基準を満たすための14暦日の是正期間を与えます。

この期間中、プラットフォーム側は、基準を満たしたことをCUA提供者が示せるようになるまでアクセスを拒否し続けることができます。

CUA提供者は拒否をFTCへ不服申立てでき、FTCが、その拒否は恣意的または専断的であるか、提出された情報によって裏付けられていないと認めた場合には、FTCがアクセスを認めることができます。

提出された報告書は、個人を識別できる情報と営業上機微な情報を除いたうえで公開されます。

アクセスの取消し・拒否の事由も別に定められており、CUA提供者がFTCへの登録を行っていない場合、CUAが詐欺的または悪意ある活動を繰り返し助長している場合、顧客が明示の書面による同意を撤回した場合が挙げられています。

FTC側にも、義務違反を認定したCUA提供者を登録解除する規則と手続きを設ける規定があります。

執行は、この法律の違反をFTC法上の不公正・欺瞞的な行為・慣行に関する規則の違反として扱う形で行われ、罰金の算定にあたっては、違反によって影響を受けた個々のユーザーを1件の違反として考慮するとされています。

条文がここまで手続きを細かく書き下している理由そのものは、法案テキストからは読み取れません。

ただ、拒否の通知・是正期間・異議申立てという順序は、受け入れ側が単独で決めるとどうしても抜けやすい部分であり、そこを共通化しようとしている点は、私たちが自社の設計を見直すうえでも参考になると考えています。

法案の対象外でも残る論点（ここからはMIFの分析です）

ここまでは法案テキストに書かれていることです。

以下は法案の解説ではなく、私たちが自社やお客様の設計にこの内容を引き取るときの見方であり、法案がそう述べているわけではありません。

前提として、適用範囲は狭く読むべきだと考えています。

条文の「オンラインプロバイダー」は消費者向けのサービス提供者を指し、規模の閾値も5,000万人超です。

中小企業のシステムや企業間取引のSaaSがそのまま対象になると読むのは、条文の書き方から離れます。

それでも、外部のエージェントを顧客の代理として受け入れる場面で立つ問いの構造そのものは、規模や適用範囲と関係なく現れると私たちは考えています。

私たちは以前から、AIエージェントに与える権限は、人間の従業員と同じように「本人性・職務範囲・上限・監督者・操作記録・権限剥奪」の6要素をセットで設計すべきだという立場をとってきました。

この6要素と条文を突き合わせるのは、法案がそう整理しているからではなく、私たちが自社の設計に引き取るための対応づけです。

読み合わせてみると、これまで受け入れ側が個別に決めるしかなかった部分のかなりが、共通化されうるものとして条文や将来の標準の側に置かれている、というのが私たちの受け取り方です。

一方で、業務ごとの具体的な値と社内の体制は、標準ができたとしても各社に残ります。

次の表は、その線引きを整理するための叩き台であり、正しい設定を示すものではありません。

自社のリスク許容度・業界規制・扱う操作の取消可能性によって、埋める値も判断基準も変わります。

要素	法案・将来の標準が扱おうとしている部分	各社に残る具体的な判断
本人性	CUA提供者のFTC登録をアクセスの前提条件とすること、要求が本人由来であることを検証する規則、NISTによるCUAの身元・登録状況の検証プロトコル	登録や認証をどの操作までの信用材料として扱うか、標準が整うまでの暫定的な確認手段
職務範囲	範囲限定かつ取消可能な委譲資格情報の標準、商用場面ごとの委譲範囲の設定、ユーザー以上の権限を与えない原則	自社のどの操作を委譲可能として開くか、閲覧・変更・決済のどこに線を引くか
上限	頻度・性質・量に関する合理的なしきい値、公正・合理的・非差別的な利用条件、コスト・複雑性・リスクに比例した手数料	1回あたりの購入額や1日あたりの件数といった業務固有の値、何を測って上限とするか
監督者	CUA提供者が組織として遵守措置を負うこと、違反のパターンが提供者に帰属すること	受け入れる自社側で誰が許可を判断し、誰が止める権限を持つか
操作記録	CUAによるリアルタイム記録の保持とユーザーへの開示、監査可能な記録の作成に関する標準、拒否報告の公開	自社側にどこまで記録を残すか、相手側の記録とどう突き合わせるか、保存期間
権限剥奪	ユーザーによる取消しと、その速やかな伝達の仕組み、未登録・反復的な不正を理由とする拒否・取消し、FTCによる登録解除、拒否理由の通知と14暦日の是正期間	異常をどう検知するか、止める範囲を当該エージェントに限るか提供者単位にするか、復旧と再承認の手順

右の列に入るものは、既存の業務ルールをそのまま流用しにくいことが多いと感じています。

人間の担当者を想定して作られた承認フローや与信ルールは、代理人が人間よりずっと高い頻度と速度で操作することを前提にしていないためです。

なお本稿は、外部のエージェントを受け入れる側の判断を対象としており、社内で動かすエージェントの身元管理や、この法案が今後どこまで政治的に進むかの見通しは対象外とします。

まとめ——共通化される部分と、各社に残る部分

AI AGENT Actは、2026年8月時点では委員会へ付託された段階の法案であり、この先どう変わるか、あるいは成立するかは分かりません。

ただ、条文が置いている論点は、成否を待たずに読める材料になっています。

登録・本人性の検証・委譲と取消し・アクセス条件・拒否の手続きまでを共通の枠組みとして書き下そうとしている一方で、金額や件数の上限、社内の判断者、異常の検知条件、止める範囲、復旧と再承認の手順といった運用は、法案が成立したとしても各社が決める部分として残ります。

自社のサービスに顧客の代理として動くエージェントが訪れる可能性があるかを棚卸しし、上の表の右の列を自社の言葉で埋めてみることは、法案の行方にかかわらず意味のある準備になるはずです。

少なくとも、断り方を決めていない状態で最初の1件を受け取るよりは、進めやすくなると私たちは考えています。

情報確認について

本記事は2026年8月時点で、米国政府出版局が公開する連邦議会資料システム上のS.5051（AI AGENT Act of 2026、2026年7月21日上院導入版）の法案テキストおよび法案ステータス記録を主要な参照元として作成しています。

背景として、Warner上院議員事務所が2026年6月29日に公表した討議草案に関する発表を参照しています。

二次資料として、法律事務所DLA Piperによる法案分析、および専門メディアCyberScoopの報道を参照しました。

本文中のFTCによるCUA提供者の登録制度、認証機関の認定、NISTによる技術標準は、いずれも法案が成立した場合に整備されるものとして条文が定めているもので、2026年8月時点で存在する制度ではありません。

本人性・職務範囲・上限・監督者・操作記録・権限剥奪の6要素との対応づけ、および法案の適用範囲外への一般化は、法案の内容ではなくMIF LLCの分析です。

法案は2026年8月時点で商業・科学・運輸委員会へ付託された段階であり、条文の細部・審議の状況・成立の有無は今後変更される可能性があります。

最新の状況については、米連邦議会の公式記録でご確認ください。