在 UreyukiBox
お知らせを受け取る

ブログ /

Stocky の発注書・仕入先データを失わずに移行する実務ガイド

TL;DR

  • Stocky 終了後はアプリ自体が停止するため、8 月 31 日までにデータを取り出さないと永久ロストになる前提で動く。
  • 取り出すべきは 4 種: 仕入先（Suppliers）/ 発注書（Purchase Orders）/ 在庫調整（Stock Adjustments）/ 税区分（Tax Types）。
  • 取り出し方法は 3 経路: Stocky 管理画面の CSV エクスポート / Stocky API / 手動コピー。API が最も完全。
  • 落とし穴は 5 つ: API キー権限、PO 履歴の紐付き、税区分マッピング、在庫調整の数値精度、棚卸結果の保管期間。
  • 本記事の最後に 移行作業チェックリスト（テキストでそのまま使える形式）を載せています。

関連: Stocky 終了｜2026 年 8 月 31 日でサポート停止、Shopify 在庫管理はどうする？ / Stocky 代替アプリ徹底比較

なぜ「データ移行」が単独の論点になるのか

Stocky の終了は「アプリの停止」だけが問題ではありません。Stocky 内に蓄積された 1 年分以上の運用データが取り出せなくなるリスクが本質です。

具体的には:

  • 仕入先マスタ（連絡先・支払サイト・通貨など）→ 別アプリで再登録に数日〜週単位
  • 過去の発注書履歴 → 仕入交渉や原価分析の根拠資料として 必要なケースが多い
  • 棚卸の差異記録（在庫調整）→ 会計監査・税務調査時の証跡として 保管義務（青色申告 7 年、白色申告 5 年）
  • 税区分マスタ → 軽減税率対応や輸出入 0% 税率の整合性

これらが「Stocky の中でしか参照できない状態」のまま 8 月 31 日を越えると、復元手段が消滅します。

取り出すべき 4 種データ

1. 仕入先（Suppliers）

Stocky 内の仕入先は Shopify 標準の仕入先フィールドとは独立して管理されています（Shopify は商品ベースの supplier 文字列のみ、Stocky は仕入先ごとのレコード）。

含まれる情報の例:

  • 仕入先名、連絡先メール、電話番号
  • 支払条件（NET 30、前払い等）
  • 通貨（JPY、USD 等）
  • 最低発注金額（MOQ）
  • 配送リードタイム

2. 発注書（Purchase Orders）

Stocky の核機能。ステータスは draft / 発注済み / 一部入荷 / 完了 等。1 PO に複数 SKU + 数量 + 単価が紐付く。

過去の PO は 仕入交渉時の根拠（このサプライヤーは過去 X 円で売ってくれた）になるので、捨てられない。

3. 在庫調整（Stock Adjustments）

棚卸や検品で在庫数を補正したログ。「なぜ Shopify 在庫数が変わったのか」の理由が記録されている。

会計上は 増減事由の根拠資料 として保管義務あり。

4. 税区分（Tax Types）

軽減税率（8%）/ 標準税率（10%）/ 非課税 / 免税 などのマスタ。

商品ごとに紐付けられているので、Stocky の税区分マスタを失うと 商品の税率設定を再構築する必要が出る。

取り出し方法 3 経路の比較

方法完全性工数推奨度
CSV エクスポート（管理画面）△（一部のみ、フィルタ依存）低★★
Stocky API◎（全件、構造化）中★★★
手動コピー（スクリーンショット等）×極大★

CSV エクスポートでカバーされる範囲

Stocky 管理画面 → 各セクション → エクスポートボタン で取得可能:

  • ✅ 仕入先（Suppliers）— 一覧形式
  • ✅ 発注書（Purchase Orders）— ヘッダ情報のみ、明細は別途
  • △ 在庫調整 — フィルタ期間内のみ、過去全件は手動でページング
  • △ 税区分 — 一覧の取得は可能、商品との紐付きは別データ

→ CSV だけだと PO 明細や紐付き情報が抜けるので、API 取得の補完が必要。

Stocky API（推奨）

Stocky は内部 v2 API を提供しており、API キーを発行することで以下にアクセス可能:

  • GET /api/v2/suppliers — 全仕入先
  • GET /api/v2/purchase_orders — 全発注書（ページング、include で line_items / supplier も取得可能）
  • GET /api/v2/stock_adjustments — 全在庫調整
  • GET /api/v2/tax_types — 全税区分

JSON で取得できるので 構造化が保たれた状態で別 DB へ投入できる。

API キーの発行手順

  1. Stocky 管理画面にログイン
  2. Settings → API access
  3. 「Generate new key」
  4. 権限スコープ: read-only で十分（書き込みは不要）
  5. キーを安全な場所にコピー（再表示不可）

API 利用時の注意

  • レート制限: 1 秒に 2 リクエスト程度を上限に運用（過剰だと 429 エラー）
  • ページング: ?page=1&per_page=50 のように指定、全ページを順次取得
  • 有効期間: Stocky アプリ停止と同時に API も停止する見込み（8 月 31 日まで限定）

5 つの落とし穴

落とし穴 1: API キー権限の不足

「とりあえず最小権限で」と考えて発行すると、API が想定より少ないデータしか返さない。

対策: 移行用には read-only の全範囲権限を 1 つ発行。書き込み権限は不要。終了後は削除。

落とし穴 2: PO 履歴と仕入先の紐付き

PO の中の supplier_id が仕入先テーブルの id と紐付いているが、移行先アプリで仕入先を 新規 ID で登録し直す と、PO 側の supplier_id が指す先が無くなる。

