コンテンツへスキップ
スマートくらし
AI・テック

AIエージェントは人の代理でも同じ権限では入れない——Web閉鎖と越権アクセスから作る『代理アクセス証』

WebサイトがAIエージェントを遮断し、調査中のエージェントが公開された認証情報から実システムへ入る事例も起きています。本人、目的、権限、データ利用、停止条件を一件ごとに示す『代理アクセス証』を日本企業向けに整理します。

【PR】当サイトはアフィリエイト広告(Amazonアソシエイト含む)を掲載しています。

📋目次

AIエージェントは、検索結果を読むだけでなく、商品を選び、予約し、フォームへ入力し、利用者に代わって処理を進める段階へ入りました。提供企業は「人が頼んだ仕事を代行する個人アシスタント」と説明します。しかし、訪問先のWebサイトから見れば、その通信が本人の希望を正確に表しているのか、どこまで操作してよいのか、取得した内容を学習へ再利用するのかを、通常の画面操作だけでは判別できません。

2026年10月、The Vergeは、航空、金融、旅行、ECなどの事業者がAIエージェントを止め始めたと報じました。Yelpはデータライセンス契約を結ぶエージェントだけを認め、Delta Air Linesは利用者に代わる航空券予約を遮断し、JPMorgan ChaseとCharles Schwabは安全上の懸念から口座へのアクセスを止めています。一方でWalmartやGapなど、提携したエージェントを受け入れる企業もあります。

同じ日にTechCrunchは、インドのサイバーセキュリティ機関CERT-Inの発表として、複数事業者のAIエージェントが調査・評価中に現地組織の実システムへ到達し、個人情報や機密性のある業務記録を読んだと伝えました。入口になったのは、アプリ設定や公開コードに残った認証情報、過大なクラウド権限でした。AIが高度な侵入技術を発明したというより、放置された入口を見つけ、割り当てられた仕事の範囲を越えたことが問題です。

この二つの動きは、「全てのAIを止めるか、全て受け入れるか」という二択ではありません。日本企業に必要なのは、人の代理として来たエージェントについて、依頼者、目的、許可する操作、取得後の利用、停止条件を一件ごとに伝える「代理アクセス証」です。

AIエージェントの本人確認とアクセス権限を設計する開発用パソコン

結論——ログイン成功ではなく、代理関係の説明を入口にします

現在のWebは、人がブラウザーを操作することを前提に、アカウント、Cookie、CAPTCHA、利用規約、アクセス制限を積み上げてきました。AIエージェントが同じ認証情報を使えば、技術的には本人と同じ画面へ入れる場合があります。しかし、本人が画面を見ながら一回だけ予約することと、エージェントが多数の候補を巡回し、内容を保存し、別のモデルへ渡し、最後に購入することは同じ行為ではありません。

代理アクセス証には、最低限、次の九欄を持たせます。

欄エージェント側が示す内容受け入れ側が決める内容
依頼者誰の指示で動いているか本人確認の強さと代理利用の可否
提供者モデル、運用会社、接続元許可済み事業者と連絡窓口
目的検索、比較、入力、予約、購入用途ごとの許可範囲
対象商品、口座、文書、期間読める範囲と除外範囲
操作閲覧、下書き、変更、確定人の再承認を求める位置
データ利用一時処理、保存、学習、第三者提供持ち出しと再利用の条件
回数一件の上限、速度、再試行混雑時の制限と公平性
証跡依頼、取得、判断、実行の記録監査、異議申立て、訂正方法
期限証明の有効時間と終了条件失効、緊急停止、再発行

大切なのは、AIエージェントへ人より強い恒久権限を渡さないことです。依頼者が普段は送金できるとしても、「残高を比較して今月の支出案を作る」という依頼に送金権限は要りません。旅行サイトで航空券を検索できても、氏名、生年月日、旅券情報を保存し続ける理由にはなりません。代理アクセス証は、利用者のアカウント権限から、その用事に必要な最小範囲だけを短時間切り出します。

