W EC AI WorksECの仕事を、AIで減らす。

読み物

楽天RMSとAIエージェントを
どうつなぐか

APIのつなぎ方はAIに任せていい。データは自社に貯める。守るのも自社。そして、決まった集計はプログラムにさせ、人間も見られる画面を作る。

楽天店舗をAIで自動化するとき、私たちが実際に試してきて、今いちばんおすすめしている構成です。

楽天RMSとAIをどう接続するのか、どのAPIを使うのか、外部AIにデータを渡していいのか、RMSをブラウザ操作していいのか。

よく聞かれる5つの質問に、実際に楽天店舗をAIエージェント化してきた経験から答えます。

1RMS WEB SERVICEとAIを、実際につないで運用している人はいる?

はい、うちで運用しています。構成はこうです。

楽天RMS(RMS WEB SERVICE)受注・商品・在庫のAPI
↓
自社サーバーのプログラム毎日決まった時間に取りに行く
↓
自社のデータベース(MySQL)購入者の情報も含めて貯めていく
↓
集計プログラムと管理画面人が見ても分かる形にする
↓
AIエージェント集計を読んで判断し、担当へ振り分けて報告

まず知っておいてほしいのは、APIのつなぎ方そのものは、AIエージェントに全部任せてしまっていいということです。

「楽天のAPIでつないで、受注データを取ってきて」

Claude Codeのようなエージェントにこう頼めば、APIの仕様を読み、認証の仕組みを組み、取得のプログラムまで書いてくれます。人がやるのは、RMSの管理画面でAPIの利用を申し込み、キーを発行するところくらいです。

ひとつだけ実務の注意を。RMSのAPIキーには有効期限があり、更新は管理画面での操作になります。 期限が切れた日に、自動の取得が黙って止まります。期限を見張って前もって知らせる仕組みも、最初にAIに一緒に作らせておくと安心です。

そのうえで、取ってきたデータの置き場所です。

AIに毎回APIを叩かせて、その場で分析させることもできます。ただ、うちでは取ったデータをいったん自社のデータベースに入れて、そこを分析する形にしています。

  • 過去のデータが手元に残る(APIで遡れる期間には限りがあります)
  • 分析のたびに楽天へ取りに行かなくて済む
  • 同じデータを、あとから何度でも別の切り口で集計し直せる
  • 楽天以外のモールや広告のデータとも並べて見られる

そのためのサーバーとデータベースの組み方は、こちらに書いています。

2売上・注文数・商品・価格・在庫は、どのAPIを使えばいい?

参考までに、うちで使っているものを書いておきます。

  • 日別売上・注文件数・商品別売上 … 受注API(受注データを取ってきて、自社側で日別・商品別に集計する)
  • 商品情報・価格 … 商品API
  • 在庫数 … 在庫API

なお、アクセス数や広告の数字には公式のAPIがありません。ここはCSVで取り込んでいます。

ただ、正直に言うと、この段階で「どのAPIを使うか」を人が決めておく必要はありません。

最初からAIに全部を指示しなくても大丈夫です。取れたデータを見ながらAIとやりとりを重ねていくと、

「在庫も一緒に見たい」
「商品ごとの価格の変化も知りたい」

と必要なものが出てきます。そのとき、AIのほうで新しいAPIをつなぎ、足りないデータを取ってきてくれます。

どのAPIを使うかは、AIに完全に任せてOKです。人が決めるのは「何を知りたいか」のほうです。

3APIのデータを外部のAIで処理するとき、規約やセキュリティで注意していることは?

購入者の氏名・住所・電話番号はAIに渡さない。この前提はとても大事です。

ただし、「AIに渡さない」は「集計に使わない」という意味ではありません。

住所をはじめとする購入者の情報は、実はとても重要なデータです。

  • 同じお客様が、何度買ってくれているか(リピート)
  • 1人のお客様が、長いお付き合いの中でどれだけ買ってくれるか(LTV=顧客生涯価値)
  • どの地域から、どんな注文が多いか(エリア集計)

どれも分析の価値が高く、店の次の打ち手に直結します。捨ててしまうのは、もったいないどころではありません。

だから、うちではこうしたデータも自社のデータベースに貯めています。集計は自社のプログラムが行い、AIには個人が分からない形にした結果(何回目の購入か、都道府県ごとの売上など)を分析させる形です。

生のデータは自社に貯める。
AIが分析するのは、集計した結果。

