【2026年版】楽天の管理画面は言葉で動く｜EC運営者のAPI自動化20選

私の店は楽天市場に出店しています。雑貨と日用品を扱う、社員数人の小さなネットショップです。

商品の編集は、RMS（楽天の出店者向け管理画面）からほとんど離れました。開く回数も、はっきり減っています。

今朝も、商品データは自動で手元へ落ちてきました。キャッチコピーは全商品ぶん書き換わっています。昨夜売り切れた商品は、連携している販売先で止まりました。

そのあいだに私がやったのは、日本語で3回ほど話しかけただけです。

「昨日から値段が下がったままの商品はある？」

「この10商品の説明文に、去年の日付が残ってないか見て」

「明日の朝いちで、在庫が切れそうなものを教えて」

これができるようになったのは、楽天API（外部のプログラムから楽天の店舗を操作するための窓口）とAIツールをつないだからです。

この記事では、私の店がAPIとAIでやっている20のことを書きます。全部が毎日自動で動いているわけではありません。手作業が残っているものも、まだ着手できていないものも、そのまま書きます。そのあとで、できないことと、あえてやらないと決めたことも書きます。

📌 この記事でわかること

• 「日本語で話しかけると店が動く」とは、具体的にどういうことか

• 楽天APIとAIをつなぐと自動化できること20選（読む・書く・つなぐ・判断する）

• 実際にAIへ投げている依頼文（そのまま使えます）

• 始める前に確認しておくこと5つ（申し込み・動かす場所・費用・カギの扱い・試し方）

• APIが「そもそも無い」領域と、制約でつまずく罠

• 技術的にはできるのに、やらないと決めた6つ

• 明日やる3つと、そのあとの順番

1️⃣ 何が変わったのか｜日本語が、そのまま操作になる

変わったのは作業の速さではありません。事実を見に行く回数です。

以前のやり方

管理画面を開く。ログインする。商品管理の画面へ行く。検索する。絞り込む。CSV（表計算ソフトで開けるデータ形式）に落とす。Excelで開く。

ここまでで15〜20分かかります。

すると人は、確信があるときしか調べません。「たぶん大丈夫だろう」で済ませます。

その「たぶん」が積もったところに、事故が起きます。

今のやり方

「この商品、いま何個ある？」

30秒で返ってきます。

聞くのが30秒になると、確信がなくても聞きます。判断の前に事実を見る回数が、桁で変わりました。

仕組みそのものは単純です

AIツールに「私の店のAPIを呼ぶ道具」を持たせておくだけです。あとは日本語で頼みます。

仕様を最初から読み込んでおく必要はありません。やりたいことを日本語で言えば、足りない情報はAIのほうから聞いてくることが多いです。

⚠️ ただし、書き込みに入る前だけは別です。書き込みの単位・必須の項目・呼び出しの上限は、人が公式の仕様で確かめてください。理由は第10章に書きます。

エンジニアでなくてもいいのか

ここは慎重に書きます。

私はプログラムを書けません。エラーが出たら、その文面をそのままAIに渡して直してもらっています。それで動いています。

ただし「誰でもすぐできる」とは書きません。

止まったときに自分で切り分けられないと、動かなくなった日にお手上げになります。書けなくてもいいですが、読めるようにはなったほうがいい。私はそう思っています。

💻 コードを書かない人はここまでできる

管理画面から出したCSVをAIのチャット画面に貼れば、比較や異常の検出まではできます。ただし数千商品ぶんをそのまま貼ると入りきりません。列を絞る、上位数百行に切る。この一手間で通ります。

2️⃣ 前提｜楽天のAPIは2種類ある

混同すると、あとの話が全部ずれます。分かれ目は、見える範囲です。

🔵 誰でも使える「公開のAPI」

楽天市場に公開されている商品情報・ランキングなどが取れます。出店していなくても使えます。仕様書も一般公開されています。

もともとは、アフィリエイトのサイトやアプリを作る人に向けた窓口です。公開されている情報を、公開されている場所で見せるためのもの、という位置づけです。

🔵 出店者だけが使える「店舗向けのAPI」

自分の店の商品・在庫・受注・画像・ページが読み書きできます。この記事で「20選」として書くのは、こちらです。仕様書は管理画面にログインした先にあり、ログインしないと読めません。

よくある勘違いを1つ。「公開のAPIで自分の店の受注が取れるのでは」——取れません。公開のAPIは公開情報しか返しません。

💡 覚え方：公開のAPIは「店の外から見える景色」。店舗向けのAPIは「自分の店の中」。窓が別なので、片方から反対側は見えません。

⚠️ 規約も別々です。窓が違うので、守るべきことも違います。使う前に、それぞれの規約を確認してください。

3️⃣ 始める前に、確認しておくこと5つ

始める前に決めることが5つあります。うち1つは、あとから戻せません。

◆ ① 楽天側の利用申し込みが要る

店舗向けのAPIは、出店していれば自動で使えるわけではありません。管理画面から申し込みと、アプリの登録という2段の手続きがあります。申し込んでから使えるようになるまでに時間がかかることもあるので、思い立った日には始められません。

◆ ② パソコンが起きている必要がある

手元のパソコンで動かす構成なら、決まった時刻にそのパソコンが起きている必要があります。常時動かしたいなら、サーバーなど別の環境に置く選択肢もあります。

私も最初、これに気づかずに「朝になっても動いていない」を繰り返しました。

◆ ③ 費用は、思っていたより楽天側にかからない

店舗向けのAPIそのものは、無料で使えます。ここは私も最初、有料だと思い込んでいました。

ただし例外があります。商品を扱うAPIを使うには、商品の一括登録サービスの申し込みが別途必要です。こちらは有料のオプションになります。

