EC運営の定型業務はGASで自動化する。現役セラーが毎日使っている実例5選【コード付き】

毎朝の売上転記、在庫の目視チェック、競合価格の確認。その1時間は、Google Apps Scriptなら無料でゼロにできます。4モールを運営する現役セラーが実際に毎日使っている自動化を、コードと一緒に公開します。

監修: 廣瀬正拓(中小企業診断士 / 現役EC事業経営者)

なぜECの自動化はGASから始めるべきか

Google Apps Script(GAS)は、Googleスプレッドシートに標準で付いてくるプログラミング環境です。EC運営の自動化の第一歩として、これ以上の選択肢はないと考えています。理由は3つです。

1. 無料で、サーバーも要らない。Googleアカウントがあれば今日から動かせます。実行環境の構築や月額費用は一切不要です。有料の自動化ツールを契約する前に、まずここで試せます
2. すでに業務がスプレッドシートにある。多くのEC事業者は在庫表も売上表もスプレッドシートで管理しています。業務の形を変えずに、自動化だけを差し込めます
3. 時間駆動で勝手に動く。「毎朝8時に実行」「1時間ごとに実行」という設定(トリガー)が標準機能です。人が起動する必要がありません

以下の5つは、私たちがタロットカード・オラクルカードの自社ブランドを4モール(Amazon・楽天・Shopify・Qoo10)で運営する中で、実際に毎日動かしている仕組みです。

実例1: モール横断の売上を毎朝チャットに届ける

複数モールを運営していると、売上確認だけで各管理画面を巡回することになります。この巡回を廃止し、毎朝8時、昨日の売上がチャネル別にチャットへ届く状態を作ります。

各モールの売上データをスプレッドシートに集約しておけば(手動貼り付けでも、後述のAPI連携でも構いません)、通知部分はこれだけで動きます。

function sendDailySales() {
  const sheet = SpreadsheetApp.getActiveSpreadsheet()
    .getSheetByName('日次売上');
  const data = sheet.getDataRange().getValues();
  const yesterday = data[data.length - 1]; // 最終行 = 昨日分

  const message = [
    '昨日の売上(' + yesterday[0] + ')',
    'Amazon: ' + yesterday[1].toLocaleString() + '円',
    '楽天: ' + yesterday[2].toLocaleString() + '円',
    'Shopify: ' + yesterday[3].toLocaleString() + '円',
    'Qoo10: ' + yesterday[4].toLocaleString() + '円',
    '合計: ' + yesterday[5].toLocaleString() + '円'
  ].join('\n');

  const webhook = 'https://hooks.slack.com/services/xxx'; // Slack Webhook URL
  UrlFetchApp.fetch(webhook, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: message })
  });
}

これをトリガーで毎朝8時に実行するだけです。チーム全員が同じ数字を毎朝見る文化は、売上への意識を確実に変えます。

この仕組みの本当の効果は、時短だけではありません。各モールの管理画面を巡回する数分の作業が消えるのはもちろんですが、それ以上に、全員が毎朝同じ数字を目にすることの意味が大きいのです。誰かが確認して共有するのを待つのではなく、チーム全体が昨日の結果を同時に把握する。この小さな習慣が、数字への感度を組織に根づかせます。仮にあるチャネルの売上が急に落ちていれば、その日のうちに誰かが気づき、原因を探り始められます。

実例2: 在庫が閾値を切ったら即通知する

在庫切れは機会損失であると同時に、Amazonでは検索順位の毀損にもつながります。しかし在庫表の目視チェックは必ず漏れます。チェックを人の注意力に頼らず、仕組みに任せるのがこの自動化です。

ここで鍵になるのが、商品ごとに設定する発注点です。在庫がその数を割ったら通知する、という基準をあらかじめ決めておきます。発注点は、その商品が売れる速さと、発注してから届くまでの日数から逆算します。仮に届くまで数週間かかる商品なら、その間に売れる見込み数に余裕を足した数を発注点にしておけば、届く前に在庫が尽きる事故を防げます。売れ筋ほどこの設定を丁寧にしておく価値があります。

