ECと基幹システムの二重入力をなくす：受注から仕訳までの自動化アーキテクチャ

成長しているのに、作業量も増え続けている

楽天市場に出店した。次にAmazon Japanを開設した。自社ブランドの強化のためにShopifyも立ち上げた。売上は順調に伸びている。

しかし気づけば、毎日の運用がこうなっていないだろうか。

朝、各プラットフォームから受注CSVをエクスポートする
フォーマットを整えて勘定奉行や弥生会計にインポートする
在庫数を各ECバックエンドと社内スプレッドシートで突き合わせる
全部終わる頃には午後になっており、データはすでに昨日のものだ

これが「二重入力」である。EC運営チームが少人数で回している日本の中小企業において、これは些細な非効率ではない。毎日積み重なる構造的なコストだ。人件費が消費され、入力ミスが発生し、月次決算が遅れ、在庫判断は常に古いデータをもとに下される。

本質的な問題はここにある。Shopify・楽天・Amazon・勘定奉行・弥生・freee・SAP Business One——これらすべてにAPIが存在する。データは自動で流れることができる。流れていないのは、まだ「橋」が架かっていないからだ。

本稿では、その橋がどのような構造を持ち、何を自動化し、どう実装するかを解説する。

なぜiPaaSでは解決できないのか

IT部門の第一反応はZapierやMake等のiPaaSツールに手を伸ばすことが多い。低ボリュームのシンプルなユースケースであれば機能する。しかしEC連携をある規模以上で運用しようとすると、すぐに限界に突き当たる。

EC受注データは単純ではない。

楽天の1件の注文には、以下が含まれることがある。

税率の異なる複数の明細行（標準税率・軽減税率の混在）
独立して仕訳が必要な送料
仕訳構造に影響するクーポンやポイント値引き
売掛金の計上先を決める決済手段（クレジットカード・コンビニ払い・銀行振込）
一度確定した取引を修正する返品・一部キャンセル

汎用的な自動化ツールはフィールドをマッピングする。会計ロジックを理解しない。エッジケースが発生したとき——必ず発生するのだが——仕訳が誤って登録されるか、自動化が無音で失敗して手作業が戻ってくる。

もう一つの問題は日本固有の事情だ。勘定奉行と弥生会計はモダンなREST APIを持っていない。 勘定奉行はCOMベースのインターフェースとバージョン依存のCSVインポート形式を持つ。弥生は独自のインポート形式を使う。freeeは正規のREST APIを持つ。SAP Business OneはService Layerを持つ。それぞれが完全に異なるアプローチを必要とし、いずれもZapierやMakeが前提とするSalesforceやQuickBooks向けの設計では対応できない。

だからこそ、橋はカスタムで構築する必要がある。

アーキテクチャ：カスタムミドルウェア層

解決策は専用のミドルウェアサービスだ。ECプラットフォームと基幹システムの間に置く軽量なAPIレイヤーであり、汎用ツールが処理できない変換・変形・ルーティングを担う。