実際にかかるのは、主にAIツールの月額のほうです。個人で使う範囲なら月に数千円から、本格的に回すなら数万円というのが2026年8月時点の相場感です。

◆ ④ 認証情報の扱いだけ、先に決めておく

これは費用や環境より先です。APIのカギ（認証情報）を、チャットに貼らないでください。置き場所だけ伝えて、中身はAIに読ませません。

※「チャットに貼らなければ安全」ではありません。ファイルを読めるAIツールなら、置き場所を教えた時点で読めます。AIから読めない場所に置いてください。

頼めば「カギを教えて」と聞かれます。そこで貼らないことが、最初の関門です。

⚠️ もし貼ってしまったら、消して終わりにしないでください。そのカギを失効させて、作り直します。貼った時点で、どこかに残っていると考えたほうが安全です。

そしてもう1つ、誰が使えるかも先に決めます。店舗向けのAPIは、店の中身を丸ごと読み書きできます。カギを持っている人が、そのまま全権限を持ちます。

私の店では、使えるのは店舗の運営に責任を持つ立場の人だけにしています。そしていつ誰が何を動かしたかのログを残しています。扱いを個人の裁量に委ねないこと、あとから追えること。この2つが条件です。

⚠️ ログは、事故の後に効きます。「誰かが間違えた」ではなく「いつ何が起きたか」から入れると、原因の切り分けが速い。残していないと、この入り口自体がありません。

◆ ⑤ 本番の前に、必ず試す

これは残り4つの全部に掛かります。いきなり本番のデータで動かさないでください。

読むだけの処理でも、まず1件だけ取って中身を見ます。書き込みなら、テスト用に作った非公開の商品で一度通してから、少数で試して、そのあと全件へ広げます。

試した結果を自分の目で見て、問題がないと確認してから本番運用に入る。この順番だけは省かないでください。

⚠️ この試し方が使えるのは、商品まわりだけです。カテゴリの並べ替え、店舗の設定、受注に関わる操作は、非公開の商品では試せません。本番でしか試せないものは、自動化を後回しにしてください。

⚠️ とくに書き込みは、試さずに出すと戻せません。「たぶん動くはず」で全商品に流して、気づいたときには全件が書き換わっている。自動化でいちばん多い事故がこれです。

そして、いちばん先に決めるのは「やらないこと」です

作り始める前に、頭に入れておいてほしい地図があります。この記事の残り全部が、この3層のどこかに入ります。

🔵 第1層：APIが無い（第9章）

🔵 第2層：制約がある（第10章）

🔵 第3層：やらないと決めた（第11章）

多くの人は第1層だけ調べて始めます。そして第3層を決めないまま進んで、事故ります。

順番は逆です。決めるのは第3層から。先に読みたい方は、第11章へ飛んでも構いません。

4️⃣ 【楽天API自動化20選①】管理画面を開かずに読む・調べる6つ

ここから本題です。私の店で実際にできるようになったことを、20個挙げます。

各項目は「頼む言葉 → 起きること → 効き目」の形で書きます。人が頼まなくても動くものだけ、「頼む言葉」が「きっかけ」になります。

いくつかには「測り方」も添えました。効果の実数は営業秘密なので出せません。

数字を出せないぶん、代わりに「ご自分の店で測れる形の指標」を置きました。6項目に付いています。私の店の数字より、あなたの店の数字のほうが役に立ちます。規模も客層も違うので、他店の実数はそのまま当てはまりません。

全部には付いていません。自分でまだ測れていないものには、付けていません。

① 全商品を、まるごと手元に落とす

頼む言葉：「私の店の全商品を毎日1回取ってきて、手元に保存して」

起きること：商品情報・店舗内カテゴリ・在庫数が全件、決まった時刻に自動で保存されます。私の店は1か月分ためています。

効き目：管理画面を開かなくても、その場で質問に答えられるようになります。ここが土台で、以降の項目はほぼ全部これに乗っています。

② 全商品をExcelで出す

頼む言葉：「全商品を取ってきて、フィルター付きのExcelにして」

起きること：数百点規模なら数分で、項目を並べた表ができます。列の絞り込みや並べ替えも、頼めばその場でやってくれます。

効き目：必要な列だけを選んで出せます。管理画面のCSVは項目が固定なので、社内で回すときも取引先に渡すときも、そのままでは使えないことが多い。「この5列だけ、在庫が10未満のものだけ」と頼めば、その形で出てきます。

③ 昨日との差分を出す

頼む言葉：「昨日と今日を比べて、価格が変わった商品・在庫が減った商品・説明文が変わった商品を出して。変わっていないものは出さなくていい」

起きること：3つの一覧が返ってきます。

効き目：管理画面には「昨日の状態」がありません。上書きすると前の値は見えなくなります。差分は、自分で毎日ためていないと永久に出せません。

④ 品切れ予定日を毎朝出す

頼む言葉：「在庫の減り方から、何日後に0になるか出して。補充にかかる日数を切るものだけ教えて」

起きること：毎朝、危ない商品だけが一覧で届きます。

効き目：管理画面が出すのは「今の在庫数」です。減り方は時系列がないと出ません。売れている商品ほど早く消えるので、いちばん売れている最中に切れます。

測り方：品切れによる販売停止日数の合計

※これは在庫の減り方からの簡易推定です。入荷や返品でも在庫は動くので、補充のあった期間は外して見てください。

⑤ 戻し忘れた値下げを検知する

頼む言葉：「昨日から価格が下がったまま戻っていない商品を、毎朝出して」

起きること：値下げ状態のまま戻っていない候補が、翌朝に出ます。

※2日ぶんの比較だけでは、意図した恒久値下げとの区別がつきません。セールの終了日を別に持っておくと、「終わったのに戻っていない」だけを出せます。