function checkStock() {
  const sheet = SpreadsheetApp.getActiveSpreadsheet()
    .getSheetByName('在庫管理');
  const rows = sheet.getDataRange().getValues().slice(1);
  const alerts = [];

  rows.forEach(function(r) {
    const name = r[0], stock = r[2], threshold = r[3];
    if (stock <= threshold) {
      alerts.push(name + ': 残り' + stock + '個(発注点 ' + threshold + ')');
    }
  });

  if (alerts.length === 0) return; // 問題なければ沈黙する

  const webhook = 'https://hooks.slack.com/services/xxx';
  UrlFetchApp.fetch(webhook, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: '在庫アラート\n' + alerts.join('\n') })
  });
}

実例3: 競合価格の変化だけを知らせる

競合の値下げに気づかず1週間放置すれば、カートも検索順位も持っていかれます。かといって毎日競合ページを見に行くのは時間の無駄です。しかも、複数の競合を毎日目視で追うのは現実的ではなく、必ずどこかで見落とします。監視対象のASINをスプレッドシートに並べ、GASで定期取得し、前回と価格が変わったときだけ通知する仕組みにします。

取得方法は、Amazon SP-APIの利用申請をするのが正攻法です。API経由であれば価格・カート状況・ランキングを安定して取得できます。SP-APIの認証まわりの実装は少し骨が折れますが、一度作れば資産になります。

仕組みの要点は「前回の価格をシートに覚えておき、今回の取得値と比べる」ことです。監視対象のASINごとに、取得日時と価格を1行ずつ追記していきます。新たに取得した価格が前回と違ったときだけ通知を飛ばせば、変化のない日は何も鳴りません。仮に監視対象が数十商品あっても、値動きのあったものだけがチャットに上がるので、目を通す量は最小限で済みます。値下げに即座に気づけるかどうかは、カート獲得や検索順位に直結する死活問題です。人の巡回に頼っていた監視を、変化検知の仕組みに置き換える価値は大きいと考えています。

実例4: 商品マスタから各モールのCSVを一括生成する

多モール展開の最大の壁は商品登録です。同じ商品なのに、Amazon・楽天・Qoo10でCSVの形式も文字数制限も画像規格も全部違う。1商品を4モールに登録するのに、手作業なら半日かかります。しかも、この作業は商品を増やすたびに繰り返し発生し、手作業である限りミスも比例して増えていきます。

そこで、自社の商品情報を1枚の「商品マスタ」シートに集約し、ボタン一つで各モールのフォーマットに変換して出力する仕組みを作りました。モールごとの文字数制限の切り詰め、禁止ワードの置換、画像URLの生成規則もすべてスクリプト側に持たせています。

この仕組みの本当の価値は時短ではありません。登録ミスと表記ゆれが構造的に発生しなくなることです。商品名の全角半角が揃い、価格の転記ミスが消える。多モール運営の品質は、こういう地味な仕組みで決まります。

この仕組みを作るうえで大切なのは、変換のルールをすべてスクリプト側に集約することです。例えばAmazonでは全角、別のモールでは半角、といった各モールの癖を、人がその都度覚えて手作業で直していては、必ずどこかで漏れます。ルールをコードに書いておけば、担当者が誰であっても同じ結果が出ます。仮に新しいモールに展開するときも、そのモール用の変換ルールを一つ足すだけで、既存の商品マスタから一括で出力できます。人の記憶に頼る運用から、ルールで統制する運用へ。この転換が、商品数が増えても品質を保てる体制を作ります。属人化を避ける発想は、EC運営のあらゆる業務に共通する原則です。

実例5: レビューの見逃しをなくす

低評価レビューへの初動は速いほど傷が浅く済みます。改善要望が書かれていれば商品開発の材料になります。にもかかわらず、レビュー確認は緊急でないという理由で、後回しにされがちな業務の筆頭です。気づいたときには低評価が積み重なっていた、というのは多くのセラーが経験する失敗です。

自社商品のレビューを定期取得してシートに蓄積し、新着があったときだけ通知する。星3以下は別枠で強調する。これだけで、レビューという最重要の顧客の声が、確実にチームの目に入るようになります。蓄積したレビューデータは、次の商品企画の一次情報としても機能します。

