赤兎馬赤兎馬EC運用支援

手数料を「実額」で取りに来る|公式APIで広告後粗利を自動計算する分析基盤を内製した話

#生成AI #AI活用 #EC運用 #ネットショップ運営 #Amazon物販 #広告後粗利 #ClaudeAI

手数料を「だいたい10%くらい」で置いている限り、利益はいつまでもぼやけたままです。

私たちは月額の分析ツールを契約する前に、自社EC(Amazon+楽天)の受注・手数料・広告費・在庫を公式APIから取り込んで、SKU別の広告後粗利を出す仕組みを内製しました。設計と実装の加速にはClaudeを使っています。

うまくいった部分より、つまずいた部分のほうが役に立つと思うので、そちらを中心に書きます。

なぜ概算をやめたのか

きっかけは単純で、同じ商品の粗利が、見る資料によって違ったからです。

販売手数料をカテゴリの代表値で置いた計算と、実際に引かれた金額を見た計算で、SKUによっては数百円ずれていました。単品粗利が1,000円台の商品で数百円ずれるということは、黒字と赤字が入れ替わるということです。

概算のまま「このSKUは黒字だから広告を増やそう」と判断していたら、増やしていたのは赤字だったかもしれない。そう気づいた時点で、実額を取りに行くしかなくなりました。

作ったものの全体像

考え方の粒度で書きます。

```
公式APIから取得(受注 / 手数料 / 広告費 / 在庫)
↓
データベースに正規化(SKU単位で突き合わせられる形にする)
↓
指標を計算(単品粗利 → 広告後粗利 → 損益分岐ACoSとの比較)
↓
現場が見る場所へ配信(ダッシュボード / スプレッドシート)
```

4層にしたのは、どこかが壊れたときに切り分けられるようにするためです。API側の仕様変更で取得が止まっても、計算ロジックとは無関係だと分かる。この分離はやっておいてよかったです。

AIに任せた部分と、任せなかった部分

ここが一番書きたかったところです。

Claudeに任せたのは実装の加速です。APIのレスポンスをどう正規化するか、リトライやレート制限をどう扱うか、テストをどう書くか。この辺りは対話しながら進めると明らかに速い。

任せなかったのは指標の定義です。「何を利益と呼ぶか」「広告費をどのSKUに割り当てるか」「返品をいつの月に計上するか」。この定義を人が決めずにAIに書かせると、数字は出るが意思決定に使えないものが出てきます。

もっともらしい数字が並ぶぶん、むしろ危ない。定義が曖昧な指標は、後から「これ何の数字だっけ」となって誰も見なくなります。

AIを入れて速くなるのは実装であって、何を測るかを決める仕事は減りません。ここは経験上はっきりしています。

つまずいた3つ

1. 手数料は後から効いてくる

これが一番やられました。手数料は決済の確定処理が後追いになるため、当日や翌日にAPIを叩いても金額が確定していないことがあります。

最初は取得した日のデータをそのまま確定値として扱っていたので、粗利が実際より良く出ていました。良い数字が出ると疑いにくいので、しばらく気づけませんでした。

対策は、直近の一定期間をさかのぼって毎回取り直す設計に変えることです。つまり「昨日ぶんを1回取る」ではなく「直近2週間ぶんを毎回上書きする」。地味ですが、これで数字が落ち着きました。

2. APIの権限は、欲しいデータが最初から全部取れるわけではない

外部APIは用途ごとに利用申請と審査があり、取りたい情報の種類によって必要な権限が違います。私たちも、受注系は通ったのに競合のランキング系は権限の追加が必要で、そこは取れないまま動かし始めました。

ここで全部揃うまで待つ判断もあったと思いますが、待つと何も動かないので、取れるデータだけで先に回しました。結果としてはこれで良かったです。完璧な基盤を待つより、不完全でも毎日見る数字があるほうが判断は進みます。

3. ダッシュボードより、スプレッドシートのほうが見られた

きれいなダッシュボードを作ったのですが、実際に現場で開かれたのはスプレッドシートに書き出したほうでした。

理由は分かりやすくて、その場で並べ替えたり、メモを書き足したり、他の資料と一緒に貼れるからです。ツールとして正しいかより、普段の作業の流れの中にあるかのほうが強い。作る前に気づきたかった話です。

何が変わったか

SKU別の広告後粗利が毎日固定されると、これまで別々に議論していたものが同じ土俵に乗ります。

「利益」という共通の物差しができたというのが、一番大きな変化です。

内製すべきか、ツールを買うべきか

正直に書くと、これは場合によります。

市販の分析ツールはよくできていて、立ち上げの速さでは勝てません。私たちが内製を選んだのは、手数料の扱いや広告費の配分ロジックを自分たちで定義したかったからで、そこにこだわりがないなら既存ツールのほうが合理的です。

ただ、どちらを選ぶにせよ「何を利益と呼ぶか」を自社で決めておく必要があるのは同じです。ここが決まっていないと、どんなに良いツールを入れても出てくる数字を解釈できません。

まず現状を可視化するところから

「SKU別の広告後粗利を出す」と言葉にすると簡単ですが、実額手数料を揃えるところで止まる店舗が多いのが実情です。

もし自社の数字がまだ揃っていないなら、いきなり基盤を作る必要はありません。まずは主力1SKUの実額を洗い出すところから始めれば十分です。

そこも含めて手が回らない場合は、店舗URLをいただければ公開情報の範囲で改善余地をレポートにしてお返ししています。まずは現状を可視化しませんか、という提案です。

無料EC診断:https://ec-sekitoba.jp/#contact

なお本文中の設計は考え方の粒度にとどめており、具体的な実装手順やプロンプトは記載していません。

引用元
・出品・注文・手数料データの取得仕様および利用申請:Amazon Selling Partner API 公式ドキュメント ・広告レポートの取得仕様:Amazon Ads API 公式ドキュメント ・受注・在庫データの取得仕様:楽天 RMS Web Service 公式ドキュメント ※本文中の金額はすべて説明のための仮の計算例です。

関連サービスAI内製化道場(社内に「作れる人」を育てる月額プログラム)EC運用支援