効き目：セール価格のまま戻っていない商品は、原価を割っていれば売れるほど損が増えます。気づくのが月末の粗利集計では遅すぎます。

測り方：戻し忘れの検出件数と、その商品の販売数

⚠️ 値引きの「見せ方」には別のルールがあります。「もとの価格」として何を表示してよいかには要件があります。いくらで売るかの判断と、価格の表示方法は別の話なので、混ぜないでください。

⑥ 動かなくなった在庫を洗い出す

頼む言葉：「30日間、在庫が1つも減っていない商品を出して。在庫数と一緒に」

起きること：止まっている商品が一覧になります。

効き目：在庫は、減ってはじめて「売れた」と分かります。管理画面が出すのは「今いくつあるか」だけで、「いつから動いていないか」は蓄積がないと出せません。

売れているものは放っておいても目に入ります。止まっているものは、探しにいかないと一生見えません。値下げ・入れ替え・写真の撮り直し。判断はどれもこの一覧から始まります。

測り方：止まっている商品の点数と、その在庫金額

※補充と販売が相殺されると、売れている商品が「動いていない」に見えます。販売実績が取れるなら、そちらを基準にしてください。

💻 コードを書かない人はここまでできる

③と⑤は、CSVでも半分できます。管理画面から商品データを2日ぶん落として、AIに「この2つを比べて、変わった行だけ出して」と頼むだけ。検出だけなら、今日から始められます。

5️⃣ 【楽天API自動化20選②】管理画面を開かずに書く・直す｜8つ

ここから書き込みです。事故のリスクが一段上がります。

⑦ 商品ページを非公開のまま複製する

頼む言葉：「この商品をコピーして、色違いの新品番を作って。非公開のままで」

起きること：新しい品番のページが、非公開の状態で用意されます。そのあと、元のページとの差分が機械的に出ます。「本来変わるべきなのに変わっていない箇所」がここで見つかります。

効き目：手でコピーすると置き換え漏れが出ます。「色だけ変えたつもりが、説明文に前の色名が残っている」というやつです。公開ボタンは、人が押します。

⑧ キャッチコピーを毎日書き換える

きっかけ：毎日、決まった時刻に自動で動きます

起きること：全商品のキャッチコピーが、毎日1回、自動で書き換わります。中身は「検索されやすい言葉」＋「その時点で実際に買える種類の一覧」です。

効き目：昨日まで5種類あった商品が、今日は3種類かもしれません。5種類と書いたままだと、お客様は「あると思って来たのに無い」となります。毎日更新すれば、売り切れた種類は翌日には消えます。この事故が起きる余地が、構造的にかなり小さくなります。

文字数の上限があるので、そこは機械で検証しています。失敗したら私にメールが飛びます。

⑨ 説明文の禁止語を、全商品から検出して直す

頼む言葉：「このリストの言葉が入っている商品を全部出して。承認したら一括で直して」

リストの中身は、その店が踏んだ失敗の記録です。「以前この言い方で問い合わせが増えた」「この販売先ではこの語が弾かれた」。汎用の校正機能には入っていません。

起きること：全商品を横断して違反箇所が出ます。修正は承認を経て一括で当てます。

※出口のガードが掛かっているのは、いまのところ一部の販売先だけです。全部の生成経路に通すのが目標で、まだ途中です。

効き目：ここは大事な話です。生成の仕組みにガードを入れても、すでに公開しているものは直りません。

私の店でも、ルールを決める前に作ったページに古い表現が残っていました。数え直したら、想像していた桁より1つ多かったです。3日かかりました。直す件数より、数える工程のほうが長かった。

検出と修正を、同じ作業にしないでください。まず数えるだけ、が正解です。

⑩ 終わった時期の表記を、見つけて外す

頼む言葉：「本文と商品名から、時期を過ぎた季節の言葉を全部見つけて」

起きること：期限切れの催事表記が一覧になります。承認したら、まとめて外します。

効き目：終わった催事の表記が残っていると、在庫や納期の情報も同じように古いのではないかと受け取られかねません。個別に直すのは管理画面でもできますが、「全商品を毎月」が人力では抜けます。

測り方：期限切れ表記の検出件数

⑪ 記事ページを作って入稿する

頼む言葉：「この構成で特集ページを作って、画像も配置して」

起きること：構成・本文・画像を作り、ページとして入稿するところまで通ります。

効き目：記事は書いて終わりではなく、あとから直せることのほうが効きます。ここで大事にしていることが3つあります。

◆ 全ページを毎日バックアップする。事故があったら戻せます。ただし戻せるのはページの中身までで、公開されて外に伝わったものは戻りません。取るだけでなく、戻せるかを一度試しておいてください。

◆ 実際に公開されているページを「正」とする。手元の下書きは公開ページの写しではありません。実際にやらかしました。下書きを検索して「この3ページだけ直せばいい」と判断したら、公開ページの対象は倍以上ありました。

◆ 表記の一括修正ができる。全ページ横断で古い表記を一気に直せます。

⑫ 画像を配置して、3点照合する

頼む言葉：「この画像をアップして、ページに配置して。そのあと3つが一致しているか確認して」

起きること：手元の原本／楽天の画像置き場／実際にページに表示されているもの、この3つが照合されます。

効き目：「アップロードしたつもりが、古い画像のままだった」は本当によく起きます。

なお、この照合は単純な一致では通りません。保存し直すと中身が変わるので、見た目の近さで比べる仕組みが要ります。ここで一度つまずきました。

⑬ 季節のカテゴリを、まとめて入れ替える

頼む言葉：「夏のカテゴリにある商品を、全部この秋冬のカテゴリへ移して。元の構成を先に保存してから」

起きること：カテゴリそのものの作成や並べ替えと、商品とカテゴリの紐づけの付け替えが、まとめて走ります。