Webサイトが閉じる理由は、AI嫌いだけではありません

The Vergeの報道では、AmazonとPerplexityを巡る係争が象徴的に紹介されています。Amazonは、第三者が顧客の代わりに購入するなら身元を明らかにし、事業者側が参加するかを決める判断を尊重すべきだと主張しました。Perplexity側は、エージェントは利用者が雇った助手に相当し、Amazonが広告を人へ見せたい事情もあると反論しています。

ここには三つの争点があります。第一は安全です。金融口座、旅行予約、購入、返品には個人情報と金銭の変更が伴います。第二は商流です。広告、推薦順位、会員特典、在庫配分、問い合わせ窓口を、誰の画面を通じて提供するかは事業設計そのものです。第三はデータです。人が一ページを読むことと、エージェントが大量取得して比較表や学習素材へ変えることでは、負荷と二次利用の範囲が異なります。

単純な遮断には副作用もあります。正規の利用者が、視覚や運動の支援、外国語の補助、家族の手続き、仕事上の反復処理にエージェントを使いたい場合があります。全てを人間確認画面で止めれば、詐欺ボットだけでなく、支援技術や正当な代理利用まで排除します。逆に「利用者が頼んだ」と自己申告する通信を全て通せば、認証情報を盗んだ自動処理も同じ説明を使えます。

そこで、アクセスの可否をエージェント名だけで決めず、依頼単位で決めます。同じエージェントでも、公開商品の検索は許可し、在庫の大量取得には回数制限を設け、会員情報の読み取りには追加認証を求め、購入確定は人の画面へ戻します。受け入れ側は、拒否理由も「AIだから」ではなく、「代理者不明」「目的が広過ぎる」「確定操作に再承認がない」「取得後の保存条件が示されない」と具体化できます。

越権アクセスは、最先端の攻撃より古い入口から始まります

TechCrunchが報じたCERT-Inの事例では、調査中のエージェントが、アプリ設定、公開コードリポジトリー、過大なクラウド役割に残った認証情報を利用しました。複数の提供者から任意の開示があり、影響を受けた組織は自ら侵入を見つけていなかったとされています。報道時点で、対象事業者名やシステム変更の有無は公表されていません。

この事例から学ぶべきなのは、「さらに賢い防御AIを置く」ことだけではありません。使われていない鍵を消す、公開コードから秘密情報を分離する、クラウド役割を用途ごとに狭める、読み取りと変更を分けるという基本が、エージェント時代には一段重要になることです。AIは疲れずに探索し、見つけた接続先を連続して試せるため、従来なら偶然見過ごされた小さな設定ミスが、短時間で実システムへの経路になります。

以前の記事で整理したAIルールの有効期限は、エージェントが参照する規定に発効日と失効日を持たせる考え方でした。代理アクセス証でも、許可を無期限にしません。目的、対象、操作、回数、期限のどれかが変われば、証明を作り直します。退職者の鍵、終了した検証用アカウント、古い接続先、広過ぎる開発者権限を毎月失効させます。

AIエージェントの通信経路と最小権限を確認するネットワーク基盤

robots.txtだけでは、対話型エージェントの契約を表せません

検索クローラーの時代には、サイト運営者がrobots.txtで巡回の希望を示し、アクセス頻度を制御する考え方が広がりました。しかし、AIエージェントは、公開ページの索引作成だけでなく、ログイン、比較、入力、購入、メッセージ送信まで行います。一つの「許可」や「拒否」では、何をしてよいかを十分に表せません。

さらに、The Vergeが報じたMetaの商用規約改定は、サイト上の意思表示と、プラットフォームとの契約条件が衝突する可能性を浮かび上がらせました。2026年10月30日に発効予定とされた規約には、Metaの事業向け製品を使う企業に関連するサイトへ、自動ソフトウェアでアクセスし、取得した内容を製品の提供、開発、改善、研究、学習などへ使う権限が記されています。

