複数モールの売上を1枚にまとめようとして詰まる理由

複数モールの売上を1枚のシートで見たいという要望自体は単純です。しかし、各モールの管理画面は独立しており、ダウンロードできる項目・粒度・期間の切り方がそれぞれ異なります。

モールごとにデータの出どころが違う

「とりあえずCSVを全部同じシートに貼る」というやり方でも一応は集約できますが、モールが増えるたびに貼り付け作業が増え、集計式もモールごとの列構成に合わせて個別に組む必要が出てきます。

「自動化できるか」を先に決めてから設計する

私たちが実際に詰まったのは、集約の仕組みを先に作ってから、後で自動化を検討しようとした場面でした。取得方法（API／CSV）が後から変わると、集約側のロジックも書き直しになります。

このため、設計の順番を変えました。先に「このモールはAPIで自動取得できるか」をモールごとに検証し、取得方法が確定してから、集約の仕組みを作るという順番です。次の章では、その前に必要な整理として、そもそも何を集約したいのかを分解します。

「売上・注文・流入」の3種類を分けて考える

「売上管理」とひと言でまとめると、実際にはモールから取得したい数字が複数の種類にまたがっていることを見落としがちです。私たちは次の3種類に分けて考えています。

  • 売上データ：日別・SKU別・流入元別などの売上金額と注文数
  • 注文データ：個々の注文の明細（単価・送料・ポイント負担などの内訳）
  • 流入データ：セッション数、カート追加数、購入完了に至った数などの挙動の数字

この3種類で「取得可否」が分かれる

この分け方が要るのは、モールによって「APIで取れる種類」が異なるからです。売上や注文はAPIで取れても、流入（セッション数などのアクセス系データ）は取れない、というモールがあります。

「売上管理シート」として一括りに設計すると、一部のデータだけ自動化できてもシート全体を作り直すことになりかねません。3種類に分けておけば、種類ごとに取得方法を決められます。

週次レビューではこの3種を並べて見る

私たちの週次レビューでは、モールごとの「売上データ」タブと「商品（流入）データ」タブを分けて持ち、そこから週次の集計値を出しています。売上だけを見ていると、流入が落ちているのか、流入は変わらないのに転換が落ちているのかを区別できません。

3種類を分けて集めておくことで、次に説明する「モールごとの取得可否の検証」がしやすくなります。

モールごとに「APIで取れるか」を検証した結果

2026年7月に、手動CSVダウンロードをAPI自動取得へ置き換えられるかを、モールごとに検証しました。ここでは結果が分かれた3モールを取り上げます。

Shopify――売上も流入もAPIで取れた

Shopifyは、日別×流入元×SKUの売上と注文数、および日別×ランディングページのセッション数・カート追加・チェックアウト到達・購入完了までをAPIで取得できました。

検証時には、手動ダウンロードした生データとAPIで取得した生データを4行突合し、4行とも一致することを確認しています。セッション数の合計も、手動CSVとAPIの両方で14,360と一致しました。この結果を受けて、Shopifyの売上データと流入データは、両方ともAPI自動取得に置き換えています。

楽天――受注・売上はAPIで取れるが、流入は手動のまま

楽天市場は、受注検索・受注取得のAPIで受注データと売上データを取得できます。一方で、アクセス人数などの流入データはAPIで提供されておらず、手動CSVダウンロードのまま残しています。

加えて、楽天のAPI認証キーは約90日で失効し、手動での更新が必要です。売上だけを見れば自動化の余地はありますが、流入データが取れないうえに認証更新という手動作業が残るため、私たちはこのモールの自動化を見送り、手動CSV据え置きとしました。

なお、楽天の年度売上CSVには「アクセス人数」の列が含まれていません。売上のダウンロードと流入のダウンロードは、そもそも別のファイルになります。

Yahoo!――受注・売上の内訳は詳細に取れるが、流入は手動のまま

Yahoo!ショッピングは、受注・売上のAPIで実請求額・税込／税抜単価・送料・出店者負担ポイントの内訳まで取得できます。売上データとしての取得範囲は楽天より詳細でした。

しかし流入データのAPIは提供されておらず、こちらも手動CSVのまま残しています。さらに、Yahoo!の認証トークンは最長4週間で失効し、手動での再認可が必要です。楽天と同じ理由で、私たちはYahoo!の自動化も見送りました。

判断基準は「売上が取れるか」ではなく「流入まで取れて、無人で更新できるか」

3モールを検証して確定した判断基準は次の1点です。「売上・注文がAPIで取れるか」だけでは自動化の可否を決められません。流入データまでAPIで取得できるか、そして認証が無人で更新され続けるか、この2つが揃って初めて自動化の対象にしています。

