ECの手作業をつなぐ——GAS・API・ノーコードのどれか決められない人へ

EC業務の自動化ツールは、機能の多さでは選べない。モールの仕様変更や認証切れで止まるのは避けられず、選ぶ基準は「止まったときに気づけて、自分で直せるか」になる。判断軸は、つなぐ相手・更新頻度・自分以外に触る人がいるかの3つ。手元で完結するならGAS、引き継ぐならノーコードが起点だ。

• できることは重なる：GAS・API・ノーコードの機能範囲は大きく重なる。差が出るのは復旧のしやすさと、自分以外が触れるかどうかだ
• 判断軸は3つ：①つなぐ相手 ②更新頻度 ③自分以外に触る人がいるか
• ツール名から入らない：料金やAPIの仕様は変動が速い。名前より先に、この3軸で自分の条件を確定させる

「止まらない自動化」は、そもそも選べない

設定したら放置して動き続けてほしい。動機はほぼこれで、正しい。

ただし「止まらないもの」は選択肢の中にない。止まる原因の多くは、変更権限が自分の外側にある。モールのCSVの列が1本増える。APIのバージョンに終了予定日が付く。社内も同じで、同僚がスプレッドシートに列を1本挿す、定期実行の所有者アカウントが退職で消える。どれにも自分の承認は挟まらない。

気づけるかどうかは、通知の有無より宛先で決まる。廃止の告知が届いても、宛先がアプリ登録時のアドレスのままなら店舗には来ない。

壊れ方は「エラーが出る」だけではない。構造上3種類ある。

• エラーで止まる：メッセージが出て停止する。最も幸運な壊れ方だ
• 沈黙して動かない：実行そのものが起きない。何も起きないので気づけない
• 成功したまま中身が壊れる：ログは「成功」。列がずれても型が合えば通り、隣の列の値が入る

厄介なのは3つ目だ。未知の区分値が「その他」に落ちる、空の応答で在庫数が0に上書きされる。どれもエラーにならない。エラー前提の選び方では、この帯を取りこぼす。

だから選ぶ観点は2つに絞られる。止まったと気づけるか、自分で直せるか。何を自動化するかがまだ固まっていないなら、EC受発注・在庫管理の自動化は、どこからAIに渡していいのかが先だ。

選び分けを決める3つの判断軸

手段を先に決めない。次の3つを自分に当てると、選べる手段は絞られる。

軸① つなぐ相手：仕様の変更権限が自社の外にあるか

そのデータはスプレッドシートと自社ECの中だけで動いているか。それとも楽天RMSやセラーセントラル、WMSを跨ぐか。跨ぐなら2つ見る。仕様変更のお知らせは誰のメールアドレスに届くか。SKUと商品管理番号、モール別商品番号の対応表がそもそも存在するか。無いなら、手段選びより先にそれを作る話になる。これは在庫管理の「勘」をAIに渡す前に、言語化しておくべきことと地続きだ。

軸② 更新頻度：作った後、何を触り続けるのか

1回動けば終わる移行作業か、毎日や毎週動き続ける定常業務か。定常なら、次に手を入れる予定はいつか。予定がないなら、沈黙して止まったことに気づく機会がない。月1回しか動かない処理は、壊れてから気づくまで最長1か月かかる。

軸③ 自分以外に触る人がいるか

そのシートを自分以外の誰が編集できるか。列を1本挿入されたら壊れる作りか。つまり参照が列番号か、ヘッダー名か。自分が1週間休んだとき、止まったことに誰が気づき、誰が戻せるか。所有者アカウントは、退職や異動で消えないか。

GAS・API・ノーコードが、それぞれ向く場面

順番の話ではなく、3軸のどこにいるかで残る選択肢が変わる。

GAS：スプレッドシートの中で完結し、自分で直せるとき

主戦場は、モールから落としたCSVをシートに貼り、商品管理番号で突き合わせて在庫数を作る形だ。外部のAPIも呼べるが、認証の面倒を自分が抱える側になる。軸③は最も弱い。書いた本人以外が直すにはコードを読める人が要り、所有者アカウントに寿命がある。復旧はコードの修正か承認のやり直しで、画面のボタン1つでは戻らない。鍵やトークンをセルに直書きしないことも前提だ。

API連携：相手の一次仕様に正面から追随したいとき

SP-APIで注文を取り、出荷実績と伝票番号を返す。相手の一次仕様に最も忠実で、仕様変更に自分の判断で追随できる。ほかの手段では追随の主導権がツール提供元にある。高頻度・大量件数にも耐える。ただし中身を読めるのはコードを読める人に限られ、復旧はコードとログの読解が前提になる。コードを書かない前提なら外注になり、その時点で「自分で直せるか」の答えは変わる。

ノーコード：定常運用と引き継ぎを前提にするとき

前提は、つなぐ相手のコネクタが実在するかだ。海外製のツールが日本のモールを標準で持つとは限らず、「あるはず」で設計を始めるのが最大の落とし穴だ。主要なツールでは実行履歴と再実行が画面に残るので、処理件数が前日と大きく違うといった異常に気づける。ただし履歴の保持期間と再実行の可否はプランで変わるため、選ぶ前に確認する。流れを他人が読めるので、引き継ぎのコストは3つの中で最も低い。復旧も画面上の再接続や再実行で戻る範囲が広い。組み方の例はノーコードで受発注メールを自動仕分けしてみた記録にある。氏名や住所を含む受注データが外部を経由するなら、委託先の管理も確認する。

生成AIに文章を作らせるステップは、どの手段でも挟める。ただし出力は返ってくるのでエラーにならない。ChatGPTに書かせた商品説明文、そのまま使うと危ない理由が典型だ。

3軸はどれも「自分で直せるか」に収束する。この線引きを決めること自体が、EC担当者がAI時代に学ぶべきスキルの本体でもある。

よくある質問

コードが書けないなら、ノーコード一択ですか

一択ではない。分かれ目は技量ではなく、コネクタが実在するかと、壊れたとき誰が直すかだ。逆にシート内で完結する処理なら、経由する外部サービスが1つ減るぶんGASの方が壊れる地点が少ないこともある。

無料で始められますか

金額は各サービスの現行プランを見てほしい。ここで答えられるのは、無料で始めると何を自分が引き受けるかだ。実行の履歴が残るか、失敗の通知が来るか、失敗した分を再実行できるか。この3つが無い状態は無料ではなく、気づけないコストを後払いしているだけだ。

途中で乗り換えられますか

重さを決めるのは処理の中身ではなく、次の3つがツールの外にあるかだ。正本の定義、番号の対応表、項目のマッピング定義。これが設定画面の中にしか無いと、乗り換えは作り直しになる。対応表とマッピングを外に出しておけば、選び直しが選び直しで済む。

あわせて読みたい：商品ページを生成AIで作る：任せていい範囲と、危ない範囲

あわせて読みたい：どの業務から触るかを先に決めたい場合はEC担当がAIを覚える順番：自分の業務のどこから触ると、いちばん早く手応えが出るか。