MuseでAmazonにログインできない理由｜出口IPを調べた

MetaのAIエージェント「Muse」に収益レポートの集計を任せたところ、AdSense・DMM・楽天には自動でログインできたのに、Amazonだけはログイン画面すら出ませんでした。

運営者の環境で切り分けた結果、原因はアカウントや操作ではなく、Museの通信が外へ出ていく出口（出口IP）の側にあると見ています。

この記事では、その切り分けの手順と、規約に触れない回避策をまとめます。

結論：Amazonだけが通信の段階で止めていた

Museの通信は米国のデータセンターのIPから出ていて、Amazonはブラウザーを通さない通信にも、通常のページではない応答（HTTP 202）を返しました。

Amazon.co.jpの利用規約には、AIエージェントのアクセスを技術的な措置で制限できることと、その制限を回避してはいけないことが書かれています。

そこで出口IPを変えるような回避はやめて、Amazonの分だけをMuseとは別のマシンで記録する形に分けました。

• 計測日：2026年11月7日〜8日（運営者の環境での計測）
• 公式の資料・規約の確認日：2026年11月8日
• わかったこと：Amazonだけが、ログインの前の段階で通信を止めていた
• 確かめていないこと：AmazonがMuseを名指しで止めているのか、データセンターのIP全般を止めているのか（外からは区別できない）

同じ症状で困っている人向けに、症状ごとの確かめ方を先にまとめます。

4つのAIボット（dots・Claude Duet・Grok Bot・Muse）の違いはAIボット4つの比較にまとめています。

→ 関連：MuseでXに自動投稿する方法｜ログインが弾かれる原因と4つの方式の費用

やりたかったこと：4媒体の収益を毎朝まとめる

目的は、アフィリエイトと広告の収益の日次レポートを自動にすることでした。

対象はGoogle AdSense・Amazonアソシエイト・DMMアフィリエイト・楽天アフィリエイトの4つです。

毎朝、前日の分と当月の累計を集計して、レポートにまとめます。

Museにブラウザーの操作を任せ、各媒体の管理画面にログインして数字を読ませる形を組みました。

症状：ログインのフォームすら出ない

Amazon.co.jpを開くと、サインインの画面に進む前に「ご迷惑をおかけしています！」のエラー画面が出て、先に進めませんでした。

IDやパスワードを入れる欄そのものが表示されません。

試した3つの入り口はすべて同じ画面

1. Amazon.co.jpのトップからの通常のサインイン
2. アソシエイト・セントラルへのサインイン
3. アソシエイト用のサインインのURLを直接開く

3つとも同じエラー画面で止まりました。

人が手で操作しても変わらない

Museのブラウザーを人が手で操作しても、結果は同じでした。

入力の速さや操作の手順ではなく、もっと手前で止められていることになります。

ゆっくり開かせても変わらない

11月8日23時17分に、Museへ「ゆっくり開く」という条件をつけて、Amazon.co.jpのトップを1回だけ開かせました。

表示は「ご迷惑をおかけしています！」のまま変わりませんでした。

操作の速さではなく、ページを取得した時点で止まっていると見ています。

切り分け1：ブラウザーを通さない通信でも弾かれる

ブラウザーの問題かどうかを確かめるため、同じマシンからブラウザーを使わずに直接アクセスしました（2026年11月7日）。

Amazonのトップだけが、ほかのサイトと違う応答を返しています。

ブラウザーを通さなくても止まるので、原因はブラウザーではなく通信そのものにあると判断しました。

念のためGoogle Chromeを入れて試しましたが、出口が同じなので結果は変わりませんでした。

切り分け2：出口IPは米国のデータセンター

次に、このマシンの通信がどこから外へ出ているかを調べました。

出口は、Fastlyのネットワークに属する、米国のデータセンターのIPでした。

日本の家庭の回線ではありません。

Museの通信は管理された出口から出る

Metaの安全の解説によると、Museの仮想マシンからの通信はフォワードプロキシを通り、出口で「Sentinel」という仕組みがすべてのリクエストを管理しています（Metaの解説）。

同じ解説には、出口の地域やIPを利用者が選べるという記載は見当たりませんでした。

同じ環境からGoogle・DMM・楽天には普通にログインできたので、遮断の厳しさはサービスごとに違い、Amazonがとくに厳しいというのが計測からの結論です。

入れていたCLIは関係なかった

Museの環境には開発支援のCLI（Grok Build）を入れていたため、そのせいかどうかも確かめました。

マシンの中で閉じて動く単体のCLIで、ネットワークの設定・hostsファイル・ブラウザーのプロファイルは変わっておらず、今回の症状とは無関係でした。

報道されているAmazonとMuseの対立

Business Insider Japan（2026年9月24日）は、AmazonがMuseによる買い物を自社のサイトで止めたと報じています（記事）。