flowchart TD
    subgraph EC["ECプラットフォーム"]
        SHOPIFY["Shopify\nAdmin API"]
        RAKUTEN["楽天 RMS\n受注 API"]
        AMAZON["Amazon Japan\nSP-API"]
        WOO["WooCommerce\nREST API"]
    end

    subgraph MIDDLEWARE["カスタムミドルウェア FastAPI"]
        INGEST["受注取込・正規化"]
        RULES["ビジネスルールエンジン\n税率 / 値引 / 返品 / 決済ルーティング"]
        TRANSFORM["データ変換\n仕訳生成 / 在庫差分計算"]
        QUEUE["ジョブキュー\n再試行・重複排除"]
    end

    subgraph CORE["基幹システム"]
        KANJO["勘定奉行\nCSV Import"]
        YAYOI["弥生会計\nImport"]
        FREEE["freee\nREST API"]
        SAP["SAP Business One\nService Layer"]
        INV["在庫 DB\nPostgreSQL"]
    end

    subgraph NOTIFY["通知・モニタリング"]
        SLACK["Slack / LINE Notify"]
        EMAIL["メールアラート"]
        DASH["オペレーターダッシュボード"]
    end

    SHOPIFY -->|"Webhook"| INGEST
    RAKUTEN -->|"ポーリング"| INGEST
    AMAZON -->|"ポーリング"| INGEST
    WOO -->|"Webhook"| INGEST

    INGEST --> RULES
    RULES --> TRANSFORM
    TRANSFORM --> QUEUE

    QUEUE -->|"CSV生成"| KANJO
    QUEUE -->|"CSV生成"| YAYOI
    QUEUE -->|"API呼出"| FREEE
    QUEUE -->|"Service Layer"| SAP
    QUEUE --> INV

    QUEUE -->|"エラー・完了"| SLACK
    QUEUE -->|"エラー・完了"| EMAIL
    QUEUE -->|"ステータス"| DASH

各コンポーネントの役割を説明する。

受注取込・正規化

全ECプラットフォームからの受注イベントを受け取る。Webhookが使えるプラットフォーム（Shopify・WooCommerce）はリアルタイムで受信し、Webhookに対応していないプラットフォーム（楽天RMS・Amazon SP-API）は定期ポーリングで取得する。取得後は、ソースプラットフォームに関わらず単一の内部受注スキーマに正規化する。この段階以降のミドルウェアは、注文がShopifyからのものか楽天からのものかを区別しない。

ビジネスルールエンジン

会計ロジックが集約されるコアコンポーネントだ。ルールは設定可能であり、以下をカバーする。

税率処理 — 標準税率・軽減税率（食品・新聞等）・非課税品の判別と仕訳分岐
値引・クーポン処理 — プラットフォーム発行クーポン（楽天負担）と出店者発行クーポン（自社負担）の区別、ポイント値引きの会計処理
決済手段別ルーティング — クレジットカードは売掛金勘定へ、コンビニ払いは入金確認まで仮受金として保留、銀行振込は入金通知受信後に確定
返品・キャンセル処理 — 一部返品は元の仕訳を按分修正、全額キャンセルは逆仕訳を自動生成
プラットフォーム手数料 — 楽天・Amazonの販売手数料は販売費として月次精算データから抽出・計上

データ変換

ルール処理済みの受注を、対象の会計システムが要求する正確な出力形式に変換する。勘定奉行と弥生会計向けにはバージョン固有のCSVインポートファイルを生成する。freee向けは正規のAPIペイロードを構築する。SAP Business One向けはService Layerに対して正しいドキュメントタイプと明細構造のリクエストを組み立てる。

ジョブキュー

信頼性を担保するコンポーネントだ。すべての出力ジョブはキューに積まれ、失敗時は自動再試行され、重複排除処理によってWebhookの二重送信が二重仕訳を引き起こさないよう制御される。失敗したジョブはフルペイロードとともにログに残り、手動確認と再処理が可能だ。

プラットフォーム別の自動化フロー

このミドルウェアが稼働すると、日次の運用は次のように変わる。

いずれかのプラットフォームで受注発生 → 数秒以内にミドルウェアがイベントを受信 → ビジネスルール適用 → 仕訳エントリ生成 → 会計システムへ送信 → 在庫更新 → 完了ログ記録

CSVエクスポートなし。手動インポートなし。突き合わせ作業なし。会計システムはほぼリアルタイムで実態を反映する。

Shopify → freee

新規受注のWebhookが即時トリガーされる。明細行は商品売上勘定にマッピングされる。送料は運賃収入勘定に計上される。Shopify Paymentsの振込（ペイアウト）が着金した際に預金入金仕訳が自動生成される。返金はShopifyのRefund Webhookを受けて元仕訳を自動逆転する。