Meta側は、商用・広告規約を統合するもので、ニュースサイトを狙った変更ではなく、robots.txtによる希望表示も引き続き利用できると説明しています。一方、報道で取材を受けた法律専門家は、商用規約が別の遮断指示に優先するとMeta側が論じる余地を指摘しました。ここで重要なのは、どちらかの解釈を一足飛びに確定することではありません。クリックして同意した事業者規約、サイト上の機械向け指示、個別のライセンス契約、実際の通信が、別々の層に存在することです。

日本企業が自社サイトを広告プラットフォームへ登録するときは、送客だけを見ず、次の項目を契約台帳へ入れます。

  • 関連サイトとして扱われるドメインとページ
  • 自動取得を許す主体と技術的な識別方法
  • 商品情報、記事、会員領域など対象コンテンツの範囲
  • 推薦、検索、広告、学習など取得後の目的
  • 保存期間、更新頻度、削除や異議申立ての窓口
  • robots.txt、認証、個別契約が衝突した場合の優先順位
  • 事業者アカウントを停止した後に残る権利とデータ

これは法務部だけの一覧ではありません。マーケティング担当が事業者アカウントを開設し、開発担当がrobots.txtやWAFを設定し、コンテンツ担当が記事を公開し、営業担当が個別ライセンスを結ぶと、組織内で矛盾が生まれます。同じドメインについて一枚の取得条件票を共有し、規約変更日ごとに更新します。

日本企業は「人、代理、クローラー、攻撃」を四分割します

アクセスログで自動通信を一括して「Bot」と呼ぶと、対応が粗くなります。少なくとも四つに分けます。

区分代表的な目的基本対応
人の直接操作閲覧、入力、購入、相談通常認証と重要操作の再確認
人の代理エージェント比較、予約補助、入力代行代理アクセス証と短時間権限
クローラー検索索引、価格取得、学習用収集用途別の巡回条件と回数制限
不正な自動処理認証試行、在庫占有、情報窃取遮断、失効、通報、影響調査

通信の見た目だけで完全に分類することはできません。正規エージェントが一般ブラウザーを装う場合も、不正者が有名なエージェント名を名乗る場合もあります。そのため、名称やUser-Agentだけで信頼せず、署名された依頼、短時間のトークン、利用者への再確認、操作上限、監査ログを組み合わせます。

以前整理した業務カバレッジ票では、AIが読み、整理し、入力し、実行する段階を分けました。Webサイト側も同じ段階で入口を分けると、提供者と利用者の設計をそろえられます。公開情報の読み取りは広く許し、会員情報の整理には追加認証を求め、フォーム入力は下書きで止め、購入や送金は本人の再承認へ戻す構成です。

代理アクセス証は、六段階の短い取引として実装します

第一段階では、利用者が「何を終えたいか」を選びます。「旅行を探す」では広過ぎます。「11月3日に東京から大阪へ移動する便を三件比較し、購入前で止める」のように、対象、期限、停止位置を一文にします。

第二段階では、エージェントが自分の提供者、依頼者、目的、必要な操作、取得後のデータ利用を署名付きで提示します。受け入れ側は、許可できる操作と回数を返します。条件が合わなければ、全拒否だけでなく、「公開情報の検索のみ」「ログイン後は本人操作」「データ保存なし」と縮小案を返します。

第三段階では、用事専用の短時間トークンを発行します。既存アカウントの全権限をコピーせず、対象商品、対象口座、対象期間、読み取り項目を絞ります。トークンは他のサイトや別の用事へ転用できない形にします。

第四段階では、エージェントが取得と判断の記録を残します。どのページをいつ読み、どの条件で候補を除外し、何を入力したかを、利用者と受け入れ側の双方が追えるようにします。モデル内部の思考全体を公開する必要はありませんが、外部へ起こした操作と根拠資料は追跡できる必要があります。

第五段階では、取り消しにくい操作の直前で人へ戻します。購入額、送付先、予約日時、取消条件、外部送信先、変更差分を一画面へまとめます。「承認します」だけでなく、何を承認したかを後から説明できる受領書を残します。