効き目：季節が変わるたび、数百商品の付け替えが発生します。手でやると数日かかり、必ず取りこぼす。0件になったカテゴリへ送客するのは、空の棚に案内するのと同じです。

⚠️ 元の構成を先に保存してから実行してください。カテゴリは店内の回遊の骨格なので、戻せないと痛い。保存が無ければ実行しない作りにするのが安全です。

※私の店はまだ手作業です。次に仕組みにするならここだと思っています。

⑭ 納期に関わる日数を、期間指定で書き換える

頼む言葉：「連休中の出荷にかかる日数を、この期間だけ全商品で伸ばして」

起きること：商品ごとの出荷までの日数と、配送にかかる日数を、まとめて書き換えられます。

効き目：連休前の納期表示の直しは、毎年の重荷です。しかも直し漏れると「間に合うと思ったのに」というクレームになる。発送に関わる表示は1か所ではないので、数えて直す仕組みが要ります。

※これも私が「読めるけれど書けない」と思い込んでいた側でした（第9章）。連休前の直しは、いまも手でやっています。

💻 コードを書かない人はここまでできる

書き込み系は、いきなりAPIに行かないほうがいいです。まずは管理画面の商品一括編集CSVで、AIに作らせた文章を貼り付ける形から。

⚠️ CSVでも本番のデータは変わります。「戻せる」のは更新前のCSVを取ってある場合だけです。先に落として保存し、少数で試してから広げてください。

6️⃣ 【楽天API自動化20選③】販売先をつなぐ｜2つ

複数の販売先に出している店なら、ここがいちばん効くかもしれません。

⑮ 売り切れを、他の販売先へ短時間で伝える

きっかけ：売り切れの知らせが届いた時点で動きます（30分おきに受信箱を見ています）

※30分おきなので、その間は反映されません。売り切れてから止まるまでのあいだに売れてしまう可能性は、ゼロにはできていません。

起きること：該当商品の在庫が、他の販売先で0になります。ただし、全部が自動ではありません。自動で止まるのは2つの販売先だけで、残りは通知が飛ぶだけ、あるいは私が手で0にしています。在庫の粒度が販売先ごとに違うので、同じ形にできませんでした。

効き目：在庫は共通です。倉庫は1つですから。楽天で最後の1点が売れたら、他でも売ってはいけません。人が手で反映していたら、夜中に売れたぶんは翌朝までそのままです。

この仕組みを入れてから、在庫起因のキャンセルは減りました。ただしこれは私の店の体感であって、数字を公開できる形では取っていません。

⚠️ 先に書いておきます

在庫連動は、専用の一元管理サービス（複数の販売先の在庫や受注をまとめて扱う既製のサービス）を契約するほうが早いです。自作するのは、既製で要件が満たせないと分かってからで十分です。この記事は自作を勧める記事ではありません。

⑯ 販売先をまたいだ商品の名寄せ台帳を持つ

頼む言葉：「この対応表をもとに、全販売先の同じ商品を突き合わせて」

起きること：バラバラな商品コードが名寄せ（別々の呼び名を同じものとして1つにまとめること）され、1枚の表に束ねられます。以後の横断処理は全部そこを通ります。

効き目：同じ商品が販売先ごとに違うコード・違う粒度で登録されています。この対応関係は、店が過去に積んだ登録作業の履歴そのもので、どこにも書かれていません。外から機械的に名寄せすると取り違えます。

まずは販売数の多い上位50商品だけ、手で対応表を作る。ここが全横断処理の土台になります。

これがあると、次の2つが乗ります。

◆ 表現の出し分け——ある販売先で使える言葉が、別の販売先では弾かれることがあります。原稿1本から、それぞれの版を出せます。

◆ 表記の食い違いの点検——納期や返品条件が「片方だけ古い」状態を洗い出せます。両方を並べて初めて分かることです。

どちらも同じ商品だと分かっていないと成立しません。だから台帳が先です。

※私の店は上位商品だけです。全商品ぶんは手作業の途中で、出し分けも点検も都度お願いしている段階です。

⚠️ 在庫の出し方を販売先ごとに変えることも技術的には可能ですが、先に契約を読んでください。販売先によっては、他の経路と比べて不利な扱いをしないことを求める条項が置かれている場合があります。私の店はこれ自体に手をつけていません。

7️⃣ 【楽天API自動化20選④】既製サービスでは埋めにくい判断｜4つ

ここが、既製のサービスではいちばん埋めにくい領域です。理由も書きます。

先に、立場をはっきりさせておきます

プラットフォームや一元管理サービスは、多数の店に同じ機能を提供します。だから平均に合わせた作りになります。

これは怠慢ではありません。多くの店に対して公平で、安定していて、壊れにくいものを出す。それが彼らの責任です。

実際、ここまでに挙げた16個のうち、名寄せ（⑯）・禁止語の検出（⑨）・昨日との差分（③）は、既製のサービスの中核機能とそのまま重なります。重なるなら、そちらのほうが早くて安全です。

重なる部分を全部引いた残りが、この4つです。自店の原価と、取引先との約束と、過去に自分が踏んだ失敗が判断に入る瞬間だけが残りました。

⚠️ 1つだけ性格が違うものが混ざっています。⑲は判断そのものではなく、判断を動かし続けるための土台です。ここが止まると、残り3つは静かに嘘をつきはじめます。だからこの章に入れました。

⑰ 粗利の下限を、機械に守らせる

粗利（売値から仕入れ値を引いた残り）の下限を、先に決めておきます。そのうえで、お金が出ていく処理の出口に、その線を置きます。

私の店がいま置いているのは、広告費のところです。

頼む言葉：「粗利がこの線を割る商品は、広告の単価を上げないで」