楽天 → 勘定奉行

RMS受注APIから15分間隔でポーリングする。楽天のポイント値引き構造——楽天負担ポイント（プラットフォーム費用、出店者費用ではない）と出店者負担ポイント（自社コスト）——を区別して処理する。月次精算データから手数料を抽出して販売費として計上する。出力は勘定奉行のCSVインポート形式で生成され、スケジュールに従って自動インポートされる。

Amazon Japan → 弥生会計

Amazon SP-APIから受注を取得し、FBA（フルフィルメントby Amazon）とFBM（出店者出荷）を区別して処理する——フルフィルメントコストの会計処理が異なるためだ。Amazonの精算レポートを解析して、手数料控除後の実際の純受取額（グロスの受注金額とは異なる）を抽出する。インストール済みバージョンに対応した弥生インポートファイルを生成する。

WooCommerce / カスタムEC → SAP Business One

受注はService Layer経由でSAP販売オーダーにマッピングされる。受注作成時点でSAPの在庫が即時減算される。出荷確定時に請求書が生成される。入金確認時に入金仕訳が転記される。受注から入金までの全サイクルが手動介入なしに完結する。

在庫：問題の第二の側面

仕訳の自動化は全体の半分にすぎない。在庫側も同様に重要だ。

同一SKUがShopify・楽天・Amazonで同時に販売されている場合、ミドルウェアはPostgreSQLの内部在庫DBで単一の在庫ソースを管理する。いずれかのプラットフォームでの販売は同じ在庫プールから減算され、入庫イベントはプールに加算される。更新された在庫数は各プラットフォームの在庫APIに書き戻される。

これにより、マルチプラットフォームEC運営で最も痛い事態を防ぐことができる。在庫の二重販売——楽天で注文を受けたと同時にAmazonでも同じ商品が売れ、キャンセル・低評価・楽天ペナルティポイントが発生するシナリオだ。

このアーキテクチャが「やらないこと」

スコープについて明確にしておく。

このミドルウェアはERP置き換えではない。勘定奉行・弥生・freee・SAPの機能を再現しようとするものではない。既存の勘定科目体系・マスタデータ・承認ワークフローには一切手を加えない。すでに使っている会計システムに対して、正しくフォーマットされたデータを送り込むだけだ。会計システム側の設定変更は不要である。

ECプラットフォームの置き換えも不要だ。ShopifyはShopifyのまま。楽天は楽天のまま。ミドルウェアは既存APIで接続する。ストアフロント側は何も変わらない。

一般的な実装スコープは8〜16週間。関与するプラットフォームと会計システムの数、ビジネスルールの複雑さ、移行が必要な過去データ量によって変動する。週末プロジェクトではないが、数年規模のERP刷新プロジェクトでもない。

今すぐ自動化が必要なサイン

以下の状況に3つ以上当てはまる場合、手動プロセスはすでに限界に達しており、自動化しないコストが構築コストを上回っている。

月次決算に3日以上かかる理由として、ECデータの突き合わせがボトルネックになっている
過去6ヶ月以内に、複数プラットフォームをまたぐ在庫の二重販売が1件以上発生した
EC〜会計間のデータ転送作業に週5時間以上の人件費が費やされている
経理チームが24時間以上古いデータをもとに業務を行っている
新しいECプラットフォームへの出店を検討しているが、またCSV作業が増えることが懸念材料になっている

まとめ

日本のECプラットフォームと基幹会計システムの間のデータパイプラインは、技術的に定義されている。Shopify・楽天・Amazon・WooCommerceはすべてAPIで受注データを公開している。freeeとSAP Business Oneはプログラムから受け取れる。勘定奉行と弥生会計は自動生成できるインポート形式を持っている。

技術的な障壁ではなく、欠けているのは日本の会計ロジックを理解し、エッジケースを正しく処理し、正しい形式で正しいシステムにデータをルーティングするミドルウェア層だ。