対策: 仕入先を先に移行 → 仕入先の旧 ID と新 ID のマッピングを保持 → PO 投入時にマッピングで置換。

落とし穴 3: 税区分マッピング

Stocky の「Reduced rate 8%」「Standard rate 10%」のような区分名が、移行先アプリでは別の用語を使っているケース。

対策: 税区分は マッピング表 を作って手動 or スクリプトで置換。商品 → 税区分 の関連も並行して更新。

落とし穴 4: 在庫調整の数値精度

在庫調整の数量に 小数点が含まれる ケース（Stocky は整数のみだが、kg 単位等で運用してた場合）。移行先によっては精度が違う。

対策: 数値型を確認し、必要なら 桁丸め ルールを決める（例: 小数第 2 位で切り捨て）。

落とし穴 5: 棚卸結果の保管期間

「過去 5 年分の棚卸結果」を移行先システムに投入したくても、移行先が 1 年分しか保持しないケース。

対策: 生データ（CSV / JSON）を社内ストレージに別途保管。移行先システムには直近 1-2 年だけ投入し、過去分は外部参照とする。

移行作業チェックリスト

事前準備（〜2026 年 6 月）

  • Stocky 管理画面ログイン確認（管理者権限）
  • Stocky API キー発行（read-only 全範囲）
  • 移行先アプリ選定完了（Stocky 代替アプリ徹底比較 参照）
  • 棚卸サイクル直前であれば実施 → Stocky に最新データ反映

4 種データ取得

仕入先

  • CSV エクスポート保存（管理画面）
  • API GET /suppliers で JSON 全件取得 → ファイル保存
  • 件数を 2 経路で照合

発注書

  • CSV エクスポート保存（管理画面、ヘッダのみ）
  • API GET /purchase_orders?include=line_items,supplier で全件 JSON 取得
  • PO ステータス分布を確認（draft / 発注済 / 完了）

在庫調整

  • API GET /stock_adjustments で全件 JSON 取得
  • 期間別件数で分布確認

税区分

  • CSV エクスポート保存
  • API GET /tax_types で全件 JSON 取得
  • 商品との紐付け（product → tax_type_id）を別途取得 or CSV で確認

移行先への投入

  • 仕入先を移行先に登録 → 旧 ID → 新 ID マッピング表を作成
  • 税区分マスタを移行先に作成 → 同マッピング表作成
  • PO を JSON から再構成 → supplier_id を新 ID に置換 → 投入
  • 在庫調整を JSON から投入（時系列順）
  • 商品の税区分紐付けを更新

移行後検証

  • 仕入先件数が一致するか確認
  • 直近 30 日の PO が正しく表示されるか確認
  • 在庫調整の合計が Shopify 在庫数と整合しているか確認
  • 税区分が商品に正しく紐付いているか確認

バックアップ保管

  • 取得した CSV / JSON を社内ストレージ（Google Drive、Dropbox、S3 等）に保管
  • 保管期間: 少なくとも 7 年（青色申告の保存期間）
  • 棚卸結果のサマリ（PDF）を会計士と共有

8 月 31 日（終了当日）

  • 最終バックアップ（直前の運用変更を含む）
  • 移行先で 9 月 1 日からの初回サイクル運用を確認
  • Stocky アプリは念のためアンインストールせず残す（停止後にデータ確認できる可能性に備える）

自動化の選択肢

上記を手動で全部やるのは結構な工数（小規模ストアでも 1-2 日）です。専用アプリで自動化する選択肢:

  • UreyukiBox（本サイト運営・2026 年 7 月 15 日ローンチ予定）: Stocky API キーを入力するだけで 4 種データを自動取得 → 自社 DB に永続保存。移行が完遂できなければ全額返金。
  • Fabrikatör: 海外発、人手サポート明示。英語対応のみ。
  • 自社開発スクリプト（Python + httpx 等）: 開発リソースがあれば自前で API 叩いて投入。最も柔軟。

FAQ

Q. Stocky API のドキュメントはどこ？

A. 公式ドキュメントは限定公開（Shopify Partners ポータル経由）。Stocky のレスポンス構造は v2 で公開されています。在庫管理アプリの開発者向けに apps.shopify.com/stocky 関連で API 仕様の解説記事や OSS のクライアントが存在します。

Q. API キーを 8 月 31 日以降も使える？

A. 不可の前提で動く。Shopify が公式に「アプリ終了 = API 停止」と明示してはいませんが、Stocky 内部の API サーバが停止すれば自動的に 401/503 系で応答不能になります。8 月 31 日までに全データを取り出すのが安全。

Q. CSV と JSON はどっちが安全？

A. 両方取っておく。CSV は人間可読で会計士との共有に便利、JSON は構造化されて再投入しやすい。冗長性のため両方保管推奨。

Q. 移行先で「Stocky の supplier_id を保持する」のは可能？

A. アプリによる。移行先が 外部 ID（external_id） フィールドを持っていれば、そこに stocky:123 のような形で旧 ID を保存できる。後から照合する必要が出た時に便利。UreyukiBox は外部 ID をフィールドに持つ設計です。

まとめ

データ移行は 「いつかやろう」と先送りすると間に合わない領域です。1 ストア当たり手作業で 1-2 日、API スクリプト書いて自動化しても準備に半日。6 月中に試行 → 7 月中に本番移行 → 8 月は移行先での運用慣れ くらいのスケジュールが安全です。

UreyukiBox の移行ウィザードは、これを API キー入力 + ボタン 1 つ + 数分待機 で完了するように設計しています（移行が完遂できなかった場合は全額返金保証）。

関連記事