起きること：広告の単価を決める処理の出口に検査が入り、粗利が下限を割る商品は増額の候補から外れます。楽天へ反映するのは一括更新の形なので、送るファイルを作る時点で落ちます。人が指示しても上がりません。

効き目：売れているという理由だけで、利益の出ない商品に費用を積み増すのを止められます。

入れたきっかけは、よく売れているからと広告を強めた商品が、粗利で見たら赤字だったことです。気づいたのは月末でした。

なぜ自分で作るのか。原価は店の営業秘密で、外部のサービスに渡っていません。渡したとしても、下限をいくつにするかは店の資金繰りと在庫の性格で決まります。全店に同じ値を配ることに意味がありません。

まずは、お金が出ていく経路を紙に書き出してください。私の店は5本ありました。線を置けるのは、経路が見えている場所だけです。

⚠️ ただし裏面があります。原価データが古ければ、このガードは伸ばすべき商品まで止めます。事故防止が静かな機会損失に化けます。「止めた件数を毎日見る」をセットにしてください。ガードを入れることと、ガードを監視することは別の作業です。

測り方：ガードが止めた件数（ゼロが続くなら緩すぎ、多すぎるなら基準か原価が古い）

⑱ 広告のレポートを、解釈つきで読ませる

頼む言葉：「楽天のレポートを見て」

起きること：前月比・商品別・キーワード別の解釈つきレポートが日本語で出ます。「この語は成果がゼロのまま続いている」「この商品は外すことを検討したほうがいい」という判断まで出します。外すかどうかを私が決めると、その理由が記録されます。翌月、同じ議論を蒸し返しません。

効き目：広告の実績データを取ってくるAPIは、私が確認した範囲では見当たりませんでした。でも、諦める必要はありません。無いのは「取得」だけで、取ったあとの集計と解釈は自動化できます。

集計で1つ工夫があります。落とすたびに集計期間の起点が微妙にずれます。月初からのときもあれば、直近30日のときもある。そのまま前月と比べると、期間の長さの違いを効果の差だと読み違えます。なので「1日あたり」に直した数値を併記します。

⚠️ 成果がゼロだからと機械的に全部外すと、将来の入口を失います。「複数回のデータで一貫してゼロ」「商品と語がそもそも噛み合っていない」など、確信の持てるものから段階的に。

この形は、APIが無くても今日から始められます。

⑲ 自動処理そのものを見張る

きっかけ：毎日、決まった時刻に単独で動きます

起きること：日次処理の成否・件数・所要時間が記録され、「前日より件数が急減した」「今日の実行記録が無い」を検知して通知します。

効き目：異常に気づくまでの時間が、翌日から数分になります。実話から書きます。

ある日、価格の一斉変更が実行されていませんでした。ログを見ると処理は途中で落ちています。原因は送信ではありませんでした。送信は成功していたのです。そのあとの、結果を画面に表示する行で落ちていました。表示に使った記号が、その環境では扱えなかった。

呼び出した側から見ると、これは「失敗」です。だから後続の処理を全部やめました。実際には送信済みなのに。

この不整合が、9時間続きました。

自動化を勧める記事が書き落としがちな論点がここです。自動化は、止まっても誰も気づきません。そして成功の定義を「エラーが出なかったこと」にすると、この種の失敗を拾えません。件数で持つ必要があります。

測り方：異常が起きてから気づくまでの時間

⑳ 返品の多い商品と、その説明文を突き合わせる

頼む言葉：「返品が集中している商品を出して。その商品のページに、その理由に触れた記述があるか見て」

起きること：説明で先回りできていない商品が浮かびます。

効き目：私の店では、返品の多い商品を見に行くと、その理由に触れていないページが実際に出てきました。もちろん返品の原因は説明文だけではありません。品質や配送の問題もあります。ここで拾えるのは「説明で減らせたはずのぶん」だけです。

⚠️ ここは必ず1つ挟んでください

返品理由も、問い合わせの内容も、お客様の個人情報を含みます。

ためるのは商品コードと、理由の分類と、日付だけにしてください。お名前、注文番号、住所、連絡先、それに体調や身体に関する記述は、分類した時点で切り離します。

ここを飛ばすと、便利な台帳がそのまま個人情報のデータベースになります。始める前に、利用目的をはっきりさせること、見られる人を限ること。この2つだけは先に決めてください。

※この項目は、私の店ではまだ手作業の途中です。仕組みになりきっていません。

8️⃣ 実際の頼み方｜そのまま使える依頼文3本

ここでつまずく方が多いので、私の店で使っている頼み方を載せます。

⚠️ カギの扱いは第3章に書いたとおりです。チャットに貼らない。ここがいちばん踏まれる場所なので、もう一度だけ。

◆ 取得を頼むとき

楽天の店舗向けAPIで、私の店の全商品を取ってきたい。
まず1件だけ取って、中身を見せて。
うまくいったら全件に広げたいので、そのつもりで組んで。
書き込みは絶対にしないでください。

最後の1行が大事です。読むだけの仕組みには、書き込む道を最初から作らない。

◆ 保存を頼むとき

さっきの取得を毎日1回、決まった時刻に動かして、
その日の状態をまるごと手元に保存したい。
1か月ぶんためて、前の日と比べられる形にして。
失敗したら私にメールが飛ぶようにして。

◆ 比較を頼むとき

昨日と今日を比べて、次の3つを出して。
1. 価格が変わった商品
2. 在庫が減った商品
3. 説明文が変わった商品
変わっていないものは出さなくていい。

この3つが動けば、20選の①と③が完成し、④⑤に必要なデータがそろいます。ここまでで、書き込みは1回もしていません。

9️⃣ できないこと｜楽天APIが「そもそも無い」領域

探しても無いものと、あると思って壊すもの。危ないのは後者です。