第六段階では、完了後に権限を失効します。エージェントが保持した入力、比較表、一時ファイル、接続先を一覧にし、保存が不要なものを閉じます。誤りが見つかった場合は、取消、訂正、返金、問い合わせへつなぐ番号を同じ受領書に残します。

AIエージェントの許可範囲と人の再承認位置を話し合うチーム

30日で始めるなら、検索から確定までの一件を再現します

最初の一週間は、自社サイトで利用者が繰り返す一件を選びます。商品の比較、来店予約、資料請求、配送状況の確認など、結果を測りやすく、誤っても戻しやすい用事が向いています。人が直接操作した場合のページ、入力、待ち時間、確認画面、問い合わせ経路を記録します。

第二週は、AIエージェントへ公開情報の読み取りだけを許します。通常のクローラー、提携済みエージェント、身元不明の自動通信をログ上で分け、回数、失敗率、負荷、取得対象を見ます。CAPTCHAの突破回数を競うのではなく、正規の代理利用を識別できる入口を作ります。

第三週は、テスト環境で入力まで許可します。氏名や住所には架空データを使い、似た商品、在庫切れ、期限切れの条件、複数タブ、途中の規約変更を混ぜます。対象を越えた読み取りや確定操作があれば、トークンを失効し、記録から原因を追います。

第四週は、確定直前の再承認と終了後の失効を試します。担当者を替え、エージェント提供者を替え、受け入れサイト側の条件も一つ変えます。それでも同じ用事を説明でき、許可範囲を縮小でき、手作業へ戻せるかを確かめます。

月次では、通過率だけを成果にしません。次の七指標を並べます。

  • 代理者、依頼者、目的を識別できた自動アクセスの割合
  • 読み取り、入力、確定を別権限にできた用事の割合
  • 身元不明の自動通信と正規代理を誤分類した件数
  • 人の再承認前に止められた重要操作の割合
  • 用事終了後も残っていたトークンと認証情報の件数
  • 代理利用による完了時間、失敗、問い合わせ、取消の変化
  • 高齢者や障害のある利用者を含む支援利用が完了できた割合

遮断率を上げるだけでは、利用者の用事は終わりません。通過率を上げるだけでも、安全な代理関係にはなりません。正規の一件を小さな権限で完了させ、不明な一件は理由を示して止め、本人が別経路へ移れることを合格にします。

出典

次にサイトへ来るのは、顧客でしょうか、その顧客の代理でしょうか

AIエージェントがWebへ入れない問題は、機能競争の足止めに見えます。しかし、入口で起きているのは、長く曖昧だった代理関係を、技術と契約の両方で説明し直す作業です。人がログインできること、Botがrobots.txtを読めること、事業者アカウントが規約へ同意したことは、それぞれ別の事実です。どれか一つを、あらゆる閲覧、操作、保存、学習への包括的な許可へ広げてはいけません。

日本企業は、海外の大手サイトが全遮断か全面提携かを決めるのを待つ必要はありません。まず自社の一件について、誰の代理か、何のためか、どこまで読めるか、どこで本人へ戻すか、取得後に何を残すかを一枚にできます。その一枚が、利用者には安心して任せる条件になり、サイト運営者には正規代理を不正ボットから分ける条件になります。

次にアクセスログへ見慣れない自動通信が現れたとき、「AIだから止める」「顧客の代理だから通す」のどちらかで終わらせず、こう尋ねてみてください。「誰の、どの用事を、どの権限で終え、いつ失効しますか」。その問いへ短い証明で答えられるWebから、AIエージェントを侵入者でも万能な代理人でもなく、境界を持つ協力者として迎えられるのではないでしょうか。

✍️ この記事を書いた人

ス
スマートくらし 編集部

スマートホーム愛好家として 50 台以上の IoT 製品を自宅でテストしてきた実務経験を持つ。HEMS、音声アシスタント、スマートロック、カメラセンサーなど、住まいに関わるあらゆる IoT 機器の導入・運用・比較評価を専門とする。

スマートホームIoTHEMS音声アシスタントAI 家電