記事によると、Museで買い物をしようとした利用者には、権限のないAIエージェントによるアクセスは規約違反だという趣旨の警告が出たそうです。

ただし運営者の環境で出たのは、その警告ではなく「ご迷惑をおかけしています！」のエラー画面でした。

Museの通信だから止められたのか、データセンターのIPだから止められたのかは、外からは区別できません。

Amazon.co.jpの利用規約にあるエージェント条件

Amazon.co.jpの利用規約（2026年11月2日更新、11月8日に確認）には「エージェント」の節があります。

ここでいうエージェントは、人や組織の代わりに自律的、または半ば自律的に動くソフトウェアやサービスのことです。

• エージェントは、自分がエージェントだと明らかにしたうえでなければ、アマゾンのサービスを使えない
• Amazonから控えるよう求められたサービスには、アクセスできない
• Amazonは、技術的な措置などでエージェントのアクセスを制限できる
• すべてのリクエストのユーザーエージェントに、エージェントの名前を書く
• 人の操作をまねたり、CAPTCHAを迂回したりして、エージェントであることを隠さない
• 遮断や制限の措置を回避しない

出典はAmazon.co.jp利用規約の「エージェント」と「利用許可およびサイトへのアクセス」の節です。

同じ規約の利用許可の節でも、データマイニングやロボットなどのデータ収集・抽出ツールの使用は許可の外とされています。

Museが自分をエージェントと名乗る形で通信しているかどうかは、確かめていません。

いずれにしても、出口IPを変えて通そうとすると、この「制限を回避しない」に触れるおそれがあります。

切り分け3：Creators APIは応答するがレポートは空

Webの画面がだめならAPIで取れないかと考え、Amazonアソシエイトの「Creators API」を同じ環境から試しました（2026年11月8日）。

APIの宛先は202を返さない

APIの宛先（creatorsapi.amazon）は、Webのような202ではなく、通常のAPIの応答を返しました。

同じ出口から出ても、WebとAPIでは防御の仕組みが別のようです。

認証が通っても、収益の数字は取れなかった

問題は、成果レポートの一覧が空だったことです。

Creators APIの公式ドキュメント（Welcome to Creators API、11月8日に確認）は商品情報の取得が中心で、成果レポートの使い方は見つかりませんでした。

連携サービスの説明には、成果レポートはAPIの登録とは別に、サポートを通じた有効化が要るとあります。

運営者のアカウントは売上の規模が小さく、レポートが発行されていなかったと見ています。

切り分け4：出口IPを変える方法は採らなかった

出口IPが原因なら、日本の回線から出るように変えれば通るかもしれません。

3つの方法を考えましたが、どれも採りませんでした。

TailscaleのExit Node

Exit Nodeは、tailnetの中の1台を出口にして、ほかの端末のインターネットの通信をすべてその1台から出す機能です（Tailscaleの公式ドキュメント）。

自宅のPCを出口にすれば日本の回線から出せる、という考えでした。

しかしMuseの環境で使えたTailscaleのクライアントはExit Nodeに対応しておらず、ブラウザーの通信はトンネルを通りませんでした。

レジデンシャルプロキシ

家庭用の回線を貸し出すプロキシなら、通る可能性はあります。

ただ、ログインする地域が不自然に変わることが、かえって不正ログインの判定を招きかねません。

Amazonのパスワードなどの認証情報を、第三者の経路に通すことにもなります。

先に見た利用規約の「制限を回避しない」にも触れるおそれがあるため、使わないと決めました。

回避策：台帳を挟んで、媒体ごとに経路を分ける

全部をMuseで取るか、全部あきらめるかの二択にせず、間に台帳を挟むのが今回の答えです。

1. Googleスプレッドシートを収益台帳にする
2. AdSense・DMM・楽天の3つは、Museが毎朝台帳に追記する
3. Amazonは、Museとは別のマシンで動くタスクが毎朝7時に台帳へ追記する
4. 朝8時のレポートは台帳だけを読み、4媒体を合算する

Amazonの分は、Museとは別のマシンでCreators APIを使って記録する方にしました。

Amazonの行が無い日は、レポートに「未記入」と出して、売上0円の日と区別します。

取れなかった日を0円と見誤ると、月の累計がずれていくためです。

この形のデメリットは、Amazonの分のために、Museとは別のマシンを毎朝動かしておく必要があることです。

Museで無理にログインするのは、やめておいた

Museの環境で出口を変えて無理にログインする方法は、現時点ではやめておくことにしました。

規約の面でも安全の面でも、得るものより失うもののほうが大きいと考えたからです。

今後、Museの出口の地域を選べるようになったり、手元の端末のブラウザーと連携できるようになったりしたら、もう一度試してみます。

改善されるといいなと思っています。

Xで見かけた回避策（おすすめしない）

Xでは11月6日〜7日ごろ、MuseでAmazonを開けたという投稿もいくつか見かけました。