この章は前者——「探しても無いもの」です。後者の制約の罠は、次の第10章にまとめました。着手前にいちばん効くのは、そちらです。

探しても見つからなかった5つ

🔵 A 動画のアップロード

商品ページに動画を載せる仕組みはありますが、私が確認した範囲では、動画ファイルをアップロードするAPIは見当たりませんでした。登録済みの動画をページに配置する部分は自動化できます。「ファイルを選ぶところだけ人、あとは自動」という分担です。

なお、載せる動画そのものの権利まわりは別の話です。撮影許可と商用利用は別物なので、こちらの記事にまとめてあります。

🔵 B メルマガの作成と配信予約

配信システムに、外部から操作する窓口は見当たりませんでした。原稿はAIに書かせられますが、入れて予約するところは画面作業です。

🔵 C 広告の入札操作

入札額を直接動かすAPIは見当たりませんでした。ただし「APIが無い＝自動化できない」ではありません。画面が受け付ける一括更新の形に落とせば、判断そのものは仕組みにできます。⑱の解釈と組み合わせると、ここは自動化の余地が大きい領域です。

🔵 D レビュー本文の取得

店舗向けに、レビュー本文を取ってくるAPIは見当たりませんでした。

ここは手段の選び方そのものが論点になる領域です。「APIが無いなら別の方法で取ればいい」と考える前に、その方法がサイト側の規約に触れないかを確かめてください。私はこの記事で、具体的な取得手段については書きません。規約の判断は、取る人が自分の条件で行うべきものだからです。

🔵 E 公開のAPIから自店のデータを見る

公開のAPIは公開情報しか返しません。ここだけは断定できます。

⚠️ A〜Dは、2026年8月時点で私の店が確認した範囲です。提供機能は増減します。着手前に必ず最新の情報をご自身で確認してください。

「できない」と思い込んでいたもの

正直に書きます。この記事を書くために調べ直したら、できるものが混じっていました。

🔵 店舗の設定は、書けます

私はずっと「休業日や納期の表示は、読めるけれど書けない」と思っていました。間違いでした。取得だけでなく、登録や更新もできる機能が用意されています。

私の店が読み取りだけで使っていたのは、そういう運用にしていたからで、できないからではありません（⑭の納期表示がその例です）。

思い込みで「できない」に分類していたわけです。自分の運用の制約と、提供されていないことは、別物でした。

まだ手をつけていない領域

同じく調べ直して分かった、私の店が使っていない機能です。どれも提供されています。

クーポン／問い合わせ管理／購入の申込／組み合わせ販売／ジャンルと商品属性／製品情報／購入された商品の実績。

この7つは、私がまだ触っていないだけです。何ができるかの詳細は、ここには書きません。自分の管理画面から、提供されている機能の一覧を通しで見てください。

このうち問い合わせ管理は、私にとって次の一手になりそうです。⑳で「返品の理由を手で書き残している」と書きましたが、取ってくる部分は仕組みにできます。

ただし本文そのものはAIに渡しません。分類をどこで行うかは、第11章のルール5（個人情報はAIを通さない経路で処理する）に従って決めます。

「無い」と思っていたものが、実はあった。着手する前に、いま提供されている機能の一覧を一度は通しで見てください。作らなくていいものを作らずに済みます。

🔟 壊さないために｜制約でつまずく7つの罠

ここからが本番です。「APIが無い」は調べれば分かります。危ないのは、あると思って触って壊すほうです。

この7つは、着手前に全部読んでおいてください。とくに罠②は、知らずに触ると取り返しがつきません。

🔵 罠① 呼び出しの回数に上限がある

好きなだけ呼べません。「全商品を一気に処理する」ができないので、一晩かけて回す前提で設計します。副作用もあって、全件を一律に回すといちばん動いている商品の情報がいちばん古くなるという逆転が起きます。

🔵 罠② 書き込みが「上書き」として働くことがある

これがいちばん怖い罠です。在庫の数だけを更新したつもりが、一緒に送らなかった項目が空になって消えることがあります。書き込みの単位が「1項目」ではなく「レコード全体の置き換え」になっている場合です。全商品に定時で回す仕組みだと、気づいたときには全件が壊れています。

対策は3つ。書き込む前に現在の値を丸ごと取得して、変えない項目もそのまま載せて送る。ごく少数で試して照合してから全件へ広げる。実行後に必ず読み直して照合する。

ただし1つめには副作用があります。取得してから送るまでの間に誰かが画面から値を変えていると、その変更を巻き戻します。なので「自動処理を動かしたまま、同じ項目を人が画面から直す」ことをしないでください。手で直すときは、いったん自動処理を止めます。

着手前に「書き込みの単位は項目なのか、レコード全体なのか」を必ず確かめてください。

🔵 罠③ 画像は必ず楽天の置き場を経由する

私が確認した範囲では、自分のサーバーの画像URLを商品の画像欄に登録することはできませんでした。差し替えは「アップロード → 参照先を変更」の2手順です。

🔵 罠④ 反映に時間差がある

更新してもすぐページに出るとは限りません。ここで「反映されていない」と判断して二重に更新するのが、いちばんよくある時間の溶かし方です。人は待てません。仕組みは待てます。

🔵 罠⑤ 一度やると戻せない操作がある

事前のバックアップが必須です。

🔵 罠⑥ 認証のカギに期限がある

切れると全処理が一斉に止まります。期限を自分で覚えておく必要はありません。取りに行って知らせる仕組みを1つ足してください。

🔵 罠⑦ 画面にしかない情報がある

APIで取れる項目と管理画面で見える項目は完全には一致しません。管理画面と併用する前提で設計します。

1️⃣1️⃣ できるけど、やらないと決めた6つ

