Case Study · 貿易

画面操作のRPAを、API連携と判定ツールに作り直す

Amazon輸入販売で、画面操作のRPAに頼っていた商品確認を作り直した。売れている商品から販売できない候補を洗い出す判定ツールと、Amazon公式APIとの連携。AIは候補の下書きまで、取り下げなどの実操作は人が決める。

講義用のデモではありません。米国で仕入れ、日本のAmazonで販売する輸入販売の部門で、画面操作のロボット（RPA）に頼っていた確認作業を作り直した事例です。RPAの動きをそのまま再現するのではなく、「何を判定し、どこで人が決めるか」という業務の要件だけを引き継ぎました。画面の画像は架空の商品データで作成しています。

課題

輸入販売では、出品している商品の中から「日本へ輸入して売ってはいけない商品」を定期的に見つけ、取り下げる必要があります。銃関連、ガラスなどの割れ物、液体、重すぎる商品などです。出品数が多いため、人がすべてを確認するのは現実的ではありません。一方で、判定を誤って売ってはいけない商品を残すことも、売れる商品を誤って消すことも避けなければなりません。

従来

判定や各種データの取得は、画面を操作するRPAで回していました。棚卸しすると、支援の記録が残るロボットだけで19本あります。画面の変更で動かなくなる、途中から再開しにくい、止まっても気づきにくい、複数の出品アカウントのデータが混ざる危険がある、といった問題を抱えていました。作り込んでも、安定して回る状態にはなりませんでした。

用語の解説

RPAとは？画面を操作する「ソフトのロボット」

RPAは「Robotic Process Automation（ロボティック・プロセス・オートメーション）」の略です。人がパソコンで行っているクリック・文字の入力・コピー＆貼り付けといった操作を、ソフトウェアのロボットが画面の上でそのまま真似して代わりに行います。たとえるなら「決められた手順どおりに、画面を見ながら操作してくれるアルバイト」です。

図解：同じ作業を3つのやり方で比べる

例：「商品の情報を確認して、一覧表に書き写す」作業

手作業

人が画面を操作する

人
目で見て判断
画面を操作
クリック・入力・コピー
システム
販売管理画面など

確実ですが、件数が増えるほど時間がかかり、転記ミスも起きます。

RPA

ロボットが人の代わりに画面を操作する

ロボット
決めた手順を再生
画面を操作
ボタンの位置や見た目で判断
システム
販売管理画面など

人の操作を自動で繰り返せます。ただし、ロボットが頼りにしているのは「画面の見た目」です。ボタンの位置やデザインが変わると、どこを押せばよいか分からなくなって止まります。

API連携

システム同士が専用の窓口でデータを受け渡す

プログラム
必要なデータを依頼
API（専用の窓口）
決められた形式で受け渡し
システム
データを直接返す

画面を通らず、データだけを受け取ります。画面のデザインが変わっても影響を受けにくいのが特長です。ただし、提供側がAPIを用意していること、利用の審査・権限があることが前提です。

RPAが得意なこと

・毎回同じ手順の繰り返し（転記、ダウンロード、定型入力）
・APIが用意されていないシステムでも自動化できる
・今使っているシステムを変えずに導入できる

RPAが苦手なこと

・画面の変更に弱い（ボタンの位置・文言・デザインが変わると止まる）
・途中で止まると、どこから再開すればよいか分かりにくい
・止まっても気づきにくい。夜間の自動実行では特に
・「売ってよい商品か」のような判断そのものは苦手

この事例で起きていたこと

輸入販売の部門では、データの取得や切り替え、商品の判定まで、多くの作業をRPAで回していました。判定では、AIのチャット画面をロボットに操作させて答えを受け取る、という作りまでありました。画面の変化で止まる、途中から再開しにくいといった弱点がそのまま出て、作り込んでも安定しませんでした。そこで、手元のデータで判定できる部分は判定ツールに、商品ページの事実が必要な部分はAPI連携に、最後の判断は人に、と役割を分け直しました。

使い分けの目安
こんなとき	向いている方法
相手のシステムに画面しかなく、手順が毎回同じ	RPA
相手が公式のAPIを用意していて、利用が認められている	API連携
手元にあるCSVやExcelのデータで判断できる	判定ツール（自作アプリ）
取り返しのつかない操作（削除・価格変更など）	人が確認して決める