投稿者は伏せて要旨だけを並べますが、どれも運営者は試しておらず、未検証です。

• Museの内蔵ブラウザーではなくChromeを使うよう頼んだら開けた（ただし、タスクとして動かす作業は内蔵ブラウザーでないとだめらしい）
• SSHでMuseの仮想マシンを自分のPCにつなぎ、Playwrightでブラウザーを操作して通した
• PCを丸ごと操作できるようにして、ブラウザーを動かすと開けるらしい
• 負荷をかけないよう、ゆっくりクリックしてと頼んだら普通に見られた
• 課金しなくても突破できた

前の3つは、出口を自分のPCに変える方法

SSHとPlaywrightの例と、PCを丸ごと操作する例は、Amazonへの通信が自分のPC（日本の家庭の回線）から出る形です。

Chromeの例も、手元のPCのChromeを指しているなら同じ形と読めます。

運営者の環境では、Museの仮想マシンにChromeを入れても結果は変わりませんでした。

どれも、この記事の「出口IPの側に原因がある」という見立てと合います。

ゆっくり開く例は、別の話と見ている

ゆっくりクリックする例は、運営者の追試（11月8日）では再現しませんでした。

閲覧の途中で操作の頻度から判定される話で、ページを取得した時点で止まる運営者の症状とは別物と見ています。

課金の有無で結果が変わるかどうかも、確かめていません。

おすすめしない理由

• Amazon.co.jp利用規約の「エージェント」の節にある、人の操作をまねない・遮断や制限の措置を回避しない、に触れるおそれがある
• ふだんと違う経路や操作でのログインが続くと、自分のAmazonのアカウントが不正ログインと判定されるおそれがある
• SSHでつないだり、PCを丸ごと操作させたりすると、AIに開く自分のPCの範囲が広がる

運営者はこれらを試していません。

Museで無理にログインするのは、現時点ではやめておきました。

同じ症状のときの確かめ方

クラウドで動くAIエージェントに、ブラウザーの作業を任せる前に確かめておくと早い順に並べると、次のとおりです。

1. エージェントの環境のターミナルで、出口IPの国と運営元（データセンターか家庭の回線か）を調べる
2. 同じ環境から、つなぎたいサイトの応答のコードを見る（202や403なら通信の段階で止められている）
3. サイトの利用規約に、AIエージェントや自動アクセスの条件が無いかを読む
4. APIがあるなら、認証だけでなく、使いたい機能（レポートなど）が有効かまで確かめる
5. 取れない媒体は、取れる経路（自宅の回線のマシンなど）に分け、台帳で合流させる

1と2の確かめ方は、たとえば次のコマンドです。

curl -s https://ipinfo.io/json
curl -s -o /dev/null -w "%{http_code}\n" https://www.amazon.co.jp/

1行目は出口のIPと国・運営元を表示し、2行目はAmazonのトップの応答コードだけを表示します。

応答が202のときは、ブラウザーを替えても通らないと考えてよさそうです。

確かめていないこと

• AmazonがMuseを名指しで止めているのか、データセンターのIP全般を止めているのか
• Museのブラウザーが、自分をエージェントとして名乗る形で通信しているか
• Museで、出口の地域を選んだり、手元の端末の回線を使ったりする公式の方法があるか
• Creators APIの成果レポートを有効にする条件（公式のドキュメントでは見つからなかった）
• 日本の家庭の回線から同じ手順でMuseを使った場合の結果
• Xで見かけた回避策が、いまも通るかどうか

出口IPや各サービスの応答は、2026年11月7日〜8日の計測時点のものです。

変わったことがわかったら、この記事に追記します。

まとめ

• MuseでAmazonにだけログインできなかったのは、ログイン画面の手前で通信が止められていたため
• Museの出口は米国のデータセンターのIPで、Amazonはブラウザーを通さない通信にも202を返した
• Amazon.co.jpの利用規約は、エージェントの制限と、その制限を回避しないことを定めている
• Creators APIは応答したが、成果レポートは空で、収益の数字は取れなかった
• 台帳を挟み、Amazonだけ別のマシンで記録する形に分けて解決した

次の一歩として、クラウドのAIエージェントに管理画面の作業を任せるなら、最初に出口IPと各サイトの応答を確かめておくのが近道です。

Museとほかのボットの料金や日本で使えるかの違いは、AIボット4つの比較で並べています。

MuseにCLIを入れて使う話の続きは、Grok Buildの導入の記事へどうぞ。

参考にした資料は次のとおりで、いずれも2026年11月8日に確認しました。

• Amazon.co.jp利用規約（エージェント、利用許可およびサイトへのアクセス）
• Security and safety for AI agents: our approach with Muse（Meta）
• Museの日本での提供開始（Meta）
• Welcome to Creators API（Amazonアソシエイト）
• Exit nodes（Tailscale）
• AmazonによるMuseの遮断の報道（Business Insider Japan、2026年9月24日）