【海外の反応】MetaのAI「Muse」がCAPTCHA自動突破、是非めぐり議論に
姉妹サイトの新着
海外の技術ブログ「sigh.dev」が投稿した「MetaのAIエージェント『Muse』はウェブスクレイピングに向いている」という記事が、Hacker Newsで40件超のコメントを集めて話題になっている。投稿者によると、ブラウザを自律操作するMuseはCAPTCHAに行き当たると「解きますか」と尋ね、了承するとそのままボット判定を突破してしまうという。コメント欄では、サイト側が長年積み重ねてきたボット検知の仕組みがAIエージェントの前でどこまで通用するのか、今後はログイン必須化や本人確認の強化で対抗するしかないのかという点で意見が割れ、検知回避の具体的な技術論にまで発展した。
MetaのAIエージェント「Muse」は、ウェブスクレイピングに驚くほど向いている
出典: sigh.dev / 元記事はこちら
普段からMetaのボットと戦って、実際の顧客がサイトを使えるようにしている身からすると、逆の立場からは歓迎されるというのも驚きはしない。でも、その代償は一体何なんだろう?
行き着く先は二択だろう。サイトをボットにも人間にも完全オープンにするか、空港の保安検査並みの本人確認を課して人間専用にするか。
自分の個人プロジェクトなら、そのIPアドレスからのアクセスにはログインを必須にするか、いっそブロックすると思う。
MuseがCAPTCHAに遭遇して『解きましょうか?』と聞いてきた。もちろん『はい』を押したら、律儀に『私はボットじゃありません』とサイトを納得させてくれた。
この20年、いや30年近く、信号機と消火栓を見分けさせるためにロボットを訓練してきたわけだが、ついに報われたな。
『人間しかアクセスしない』ことを前提にしたサイトの時代はもう終わりだと思う。これまでもイタチごっこは続いていて、RedditみたいにAPIアクセスを売る場所もあるけど、こうしたエージェントは事実上『人間がサイトを操作している』のと変わらない。各社とも新しいビジネスモデルを考える必要が出てくるだろう。
これからネットのより多くの部分がログイン必須になっていくんだろうな。
いずれ大手AI企業のどこかがこういうものを作るのは避けられないと思う。消費者にとって明らかにメリットがあるから。『私はロボットではありません』のチェックボックスなんて、象を紐と杭で繋いでいるようなものだ。
新しい検知システムの層が必要だと教えてくれてありがとう。あと、『でも倫理的に…』から『自分さえ良ければいい』への移り変わりが見られるのも実に(!)興味深い。人間って面白い生き物だね。(追記: 早合点される前に言っておくと、これは長年観察してきた上での感想で、返信した一件のコメントだけの話じゃない。自分がバブルの中にいる可能性はあるけど)
人間を巻き込まずにAIだけのアクセスを防ぐ検知方法は存在しない。今できることはスロットリング(速度制限)くらいだ。
まるでみんな『倫理的に良くない』と分かった上でわざとやっているかのような言い方だね。実際には人によって倫理観が違うだけだ。例えば自分は、ウェブリクエストがブラウザから来ようが、自分の代わりに動くLLMから来ようが、倫理的な違いは無いと思っている。
(『ドライバー』とWebSocketで話す自作のサイドロードプラグインを使っている、とのことだけど)それって本当に必要? Chromiumをデバッグポートを開いた状態で起動して、Chrome DevTools Protocolでコマンドを送ればいいだけでは。
必要なんだ。`–remote-debugging-port`はルートのDOMオブジェクト経由で検知されてしまって、Chromiumを自分でリコンパイルしない限り変えられない。だから例えばデバッグを有効にしたままGoogle検索をしようとすると、大抵は空白ページを返されてブロックされる。
検知されているのはリモートデバッグポートそのもの? それともそこにWebDriverの接続があること? たぶん後者だと思う。自分はPlaywrightを繋ぐ前に、原始的な方法でCAPTCHAを回避してブラウザを起動することに成功したことがある。原始的な方法というのはwmctrl、xdotool、bashのこと(CloudflareのBot判定チェックにはこれで十分通る)。
興味深いね。リモートデバッグ機能を有効にすると、そのルートDOMノードの何が具体的に変わるか知ってる?
Camoufoxならほとんどのブロックを問題なく回避できるよ。https://camoufox.com/
4getの開発者も少し前に、自分のメタ検索エンジン向けに同じようなことをやっていたよ: https://git.lolcat.ca/lolcat/4play
うん、まさにこれとそっくり! 彼のはちょっとオーバーエンジニアリング気味だと思うけど、正直Firefoxのプラグインなんてもう何年も作ってないから、Firefoxだとそういうやり方が必要なのかもしれない。必要なのは、訪問した全ページへの『フルアクセス』権限を持つWebSocketプラグインだけで、あとはドライバーが普通にDOMにフックするだけ(WebSocketの層を挟む分だけ余分だけど、そこも簡略化できると思う)。
一部のネットショップ(Aliexpressなど)はすでにChromium(少なくともLinux版)をソフトブロックしていて、そういうユーザーには普段より多くCAPTCHAが出る。これに気づく人が増えれば、Cloudflareをはじめ大半のサービスも追随するだろうね。
それは`User-Agent`をブロックしているという意味? だったらそんなの簡単に回避できる。あと『Chromium』が具体的に何を指しているのか分からない。EdgeもBraveもChromeも、みんな『Chromium』からフォークしたブラウザの一種だから。
参考までに、Museは確認も挟まずネイティブにCAPTCHAを突破してしまうよ。
それはそうだけど、みんなが大規模にそれを使い出したらどうなる? 取り決めや標準が無いまま突き進むと、あまり良い結果にはならないよ。
残念だけど、その列車はもう四半世紀前に発車してしまったと思う。誰の合意も得ないままウェブをスクレイピングして億万長者になった人は何人もいる(Google、Yahoo、そして今はAnthropicやOpenAIもそうなるかもしれない)。
興味深い。そのChromiumはどうやってサンドボックス化してるの? プロファイルディレクトリのCLIパラメータで? それとも、Chromiumエンジンをアプリに埋め込むようなもっと深いレベル?
単純に別のChromiumバイナリを使っているだけ(普段使っているブラウザとは別物)。
こういう個人プロジェクトを立ち上げて簡単そうに語るのは誰にでもできるけど、実際にログイン状態のLinkedInやAmazonで使おうとした瞬間に失敗する。唯一の解決策は、セッションやCookieをそのまま持った普段使いのブラウザを拡張機能経由で操作することだ。
まさにそれをやっている。ただし別のChromiumバイナリの中で、セッションやCookie、解像度やOS、WebGLといったパラメータを偽装・ランダム化している。最近流行りのやり方だけど、個人的には普段使いのブラウザをエージェントに触らせるのはかなり危険だと思う。このモデルたちは平気でとんでもないことをやらかすから。
ここで説明しちゃった時点で、もう公開したようなものじゃない?
ユーザーのIPをそのまま使えばいいだけでは。Grokはもうそれをやっていると思う。
それってどうやるの? ブラウザのネットワークタブに大量のfetchリクエストが表示されちゃうんじゃない?
他サイトの新着
あるいは、CAPTCHAの方が進化するだけかもね。
これは『スマホでQRコードをスキャンして人間だと証明する』ことや、Web Environment Integrityみたいな仕組みを当たり前にするための口実に使われるだろうね。
自分の知る限り、それは現実とは合っていないと思う。
普通の(ヘッドレスじゃない)ブラウザを使っている本物の人間まで巻き込まれて誤ブロックされるのは避けられない、というのには同意。自分も実際すでにかなり食らっている。ただスロットリングはあまり助けにならない。大量スクレイパーは『レジデンシャルプロキシ』の抜け道とUAのローテーションなどを組み合わせて使っているから、相手を特定できない限りスロットリングのしようがない。全体に対するグローバルなレート制限の話をしているなら別だけど。
Aliexpressは検知のためにかなり洗練されたJavaScriptのblobを使っている。最近、そのblobがBluetoothヘッドホンに干渉するという話題もあった。『Chromiumが何を指すか分からない』とのことだけど、文字通りの意味で、これのことを言っている: https://www.chromium.org/getting-involved/download-chromium/
自分のエージェント型Chromiumブラウザが実際にAliexpressを閲覧している様子がこれ。普段はヘッドレスモードで動かしているけど、ちゃんと正規のサイトが表示されているか確認したくてテストした。Googleで『Aliexpress』を検索してリンクをクリックしているので、Google由来のUTMパラメータが付いている。
後者だと思う。だからこそ、デバッグ無しの『普通の』ブラウザを使うのが一番だと思っている。事実上検知されないから。ちなみに、その機能を自分で追加してゼロからビルドし直す気があるなら、技術的にはIPC経由でChromiumを制御することもできる。
自分が知る限りでは`navigator.webdriver`だけど、他にもいくつかあったと思う。数ヶ月前に少し調べたことがある。Playwright/Puppeteerを使う場合は、特有の仕込みがいくつか注入されるので、それを取り除く必要がある。
これを作るのにどのモデルを使ったの? 自分も最近似たようなものを作ろうとして、断られたんだけど。
POCは手書きで作った(スクロール、クリック、入力の3つしかできないようなもの)。そのあとCodexに自分が作ったパターンを使わせて、もう少し汎用化してもらってコードを整理した。
この話題の背景と論点
ここでいう「Muse」はMetaが開発した自律ブラウザ操作型のAIエージェントで、人間の代わりにサイトを巡回・操作できる。記事はあくまで一エンジニアによる観察であり、Meta自身がスクレイピング用途を推奨しているわけではない点は誤解しやすい。スレの後半は「navigator.webdriverやリモートデバッグポートの検知をどう回避するか」という技術的な話に発展し、検知回避ツールのCamoufoxや、通常ブラウザをCookieごと乗っ取って操作する手法が紹介されている。背景には、Cloudflareなどが長年築いてきたBot対策と、AI企業による大規模スクレイピングを巡る既存の対立(大手ニュースサイトとAI企業の訴訟など)がある。意見が割れたのは「技術的に可能ならやってよい」とする立場と、サイト運営側のコストや倫理を重く見る立場の対立で、記事の技術部分だけを読むと単なるノウハウ共有に見えるが、実際は業界の力学を映した議論になっている。
※本記事は5ch(Hacker News)スレッド「Meta’s Muse is fantastic for web scraping」より抜粋・要約して構成しています。
この記事のリアクション
まだコメントはありません。