技術的にはできます。でも、やらないと決めています。

自動化で事故る原因は、できる範囲の狭さではありません。やらない範囲が決まっていないことです。

やらない範囲を決めておくと、知識が足りなくて間違えたときでも、被害の大半は公開前で止まります。私が踏んだ失敗はどれも知識不足が原因でしたが、公開の手前に人を置いていたおかげで、お客様には届きませんでした。

⚠️ ただし「大半」です。このあと書く2つの例外は、無人で公開中のページを変えます。そこだけは、人の代わりに検査と見張りを置いています。

🔵 ルール1 承認なしの公開はしない

新しく公開するときと、ページの内容を変えるときは、人が押します。作るところ、検証するところまでが自動です。

⚠️ 例外を2つ持っています。どちらも無人で、公開中の商品情報や販売可否を変えます。

◆ ⑧のキャッチコピー——毎日決まった時刻に書き換わります。書き換える型を先に承認してあり、入る値は在庫データから機械的に決まります。文字数の検証を通ったものだけが送られ、落ちたら私にメールが飛びます。

◆ ⑮の在庫連動——自動で連動している2つの販売先については、売り切れの知らせが届いたら承認を待たずに0にします。止める方向にしか動かないからです。売れるようにする変更は、人が押します。

例外を作るなら、3つが要ります。型を先に承認しておくこと。値が機械的に決まること。検査に落ちたら止まって知らせること。⑮にはもう1つ、動く向きが片方だけという条件が付いています。

正直に書くと、⑮の検査は「実行したあとの照合」です。送る前に止める仕組みは入っていません。そこは私の宿題です。

「便利だから」で外すと、例外は静かに増えます。

そして承認を求めるときは、件数だけを見せません。対象・項目・変更前の値・変更後の値を全件出します。「◯件を更新します」だけでは、押す側が判断できないので。

しきい値（ここを超えたら扱いを変える、という境目の数字）の決め方も書いておきます。「これが全部間違っていたら、手で戻すのに何時間かかるか」から逆算します。戻せない件数は、自動にしてはいけません。

🔵 ルール2 受注データは書き換えない

発送処理も注文変更も、APIからはやっていません。読むだけです。

ここは「できないから」ではありません。受注まわりは、書き込み側がいちばん充実している領域です。発送も、注文内容の変更も、キャンセルまで含めてできます。発送のあとから直せるものもあります。

つまり、私は相当広い範囲を意図的に捨てています。

この領域だけは、お客様へ直接通知が飛ぶからです。取り消せません。将来やるとしても、件数の事前確認・人の承認・実行・実行後の全件照合、この4段は省けません。

⚠️ もう1つ。ここを自動化するなら、カギの更新の運用を先に決めてください。切れた朝に受注が止まります。

🔵 ルール3 お客様の個人情報を手元に残さない

受注の照会はしますが、保存していません。必要なときに見るだけです。

⚠️ ただし保存していないから法律の対象外、ではありません。見ている時点で取り扱っています。利用目的をはっきりさせること、見られる人を限ること、誰がいつ何を見たかを追える状態にしておくこと。これは保存の有無に関係なく効きます。「持たない」は被害の大きさを下げる対策であって、義務を消す対策ではありません。

🔵 ルール4 認証情報をAIに読ませない

カギは保護された場所に人が直接置きます。中身はプログラムだけが読みます。チャットにもログにもレポートにも出しません。

AIツール側の権限設定でも同じ線を引けます。そのやり方はClaude Codeセキュリティ対策の記事に書きました。

🔵 ルール5 個人情報は、AIを通さない経路で処理する

お客様の個人情報は、生成AIに渡しません。これは例外を作らない原則です。便利かどうか、精度が上がるかどうかで動かしません。

店のデータを送る先は、自分の店に関わるサービスだけに絞っています。ただし、それだけでは足りません。AIツール自体が外部のサービスだからです。だから線をもう1本引いています。

そして「渡さないように気をつける」では守れません。経路を2本に分けています。

◆ AIを通す経路

商品・在庫・価格・説明文など、個人が特定できないものだけ。文章を書く、分類する、解釈する。ここはAIの仕事です。

◆ AIを通さない経路

受注、お名前、ご住所、連絡先、問い合わせの本文。プログラムが直接読んで、そのまま処理します。AIには一度も渡りません。

分析に使いたいときは、AIを通さない側で個人情報を落としてから、残ったものだけをAIへ渡します。返品理由なら、商品コードと理由の分類と日付だけを抜き出して、あとはその場で捨てる。

この分け方は、作るときに決めます。あとから「この処理はAIを通していないはず」と確認する形にすると、いつか混ざります。

外部に出すか出さないかではなく、どの経路で処理するかで線を引いています。

そしてもう1つ。外部のAIサービスに何かを渡す場合、それが業務の委託として整理できるのか、第三者への提供に当たるのかは、渡すものによって変わります。個人情報が絡むなら、この整理は避けて通れません。私は個人情報を渡さないことで、この論点そのものを発生させない側に倒しています。渡す設計にするなら、どちらの整理で運用するかを先に決めてください。

🔵 ルール6 危ない操作は「気をつける」で済ませない

削除と、承認していない上書きは、実行そのものを機械的に止めています。うっかり書いても、そこで止まります。

止めるのは「すべての上書き」ではありません。それでは⑧も⑨も動きません。止めるのは、承認していない削除と、変えるつもりのない項目への上書きです。この線引きを先に決めておかないと、ガードを入れた瞬間に何も動かなくなります。ただし仕組み自体の設定ミスまでは防げないので、定期的にわざと引っかけて止まるかを試しています。

自前でやる代償も、書いておきます

いい面ばかり書くのはフェアではないので。