レビューの価値は、初動の速さと蓄積の両面にあります。低評価がついたとき、その日のうちに気づいて対応できれば、傷は浅く済みます。放置して同じ不満が積み重なると、商品全体の評価が下がり、挽回に大きな労力がかかります。一方で、蓄積されたレビューは宝の山です。仮に「梱包が甘い」という声が複数集まっていれば、それは次に手を打つべき明確な課題です。購入者が自分の言葉で書いた不満と満足は、どんな市場調査より正直で具体的です。通知で初動を速くし、蓄積で改善のネタを拾う。この二つを同時に叶えるのが、レビュー監視の仕組みです。

トリガーで自動実行する

ここまでのスクリプトは、書いただけでは動きません。人が起動しなくても勝手に走るようにする設定が「トリガー」です。ここがGASの真価であり、手作業をゼロにする肝でもあります。

設定はスクリプトエディタの時計のアイコンから行います。関数名と、実行のきっかけを選ぶだけです。よく使うのは次のパターンです。

• 時間主導型。毎日決まった時刻、あるいは数時間おきに実行する。売上通知や在庫チェックに向く
• スプレッドシート主導型。シートが編集されたときに実行する。入力をきっかけに処理したいときに使う

例えば売上通知なら毎朝8時に、在庫チェックなら1時間おきに、といった具合に設定します。一度決めてしまえば、あとは人が何もしなくても仕組みが動き続けます。仮に旅行で家を空けても、在庫アラートは変わらず鳴り、朝の売上はチャットに届きます。人の起動を待たないという一点が、単なる便利ツールと自動化を分ける境目です。

GAS導入でつまずきやすい点

初めてGASに触れる人が引っかかりやすい点を、先にお伝えしておきます。知っていれば数分で越えられる壁です。

• 初回の承認。最初にスクリプトを実行すると、Googleアカウントへのアクセス許可を求められます。自分で書いた処理を自分のシートに対して動かすための確認なので、内容を読んで進めます
• 実行時間の上限。1回の実行には時間の制限があります。大量データを一度に処理しようとすると止まるので、分割して処理する工夫が要ります
• 外部通知の設定。SlackやLINEへ送るには、送信先のWebhook URLなどの準備が必要です。ここは一度作れば使い回せます
• エラー時の気づき方。トリガーで動く処理は、失敗しても画面に出ません。失敗を通知する仕組みを入れておくと、静かに止まっていた事故を防げます

どれも一度越えれば、二度目からは意識せず使えます。最初の1本を動かすまでが少しだけ骨で、そこを越えると一気に世界が広がります。仮に最初でつまずいても、エラーの文言をそのまま検索すれば、たいてい解決策が見つかります。完璧を目指さず、まず動かすことを優先してください。

自動化を定着させる3つのコツ

最後に、数年運用して分かった定着のコツを共有します。

1. 通知先を人が毎日見る場所にする。メールではなくSlackやLINE。既読される場所に届けなければ、自動化は存在しないのと同じです
2. 異常時だけ鳴らす。正常報告を毎日送ると、通知全体が読み飛ばされるようになります。沈黙はよい知らせ、という設計を守る
3. 1つずつ育てる。最初から全部作ろうとせず、いちばん面倒な業務から1つ。動いて信頼されてから次を作る

• 毎朝、誰かが手作業で売上を転記している
• 在庫切れに「気づいたら起きていた」ことが年に数回ある
• 競合の値下げに1週間気づかなかったことがある
• 商品登録のたびに各モールのCSVを手で作っている
• 低評価レビューへの返信が3日以上遅れたことがある

1つでも当てはまれば、GASによる自動化の効果が出る状態です。まずは実例1の売上通知から始めてみてください。最初の1本が動いて手作業が消える体験をすると、次に自動化したい業務が自然と見えてきます。完璧なシステムを目指すのではなく、いちばん面倒な作業を一つ、機械に肩代わりさせる。その積み重ねが、気づけばEC運営の土台を大きく軽くしてくれます。