読み物
楽天RMSの完全自動ログインに
つまづいた経緯
AIエージェントでEC業務を自動化していると、かなり早い段階でぶつかるのが「ログイン」の問題です。
楽天RMS、広告管理画面、受注管理システム、会計ソフト。
人間が操作するときには何気なくやっているログインですが、AIエージェントにやらせようとすると、意外とここが大きな壁になります。
私も楽天RMSの自動ログインでは、かなり長い間苦戦しました。
着手したのが2026年6月20日。
完全に原因が分かったのが9月4日なので、約2か月半かかったことになります。
しかも最終的に分かったのは、
「楽天がAIをBot判定してログインを拒否していた」という、AI自身の説明が必ずしも正しくなかった
ということでした。
今回はその経緯を書いてみます。
そもそもAIはどうやってWebサイトにログインするのか
まず前提として、AIエージェントがWebサイトへログインする方法はいくつかあります。
1プログラムでID・パスワードを入力する
PlaywrightやSeleniumなどを使い、
- ID欄にIDを入力
- パスワード欄にパスワードを入力
- ログインボタンを押す
という、人間とほぼ同じ操作をプログラムにやらせる方法です。
ただし、AIサービスによってはセキュリティ上の理由から、AI自身が平文のパスワードを受け取り、そのまま入力するような処理を嫌がったり、断ったりすることがあります。
そこで私は、パスワードを入力する小さなプログラムを別に用意し、そのプログラムをAIから呼び出すような仕組みも使っています。
つまり、
AIはパスワードそのものを知らないが、ログイン処理は実行できる
という形です。
2ログイン済みのCookie・セッションを再利用する
Webサイトに一度ログインすると、
「この人はログイン済みですよ」
という情報がブラウザに保存されます。
Cookieやセッションと呼ばれるものです。
これを保存しておけば、AIエージェントは毎回パスワードを入力しなくても、ログイン済みの状態から作業を始められます。
Playwrightなどでもよく使われる方法です。
ただし、これは永久には使えません。
Webサイト側が、
- 「一定時間操作が無ければログアウトする」
- 「一定期間経過したセッションは無効にする」
といった仕組みを持っているからです。
楽天RMSの場合も、夜にログインしておけば翌朝も使える、という単純なものではありませんでした。
実際に調べてみると、前日のCookie自体は残っているのに、翌朝になるとRMS側でセッションが失効していました。
そのため一時期は、
- 人間が朝ログインする
- そのセッションをAIエージェントが使う
という運用をしていました。
3普段使っているブラウザのプロファイルをそのまま使う
もう一つが、
人間が普段ログインしているChromeなどのブラウザ環境そのものをAIに操作させる
方法です。
ChromeのプロファイルにはCookieやログイン状態などが保存されています。
そのブラウザをAIから操作すれば、改めてログインしなくても済むことがあります。
2段階認証があるサイトなどでは、この方法が便利なこともあります。
最近では、パスワードマネージャーやOS側に認証情報を持たせて、AI自身にはパスワードを見せない方法もあります。
つまり、
「AIがパスワードを知らない」ことと、「AIがログイン済みサイトを操作できない」ことは別問題
です。
ここはかなり重要です。
楽天以外は自動ログインできた
こうした方法を組み合わせることで、楽天以外の多くのサイトについては、自動ログインして毎日の処理を行えるようになりました。
ところが、楽天RMSだけがどうしてもうまくいきません。
最初はPlaywrightが起動したChromeでログインしようとしましたが、楽天会員ログインの途中で止まってしまいました。
そこで、
- 普通のChromeを起動
- デバッグポートを開く
- そこへAIが外から接続して操作
という方式に変更しました。
これだとある程度までは通ります。
さらに、
- ブラウザ終了時にセッションを正常に保存する
- 前回のセッションをChrome起動時に復元する
- 定期的にRMSへアクセスしてセッションを延命する
という仕組みまで作りました。
一時期はこれで3週間ほどセッションを維持できました。
ただ、それでも、
最初に一度、人間がログインしなければならない
という問題が残りました。
ここがずっと気持ち悪かったのです。
AIは「楽天がBot判定している」と説明していた
Claude Codeに何度も原因を調べてもらいました。
すると頻繁に返ってきた説明が、
「楽天側が自動操作を検知して利用規制している可能性が高い」
というものでした。
実際、画面にも、
「ご利用規制などのため、操作を継続して受け付けることができません」
という表示が出ます。
これを見ると、
「なるほど、楽天がBotを弾いているのか」
と思ってしまいます。
私もかなり長い間そう思っていました。
記録が残っているだけでも、2026年8月13日以降49回ログインを試しています。
成功13回。
失敗36回。
そして失敗36回のうち35回が、システム上は「利用規制」と記録されていました。
ここまでデータがそろうと、ますます、
「楽天はAIによるログインを規制している」
ように見えます。
実は、その前にも大量のバグがあった
ところが8月にログを細かく調べると、それ以前にもかなり問題があることが分かりました。
たとえば、
- 保存済みのIDが入っている入力欄に、さらに同じIDを追記していた。
- 本当はログイン成功しているのに、URL判定を間違えて失敗扱いしていた。
- リダイレクトの途中でURLを見て、「まだログイン画面だ」と判定して処理を終了していた。
- 規制ページが表示される前に監視処理が終わっていたため、正しく規制を検知できていなかった。
こんなバグが次々見つかりました。
特に厄介だったのは、
人間が一度ログインしたセッションを使えば、その後のデータ取得は正常に動いていた
ことです。
- 売上データも取れている。
- アクセス人数も取れている。
- 広告費も取れている。
そのため監視システムは、
「正常」
と言い続けます。
しかし、
データが取れていることと、AI自身がログインできていることは全く別です。
ここも大きな反省点でした。
それでも「Bot規制説」は残った
コード側のバグを修正すると、8月11日に初めて自動ログイン成功の記録が取れました。
ところが、その後も成功したり失敗したりします。
そこで、
「毎正時はBotが多いから怪しまれているのでは」
と考えて9:00を9:37に変えたり、
「午後のログイン試行が夕方のログインまで規制させているのでは」
と考えてログインを試さない時間帯を作ったり、
Power Automate Desktopなら通るのではないか、
Chrome拡張なら通るのではないか、
デバッグポートを使っていること自体が楽天側に検知されているのではないか、
など、いろいろ試しました。
そして最終的には、
「楽天だけは人間が朝1回ログインする」
という例外ルールまで作りました。
敗北宣言に近いです。
「実際の画面を見せて」と言ってみた
ところが9月4日、ふと思いました。
AIはずっとバックグラウンドで操作しています。
私は、
「ログイン失敗しました」
「利用規制です」
というAIからの報告しか見ていません。
実際に何をやって失敗しているのかを、自分の目で一度も見ていなかった。
そこでAIに、
「バックグラウンドでやらずに、RMSログインの動きをモニター上に出して。私が見える状態でやって」
と指示しました。
すると、楽天RMSのログイン画面が目の前に表示されました。
AIがログイン処理を開始します。
IDとパスワードが入力される。
次の画面へ進む。
2段階の認証も通る。
ここまでは問題ありません。
そして、その後です。
楽天から確認画面が表示されました。
ところがAIは、その画面にある「次へ」ボタンを押さずに、
次のページのURLを直接ブラウザへ入力して移動しようとしたのです。
私はそれを見て、
「URLを直接入力せずに、その画面にある『次へ』を押して進んでみて」
と指示しました。
すると先へ進みました。
さらにもう1枚、
「上記を遵守していることを確認の上、RMSを利用します」
という確認画面が表示されます。
そこでもボタンを押しました。
すると、
普通にRMSの管理画面まで到達しました。
Bot規制ではなかった
ここで初めて、長い間の誤診が判明しました。
AIは、
「楽天がBotを検知して自動ログインを規制している」
と考えていました。
ところが実際には、
楽天が用意している確認画面を1枚飛ばして、URLを直接指定して先へ進もうとしていた
のです。
楽天側からすると、
本来通るべき確認画面を通っていない。
その状態でRMSへ直接入ろうとしている。
その結果、
「ご利用規制などのため、操作を継続して受け付けることができません」
というページが返ってきていました。
AIはその文章を見て、
「Bot規制された」
と判断していました。
でも、
「規制画面が出た」ことと、「Bot判定された」ことは同じではありません。
ここを取り違えていたわけです。
人間なら自然にやっていた
なぜ人間ならログインできたのでしょう。
単純です。
確認画面が出てきたら、人間は普通、
「次へ」
を押します。
わざわざURL欄を書き換えて次のページへ移動しようとはしません。
ところが自動化プログラムでは、
「最終的にこのURLへ行きたい」
というゴールを知っているため、
途中のページを飛ばして直接URLへアクセスしてしまうことがあります。
人間にとっては当たり前の動作が、AIには当たり前ではなかった。
そして、
その違いを、バックグラウンドで動かしている限り私は見ることができませんでした。
「AIの回答を鵜呑みにするな」と言っていた本人が鵜呑みにしていた
このサイトの記事でも、
「AIの言うことをそのまま信用してはいけない」
という話を何度も書いてきました。
ところが今回、
私自身が、
「楽天がBot規制しているから仕方ない」
というAIの説明をかなり長期間信じていました。
少し皮肉な話です。
ただ、今回の件で一つ考えが変わりました。
大事なのは、
「AIを疑え」と精神論で言うことではない。
AIが間違っているときに、
人間がそれに気づける仕組みを持つこと
の方が重要なのではないかと思います。
自動化が失敗したら「人間が操作を見る」
今回の件を受けて、自動化のデバッグ方法も変えました。
自動化に失敗が続いた場合、
- ログを見る
- AI自身に原因分析させる
- それでも解決しなければ
- 実際の操作を画面に表示して人間が見る
というステップを入れます。
これだけで、
- AIがどこをクリックしているのか。
- 何を入力しているのか。
- 本当にエラーメッセージの解釈は正しいのか。
- 人間の操作とAIの操作で何が違うのか。
が分かります。
AIに、
「なぜ失敗した?」
と100回聞くより、
1回横で操作を見た方が早い
ことがあります。
今回がまさにそうでした。
もう一つの教訓。「できない」で終わらせない
今回、何度も、
「楽天のBot規制なので難しいです」
「自動ログインは安定しません」
という説明を受けました。
そこで、
「そうか、楽天は無理なのか」
と止めていたら、今も毎朝人間がログインしていたと思います。
自動化では、
できない理由を説明することと、できる方法を探すことは別です。
「この方法ではできない」
のであれば、
- 別のブラウザならどうか。
- 別の操作方法ならどうか。
- セッションを使えばどうか。
- APIならどうか。
- 人間の操作との違いは何か。
- 実際の画面を見たらどうか。
と、方法を変えていく。
AIは非常に便利ですが、
「できません」
という説明も非常に上手です。
しかも、それらしい技術用語を使って説明されると、人間側も納得してしまいます。
だからこそ、
「それは本当にできないのか。それとも、今のやり方ではできないだけなのか」
を分けて考える必要があります。
今回の楽天RMS自動化から学んだこと
今回の約2か月半で、私が一番重要だと思ったのはこの5つです。
- データ取得成功と、ログイン成功を分けて監視する
- AIが付けたエラー原因のラベルを事実だと思わない
- 自動操作と人間操作の違いを比較する
- 失敗が続くならバックグラウンド処理を画面に出す
- 「できない」ではなく「この方法ではできない」と考える
特に2番目です。
今回、
「利用規制」
という表示は確かにありました。
だからAIは嘘をついていたわけではありません。
でも、
「利用規制の画面が出た」
という観測事実と、
「楽天がBotと判定した」
という原因の推測が、いつの間にか同じものとして扱われていました。
AIを使う上では、
事実とAIの推測を分ける
ことが非常に重要です。
AI自動化で大事なのは「AIを信用しないこと」ではない
AIを疑ってばかりでは仕事になりません。
AIにはどんどん仕事を任せればいいと思っています。
ただし、
AIが間違えたときに、人間がそれを発見できる仕組みを作る。
こちらの方がずっと重要です。
今回なら、
- ログを残す。
- 成功条件を細かく分ける。
- 操作画面を人間が確認できるようにする。
- AIの推測と観測事実を分けて記録する。
こうした仕組みです。
AIエージェントによる自動化が増えれば増えるほど、
「AIに任せる技術」だけではなく、
「AIの間違いを発見する技術」
も重要になってくる。
楽天RMSのログイン問題は、それをかなり分かりやすく教えてくれた事例でした。
この記事は、いまのあなたに合っていましたか
ボタンについては、お名前を取っていません。同じ方が二重に数えられないようにするためだけに記録が残ります。