自社のサーバー 自社のデータベース(生のデータ) 購入者の氏名・住所・電話番号も貯める 集計は自社のプログラムが行う リピート・LTV・エリア集計 氏名・住所・電話番号はAIに渡さない 個人が分からない形にした結果 何回目の購入か、都道府県ごとの売上など AIが分析する
「AIに渡さない」は「集計に使わない」という意味ではない。生のデータは自社に貯め、AIが分析するのは集計した結果。

そうなると、ここで気をつけるのは楽天に対してというより、自社のデータベースを置いた自社のサーバーに対してです。

大事な顧客データが全部そこに集まり、そのサーバーにAIが出入りして作業をします。だからこそ、自社データベースのセキュリティ対策は本当に大事です。

  • 購入者の氏名・住所・電話番号は、入れる表を分けて、読める人とプログラムを絞る(AIには集計した結果だけを見せる)
  • APIのキーやパスワードは、プログラムの本文や公開フォルダに書かず、外から読めない場所に置く
  • データベースは外部から直接つなげないようにし、必要な権限だけを持つユーザーで使う
  • サーバーに入れる経路(管理画面・SSHなど)を絞り、使っていない入口は閉じる
  • AIに「消す・書き換える」ができる範囲を先に決めて、そこに手が届かないようにしておく
  • バックアップを取り、戻せることを確かめておく

このあたりは、関連する記事にまとめています。

4ログイン済みのRMSを、AIのブラウザ操作で動かしてもいい?

うちも、APIでは取れない数字を取るために、画面を自動で操作していた時期があります。そこで起きたことは、こちらに全部書きました。

そのうえでの、私の見解です。

楽天は、AIエージェントやプログラムにRMSの画面を操作させることを、あまり良く思っていない節があると感じています。

規約上、いまの時点で規制されたり止められたりしたことは確認していません。ただ、今後どうなるかは分かりません。

一方で、APIは楽天が用意している正規の入口です。API自体が規制されることはまず無いと考えているので、APIで自由にデータを取ることは大丈夫だと思います。

いちばん問題になりやすいのは、AIエージェントによる画面操作です。

実際に、AIによる画面操作を禁じるサービスも出てきています。画面操作に頼った仕組みは、ある日ルールが変わったら丸ごと使えなくなるかもしれません。

「楽天ECCに正式に確認してから進めたい」という声もよく聞きます。これも私の見解ですが、AIの画面操作について、わざわざ楽天に相談はしないほうがいいと思っています。API中心で組んでおけば、そもそも相談が要る場面はほとんど無くなります。

5RMSとAIエージェントを、どんな構成でつないでいる?

構成は1番の図のとおりです。その中で、いちばんおすすめしたいのがここです。

データを貯めたら、それを集計するプログラムを作る。
人間が見ても分かる、Webで確認できる画面にする。

これは、うちでも実際にやっていることです。

AIに毎回ゼロから集計させると、遅く、費用がかかり、結果もぶれます。決まった集計はプログラムにさせ、AIにはその結果を読んで「どこがおかしいか」「次に何をするか」を判断させる。人間は、同じ画面を見てAIの判断を確かめる。

こうしておくと、画面操作に頼らずに済み、AIが何を見て判断したのかも人が後から確かめられます。「異常を見つけて、必要な作業を担当のAIへ振り分ける」ところまで進めても、中身が見えなくなりません。

集計するプログラム 決まった集計はプログラムにさせる Webで確認できる画面 AI その結果を読んで 判断する 人間 同じ画面を見て AIの判断を確かめる
集計はプログラムに、判断はAIに、確認は人が見て分かる画面で。AIが何を見て判断したのかを、人が後から確かめられる。

まとめ

  • APIのつなぎ方は、AIエージェントに任せていい
  • どのAPIを使うかも、最初は決めなくていい。必要になればAIがつないで取ってくる
  • 取ったデータは自社のデータベースに貯めて分析する
  • 購入者の情報もリピート・LTV・エリア集計に使う。AIに渡すのは集計した結果
  • 守るべきなのは、楽天より自社のサーバー
  • 画面操作はいちばんのリスク。APIを中心に組む
  • 集計はプログラムに、判断はAIに、確認は人が見て分かる画面で

なぜ「VPS+MySQL+PHP+AI」の構成をすすめるのか コンテンツ一覧へ

この記事は、いまのあなたに合っていましたか

ボタンについては、お名前を取っていません。同じ方が二重に数えられないようにするためだけに記録が残ります。

この記事について質問・感想を送る

いただいた内容は、確認したうえで記事の下に載せることがあります。お名前は取っていません。