問題1：作った人が抜けたら終わる。私自身、1週間ほど店を空けたことがあります。その間に1本が止まりました。戻るまで誰も手を打てませんでした。読み取り側だったので実害はありませんでしたが、書き込み側だったらと思うと、いまでも冷やっとします。

問題2：全部が同じカギを共有していると、一斉に落ちる。これも一度やりました。朝、メールが1通も来ていないので調子がいいのかと思ったら、前の晩から全部止まっていました。しかも見張りのメールを送る処理も同じカギを使っていたので、見張りごと沈黙していたわけです。

対策は3つです。

対策① 手順を人の頭ではなく文書に置く。何をしているか、止まったらどうするかを書き残します。AIに読ませる前提で書くと、書く動機が生まれます。

対策② 止まる前に鳴る見張りを、最初から入れる。後から入れるものではありません。1本目と一緒に作ります（⑲がそれです）。しかも見張りは、本体と別の経路で鳴らしてください。同じカギを共有していると、上のように見張りごと沈黙します。

対策③ 作る前に、これを計算しておく。「この仕組みが止まったとき、手作業で回すのに何時間かかるか」。回せない規模のものは、自動化してはいけません。

1️⃣2️⃣ 何から始めるか｜明日やる3つ

明日やることは3つだけ。それぞれ10分で始められます。

明日やる3つ（それぞれ10分）

◆ 1つめ：やらないリストを紙に書く

そのまま写して構いません。

• 公開は、人が押す

• 受注データは書き換えない

• お客様の個人情報は手元に残さない

• 認証情報はAIに読ませない

• 個人情報はAIを通さない経路で処理する（プログラムが直接扱う）

• 承認していない削除と上書きは、機械で止める

◆ 2つめ：管理画面から商品データを1回だけ落とす

列を絞ります。商品コード、名前、価格、在庫、そして商品説明文。この5つです。

◆ 3つめ：AIに1文だけ投げる

「このデータの中から、説明文に去年の日付が残っている商品を全部出して」

これで何か出てきたら、あなたの店には自動化する価値のある作業があります。何も出てこなければ、急ぐ必要はありません。

そのあとの順番

ステップ1：やらない範囲を先に決める。私はここを飛ばして、いきなり書き込みから作りました。1週間で戻すはめになりました。

ステップ2：読むだけの仕組みを1つ作る。20選の①がそれです。書き込む経路を持たない作りにしてください。期間の目安は数週間。

ステップ3：書く仕組みを1つ、検査つきで作る。書く処理より先に、検査を作ります。そして自動処理と同じ項目を、動かしたまま手で直さないでください。毎日上書きする仕組みなら、手修正は翌日に消えます。直すときは、いったん自動処理を止めます。期間の目安は1〜2か月。

やってはいけない順番

• いきなり書き込みから始める

• 検査を後回しにする

• やらない範囲を決めずに進める

• 全商品を一度に処理しようとする

• 見張りを後から入れようとする

「私の店にはデータの蓄積がない」と思った方へ

資産はデータの量ではなく、文脈です。

返品が月に3件しかなくても、その3件の理由を知っているのは自分だけです。それは1万件のデータを持つ他社が持っていない情報です。

ただし、量が要る施策もあります。④の減り方の推定や、⑳の返品の突き合わせは、件数が少ないと成立しません。そこは無理に始めなくていいです。

まとめ

🔵 店の管理画面は、言葉で動かせます。

ログインして、検索して、CSVに落として、Excelで開く。この15〜20分が30秒になります。変わるのは速さより、事実を見に行く回数です。

🔵 自動化できることは、20個ありました。

読む6つ、書く8つ、つなぐ2つ、判断する4つ。ただし全部が毎日動いているわけではありません。手作業の途中のものには、その旨を明記しました（⑨⑬⑭⑮⑯⑳）。

🔵 APIが無くても、諦めなくていい。

広告のレポートがその例です。取得が手作業でも、解釈と判断は自動化できます。

🔵 できないことは3層あります。

APIが無い。制約がある。そして、できるけどやらないと決めた。

🔵 いちばん大事なのは第3層です。

やらない範囲を先に引いておくと、知識が足りなくて間違えても、被害の大半は公開前で止まります。無人で動かす例外を作るなら、そこには人の代わりの検査を置いてください。

🔵 規約と法令は、作る前に確認する。

利用規約、個人情報の扱い、価格や表示のルール。詳細はここには書きません。使うAPIごとに、各規約をご自身で確認してください。

私の店も、最初は管理画面とにらめっこでした。全部を一度に変えたわけではありません。

読むだけの仕組みを1つ作るところから始めました。それが動いた日のことは、今でも覚えています。

最初の1つは、驚くほど小さくて大丈夫です。

🔗 関連記事

【前回】：【2026年保存版】撮影許可と商用利用は別物｜EC運営者が守る3つの権利

【あわせて読みたい】：【2026年版】Claude Codeセキュリティ対策｜settings.json権限設定とサンドボックスで押さえる5つの急所

✨ 最後まで読んでいただき、ありがとうございました ✨

この記事が役に立ったら、スキを押していただけると励みになります。

「私の店ではこうしている」という話があれば、ぜひコメントで教えてください。私も知りたいです。

※APIの提供内容や利用条件は変わることがあります。利用前に、各規約をご自身でご確認ください。

※この記事は、紹介しているツールの提供元から、金銭その他の対価を受け取って書いたものではありません。

#楽天市場 #楽天API #EC運営 #ネットショップ運営 #EC事業者 #店長 #業務効率化 #自動化 #ClaudeCode #AI活用 #生成AI #API連携 #在庫管理 #受注管理 #商品ページ #楽天出店 #Amazon #Yahooショッピング #EC自動化 #RPP広告 #粗利管理 #利用規約 #マーケティング #2026年