楽天・Yahoo!はどちらも売上・注文はAPIで取れるものの、流入データが欠けており、認証の手動更新という負債も抱えるため、手動CSVを据え置く判断をしました。着手前に、まず数行が取得できるか、認証が自動延命できるかという小さな検証を行うことで、この見極めができます。

集約ロジックはシート側に置き、取得側は生データを貼るだけにする

Shopifyのように自動取得に置き換えたモールも、楽天・Yahoo!のように手動CSVのままのモールも、シートに入ってくる時点では「生の行」であることを揃えています。取得側（APIスクリプトやCSVの手動貼り付け）は、集計や加工をせず、生データをそのままタブに貼るだけの役割にしています。

取得側にロジックを持たせない

集約・加工のロジックは、取得方法によらずシート側の数式に一本化しています。この分離により、モールの取得方法を手動からAPIへ切り替えても、あるいはその逆でも、集約側の数式には手を入れずに済みます。

ARRAYFORMULAで行っている変換

私たちのシートでは、モールごとの「売上データ」タブと「商品（流入）データ」タブから、ARRAYFORMULAを使って次の変換を行い、週次の集計値を作っています。

  • 送料を除外する
  • バリエーション違いなどの子SKUを親SKUへロールアップする
  • 税込表示の金額を税抜きへ変換する
  • 商品を分析用のカテゴリへ割り当てる

これらはすべて、取得したモールが楽天であってもShopifyであっても、同じ形式の生データが並んでいれば適用できる変換です。モールごとに個別の集計式を組む必要がなくなります。

この分離がもたらす保守性

取得側と集約側を分けておく設計の利点は、モールの取得方法が変わったときの影響範囲を、取得側だけに閉じ込められることです。今後、楽天やYahoo!のAPIで流入データが提供されるようになった場合や、認証更新が自動化できる手段が出てきた場合も、集約側のARRAYFORMULAには手を加えず、取得側だけを差し替えれば済みます。

この設計を踏まえて、実際の週次レビューをどう回しているかを次に説明します。

週次レビューをどう回すか――自動化してよい範囲と人が見るべき範囲

集約の仕組みができたあとは、どこまでを機械に任せ、どこから人が見るかを分けておく必要があります。

自動化してよい範囲

私たちが自動化しているのは、次の作業です。

  • Shopifyの売上・注文・流入データのAPI取得
  • 送料除外・親SKUロールアップ・税抜き変換・カテゴリ割当のARRAYFORMULA集計
  • モールごとのタブへの生データの転記（Shopifyは自動、楽天・Yahoo!は手動CSVを貼るだけ）

これらは、集計ロジックを一度シート側に組んでしまえば、モールが増えても取得方法が変わっても同じ形式で再現できる作業です。

人が見るべき範囲

一方で、次の判断は自動化の対象にしていません。

  • どのモールを自動化対象にするかという線引きそのもの（流入まで取れるか、認証が無人更新できるかの検証）
  • 楽天・Yahoo!の認証キー・トークンの手動更新（90日・4週間という期限管理を含む）
  • 集計結果を見たうえでの週次の意思決定（在庫・広告・価格への反映）

認証更新のようにモール側の仕様に依存する作業は、無人化できる保証がない限り、そのまま手動作業として残すという判断をしています。

楽天・Yahoo!を手動据え置きとした前提での運用

楽天・Yahoo!については、流入データがAPIで取れるようになるか、認証更新が自動化できる手段が現れない限り、この線引きを変える予定はありません。手動CSVのダウンロードと貼り付けという作業は残りますが、集約側のロジックはシートに置いてあるため、貼り付けさえ行えば週次の集計値は自動で更新されます。

一部のモールが手動のままでも、集約の仕組み自体を壊さずに運用できる状態を、私たちはこの設計で維持しています。集計した売上から商品ごとにどれだけ利益が残っているかを見る段階は、EC商品別の粗利管理 で扱っています。

複数モールの売上をスプレッドシートに集約する際、「売上が取れるか」だけで自動化の可否を判断すると、流入データが欠けたまま自動化してしまい、あとで見えない部分が残ります。私たちが7モールで検証した結果、判断基準は「売上・注文・流入の3種類がすべてAPIで取れ、かつ認証が無人で更新され続けるか」でした。この基準でShopifyは自動取得に置き換え、楽天・Yahoo!は流入データの欠落と認証の手動更新負担から手動CSV据え置きとしています。取得側は生データを貼るだけにし、集約ロジックをシート側のARRAYFORMULAに一本化することで、モールごとの取得方法が変わっても集計の仕組み自体は壊れずに運用できます。