どう変えたか

まずRPAを棚卸しし、画面操作ではなく業務の要件を書き出しました。そのうえで、判定を2層に分けています。1層目は、販売データ（ビジネスレポート）に含まれる商品名から、禁止キーワードで販売不可の候補を洗い出す判定ツールです。2層目は、Amazonの公式API（SP-API）と連携し、米国の商品ページの有無、在庫、重量や寸法といった事実を取得して判定する仕組みです。コードは自分では書かず、判定条件と人が決める範囲を先に決め、実装はAIに指示して進めました。

成果

判定ツールは、Python版で作った判定ロジックをWebアプリへ移し、同じ実データで両者の判定が一致することを確かめています。実データでは、おすすめ出品の獲得率が0%の商品（売れる見込みが極めて低い商品）を除くだけで、確認対象を約16,000件から約2,000件まで絞り込めました。2層目のAPI連携も、実データで米国の商品情報を取得できることを確認しています。出品の取り下げや価格の変更は、AIもツールも一切行いません。AIが作るのは確認リストの下書きまでで、最後は人が見て決めます。

仕組み

判定を任せきらないための仕組み

判定は2層に分ける

1層目は、手元の販売データだけで判定できる「商品名に禁止キーワードが含まれるか」。2層目は、実際の商品ページを見ないと分からない「在庫があるか」「重さ・大きさは基準内か」。データの取り方が違うものを分けておくと、片方が止まってももう片方は使えます。

API連携とは

ソフトウェア同士が、決められた窓口を通じてデータをやり取りする仕組みです。ここではAmazonが出品者向けに用意している公式の窓口（SP-API）を使い、画面を操作せずに商品情報を受け取ります。画面のデザインが変わっても壊れにくいのが、RPAとの大きな違いです。ただし、使えるかどうかは提供側の審査や権限、方針に左右されます。

誤検知を減らす工夫

禁止キーワードは約100語。単純な文字の一致だと「oil」が「coil」に反応するため、英単語は単語の区切りで判定します。「heat gun（熱風を出す工具）」のように、禁止語を含んでも問題ない言い回しは除外リストで外します。

迷うものは人に回す

判定結果はOK・NG・要確認の3つです。電気用品や電波の規制に関わりそうなもの、刃物のように用途で判断が分かれるものは「要確認」として人に回します。情報が足りないときも、推測で埋めません。

アカウントを混ぜない

出品アカウントは複数あります。画面では常に1つのアカウントを選んで処理し、商品や売上が混ざらないようにしています。

データを外に出さない

判定ツールは、読み込んだ販売データをブラウザの中だけで処理し、外部のサーバーへ送りません。結果はExcelとCSVで書き出し、確認後の判断もそのまま残せます。

画面

判定ツールの画面（架空の商品データ）

削除候補（NG）の一覧と判定理由（架空の商品データ） — 削除候補（NG）
ガラス、陶器、塗料、オイル、エアガン関連など、禁止キーワードに当たった商品です。右端に判定理由を出し、人が理由を見て確認できるようにしています。

要確認の一覧（架空の商品データ） — 人間確認（要確認）
無線機器、刃物、バッテリーなど、機械的に決めきれない商品は人に回します。確認結果は画面で上書きでき、そのままExcelに書き出せます。

学べること

この事例から持ち帰れること

RPAを作り直すときは、画面操作を再現しないことです。何を判定し、どこで人が決めるかという要件だけを引き継ぐと、壊れにくい仕組みになります。
AIに任せるのは候補の下書きまで。取り下げや価格の変更のように取り返しがつかない操作は、人の承認を前提に設計します。
外部のAPIは、提供側の審査・権限・方針で使えなくなることがあります。手元のデータだけで回る部分と、APIが必要な部分を分けておくと、事業は止まりません。
判定条件を言葉にできれば、コードを書かなくても仕組みは作れます。判定の基準を決めるのは、業務を知っている経営者です。

同じ型が使われている事例

手作業の塾運営を、現場が回せる基幹に

詳しく見る →

知識・運営

現場の知見を、フォルダに残して回す