毎朝カートの管理画面を開いて、注文を Excel へ写す。実験用ショップで数えたら、受注 30 件の転記は見積りで約 42 分かかる計算でした。これを WooCommerce REST API の在庫連携スクリプトに置き換えたら、取得から転記まで約 2 秒。しかも手転記に混ぜた 3 件のミスを、在庫突合が全部あぶり出しました。ローカルに本物のショップを立てて測った記録です。
結論：転記 30 件は約 2 秒、在庫のズレは 0 件になった
結論から言うと、「受注を台帳へ写して在庫と突き合わせる」という二重管理の接続部は、WooCommerce REST API（wc/v3）でそのまま自動化できました。既製ツールなしの在庫連携です。実際に計測した数字を並べます。
| 項目 | 手作業（見積り） | API 連携（実測） |
|---|---|---|
| 受注 30 件（明細 58 行）の転記 | 約 31〜54 分 | 約 2 秒（取得 1.94 秒 + 転記 0.001 秒未満） |
| 転記ミス | 3 件混入 → 目視では気づきにくい | 在庫突合で 4 SKU のズレとして全件検出 |
| 在庫の一致（120 SKU） | 4 SKU でズレ | ズレ 0 件（完全一致） |
| かかった費用 | — | 0 円（WooCommerce と Python のみ） |
手作業の時間だけは実測ではなく見積りです。明細 58 行 × 8 フィールド = 464 回の目視コピーを 1 回 3〜5 秒、注文 30 件の画面遷移を 1 件 15〜30 秒として積み上げました。誇張しないために、ここは「見積り」と明記しておきます。
EC の「二重管理」は何が問題か
受注はカートの管理画面にある。でも台帳と在庫は Excel にある。この状態が二重管理です。データが 2 か所にあること自体は悪くありません。問題は、その 2 か所を毎日「人の目と手」でつないでいることです。
手転記には打ち間違い・取り違え・写し漏れが必ず混ざります。しかも在庫のズレは、欠品か棚卸しで発覚するまで気づきにくい。Excel 在庫管理の限界を扱う解説でも、他業務との連携部分の転記・二重入力が弱点とされています。Excel を捨てる必要はなくて、転記という接続部だけ自動化すればいい。これが今回の立場です。
ちなみに、台帳側が育ちすぎてマクロの塊になった現場の話は属人化 Excel マクロを AI で解析した記事に書きました。今回はその手前、「台帳へ写す」段階の自動化です。
実験の設計：使い捨てショップ「ミナトヤ珈琲オンライン」を立てた
試すからには本物で測りたい。そこでローカルに実験専用の WordPress を新設して、WooCommerce の架空ショップを 1 つ作りました。コーヒー豆と器具で 120 SKU、受注 30 件（明細 58 行）。商品名も顧客名もすべて合成ダミーで、実在のデータは一切使っていません。
環境と構成
| WordPress | 7.0（ja） |
| WooCommerce | 10.9.4（実験日の最新） |
| PHP / MySQL | 8.2.29 / 8.0.35 |
| クライアント | Python 3.13 + 公式 woocommerce パッケージ 3.0.0 |
| REST API | wc/v3（公式リファレンス） |
1 点だけ注記すると、この新規セットアップでは注文ストレージの HPOS が無効のままでした。環境によって有効・無効が分かれるので、「最新版なら必ず HPOS」とは思い込まないほうが安全です。
最初のつまずき：HTTP では Basic 認証が「黙って」失敗する
API キー（consumer key / secret）を発行して、さっそく Basic 認証でリクエスト。返ってきたのはこれでした。
{"code":"woocommerce_rest_cannot_view",
"message":"Sorry, you cannot list resources.",
"data":{"status":401}}キーは正しいのに 401。ここはちょっとハマりました。WooCommerce の仕様で、Basic 認証が使えるのは HTTPS のときだけです。非 SSL の HTTP では資格情報がエラーにならず「黙って無視」されて、匿名扱いの 401 が返ります。ローカルや社内のテスト環境で詰まる典型だと思います。
HTTP のままなら OAuth 1.0a の署名が必須です。公式の Python パッケージが署名を自動でやってくれるので、切り替えたら一発で 200 が返りました（疎通 0.318 秒）。なお API キーも認証情報なので、権限は必要最小限に絞るのが基本です。このあたりの考え方はWordPress の多層防御の記事で書いています。
受注の取得から台帳の転記まで
受注 30 件の取得は 3 リクエスト・1.9 秒
GET /wp-json/wc/v3/orders をページネーション（per_page=10）で回すと、3 リクエストで全 30 件が取れました。所要は初回 1.936 秒、2 回目以降は 0.822 秒。返ってくる JSON はこんな形です（1 件抜粋・顧客は架空）。
{
"id": 131,
"status": "completed",
"date_created": "2026-07-08T08:36:22",
"total": "5400.00",
"currency": "JPY",
"billing": { "first_name": "中島 奈々", "email": "dummy1@example.test" },
"line_items": [
{ "name": "ポーレックス コーヒーミル II",
"sku": "MYC-0096", "quantity": 1, "total": "5400.00" }
]
}注文番号・日付・顧客名・SKU・数量・金額・ステータス。台帳に写したい項目が最初から構造化されています。手転記でやっていたのは、この JSON を人間が目でパースする作業だったわけです。
台帳への転記は 58 行で 0.001 秒未満
取得した JSON を openpyxl で Excel 台帳（.xlsx）へ流し込みます。出力は 58 行。転記処理そのものは 0.00082 秒で、ボトルネックは API の往復でした。つまり取得と合わせても約 2 秒。自動転記された台帳の実物がこちらです。
注文番号,日付,顧客名,SKU,商品名,数量,金額,ステータス
131,2026-07-08,中島 奈々,MYC-0096,ポーレックス コーヒーミル II,1,5400,完了
132,2026-07-08,中村 太郎,MYC-0103,ボダム フレンチプレス 350ml,3,11400,完了
132,2026-07-08,中村 太郎,MYC-0042,コスタリカ タラス 深煎り 500g,4,8280,完了
133,2026-07-08,斎藤 一郎,MYC-0029,ケニア AA 深煎り 200g,3,2910,処理中
（以下 58 行まで続く）手転記のミスは、在庫では「4 SKU のズレ」になった
自動化の価値は速さより検出です。ここを確かめるために、手転記でよくあるミスを 3 件だけ意図的に混ぜた「手作業版の台帳」を別に作りました。実データの改ざんではなく、教材用に仕込んだダミーの誤りです。
131,…,MYC-0096,ポーレックス コーヒーミル II,6,… ← 正しくは数量 1（打ち間違い）
132,…,MYC-0001,エチオピア イルガチェフェ…,3,… ← 正しくは MYC-0103（SKU 取り違え）
132 の MYC-0042（数量 4）の行が存在しない ← まるごと転記漏れそのうえで在庫を突き合わせます。ロジックは単純で、「棚卸し時点の開始在庫 − 台帳の売上数量 = 理論在庫」を SKU ごとに計算し、API から取った実在庫（stock_quantity）と比べるだけ。
結果、自動転記の台帳は 120 SKU すべて一致（ズレ 0 件）。手作業版は 4 SKU のズレが検出されました。突合スクリプトの実出力がこれです。
| SKU | 開始在庫 | 台帳売上 | 理論在庫 | 実在庫 | 差 | 起因 |
|---|---|---|---|---|---|---|
| MYC-0096 | 82 | 9 | 73 | 78 | −5 | 数量の打ち間違い |
| MYC-0001 | 57 | 3 | 54 | 57 | −3 | 取り違えで生えた幻の売上 |
| MYC-0103 | 51 | 0 | 51 | 48 | +3 | 売上が別 SKU へ消えた |
| MYC-0042 | 104 | 0 | 104 | 100 | +4 | 行の転記漏れ |
面白いのは、ミス 3 件がズレ 4 件になったことです。SKU の取り違えは「幻の売上が立った SKU」と「売上が消えた SKU」の両方をズラすので、1 つのミスが 2 か所に現れます。目視でこの対応関係を追うのは、正直かなりつらい作業です。
在庫書き戻しの罠：batch は 100 件まで、超えると全件拒否
在庫連携の仕上げは書き戻しです。棚卸し結果の反映には一括更新の POST /wc/v3/products/batch を使います。ここで仕様を実機で確かめました。件数を変えて投げた結果です。
| 件数 | HTTP | 適用 | 所要 |
|---|---|---|---|
| 20 件 | 200 | 20 件更新 | 1.600 秒 |
| 100 件 | 200 | 100 件更新 | — |
| 101 件 | 413 | 0 件 | — |
| 120 件 | 413 | 0 件 | 0.159 秒 |
{
"code": "woocommerce_rest_request_entity_too_large",
"message": "Unable to accept more than 100 items for this request.",
"data": { "status": 413 }
}上限はちょうど 100 件。そして超過すると「先頭 100 件だけ処理」ではなく、リクエスト全体が 413 で拒否されて 1 件も適用されません。120 件投入後に在庫を検証したら、書き換わった SKU は 0 件でした。中途半端に反映されない分だけ安全ともいえますが、知らないと「一部だけ更新されたはず」と思い込みそうな挙動です。120 SKU なら 100 + 20 の 2 回に分けます。
もうひとつ。wc/v3 の REST API には既定のレート制限がありません（制限機構があるのはカート向けの Store API だけで、しかも既定は無効。公式ドキュメント参照）。つまり自作スクリプトで無造作に叩くと、自分の店を自分で重くします。batch でまとめる・間隔を空ける、は自衛のマナーです。
正直な注意点：自作が向かない場面
2 秒の実測を見せておいてなんですが、何でも自作すればいいとは思っていません。向かない場面をはっきり書いておきます。
- 楽天・Amazon など複数モールの一元化：モールごとの API 仕様・認証・仕様変更への追従を、すべて自前で抱えるのは重荷です。対応モール 50 以上をうたうネクストエンジン（月額 3,000 円〜の従量制）のような既製ツールのほうが合理的なケースは普通にあります
- 在庫まわりの API 挙動を検証せずに本番投入する運用：過去には下書き注文の操作で在庫が意図せず減るバグ（報告後に修正済み）がありました。使うバージョンで在庫の増減を一度測ってからが安全です
- 「作って終わり」にしたい場合：スクリプトは WooCommerce の更新のたびに動作確認が要ります。保守する人がいないなら、既製ツールの月額は保守費と考えると高くありません
逆にいうと、自社サイトの受注と手元の Excel 台帳、あるいは基幹系との接続部のような「既製ツールがつないでくれない部分」こそ、自作の在庫連携が刺さる場所です。
まとめ：二重管理の「接続部」だけ自動化する
- 受注 30 件（明細 58 行）の取得〜台帳転記は実測約 2 秒。手作業見積り 31〜54 分との差は桁が 3 つ
- 手転記ミス 3 件は在庫突合で 4 SKU のズレとして全件検出できた。速さより、この検出が自動化の本命
- 非 SSL では Basic 認証が黙って 401 になる。HTTP のままなら OAuth 1.0a が必須
- batch の上限は 100 件ちょうどで、超過は全件拒否。分割前提で設計する
- 多モール一元化は既製ツール、既製ツールがつながない接続部は自作。使い分けが現実解
今回のような受注・在庫の API 連携は、NEORIVA として法人向けにも構築しています。既製の一元管理ツールでつながらない部分を個別開発でつなぐ、という相談が入り口になることが多いです。ほかの自動化の実測は業務自動化・API連携のカテゴリにまとめています。
